From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH 1/4] arm64: dts: mediatek: mt7622: add 'serial' cell to efuse
Date: Wed, 17 Sep 2025 13:53:57 +0200 [thread overview]
Message-ID: <9d895847-9dd8-45e4-bc3f-a27e80371836@collabora.com> (raw)
In-Reply-To: <aMqImGmz0uf_aTUR@pidgin.makrotopia.org>
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@collabora.com>
to all four commits.
Cheers,
Angelo
prev parent reply other threads:[~2025-09-17 11:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-16 23:05 [PATCH 1/4] arm64: dts: mediatek: mt7622: add 'serial' cell to efuse Daniel Golle
2025-09-16 23:05 ` [PATCH 2/4] arm64: dts: mediatek: mt7986a: " Daniel Golle
2025-09-16 23:05 ` [PATCH 3/4] arm64: dts: mediatek: mt7981b: " Daniel Golle
2025-09-16 23:05 ` [PATCH 4/4] arm64: dts: mediatek: mt7988a: " Daniel Golle
2025-09-17 9:06 ` [PATCH 1/4] arm64: dts: mediatek: mt7622: " AngeloGioacchino Del Regno
2025-09-17 10:08 ` Daniel Golle
2025-09-17 11:53 ` AngeloGioacchino Del Regno [this message]
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=9d895847-9dd8-45e4-bc3f-a27e80371836@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=conor+dt@kernel.org \
--cc=daniel@makrotopia.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=robh@kernel.org \
/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