[PATCH RFC] arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590

[PATCH RFC] arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590

[Bjorn Andersson]

The QCS6490 Rb3Gen2 has a Renesas μPD720201 XHCI controller hanging off
the TC9563 PCIe switch, on this a Genesys Logic GL3590 USB hub provides
two USB Type-A ports and an ASIX AX88179 USB 3.0 Gigabit Ethernet
interface.

The Renesas chip is powered by two regulators controlled through PM7250B
GPIOs 1 and 4, and the power/reset pin is pulled down by PM8350C GPIO 4.
The Genesys chip power is always-on, but the reset pin is controlled
through TLMM GPIO 162.

Describe the Renesas chip on the PCIe bus, with supplies and reset, to
allow it to be brought out of reset and discovered. Then describe the
two peers of the USB hub, with its reset GPIO, to allow this to be
brought out of reset.

The USB Type-A connectors are not described, as they are in no regard
controlled by the operating system.

Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
---
Posting this as a RFC, because it doesn't work without some hacks in the
PCI pwrctrl code. It depends on Neil's work for μPD720201 pwrctrl [1],
on the GL3590 work by Swati and Krisha [2], and my regulator fix [3].
With these three dependencies, the hacks in drivers/pci/pwrctrl/core.c,
and firmware for the μPD720201, the primary ethernet lights up.

Then in pci_pwrctrl_create_device() we assume that anything in a PCI
device node, with either a -supply or port/ports property, should be a
platform_device. When the USB bus(es) of the μPD720201 shows up, it
again registers this platform_device. It seems that
of_platform_device_create() saves us and does an early exit, but by
"accident".

__pci_pwrctrl_power_on_device() and __pci_pwrctrl_power_off_device() on
the other hand, they happily pick up the non-NULL drvdata, which is of
type struct onboard_dev, to call the power_on() and power_off() methods.

It's not clear to me why the whole board resets at this point, but I
don't think we can assume that any random platform_device we find at any
level below the PCIe bus has a drvdata of type struct pci_pwrctrl...

[1] https://lore.kernel.org/all/20260206-topic-sm8650-ayaneo-pocket-s2-base-v3-0-5b79c5d61a03@linaro.org/
[2] https://lore.kernel.org/all/20260122092852.887624-1-swati.agarwal@oss.qualcomm.com/
[3] https://lore.kernel.org/linux-arm-msm/177091226767.237262.6699917364293122804.b4-ty@kernel.org/T/#t
---
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 94 ++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index e3d2f01881ae05f17796f9c97f10b53cea50daff..e8d3588e67d0386150258d0bc28b4c6200920067 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -262,6 +262,28 @@ active-config0 {
 		};
 	};
 
+	vreg_pcie0_1p05: regulator-pcie0-1p05v {
+		compatible = "regulator-fixed";
+		regulator-name = "PCIE0_1.05V";
+		gpio = <&pm7250b_gpios 4 GPIO_ACTIVE_HIGH>;
+		regulator-min-microvolt = <1050000>;
+		regulator-max-microvolt = <1050000>;
+		enable-active-high;
+		pinctrl-0 = <&upd_pwr_en2_state>;
+		pinctrl-names = "default";
+	};
+
+	vreg_pcie0_3p3: regulator-pcie0-3p3v-dual {
+		compatible = "regulator-fixed";
+		regulator-name = "PCIE0_3.3V_Dual";
+		gpio = <&pm7250b_gpios 1 GPIO_ACTIVE_HIGH>;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		enable-active-high;
+		pinctrl-0 = <&upd_pwr_en1_state>;
+		pinctrl-names = "default";
+	};
+
 	vdd_ntn_0p9: regulator-vdd-ntn-0p9 {
 		compatible = "regulator-fixed";
 		regulator-name = "VDD_NTN_0P9";
@@ -870,6 +892,41 @@ pcie@2,0 {
 			device_type = "pci";
 			ranges;
 			bus-range = <0x4 0xff>;
+
+			/* Renesas μPD720201 PCIe USB3.0 Host Controller */
+			usb-controller@0,0 {
+				compatible = "pci1912,0014";
+				reg = <0x40000 0x0 0x0 0x0 0x0>;
+
+				avdd33-supply = <&vreg_pcie0_3p3>;
+				vdd10-supply = <&vreg_pcie0_1p05>;
+				vdd33-supply = <&vreg_pcie0_3p3>;
+
+				pinctrl-0 = <&upd_hub_rst_state>;
+				pinctrl-names = "default";
+
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				/* Genesys Logic GL3590 USB Hub Controller */
+				gl3590_2_0: hub@1 {
+					compatible = "usb5e3,610";
+					reg = <1>;
+					reset-gpios = <&tlmm 162 GPIO_ACTIVE_HIGH>;
+
+					pinctrl-0 = <&usb_hub_reset_state>;
+					pinctrl-names = "default";
+
+					peer-hub = <&gl3590_3_0>;
+				};
+
+				gl3590_3_0: hub@2 {
+					compatible = "usb5e3,625";
+					reg = <2>;
+
+					peer-hub = <&gl3590_2_0>;
+				};
+			};
 		};
 
 		pcie@3,0 {
@@ -1198,6 +1255,17 @@ ntn_1p8_en: ntn-1p8-en-state {
 		power-source = <0>;
 	};
 
+	upd_hub_rst_state: upd-hub-rst-state {
+		pins = "gpio4";
+		function = "normal";
+
+		bias-disable;
+		input-disable;
+		output-enable;
+		output-high;
+		power-source = <0>;
+	};
+
 	tc9563_resx_n: tc9563-resx-state {
 		pins = "gpio1";
 		function = "normal";
@@ -1378,6 +1446,15 @@ &edp_hot_plug_det {
 };
 
 &pm7250b_gpios {
+	upd_pwr_en1_state: upd-pwr-en1-state {
+		pins = "gpio1";
+		function = "normal";
+
+		output-enable;
+		input-disable;
+		power-source = <0>;
+	};
+
 	lt9611_rst_pin: lt9611-rst-state {
 		pins = "gpio2";
 		function = "normal";
@@ -1386,6 +1463,15 @@ lt9611_rst_pin: lt9611-rst-state {
 		input-disable;
 		power-source = <0>;
 	};
+
+	upd_pwr_en2_state: upd-pwr-en2-state {
+		pins = "gpio4";
+		function = "normal";
+
+		output-enable;
+		input-disable;
+		power-source = <0>;
+	};
 };
 
 &sdc2_clk {
@@ -1431,6 +1517,14 @@ sd_cd: sd-cd-state {
 		function = "gpio";
 		bias-pull-up;
 	};
+
+	usb_hub_reset_state: usb-hub-reset-state {
+		pins = "gpio162";
+		function = "gpio";
+
+		drive-strength = <2>;
+		bias-disable;
+	};
 };
 
 &lpass_audiocc {

---
base-commit: fd9678829d6dd0c10fde080b536abf4b1121c346
change-id: 20260212-rb3gen2-upd-gl3590-d110dd722e1b

Best regards,
-- 
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>

Re: [PATCH RFC] arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590

[Manivannan Sadhasivam]

On Thu, Feb 12, 2026 at 02:43:46PM -0600, Bjorn Andersson wrote:
> The QCS6490 Rb3Gen2 has a Renesas μPD720201 XHCI controller hanging off
> the TC9563 PCIe switch, on this a Genesys Logic GL3590 USB hub provides
> two USB Type-A ports and an ASIX AX88179 USB 3.0 Gigabit Ethernet
> interface.
> 
> The Renesas chip is powered by two regulators controlled through PM7250B
> GPIOs 1 and 4, and the power/reset pin is pulled down by PM8350C GPIO 4.
> The Genesys chip power is always-on, but the reset pin is controlled
> through TLMM GPIO 162.
> 
> Describe the Renesas chip on the PCIe bus, with supplies and reset, to
> allow it to be brought out of reset and discovered. Then describe the
> two peers of the USB hub, with its reset GPIO, to allow this to be
> brought out of reset.
> 
> The USB Type-A connectors are not described, as they are in no regard
> controlled by the operating system.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> ---
> Posting this as a RFC, because it doesn't work without some hacks in the
> PCI pwrctrl code. It depends on Neil's work for μPD720201 pwrctrl [1],
> on the GL3590 work by Swati and Krisha [2], and my regulator fix [3].
> With these three dependencies, the hacks in drivers/pci/pwrctrl/core.c,
> and firmware for the μPD720201, the primary ethernet lights up.
> 
> Then in pci_pwrctrl_create_device() we assume that anything in a PCI
> device node, with either a -supply or port/ports property, should be a
> platform_device. When the USB bus(es) of the μPD720201 shows up, it
> again registers this platform_device. It seems that
> of_platform_device_create() saves us and does an early exit, but by
> "accident".
> 

I agree that this is an issue, probably an overlook on my part assuming that
every child node of the Root Port is a PCIe node. I should add a check for
the 'device_type' property before we even check for the existence of the
supply/graph properties.

I was notified of an internal regression as well with graph port check. So I'll
send both fixes in a single series.

- Mani

> __pci_pwrctrl_power_on_device() and __pci_pwrctrl_power_off_device() on
> the other hand, they happily pick up the non-NULL drvdata, which is of
> type struct onboard_dev, to call the power_on() and power_off() methods.
> 
> It's not clear to me why the whole board resets at this point, but I
> don't think we can assume that any random platform_device we find at any
> level below the PCIe bus has a drvdata of type struct pci_pwrctrl...
> 
> [1] https://lore.kernel.org/all/20260206-topic-sm8650-ayaneo-pocket-s2-base-v3-0-5b79c5d61a03@linaro.org/
> [2] https://lore.kernel.org/all/20260122092852.887624-1-swati.agarwal@oss.qualcomm.com/
> [3] https://lore.kernel.org/linux-arm-msm/177091226767.237262.6699917364293122804.b4-ty@kernel.org/T/#t
> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 94 ++++++++++++++++++++++++++++
>  1 file changed, 94 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index e3d2f01881ae05f17796f9c97f10b53cea50daff..e8d3588e67d0386150258d0bc28b4c6200920067 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -262,6 +262,28 @@ active-config0 {
>  		};
>  	};
>  
> +	vreg_pcie0_1p05: regulator-pcie0-1p05v {
> +		compatible = "regulator-fixed";
> +		regulator-name = "PCIE0_1.05V";
> +		gpio = <&pm7250b_gpios 4 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <1050000>;
> +		regulator-max-microvolt = <1050000>;
> +		enable-active-high;
> +		pinctrl-0 = <&upd_pwr_en2_state>;
> +		pinctrl-names = "default";
> +	};
> +
> +	vreg_pcie0_3p3: regulator-pcie0-3p3v-dual {
> +		compatible = "regulator-fixed";
> +		regulator-name = "PCIE0_3.3V_Dual";
> +		gpio = <&pm7250b_gpios 1 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		enable-active-high;
> +		pinctrl-0 = <&upd_pwr_en1_state>;
> +		pinctrl-names = "default";
> +	};
> +
>  	vdd_ntn_0p9: regulator-vdd-ntn-0p9 {
>  		compatible = "regulator-fixed";
>  		regulator-name = "VDD_NTN_0P9";
> @@ -870,6 +892,41 @@ pcie@2,0 {
>  			device_type = "pci";
>  			ranges;
>  			bus-range = <0x4 0xff>;
> +
> +			/* Renesas μPD720201 PCIe USB3.0 Host Controller */
> +			usb-controller@0,0 {
> +				compatible = "pci1912,0014";
> +				reg = <0x40000 0x0 0x0 0x0 0x0>;
> +
> +				avdd33-supply = <&vreg_pcie0_3p3>;
> +				vdd10-supply = <&vreg_pcie0_1p05>;
> +				vdd33-supply = <&vreg_pcie0_3p3>;
> +
> +				pinctrl-0 = <&upd_hub_rst_state>;
> +				pinctrl-names = "default";
> +
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				/* Genesys Logic GL3590 USB Hub Controller */
> +				gl3590_2_0: hub@1 {
> +					compatible = "usb5e3,610";
> +					reg = <1>;
> +					reset-gpios = <&tlmm 162 GPIO_ACTIVE_HIGH>;
> +
> +					pinctrl-0 = <&usb_hub_reset_state>;
> +					pinctrl-names = "default";
> +
> +					peer-hub = <&gl3590_3_0>;
> +				};
> +
> +				gl3590_3_0: hub@2 {
> +					compatible = "usb5e3,625";
> +					reg = <2>;
> +
> +					peer-hub = <&gl3590_2_0>;
> +				};
> +			};
>  		};
>  
>  		pcie@3,0 {
> @@ -1198,6 +1255,17 @@ ntn_1p8_en: ntn-1p8-en-state {
>  		power-source = <0>;
>  	};
>  
> +	upd_hub_rst_state: upd-hub-rst-state {
> +		pins = "gpio4";
> +		function = "normal";
> +
> +		bias-disable;
> +		input-disable;
> +		output-enable;
> +		output-high;
> +		power-source = <0>;
> +	};
> +
>  	tc9563_resx_n: tc9563-resx-state {
>  		pins = "gpio1";
>  		function = "normal";
> @@ -1378,6 +1446,15 @@ &edp_hot_plug_det {
>  };
>  
>  &pm7250b_gpios {
> +	upd_pwr_en1_state: upd-pwr-en1-state {
> +		pins = "gpio1";
> +		function = "normal";
> +
> +		output-enable;
> +		input-disable;
> +		power-source = <0>;
> +	};
> +
>  	lt9611_rst_pin: lt9611-rst-state {
>  		pins = "gpio2";
>  		function = "normal";
> @@ -1386,6 +1463,15 @@ lt9611_rst_pin: lt9611-rst-state {
>  		input-disable;
>  		power-source = <0>;
>  	};
> +
> +	upd_pwr_en2_state: upd-pwr-en2-state {
> +		pins = "gpio4";
> +		function = "normal";
> +
> +		output-enable;
> +		input-disable;
> +		power-source = <0>;
> +	};
>  };
>  
>  &sdc2_clk {
> @@ -1431,6 +1517,14 @@ sd_cd: sd-cd-state {
>  		function = "gpio";
>  		bias-pull-up;
>  	};
> +
> +	usb_hub_reset_state: usb-hub-reset-state {
> +		pins = "gpio162";
> +		function = "gpio";
> +
> +		drive-strength = <2>;
> +		bias-disable;
> +	};
>  };
>  
>  &lpass_audiocc {
> 
> ---
> base-commit: fd9678829d6dd0c10fde080b536abf4b1121c346
> change-id: 20260212-rb3gen2-upd-gl3590-d110dd722e1b
> 
> Best regards,
> -- 
> Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> 

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH RFC] arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590

[Konrad Dybcio]

On 2/12/26 9:43 PM, Bjorn Andersson wrote:
> The QCS6490 Rb3Gen2 has a Renesas μPD720201 XHCI controller hanging off
> the TC9563 PCIe switch, on this a Genesys Logic GL3590 USB hub provides
> two USB Type-A ports and an ASIX AX88179 USB 3.0 Gigabit Ethernet
> interface.
> 
> The Renesas chip is powered by two regulators controlled through PM7250B
> GPIOs 1 and 4, and the power/reset pin is pulled down by PM8350C GPIO 4.
> The Genesys chip power is always-on, but the reset pin is controlled
> through TLMM GPIO 162.
> 
> Describe the Renesas chip on the PCIe bus, with supplies and reset, to
> allow it to be brought out of reset and discovered. Then describe the
> two peers of the USB hub, with its reset GPIO, to allow this to be
> brought out of reset.
> 
> The USB Type-A connectors are not described, as they are in no regard
> controlled by the operating system.

Nice, for a change ;)

[...]

> +
> +	usb_hub_reset_state: usb-hub-reset-state {
> +		pins = "gpio162";
> +		function = "gpio";
> +
> +		drive-strength = <2>;
> +		bias-disable;

Straying away from the main topic, I find these newlines in the middle
excessive

Konrad

Re: [PATCH RFC] arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590

[Dmitry Baryshkov]

On Thu, Feb 12, 2026 at 02:43:46PM -0600, Bjorn Andersson wrote:
> The QCS6490 Rb3Gen2 has a Renesas μPD720201 XHCI controller hanging off
> the TC9563 PCIe switch, on this a Genesys Logic GL3590 USB hub provides
> two USB Type-A ports and an ASIX AX88179 USB 3.0 Gigabit Ethernet
> interface.
> 
> The Renesas chip is powered by two regulators controlled through PM7250B
> GPIOs 1 and 4, and the power/reset pin is pulled down by PM8350C GPIO 4.
> The Genesys chip power is always-on, but the reset pin is controlled
> through TLMM GPIO 162.
> 
> Describe the Renesas chip on the PCIe bus, with supplies and reset, to
> allow it to be brought out of reset and discovered. Then describe the
> two peers of the USB hub, with its reset GPIO, to allow this to be
> brought out of reset.
> 
> The USB Type-A connectors are not described, as they are in no regard
> controlled by the operating system.

Nevertheless, their presense in DT controls port's connect_type as can
be seen in sysfs.

> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> ---
-- 
With best wishes
Dmitry

Re: [PATCH RFC] arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590

[Bjorn Andersson]

On Tue, Feb 24, 2026 at 09:52:45AM +0200, Dmitry Baryshkov wrote:
> On Thu, Feb 12, 2026 at 02:43:46PM -0600, Bjorn Andersson wrote:
> > The QCS6490 Rb3Gen2 has a Renesas μPD720201 XHCI controller hanging off
> > the TC9563 PCIe switch, on this a Genesys Logic GL3590 USB hub provides
> > two USB Type-A ports and an ASIX AX88179 USB 3.0 Gigabit Ethernet
> > interface.
> > 
> > The Renesas chip is powered by two regulators controlled through PM7250B
> > GPIOs 1 and 4, and the power/reset pin is pulled down by PM8350C GPIO 4.
> > The Genesys chip power is always-on, but the reset pin is controlled
> > through TLMM GPIO 162.
> > 
> > Describe the Renesas chip on the PCIe bus, with supplies and reset, to
> > allow it to be brought out of reset and discovered. Then describe the
> > two peers of the USB hub, with its reset GPIO, to allow this to be
> > brought out of reset.
> > 
> > The USB Type-A connectors are not described, as they are in no regard
> > controlled by the operating system.
> 
> Nevertheless, their presense in DT controls port's connect_type as can
> be seen in sysfs.
> 

Is that information useful enough to be worth describing the connectors
and wire them up, despite being completely passive?

What consumes connect_type?

Regards,
Bjorn

> > 
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> > ---
> -- 
> With best wishes
> Dmitry

Re: [PATCH RFC] arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590

[Dmitry Baryshkov]

On Tue, Feb 24, 2026 at 09:40:40PM -0600, Bjorn Andersson wrote:
> On Tue, Feb 24, 2026 at 09:52:45AM +0200, Dmitry Baryshkov wrote:
> > On Thu, Feb 12, 2026 at 02:43:46PM -0600, Bjorn Andersson wrote:
> > > The QCS6490 Rb3Gen2 has a Renesas μPD720201 XHCI controller hanging off
> > > the TC9563 PCIe switch, on this a Genesys Logic GL3590 USB hub provides
> > > two USB Type-A ports and an ASIX AX88179 USB 3.0 Gigabit Ethernet
> > > interface.
> > > 
> > > The Renesas chip is powered by two regulators controlled through PM7250B
> > > GPIOs 1 and 4, and the power/reset pin is pulled down by PM8350C GPIO 4.
> > > The Genesys chip power is always-on, but the reset pin is controlled
> > > through TLMM GPIO 162.
> > > 
> > > Describe the Renesas chip on the PCIe bus, with supplies and reset, to
> > > allow it to be brought out of reset and discovered. Then describe the
> > > two peers of the USB hub, with its reset GPIO, to allow this to be
> > > brought out of reset.
> > > 
> > > The USB Type-A connectors are not described, as they are in no regard
> > > controlled by the operating system.
> > 
> > Nevertheless, their presense in DT controls port's connect_type as can
> > be seen in sysfs.
> > 
> 
> Is that information useful enough to be worth describing the connectors
> and wire them up, despite being completely passive?
> 
> What consumes connect_type?

Quick check through sources.debian.net reveals usbguard and
libusbauth-configparser. Granted that Stephen Boyd wired it up for DT
devices pointing Trogdor devices, I'd assume that something inside CrOS
can also be using these properties.

> 
> Regards,
> Bjorn
> 
> > > 
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> > > ---
> > -- 
> > With best wishes
> > Dmitry

-- 
With best wishes
Dmitry