Re: [PATCH v2] tlv: Add tlv_bind_soc_uid mapping

[Jonas Rebmann <jre@pengutronix.de>]

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.

Regards,
Jonas

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