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

[Alexey Charkov]

Hi Rob,

On Fri, Sep 18, 2026 at 2:19 AM Rob Herring <robh@xxxxxxxxxx> 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@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.

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@xxxxxxxxxxx/
[2] https://lore.kernel.org/all/20260916123355.4507-1-untilscour@xxxxxxxxxxxxxx/