From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Alexey Charkov <alchark@flipper.net>
Cc: Srinivas Kandagatla <srini@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
Michael Walle <michael@walle.cc>,
Finley Xiao <finley.xiao@rock-chips.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/4] nvmem: layouts: Add Rockchip OTP CPUID layout driver
Date: Wed, 02 Sep 2026 11:40:52 +0200 [thread overview]
Message-ID: <878q5k7zyz.fsf@bootlin.com> (raw)
In-Reply-To: <20260901-rk3576-otp-cpuid-mac-v1-3-ea9135270fc2@flipper.net> (Alexey Charkov's message of "Tue, 01 Sep 2026 19:33:13 +0400")
On 01/09/2026 at 19:33:13 +04, Alexey Charkov <alchark@flipper.net> wrote:
> Rockchip SoCs customarily use the CPU ID programmed into their on-chip OTP
> memory to derive stable Ethernet MAC addresses even when a board doesn't
> otherwise have dedicated storage for those. The derivation depends on the
> particular bootloader implementation (e.g. it is done by upstream U-Boot,
> which patches the derived MAC addresses at runtime into the device tree it
> hands to the kernel). Using less featureful bootloaders, such as direct
> boot to Linux from SPL, leaves the kernel with only a random MAC address
> instead, even though everything required for the derivation is equally
> available to Linux as it is to U-Boot.
>
> Reproduce the same derivation in the kernel and expose the result as an
> nvmem cell named "mac-address", so that of_get_mac_address() picks it up
> through its standard nvmem fallback. The address index comes from the DT
> phandle argument, which lets both interfaces of a dual Ethernet board
> share a single cell.
>
> Enable the layout by default on Rockchip, as consumers of its cells would
> otherwise defer their probe indefinitely.
>
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
Quick review on my side, looks good to me.
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Alexey Charkov <alchark@flipper.net>
Cc: Srinivas Kandagatla <srini@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
Michael Walle <michael@walle.cc>,
Finley Xiao <finley.xiao@rock-chips.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/4] nvmem: layouts: Add Rockchip OTP CPUID layout driver
Date: Wed, 02 Sep 2026 11:40:52 +0200 [thread overview]
Message-ID: <878q5k7zyz.fsf@bootlin.com> (raw)
In-Reply-To: <20260901-rk3576-otp-cpuid-mac-v1-3-ea9135270fc2@flipper.net> (Alexey Charkov's message of "Tue, 01 Sep 2026 19:33:13 +0400")
On 01/09/2026 at 19:33:13 +04, Alexey Charkov <alchark@flipper.net> wrote:
> Rockchip SoCs customarily use the CPU ID programmed into their on-chip OTP
> memory to derive stable Ethernet MAC addresses even when a board doesn't
> otherwise have dedicated storage for those. The derivation depends on the
> particular bootloader implementation (e.g. it is done by upstream U-Boot,
> which patches the derived MAC addresses at runtime into the device tree it
> hands to the kernel). Using less featureful bootloaders, such as direct
> boot to Linux from SPL, leaves the kernel with only a random MAC address
> instead, even though everything required for the derivation is equally
> available to Linux as it is to U-Boot.
>
> Reproduce the same derivation in the kernel and expose the result as an
> nvmem cell named "mac-address", so that of_get_mac_address() picks it up
> through its standard nvmem fallback. The address index comes from the DT
> phandle argument, which lets both interfaces of a dual Ethernet board
> share a single cell.
>
> Enable the layout by default on Rockchip, as consumers of its cells would
> otherwise defer their probe indefinitely.
>
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
Quick review on my side, looks good to me.
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2026-09-02 9:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 15:33 [PATCH 0/4] nvmem: Derive Rockchip MAC addresses from the OTP CPU ID Alexey Charkov
2026-09-01 15:33 ` Alexey Charkov
2026-09-01 15:33 ` [PATCH 1/4] nvmem: rockchip-otp: Serialize reads Alexey Charkov
2026-09-01 15:33 ` Alexey Charkov
2026-09-01 15:39 ` sashiko-bot
2026-09-02 9:10 ` Miquel Raynal
2026-09-02 9:10 ` Miquel Raynal
2026-09-02 9:24 ` Alexey Charkov
2026-09-02 9:24 ` Alexey Charkov
2026-09-02 10:17 ` Miquel Raynal
2026-09-02 10:17 ` Miquel Raynal
2026-09-02 12:40 ` Alexey Charkov
2026-09-02 12:40 ` Alexey Charkov
2026-09-03 8:06 ` Miquel Raynal
2026-09-03 8:06 ` Miquel Raynal
2026-09-01 15:33 ` [PATCH 2/4] dt-bindings: nvmem: layouts: Add Rockchip OTP CPUID layout Alexey Charkov
2026-09-01 15:33 ` Alexey Charkov
2026-09-01 15:33 ` [PATCH 3/4] nvmem: layouts: Add Rockchip OTP CPUID layout driver Alexey Charkov
2026-09-01 15:33 ` Alexey Charkov
2026-09-01 16:03 ` sashiko-bot
2026-09-02 9:40 ` Miquel Raynal [this message]
2026-09-02 9:40 ` Miquel Raynal
2026-09-01 15:33 ` [PATCH 4/4] arm64: dts: rockchip: Derive GMAC MAC addresses from OTP on RK3576 Alexey Charkov
2026-09-01 15:33 ` Alexey Charkov
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=878q5k7zyz.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=alchark@flipper.net \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=finley.xiao@rock-chips.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=michael@walle.cc \
--cc=robh@kernel.org \
--cc=srini@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 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.