Re: [PATCH v2 0/4] nvmem: Derive Rockchip MAC addresses from the OTP CPU ID

[Alexey Charkov]

On Wed, Sep 2, 2026 at 5:08 PM Alexey Charkov <alchark@xxxxxxxxxxx> 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@xxxxxxxxxxx/
>
> Signed-off-by: Alexey Charkov <alchark@xxxxxxxxxxx>
> ---
> 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@xxxxxxxxxxx
>
> ---
> 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