linux-kernel - Re: [PATCH v2] 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: <4830042.taCxCBeP46@diego>
Date: Tue, 20 Jan 2026 15:41:06 +0100
From: Heiko Stübner <heiko@...ech.de>
To: Quentin Schulz <quentin.schulz@...rry.de>,
 Alexey Charkov <alchark@...il.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 "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 v2] arm64: dts: rockchip: Explicitly request UFS reset pin on
 RK3576

Am Dienstag, 20. Januar 2026, 14:14:48 Mitteleuropäische Normalzeit schrieb Alexey Charkov:
> On Tue, Jan 20, 2026 at 5:00 PM Quentin Schulz <quentin.schulz@...rry.de> wrote:
> >
> > Hi Alexey,
> >
> > On 1/20/26 1:53 PM, 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.
> > >
> >
> > Would have liked a mention on why pull-down in the commit log.
> 
> Indeed. Heiko, if you're going to apply this to your tree, would you
> mind amending the commit description with something like the
> following?
> 
> The pin is requested with pull-down enabled, which is in line with the
> SoC power-on default and helps ensure that the attached UFS chip stays
> in reset until the driver takes over the control of the respective
> GPIO line.

Will do :-)

Heiko


> > In any case,
> >
> > Reviewed-by: Quentin Schulz <quentin.schulz@...rry.de>
> 
> Thanks a lot!
> 
> Best regards,
> Alexey
>