[PATCH 0/2] TQMa6UL[L]x[L] DT improvements

[PATCH 0/2] TQMa6UL[L]x[L] DT improvements

[Alexander Stein]

Hi everyone,

this small series improves the DT for TQMa6UL[L]x[L] a bit.
Ethernet PHY IRQ support can now be added. And the on-board USB hub
is explicitly specified.

Thanks and best regards,
Alexander

Alexander Stein (2):
  ARM: dts: mba6ulx: Add Ethernet PHY interrupt support
  ARM: dts: mba6ulx: Add USB hub node

 arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

-- 
2.55.0

[PATCH 1/2] ARM: dts: mba6ulx: Add Ethernet PHY interrupt support

[Alexander Stein]

With commit 417b0f8d08f87 ("gpio: pca953x: Add support for level-triggered
interrupts") the GPIO expander gained support for level-low interrupts
required for Ethernet PHYs

Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
index f0f886f2b8cfd..dea473f660f91 100644
--- a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
@@ -230,6 +230,8 @@ ethphy0: ethernet-phy@0 {
 			clocks = <&clks IMX6UL_CLK_ENET_REF>;
 			reg = <0>;
 			max-speed = <100>;
+			interrupt-parent = <&expander_in0>;
+			interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
 		};
 
 		ethphy1: ethernet-phy@1 {
@@ -237,6 +239,8 @@ ethphy1: ethernet-phy@1 {
 			clocks = <&clks IMX6UL_CLK_ENET2_REF_125M>;
 			reg = <1>;
 			max-speed = <100>;
+			interrupt-parent = <&expander_in0>;
+			interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
 		};
 	};
 };
-- 
2.55.0

Re: [PATCH 1/2] ARM: dts: mba6ulx: Add Ethernet PHY interrupt support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Leftover `gpio-hog` nodes (`enet1_int-hog` and `enet2_int-hog`) for Ethernet PHY interrupt pins double-book GPIO resources.
--

--- Patch [1]: [PATCH 1/2] ARM: dts: mba6ulx: Add Ethernet PHY interrupt support ---
commit b452753cee9dad50d404387319c21ed7231c45d2
Author: Alexander Stein <alexander.stein@ew.tq-group.com>

ARM: dts: mba6ulx: Add Ethernet PHY interrupt support

This commit adds interrupt-parent and interrupts properties to the ethphy0
and ethphy1 nodes in the device tree. It configures the Ethernet PHYs to
use level-low interrupts provided by the GPIO expander.

> diff --git a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
> --- a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
> +++ b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
> @@ -214,6 +214,8 @@ ethphy0: ethernet-phy@0 {
>  			clocks = <&clks IMX6UL_CLK_ENET_REF>;
>  			reg = <0>;
>  			max-speed = <100>;
> +			interrupt-parent = <&expander_in0>;
> +			interrupts = <6 IRQ_TYPE_LEVEL_LOW>;

[Severity: Medium]
Will this conflict with the existing enet1_int-hog in the expander_in0 node?

Further down in this file, expander_in0 still defines these pins as
gpio-hogs:

		enet1_int-hog {
			gpio-hog;
			gpios = <6 0>;
			input;
		};

		enet2_int-hog {
			gpio-hog;
			gpios = <7 0>;
			input;
		};

Does leaving these redundant gpio-hog nodes in place cause the device tree
to claim the same hardware resource twice? This might result in a resource
ownership conflict between the GPIO and IRQ subsystems, potentially causing
the IRQ request to fail and fall back to polling.

>  		};
>  
>  		ethphy1: ethernet-phy@1 {
>  			compatible = "ethernet-phy-ieee802.3-c22";
>  			clocks = <&clks IMX6UL_CLK_ENET2_REF_125M>;
>  			reg = <1>;
>  			max-speed = <100>;
> +			interrupt-parent = <&expander_in0>;
> +			interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
>  		};
>  	};
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260813121250.3993187-1-alexander.stein@ew.tq-group.com?part=1

Re: [PATCH 1/2] ARM: dts: mba6ulx: Add Ethernet PHY interrupt support

[Alexander Stein]

Am Donnerstag, 13. August 2026, 14:51:31 CEST schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Leftover `gpio-hog` nodes (`enet1_int-hog` and `enet2_int-hog`) for Ethernet PHY interrupt pins double-book GPIO resources.
> --
> 
> --- Patch [1]: [PATCH 1/2] ARM: dts: mba6ulx: Add Ethernet PHY interrupt support ---
> commit b452753cee9dad50d404387319c21ed7231c45d2
> Author: Alexander Stein <alexander.stein@ew.tq-group.com>
> 
> ARM: dts: mba6ulx: Add Ethernet PHY interrupt support
> 
> This commit adds interrupt-parent and interrupts properties to the ethphy0
> and ethphy1 nodes in the device tree. It configures the Ethernet PHYs to
> use level-low interrupts provided by the GPIO expander.
> 
> > diff --git a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
> > --- a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
> > +++ b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
> > @@ -214,6 +214,8 @@ ethphy0: ethernet-phy@0 {
> >  			clocks = <&clks IMX6UL_CLK_ENET_REF>;
> >  			reg = <0>;
> >  			max-speed = <100>;
> > +			interrupt-parent = <&expander_in0>;
> > +			interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
> 
> [Severity: Medium]
> Will this conflict with the existing enet1_int-hog in the expander_in0 node?
> 
> Further down in this file, expander_in0 still defines these pins as
> gpio-hogs:
> 
> 		enet1_int-hog {
> 			gpio-hog;
> 			gpios = <6 0>;
> 			input;
> 		};
> 
> 		enet2_int-hog {
> 			gpio-hog;
> 			gpios = <7 0>;
> 			input;
> 		};
> 
> Does leaving these redundant gpio-hog nodes in place cause the device tree
> to claim the same hardware resource twice? This might result in a resource
> ownership conflict between the GPIO and IRQ subsystems, potentially causing
> the IRQ request to fail and fall back to polling.

Because drivers/gpio/gpio-pca953x.c does use GPIOCHIP_IRQ_RESOURCE_HELPERS
these hogs are actually redundant. Will remove in v2.

Best regards
Alexander

> >  		};
> >  
> >  		ethphy1: ethernet-phy@1 {
> >  			compatible = "ethernet-phy-ieee802.3-c22";
> >  			clocks = <&clks IMX6UL_CLK_ENET2_REF_125M>;
> >  			reg = <1>;
> >  			max-speed = <100>;
> > +			interrupt-parent = <&expander_in0>;
> > +			interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> >  		};
> >  	};
> >  };
> 
> 


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

[PATCH 2/2] ARM: dts: mba6ulx: Add USB hub node

[Alexander Stein]

Instead of handling the USB hub reset using a regulator, add a proper
on-board USB hub device with reset-gpios set.

Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi | 20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
index dea473f660f91..2327528b402f3 100644
--- a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
@@ -133,16 +133,6 @@ reg_mpcie: regulator-mpcie-3v3 {
 		vin-supply = <&reg_mba6ul_3v3>;
 	};
 
-	reg_otg2vbus_5v0: regulator-otg2-vbus-5v0 {
-		compatible = "regulator-fixed";
-		gpio = <&expander_out1 0 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-		regulator-name = "otg2-vbus-supply-5v0";
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-		vin-supply = <&reg_mpcie>;
-	};
-
 	reserved-memory {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -407,10 +397,18 @@ &usbotg1 {
 /* 7-port usb hub */
 /* id, pwr, oc pins not connected */
 &usbotg2 {
+	#address-cells = <1>;
+	#size-cells = <0>;
 	disable-over-current;
-	vbus-supply = <&reg_otg2vbus_5v0>;
 	dr_mode = "host";
 	status = "okay";
+
+	hub_2_0: hub@1 {
+		compatible = "usb424,2517";
+		reg = <1>;
+		reset-gpios = <&expander_out1 0 GPIO_ACTIVE_LOW>;
+		vdd-supply = <&reg_mba6ul_3v3>;
+	};
 };
 
 &usdhc1 {
-- 
2.55.0

Re: [PATCH 2/2] ARM: dts: mba6ulx: Add USB hub node

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] I2C GPIO expander used as reset-gpios for onboard_usb_dev causes PM phase mismatch, breaking reset timing during resume.
--

--- Patch [2]: [PATCH 2/2] ARM: dts: mba6ulx: Add USB hub node ---
commit 52d9db850f98165215d9ab4ba1bee0bd2993c73e
Author: Alexander Stein <alexander.stein@ew.tq-group.com>

ARM: dts: mba6ulx: Add USB hub node

This commit replaces a fixed regulator previously used for USB hub reset with
a proper onboard USB hub device node that utilizes reset-gpios.

> diff --git a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
> index 244376b38835a..322fbd82531e6 100644
> --- a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
> +++ b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi

[ ... ]

> @@ -379,10 +369,18 @@ &usbotg1 {
>  /* 7-port usb hub */
>  /* id, pwr, oc pins not connected */
>  &usbotg2 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
>  	disable-over-current;
> -	vbus-supply = <&reg_otg2vbus_5v0>;
>  	dr_mode = "host";
>  	status = "okay";
> +
> +	hub_2_0: hub@1 {
> +		compatible = "usb424,2517";
> +		reg = <1>;
> +		reset-gpios = <&expander_out1 0 GPIO_ACTIVE_LOW>;
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Does using an I2C GPIO expander for the onboard USB hub reset cause a PM phase
mismatch during system suspend and resume?

The onboard_usb_dev driver uses suspend_late() and resume_early() power
management operations, while standard I2C GPIO expanders typically use normal
suspend() and resume() operations.

During system suspend, the expander suspends first (in the suspend phase) and
puts its regmap into cache_only mode. When the hub driver suspends later in
suspend_late(), its reset GPIO assertion is merely cached.

During system resume, the hub driver attempts to deassert the reset in
resume_early() and waits for power_on_delay_us. Because the expander is
still in cache_only mode, the physical pin remains unchanged. 

Later, during the normal resume phase, the expander finally syncs its cache
to hardware and physically deasserts the reset pin. This entirely bypasses the
hub driver's power_on_delay_us wait and causes a race with the USB host
controller, which could result in enumeration failures upon wake.

> +		vdd-supply = <&reg_mba6ul_3v3>;
> +	};
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260813121250.3993187-1-alexander.stein@ew.tq-group.com?part=2

Re: [PATCH 2/2] ARM: dts: mba6ulx: Add USB hub node

[Alexander Stein]

Am Donnerstag, 13. August 2026, 14:52:22 CEST schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] I2C GPIO expander used as reset-gpios for onboard_usb_dev causes PM phase mismatch, breaking reset timing during resume.
> --
> 
> --- Patch [2]: [PATCH 2/2] ARM: dts: mba6ulx: Add USB hub node ---
> commit 52d9db850f98165215d9ab4ba1bee0bd2993c73e
> Author: Alexander Stein <alexander.stein@ew.tq-group.com>
> 
> ARM: dts: mba6ulx: Add USB hub node
> 
> This commit replaces a fixed regulator previously used for USB hub reset with
> a proper onboard USB hub device node that utilizes reset-gpios.
> 
> > diff --git a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
> > index 244376b38835a..322fbd82531e6 100644
> > --- a/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
> > +++ b/arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi
> 
> [ ... ]
> 
> > @@ -379,10 +369,18 @@ &usbotg1 {
> >  /* 7-port usb hub */
> >  /* id, pwr, oc pins not connected */
> >  &usbotg2 {
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> >  	disable-over-current;
> > -	vbus-supply = <&reg_otg2vbus_5v0>;
> >  	dr_mode = "host";
> >  	status = "okay";
> > +
> > +	hub_2_0: hub@1 {
> > +		compatible = "usb424,2517";
> > +		reg = <1>;
> > +		reset-gpios = <&expander_out1 0 GPIO_ACTIVE_LOW>;
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> [Severity: High]
> Does using an I2C GPIO expander for the onboard USB hub reset cause a PM phase
> mismatch during system suspend and resume?
> 
> The onboard_usb_dev driver uses suspend_late() and resume_early() power
> management operations, while standard I2C GPIO expanders typically use normal
> suspend() and resume() operations.
> 
> During system suspend, the expander suspends first (in the suspend phase) and
> puts its regmap into cache_only mode. When the hub driver suspends later in
> suspend_late(), its reset GPIO assertion is merely cached.
> 
> During system resume, the hub driver attempts to deassert the reset in
> resume_early() and waits for power_on_delay_us. Because the expander is
> still in cache_only mode, the physical pin remains unchanged. 
> 
> Later, during the normal resume phase, the expander finally syncs its cache
> to hardware and physically deasserts the reset pin. This entirely bypasses the
> hub driver's power_on_delay_us wait and causes a race with the USB host
> controller, which could result in enumeration failures upon wake.

Mh, my platform doesn't support system suspend/wakeup (yet?).
So there is nothing I could test here.
On the other hand this sounds like a generic problem other if not all
platforms affected as well if the reset is attached to a GPIO expander.

Any suggestion?

Best regards,
Alexander

> > +		vdd-supply = <&reg_mba6ul_3v3>;
> > +	};
> >  };
> 
> 


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/