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: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-17 17:14 [PATCH v2] tlv: Add tlv_bind_soc_uid mapping 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-26 11:16 ` Jan Lübbe
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.