.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 + .../nvmem/layouts/rockchip,rk3576-otp-cpuid.yaml | 73 +++++++++++++ MAINTAINERS | 7 ++ arch/arm64/boot/dts/rockchip/rk3576.dtsi | 12 +++ drivers/nvmem/layouts/Kconfig | 13 +++ drivers/nvmem/layouts/Makefile | 1 + drivers/nvmem/layouts/rockchip-otp-cpuid.c | 119 +++++++++++++++++++++ drivers/nvmem/rockchip-otp.c | 15 ++- 8 files changed, 240 insertions(+), 1 deletion(-)
Rockchip SoCs are shipped with a unique CPU ID in their internal OTP
memory, and Rockchip bootloaders use it to give boards which have no
dedicated storage for a MAC address a stable one anyway: they hash the CPU
ID and patch the resulting addresses into the device tree they hand over.
Kernels started without that fixup, e.g. straight from the SPL in Falcon
mode or by any other loader which does not implement Rockchip's derivation,
fall back to random MAC addresses which change on every boot.
Formalize the derivation in the DT binding and add a Linux kernel driver
implementing it, so that a Linux image can use the same stable addresses
regardless of the boot flow.
Only RK3576 is wired up here, that being the SoC I can test on. Other
Rockchip SoCs keep the same CPU ID at a different OTP offset - 0x7 rather
than 0xa on RK3588, for instance - which makes supporting them a two-line
addition to the driver's match table plus the layout node.
Patch 1 is a prerequisite fix. The OTP hardware has its own internal state
machine which only works correctly with serial access, but the current
driver serializes nothing, which results in timeouts and/or corrupted
reads (e.g. returning splicing a TSADC trim value into the buffer of a
caller asking for the CPU ID, or mixing up trim values of different TSADC
callers). Hence the Fixes: tag and Cc: stable.
Cross-checked on an RK3576 board: the addresses fixed up into the FDT by
U-Boot match the ones derived by the new driver, and the driver correctly
assigns them to the network interfaces when the kernel is booted without
U-Boot proper at all (via Falcon mode).
Sashiko also rightly pointed out a use-after-free in the nvmem core when
a layout driver is unloaded leaving its sysfs nodes and the postprocessor
function pointer dangling. This is fixed separately in [1].
[1] https://lore.kernel.org/all/20260902-nvmem-layout-unreg-v1-1-2d16bebeb518@flipper.net/
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
Changes in v2:
- Switched from a scope-based guard to explicit lock/unlock calls in the
OTP driver to avoid mixing styles in a function using goto error
handling (Sashiko)
- Link to v1: https://patch.msgid.link/20260901-rk3576-otp-cpuid-mac-v1-0-ea9135270fc2@flipper.net
---
Alexey Charkov (4):
nvmem: rockchip-otp: Serialize reads
dt-bindings: nvmem: layouts: Add Rockchip OTP CPUID layout
nvmem: layouts: Add Rockchip OTP CPUID layout driver
arm64: dts: rockchip: Derive GMAC MAC addresses from OTP on RK3576
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
.../nvmem/layouts/rockchip,rk3576-otp-cpuid.yaml | 73 +++++++++++++
MAINTAINERS | 7 ++
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 12 +++
drivers/nvmem/layouts/Kconfig | 13 +++
drivers/nvmem/layouts/Makefile | 1 +
drivers/nvmem/layouts/rockchip-otp-cpuid.c | 119 +++++++++++++++++++++
drivers/nvmem/rockchip-otp.c | 15 ++-
8 files changed, 240 insertions(+), 1 deletion(-)
---
base-commit: 8b72f6626dc39b9e7e82b2721d4f7c3b86286012
change-id: 20260901-rk3576-otp-cpuid-mac-3c90243d0884
Best regards,
--
Alexey Charkov <alchark@flipper.net>
On Wed, Sep 2, 2026 at 5:08 PM Alexey Charkov <alchark@flipper.net> wrote: > > Rockchip SoCs are shipped with a unique CPU ID in their internal OTP > memory, and Rockchip bootloaders use it to give boards which have no > dedicated storage for a MAC address a stable one anyway: they hash the CPU > ID and patch the resulting addresses into the device tree they hand over. > > Kernels started without that fixup, e.g. straight from the SPL in Falcon > mode or by any other loader which does not implement Rockchip's derivation, > fall back to random MAC addresses which change on every boot. > > Formalize the derivation in the DT binding and add a Linux kernel driver > implementing it, so that a Linux image can use the same stable addresses > regardless of the boot flow. > > Only RK3576 is wired up here, that being the SoC I can test on. Other > Rockchip SoCs keep the same CPU ID at a different OTP offset - 0x7 rather > than 0xa on RK3588, for instance - which makes supporting them a two-line > addition to the driver's match table plus the layout node. > > Patch 1 is a prerequisite fix. The OTP hardware has its own internal state > machine which only works correctly with serial access, but the current > driver serializes nothing, which results in timeouts and/or corrupted > reads (e.g. returning splicing a TSADC trim value into the buffer of a > caller asking for the CPU ID, or mixing up trim values of different TSADC > callers). Hence the Fixes: tag and Cc: stable. > > Cross-checked on an RK3576 board: the addresses fixed up into the FDT by > U-Boot match the ones derived by the new driver, and the driver correctly > assigns them to the network interfaces when the kernel is booted without > U-Boot proper at all (via Falcon mode). > > Sashiko also rightly pointed out a use-after-free in the nvmem core when > a layout driver is unloaded leaving its sysfs nodes and the postprocessor > function pointer dangling. This is fixed separately in [1]. > > [1] https://lore.kernel.org/all/20260902-nvmem-layout-unreg-v1-1-2d16bebeb518@flipper.net/ > > Signed-off-by: Alexey Charkov <alchark@flipper.net> > --- > Changes in v2: > - Switched from a scope-based guard to explicit lock/unlock calls in the > OTP driver to avoid mixing styles in a function using goto error > handling (Sashiko) > - Link to v1: https://patch.msgid.link/20260901-rk3576-otp-cpuid-mac-v1-0-ea9135270fc2@flipper.net > > --- > Alexey Charkov (4): > nvmem: rockchip-otp: Serialize reads Incidentally, patch 1 of this series also fixes CPU thermal throttling on my RK3576 device: apparently, the mis-read OTP-programmed thermal trim values broke the thermal governor logic, which now works correctly with properly serialized OTP reads. So it would be great to have these merged. Best regards, Alexey
On Thu, Sep 10, 2026 at 06:48:33PM +0400, Alexey Charkov wrote: > On Wed, Sep 2, 2026 at 5:08 PM Alexey Charkov <alchark@flipper.net> wrote: > > > > Rockchip SoCs are shipped with a unique CPU ID in their internal OTP > > memory, and Rockchip bootloaders use it to give boards which have no > > dedicated storage for a MAC address a stable one anyway: they hash the CPU > > ID and patch the resulting addresses into the device tree they hand over. > > > > Kernels started without that fixup, e.g. straight from the SPL in Falcon > > mode or by any other loader which does not implement Rockchip's derivation, > > fall back to random MAC addresses which change on every boot. > > > > Formalize the derivation in the DT binding and add a Linux kernel driver > > implementing it, so that a Linux image can use the same stable addresses > > regardless of the boot flow. > > > > Only RK3576 is wired up here, that being the SoC I can test on. Other > > Rockchip SoCs keep the same CPU ID at a different OTP offset - 0x7 rather > > than 0xa on RK3588, for instance - which makes supporting them a two-line > > addition to the driver's match table plus the layout node. > > > > Patch 1 is a prerequisite fix. The OTP hardware has its own internal state > > machine which only works correctly with serial access, but the current > > driver serializes nothing, which results in timeouts and/or corrupted > > reads (e.g. returning splicing a TSADC trim value into the buffer of a > > caller asking for the CPU ID, or mixing up trim values of different TSADC > > callers). Hence the Fixes: tag and Cc: stable. > > > > Cross-checked on an RK3576 board: the addresses fixed up into the FDT by > > U-Boot match the ones derived by the new driver, and the driver correctly > > assigns them to the network interfaces when the kernel is booted without > > U-Boot proper at all (via Falcon mode). > > > > Sashiko also rightly pointed out a use-after-free in the nvmem core when > > a layout driver is unloaded leaving its sysfs nodes and the postprocessor > > function pointer dangling. This is fixed separately in [1]. > > > > [1] https://lore.kernel.org/all/20260902-nvmem-layout-unreg-v1-1-2d16bebeb518@flipper.net/ > > > > Signed-off-by: Alexey Charkov <alchark@flipper.net> > > --- > > Changes in v2: > > - Switched from a scope-based guard to explicit lock/unlock calls in the > > OTP driver to avoid mixing styles in a function using goto error > > handling (Sashiko) > > - Link to v1: https://patch.msgid.link/20260901-rk3576-otp-cpuid-mac-v1-0-ea9135270fc2@flipper.net > > > > --- > > Alexey Charkov (4): > > nvmem: rockchip-otp: Serialize reads > > Incidentally, patch 1 of this series also fixes CPU thermal throttling > on my RK3576 device: apparently, the mis-read OTP-programmed thermal > trim values broke the thermal governor logic, which now works > correctly with properly serialized OTP reads. So it would be great to > have these merged. It would be great to have the sashiko comments analyzed and replied to as well if you would like this to be reviewed. Rob
Hi Rob, On Fri, Sep 18, 2026 at 2:19 AM Rob Herring <robh@kernel.org> wrote: > > On Thu, Sep 10, 2026 at 06:48:33PM +0400, Alexey Charkov wrote: > > On Wed, Sep 2, 2026 at 5:08 PM Alexey Charkov <alchark@flipper.net> wrote: > > > > > > Rockchip SoCs are shipped with a unique CPU ID in their internal OTP > > > memory, and Rockchip bootloaders use it to give boards which have no > > > dedicated storage for a MAC address a stable one anyway: they hash the CPU > > > ID and patch the resulting addresses into the device tree they hand over. > > > > > > Kernels started without that fixup, e.g. straight from the SPL in Falcon > > > mode or by any other loader which does not implement Rockchip's derivation, > > > fall back to random MAC addresses which change on every boot. > > > > > > Formalize the derivation in the DT binding and add a Linux kernel driver > > > implementing it, so that a Linux image can use the same stable addresses > > > regardless of the boot flow. > > > > > > Only RK3576 is wired up here, that being the SoC I can test on. Other > > > Rockchip SoCs keep the same CPU ID at a different OTP offset - 0x7 rather > > > than 0xa on RK3588, for instance - which makes supporting them a two-line > > > addition to the driver's match table plus the layout node. > > > > > > Patch 1 is a prerequisite fix. The OTP hardware has its own internal state > > > machine which only works correctly with serial access, but the current > > > driver serializes nothing, which results in timeouts and/or corrupted > > > reads (e.g. returning splicing a TSADC trim value into the buffer of a > > > caller asking for the CPU ID, or mixing up trim values of different TSADC > > > callers). Hence the Fixes: tag and Cc: stable. > > > > > > Cross-checked on an RK3576 board: the addresses fixed up into the FDT by > > > U-Boot match the ones derived by the new driver, and the driver correctly > > > assigns them to the network interfaces when the kernel is booted without > > > U-Boot proper at all (via Falcon mode). > > > > > > Sashiko also rightly pointed out a use-after-free in the nvmem core when > > > a layout driver is unloaded leaving its sysfs nodes and the postprocessor > > > function pointer dangling. This is fixed separately in [1]. > > > > > > [1] https://lore.kernel.org/all/20260902-nvmem-layout-unreg-v1-1-2d16bebeb518@flipper.net/ > > > > > > Signed-off-by: Alexey Charkov <alchark@flipper.net> > > > --- > > > Changes in v2: > > > - Switched from a scope-based guard to explicit lock/unlock calls in the > > > OTP driver to avoid mixing styles in a function using goto error > > > handling (Sashiko) > > > - Link to v1: https://patch.msgid.link/20260901-rk3576-otp-cpuid-mac-v1-0-ea9135270fc2@flipper.net > > > > > > --- > > > Alexey Charkov (4): > > > nvmem: rockchip-otp: Serialize reads > > > > Incidentally, patch 1 of this series also fixes CPU thermal throttling > > on my RK3576 device: apparently, the mis-read OTP-programmed thermal > > trim values broke the thermal governor logic, which now works > > correctly with properly serialized OTP reads. So it would be great to > > have these merged. > > It would be great to have the sashiko comments analyzed and replied to > as well if you would like this to be reviewed. Of course. One code-related comment Sashiko raised has been addressed in a separate patch [1] which is still pending review. The binding-related comments will need to be revisited, as I'd like to first explore the idea Ryan proposed in the adjacent thread [2], as it will change the approach somewhat if it works out. Best regards, Alexey [1] https://lore.kernel.org/all/20260902-nvmem-layout-unreg-v1-1-2d16bebeb518@flipper.net/ [2] https://lore.kernel.org/all/20260916123355.4507-1-untilscour@protonmail.com/
On 02/09/2026 15:07, Alexey Charkov wrote: > Rockchip SoCs are shipped with a unique CPU ID in their internal OTP > memory, and Rockchip bootloaders use it to give boards which have no > dedicated storage for a MAC address a stable one anyway: they hash the CPU > ID and patch the resulting addresses into the device tree they hand over. > > Kernels started without that fixup, e.g. straight from the SPL in Falcon > mode or by any other loader which does not implement Rockchip's derivation, > fall back to random MAC addresses which change on every boot. > > Formalize the derivation in the DT binding and add a Linux kernel driver > implementing it, so that a Linux image can use the same stable addresses > regardless of the boot flow. > > Only RK3576 is wired up here, that being the SoC I can test on. Other > Rockchip SoCs keep the same CPU ID at a different OTP offset - 0x7 rather > than 0xa on RK3588, for instance - which makes supporting them a two-line > addition to the driver's match table plus the layout node. Hi Alexey, I went off trying this on RK3588 and - exactly like you said - it translates perfectly there, just with a different offset. Thanks! Not content, I went for RK356x as well - and that revealed what I think is a snag. Both RK3576 and RK3588 currently describe their fixed cells as direct children of the OTP node -- turns out that is the "legacy" way, which works due to 'add_legacy_fixed_of_cells'. But RK356x/3528/3562, done more recently [1], use a single 'fixed-layout' with child cells; and there can only ever be one layout, so we wouldn't be able to use the new layout for those. I imagine one way around it would be to allow such fixed cells also under the new layout, by delegating to 'nvmem_add_cells_from_dt()' and adding patternProperties with '$ref: fixed-cell.yaml' in the binding, similar to what fixed-layout.yaml does, but I'm unsure that would be a good idea? Either way, thanks for this, it really helps with Falcon mode and edk2; I can also use it for the fixed-function RTL8125 PCIe NICs I started describing [2] (and will eventually send a v5). [1] https://lore.kernel.org/all/20260312213019.13965-3-heiko@sntech.de/ [2] https://lore.kernel.org/linux-rockchip/20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-0-2bd38922d129@pardini.net/ mvg, Ricardo
On Wed, 02 Sep 2026 17:07:51 +0400, Alexey Charkov wrote:
> Rockchip SoCs are shipped with a unique CPU ID in their internal OTP
> memory, and Rockchip bootloaders use it to give boards which have no
> dedicated storage for a MAC address a stable one anyway: they hash the CPU
> ID and patch the resulting addresses into the device tree they hand over.
>
> Kernels started without that fixup, e.g. straight from the SPL in Falcon
> mode or by any other loader which does not implement Rockchip's derivation,
> fall back to random MAC addresses which change on every boot.
>
> [...]
Applied, thanks!
[1/4] nvmem: rockchip-otp: Serialize reads
commit: 798be42019957b28b4fb897d7f9f6cf6712247db
Best regards,
--
Srinivas Kandagatla <srini@kernel.org>
© 2016 - 2026 Red Hat, Inc.