linux-kernel - Re: [PATCH 1/4] arm64: dts: mediatek: mt7622: add 'serial' cell to efuse

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <9d895847-9dd8-45e4-bc3f-a27e80371836@collabora.com>
Date: Wed, 17 Sep 2025 13:53:57 +0200
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Matthias Brugger
 <matthias.bgg@...il.com>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 1/4] arm64: dts: mediatek: mt7622: add 'serial' cell to
 efuse

Il 17/09/25 12:08, Daniel Golle ha scritto:
> On Wed, Sep 17, 2025 at 11:06:13AM +0200, AngeloGioacchino Del Regno wrote:
>> Il 17/09/25 01:05, Daniel Golle ha scritto:
>>> The efuse of the MediaTek MT7622 contains an 8-byte unique identifier.
>>> Add a 'serial' cell covering those 8 bytes to the nvmem defininition of
>>> the efuse to allow easy access from userspace, eg. to generate a
>>> persistent random MAC address on boards like the BananaPi R64 which
>>> doesn't have any factory-assigned addresses.
>>
>> Sorry, but I don't get why this is named "serial" and not "soc-uuid".
>>
>> Care to explain?
> 
> I don't have documentation covering the efuse content but only got this
> information on an informal way:
> 
> https://forum.banana-pi.org/t/bpi-r3-serial-number/14556/10?u=dangowrt
> 
> Either name is fine with me, I thought of it as "serial number", but
> obviously "soc-uuid" works fine, too.
> I can change it to that and send v2 tonight.
> 

Aaaaaah that's why "serial", okay - I got confused because the eFuses contain
many "calibration data" entries, and that triggered me to think that it could
be a "serial calibration data" entry.

After reading the commit description it became very clear that the initial
impression was wrong, but then still, when reading the devicetree without having
the description of the commit introducing that, it's easy to get confused again.

In any case, well, it could be a serial number, or it could be a randomly generated
UUID - but since we don't know, I think that calling this "serial-no" may actually
be wrong anyway.

We can escape this uncertainty though: a serial number is supposed to be unique,
and it is used as an identifier (which identifies one, or multiple aspects, either
an increasing number for chip number, or one that says the production date and
chip number).

Seeing it like this, calling it "soc-uuid" identifies this array as containing a
number that uniquely identifies the chip, be it a serial number or a randomly
generated number.

In case you find out sure information that this is really a serial number (which
doesn't really look right, it's too many bytes, but you never know) you can always
come back later and add a comment in DT saying that it is just.. that.

For now, let's go with soc-uuid :-)

So please, change the name to soc-uuid on all four commits, after which, feel
free to add my

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>

to all four commits.

Cheers,
Angelo