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] [day] [month] [year] [list]
Message-ID: <CABjd4YyPhHCL0TNzKG1_t4bTspfcC0bx41a8t=u+CJo6JvMC0g@mail.gmail.com>
Date: Wed, 21 Jan 2026 11:35:15 +0400
From: Alexey Charkov <alchark@...il.com>
To: Rob Herring <robh@...nel.org>
Cc: devicetree@...r.kernel.org, Shawn Lin <shawn.lin@...k-chips.com>, 
	Quentin Schulz <quentin.schulz@...rry.de>, Conor Dooley <conor+dt@...nel.org>, 
	linux-kernel@...r.kernel.org, 
	"Martin K. Petersen" <martin.petersen@...cle.com>, Heiko Stuebner <heiko@...ech.de>, stable@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Manivannan Sadhasivam <mani@...nel.org>, linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v2] arm64: dts: rockchip: Explicitly request UFS reset pin
 on RK3576

On Wed, Jan 21, 2026 at 1:45 AM Rob Herring <robh@...nel.org> wrote:
>
>
> On Tue, 20 Jan 2026 16:53:54 +0400, 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.
> >
> > Cc: stable@...r.kernel.org
> > Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC")
> > Reported-by: Quentin Schulz <quentin.schulz@...rry.de>
> > Signed-off-by: Alexey Charkov <alchark@...il.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/
> > ---
> > Changes in v2:
> > - Change default pin pull to pull-down in line with the SoC power-on default
> > - Link to v1: https://lore.kernel.org/r/20260119-ufs-rst-v1-1-c8e96493948c@gmail.com
> > ---
> >  arch/arm64/boot/dts/rockchip/rk3576-pinctrl.dtsi | 7 +++++++
> >  arch/arm64/boot/dts/rockchip/rk3576.dtsi         | 2 +-
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> >
>
>
> My bot found new DTB warnings on the .dts files added or changed in this
> series.
>
> Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
> are fixed by another series. Ultimately, it is up to the platform
> maintainer whether these warnings are acceptable or not. No need to reply
> unless the platform maintainer has comments.
>
> If you already ran DT checks and didn't see these error(s), then
> make sure dt-schema is up to date:
>
>   pip3 install dtschema --upgrade
>
>
> This patch series was applied (using b4) to base:
>  Base: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b (use --merge-base to override)
>
> If this is not the correct base, please add 'base-commit' tag
> (or use b4 which does this automatically)
>
>
> New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/rockchip/' for 20260120-ufs-rst-v2-1-b5735f1996f6@...il.com:
>
> arch/arm64/boot/dts/rockchip/rk3576-luckfox-omni3576.dtb: ufs: ufs-rst-gpio: {'rockchip,pins': [[4, 24, 0, 29]], 'phandle': 113} is not of type 'array'
>         from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml
> arch/arm64/boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dtb: ufs: ufs-rst-gpio: {'rockchip,pins': [[4, 24, 0, 29]], 'phandle': 130} is not of type 'array'
>         from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml
> arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dtb: ufs: ufs-rst-gpio: {'rockchip,pins': [[4, 24, 0, 29]], 'phandle': 116} is not of type 'array'
>         from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml
> arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dtb: ufs: ufs-rst-gpio: {'rockchip,pins': [[4, 24, 0, 29]], 'phandle': 117} is not of type 'array'
>         from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml
> arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dtb: ufs: ufs-rst-gpio: {'rockchip,pins': [[4, 24, 0, 29]], 'phandle': 133} is not of type 'array'
>         from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml
> arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dtb: ufs: ufs-rst-gpio: {'rockchip,pins': [[4, 24, 0, 29]], 'phandle': 122} is not of type 'array'
>         from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml
> arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dtb: ufs: ufs-rst-gpio: {'rockchip,pins': [[4, 24, 0, 29]], 'phandle': 134} is not of type 'array'
>         from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml
> arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dtb: ufs: ufs-rst-gpio: {'rockchip,pins': [[4, 24, 0, 29]], 'phandle': 130} is not of type 'array'
>         from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml
> arch/arm64/boot/dts/rockchip/rk3576-evb1-v10-pcie1.dtb: ufs: ufs-rst-gpio: {'rockchip,pins': [[4, 24, 0, 29]], 'phandle': 134} is not of type 'array'
>         from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml
> arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5-v1.2-wifibt.dtb: ufs: ufs-rst-gpio: {'rockchip,pins': [[4, 24, 0, 29]], 'phandle': 130} is not of type 'array'
>         from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml

Thank you bot. This wildcard for *-gpio is driving me crazy. And yes,
looks like I forgot to test against the schema - sorry for that. Will
resend a slightly adjusted version shortly
(s/ufs-rst-gpio/ufs-rstgpio/ to avoid incorrectly matching against the
GPIO schema)

Best regards,
Alexey