mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: "Jan Lübbe" <jlu@pengutronix.de>
To: Jonas Rebmann <jre@pengutronix.de>,
	Sascha Hauer <s.hauer@pengutronix.de>
Cc: BAREBOX <barebox@lists.infradead.org>
Subject: Re: [PATCH v2] tlv: Add tlv_bind_soc_uid mapping
Date: Wed, 19 Nov 2025 16:15:40 +0100	[thread overview]
Message-ID: <11773b48d0ce0781f1ec24e3a98e81137f913de1.camel@pengutronix.de> (raw)
In-Reply-To: <e630c09b-8eba-48aa-8f10-0d17a4d9df60@pengutronix.de>

On Tue, 2025-11-18 at 10:57 +0100, Jonas Rebmann wrote:
> Hi again, tiny addition:
> 
> On 2025-11-18 10:49, Jonas Rebmann wrote:
> > On 2025-11-18 09:40, Sascha Hauer wrote:
> > To me the big question is: What is a SoC UID?
> > 
> > Is it an arbitrary string that happens to be, for many SoCs composed of
> > [0-9A-F] and efficiently represented in binary in the efuses? Then it
> > feels a bit surprising to me to compare this 'arbitrary vendor-provided
> > string' case-insensitively.
> > 
> > But if we consider this an arbitrary block of binary data, typically
> > looked at in hexadecimal then I suggest we use the raw "bytes"-format I
> > sent an RFC patch for on Nov 12, and compare to
> > barebox_get_soc_uid_bin(). I originally wrote that RFC patch for storing
> > SoC UIDs but had a conversation with Ahmad that led me to view the SoC
> > UID as an arbitrary string. However now that we have
> > barebox_get_soc_uid_bin(), I'm tempted to change my mind.
> 
> I did consider changing this for v2 however in your [PATCH v2 1/9]
> "introduce SoC UID" you mentioned that "Others even print the binary
> data as decimal (qcom).". If we where to use 'raw "bytes"-format' as in
> my RFC, the data YAMLs would have hexadecimal representation and I'm not
> sure if that could get too confusing. At least we could consider to add
> a (mandatory?) YAML-field that specifies the number system.

As the UID is normally read from registers or messages exchanged with a security
enclave, each SOC vendor has already defined a binary format. We should just
store that unmodified in the TLV value instead of inventing a custom format.

In the schema yaml file, we could freely define how a "bytes" format is
translated from and to a human readable representation, by adding an "text-
encoding" property (e.g. "hex-lower"/"hex-upper"/"base64") as fits each use-
case.

Jan
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



  reply	other threads:[~2025-11-19 15:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-17 17:14 Jonas Rebmann
2025-11-18  8:40 ` Sascha Hauer
2025-11-18  9:49   ` Jonas Rebmann
2025-11-18  9:57     ` Jonas Rebmann
2025-11-19 15:15       ` Jan Lübbe [this message]
2025-11-24 10:35         ` Sascha Hauer
2025-11-24 19:58           ` Jonas Rebmann
2025-11-18 13:56     ` Sascha Hauer
2025-11-19 15:05 ` Jan Lübbe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11773b48d0ce0781f1ec24e3a98e81137f913de1.camel@pengutronix.de \
    --to=jlu@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=jre@pengutronix.de \
    --cc=s.hauer@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox