From nobody Sun Feb 8 10:22:03 2026 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 96FF986323 for ; Wed, 21 Jan 2026 07:42:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768981342; cv=none; b=DFFdHgBeOyn48LJ5/h5hUwiunhXm/z3B53vYXsJIB/DQ1G9hRc+PgqdGcNjRmJyY6OHZpy2kJNBIj5hMhWkgjs94EHQvowgPtVkfojXV3wwgCndnrDQX6hf3qeQqBgqoB/f67O4J2e1Pb4/YihkkCGJop18RgCgSLfjP89CwY04= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768981342; c=relaxed/simple; bh=H/Le12Y1Ya9Ys/AHE2MLwlPKgu80NfZB2AyT4Dbqvfw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=Vh0kiks1oaPXX6aRoVv/SnYQifEnXvAOyqPWuiBeUN7WjqM/RerMeGp5CIZCb6W4vOeIkAKYc+epuoSv486is9tfXIVDXMlO3YRfiK/s1wQgEaXDD8TWAPEHowj6Pf2E40WVfhIEAoM5sUfsufkQZf/tcDRkBdqnC5FTxhw6x8Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=EHHj3guZ; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EHHj3guZ" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-47ee301a06aso59211885e9.0 for ; Tue, 20 Jan 2026 23:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768981339; x=1769586139; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=0cCPUZnGLoUlQBF/9NTsmnTAUK8WV5r6Blkl4XMyMuE=; b=EHHj3guZ4OUY8C10L9bOUKoUzpfWkdNAc7lKSKp+PU1+/jQEknZb0gXzHqx++d/ckG qssxHBDEznGgjznyucCUVzQqmqWWa03WV+0vBWsP3tyR7zJt5pllASVFzjEuhcRweULr 7RaIJKe2dip0GegKszVbFNaiBFxPAhp7RdHgILwgDSJt5FYYYqnnqqFhsXEXhStxubxE R6yuQnP+hSQbXzt8rWb3W9wq6Rcr93yM0nWXO159skNVmc8gSdC6yDNCUyGiyjn2jHs7 ltyAcJdpK7YqXRTUU6OI2JadS1lm9xRqDDYXLJVJ66FtC6WOk93O6UndPkCeayEfoj9p bswg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768981339; x=1769586139; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0cCPUZnGLoUlQBF/9NTsmnTAUK8WV5r6Blkl4XMyMuE=; b=N3hkHB8QM/aXcpZXYfombE5BXg+nE5OLs+AF14c5Y9/PgUWIEbvMHScGXd3OXy/H1h GP7iZ/l42FTJ6i89044eRvxkMZQh7Do+91wNQ5yhg5rG92E2TkfmvMqH5LqnFO8wzrVI 50Mtf3B/oIHS9PJ3RhCHvXJ0iqQ8uUyyYHmWEkwMciJmO6Ak+fv5+3TZrpk/Cq52xJhX 7qXUwpCUSozshupq9jaFE6pX6tZe47U5b3sMQvP37OeIKsDRpJ2f+mPUfmL9wH9Da4OW LWYw7JAYJHQF0zHoFSMKQuokZhtgBX51GbJ/y6bvzDowqZXX2+C3PtWE0hJAtrAt/1PC k75w== X-Forwarded-Encrypted: i=1; AJvYcCWfkqeGYoIvwfrdFrnV4i47ofvS4cmT04DDBKK+xoycRTYu1cvqeaiKdGSNoo4LSWD+dFSwJyWe8hIjnHU=@vger.kernel.org X-Gm-Message-State: AOJu0Ywdf5shMgto8TYcPsBut2KLHQthFJm98D9JeTTle8f8m78iy/VL KCv7C9F3aIYD2KcNjy/cTP82Ik0+k5bkvnxzANsGzJ/3WtqD57VDlur6 X-Gm-Gg: AZuq6aKU5ZSh/auWH9KixunJd3ztF2v1pVp7U6OVwVucaAALLyL+Md2Hqw8ns5xBG5I skWkgYeGeAtKG67Xj7a8eicY1G7tY2IoqBZ0z7VB8wp4ZQUJcQNCKG+33yJT43X15UwY3PHIrR/ P12509Bzs3FA9/pcSAIfaL/nYip1oENmalNZMseZ57RzupczqY1GxCsQ/eER6DrEFuy5otGihf3 4Kdb741tYG+HkVZ4qCVl9GbHcKOra2KGAag7SSkUFTcQuxYimlyRxNr3FDauFQlGg0HNyM4yNDc QImHSmhNJbB+SRBdbBzKahZfxrLTV1DE4TXdqkNy0n2Zdr5kuNutZEJBlvoxlU4ks6k+5lwpYoO B6caatwIlVR3HPZk1r+cAQ+czO8q7bDhSH9QEW8Y05zqMAK+WNnfwZbuZT7Ya9VRxtN2FCWHso3 WkPTukzwIWl+0zoAc6tJdvUI1x7wadv9dOmFJj+N9FvI3HWslpmOHXTFNorwx4bIw= X-Received: by 2002:a05:600c:198e:b0:477:9976:9e1a with SMTP id 5b1f17b1804b1-4801eaadc94mr208656345e9.6.1768981338757; Tue, 20 Jan 2026 23:42:18 -0800 (PST) Received: from alchark-surface.localdomain (bba-83-110-134-52.alshamil.net.ae. [83.110.134.52]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356999824csm34368915f8f.39.2026.01.20.23.42.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 23:42:18 -0800 (PST) From: Alexey Charkov Date: Wed, 21 Jan 2026 11:42:13 +0400 Subject: [PATCH v3] arm64: dts: rockchip: Explicitly request UFS reset pin on RK3576 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260121-ufs-rst-v3-1-35839bcb4ca7@gmail.com> X-B4-Tracking: v=1; b=H4sIAFSDcGkC/2WMyw6CMBBFf4XM2pq2QGld+R/GBdQpTCKPtNhoC P9uYSOJy3Nzz1kgoCcMcMkW8Bgp0DgkyE8Z2K4eWmT0SAySS8WFMOzlAvNhZs41lqPVGnkF6T1 5dPTeS7d74o7CPPrPHo5iW/8bUTDBrEajCpObQttr29f0PNuxh60R5cGT/OfJ5DVllZdOGKOcO nrrun4BqGEyK9YAAAA= X-Change-ID: 20260119-ufs-rst-ffbc0ec88e07 To: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Heiko Stuebner , "Martin K. Petersen" , Shawn Lin , Manivannan Sadhasivam Cc: Quentin Schulz , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Alexey Charkov X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=4576; i=alchark@gmail.com; h=from:subject:message-id; bh=H/Le12Y1Ya9Ys/AHE2MLwlPKgu80NfZB2AyT4Dbqvfw=; b=owGbwMvMwCW2adGNfoHIK0sZT6slMWQWNEd1/vFnKX7XOtVy1p1lmvIvev2rTpd0fmpM/nNXQ vLCtTVnOyayMIhxMViKKbLM/bbEdqoR36xdHh5fYeawMoEMkRZpYAACFga+3MS8UiMdIz1TbUM9 Q0MdYx0jBi5OAZhq3h8M/1PUlrT1cjzd+LP2hPPHiVdrjqyKMv++LfWp+MFDKeIlvxoYGc5LHbw W1GfhP9fil9RNhbevDEyO6D33TZoS4bdp5St7fX4A X-Developer-Key: i=alchark@gmail.com; a=openpgp; fpr=9DF6A43D95320E9ABA4848F5B2A2D88F1059D4A5 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. The pin is requested with pull-down enabled, which is in line with the SoC power-on default and helps ensure that the attached UFS chip stays in reset until the driver takes over the control of the respective GPIO line. This doesn't appear to affect Linux, but it does affect U-boot: Before: =3D> md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ... > =3D> ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=3D[3, 3], lane[2, 2], pwr[FA= STAUTO_MODE, FASTAUTO_MODE], rate =3D 2 =3D> md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ After: =3D> md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ...> =3D> ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=3D[3, 3], lane[2, 2], pwr[FA= STAUTO_MODE, FASTAUTO_MODE], rate =3D 2 =3D> 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 =3D GPIO, set =3D 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 RK357= 6 SoC") Reported-by: Quentin Schulz Reviewed-by: Quentin Schulz Signed-off-by: Alexey Charkov --- 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@che= rry.de/ --- Changes in v3: - Rename the pin to "ufs-rstgpio" to avoid incorrectly matching against the GPIO schema with the *-gpio pattern (thanks Rob's bot) - Amend the commit description to reflect the rationale for the pull-down configuration (thanks Quentin) - Link to v2: https://lore.kernel.org/r/20260120-ufs-rst-v2-1-b5735f1996f6@= gmail.com 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(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3576-pinctrl.dtsi b/arch/arm64/= boot/dts/rockchip/rk3576-pinctrl.dtsi index 0b0851a7e4ea..98c9f8013158 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_rstgpio: ufs-rstgpio { + rockchip,pins =3D + /* ufs_rstn */ + <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_down>; + }; }; =20 ufs_testdata0 { diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts= /rockchip/rk3576.dtsi index 3a29c627bf6d..49ccdf12ef7e 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 =3D <&cru CLK_REF_MPHY_26M>; interrupts =3D ; power-domains =3D <&power RK3576_PD_USB>; - pinctrl-0 =3D <&ufs_refclk>; + pinctrl-0 =3D <&ufs_refclk &ufs_rstgpio>; pinctrl-names =3D "default"; resets =3D <&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, --=20 Alexey Charkov