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

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

[Ryan Leung]

Hi Ricardo, Alexey,

> 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

What about changing the driver to handle something like:

	otp: otp@... {
		compatible = "rockchip,rk3528-otp";

		#address-cells = <1>;
		#size-cells = <1>;

		nvmem-layout {
			compatible = "fixed-layout";

			#address-cells = <1>;
			#size-cells = <1>;

			otp_id: id@a {
				reg = <0x0a 0x10>;
			};
		};
	};

	otp_mac: otp-mac {
		compatible = "rockchip,otp-cpuid-mac";

		nvmem-cells = <&otp_id>;
		nvmem-cell-names = "source";

		#address-cells = <1>;
		#size-cells = <1>;

		otp_mac_address: mac-address@0 {
			reg = <0 0x10>;
			#nvmem-cell-cells = <1>;
		};
	};

using devm_nvmem_cell_get("source") to read the otp cell.

Then a match table would not be necessary and it would work with every
SoC, even those without the fixed-layout nvmem, because of
add_legacy_fixed_of_cells as you mentioned.

Best regards,
Ryan