linux-kernel - Re: [PATCH 1/2] arm64: dts: rockchip: enable NPU on rk3588-tiger

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] [day] [month] [year] [list]

Message-ID: <d784230e-49f4-49e9-be4a-bc7c00020cfb@cherry.de>
Date: Fri, 22 Aug 2025 17:16:37 +0200
From: Quentin Schulz <quentin.schulz@...rry.de>
To: Heiko Stuebner <heiko@...ech.de>
Cc: linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org, Heiko Stuebner <heiko.stuebner@...rry.de>
Subject: Re: [PATCH 1/2] arm64: dts: rockchip: enable NPU on rk3588-tiger

Hi Heiko,

On 8/12/25 10:52 AM, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner@...rry.de>
> 
> Enable the NPU cores and their mmus and wire up the supply-regulator.
> The regulator itself was already defined, but it does not need to be
> always on - the npu can control it.
> 
> Signed-off-by: Heiko Stuebner <heiko.stuebner@...rry.de>
> ---
>   .../arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 35 ++++++++++++++++++-
>   1 file changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
> index f4bebd25e938..9859f31d2894 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
> @@ -194,7 +194,6 @@ vdd_npu_s0: regulator@42 {
>   		reg = <0x42>;
>   		fcs,suspend-voltage-selector = <1>;
>   		regulator-name = "vdd_npu_s0";
> -		regulator-always-on;
>   		regulator-boot-on;

I'm not sure we need this property?

The binding states:

"""
       This property is intended to only be used for regulators where
       software cannot read the state of the regulator.
"""

but the rk860 we use here can report its state if I read the driver 
properly.

If that is correct the same "mistake" was done for other RK3588 boards 
which enabled the NPU recently.

The diff makes sense compared to other RK3588 boards' recent NPU support 
addition so I guess this is fine :)

I am currently unable to test this though but considering that this is 
an IP within the SoC which only differs between different boards by its 
regulator feeding the controller(s) and that this change looks in sync 
with our hardware design, I guess we don't need to wait for me to be 
able to test this :)

Same remarks for the next patch in the series.

Cheers,
Quentin