On Tue, Jan 20, 2026 at 5:39 AM Shawn Lin [off-list ref] wrote:

在 2026/01/19 星期一 17:22, Alexey Charkov 写道:

quoted

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.

quoted

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.

quoted

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