From: Sascha Hauer <s.hauer@pengutronix.de>
To: "Jan Lübbe" <jlu@pengutronix.de>
Cc: Jonas Rebmann <jre@pengutronix.de>,
BAREBOX <barebox@lists.infradead.org>
Subject: Re: [PATCH v2] tlv: Add tlv_bind_soc_uid mapping
Date: Mon, 24 Nov 2025 11:35:45 +0100 [thread overview]
Message-ID: <aSQ1AWPxHw4knocf@pengutronix.de> (raw)
In-Reply-To: <11773b48d0ce0781f1ec24e3a98e81137f913de1.camel@pengutronix.de>
On Wed, Nov 19, 2025 at 04:15:40PM +0100, Jan Lübbe wrote:
> 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.
The format is not custom, it's the format Linux provides in sysfs.
It might be confusing if the SOC UID we use has a different format.
Sascha
--
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-24 10:36 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
2025-11-24 10:35 ` Sascha Hauer [this message]
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=aSQ1AWPxHw4knocf@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=jlu@pengutronix.de \
--cc=jre@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