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 |
next prev parent 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