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

[Rob Herring]

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@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.

It would be great to have the sashiko comments analyzed and replied to 
as well if you would like this to be reviewed.

Rob