[PATCH] arm64: dts: rockchip: Explicitly request UFS reset pin on RK3576

[PATCH] arm64: dts: rockchip: Explicitly request UFS reset pin on RK3576

[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.

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@2a2d0000: [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@2a2d0000: [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@vger.kernel.org
Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC")
Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Alexey Charkov <alchark@gmail.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@2a2d0000 {
 			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,
-- 
Alexey Charkov <alchark@gmail.com>

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

[Quentin Schulz]

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@2a2d0000: [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@2a2d0000: [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@vger.kernel.org
> Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC")
> Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
> Signed-off-by: Alexey Charkov <alchark@gmail.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?

Cheers,
Quentin

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

[Alexey Charkov]

Hi Quentin,

On Mon, Jan 19, 2026 at 3:08 PM Quentin Schulz <quentin.schulz@cherry.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@2a2d0000: [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@2a2d0000: [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@vger.kernel.org
> > Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC")
> > Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
> > Signed-off-by: Alexey Charkov <alchark@gmail.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

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

[Quentin Schulz]

Hi Alexey,

On 1/19/26 2:43 PM, Alexey Charkov wrote:
> Hi Quentin,
> 
> On Mon, Jan 19, 2026 at 3:08 PM Quentin Schulz <quentin.schulz@cherry.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@2a2d0000: [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@2a2d0000: [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@vger.kernel.org
>>> Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC")
>>> Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
>>> Signed-off-by: Alexey Charkov <alchark@gmail.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

Exactly that.

Imagine for some reason the driver EPROBE_DEFER, there can be a lot of 
time between the original pinconf/pinmux and the time the GPIO is 
actually driven.

At the same time.. I guess it may not matter much if the UFS chip gets 
out of reset temporarily as (I assume) when the UFS controller probes 
properly, it'll do a full reset of the UFS chip via the reset GPIO. 
Don't know anything about UFS, so maybe there could be damage if the UFS 
chip gets out of reset if its supplies or IO lines are in an illegal state?

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

s/schematics/TRM/

I'll let Heiko decide but I would personally go for a PD to match the 
default state of the SoC according to the TRM.

Cheers,
Quentin

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

[Alexey Charkov]

On Mon, Jan 19, 2026 at 5:58 PM Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Alexey,
>
> On 1/19/26 2:43 PM, Alexey Charkov wrote:
> > Hi Quentin,
> >
> > On Mon, Jan 19, 2026 at 3:08 PM Quentin Schulz <quentin.schulz@cherry.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@2a2d0000: [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@2a2d0000: [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@vger.kernel.org
> >>> Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC")
> >>> Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
> >>> Signed-off-by: Alexey Charkov <alchark@gmail.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
>
> Exactly that.
>
> Imagine for some reason the driver EPROBE_DEFER, there can be a lot of
> time between the original pinconf/pinmux and the time the GPIO is
> actually driven.
>
> At the same time.. I guess it may not matter much if the UFS chip gets
> out of reset temporarily as (I assume) when the UFS controller probes
> properly, it'll do a full reset of the UFS chip via the reset GPIO.
> Don't know anything about UFS, so maybe there could be damage if the UFS
> chip gets out of reset if its supplies or IO lines are in an illegal state?
>
> > 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.
> >
>
> s/schematics/TRM/
>
> I'll let Heiko decide but I would personally go for a PD to match the
> default state of the SoC according to the TRM.

Happy to make a v2 with an explicit pull-down. Will wait a bit for any
other potential feedback though.

Thanks a lot,
Alexey

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

[Heiko Stübner]

Am Montag, 19. Januar 2026, 15:05:16 Mitteleuropäische Normalzeit schrieb Alexey Charkov:
> On Mon, Jan 19, 2026 at 5:58 PM Quentin Schulz <quentin.schulz@cherry.de> wrote:
> >
> > Hi Alexey,
> >
> > On 1/19/26 2:43 PM, Alexey Charkov wrote:
> > > Hi Quentin,
> > >
> > > On Mon, Jan 19, 2026 at 3:08 PM Quentin Schulz <quentin.schulz@cherry.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@2a2d0000: [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@2a2d0000: [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@vger.kernel.org
> > >>> Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC")
> > >>> Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
> > >>> Signed-off-by: Alexey Charkov <alchark@gmail.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
> >
> > Exactly that.
> >
> > Imagine for some reason the driver EPROBE_DEFER, there can be a lot of
> > time between the original pinconf/pinmux and the time the GPIO is
> > actually driven.
> >
> > At the same time.. I guess it may not matter much if the UFS chip gets
> > out of reset temporarily as (I assume) when the UFS controller probes
> > properly, it'll do a full reset of the UFS chip via the reset GPIO.
> > Don't know anything about UFS, so maybe there could be damage if the UFS
> > chip gets out of reset if its supplies or IO lines are in an illegal state?
> >
> > > 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.
> > >
> >
> > s/schematics/TRM/
> >
> > I'll let Heiko decide but I would personally go for a PD to match the
> > default state of the SoC according to the TRM.
> 
> Happy to make a v2 with an explicit pull-down. Will wait a bit for any
> other potential feedback though.

I'd side with Quentin here, having the pin firmly on one state, when no-one
(board nor driver) is caring would be my preference.
Especially as Quentin said, this is the hardware-default too.

Heiko

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

[Shawn Lin]

在 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@2a2d0000: [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@2a2d0000: [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@vger.kernel.org
> Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC")
> Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
> Signed-off-by: Alexey Charkov <alchark@gmail.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@2a2d0000 {
>   			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,

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

[Alexey Charkov]

On Tue, Jan 20, 2026 at 5:39 AM Shawn Lin <shawn.lin@rock-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

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

[Heiko Stuebner]

Am Dienstag, 20. Januar 2026, 02:39:28 Mitteleuropäische Normalzeit schrieb Shawn Lin:
> 在 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?

Yes, a fixes tag is warranted here, in Linux it "only" fixes a potential
issue due to the mismatch between pinconfig and gpio during probe.

nce this patch then enters the kernel, it can be cherry-picked to
the current u-boot development cycle. I don't think u-boot is doing
stable releases though, so U-Boot will only profit for the next
version where this is included.

Heiko

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

[Heiko Stuebner]

Am Montag, 19. Januar 2026, 15:42:23 Mitteleuropäische Normalzeit schrieb Heiko Stübner:
> Am Montag, 19. Januar 2026, 15:05:16 Mitteleuropäische Normalzeit schrieb Alexey Charkov:
> > Happy to make a v2 with an explicit pull-down. Will wait a bit for any
> > other potential feedback though.
> 
> I'd side with Quentin here, having the pin firmly on one state, when no-one
> (board nor driver) is caring would be my preference.
> Especially as Quentin said, this is the hardware-default too.

Also it would be good to send that v2 sooner rather than later, as we're
pretty late in the current development cycle already.
(We're after -rc6 already)


Thanks
Heiko

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

[Quentin Schulz]

Hi Heiko,

On 1/20/26 9:55 AM, Heiko Stuebner wrote:
> Am Dienstag, 20. Januar 2026, 02:39:28 Mitteleuropäische Normalzeit schrieb Shawn Lin:
>> 在 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?
> 
> Yes, a fixes tag is warranted here, in Linux it "only" fixes a potential
> issue due to the mismatch between pinconfig and gpio during probe.
> 
> nce this patch then enters the kernel, it can be cherry-picked to
> the current u-boot development cycle. I don't think u-boot is doing
> stable releases though, so U-Boot will only profit for the next
> version where this is included.
> 

U-Boot only takes what's in devicetree-rebasing 
(https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git), 
so only from Linus's tree AFAICT. C.f. 
https://docs.u-boot.org/en/latest/develop/process.html#resyncing-of-the-device-tree-subtree 
and 
https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing. 
See also OF_UPSTREAM Kconfig symbol in U-Boot.

This policy does make adding support for a new board quite slow as we 
may need to wait months before it makes it to Linus's tree, and then go 
through the development cycle in U-Boot which can also take a few months 
if the timing is unfortunate. For now it seems like we're sticking with 
this policy to avoid too much in "downstream" DT in U-Boot. I know we 
push for this aggressively for new Rockchip boards and SoCs, cannot say 
for other vendors.

Cheers,
Quentin

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

[Heiko Stuebner]

Am Dienstag, 20. Januar 2026, 11:21:34 Mitteleuropäische Normalzeit schrieb Quentin Schulz:
> Hi Heiko,
> 
> On 1/20/26 9:55 AM, Heiko Stuebner wrote:
> > Am Dienstag, 20. Januar 2026, 02:39:28 Mitteleuropäische Normalzeit schrieb Shawn Lin:
> >> 在 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?
> > 
> > Yes, a fixes tag is warranted here, in Linux it "only" fixes a potential
> > issue due to the mismatch between pinconfig and gpio during probe.
> > 
> > nce this patch then enters the kernel, it can be cherry-picked to
> > the current u-boot development cycle. I don't think u-boot is doing
> > stable releases though, so U-Boot will only profit for the next
> > version where this is included.
> > 
> 
> U-Boot only takes what's in devicetree-rebasing 
> (https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git), 
> so only from Linus's tree AFAICT. C.f. 
> https://docs.u-boot.org/en/latest/develop/process.html#resyncing-of-the-device-tree-subtree 
> and 
> https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing. 
> See also OF_UPSTREAM Kconfig symbol in U-Boot.
> 
> This policy does make adding support for a new board quite slow as we 
> may need to wait months before it makes it to Linus's tree, and then go 
> through the development cycle in U-Boot which can also take a few months 
> if the timing is unfortunate. For now it seems like we're sticking with 
> this policy to avoid too much in "downstream" DT in U-Boot. I know we 
> push for this aggressively for new Rockchip boards and SoCs, cannot say 
> for other vendors.

Yeah, this is what I "meant", but explained badly :-)

Also this is the reason I'd like that v2 soon'ish, that it can make its
way still into 6.20-rc1 and thus into u-boot.