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: <CABjd4Yx_2NPkY7U6U8XL_89uK20j7S3e4px1Cbp+JbF3FavjyQ@mail.gmail.com>
Date: Tue, 20 Jan 2026 11:13:34 +0400
From: Alexey Charkov <alchark@...il.com>
To: Shawn Lin <shawn.lin@...k-chips.com>
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>, Manivannan Sadhasivam <mani@...nel.org>, 
	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

On Tue, Jan 20, 2026 at 5:39 AM Shawn Lin <shawn.lin@...k-chips.com> wrote:
>
> 在 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).

Thanks Shawn, both of the above is very helpful context - I think I'll
mention it in my next version of the U-boot patch series where this
discussion first surfaced.

> > 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?

Device trees are treated somewhat independently of Linux driver code,
even though they follow the same development cycle. I believe that
broader policy is that both bindings and device tree sources should
equally cater to different codebases that use them, so a potential
issue outside the Linux kernel warrants a fix. Perhaps Rob, Krzysztof
and Conor are best positioned to confirm this or not.

In this particular case, the fact that the GPIO descriptor is defined
in rk3576.dtsi, but the respective pin configuration is not, leaves
ambiguity in the hardware description, which different codebases might
resolve differently (and not necessarily correctly for the hardware).
So there is a benefit in backporting the change which explicitly
resolves the ambiguity.

Best regards,
Alexey