Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v12 28/36] phy: rockchip: usbdp: Only enable USB3 when not in high-speed mode
From: sashiko-bot @ 2026-07-10 21:26 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: robh, conor+dt, linux-phy, vkoul, devicetree, neil.armstrong,
	olteanv
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-28-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] rk_udphy_power_on returns 0 (success) for unsupported modes, tricking callers into accessing unclocked PHY registers
--

--- Patch [28]: [PATCH v12 28/36] phy: rockchip: usbdp: Only enable USB3 when not in high-speed mode ---
commit fac8dba407b679ba8fc75d417de958451d90f46f
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Only enable USB3 when not in high-speed mode

Ensure that USB3 mode is not accidently enabled during PHY re-init
for systems that are configured as high-speed only via DT.

Closes: https://sashiko.dev/#/message/20260626212424.C215E1F000E9%40smtp.kernel.org

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 2099ae2e51d1c..af915cc377275 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1009,7 +1009,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
>  		if (ret)
>  			return ret;
>  

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in how
rk_udphy_power_on() handles unsupported modes.

At the beginning of rk_udphy_power_on(), if the hardware isn't configured
for the requested mode, the function logs an info message and returns 0:

	if (!(udphy->mode & mode)) {
		dev_info(udphy->dev, "mode 0x%02x is not support\n", mode);
		return 0;
	}

Because it returns success, callers might assume the PHY was successfully
powered up and clocked. For example, if we look at rk_udphy_dp_phy_power_on():

	ret = rk_udphy_power_on(udphy, UDPHY_MODE_DP);
	if (ret)
		return ret;

	rk_udphy_dp_lane_enable(udphy, udphy->dp_lanes);

If UDPHY_MODE_DP is requested but not supported (for instance, if the
device tree configures it as USB-only), rk_udphy_power_on() will skip
the setup sequence and return 0.

Would the caller then proceed to access unclocked memory-mapped registers
in rk_udphy_dp_lane_enable() and trigger a kernel panic (SError)?

Should rk_udphy_power_on() return an error code like -EOPNOTSUPP instead
of 0 when an unsupported mode is requested?

> -		if (udphy->mode & UDPHY_MODE_USB)
> +		if (!udphy->hs && udphy->mode & UDPHY_MODE_USB)
>  			rk_udphy_u3_port_disable(udphy, false);
>  		udphy->phy_needs_reinit = false;
>  	} else if (udphy->phy_needs_reinit) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=28

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 33/36] phy: rockchip: usbdp: Rename mode to hw_mode
From: sashiko-bot @ 2026-07-10 21:23 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: conor+dt, linux-phy, devicetree, neil.armstrong, vkoul, olteanv,
	robh
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-33-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Compilation failure due to an incomplete rename of `udphy->mode` to `udphy->hw_mode` in `rk_udphy_power_on()`.
--

--- Patch [33]: [PATCH v12 33/36] phy: rockchip: usbdp: Rename mode to hw_mode ---
commit e122bf8f901705d3a0997d20cdd65f61c58d31c9
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Rename mode to hw_mode

This commit renames the mode field in struct rk_udphy to hw_mode. It
updates references across the driver to clarify that this represents the
hardware-supported modes.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index cf173276bfc01..7bce642f1e968 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c

[ ... ]

> @@ -1006,7 +1006,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
>  			return ret;
>  		}
>  
> -		if (!udphy->hs && udphy->mode & UDPHY_MODE_USB)
> +		if (!udphy->hs && udphy->hw_mode & UDPHY_MODE_USB)
>  			rk_udphy_u3_port_disable(udphy, false);
>  		udphy->phy_needs_reinit = false;
>  

[Severity: Low]
Does this code miss another rename of the mode field slightly further down in
rk_udphy_power_on()?

Looking at the else if (udphy->phy_needs_reinit) branch in the same function,
there is another reference to the old mode field:

		if (udphy->mode & UDPHY_MODE_USB)
			rk_udphy_u3_port_disable(udphy, false);

Will this cause a compilation failure since the mode field was removed from
struct rk_udphy?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=33

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* [PATCH v2 09/10] Input: matrix_keyboard - replace linux/gpio.h inclusion
From: Arnd Bergmann @ 2026-07-10 21:19 UTC (permalink / raw)
  To: linux-gpio, Linus Walleij, Bartosz Golaszewski
  Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
	Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
	Greg Ungerer, Thomas Bogendoerfer, Hauke Mehrtens,
	Rafał Miłecki, Yoshinori Sato,
	John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
	linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
	linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
	linux-phy, linux-rockchip, linux-sound, Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-1-arnd@kernel.org>

From: Arnd Bergmann <arnd@arndb.de>

linux/gpio.h is going away, so remove that since the driver already
includes linux/gpio/consumer.h.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/input/keyboard/matrix_keypad.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/input/keyboard/matrix_keypad.c b/drivers/input/keyboard/matrix_keypad.c
index e50a6fea9a60..8863b741d1a3 100644
--- a/drivers/input/keyboard/matrix_keypad.c
+++ b/drivers/input/keyboard/matrix_keypad.c
@@ -16,7 +16,6 @@
 #include <linux/interrupt.h>
 #include <linux/jiffies.h>
 #include <linux/module.h>
-#include <linux/gpio.h>
 #include <linux/input/matrix_keypad.h>
 #include <linux/slab.h>
 #include <linux/of.h>
-- 
2.39.5


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH v2 08/10] phy: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-07-10 21:19 UTC (permalink / raw)
  To: linux-gpio, Linus Walleij, Bartosz Golaszewski
  Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
	Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
	Greg Ungerer, Thomas Bogendoerfer, Hauke Mehrtens,
	Rafał Miłecki, Yoshinori Sato,
	John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
	linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
	linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
	linux-phy, linux-rockchip, linux-sound, Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-1-arnd@kernel.org>

From: Arnd Bergmann <arnd@arndb.de>

linux/gpio.h should no longer be used, so remove those and
make sure linux/gpio/consumer.h is included instead.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c | 1 -
 drivers/phy/rockchip/phy-rockchip-usbdp.c | 2 +-
 drivers/phy/ti/phy-j721e-wiz.c            | 1 -
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
index 8473fa574529..171bf097a8b8 100644
--- a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
+++ b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
@@ -3,7 +3,6 @@
 
 #include <linux/delay.h>
 #include <linux/extcon-provider.h>
-#include <linux/gpio.h>
 #include <linux/gpio/consumer.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index fba35510d88c..d0d736a30d08 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -11,7 +11,7 @@
 #include <linux/bits.h>
 #include <linux/clk.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/mfd/syscon.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 7531a8a04912..1f5dba49ace4 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -11,7 +11,6 @@
 #include <linux/slab.h>
 #include <linux/clk.h>
 #include <linux/clk-provider.h>
-#include <linux/gpio.h>
 #include <linux/gpio/consumer.h>
 #include <linux/io.h>
 #include <linux/module.h>
-- 
2.39.5


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH v2 07/10] pcmcia: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-07-10 21:19 UTC (permalink / raw)
  To: linux-gpio, Linus Walleij, Bartosz Golaszewski
  Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
	Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
	Greg Ungerer, Thomas Bogendoerfer, Hauke Mehrtens,
	Rafał Miłecki, Yoshinori Sato,
	John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
	linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
	linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
	linux-phy, linux-rockchip, linux-sound, Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-1-arnd@kernel.org>

From: Arnd Bergmann <arnd@arndb.de>

The pcmcia drivers all use the legacy interfaces, so convert to
include linux/gpio/legacy.h instead.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/pcmcia/bcm63xx_pcmcia.c | 2 +-
 drivers/pcmcia/db1xxx_ss.c      | 2 +-
 drivers/pcmcia/sa1100_h3600.c   | 2 +-
 drivers/pcmcia/soc_common.c     | 2 +-
 drivers/pcmcia/xxs1500_ss.c     | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pcmcia/bcm63xx_pcmcia.c b/drivers/pcmcia/bcm63xx_pcmcia.c
index 724fd6ee0fd0..1612b5d76975 100644
--- a/drivers/pcmcia/bcm63xx_pcmcia.c
+++ b/drivers/pcmcia/bcm63xx_pcmcia.c
@@ -14,7 +14,7 @@
 #include <linux/slab.h>
 #include <linux/delay.h>
 #include <linux/pci.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 
 #include <bcm63xx_regs.h>
 #include <bcm63xx_io.h>
diff --git a/drivers/pcmcia/db1xxx_ss.c b/drivers/pcmcia/db1xxx_ss.c
index 7b896d7dbc9f..410d24762f13 100644
--- a/drivers/pcmcia/db1xxx_ss.c
+++ b/drivers/pcmcia/db1xxx_ss.c
@@ -23,7 +23,7 @@
  */
 
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/interrupt.h>
 #include <linux/pm.h>
 #include <linux/module.h>
diff --git a/drivers/pcmcia/sa1100_h3600.c b/drivers/pcmcia/sa1100_h3600.c
index 10cb99c20a7f..6c52d90795eb 100644
--- a/drivers/pcmcia/sa1100_h3600.c
+++ b/drivers/pcmcia/sa1100_h3600.c
@@ -11,7 +11,7 @@
 #include <linux/interrupt.h>
 #include <linux/init.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 
 #include <mach/hardware.h>
 #include <asm/irq.h>
diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c
index 87aa3f667117..23585e3968e9 100644
--- a/drivers/pcmcia/soc_common.c
+++ b/drivers/pcmcia/soc_common.c
@@ -32,8 +32,8 @@
 
 
 #include <linux/cpufreq.h>
-#include <linux/gpio.h>
 #include <linux/gpio/consumer.h>
+#include <linux/gpio/legacy.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
diff --git a/drivers/pcmcia/xxs1500_ss.c b/drivers/pcmcia/xxs1500_ss.c
index 8a8aae1843b5..ba1bd0f9d9f8 100644
--- a/drivers/pcmcia/xxs1500_ss.c
+++ b/drivers/pcmcia/xxs1500_ss.c
@@ -7,7 +7,7 @@
  */
 
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/ioport.h>
-- 
2.39.5


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH v2 06/10] ASoC: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-07-10 21:19 UTC (permalink / raw)
  To: linux-gpio, Linus Walleij, Bartosz Golaszewski
  Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
	Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
	Greg Ungerer, Thomas Bogendoerfer, Hauke Mehrtens,
	Rafał Miłecki, Yoshinori Sato,
	John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
	linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
	linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
	linux-phy, linux-rockchip, linux-sound, Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-1-arnd@kernel.org>

From: Arnd Bergmann <arnd@arndb.de>

linux/gpio.h is going away,s o use linux/gpio/consumer.h instead.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 sound/soc/codecs/cs42l84.c | 1 -
 sound/soc/codecs/cx2072x.c | 2 +-
 sound/soc/codecs/dmic.c    | 1 -
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/sound/soc/codecs/cs42l84.c b/sound/soc/codecs/cs42l84.c
index f2a58163de0e..f2448b4c11fc 100644
--- a/sound/soc/codecs/cs42l84.c
+++ b/sound/soc/codecs/cs42l84.c
@@ -16,7 +16,6 @@
 #include <linux/init.h>
 #include <linux/delay.h>
 #include <linux/i2c.h>
-#include <linux/gpio.h>
 #include <linux/regmap.h>
 #include <linux/slab.h>
 #include <linux/acpi.h>
diff --git a/sound/soc/codecs/cx2072x.c b/sound/soc/codecs/cx2072x.c
index 83c6cbd40804..0dd35fa86cc5 100644
--- a/sound/soc/codecs/cx2072x.c
+++ b/sound/soc/codecs/cx2072x.c
@@ -11,7 +11,7 @@
 #include <linux/acpi.h>
 #include <linux/clk.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/init.h>
 #include <linux/i2c.h>
 #include <linux/module.h>
diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
index 61e1bf1b3c9e..cbed11136935 100644
--- a/sound/soc/codecs/dmic.c
+++ b/sound/soc/codecs/dmic.c
@@ -6,7 +6,6 @@
  */
 
 #include <linux/delay.h>
-#include <linux/gpio.h>
 #include <linux/gpio/consumer.h>
 #include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
-- 
2.39.5


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH v2 05/10] mfd: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-07-10 21:19 UTC (permalink / raw)
  To: linux-gpio, Linus Walleij, Bartosz Golaszewski
  Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
	Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
	Greg Ungerer, Thomas Bogendoerfer, Hauke Mehrtens,
	Rafał Miłecki, Yoshinori Sato,
	John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
	linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
	linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
	linux-phy, linux-rockchip, linux-sound, Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-1-arnd@kernel.org>

From: Arnd Bergmann <arnd@arndb.de>

linux/gpio.h should no longer be used, convert these instead to
either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/mfd/aat2870-core.c        | 2 +-
 drivers/mfd/arizona-irq.c         | 2 +-
 drivers/mfd/lp3943.c              | 2 +-
 drivers/mfd/sm501.c               | 2 +-
 drivers/mfd/tps6105x.c            | 2 +-
 drivers/mfd/tps65911-comparator.c | 2 +-
 drivers/mfd/wm8994-irq.c          | 2 +-
 include/linux/mfd/lp3943.h        | 2 +-
 include/linux/mfd/ti-lmu.h        | 1 -
 include/linux/mfd/tps65910.h      | 2 +-
 include/linux/mfd/ucb1x00.h       | 2 +-
 11 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/mfd/aat2870-core.c b/drivers/mfd/aat2870-core.c
index 34d66ba9646a..0d56cd6fbc6a 100644
--- a/drivers/mfd/aat2870-core.c
+++ b/drivers/mfd/aat2870-core.c
@@ -13,7 +13,7 @@
 #include <linux/uaccess.h>
 #include <linux/i2c.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/mfd/core.h>
 #include <linux/mfd/aat2870.h>
 #include <linux/regulator/machine.h>
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index 544016d420fe..14f9cb2c4b67 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -8,7 +8,7 @@
  */
 
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/irqdomain.h>
diff --git a/drivers/mfd/lp3943.c b/drivers/mfd/lp3943.c
index 6764553147e4..1918b5c7a5e7 100644
--- a/drivers/mfd/lp3943.c
+++ b/drivers/mfd/lp3943.c
@@ -28,7 +28,7 @@
  */
 
 #include <linux/err.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/i2c.h>
 #include <linux/mfd/core.h>
 #include <linux/mfd/lp3943.h>
diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index b5bda477ebfc..9d5bb67e8084 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -35,7 +35,7 @@ struct sm501_device {
 struct sm501_gpio;
 
 #ifdef CONFIG_MFD_SM501_GPIO
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 
 struct sm501_gpio_chip {
 	struct gpio_chip	gpio;
diff --git a/drivers/mfd/tps6105x.c b/drivers/mfd/tps6105x.c
index e2f6858d101e..b11cd2c03311 100644
--- a/drivers/mfd/tps6105x.c
+++ b/drivers/mfd/tps6105x.c
@@ -16,7 +16,7 @@
 #include <linux/init.h>
 #include <linux/i2c.h>
 #include <linux/regmap.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/spinlock.h>
 #include <linux/slab.h>
 #include <linux/err.h>
diff --git a/drivers/mfd/tps65911-comparator.c b/drivers/mfd/tps65911-comparator.c
index 7098712ea008..cc8545a972bc 100644
--- a/drivers/mfd/tps65911-comparator.c
+++ b/drivers/mfd/tps65911-comparator.c
@@ -14,7 +14,7 @@
 #include <linux/err.h>
 #include <linux/platform_device.h>
 #include <linux/debugfs.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/mfd/tps65910.h>
 
 #define COMP1					0
diff --git a/drivers/mfd/wm8994-irq.c b/drivers/mfd/wm8994-irq.c
index a46cea948763..a15483489b9d 100644
--- a/drivers/mfd/wm8994-irq.c
+++ b/drivers/mfd/wm8994-irq.c
@@ -9,7 +9,7 @@
 
 #include <linux/kernel.h>
 #include <linux/module.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/i2c.h>
 #include <linux/irq.h>
 #include <linux/mfd/core.h>
diff --git a/include/linux/mfd/lp3943.h b/include/linux/mfd/lp3943.h
index 402f01078fcc..5d2d172d3598 100644
--- a/include/linux/mfd/lp3943.h
+++ b/include/linux/mfd/lp3943.h
@@ -10,7 +10,7 @@
 #ifndef __MFD_LP3943_H__
 #define __MFD_LP3943_H__
 
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/regmap.h>
 
 /* Registers */
diff --git a/include/linux/mfd/ti-lmu.h b/include/linux/mfd/ti-lmu.h
index 0bc0e8199798..2089ec5124e8 100644
--- a/include/linux/mfd/ti-lmu.h
+++ b/include/linux/mfd/ti-lmu.h
@@ -10,7 +10,6 @@
 #ifndef __MFD_TI_LMU_H__
 #define __MFD_TI_LMU_H__
 
-#include <linux/gpio.h>
 #include <linux/notifier.h>
 #include <linux/regmap.h>
 #include <linux/gpio/consumer.h>
diff --git a/include/linux/mfd/tps65910.h b/include/linux/mfd/tps65910.h
index f67ef0a4e041..3813fc9c2b55 100644
--- a/include/linux/mfd/tps65910.h
+++ b/include/linux/mfd/tps65910.h
@@ -12,7 +12,7 @@
 #ifndef __LINUX_MFD_TPS65910_H
 #define __LINUX_MFD_TPS65910_H
 
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/regmap.h>
 
 /* TPS chip id list */
diff --git a/include/linux/mfd/ucb1x00.h b/include/linux/mfd/ucb1x00.h
index ede237384723..4ad54e22ed33 100644
--- a/include/linux/mfd/ucb1x00.h
+++ b/include/linux/mfd/ucb1x00.h
@@ -9,7 +9,7 @@
 
 #include <linux/device.h>
 #include <linux/mfd/mcp.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/gpio/driver.h>
 #include <linux/mutex.h>
 
-- 
2.39.5


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH v2 04/10] sh: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-07-10 21:19 UTC (permalink / raw)
  To: linux-gpio, Linus Walleij, Bartosz Golaszewski
  Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
	Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
	Greg Ungerer, Thomas Bogendoerfer, Hauke Mehrtens,
	Rafał Miłecki, Yoshinori Sato,
	John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
	linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
	linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
	linux-phy, linux-rockchip, linux-sound, Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-1-arnd@kernel.org>

From: Arnd Bergmann <arnd@arndb.de>

linux/gpio.h should no longer be used, convert these instead to
linux/gpio/legacy.h for the sh boards using the legacy interfaces,
or remove it where it is not needed at all.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/sh/boards/board-magicpanelr2.c             | 2 +-
 arch/sh/boards/board-sh7757lcr.c                | 2 +-
 arch/sh/boards/board-urquell.c                  | 2 +-
 arch/sh/boards/mach-ap325rxa/setup.c            | 2 +-
 arch/sh/boards/mach-ecovec24/setup.c            | 2 +-
 arch/sh/boards/mach-highlander/pinmux-r7785rp.c | 2 +-
 arch/sh/boards/mach-kfr2r09/lcd_wqvga.c         | 2 +-
 arch/sh/boards/mach-kfr2r09/setup.c             | 2 +-
 arch/sh/boards/mach-migor/lcd_qvga.c            | 2 +-
 arch/sh/boards/mach-migor/setup.c               | 2 +-
 arch/sh/boards/mach-rsk/devices-rsk7203.c       | 2 +-
 arch/sh/boards/mach-rsk/devices-rsk7269.c       | 1 -
 arch/sh/boards/mach-se/7724/setup.c             | 2 +-
 arch/sh/include/mach-common/mach/magicpanelr2.h | 2 --
 arch/sh/kernel/cpu/sh4a/setup-shx3.c            | 2 +-
 15 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/arch/sh/boards/board-magicpanelr2.c b/arch/sh/boards/board-magicpanelr2.c
index 75de893152af..3f14118a1015 100644
--- a/arch/sh/boards/board-magicpanelr2.c
+++ b/arch/sh/boards/board-magicpanelr2.c
@@ -10,7 +10,7 @@
 #include <linux/irq.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/smsc911x.h>
diff --git a/arch/sh/boards/board-sh7757lcr.c b/arch/sh/boards/board-sh7757lcr.c
index bca54e489e11..6d18f59ef261 100644
--- a/arch/sh/boards/board-sh7757lcr.c
+++ b/arch/sh/boards/board-sh7757lcr.c
@@ -7,7 +7,7 @@
 
 #include <linux/init.h>
 #include <linux/platform_device.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/irq.h>
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
diff --git a/arch/sh/boards/board-urquell.c b/arch/sh/boards/board-urquell.c
index dad2b3b40735..1f73c04d341f 100644
--- a/arch/sh/boards/board-urquell.c
+++ b/arch/sh/boards/board-urquell.c
@@ -14,7 +14,7 @@
 #include <linux/smc91x.h>
 #include <linux/mtd/physmap.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/irq.h>
 #include <linux/clk.h>
 #include <linux/sh_intc.h>
diff --git a/arch/sh/boards/mach-ap325rxa/setup.c b/arch/sh/boards/mach-ap325rxa/setup.c
index bb5004a8ac02..17c3f568d92e 100644
--- a/arch/sh/boards/mach-ap325rxa/setup.c
+++ b/arch/sh/boards/mach-ap325rxa/setup.c
@@ -17,7 +17,7 @@
 #include <linux/clkdev.h>
 #include <linux/delay.h>
 #include <linux/device.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/consumer.h>
 #include <linux/gpio/machine.h>
 #include <linux/i2c.h>
diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c
index a641e26f8fdf..ca4b4dd1ddef 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -20,7 +20,7 @@
 #include <linux/mmc/host.h>
 #include <linux/platform_data/sh_mmcif.h>
 #include <linux/mtd/physmap.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <linux/platform_data/gpio_backlight.h>
 #include <linux/platform_data/tmio.h>
diff --git a/arch/sh/boards/mach-highlander/pinmux-r7785rp.c b/arch/sh/boards/mach-highlander/pinmux-r7785rp.c
index 689bd8732d9e..3a1057ee9ace 100644
--- a/arch/sh/boards/mach-highlander/pinmux-r7785rp.c
+++ b/arch/sh/boards/mach-highlander/pinmux-r7785rp.c
@@ -3,7 +3,7 @@
  * Copyright (C) 2008 Paul Mundt
  */
 #include <linux/init.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <cpu/sh7785.h>
 #include <mach/highlander.h>
 
diff --git a/arch/sh/boards/mach-kfr2r09/lcd_wqvga.c b/arch/sh/boards/mach-kfr2r09/lcd_wqvga.c
index f6bbac106d13..68716660de34 100644
--- a/arch/sh/boards/mach-kfr2r09/lcd_wqvga.c
+++ b/arch/sh/boards/mach-kfr2r09/lcd_wqvga.c
@@ -14,7 +14,7 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <video/sh_mobile_lcdc.h>
 #include <mach/kfr2r09.h>
 #include <cpu/sh7724.h>
diff --git a/arch/sh/boards/mach-kfr2r09/setup.c b/arch/sh/boards/mach-kfr2r09/setup.c
index 70236859919d..30dd7dae7906 100644
--- a/arch/sh/boards/mach-kfr2r09/setup.c
+++ b/arch/sh/boards/mach-kfr2r09/setup.c
@@ -14,7 +14,7 @@
 
 #include <linux/clkdev.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <linux/i2c.h>
 #include <linux/init.h>
diff --git a/arch/sh/boards/mach-migor/lcd_qvga.c b/arch/sh/boards/mach-migor/lcd_qvga.c
index 4ebf130510bc..f72934e370fd 100644
--- a/arch/sh/boards/mach-migor/lcd_qvga.c
+++ b/arch/sh/boards/mach-migor/lcd_qvga.c
@@ -14,7 +14,7 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <video/sh_mobile_lcdc.h>
 #include <cpu/sh7722.h>
 #include <mach/migor.h>
diff --git a/arch/sh/boards/mach-migor/setup.c b/arch/sh/boards/mach-migor/setup.c
index 1853e6319a66..b0198e7cb9ab 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -22,7 +22,7 @@
 #include <linux/smc91x.h>
 #include <linux/delay.h>
 #include <linux/clk.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <linux/videodev2.h>
 #include <linux/sh_intc.h>
diff --git a/arch/sh/boards/mach-rsk/devices-rsk7203.c b/arch/sh/boards/mach-rsk/devices-rsk7203.c
index e6b05d4588b7..eb56b57812bd 100644
--- a/arch/sh/boards/mach-rsk/devices-rsk7203.c
+++ b/arch/sh/boards/mach-rsk/devices-rsk7203.c
@@ -10,7 +10,7 @@
 #include <linux/interrupt.h>
 #include <linux/smsc911x.h>
 #include <linux/input.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio_keys.h>
 #include <linux/leds.h>
 #include <asm/machvec.h>
diff --git a/arch/sh/boards/mach-rsk/devices-rsk7269.c b/arch/sh/boards/mach-rsk/devices-rsk7269.c
index 4b1e386b51dd..54edd9958eca 100644
--- a/arch/sh/boards/mach-rsk/devices-rsk7269.c
+++ b/arch/sh/boards/mach-rsk/devices-rsk7269.c
@@ -11,7 +11,6 @@
 #include <linux/interrupt.h>
 #include <linux/input.h>
 #include <linux/smsc911x.h>
-#include <linux/gpio.h>
 #include <asm/machvec.h>
 #include <asm/io.h>
 
diff --git a/arch/sh/boards/mach-se/7724/setup.c b/arch/sh/boards/mach-se/7724/setup.c
index e500feb91053..bed8f44fcecb 100644
--- a/arch/sh/boards/mach-se/7724/setup.c
+++ b/arch/sh/boards/mach-se/7724/setup.c
@@ -15,7 +15,7 @@
 
 #include <linux/delay.h>
 #include <linux/device.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/init.h>
 #include <linux/input.h>
 #include <linux/input/sh_keysc.h>
diff --git a/arch/sh/include/mach-common/mach/magicpanelr2.h b/arch/sh/include/mach-common/mach/magicpanelr2.h
index c2d218cea74b..29d86dd21b7b 100644
--- a/arch/sh/include/mach-common/mach/magicpanelr2.h
+++ b/arch/sh/include/mach-common/mach/magicpanelr2.h
@@ -10,8 +10,6 @@
 #ifndef __ASM_SH_MAGICPANELR2_H
 #define __ASM_SH_MAGICPANELR2_H
 
-#include <linux/gpio.h>
-
 #define __IO_PREFIX mpr2
 #include <asm/io_generic.h>
 
diff --git a/arch/sh/kernel/cpu/sh4a/setup-shx3.c b/arch/sh/kernel/cpu/sh4a/setup-shx3.c
index 7014d6d199b3..60be8dca54f6 100644
--- a/arch/sh/kernel/cpu/sh4a/setup-shx3.c
+++ b/arch/sh/kernel/cpu/sh4a/setup-shx3.c
@@ -9,7 +9,7 @@
 #include <linux/serial.h>
 #include <linux/serial_sci.h>
 #include <linux/io.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/sh_timer.h>
 #include <linux/sh_intc.h>
 #include <cpu/shx3.h>
-- 
2.39.5


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH v2 03/10] mips: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-07-10 21:19 UTC (permalink / raw)
  To: linux-gpio, Linus Walleij, Bartosz Golaszewski
  Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
	Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
	Greg Ungerer, Thomas Bogendoerfer, Hauke Mehrtens,
	Rafał Miłecki, Yoshinori Sato,
	John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
	linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
	linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
	linux-phy, linux-rockchip, linux-sound, Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-1-arnd@kernel.org>

From: Arnd Bergmann <arnd@arndb.de>

linux/gpio.h should no longer be used, convert these instead to
either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/mips/alchemy/board-xxs1500.c                   | 2 +-
 arch/mips/alchemy/devboards/db1000.c                | 2 +-
 arch/mips/alchemy/devboards/db1200.c                | 2 +-
 arch/mips/alchemy/devboards/db1550.c                | 2 +-
 arch/mips/bcm47xx/workarounds.c                     | 2 +-
 arch/mips/bcm63xx/boards/board_bcm963xx.c           | 1 +
 arch/mips/include/asm/mach-bcm63xx/board_bcm963xx.h | 2 +-
 arch/mips/txx9/rbtx4927/setup.c                     | 2 +-
 8 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/mips/alchemy/board-xxs1500.c b/arch/mips/alchemy/board-xxs1500.c
index f175bce2987f..a03762dde4e7 100644
--- a/arch/mips/alchemy/board-xxs1500.c
+++ b/arch/mips/alchemy/board-xxs1500.c
@@ -11,7 +11,7 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/platform_device.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/delay.h>
 #include <linux/pm.h>
 #include <asm/bootinfo.h>
diff --git a/arch/mips/alchemy/devboards/db1000.c b/arch/mips/alchemy/devboards/db1000.c
index 8fb24b220e3a..5eff34a8683b 100644
--- a/arch/mips/alchemy/devboards/db1000.c
+++ b/arch/mips/alchemy/devboards/db1000.c
@@ -8,7 +8,7 @@
 
 #include <linux/clk.h>
 #include <linux/dma-mapping.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <linux/gpio/property.h>
 #include <linux/init.h>
diff --git a/arch/mips/alchemy/devboards/db1200.c b/arch/mips/alchemy/devboards/db1200.c
index de2a9083ed9a..539b311fc8af 100644
--- a/arch/mips/alchemy/devboards/db1200.c
+++ b/arch/mips/alchemy/devboards/db1200.c
@@ -7,7 +7,7 @@
 
 #include <linux/clk.h>
 #include <linux/dma-mapping.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/i2c.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
diff --git a/arch/mips/alchemy/devboards/db1550.c b/arch/mips/alchemy/devboards/db1550.c
index b8295a5c2e9a..579fc8f1eaed 100644
--- a/arch/mips/alchemy/devboards/db1550.c
+++ b/arch/mips/alchemy/devboards/db1550.c
@@ -7,7 +7,7 @@
 
 #include <linux/clk.h>
 #include <linux/dma-mapping.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/i2c.h>
 #include <linux/init.h>
 #include <linux/io.h>
diff --git a/arch/mips/bcm47xx/workarounds.c b/arch/mips/bcm47xx/workarounds.c
index 745c6228eb2c..dc9e5483347d 100644
--- a/arch/mips/bcm47xx/workarounds.c
+++ b/arch/mips/bcm47xx/workarounds.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include "bcm47xx_private.h"
 
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <bcm47xx_board.h>
 #include <bcm47xx.h>
 
diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c b/arch/mips/bcm63xx/boards/board_bcm963xx.c
index c5617b889b1c..71628dac6c26 100644
--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
+++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
@@ -7,6 +7,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include <linux/init.h>
+#include <linux/gpio/legacy.h>
 #include <linux/kernel.h>
 #include <linux/string.h>
 #include <linux/platform_device.h>
diff --git a/arch/mips/include/asm/mach-bcm63xx/board_bcm963xx.h b/arch/mips/include/asm/mach-bcm63xx/board_bcm963xx.h
index 830f53f28e3f..428cf4508f9a 100644
--- a/arch/mips/include/asm/mach-bcm63xx/board_bcm963xx.h
+++ b/arch/mips/include/asm/mach-bcm63xx/board_bcm963xx.h
@@ -3,7 +3,7 @@
 #define BOARD_BCM963XX_H_
 
 #include <linux/types.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/leds.h>
 #include <bcm63xx_dev_enet.h>
 #include <bcm63xx_dev_usb_usbd.h>
diff --git a/arch/mips/txx9/rbtx4927/setup.c b/arch/mips/txx9/rbtx4927/setup.c
index 31955c1d5555..b4fbe6a2a73a 100644
--- a/arch/mips/txx9/rbtx4927/setup.c
+++ b/arch/mips/txx9/rbtx4927/setup.c
@@ -48,7 +48,7 @@
 #include <linux/ioport.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/leds.h>
 #include <asm/io.h>
 #include <asm/reboot.h>
-- 
2.39.5


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* Re: [PATCH v12 26/36] phy: rockchip: usbdp: Avoid xHCI SErrors
From: sashiko-bot @ 2026-07-10 21:20 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: olteanv, robh, conor+dt, linux-phy, vkoul, devicetree,
	neil.armstrong
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-26-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] Clock and power leak in `rk_udphy_usb3_phy_exit` when Type-C mode drops USB support.
- [High] The patch unconditionally re-enables the SuperSpeed U3 port during PHY initialization and re-initialization, ignoring the high-speed restriction (`udphy->hs`).

Pre-existing issues:
- [High] When a Type-C device is unplugged, the PHY re-initialization is flagged but never executed, leaving the USB3 port physically disabled and breaking subsequent USB3 connections.
--

--- Patch [26]: [PATCH v12 26/36] phy: rockchip: usbdp: Avoid xHCI SErrors ---
commit 66857e87fceaec79fad3845d46dbfd48c9340977
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Avoid xHCI SErrors

This commit addresses an SError caused by the dwc3 driver accessing xHCI
registers while the USBDP PHY is temporarily disabled during a mode switch.
It resolves this by disabling the USB3 port prior to re-initialization, which
safely re-routes the PIPE clock to the UTMI fallback clock.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index edee27933d890..ff768e5b43ca0 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1000,12 +1000,15 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
>  			rk_udphy_u3_port_disable(udphy, false);
>  		udphy->phy_needs_reinit = false;
>  	} else if (udphy->phy_needs_reinit) {
> -		if (udphy->mode == UDPHY_MODE_DP)
> -			rk_udphy_u3_port_disable(udphy, true);
> +		rk_udphy_u3_port_disable(udphy, true);
> +		udelay(10);
>  
>  		ret = rk_udphy_init(udphy);
>  		if (ret)
>  			return ret;
> +
> +		if (udphy->mode & UDPHY_MODE_USB)
> +			rk_udphy_u3_port_disable(udphy, false);

[Severity: High]
Does this code unconditionally re-enable the SuperSpeed U3 port purely based on
the mode?

During rk_udphy_usb3_phy_init(), the U3 port is kept disabled if udphy->hs is
true. However, when a mode switch or DP power-on triggers a PHY
re-initialization in rk_udphy_power_on(), this new logic executes without
checking !udphy->hs.

Could this result in misconfiguring the hardware by enabling the SuperSpeed U3
port on boards that explicitly restricted the PHY to high-speed
(maximum-speed = "high-speed")?

>  		udphy->phy_needs_reinit = false;

[Severity: High]
This is a pre-existing issue, but does the phy_needs_reinit state machine get
stuck when a Type-C device is unplugged?

If a DP-only cable is unplugged after a standard USB3 cable was active,
typec_mux_set() reverts to UDPHY_MODE_DP_USB and flags
phy_needs_reinit = true. The DP framework calls rk_udphy_dp_phy_power_off(),
which clears the DP bit from udphy->status:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_power_off() {
    rk_udphy_dp_lane_enable(udphy, 0);
    rk_udphy_power_off(udphy, UDPHY_MODE_DP);
}

Because the USB3 controller never suspended, udphy->status remains non-zero
(set to UDPHY_MODE_USB), so the PHY isn't disabled. Crucially, no driver calls
rk_udphy_power_on() to process the pending phy_needs_reinit state.

Will this strand the active USB3 PHY in a disabled physical state, breaking
subsequent USB3 connections?

>  	}

[Severity: High]
Regarding the related commit in this series that clears USB status on PHY exit,
is there a clock and power leak in rk_udphy_usb3_phy_exit() when the Type-C
mode drops USB support?

In rk_udphy_usb3_phy_exit():

	if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs) {
		udphy->status &= ~UDPHY_MODE_USB;
		return 0;
	}

When the Type-C mode dynamically changes to a state without USB support (e.g.,
a DP-only cable is connected), udphy->mode becomes UDPHY_MODE_DP. If the USB
controller then suspends and calls phy_exit(), rk_udphy_usb3_phy_exit()
executes this early return.

This clears the UDPHY_MODE_USB bit from udphy->status, but misses checking if
udphy->status == UDPHY_MODE_NONE. Could this completely fail to call
rk_udphy_disable(), wasting power and potentially blocking system suspend?

Additionally, rk_udphy_power_off() inappropriately refuses to turn off active
hardware features if the negotiated Type-C udphy->mode has already shifted
away from the requested mode:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_power_off() {
	if (!(udphy->mode & mode)) {
		dev_info(udphy->dev, "mode 0x%02x is not support\n", mode);
		return;
	}
    ...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=26

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* [PATCH v2 02/10] m68k/coldfire: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-07-10 21:19 UTC (permalink / raw)
  To: linux-gpio, Linus Walleij, Bartosz Golaszewski
  Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
	Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
	Greg Ungerer, Thomas Bogendoerfer, Hauke Mehrtens,
	Rafał Miłecki, Yoshinori Sato,
	John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
	linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
	linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
	linux-phy, linux-rockchip, linux-sound, Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-1-arnd@kernel.org>

From: Arnd Bergmann <arnd@arndb.de>

linux/gpio.h should no longer be used, convert these instead to
linux/gpio/legacy.h for coldfire.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/m68k/coldfire/device.c     | 2 +-
 arch/m68k/include/asm/mcfgpio.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
index 1420bae0964f..9a0258acd998 100644
--- a/arch/m68k/coldfire/device.c
+++ b/arch/m68k/coldfire/device.c
@@ -12,7 +12,7 @@
 #include <linux/init.h>
 #include <linux/io.h>
 #include <linux/spi/spi.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/fec.h>
 #include <linux/dmaengine.h>
 #include <asm/traps.h>
diff --git a/arch/m68k/include/asm/mcfgpio.h b/arch/m68k/include/asm/mcfgpio.h
index 7103cfa4edb6..29726aa40eb6 100644
--- a/arch/m68k/include/asm/mcfgpio.h
+++ b/arch/m68k/include/asm/mcfgpio.h
@@ -16,7 +16,7 @@ int __mcfgpio_request(unsigned gpio);
 void __mcfgpio_free(unsigned gpio);
 
 #ifdef CONFIG_GPIOLIB
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #else
 
 /* our alternate 'gpiolib' functions */
-- 
2.39.5


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH v2 01/10] ARM: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-07-10 21:19 UTC (permalink / raw)
  To: linux-gpio, Linus Walleij, Bartosz Golaszewski
  Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
	Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
	Greg Ungerer, Thomas Bogendoerfer, Hauke Mehrtens,
	Rafał Miłecki, Yoshinori Sato,
	John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
	linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
	linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
	linux-phy, linux-rockchip, linux-sound, Bartosz Golaszewski, soc
In-Reply-To: <20260710211954.1373336-1-arnd@kernel.org>

From: Arnd Bergmann <arnd@arndb.de>

linux/gpio.h should no longer be used, convert these instead to
either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Cc: soc@lists.linux.dev
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-davinci/da850.c                  | 2 +-
 arch/arm/mach-dove/mpp.c                       | 2 +-
 arch/arm/mach-mv78xx0/buffalo-wxl-setup.c      | 2 +-
 arch/arm/mach-mv78xx0/irq.c                    | 2 +-
 arch/arm/mach-mv78xx0/mpp.c                    | 2 +-
 arch/arm/mach-mvebu/pm.c                       | 2 +-
 arch/arm/mach-mxs/mach-mxs.c                   | 2 +-
 arch/arm/mach-orion5x/board-d2net.c            | 2 +-
 arch/arm/mach-orion5x/board-rd88f5182.c        | 2 +-
 arch/arm/mach-orion5x/dns323-setup.c           | 2 +-
 arch/arm/mach-orion5x/irq.c                    | 2 +-
 arch/arm/mach-orion5x/kurobox_pro-setup.c      | 2 +-
 arch/arm/mach-orion5x/mv2120-setup.c           | 2 +-
 arch/arm/mach-orion5x/net2big-setup.c          | 2 +-
 arch/arm/mach-orion5x/terastation_pro2-setup.c | 2 +-
 arch/arm/mach-orion5x/ts209-setup.c            | 2 +-
 arch/arm/mach-orion5x/ts409-setup.c            | 2 +-
 arch/arm/mach-pxa/am200epd.c                   | 2 +-
 arch/arm/mach-pxa/am300epd.c                   | 2 +-
 arch/arm/mach-pxa/generic.c                    | 2 +-
 arch/arm/mach-pxa/gumstix.c                    | 2 +-
 arch/arm/mach-pxa/mfp-pxa2xx.c                 | 2 +-
 arch/arm/mach-pxa/pxa25x.c                     | 2 +-
 arch/arm/mach-pxa/pxa27x.c                     | 2 +-
 arch/arm/mach-pxa/reset.c                      | 2 +-
 arch/arm/mach-pxa/sharpsl_pm.c                 | 2 +-
 arch/arm/mach-pxa/spitz.c                      | 2 +-
 arch/arm/mach-pxa/spitz_pm.c                   | 2 +-
 arch/arm/mach-s3c/dev-audio-s3c64xx.c          | 2 +-
 arch/arm/mach-s3c/devs.c                       | 2 +-
 arch/arm/mach-s3c/mach-crag6410.c              | 2 +-
 arch/arm/mach-s3c/pm-gpio.c                    | 2 +-
 arch/arm/mach-s3c/pm-s3c64xx.c                 | 2 +-
 arch/arm/mach-s3c/setup-fb-24bpp-s3c64xx.c     | 2 +-
 arch/arm/mach-s3c/setup-i2c0-s3c64xx.c         | 2 +-
 arch/arm/mach-s3c/setup-i2c1-s3c64xx.c         | 2 +-
 arch/arm/mach-s3c/setup-keypad-s3c64xx.c       | 2 +-
 arch/arm/mach-s3c/setup-sdhci-gpio-s3c64xx.c   | 2 +-
 arch/arm/mach-s3c/setup-spi-s3c64xx.c          | 2 +-
 arch/arm/mach-sa1100/collie.c                  | 2 +-
 arch/arm/mach-sa1100/generic.c                 | 2 +-
 arch/arm/mach-sa1100/h3600.c                   | 2 +-
 arch/arm/mach-sa1100/h3xxx.c                   | 2 +-
 arch/arm/plat-orion/mpp.c                      | 2 +-
 44 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 706f8241b5e7..611cce70c5bb 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -9,7 +9,7 @@
  * 2009 (c) MontaVista Software, Inc.
  */
 
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/init.h>
 #include <linux/io.h>
 #include <linux/mfd/da8xx-cfgchip.h>
diff --git a/arch/arm/mach-dove/mpp.c b/arch/arm/mach-dove/mpp.c
index 93cb137da5f8..e41bd473abe9 100644
--- a/arch/arm/mach-dove/mpp.c
+++ b/arch/arm/mach-dove/mpp.c
@@ -6,7 +6,7 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/io.h>
 #include <plat/mpp.h>
 #include <plat/orion-gpio.h>
diff --git a/arch/arm/mach-mv78xx0/buffalo-wxl-setup.c b/arch/arm/mach-mv78xx0/buffalo-wxl-setup.c
index 62e982f74bc2..3b2e381b7383 100644
--- a/arch/arm/mach-mv78xx0/buffalo-wxl-setup.c
+++ b/arch/arm/mach-mv78xx0/buffalo-wxl-setup.c
@@ -14,7 +14,7 @@
 #include <linux/mv643xx_eth.h>
 #include <linux/ethtool.h>
 #include <linux/i2c.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
 #include <asm/mach-types.h>
diff --git a/arch/arm/mach-mv78xx0/irq.c b/arch/arm/mach-mv78xx0/irq.c
index a34b6855fb19..6e42f6446637 100644
--- a/arch/arm/mach-mv78xx0/irq.c
+++ b/arch/arm/mach-mv78xx0/irq.c
@@ -4,7 +4,7 @@
  *
  * MV78xx0 IRQ handling.
  */
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/kernel.h>
 #include <linux/irq.h>
 #include <linux/io.h>
diff --git a/arch/arm/mach-mv78xx0/mpp.c b/arch/arm/mach-mv78xx0/mpp.c
index aff0e612cbba..32bf590d79fe 100644
--- a/arch/arm/mach-mv78xx0/mpp.c
+++ b/arch/arm/mach-mv78xx0/mpp.c
@@ -4,7 +4,7 @@
  *
  * MPP functions for Marvell MV78x00 SoCs
  */
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
diff --git a/arch/arm/mach-mvebu/pm.c b/arch/arm/mach-mvebu/pm.c
index b149d9b77505..616a7fb22d86 100644
--- a/arch/arm/mach-mvebu/pm.c
+++ b/arch/arm/mach-mvebu/pm.c
@@ -9,7 +9,7 @@
 
 #include <linux/cpu_pm.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
 #include <linux/mbus.h>
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index f639d5004351..c8231a480052 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -9,7 +9,7 @@
 #include <linux/clkdev.h>
 #include <linux/delay.h>
 #include <linux/err.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/init.h>
 #include <linux/reboot.h>
 #include <linux/micrel_phy.h>
diff --git a/arch/arm/mach-orion5x/board-d2net.c b/arch/arm/mach-orion5x/board-d2net.c
index 09bf366d05ff..7cf09da9d9e7 100644
--- a/arch/arm/mach-orion5x/board-d2net.c
+++ b/arch/arm/mach-orion5x/board-d2net.c
@@ -13,7 +13,7 @@
 #include <linux/pci.h>
 #include <linux/irq.h>
 #include <linux/leds.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
diff --git a/arch/arm/mach-orion5x/board-rd88f5182.c b/arch/arm/mach-orion5x/board-rd88f5182.c
index 1c14e49a90a6..9e2fe74ec68a 100644
--- a/arch/arm/mach-orion5x/board-rd88f5182.c
+++ b/arch/arm/mach-orion5x/board-rd88f5182.c
@@ -6,7 +6,7 @@
  *
  * Maintainer: Ronen Shitrit <rshitrit@marvell.com>
  */
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/of.h>
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index fcd38ff7ca45..7b81b08b0dda 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -13,7 +13,7 @@
  * License, or (at your option) any later version.
  *
  */
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
diff --git a/arch/arm/mach-orion5x/irq.c b/arch/arm/mach-orion5x/irq.c
index e17727e53cb4..689bec1ebe89 100644
--- a/arch/arm/mach-orion5x/irq.c
+++ b/arch/arm/mach-orion5x/irq.c
@@ -6,7 +6,7 @@
  *
  * Maintainer: Tzachi Perelstein <tzachi@marvell.com>
  */
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/kernel.h>
 #include <linux/irq.h>
 #include <linux/io.h>
diff --git a/arch/arm/mach-orion5x/kurobox_pro-setup.c b/arch/arm/mach-orion5x/kurobox_pro-setup.c
index 339b10891808..e61b9ab06943 100644
--- a/arch/arm/mach-orion5x/kurobox_pro-setup.c
+++ b/arch/arm/mach-orion5x/kurobox_pro-setup.c
@@ -4,7 +4,7 @@
  *
  * Maintainer: Ronen Shitrit <rshitrit@marvell.com>
  */
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c b/arch/arm/mach-orion5x/mv2120-setup.c
index 5b0249f109cd..b15fe5b7a0f9 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -7,7 +7,7 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  */
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
diff --git a/arch/arm/mach-orion5x/net2big-setup.c b/arch/arm/mach-orion5x/net2big-setup.c
index 4afd9b4c71a9..f04571e79805 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -17,7 +17,7 @@
 #include <linux/input.h>
 #include <linux/i2c.h>
 #include <linux/ata_platform.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <linux/delay.h>
 #include <asm/mach-types.h>
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c b/arch/arm/mach-orion5x/terastation_pro2-setup.c
index a9f01859d101..c3db3376950a 100644
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
@@ -4,7 +4,7 @@
  *
  * Maintainer: Sylver Bruneau <sylver.bruneau@googlemail.com>
  */
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index de9092e992c5..25cd50306c65 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -4,7 +4,7 @@
  *
  * Maintainer: Byron Bradley <byron.bbradley@gmail.com>
  */
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
diff --git a/arch/arm/mach-orion5x/ts409-setup.c b/arch/arm/mach-orion5x/ts409-setup.c
index 725688aa5cba..f92acef0b45f 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -7,7 +7,7 @@
  * Copyright (C) 2008  Sylver Bruneau <sylver.bruneau@gmail.com>
  * Copyright (C) 2008  Martin Michlmayr <tbm@cyrius.com>
  */
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
diff --git a/arch/arm/mach-pxa/am200epd.c b/arch/arm/mach-pxa/am200epd.c
index cac0bb09db14..4814f3cfe775 100644
--- a/arch/arm/mach-pxa/am200epd.c
+++ b/arch/arm/mach-pxa/am200epd.c
@@ -28,7 +28,7 @@
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/irq.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 
 #include "pxa25x.h"
 #include "gumstix.h"
diff --git a/arch/arm/mach-pxa/am300epd.c b/arch/arm/mach-pxa/am300epd.c
index 4b55bc89db8f..435fb72da7de 100644
--- a/arch/arm/mach-pxa/am300epd.c
+++ b/arch/arm/mach-pxa/am300epd.c
@@ -26,7 +26,7 @@
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/irq.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 
 #include "gumstix.h"
 #include "mfp-pxa25x.h"
diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index 02fdde7e3e34..f181e7b7c6be 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -13,7 +13,7 @@
  * initialization stuff for PXA machines which can be overridden later if
  * need be.
  */
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
diff --git a/arch/arm/mach-pxa/gumstix.c b/arch/arm/mach-pxa/gumstix.c
index 6074815a4bca..7ab0cb015d1b 100644
--- a/arch/arm/mach-pxa/gumstix.c
+++ b/arch/arm/mach-pxa/gumstix.c
@@ -22,7 +22,7 @@
 #include <linux/mtd/partitions.h>
 #include <linux/gpio/machine.h>
 #include <linux/gpio/property.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/err.h>
 #include <linux/clk.h>
 
diff --git a/arch/arm/mach-pxa/mfp-pxa2xx.c b/arch/arm/mach-pxa/mfp-pxa2xx.c
index d1347055fbe4..566fb4e2adba 100644
--- a/arch/arm/mach-pxa/mfp-pxa2xx.c
+++ b/arch/arm/mach-pxa/mfp-pxa2xx.c
@@ -9,7 +9,7 @@
  *  on PXA3xx,  what's more important, the low power pin state and
  *  wakeup detection are also supported by the same framework.
  */
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/gpio-pxa.h>
 #include <linux/module.h>
 #include <linux/kernel.h>
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index a4e878be004a..a273f0af095e 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -15,7 +15,7 @@
  */
 #include <linux/dmaengine.h>
 #include <linux/dma/pxa-dma.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/gpio-pxa.h>
 #include <linux/module.h>
 #include <linux/kernel.h>
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 1d34de7e5fbe..814e0a12f38a 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -10,7 +10,7 @@
  */
 #include <linux/dmaengine.h>
 #include <linux/dma/pxa-dma.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/gpio-pxa.h>
 #include <linux/module.h>
 #include <linux/kernel.h>
diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c
index 27293549f8ad..49d2e46a1fae 100644
--- a/arch/arm/mach-pxa/reset.c
+++ b/arch/arm/mach-pxa/reset.c
@@ -2,7 +2,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/io.h>
 #include <asm/proc-fns.h>
 #include <asm/system_misc.h>
diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
index 71b282b146d0..a611eea70e5a 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.c
+++ b/arch/arm/mach-pxa/sharpsl_pm.c
@@ -19,7 +19,7 @@
 #include <linux/delay.h>
 #include <linux/leds.h>
 #include <linux/suspend.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/io.h>
 
 #include <asm/mach-types.h>
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 5091b601c4e1..5eaf38243b9e 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -12,7 +12,7 @@
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/gpio_keys.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <linux/gpio/property.h>
 #include <linux/leds.h>
diff --git a/arch/arm/mach-pxa/spitz_pm.c b/arch/arm/mach-pxa/spitz_pm.c
index 03b4b347f11a..806847c36549 100644
--- a/arch/arm/mach-pxa/spitz_pm.c
+++ b/arch/arm/mach-pxa/spitz_pm.c
@@ -10,7 +10,7 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio-pxa.h>
 #include <linux/interrupt.h>
 #include <linux/platform_device.h>
diff --git a/arch/arm/mach-s3c/dev-audio-s3c64xx.c b/arch/arm/mach-s3c/dev-audio-s3c64xx.c
index 7ce119dc3a72..8884374dbcdc 100644
--- a/arch/arm/mach-s3c/dev-audio-s3c64xx.c
+++ b/arch/arm/mach-s3c/dev-audio-s3c64xx.c
@@ -7,7 +7,7 @@
 #include <linux/string.h>
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/export.h>
 
 #include "irqs.h"
diff --git a/arch/arm/mach-s3c/devs.c b/arch/arm/mach-s3c/devs.c
index bab2abd8a34a..572b156644bd 100644
--- a/arch/arm/mach-s3c/devs.c
+++ b/arch/arm/mach-s3c/devs.c
@@ -5,7 +5,7 @@
 //
 // Base Samsung platform device definitions
 
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/kernel.h>
 #include <linux/types.h>
 #include <linux/interrupt.h>
diff --git a/arch/arm/mach-s3c/mach-crag6410.c b/arch/arm/mach-s3c/mach-crag6410.c
index c4040aad1ed3..57176719d8a6 100644
--- a/arch/arm/mach-s3c/mach-crag6410.c
+++ b/arch/arm/mach-s3c/mach-crag6410.c
@@ -15,7 +15,7 @@
 #include <linux/io.h>
 #include <linux/init.h>
 #include <linux/input-event-codes.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <linux/leds.h>
 #include <linux/delay.h>
diff --git a/arch/arm/mach-s3c/pm-gpio.c b/arch/arm/mach-s3c/pm-gpio.c
index cfdbc2337998..fd5897cc26c7 100644
--- a/arch/arm/mach-s3c/pm-gpio.c
+++ b/arch/arm/mach-s3c/pm-gpio.c
@@ -11,7 +11,7 @@
 #include <linux/device.h>
 #include <linux/init.h>
 #include <linux/io.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 
 #include "gpio-samsung.h"
 
diff --git a/arch/arm/mach-s3c/pm-s3c64xx.c b/arch/arm/mach-s3c/pm-s3c64xx.c
index 284d5f462513..a73b8bd12949 100644
--- a/arch/arm/mach-s3c/pm-s3c64xx.c
+++ b/arch/arm/mach-s3c/pm-s3c64xx.c
@@ -11,7 +11,7 @@
 #include <linux/suspend.h>
 #include <linux/serial_core.h>
 #include <linux/io.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/pm_domain.h>
 
 #include "map.h"
diff --git a/arch/arm/mach-s3c/setup-fb-24bpp-s3c64xx.c b/arch/arm/mach-s3c/setup-fb-24bpp-s3c64xx.c
index c3269cd6a848..20ae926e12db 100644
--- a/arch/arm/mach-s3c/setup-fb-24bpp-s3c64xx.c
+++ b/arch/arm/mach-s3c/setup-fb-24bpp-s3c64xx.c
@@ -9,7 +9,7 @@
 
 #include <linux/kernel.h>
 #include <linux/types.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 
 #include "fb.h"
 #include "gpio-cfg.h"
diff --git a/arch/arm/mach-s3c/setup-i2c0-s3c64xx.c b/arch/arm/mach-s3c/setup-i2c0-s3c64xx.c
index a6ef8d2bc995..520e97dc8754 100644
--- a/arch/arm/mach-s3c/setup-i2c0-s3c64xx.c
+++ b/arch/arm/mach-s3c/setup-i2c0-s3c64xx.c
@@ -9,7 +9,7 @@
 
 #include <linux/kernel.h>
 #include <linux/types.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 
 struct platform_device; /* don't need the contents */
 
diff --git a/arch/arm/mach-s3c/setup-i2c1-s3c64xx.c b/arch/arm/mach-s3c/setup-i2c1-s3c64xx.c
index 0fe37363d26e..26f7ae455328 100644
--- a/arch/arm/mach-s3c/setup-i2c1-s3c64xx.c
+++ b/arch/arm/mach-s3c/setup-i2c1-s3c64xx.c
@@ -9,7 +9,7 @@
 
 #include <linux/kernel.h>
 #include <linux/types.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 
 struct platform_device; /* don't need the contents */
 
diff --git a/arch/arm/mach-s3c/setup-keypad-s3c64xx.c b/arch/arm/mach-s3c/setup-keypad-s3c64xx.c
index 8463ad37c6ab..2e1367878fb1 100644
--- a/arch/arm/mach-s3c/setup-keypad-s3c64xx.c
+++ b/arch/arm/mach-s3c/setup-keypad-s3c64xx.c
@@ -5,7 +5,7 @@
 //
 // GPIO configuration for S3C64XX KeyPad device
 
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include "gpio-cfg.h"
 #include "keypad.h"
 #include "gpio-samsung.h"
diff --git a/arch/arm/mach-s3c/setup-sdhci-gpio-s3c64xx.c b/arch/arm/mach-s3c/setup-sdhci-gpio-s3c64xx.c
index 646ff949acd5..728b66f80493 100644
--- a/arch/arm/mach-s3c/setup-sdhci-gpio-s3c64xx.c
+++ b/arch/arm/mach-s3c/setup-sdhci-gpio-s3c64xx.c
@@ -11,7 +11,7 @@
 #include <linux/interrupt.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 
 #include "gpio-cfg.h"
 #include "sdhci.h"
diff --git a/arch/arm/mach-s3c/setup-spi-s3c64xx.c b/arch/arm/mach-s3c/setup-spi-s3c64xx.c
index 497aff71c29c..8d15b13ed7d5 100644
--- a/arch/arm/mach-s3c/setup-spi-s3c64xx.c
+++ b/arch/arm/mach-s3c/setup-spi-s3c64xx.c
@@ -3,7 +3,7 @@
 // Copyright (C) 2011 Samsung Electronics Ltd.
 //		http://www.samsung.com/
 
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/platform_data/spi-s3c64xx.h>
 #include "gpio-cfg.h"
 #include "gpio-samsung.h"
diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
index 466d755d5702..af9c68b2093e 100644
--- a/arch/arm/mach-sa1100/collie.c
+++ b/arch/arm/mach-sa1100/collie.c
@@ -29,7 +29,7 @@
 #include <linux/timer.h>
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio/machine.h>
 #include <linux/power/gpio-charger.h>
 
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index 99ff55e8131d..a995625ab1a0 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -6,7 +6,7 @@
  *
  * Code common to all SA11x0 machines.
  */
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/gpio/machine.h>
 #include <linux/module.h>
 #include <linux/kernel.h>
diff --git a/arch/arm/mach-sa1100/h3600.c b/arch/arm/mach-sa1100/h3600.c
index 1cfc0b1fa41c..59e9251a138e 100644
--- a/arch/arm/mach-sa1100/h3600.c
+++ b/arch/arm/mach-sa1100/h3600.c
@@ -8,7 +8,7 @@
 
 #include <linux/init.h>
 #include <linux/kernel.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 
 #include <video/sa1100fb.h>
 
diff --git a/arch/arm/mach-sa1100/h3xxx.c b/arch/arm/mach-sa1100/h3xxx.c
index d685f03f51f3..b8fc1953db9f 100644
--- a/arch/arm/mach-sa1100/h3xxx.c
+++ b/arch/arm/mach-sa1100/h3xxx.c
@@ -8,7 +8,7 @@
 
 #include <linux/kernel.h>
 #include <linux/gpio/machine.h>
-#include <linux/gpio.h>
+#include <linux/gpio/legacy.h>
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
 #include <linux/mtd/mtd.h>
diff --git a/arch/arm/plat-orion/mpp.c b/arch/arm/plat-orion/mpp.c
index 8a6880d528b6..673ecedc721d 100644
--- a/arch/arm/plat-orion/mpp.c
+++ b/arch/arm/plat-orion/mpp.c
@@ -12,7 +12,7 @@
 #include <linux/init.h>
 #include <linux/mbus.h>
 #include <linux/io.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <plat/orion-gpio.h>
 #include <plat/mpp.h>
 
-- 
2.39.5


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH v2 00/10] treewide: replace linux/gpio.h
From: Arnd Bergmann @ 2026-07-10 21:19 UTC (permalink / raw)
  To: linux-gpio, Linus Walleij, Bartosz Golaszewski
  Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
	Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
	Greg Ungerer, Thomas Bogendoerfer, Hauke Mehrtens,
	Rafał Miłecki, Yoshinori Sato,
	John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
	linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
	linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
	linux-phy, linux-rockchip, linux-sound

From: Arnd Bergmann <arnd@arndb.de>

The linux/gpio.h header used to be the global definition for the gpio
interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
130 of those remain, so this series cleans out the rest.

In each subsystem, we can replace the header either with
linux/gpio/consumer.h for users of the modern gpio descriptor interface,
or linux/gpio/legacy.h for the few remaining users of the old number
based interface.

All patches in this series can get applied independently, so my
preference would be for each subsystem maintainer to apply these
directly, with the rest going into the gpio tree at some point.

I've uploaded this to 

   https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/ config-gpio-legacy-for-7.3

      Arnd


v2: dropped two already applied patches,
    removed duplicate includes,
    dropped final patch to remove linux/gpio.h as it now depends
    on patches in linux-next

 arch/arm/mach-davinci/da850.c                       | 2 +-
 arch/arm/mach-dove/mpp.c                            | 2 +-
 arch/arm/mach-mv78xx0/buffalo-wxl-setup.c           | 2 +-
 arch/arm/mach-mv78xx0/irq.c                         | 2 +-
 arch/arm/mach-mv78xx0/mpp.c                         | 2 +-
 arch/arm/mach-mvebu/pm.c                            | 2 +-
 arch/arm/mach-mxs/mach-mxs.c                        | 2 +-
 arch/arm/mach-orion5x/board-d2net.c                 | 2 +-
 arch/arm/mach-orion5x/board-rd88f5182.c             | 2 +-
 arch/arm/mach-orion5x/dns323-setup.c                | 2 +-
 arch/arm/mach-orion5x/irq.c                         | 2 +-
 arch/arm/mach-orion5x/kurobox_pro-setup.c           | 2 +-
 arch/arm/mach-orion5x/mv2120-setup.c                | 2 +-
 arch/arm/mach-orion5x/net2big-setup.c               | 2 +-
 arch/arm/mach-orion5x/terastation_pro2-setup.c      | 2 +-
 arch/arm/mach-orion5x/ts209-setup.c                 | 2 +-
 arch/arm/mach-orion5x/ts409-setup.c                 | 2 +-
 arch/arm/mach-pxa/am200epd.c                        | 2 +-
 arch/arm/mach-pxa/am300epd.c                        | 2 +-
 arch/arm/mach-pxa/generic.c                         | 2 +-
 arch/arm/mach-pxa/gumstix.c                         | 2 +-
 arch/arm/mach-pxa/mfp-pxa2xx.c                      | 2 +-
 arch/arm/mach-pxa/pxa25x.c                          | 2 +-
 arch/arm/mach-pxa/pxa27x.c                          | 2 +-
 arch/arm/mach-pxa/reset.c                           | 2 +-
 arch/arm/mach-pxa/sharpsl_pm.c                      | 2 +-
 arch/arm/mach-pxa/spitz.c                           | 2 +-
 arch/arm/mach-pxa/spitz_pm.c                        | 2 +-
 arch/arm/mach-s3c/dev-audio-s3c64xx.c               | 2 +-
 arch/arm/mach-s3c/devs.c                            | 2 +-
 arch/arm/mach-s3c/mach-crag6410.c                   | 2 +-
 arch/arm/mach-s3c/pm-gpio.c                         | 2 +-
 arch/arm/mach-s3c/pm-s3c64xx.c                      | 2 +-
 arch/arm/mach-s3c/setup-fb-24bpp-s3c64xx.c          | 2 +-
 arch/arm/mach-s3c/setup-i2c0-s3c64xx.c              | 2 +-
 arch/arm/mach-s3c/setup-i2c1-s3c64xx.c              | 2 +-
 arch/arm/mach-s3c/setup-keypad-s3c64xx.c            | 2 +-
 arch/arm/mach-s3c/setup-sdhci-gpio-s3c64xx.c        | 2 +-
 arch/arm/mach-s3c/setup-spi-s3c64xx.c               | 2 +-
 arch/arm/mach-sa1100/collie.c                       | 2 +-
 arch/arm/mach-sa1100/generic.c                      | 2 +-
 arch/arm/mach-sa1100/h3600.c                        | 2 +-
 arch/arm/mach-sa1100/h3xxx.c                        | 2 +-
 arch/arm/plat-orion/mpp.c                           | 2 +-
 arch/m68k/coldfire/device.c                         | 2 +-
 arch/m68k/include/asm/mcfgpio.h                     | 2 +-
 arch/mips/alchemy/board-xxs1500.c                   | 2 +-
 arch/mips/alchemy/devboards/db1000.c                | 2 +-
 arch/mips/alchemy/devboards/db1200.c                | 2 +-
 arch/mips/alchemy/devboards/db1550.c                | 2 +-
 arch/mips/bcm47xx/workarounds.c                     | 2 +-
 arch/mips/bcm63xx/boards/board_bcm963xx.c           | 1 +
 arch/mips/include/asm/mach-bcm63xx/board_bcm963xx.h | 2 +-
 arch/mips/txx9/rbtx4927/setup.c                     | 2 +-
 arch/sh/boards/board-magicpanelr2.c                 | 2 +-
 arch/sh/boards/board-sh7757lcr.c                    | 2 +-
 arch/sh/boards/board-urquell.c                      | 2 +-
 arch/sh/boards/mach-ap325rxa/setup.c                | 2 +-
 arch/sh/boards/mach-ecovec24/setup.c                | 2 +-
 arch/sh/boards/mach-highlander/pinmux-r7785rp.c     | 2 +-
 arch/sh/boards/mach-kfr2r09/lcd_wqvga.c             | 2 +-
 arch/sh/boards/mach-kfr2r09/setup.c                 | 2 +-
 arch/sh/boards/mach-migor/lcd_qvga.c                | 2 +-
 arch/sh/boards/mach-migor/setup.c                   | 2 +-
 arch/sh/boards/mach-rsk/devices-rsk7203.c           | 2 +-
 arch/sh/boards/mach-rsk/devices-rsk7269.c           | 1 -
 arch/sh/boards/mach-se/7724/setup.c                 | 2 +-
 arch/sh/include/mach-common/mach/magicpanelr2.h     | 2 --
 arch/sh/kernel/cpu/sh4a/setup-shx3.c                | 2 +-
 drivers/gpib/gpio/gpib_bitbang.c                    | 1 -
 drivers/input/keyboard/matrix_keypad.c              | 1 -
 drivers/mfd/aat2870-core.c                          | 2 +-
 drivers/mfd/arizona-irq.c                           | 2 +-
 drivers/mfd/lp3943.c                                | 2 +-
 drivers/mfd/sm501.c                                 | 2 +-
 drivers/mfd/tps6105x.c                              | 2 +-
 drivers/mfd/tps65911-comparator.c                   | 2 +-
 drivers/mfd/wm8994-irq.c                            | 2 +-
 drivers/pcmcia/bcm63xx_pcmcia.c                     | 2 +-
 drivers/pcmcia/db1xxx_ss.c                          | 2 +-
 drivers/pcmcia/sa1100_h3600.c                       | 2 +-
 drivers/pcmcia/soc_common.c                         | 2 +-
 drivers/pcmcia/xxs1500_ss.c                         | 2 +-
 drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c           | 1 -
 drivers/phy/rockchip/phy-rockchip-usbdp.c           | 2 +-
 drivers/phy/ti/phy-j721e-wiz.c                      | 1 -
 include/linux/mfd/lp3943.h                          | 2 +-
 include/linux/mfd/ti-lmu.h                          | 1 -
 include/linux/mfd/tps65910.h                        | 2 +-
 include/linux/mfd/ucb1x00.h                         | 2 +-
 sound/soc/codecs/cs42l84.c                          | 1 -
 sound/soc/codecs/cx2072x.c                          | 2 +-
 sound/soc/codecs/dmic.c                             | 1 -
 93 files changed, 84 insertions(+), 93 deletions(-)

-- 
2.39.5

Cc: Bartosz Golaszewski <brgl@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Gregory Clement <gregory.clement@bootlin.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Greg Ungerer <gerg@linux-m68k.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Linus Walleij <linusw@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: patches@opensource.cirrus.com
Cc: linux-m68k@lists.linux-m68k.org
Cc: linux-mips@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-sunxi@lists.linux.dev
Cc: linux-phy@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-sound@vger.kernel.org

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 30/36] usb: dwc3: core: support PHY reset notifications
From: sashiko-bot @ 2026-07-10 21:20 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: devicetree, olteanv, linux-phy, vkoul, robh, neil.armstrong,
	conor+dt
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-30-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The global `phy_reset_count` atomic variable is incorrectly used to track the reset state of multiple independent USB3 ports, and is read non-atomically, leading to cross-port state corruption, TOCTOU race conditions, and unbalanced PM usage counters.
- [High] The PHY reset workaround is completely bypassed if Runtime PM is disabled in the kernel configuration or via sysfs, causing the very hardware corruption the patch intends to fix.
--

--- Patch [30]: [PATCH v12 30/36] usb: dwc3: core: support PHY reset notifications ---
commit 9e1e85d93d9ab9e98188f6d4d342fd431f334513
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

usb: dwc3: core: support PHY reset notifications

This commit handles external PHY reset notifications on Rockchip platforms
by asserting PHYSOFTRST before the PHY disables and deasserting it when the
PHY returns. This prevents the DWC3 IP from corrupting the PHY's internal
state and failing to lock PLL clocks.

> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 517aa7f1486da..4d0b4c1c73f11 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c

[ ... ]

> @@ -880,6 +881,90 @@ static int dwc3_phy_init(struct dwc3 *dwc)
>  	return ret;
>  }
>  
> +static int dwc3_usb3_phy_notify(struct notifier_block *nb,
> +				unsigned long action, void *data)
> +{
> +	struct dwc3_phy_nb *pnb = container_of(nb, struct dwc3_phy_nb, nb);
> +	struct dwc3 *dwc = pnb->dwc;
> +	int port = pnb->port_index;
> +	unsigned long flags;
> +	u32 reg;
> +
> +	switch (action) {
> +	case PHY_NOTIFY_PRE_RESET:
> +		/*
> +		 * If already suspended, the resume path will reinit GUSB3PIPECTL
> +		 * via dwc3_core_init(). A forced resume is not possible as that
> +		 * would call phy_init() resulting in a deadlock. Due to the
> +		 * phy_init() in the resume path there is also no need to block
> +		 * async RPM resume on our side, since the PHY synchronizes it
> +		 * for us.
> +		 */
> +		if (pm_runtime_get_if_active(dwc->dev) <= 0)
> +			return NOTIFY_OK;

[Severity: High]
If CONFIG_PM is disabled, or runtime PM is disabled for this device via
sysfs, pm_runtime_get_if_active() returns -EINVAL.

Will this check treat the -EINVAL error code as suspended and bypass the
workaround completely, even though the DWC3 IP is actively running?

Also, if the check is later modified to proceed on -EINVAL, would the
POST_RESET path underflow the PM counter? pm_runtime_get_if_active()
doesn't increment the usage count when returning -EINVAL, but POST_RESET
unconditionally calls pm_runtime_put_autosuspend().

> +
> +		atomic_inc(&dwc->phy_reset_count);
> +
> +		/*
> +		 * Assert USB3 PHY soft reset within DWC3 before the external
> +		 * PHY resets. This disconnects the PIPE interface, preventing
> +		 * the DWC3 from interfering with PHY reinitialization and
> +		 * avoiding LCPLL lock failures.
> +		 */
> +		spin_lock_irqsave(&dwc->lock, flags);
> +		reg = dwc3_readl(dwc, DWC3_GUSB3PIPECTL(port));
> +		reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
> +		dwc3_writel(dwc, DWC3_GUSB3PIPECTL(port), reg);
> +		spin_unlock_irqrestore(&dwc->lock, flags);
> +		break;
> +
> +	case PHY_NOTIFY_POST_RESET:
> +		if (!atomic_read(&dwc->phy_reset_count))
> +			return NOTIFY_OK;

[Severity: High]
Can this global count cause state corruption on multi-port systems if
notifications interleave with PM state changes?

For example, if Port 0 starts a reset while suspended, it skips the PRE_RESET
workaround and doesn't increment phy_reset_count.

If the controller resumes and Port 1 starts a reset, it increments the
global phy_reset_count to 1.

When Port 0 finishes its reset and hits POST_RESET, it sees phy_reset_count
as 1. Won't it erroneously clear PHYSOFTRST for Port 0 (which was never set),
call pm_runtime_put_autosuspend() unbalanced, and decrement the count to 0?

If Port 1 then finishes its reset, won't it see phy_reset_count at 0 and
skip its cleanup, leaving Port 1 permanently stuck in PHYSOFTRST?

> +		/*
> +		 * Deassert PHY soft reset to reconnect the PIPE interface
> +		 * after PHY reinitialization.
> +		 */
> +		spin_lock_irqsave(&dwc->lock, flags);
> +		reg = dwc3_readl(dwc, DWC3_GUSB3PIPECTL(port));
> +		reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
> +		dwc3_writel(dwc, DWC3_GUSB3PIPECTL(port), reg);
> +		spin_unlock_irqrestore(&dwc->lock, flags);
> +
> +		pm_runtime_put_autosuspend(dwc->dev);
> +		atomic_dec(&dwc->phy_reset_count);
> +		break;
> +	}
> +
> +	return NOTIFY_OK;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=30

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 22/36] phy: rockchip: usbdp: Use guard functions for mutex
From: sashiko-bot @ 2026-07-10 21:18 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: linux-phy, neil.armstrong, robh, conor+dt, devicetree, vkoul,
	olteanv
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-22-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but `rk_udphy_dp_phy_configure` accesses shared PHY state without holding `udphy->mutex`.
--

--- Patch [22]: [PATCH v12 22/36] phy: rockchip: usbdp: Use guard functions for mutex ---
commit f4715c1e8ea1ff2794633378980dbaf55d276684
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Use guard functions for mutex

Convert the driver to use guard functions for mutex handling as
a small cleanup. There is a small functional change in the DP PHY
power up function, which no longer sleeps if the internal powerup
code returns an error.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 0399cbf96e195..8c165bcab7968 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c

[ ... ]

> @@ -1255,35 +1254,30 @@ static const struct phy_ops rk_udphy_dp_phy_ops = {
>  static int rk_udphy_usb3_phy_init(struct phy *phy)
>  {

[Severity: High]
This isn't a bug introduced by this patch, but rk_udphy_dp_phy_configure()
accesses shared PHY state without holding udphy->mutex.

Could this create a data race with Type-C orientation changes?

The function iterates over the udphy->dp_lane_sel array and writes to the
hardware PHY registers based on the mapped lanes:

    for (i = 0; i < udphy->lanes; i++) {
        lane = udphy->dp_lane_sel[i];
        switch (udphy->link_rate) {
        ...

Because phy_configure is called by the DRM bridge without udphy->mutex held,
and concurrent Type-C orientation switch events handled in
rk_udphy_orien_sw_set() hold udphy->mutex while modifying udphy->dp_lane_sel
and udphy->lane_mux_sel, they might run at the same time.

If a cable is flipped exactly during a display bring-up, could this cause a
torn read that applies settings to the same lane twice while omitting others,
leaving the hardware incorrectly configured and DP alt mode output broken?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=22

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 21/36] phy: rockchip: usbdp: Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB
From: sashiko-bot @ 2026-07-10 21:18 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: vkoul, linux-phy, robh, olteanv, devicetree, conor+dt,
	neil.armstrong
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-21-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete handling of TYPEC_STATE_USB and TYPEC_STATE_SAFE leaves the PHY stuck in DP mode, breaking USB3 recovery.
--

--- Patch [21]: [PATCH v12 21/36] phy: rockchip: usbdp: Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB ---
commit 92ff6f90dbbc1f6a2eb9a05f21ddd0b835b0116d
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Subject: phy: rockchip: usbdp: Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB

This commit modifies the typec mux handler to process TYPEC_STATE_SAFE
and TYPEC_STATE_USB modes. It removes the condition that ignored mux
events not involving DP AltMode to allow muxing to be updated when
exiting DP AltMode.

Closes: https://sashiko.dev/#/message/20260619155020.CC7361F000E9%40smtp.kernel.org

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 4e54020d17551..0399cbf96e195 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1293,17 +1293,26 @@ static const struct phy_ops rk_udphy_usb3_phy_ops = {
>  	.owner		= THIS_MODULE,
>  };
>  
> +static bool rk_udphy_is_supported_mode(struct typec_mux_state *state)
> +{
> +	/* Handle Safe State and USB State */
> +	if (state->mode < TYPEC_STATE_MODAL)
> +		return true;
> +
> +	/* Handle DP AltMode */
> +	if (state->alt && state->alt->svid == USB_TYPEC_DP_SID)
> +		return true;
> +
> +	return false;
> +}
> +
>  static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
>  				  struct typec_mux_state *state)
>  {
>  	struct rk_udphy *udphy = typec_mux_get_drvdata(mux);
>  
> -	/*
> -	 * Ignore mux events not involving DP AltMode, because
> -	 * the mode field is being reused, e.g. state->mode == 4
> -	 * could be either TYPEC_MODE_USB4 or TYPEC_DP_STATE_C.
> -	 */
> -	if (!state->alt || state->alt->svid != USB_TYPEC_DP_SID)
> +	/* Ignore mux events not involving USB or DP */
> +	if (!rk_udphy_is_supported_mode(state))
>  		return 0;
>  
>  	mutex_lock(&udphy->mutex);

[Severity: High]
This is a pre-existing issue, but since this patch explicitly aims to
fix muxing when exiting DP AltMode, is a hardware update missing here?

When exiting DP AltMode, TCPM sends a TYPEC_STATE_USB or TYPEC_STATE_SAFE
mux event. rk_udphy_typec_mux_set() updates the software state by calling
rk_udphy_set_typec_state() which sets udphy->phy_needs_reinit = true.

However, because the USB controller (DWC3) is already powered on, it
doesn't call phy_power_on() again. The DP controller calls phy_power_off()
when disabled, but rk_udphy_dp_phy_power_off() only clears the DP status
bit and doesn't re-evaluate phy_needs_reinit.

Because of this, rk_udphy_init() is never called and the hardware
CMN_LANE_MUX_AND_EN_OFFSET is never reprogrammed. Does this leave the PHY
stuck in 4-lane DP mode and break USB3 recovery?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=21

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 23/36] phy: rockchip: usbdp: Clear USB status on PHY exit
From: sashiko-bot @ 2026-07-10 21:17 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: robh, conor+dt, olteanv, linux-phy, devicetree, vkoul,
	neil.armstrong
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-23-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Clearing the USB status flag without checking if the PHY should be completely disabled leads to a clock reference and PHY power leak.

Pre-existing issues:
- [High] The `rk_udphy_dp_phy_configure` function accesses and modifies shared PHY driver state without holding the proper subsystem lock (`udphy->mutex`).
--

--- Patch [23]: [PATCH v12 23/36] phy: rockchip: usbdp: Clear USB status on PHY exit ---
commit 87780d47b4da4078adb1684ca9ebb6fc0529d86c
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Clear USB status on PHY exit
    
Ensure the USB status flag is cleared when the USB3 PHY is
exited while the system is in DP-only mode.

Closes: https://sashiko.dev/#/message/20260625-rockchip-usbdp-cleanup-v7-24-38eb3cf654fd%40collabora.com

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 8c165bcab7968..a742bde7155be 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1273,8 +1273,10 @@ static int rk_udphy_usb3_phy_exit(struct phy *phy)
>  	guard(mutex)(&udphy->mutex);
>  
>  	/* DP only or high-speed */
> -	if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs)
> +	if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs) {
> +		udphy->status &= ~UDPHY_MODE_USB;
>  		return 0;
> +	}

[Severity: High]
Does this early return bypass rk_udphy_disable() if the PHY should be completely
disabled?

If the DP side is not active, udphy->status drops to UDPHY_MODE_NONE (0) here.
Because the function returns early, it bypasses rk_udphy_power_off() and fails
to call rk_udphy_disable(udphy).

Will this leave the PHY hardware permanently powered on and the clock counts
unbalanced?

The next time the PHY is powered on, status == 0 would cause another call to
rk_udphy_setup(), which calls clk_bulk_prepare_enable() again, causing a
cumulative clock reference leak.

>  
>  	rk_udphy_power_off(udphy, UDPHY_MODE_USB);

[ ... ]

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_configure() {
    ...
    struct rk_udphy *udphy = phy_get_drvdata(phy);
    struct phy_configure_opts_dp *dp = &opts->dp;
    u32 i, val, lane;
    int ret;

    if (dp->set_rate) {
    ...
}

[Severity: High]
This is a pre-existing issue, but does rk_udphy_dp_phy_configure() access and
modify shared PHY driver state without holding the proper subsystem lock?

The PHY core framework calls .configure which reads udphy->dp_lanes and
udphy->dp_lane_sel, and writes udphy->lanes without acquiring udphy->mutex.

Concurrently, a Type-C event handled by rk_udphy_typec_mux_set() or
rk_udphy_orien_sw_set() might alter those shared fields while holding the mutex.

Could this race condition lead to the hardware being programmed with
inconsistent lane mappings during normal Type-C hotplug and DP modesetting?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=23

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 27/36] phy: rockchip: usbdp: Handle rk_udphy_reset_deassert errors
From: sashiko-bot @ 2026-07-10 21:17 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: robh, olteanv, linux-phy, devicetree, vkoul, conor+dt,
	neil.armstrong
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-27-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] If PHY re-initialization fails during a mode change, the U3 port is left permanently disabled and in reset, but the software state incorrectly remains active.
--

--- Patch [27]: [PATCH v12 27/36] phy: rockchip: usbdp: Handle rk_udphy_reset_deassert errors ---
commit 00e32198a00a3780b193e546b8f16d2218cefb74
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Handle rk_udphy_reset_deassert errors

This commit modifies the initialization sequence to handle errors returned
by reset deassertion, avoiding a theoretical SError.

Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/message/20260626211151.2332F1F000E9%40smtp.kernel.org

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -803,8 +803,12 @@ static int rk_udphy_init(struct rk_udphy *udphy)
>  	/* Step 1: power on pma and deassert apb rstn */
>  	rk_udphy_grfreg_write(udphy->udphygrf, &cfg->grfcfg.low_pwrn, true);
>  
> -	rk_udphy_reset_deassert(udphy, "pma_apb");
> -	rk_udphy_reset_deassert(udphy, "pcs_apb");
> +	ret = rk_udphy_reset_deassert(udphy, "pma_apb");
> +	if (ret)
> +		goto assert_resets;

[Severity: Medium]
This is a pre-existing issue, but returning an error here propagates up to
rk_udphy_power_on(). Does this leave the U3 port in a permanently disabled
state?

When USB3 is active and a new mode is enabled, rk_udphy_power_on() triggers
re-initialization. It disables the U3 port and calls rk_udphy_init(). If
rk_udphy_init() fails and returns an error here, the caller propagates it
immediately:

rk_udphy_power_on() {
        ...
        ret = rk_udphy_init(udphy);
        if (ret)
                return ret;

        if (udphy->mode & UDPHY_MODE_USB)
                rk_udphy_u3_port_disable(udphy, false);
        ...
}

If this path is taken, the U3 port is left permanently disabled and in reset,
but the software state (udphy->status) incorrectly remains active. The USB3
controller is unaware that the PHY has been forced into reset. 

Could this result in a silently dropped USB3 connection, potentially causing
I/O errors for active storage devices? 

While a previous patch in the series mitigates the SError by safely routing
the PIPE clock to UTMI, the state inconsistency and dead USB connection seem
to remain.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=27

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 20/36] phy: rockchip: usbdp: Factor out lane_mux_sel setup
From: sashiko-bot @ 2026-07-10 21:16 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: olteanv, linux-phy, robh, conor+dt, vkoul, neil.armstrong,
	devicetree
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-20-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Type-C states TYPEC_STATE_SAFE and TYPEC_STATE_USB incorrectly fall through to TYPEC_DP_STATE_D configuration, leaving the PHY in UDPHY_MODE_DP_USB mode.
- [High] The `rk_udphy_dp_phy_configure()` callback accesses and modifies shared PHY state without holding the `udphy->mutex`, leading to a race condition with concurrent Type-C events.
--

--- Patch [20]: [PATCH v12 20/36] phy: rockchip: usbdp: Factor out lane_mux_sel setup ---
commit 3727c9684937e2c6c25ea6548ada704fecefa99a
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Factor out lane_mux_sel setup
    
Avoid describing the USB+DP lane_mux_sel logic twice by introducing
a helper function to reduce code duplication.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 4b454798c4ed4..4e54020d17551 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -582,6 +582,42 @@ static void rk_udphy_mode_set(struct rk_udphy *udphy, u8 mode)
>  	udphy->mode = mode;
>  }
>  
> +static void rk_udphy_set_typec_state(struct rk_udphy *udphy, unsigned long state)
> +{
> +	u8 mode;
> +
> +	switch (state) {
> +	case TYPEC_DP_STATE_C:
> +	case TYPEC_DP_STATE_E:
> +		udphy->lane_mux_sel[0] = PHY_LANE_MUX_DP;
> +		udphy->lane_mux_sel[1] = PHY_LANE_MUX_DP;
> +		udphy->lane_mux_sel[2] = PHY_LANE_MUX_DP;
> +		udphy->lane_mux_sel[3] = PHY_LANE_MUX_DP;
> +		mode = UDPHY_MODE_DP;
> +		udphy->dp_lanes = 4;
> +		break;
> +
> +	case TYPEC_DP_STATE_D:
> +	default:

[Severity: High]
This is a pre-existing issue, but does this default case correctly handle
TYPEC_STATE_SAFE and TYPEC_STATE_USB?

When the Type-C subsystem exits DP AltMode or transitions to a safe state,
the mux callback rk_udphy_typec_mux_set() receives state->mode set to
TYPEC_STATE_SAFE (0).

Because rk_udphy_set_typec_state() does not explicitly handle 0, it falls
into the default case here, incorrectly setting udphy->dp_lanes = 2 and
mode = UDPHY_MODE_DP_USB.

Should TYPEC_STATE_SAFE and TYPEC_STATE_USB explicitly disable the DP lanes
instead of defaulting to DP_USB mode?

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but is there a missing lock in
rk_udphy_dp_phy_configure() that could race with Type-C events?

Looking at rk_udphy_dp_phy_configure() in
drivers/phy/rockchip/phy-rockchip-usbdp.c:

    static int rk_udphy_dp_phy_configure(struct phy *phy,
                                         union phy_configure_opts *opts)
    {
        struct rk_udphy *udphy = phy_get_drvdata(phy);
        struct phy_configure_opts_dp *dp = &opts->dp;
        u32 i, val, lane;
        int ret;
    
        if (dp->set_rate) {

It appears to access and modify shared PHY state without holding udphy->mutex.

Concurrently, a Type-C event such as rk_udphy_typec_mux_set() running in a
workqueue modifies udphy->dp_lane_sel and udphy->dp_lanes while holding
udphy->mutex.

Could rk_udphy_dp_phy_configure() read inconsistent values and cause
out-of-bounds register writes if it gets an invalid index from dp_lane_sel?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=20

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 19/36] phy: rockchip: usbdp: Re-init the PHY on orientation change
From: sashiko-bot @ 2026-07-10 21:15 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: robh, vkoul, conor+dt, olteanv, linux-phy, neil.armstrong,
	devicetree
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-19-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Deferred hardware initialization via `phy_needs_reinit` fixes DisplayPort but leaves USB-only replugs broken if the USB PHY remains powered on.
- [Medium] The function `rk_udphy_dp_phy_configure` accesses shared states locklessly, leading to a data race with concurrent orientation switches.
--

--- Patch [19]: [PATCH v12 19/36] phy: rockchip: usbdp: Re-init the PHY on orientation change ---
commit c45d3419a6f4b9509b416ffd7965a918e7fad8e4
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Re-init the PHY on orientation change

Changing the cable orientation reconfigures the lane muxing, which requires
re-initializing the PHY. The patch introduces a flag to trigger PHY
re-initialization upon orientation change.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index e44d19c9d1193..4b454798c4ed4 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -620,6 +620,7 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
>  				 enum typec_orientation orien)
>  {
>  	struct rk_udphy *udphy = typec_switch_get_drvdata(sw);
> +	bool flipped = orien == TYPEC_ORIENTATION_REVERSE;
>  
>  	mutex_lock(&udphy->mutex);
>  

[ ... ]

> @@ -631,7 +632,10 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
>  		goto unlock_ret;
>  	}
>  
> -	udphy->flip = orien == TYPEC_ORIENTATION_REVERSE;
> +	if (udphy->flip != flipped)
> +		udphy->phy_needs_reinit = true;

[Severity: High]
This is a pre-existing issue, but does this deferred initialization handle
USB-only replugs correctly if the USB PHY remains powered on?

When a user unplugs and replugs a Type-C cable, this sets
udphy->phy_needs_reinit = true. However, in configurations where the DWC3
controller remains active (e.g., fixed host mode) or during rapid replugs,
the USB controller doesn't restart and thus never calls phy_init() again.

Because rk_udphy_usb3_phy_ops only implements .init and has no .power_on
callback, rk_udphy_power_on() is never invoked to process the deferred
initialization flag:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_power_on() {
    ...
	} else if (udphy->phy_needs_reinit) {
		...
		ret = rk_udphy_init(udphy);
    ...
}

Will this cause the USB SuperSpeed connection to fail to train if the
cable is inserted in reverse orientation?

> +
> +	udphy->flip = flipped;
>  	rk_udphy_set_typec_default_mapping(udphy);

[Severity: Medium]
This is a pre-existing issue, but can this lead to a data race with concurrent
orientation switches?

While rk_udphy_orien_sw_set() acquires udphy->mutex and updates the shared lane
and mux selections here via rk_udphy_set_typec_default_mapping(),
rk_udphy_dp_phy_configure() iterates over and accesses the shared lane state
locklessly:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_configure() {
    ...
		for (i = 0; i < udphy->lanes; i++) {
			lane = udphy->dp_lane_sel[i];
    ...
						   udphy->lane_mux_sel[lane]));
    ...
}

Could this cause rk_udphy_dp_phy_configure() to read partially updated arrays
if the DP controller triggers link training concurrently with an orientation
change?

>  	rk_udphy_usb_bvalid_enable(udphy, true);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=19

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 02/36] phy: rockchip: usbdp: Update mode_change after error handling
From: sashiko-bot @ 2026-07-10 21:15 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: conor+dt, olteanv, neil.armstrong, linux-phy, vkoul, robh,
	devicetree
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-2-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 8 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Asynchronous PHY mode changes while USB is active cause fatal SErrors (kernel panics) because PHY clocks are disabled without notifying the active DWC3 controller.
- [High] `rk_udphy_power_on()` incorrectly drops active consumer tracking in `udphy->status` during a mode change, potentially causing the PHY to be disabled while still in use.
- [High] The U3 (USB3) port is not re-enabled when transitioning from DP-only mode to DP+USB mode, causing USB3 to remain broken.
- [High] `rk_udphy_clk_init()` shadows the error code from `devm_clk_bulk_get_all()`, breaking deferred probing.
- [High] The driver leaks clock enable counts and hardware reset states on probe error paths if the initial hardware status is active.
- [High] The `rk_udphy_dp_phy_configure` function accesses shared arrays and modifies hardware registers without acquiring `udphy->mutex`, leading to race conditions.
- [High] Non-DP Alternate Mode events corrupt the PHY lane mux configuration, silently breaking USB3 functionality.
- [High] DisplayPort HPD (Hot Plug Detect) events received before the DP PHY is initialized are permanently lost, preventing display detection.
--

--- Patch [2]: [PATCH v12 02/36] phy: rockchip: usbdp: Update mode_change after error handling ---
commit 44a3e651748d53a497e7bb21061bf3cb86d67fbd
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Update mode_change after error handling

If rk_udphy_init() or rk_udphy_setup() fails, the reinit will not be
tried again. Fix this by only updating the variable after all potential
errors have been handled.

Link: https://lore.kernel.org/linux-phy/20260612163835.8D5471F000E9@smtp.kernel.org/

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index fba35510d88ce..a5ffdf7a6e76b 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1000,15 +1000,14 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
>  	}
>  
>  	if (udphy->status == UDPHY_MODE_NONE) {
> -		udphy->mode_change = false;
>  		ret = rk_udphy_setup(udphy);
>  		if (ret)
>  			return ret;
>  
>  		if (udphy->mode & UDPHY_MODE_USB)
>  			rk_udphy_u3_port_disable(udphy, false);
> -	} else if (udphy->mode_change) {
>  		udphy->mode_change = false;
> +	} else if (udphy->mode_change) {

[Severity: High]
This isn't a bug introduced by this patch, but does this mode change block
neglect to conditionally re-enable the U3 port for USB modes?

If the PHY is active in DP-only mode and transitions to DP+USB, this
else if (udphy->mode_change) block is taken. Unlike the initialization
block, it fails to evaluate if (udphy->mode & UDPHY_MODE_USB) and call
rk_udphy_u3_port_disable(udphy, false).

Does this cause USB 3.0 to fail to initialize when plugged into an already
active DisplayPort?

>  		udphy->status = UDPHY_MODE_NONE;

[Severity: High]
This is a pre-existing issue, but does this forcefully erase the tracking
of all currently active consumers without transferring them to the new
state?

If DP is active, udphy->status holds UDPHY_MODE_DP. When a USB device is
plugged in, rk_udphy_power_on is called for UDPHY_MODE_USB with mode_change
true. The code clears udphy->status to UDPHY_MODE_NONE here.

Does this permanently lose the previously active UDPHY_MODE_DP bit? When
USB is later unplugged, power_off clears the USB bit, dropping status to 0,
which might prematurely disable the PHY despite DP still needing it.

>  		if (udphy->mode == UDPHY_MODE_DP)
>  			rk_udphy_u3_port_disable(udphy, true);

[Severity: Critical]
This isn't a bug introduced by this patch, but does the asynchronous
disabling of PHY bulk clocks around here cause fatal SErrors?

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_power_on() {
    ...
    } else if (udphy->mode_change) {
        udphy->status = UDPHY_MODE_NONE;
        if (udphy->mode == UDPHY_MODE_DP)
            rk_udphy_u3_port_disable(udphy, true);
        rk_udphy_disable(udphy);
    ...
}

If DWC3 is actively transferring USB data and a DisplayPort Alternate Mode
event arrives, rk_udphy_typec_mux_set triggers a mode change. The code
unconditionally calls rk_udphy_disable(udphy) which abruptly severs the
PHY clocks.

Since the DWC3 driver isn't notified, could its next register access hang
the system bus?

[ ... ]

> @@ -1017,6 +1016,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
>  		ret = rk_udphy_setup(udphy);
>  		if (ret)
>  			return ret;
> +		udphy->mode_change = false;
>  	}
>  
>  	udphy->status |= mode;

[Severity: High]
This is a pre-existing issue, but does setting the status bit here only
register the consumer that triggered the function call, leaving previous
consumers untracked?


There are a few other pre-existing issues in this file that might be worth
looking into:

[Severity: High]
This isn't a bug introduced by this patch, but does this logic shadow the
error code from devm_clk_bulk_get_all and break deferred probing?

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_clk_init() {
    ...
    if (udphy->num_clks < 1)
        return -ENODEV;
    ...
}

If devm_clk_bulk_get_all returns -EPROBE_DEFER when clock providers aren't
ready yet, this explicitly checks if udphy->num_clks < 1 and returns a
hardcoded -ENODEV. Will this cause the PHY driver to fail to probe
permanently if clocks are not immediately available during early boot?


[Severity: High]
This is a pre-existing issue, but does the driver leak clock enable counts
and hardware reset states on probe error paths if the initial hardware
status is active?

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_probe() {
    ...
    udphy->phy_u3 = devm_phy_create(dev, dev->of_node, &rk_udphy_usb3_phy_ops);
    if (IS_ERR(udphy->phy_u3)) {
        ret = PTR_ERR(udphy->phy_u3);
        return dev_err_probe(dev, ret, "failed to create USB3 phy\n");
    }
    ...
}

rk_udphy_get_initial_status calls clk_bulk_prepare_enable. If it detects
active DP hardware, it leaves the clocks enabled and sets udphy->status to
UDPHY_MODE_DP.

If any subsequent step in rk_udphy_probe fails, the driver returns the error
without disabling the clocks. Without a devm-action registered to clean this
up, does this clock enable refcount leak prevent the system from ever
powering down the clock?


[Severity: High]
This isn't a bug introduced by this patch, but does rk_udphy_dp_phy_configure
access shared arrays and modify hardware registers without acquiring
udphy->mutex, leading to race conditions?

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_configure() {
    ...
    lane = udphy->dp_lane_sel[i];
    ...
}

This reads a shared array that is actively modified by Type-C event
handlers. At the same time, Type-C orientation switch callbacks like
rk_udphy_typec_mux_set or USB initialization can modify these exact same
structures or registers.

Could this concurrent access corrupt hardware registers or result in
inconsistent lane mappings?


[Severity: High]
This is a pre-existing issue, but do non-DP Alternate Mode events corrupt
the PHY lane mux configuration and silently break USB3 functionality?

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_typec_mux_set() {
    ...
    switch (state->mode) {
    case TYPEC_DP_STATE_C:
    case TYPEC_DP_STATE_E:
        udphy->lane_mux_sel[0] = PHY_LANE_MUX_DP;
    ...
}

This executes the switch block and overwrites udphy->lane_mux_sel before
verifying state->alt->svid == USB_TYPEC_DP_SID.

Because TYPEC_DP_STATE_C is defined as TYPEC_STATE_MODAL, any other
Alternate Mode that transitions into its modal state will inadvertently
match this case. Will this erroneously route all PHY lanes to DisplayPort
if a non-DP Type-C Alternate Mode device is attached?


[Severity: High]
This isn't a bug introduced by this patch, but are DisplayPort HPD events
received before the DP PHY is initialized permanently lost, preventing
display detection?

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_init() {
    ...
    udphy->dp_in_use = true;
    ...
}

rk_udphy_dp_hpd_event_trigger caches the HPD state in
udphy->dp_sink_hpd_cfg if udphy->dp_in_use is false. Later, when the DP
DRM driver calls rk_udphy_dp_phy_init, udphy->dp_in_use is set to true.

However, the function fails to write the cached HPD configuration out to
the hardware registers. Does this result in an attached DisplayPort monitor
not being detected by the system?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=2

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 10/36] phy: rockchip: usbdp: Add missing mode_change update
From: sashiko-bot @ 2026-07-10 21:13 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: olteanv, linux-phy, vkoul, neil.armstrong, robh, conor+dt,
	devicetree
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-10-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] PHY mode updates in `rk_udphy_typec_mux_set` are incorrectly gated by DP Alt Mode and HPD status, breaking USB lane restoration when exiting Alt Mode.
- [High] The USB3 port remains permanently disabled in the GRF after dynamically returning from 4-lane DP mode.
- [High] HPD events received from the Type-C TCPM before the DisplayPort controller initializes the PHY are cached but never flushed, dropping the hot-plug event.
- [High] The driver leaks the `UDPHY_MODE_USB` bit in `udphy->status` when dynamically switching from DP+USB mode to DP-only mode.
--

--- Patch [10]: [PATCH v12 10/36] phy: rockchip: usbdp: Add missing mode_change update ---
commit 1907d9e7af04f2c28df8bf00ded6a9b5a290664a
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Add missing mode_change update

rk_udphy_set_typec_default_mapping() updates the available modes,
but does not set the mode_change as required. This results in
missing re-initialization and thus non-working DisplayPort.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 982315535caf7..7540c897dde13 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c

[ ... ]

> @@ -1361,10 +1370,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
>  			usleep_range(750, 800);
>  			rk_udphy_dp_hpd_event_trigger(udphy, true);
>  		} else if (data->status & DP_STATUS_HPD_STATE) {
> -			if (udphy->mode != mode) {
> -				udphy->mode = mode;
> -				udphy->mode_change = true;
> -			}
> +			rk_udphy_mode_set(udphy, mode);

[Severity: High]
This is a pre-existing issue, but are PHY mode updates incorrectly gated by
DP Alt Mode and HPD status here?

When the Type-C manager tears down DP Alt Mode, it calls typec_mux_set()
with state->mode = TYPEC_STATE_SAFE and state->alt = NULL. The function
computes mode = UDPHY_MODE_DP_USB, but this rk_udphy_mode_set() call is
nested inside:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_typec_mux_set() {
    ...
    if (state->alt && state->alt->svid == USB_TYPEC_DP_SID) {
    ...
        } else if (data->status & DP_STATUS_HPD_STATE) {
            rk_udphy_mode_set(udphy, mode);
    ...
}

Does this incorrectly restrict PHY mode updates to DP Alt Mode, completely
missing state teardown paths where state->alt is NULL? This appears to break
USB lane restoration when exiting Alt Mode, causing USB to fail after
unplugging a DisplayPort adapter or exiting Alt Mode without a replug.

>  			rk_udphy_dp_hpd_event_trigger(udphy, true);
>  		} else {
>  			rk_udphy_dp_hpd_event_trigger(udphy, false);

[Severity: High]
This isn't a bug introduced by this patch, but does the USB3 port remain
permanently disabled in the GRF after dynamically returning from 4-lane DP
mode?

When dynamically switching from 4-lane DP mode back to DP+USB mode,
rk_udphy_power_on() executes the following block to reinitialize the PHY:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_power_on() {
    ...
    } else if (udphy->mode_change) {
        if (udphy->mode == UDPHY_MODE_DP)
            rk_udphy_u3_port_disable(udphy, true);

        ret = rk_udphy_init(udphy);
    ...
}

While this block correctly disables the U3 port for DP-only mode via
rk_udphy_u3_port_disable(udphy, true), it lacks the inverse
rk_udphy_u3_port_disable(udphy, false) call for restoring DP+USB mode.

Could this prevent the DWC3 controller from communicating with the USB3 PHY
when returning to DP+USB mode, resulting in non-working USB3?

[Severity: High]
This is a pre-existing issue, but are HPD events dropped if they are received
from the Type-C TCPM before the DisplayPort controller initializes the PHY?

If the TCPM fires an HPD event before the DP consumer probes and calls
rk_udphy_dp_phy_init(), rk_udphy_dp_hpd_event_trigger() caches the state in
udphy->dp_sink_hpd_cfg because udphy->dp_in_use is false.

When the DP consumer finally initializes the PHY, dp_in_use is set to true:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_init() {
    ...
    mutex_lock(&udphy->mutex);

    udphy->dp_in_use = true;

    mutex_unlock(&udphy->mutex);
    ...
}

However, the cached dp_sink_hpd_cfg is never written to the hardware
registers via rk_udphy_grfreg_write(). Can this drop the hot-plug event
and cause the display to remain completely undetected until the cable is
replugged?

[Severity: High]
This is a pre-existing issue, but does the driver leak the UDPHY_MODE_USB bit
in udphy->status when dynamically switching from DP+USB mode to DP-only mode?

When the type-c mux switches mode from UDPHY_MODE_DP_USB to UDPHY_MODE_DP,
udphy->mode is updated immediately. Later, when the USB subsystem processes
the disconnect and calls rk_udphy_usb3_phy_exit(), it checks the new mux mode
rather than the currently active status:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_usb3_phy_exit() {
    ...
    /* DP only or high-speed */
    if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs)
        goto unlock;

    rk_udphy_power_off(udphy, UDPHY_MODE_USB);
    ...
}

This condition evaluates to true because the mode was already changed,
skipping rk_udphy_power_off(udphy, UDPHY_MODE_USB).

Furthermore, the overarching rk_udphy_power_off() shares this identical
flawed check:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_power_off() {
    ...
    if (!(udphy->mode & mode)) {
        dev_info(udphy->dev, "mode 0x%02x is not support\n", mode);
        return;
    }
    ...
}

Could this secondary check return early if the new mode lacks the bit the
caller is legitimately trying to power off, preventing the mode bit from ever
being cleared from udphy->status? This appears to leave PHY resources
(clocks, resets) unreleased on teardown, corrupting state tracking and
leaking power.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=10

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 18/36] phy: rockchip: usbdp: Rename mode_change to phy_needs_reinit
From: sashiko-bot @ 2026-07-10 21:10 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: robh, vkoul, neil.armstrong, linux-phy, devicetree, conor+dt,
	olteanv
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-18-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Hardware hang due to unclocked memory-mapped register access.
--

--- Patch [18]: [PATCH v12 18/36] phy: rockchip: usbdp: Rename mode_change to phy_needs_reinit ---
commit 879ba283150f41ae77236ca40a0536af8b8e8236
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Rename mode_change to phy_needs_reinit

This patch renames the mode_change property to phy_needs_reinit to better
reflect that the PHY requires re-initialization not just on mode changes, but
also on cable orientation switches. This prepares the driver to handle DP
re-init properly on orientation changes.

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 24108816e3b95..e44d19c9d1193 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
[ ... ]
> @@ -951,15 +951,15 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)

[Severity: High]
This is a pre-existing issue, but can this lead to a system hang when the PHY
is unsupported?

Looking at rk_udphy_power_on(), if the requested mode is unsupported,
it returns 0 early without enabling the clocks:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_power_on() {
	if (!(udphy->mode & mode)) {
		dev_info(udphy->dev, "mode 0x%02x is not support\n", mode);
		return 0;
	}
...
}

Because this returns 0 instead of an error code, rk_udphy_dp_phy_power_on()
assumes the PHY is clocked and proceeds to call rk_udphy_dp_lane_enable():

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_power_on() {
...
	ret = rk_udphy_power_on(udphy, UDPHY_MODE_DP);
	if (ret)
		goto unlock;

	rk_udphy_dp_lane_enable(udphy, udphy->dp_lanes);
...
}

This results in accessing memory-mapped PHY registers via pma_regmap when the
corresponding PHY clocks are gated. Could this trigger a synchronous external
abort and a kernel panic?

Additionally, this same sequence appears in rk_udphy_dp_phy_power_off()
which calls rk_udphy_dp_lane_enable(udphy, 0) unconditionally without checking
if the PHY was successfully powered on:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_power_off() {
	mutex_lock(&udphy->mutex);
	rk_udphy_dp_lane_enable(udphy, 0);
	rk_udphy_power_off(udphy, UDPHY_MODE_DP);
...
}

Should rk_udphy_power_on() return an error like -EINVAL when the mode is not
supported, and should rk_udphy_dp_phy_power_off() avoid calling
rk_udphy_dp_lane_enable() if the PHY is not powered on?

>  
>  		if (udphy->mode & UDPHY_MODE_USB)
>  			rk_udphy_u3_port_disable(udphy, false);
> -		udphy->mode_change = false;
> -	} else if (udphy->mode_change) {
> +		udphy->phy_needs_reinit = false;
> +	} else if (udphy->phy_needs_reinit) {
>  		if (udphy->mode == UDPHY_MODE_DP)
>  			rk_udphy_u3_port_disable(udphy, true);
>  
>  		ret = rk_udphy_init(udphy);
>  		if (ret)
>  			return ret;
> -		udphy->mode_change = false;
> +		udphy->phy_needs_reinit = false;
>  	}
>  
>  	udphy->status |= mode;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=18

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 12/36] phy: rockchip: usbdp: Limit DP lane count to muxed lanes
From: sashiko-bot @ 2026-07-10 21:08 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: robh, devicetree, neil.armstrong, conor+dt, linux-phy, olteanv,
	vkoul
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-12-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing lock / data race on shared driver state during PHY configuration
- [High] Incomplete fix: DP lane bounds check is bypassed during voltage-only configurations
--

--- Patch [12]: [PATCH v12 12/36] phy: rockchip: usbdp: Limit DP lane count to muxed lanes ---
commit f343affd6c4a3599ea8955fa27e07174fef51eb5
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Limit DP lane count to muxed lanes

This patch adds a check to ensure the DP controller does not request more
lanes than the PHY is configured to support. This protects against USB3
usage corruption.

Link: https://lore.kernel.org/linux-phy/20260612165546.98E1F1F000E9@smtp.kernel.org/

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index c4d62b234ea80..b172ce6a722ee 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1099,6 +1099,9 @@ static int rk_udphy_dp_phy_verify_link_rate(struct rk_udphy *udphy,
>  static int rk_udphy_dp_phy_verify_lanes(struct rk_udphy *udphy,
>  					struct phy_configure_opts_dp *dp)
>  {
> +	if (dp->lanes > udphy->dp_lanes)
> +		return -EINVAL;
> +

[Severity: High]
This is a pre-existing issue, but is there a data race when accessing
udphy->dp_lanes here?

It appears this lockless read creates a TOCTOU vulnerability against
concurrent Type-C mode switches. The dw-dp driver invokes link training
concurrently with TCPM Type-C events invoking rk_udphy_typec_mux_set().

Since rk_udphy_dp_phy_configure() and rk_udphy_dp_phy_verify_lanes()
read and write shared variables without acquiring udphy->mutex (only the
generic phy->mutex is held):

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_configure() {
        ...
        if (dp->set_voltages) {
                for (i = 0; i < udphy->lanes; i++) {
                        lane = udphy->dp_lane_sel[i];
        ...
}

Can this lead to hardware PHY corruption if DRM and TCPM use independent
workqueues with no common lock?

[Severity: High]
This isn't a bug introduced by this patch, but does this new check fully
protect the voltage configuration path?

If the dw-dp driver splits link training and first calls phy_configure()
with set_lanes = true, it caches dp->lanes into udphy->lanes. 

If it later calls it with set_voltages = true and set_lanes = false, this
bounds check in rk_udphy_dp_phy_verify_lanes() is bypassed.

If a Type-C event reduces the available udphy->dp_lanes before the second
call, the set_voltages block iterates up to the cached udphy->lanes:

drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_configure() {
        ...
        if (dp->set_voltages) {
                for (i = 0; i < udphy->lanes; i++) {
                        lane = udphy->dp_lane_sel[i];
        ...
}

Could this override active USB3 lanes and corrupt the USB3 PHY state?

>  	switch (dp->lanes) {
>  	case 1:
>  	case 2:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=12

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v12 06/36] phy: rockchip: usbdp: Drop seamless DP takeover
From: sashiko-bot @ 2026-07-10 21:08 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: linux-phy, devicetree, vkoul, robh, neil.armstrong, olteanv,
	conor+dt
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-6-8b41a9a9bef0@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing hardware reset at probe leads to system lockups if bootloader leaves PHY active
--

--- Patch [6]: [PATCH v12 06/36] phy: rockchip: usbdp: Drop seamless DP takeover ---
commit 871e6d2aea7ac2c888b4917f93fff1eda368209d
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

phy: rockchip: usbdp: Drop seamless DP takeover

This patch removes support for seamless DP takeover from the bootloader,
noting that the current DRM drivers do not support it and the code is
untested. It removes the initial status check and corresponding reset logic.

Closes: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/

> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 3fc8222fcaec2..6cb9f6b4dbf6d 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c

[ ... ]

> @@ -1495,10 +1468,6 @@ static int rk_udphy_probe(struct platform_device *pdev)
>  	if (ret)
>  		return ret;
>  
> -	ret = rk_udphy_get_initial_status(udphy);
> -	if (ret)
> -		return ret;
> -

[Severity: High]
Does removing this initial status check leave the PHY hardware in an unmanaged
state if the bootloader enabled it?

Without this initialization step, the driver no longer explicitly manages the
PHY resets or increments the clock enable count during probe. If a bootloader
leaves the PHY active (such as for a display splash screen or USB fastboot),
and the consumer driver is not loaded or defers probing, the clock framework's
clk_disable_unused will execute at late_initcall and cut the unclaimed PHY
clocks.

On Rockchip SoCs, cutting clocks to an un-reset, active peripheral frequently
causes an AXI bus hang or prevents the power domain from safely shutting down.
Is an explicit reset still needed in rk_udphy_probe() to ensure the hardware
is put into a quiescent state during boot?

>  	mutex_init(&udphy->mutex);
>  	platform_set_drvdata(pdev, udphy);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=6

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox