linux-kernel - Re: [PATCH] arm64: dts: rockchip: Explicitly request UFS reset pin on RK3576

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6479d7b8-7712-4181-9c82-0021da94d1a8@rock-chips.com>
Date: Tue, 20 Jan 2026 09:39:28 +0800
From: Shawn Lin <shawn.lin@...k-chips.com>
To: Alexey Charkov <alchark@...il.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
 "Martin K. Petersen" <martin.petersen@...cle.com>,
 Manivannan Sadhasivam <mani@...nel.org>
Cc: shawn.lin@...k-chips.com, Quentin Schulz <quentin.schulz@...rry.de>,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
 stable@...r.kernel.org
Subject: Re: [PATCH] arm64: dts: rockchip: Explicitly request UFS reset pin on
 RK3576

在 2026/01/19 星期一 17:22, Alexey Charkov 写道:
> Rockchip RK3576 UFS controller uses a dedicated pin to reset the connected
> UFS device, which can operate either in a hardware controlled mode or as a
> GPIO pin.
> 

It's the only one 1.2V IO could be used on RK3576 to reset ufs devices,
except ufs refclk. So it's a dedicated pin for sure if using ufs, that's
why we put it into rk3576.dtsi.

> Power-on default is GPIO mode, but the boot ROM reconfigures it to a
> hardware controlled mode if it uses UFS to load the next boot stage.
> 

ROM code could be specific, but the linux/loader driver is compatible，
so for the coming SoCs, with more 1.2V IO could be used, it's more
flexible to use gpio-based instead of hardware controlled(of course,
move reset pinctrl settings into board dts).

> Given that existing bindings (and rk3576.dtsi) expect a GPIO-controlled
> device reset, request the required pin config explicitly.
> 
> This doesn't appear to affect Linux, but it does affect U-boot:
> 

IIUC, it's more or less a fix for loader, more precisely U-boot here?
I'm not entirely certain about the handling here, is it standard
convention to add a fixes tag in this context?


> Before:
> => md.l 0x2604b398
> 2604b398: 00000011 00000000 00000000 00000000  ................
> < ... snip ... >
> => ufs init
> ufshcd-rockchip ufshc@...d0000: [RX, TX]: gear=[3, 3], lane[2, 2], pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate = 2
> => md.l 0x2604b398
> 2604b398: 00000011 00000000 00000000 00000000  ................
> 
> After:
> => md.l 0x2604b398
> 2604b398: 00000011 00000000 00000000 00000000  ................
> < ... snip ...>
> => ufs init
> ufshcd-rockchip ufshc@...d0000: [RX, TX]: gear=[3, 3], lane[2, 2], pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate = 2
> => md.l 0x2604b398
> 2604b398: 00000010 00000000 00000000 00000000  ................
> 
> (0x2604b398 is the respective pin mux register, with its BIT0 driving the
> mode of UFS_RST: unset = GPIO, set = hardware controlled UFS_RST)
> 
> This helps ensure that GPIO-driven device reset actually fires when the
> system requests it, not when whatever black box magic inside the UFSHC
> decides to reset the flash chip.
> 
> Cc: stable@...r.kernel.org
> Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC")
> Reported-by: Quentin Schulz <quentin.schulz@...rry.de>
> Signed-off-by: Alexey Charkov <alchark@...il.com>
> ---
> This has originally surfaced during the review of UFS patches for U-boot
> at [1], where it was found that the UFS reset line is not requested to be
> configured as GPIO but used as such. This leads in some cases to the UFS
> driver appearing to control device resets, while in fact it is the
> internal controller logic that drives the reset line (perhaps in
> unexpected ways).
> 
> Thanks Quentin Schulz for spotting this issue.
> 
> [1] https://lore.kernel.org/u-boot/259fc358-f72b-4a24-9a71-ad90f2081335@cherry.de/
> ---
>   arch/arm64/boot/dts/rockchip/rk3576-pinctrl.dtsi | 7 +++++++
>   arch/arm64/boot/dts/rockchip/rk3576.dtsi         | 2 +-
>   2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-pinctrl.dtsi
> index 0b0851a7e4ea..20cfd3393a75 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-pinctrl.dtsi
> @@ -5228,6 +5228,13 @@ ufs_rst: ufs-rst {
>   				/* ufs_rstn */
>   				<4 RK_PD0 1 &pcfg_pull_none>;
>   		};
> +
> +		/omit-if-no-ref/
> +		ufs_rst_gpio: ufs-rst-gpio {
> +			rockchip,pins =
> +				/* ufs_rstn */
> +				<4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
>   	};
>   
>   	ufs_testdata0 {
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> index 3a29c627bf6d..db610f57c845 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> @@ -1865,7 +1865,7 @@ ufshc: ufshc@...d0000 {
>   			assigned-clock-parents = <&cru CLK_REF_MPHY_26M>;
>   			interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
>   			power-domains = <&power RK3576_PD_USB>;
> -			pinctrl-0 = <&ufs_refclk>;
> +			pinctrl-0 = <&ufs_refclk &ufs_rst_gpio>;
>   			pinctrl-names = "default";
>   			resets = <&cru SRST_A_UFS_BIU>, <&cru SRST_A_UFS_SYS>,
>   				 <&cru SRST_A_UFS>, <&cru SRST_P_UFS_GRF>;
> 
> ---
> base-commit: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b
> change-id: 20260119-ufs-rst-ffbc0ec88e07
> 
> Best regards,