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

["Heiko Stübner" <heiko@sntech.de>]

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