linux-kernel - Re: [PATCH 1/3] arm64: dts: rockchip: Enable OTP controller for RK3562

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e58ebe6e-1de7-4b72-bf5e-e93cc19e69fd@kwiboo.se>
Date: Mon, 9 Feb 2026 17:54:51 +0100
From: Jonas Karlman <jonas@...boo.se>
To: Heiko Stuebner <heiko@...ech.de>
Cc: "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "linux-rockchip@...ts.infradead.org" <linux-rockchip@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "kever.yang@...k-chips.com" <kever.yang@...k-chips.com>,
 "finley.xiao@...k-chips.com" <finley.xiao@...k-chips.com>,
 "w@....eu" <w@....eu>
Subject: Re: [PATCH 1/3] arm64: dts: rockchip: Enable OTP controller for
 RK3562

Hi Heiko,

Thanks for including my RK3528 patches :-)

On 2/5/2026 10:23 PM, Heiko Stuebner wrote:
> Enable the One Time Programmable Controller (OTPC) in RK3562 and add
> an initial nvmem fixed layout.
> 
> Signed-off-by: Heiko Stuebner <heiko@...ech.de>
> ---
>  arch/arm64/boot/dts/rockchip/rk3562.dtsi | 46 ++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3562.dtsi b/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> index f84676b47b27..07626dba21bf 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> @@ -1093,6 +1093,52 @@ sdmmc1: mmc@...90000 {
>  			status = "disabled";
>  		};
>  
> +		otp: otp@...30000 {

I noticed that the node names is not consistent for all three patches in
this series.

A quick grep at Linux src also suggest that efuse@ being the most common
node name used for similar otpc/efuse, efuse is also listed under
2.2.2 Generic Names Recommendation in DT spec.

Maybe the nodes should be renamed to use efuse@ or something else?

I am mostly concerned on what the name ends up as and how that may
affect U-Boot in a future dts/upstream sync. U-Boot currently have
limited otp nodes in soc u-boot.dtsi files for these SoCs.

Regards,
Jonas

> +			compatible = "rockchip,rk3562-otp";
> +			reg = <0x0 0xff930000 0x0 0x4000>;
> +			clocks = <&cru CLK_USER_OTPC_NS>, <&cru PCLK_OTPC_NS>,
> +				 <&cru PCLK_OTPPHY>, <&cru CLK_SBPI_OTPC_NS>;
> +			clock-names = "otp", "apb_pclk", "phy", "sbpi";
> +			resets = <&cru SRST_USER_OTPC_NS>, <&cru SRST_P_OTPC_NS>,
> +				 <&cru SRST_P_OTPPHY>, <&cru SRST_SBPI_OTPC_NS>;
> +			reset-names = "otp", "apb", "phy", "sbpi";
> +
> +			nvmem-layout {
> +				compatible = "fixed-layout";
> +				#address-cells = <1>;
> +				#size-cells = <1>;
> +
> +				cpu_code: cpu-code@2 {
> +					reg = <0x02 0x2>;
> +				};
> +
> +				otp_cpu_version: cpu-version@8 {
> +					reg = <0x08 0x1>;
> +					bits = <3 3>;
> +				};
> +
> +				otp_id: id@a {
> +					reg = <0x0a 0x10>;
> +				};
> +
> +				cpu_leakage: cpu-leakage@1a {
> +					reg = <0x1a 0x1>;
> +				};
> +
> +				log_leakage: log-leakage@1b {
> +					reg = <0x1b 0x1>;
> +				};
> +
> +				npu_leakage: npu-leakage@1c {
> +					reg = <0x1c 0x1>;
> +				};
> +
> +				gpu_leakage: gpu-leakage@1d {
> +					reg = <0x1d 0x1>;
> +				};
> +			};
> +		};
> +
>  		dmac: dma-controller@...90000 {
>  			compatible = "arm,pl330", "arm,primecell";
>  			reg = <0x0 0xff990000 0x0 0x4000>;