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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABjd4YzJud4ZZQ_GrOOSnfEVG7wgHmPSf9w8oQhLVSx6WXgN5A@mail.gmail.com>
Date: Mon, 19 Jan 2026 17:43:09 +0400
From: Alexey Charkov <alchark@...il.com>
To: Quentin Schulz <quentin.schulz@...rry.de>
Cc: 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>, Shawn Lin <shawn.lin@...k-chips.com>, 
	Manivannan Sadhasivam <mani@...nel.org>, 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

Hi Quentin,

On Mon, Jan 19, 2026 at 3:08 PM Quentin Schulz <quentin.schulz@...rry.de> wrote:
>
> Hi Alexey,
>
> On 1/19/26 10:22 AM, Alexey Charkov wrote:
> > 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.
> >
> > 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.
> >
> > 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:
> >
> > 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>;
>
> The SoC default is pull-down according to the TRM. Can you check please?
> For example, the Rock 4D doesn't seem to have a hardware pull-up or
> pull-down on the line and the UFS module only seems to have a debouncer
> (capacitor between the line and ground). So except if the chip itself
> has a PU/PD, this may be an issue?

The SoC default is indeed pull-down (as stated both in the TRM and in
the reference schematic from RK3576 EVB1). Which I believe means that
the attached device should be held in a reset state until the driver
takes over the control of the GPIO line (which, in turn, is consistent
with the observed behavior when reset handling is not enabled in the
driver but the reset pin is in GPIO mode).

Are you concerned that the chip might unintentionally go in or out of
reset between the moment the pinctrl subsystem claims the pin and the
moment the driver starts outputting a state it desires? This hasn't
caused any observable issues in my testing, but I guess we could
explicitly set it to &pcfg_pull_down for more predictable behavior in
line with what's printed on the schematic.

Best regards,
Alexey