[PATCH v3 1/3] usb: dwc3: drd: extend dwc3_pre_set_role() to extcon and otg usecase

[PATCH v3 1/3] usb: dwc3: drd: extend dwc3_pre_set_role() to extcon and otg usecase

[Xu Yang]

Call dwc3_pre_set_role() to support both extcon and otg usecase, so that
the glue driver can do proper action in case of role changes.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

---
Changes in v3:
 - no changes
Changes in v2:
 - improve commit message
 - add Rb and Ab tag
---
 drivers/usb/dwc3/drd.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index 589bbeb27454..031cfd12300a 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -381,6 +381,7 @@ void dwc3_otg_update(struct dwc3 *dwc, bool ignore_idstatus)
 		dwc3_otgregs_init(dwc);
 		dwc3_otg_host_init(dwc);
 		spin_unlock_irqrestore(&dwc->lock, flags);
+		dwc3_pre_set_role(dwc, USB_ROLE_HOST);
 		ret = dwc3_host_init(dwc);
 		if (ret) {
 			dev_err(dwc->dev, "failed to initialize host\n");
@@ -406,6 +407,7 @@ void dwc3_otg_update(struct dwc3 *dwc, bool ignore_idstatus)
 			otg_set_vbus(dwc->usb2_phy->otg, false);
 		if (dwc->usb2_generic_phy[0])
 			phy_set_mode(dwc->usb2_generic_phy[0], PHY_MODE_USB_DEVICE);
+		dwc3_pre_set_role(dwc, USB_ROLE_DEVICE);
 		ret = dwc3_gadget_init(dwc);
 		if (ret)
 			dev_err(dwc->dev, "failed to initialize peripheral\n");
@@ -433,10 +435,12 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
 			     unsigned long event, void *ptr)
 {
 	struct dwc3 *dwc = container_of(nb, struct dwc3, edev_nb);
+	u32 mode = event ? DWC3_GCTL_PRTCAP_HOST : DWC3_GCTL_PRTCAP_DEVICE;
+	enum usb_role role = mode == DWC3_GCTL_PRTCAP_HOST ?
+				     USB_ROLE_HOST : USB_ROLE_DEVICE;
 
-	dwc3_set_mode(dwc, event ?
-		      DWC3_GCTL_PRTCAP_HOST :
-		      DWC3_GCTL_PRTCAP_DEVICE);
+	dwc3_pre_set_role(dwc, role);
+	dwc3_set_mode(dwc, mode);
 
 	return NOTIFY_DONE;
 }
-- 
2.34.1

[PATCH v3 2/3] usb: dwc3: imx8mp: rename dwc3 to dwc3_pdev in struct dwc3_imx8mp

[Xu Yang]

It's confuse to let "dwc3" represent a platform_device, because "dwc3"
may also represent a dwc3 core structure. Rename it for better
distinction.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

---
Changes in v3:
 - add R-b, A-b tag
Changes in v2:
 - new patch
---
 drivers/usb/dwc3/dwc3-imx8mp.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-imx8mp.c b/drivers/usb/dwc3/dwc3-imx8mp.c
index 45c276a31d84..b0f5266af954 100644
--- a/drivers/usb/dwc3/dwc3-imx8mp.c
+++ b/drivers/usb/dwc3/dwc3-imx8mp.c
@@ -51,7 +51,7 @@
 
 struct dwc3_imx8mp {
 	struct device			*dev;
-	struct platform_device		*dwc3;
+	struct platform_device		*dwc3_pdev;
 	void __iomem			*hsio_blk_base;
 	void __iomem			*glue_base;
 	struct clk			*hsio_clk;
@@ -100,7 +100,7 @@ static void imx8mp_configure_glue(struct dwc3_imx8mp *dwc3_imx)
 static void dwc3_imx8mp_wakeup_enable(struct dwc3_imx8mp *dwc3_imx,
 				      pm_message_t msg)
 {
-	struct dwc3	*dwc3 = platform_get_drvdata(dwc3_imx->dwc3);
+	struct dwc3	*dwc3 = platform_get_drvdata(dwc3_imx->dwc3_pdev);
 	u32		val;
 
 	if (!dwc3)
@@ -142,7 +142,7 @@ static const struct software_node dwc3_imx8mp_swnode = {
 static irqreturn_t dwc3_imx8mp_interrupt(int irq, void *_dwc3_imx)
 {
 	struct dwc3_imx8mp	*dwc3_imx = _dwc3_imx;
-	struct dwc3		*dwc = platform_get_drvdata(dwc3_imx->dwc3);
+	struct dwc3		*dwc = platform_get_drvdata(dwc3_imx->dwc3_pdev);
 
 	if (!dwc3_imx->pm_suspended)
 		return IRQ_HANDLED;
@@ -233,8 +233,8 @@ static int dwc3_imx8mp_probe(struct platform_device *pdev)
 		goto remove_swnode;
 	}
 
-	dwc3_imx->dwc3 = of_find_device_by_node(dwc3_np);
-	if (!dwc3_imx->dwc3) {
+	dwc3_imx->dwc3_pdev = of_find_device_by_node(dwc3_np);
+	if (!dwc3_imx->dwc3_pdev) {
 		dev_err(dev, "failed to get dwc3 platform device\n");
 		err = -ENODEV;
 		goto depopulate;
@@ -253,7 +253,7 @@ static int dwc3_imx8mp_probe(struct platform_device *pdev)
 	return 0;
 
 put_dwc3:
-	put_device(&dwc3_imx->dwc3->dev);
+	put_device(&dwc3_imx->dwc3_pdev->dev);
 depopulate:
 	of_platform_depopulate(dev);
 remove_swnode:
@@ -270,7 +270,7 @@ static void dwc3_imx8mp_remove(struct platform_device *pdev)
 	struct dwc3_imx8mp *dwc3_imx = platform_get_drvdata(pdev);
 	struct device *dev = &pdev->dev;
 
-	put_device(&dwc3_imx->dwc3->dev);
+	put_device(&dwc3_imx->dwc3_pdev->dev);
 
 	pm_runtime_get_sync(dev);
 	of_platform_depopulate(dev);
@@ -296,7 +296,7 @@ static int dwc3_imx8mp_suspend(struct dwc3_imx8mp *dwc3_imx, pm_message_t msg)
 
 static int dwc3_imx8mp_resume(struct dwc3_imx8mp *dwc3_imx, pm_message_t msg)
 {
-	struct dwc3	*dwc = platform_get_drvdata(dwc3_imx->dwc3);
+	struct dwc3	*dwc = platform_get_drvdata(dwc3_imx->dwc3_pdev);
 	int ret = 0;
 
 	if (!dwc3_imx->pm_suspended)
-- 
2.34.1

[PATCH v3 3/3] usb: dwc3: imx8mp: disable auto suspend for host role

[Xu Yang]

Do dwc3 core auto suspend enable for device and disable for host
, this can make sure dwc3 core device auto suspend setting is
correct all the time, the background of disable dwc3 core device
auto suspend is to make its parent device suspend immediately
(so wakeup enable can be enabled) after xhci-plat device suspended,
for device mode, we keep the dwc3 core device auto suspend is to
give some wait for gadget to be enumerated.

Note: It's a temporary solution until we switch to using the new
      flatten model.

Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

---
Changes in v3:
 - add A-b tag
Changes in v2:
 - add a note suggested by Thinh
---
 drivers/usb/dwc3/dwc3-imx8mp.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-imx8mp.c b/drivers/usb/dwc3/dwc3-imx8mp.c
index b0f5266af954..b3d7252bd910 100644
--- a/drivers/usb/dwc3/dwc3-imx8mp.c
+++ b/drivers/usb/dwc3/dwc3-imx8mp.c
@@ -158,11 +158,31 @@ static irqreturn_t dwc3_imx8mp_interrupt(int irq, void *_dwc3_imx)
 	return IRQ_HANDLED;
 }
 
+static void dwc3_imx_pre_set_role(struct dwc3 *dwc, enum usb_role role)
+{
+	if (role == USB_ROLE_HOST)
+		/*
+		 * For xhci host, we need disable dwc core auto
+		 * suspend, because during this auto suspend delay(5s),
+		 * xhci host RUN_STOP is cleared and wakeup is not
+		 * enabled, if device is inserted, xhci host can't
+		 * response the connection.
+		 */
+		pm_runtime_dont_use_autosuspend(dwc->dev);
+	else
+		pm_runtime_use_autosuspend(dwc->dev);
+}
+
+struct dwc3_glue_ops dwc3_imx_glue_ops = {
+	.pre_set_role   = dwc3_imx_pre_set_role,
+};
+
 static int dwc3_imx8mp_probe(struct platform_device *pdev)
 {
 	struct device		*dev = &pdev->dev;
 	struct device_node	*node = dev->of_node;
 	struct dwc3_imx8mp	*dwc3_imx;
+	struct dwc3		*dwc3;
 	struct resource		*res;
 	int			err, irq;
 
@@ -240,6 +260,17 @@ static int dwc3_imx8mp_probe(struct platform_device *pdev)
 		goto depopulate;
 	}
 
+	dwc3 = platform_get_drvdata(dwc3_imx->dwc3_pdev);
+	if (!dwc3) {
+		err = dev_err_probe(dev, -EPROBE_DEFER, "failed to get dwc3 platform data\n");
+		goto depopulate;
+	}
+
+	dwc3->glue_ops = &dwc3_imx_glue_ops;
+
+	if (dwc3->dr_mode == USB_DR_MODE_HOST)
+		pm_runtime_dont_use_autosuspend(dwc3->dev);
+
 	err = devm_request_threaded_irq(dev, irq, NULL, dwc3_imx8mp_interrupt,
 					IRQF_ONESHOT, dev_name(dev), dwc3_imx);
 	if (err) {
-- 
2.34.1

Re: [PATCH v3 3/3] usb: dwc3: imx8mp: disable auto suspend for host role

[Franz Schnyder]

On Thu, Jan 08, 2026 at 04:14:33PM +0800, Xu Yang wrote:
> Do dwc3 core auto suspend enable for device and disable for host
> , this can make sure dwc3 core device auto suspend setting is
> correct all the time, the background of disable dwc3 core device
> auto suspend is to make its parent device suspend immediately
> (so wakeup enable can be enabled) after xhci-plat device suspended,
> for device mode, we keep the dwc3 core device auto suspend is to
> give some wait for gadget to be enumerated.
> 
> Note: It's a temporary solution until we switch to using the new
>       flatten model.
> 
> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>

Hi Xu,

We have a kernel issue introduced by this patch on an iMX95, where we 
use the dwc3 usb as otg. This appears to be due to a race condition that
occurs during probe, when the parent attempts to access the driver data
from the dwc3 child. I saw your work on the new flattened model driver 
for the iMX SoCs and that it will soon be applied to the iMX95 as well. 
Does this mean that the issue shown below should no longer appear, as 
there will be no parent/child dependency?

Do you think there are any actions needed on this patch?

Here the warning with decoded trace:

[    6.905882] ------------[ cut here ]------------
[    6.910518] WARNING: drivers/base/core.c:1640 at device_del+0x2b4/0x384, CPU#4: 5/87
[    6.919309] Modules linked in: libaes(+) tcpci(+) ulpi tcpm phy_fsl_imx8mq_usb(+) gf128mul snd_soc_simple_card(+) ehci_hcd imx_pc4
[    6.964627] CPU: 4 UID: 0 PID: 87 Comm: kworker/u24:5 Not tainted 7.0.0-rc1+ #2 PREEMPT
[    6.972716] Hardware name: Aquila iMX95 on Aquila Development Board (DT)
[    6.979409] Workqueue: events_unbound deferred_probe_work_func
[    6.985247] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    6.992199] pc : device_del (drivers/base/core.c:1640 drivers/base/core.c:3882)
[    6.996028] lr : device_del (drivers/base/core.c:1634 drivers/base/core.c:3882)
[    6.999865] sp : ffff800080b339f0
[    7.003169] x29: ffff800080b339f0 x28: 0000000000000000 x27: 0000000000000000
[    7.010295] x26: ffff00008004ac28 x25: ffff0001ff067610 x24: ffff00008befdcc0
[    7.017427] x23: ffff000080ad8810 x22: 0000000004208060 x21: ffffa5bb53ea78f0
[    7.024560] x20: ffff00008befdc10 x19: ffff00008befdcb8 x18: 0000000000000000
[    7.031693] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[    7.038825] x14: 0000000000000004 x13: ffff000080129910 x12: 0000000000000000
[    7.045958] x11: ffff0000822ac0e8 x10: ffff0000822ac000 x9 : ffff000080129910
[    7.053090] x8 : ffff0000822ac028 x7 : 0000000000000000 x6 : ffff0000822af458
[    7.060223] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[    7.067356] x2 : ffff00008253e580 x1 : 0000000000000003 x0 : ffff0000895d1400
[    7.074485] Call trace:
[    7.076923]  device_del (drivers/base/core.c:1640 drivers/base/core.c:3882) (P)
[    7.080754]  platform_device_del.part.0 (drivers/base/platform.c:794)
[    7.085458]  platform_device_unregister (drivers/base/platform.c:593 drivers/base/platform.c:835)
[    7.090164]  of_platform_device_destroy (drivers/of/platform.c:621 drivers/of/platform.c:607)
[    7.094950]  device_for_each_child_reverse (drivers/base/core.c:4048)
[    7.099922]  of_platform_depopulate (./include/linux/of.h:208 drivers/of/platform.c:644 drivers/of/platform.c:640)
[    7.104282] dwc3_imx8mp_probe (drivers/usb/dwc3/dwc3-imx8mp.c:291) dwc3_imx8mp
[    7.109588]  platform_probe (drivers/base/platform.c:1449)
[    7.113260]  really_probe (drivers/base/dd.c:583 drivers/base/dd.c:661)
[    7.116833]  __driver_probe_device (drivers/base/dd.c:803)
[    7.121199]  driver_probe_device (drivers/base/dd.c:833)
[    7.125385]  __device_attach_driver (drivers/base/dd.c:962)
[    7.129831]  bus_for_each_drv (drivers/base/bus.c:500)
[    7.133663]  __device_attach (drivers/base/dd.c:1035)
[    7.137494]  device_initial_probe (drivers/base/dd.c:1088)
[    7.141671]  bus_probe_device (drivers/base/bus.c:576)
[    7.145502]  deferred_probe_work_func (drivers/base/dd.c:125 (discriminator 14))
[    7.150035]  process_one_work (kernel/workqueue.c:3286)
[    7.154047]  worker_thread (kernel/workqueue.c:3352 kernel/workqueue.c:3439)
[    7.157791]  kthread (kernel/kthread.c:467)
[    7.161030]  ret_from_fork (arch/arm64/kernel/entry.S:861)
[    7.164610] ---[ end trace 0000000000000000 ]---

Best regards,

Franz

Re: [PATCH v3 3/3] usb: dwc3: imx8mp: disable auto suspend for host role

[Xu Yang]

Hi Franz,

On Thu, May 07, 2026 at 12:46:08PM +0200, Franz Schnyder wrote:
> On Thu, Jan 08, 2026 at 04:14:33PM +0800, Xu Yang wrote:
> > Do dwc3 core auto suspend enable for device and disable for host
> > , this can make sure dwc3 core device auto suspend setting is
> > correct all the time, the background of disable dwc3 core device
> > auto suspend is to make its parent device suspend immediately
> > (so wakeup enable can be enabled) after xhci-plat device suspended,
> > for device mode, we keep the dwc3 core device auto suspend is to
> > give some wait for gadget to be enumerated.
> > 
> > Note: It's a temporary solution until we switch to using the new
> >       flatten model.
> > 
> > Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> 
> Hi Xu,
> 
> We have a kernel issue introduced by this patch on an iMX95, where we 
> use the dwc3 usb as otg. This appears to be due to a race condition that
> occurs during probe, when the parent attempts to access the driver data
> from the dwc3 child. I saw your work on the new flattened model driver 
> for the iMX SoCs and that it will soon be applied to the iMX95 as well. 
> Does this mean that the issue shown below should no longer appear, as 
> there will be no parent/child dependency?
> 
> Do you think there are any actions needed on this patch?

Thanks for the report.

It's strange that link->status is not DL_STATE_DORMANT or DL_STATE_NONE at
the time which means the device core may not properly unbind consumer devices
or handle something. The patch does a simple thing so the issue may not come
from the patch itself.

1639:	list_for_each_entry_safe_reverse(link, ln, &dev->links.consumers, s_node) {
1640:		WARN_ON(link->status != DL_STATE_DORMANT &&
1641:			link->status != DL_STATE_NONE);
1642:		__device_link_del(&link->kref);
1643:	}

Which kernel and dtb are you using? If it's a downstream repo, how do the USB
controller and related DTS nodes look like?

Does the issue easily happen? Does dwc3_imx8mp_probe() eventually succeed?

Could you add "#define DEBUG" in the head of drivers/base/core.c, rerun and share the log?

Yes, if you use the new driver, I think this issue won't happen at all.

Thanks,
Xu Yang

Re: [PATCH v3 3/3] usb: dwc3: imx8mp: disable auto suspend for host role

[Franz Schnyder]

Hi Xu,

On Fri, May 08, 2026 at 06:54:40PM +0800, Xu Yang wrote:
> It's strange that link->status is not DL_STATE_DORMANT or DL_STATE_NONE at
> the time which means the device core may not properly unbind consumer devices
> or handle something. The patch does a simple thing so the issue may not come
> from the patch itself.
> 
> 1639:	list_for_each_entry_safe_reverse(link, ln, &dev->links.consumers, s_node) {
> 1640:		WARN_ON(link->status != DL_STATE_DORMANT &&
> 1641:			link->status != DL_STATE_NONE);
> 1642:		__device_link_del(&link->kref);
> 1643:	}
> 
> Which kernel and dtb are you using? If it's a downstream repo, how do the USB
> controller and related DTS nodes look like?

I was using kernel version 7.1-rc2 and noticed it while working on 
sending the Aquila iMX95 upstream.
https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-2-69c8ee1c5413@toradex.com/
> 
> Does the issue easily happen? Does dwc3_imx8mp_probe() eventually succeed?

I did various boot attempts with the commit reverted and couldn't 
reproduce the issue. With the commit I ran into the issue in about one 
third of all boot attempts. So most of the time dwc3_imx8mp_prove 
actually succeeds.

> 
> Could you add "#define DEBUG" in the head of drivers/base/core.c, rerun and share the log?
>
I can provide you with the data next week.
 
> Yes, if you use the new driver, I think this issue won't happen at all.
> 
So once your work is merged in the imx95.dtsi we should be fine.

> Thanks,
> Xu Yang

Best regards,

Franz

Re: [PATCH v3 3/3] usb: dwc3: imx8mp: disable auto suspend for host role

[Francesco Dolcini]

On Fri, May 08, 2026 at 06:04:49PM +0200, Franz Schnyder wrote:
> On Fri, May 08, 2026 at 06:54:40PM +0800, Xu Yang wrote:
> > It's strange that link->status is not DL_STATE_DORMANT or DL_STATE_NONE at
> > the time which means the device core may not properly unbind consumer devices
> > or handle something. The patch does a simple thing so the issue may not come
> > from the patch itself.
> > 
> > 1639:	list_for_each_entry_safe_reverse(link, ln, &dev->links.consumers, s_node) {
> > 1640:		WARN_ON(link->status != DL_STATE_DORMANT &&
> > 1641:			link->status != DL_STATE_NONE);
> > 1642:		__device_link_del(&link->kref);
> > 1643:	}
> > 
> > Which kernel and dtb are you using? If it's a downstream repo, how do the USB
> > controller and related DTS nodes look like?
> 
> I was using kernel version 7.1-rc2 and noticed it while working on 
> sending the Aquila iMX95 upstream.
> https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-2-69c8ee1c5413@toradex.com/
> > 
> > Does the issue easily happen? Does dwc3_imx8mp_probe() eventually succeed?
> 
> I did various boot attempts with the commit reverted and couldn't 
> reproduce the issue. With the commit I ran into the issue in about one 
> third of all boot attempts. So most of the time dwc3_imx8mp_prove 
> actually succeeds.

...

> > Yes, if you use the new driver, I think this issue won't happen at all.
> > 
> So once your work is merged in the imx95.dtsi we should be fine.

To me it looks like a regression that should be taken care of.

Maybe not relevant for aquila imx95, where you did reproduce it (the reason is
that aquila imx95 is not in mainline, yet), but from the USB point of view this
board is very similar to other boards using the i.MX95 SoC that are therefore
likely affected.

Francesco