[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

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

[Xu Yang]

On Fri, May 08, 2026 at 06:04:49PM +0200, Franz Schnyder wrote:
> 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/

I don't see any special configuration in your DTS. I modified my configuration
to match yours, but I can't reproduce the issue. I also created some fault points
during the probe process, but still didn't encounter the issue.

> > 
> > 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.

OK. I mean, does dwc3_imx8mp_probe() still succeed after the kernel dumps
at the end?

> 
> > 
> > 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.

OK. More debug information will be helpful.

Thanks,
Xu Yang

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

[Xu Yang]

On Sat, May 09, 2026 at 02:46:44PM +0200, Francesco Dolcini wrote:
> 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.

Sure. I can't reproduce the issue now.
I'll research it when more information is given.

Thanks,
Xu Yang

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

[Franz Schnyder]

Hi Xu

On Tue, May 12, 2026 at 05:53:57PM +0800, Xu Yang wrote:
> 
> OK. I mean, does dwc3_imx8mp_probe() still succeed after the kernel dumps
> at the end?
Ah yes, afterwards it still succeeds.

> 
> OK. More debug information will be helpful.
> 

I've attached the logs below with and without the commit. looking at 
what happens before the warning I think the problem is that after probe
deferral the depopulate path races with the device link state changes 
from the fw_devlink cycle fixup.

One important thing to mention is, that we build dwc3 and typec as modules.
If I build them as built-in I can't reproduce the kernel warning so far. 

Logs whith commit present and when the warning appears:

  [    6.405710] device: '4c100000.usb': device_add
  [    6.414620] ----- cycle: start -----
  [    6.414626] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.414640] ----- cycle: start -----
  [    6.414643] /soc/phy@4c1f0040: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.414661] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/phy@4c1f0040
  [    6.414671] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
  [    6.414680] ----- cycle: end -----
  [    6.414683] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: Fixed dependency cycle(s) with /soc/usb@4c010010/usb@4c100000
  [    6.414700] device: 'platform:4c100000.usb--i2c:1-0052': device_add
  [    6.414783] i2c 1-0052: Linked as a sync state only consumer to 4c100000.usb
  [    6.414790] ----- cycle: start -----
  [    6.414793] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
  [    6.414805] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.414814] ----- cycle: end -----
  [    6.414816] /soc/usb@4c010010/usb@4c100000: Fixed dependency cycle(s) with /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.414827] ----- cycle: start -----
  [    6.414829] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
  [    6.414839] /soc/phy@4c1f0040: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.414857] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/phy@4c1f0040
  [    6.414864] ----- cycle: end -----
  [    6.414866] /soc/usb@4c010010/usb@4c100000: Fixed dependency cycle(s) with /soc/phy@4c1f0040
  [    6.414880] device: 'platform:4c1f0040.phy--platform:4c100000.usb': device_add
  [    6.414943] platform 4c100000.usb: Linked as a sync state only consumer to 4c1f0040.phy
  [    6.414947] /soc/usb@4c010010/usb@4c100000 Dropping the fwnode link to /soc/phy@4c1f0040
  [    6.414956] platform 4c100000.usb: Not linking /interrupt-controller@48000000 - might never become dev
  [    6.414962] /soc/usb@4c010010/usb@4c100000 Dropping the fwnode link to /interrupt-controller@48000000
  [    6.414979] device: 'scmi_protocol:scmi_dev.7--platform:4c100000.usb': device_add
  [    6.415027] devices_kset: Moving 4c100000.usb to end of list
  [    6.415032] platform 4c100000.usb: Linked as a consumer to scmi_dev.7
  [    6.415035] /soc/usb@4c010010/usb@4c100000 Dropping the fwnode link to /firmware/scmi/protocol@14
  [    6.416216] imx8mp-dwc3 4c010010.usb: error -EPROBE_DEFER: failed to get dwc3 platform data
  [    6.416310] platform 4c100000.usb: Dropping the link to scmi_dev.7
  [    6.416317] device: 'scmi_protocol:scmi_dev.7--platform:4c100000.usb': device_unregister
  [    6.416680] platform 4c100000.usb: Dropping the link to 4c1f0040.phy
  [    6.416687] device: 'platform:4c1f0040.phy--platform:4c100000.usb': device_unregister
  [    6.416892] i2c 1-0052: Dropping the link to 4c100000.usb
  [    6.416898] device: 'platform:4c100000.usb--i2c:1-0052': device_unregister
  [    6.419266] devices_kset: Moving 4c010010.usb to end of list
  [    6.454423] device: 'phy-4c1f0040.phy.0': device_add
  [    6.454545] device: '4c100000.usb': device_add
  [    6.454659] ----- cycle: start -----
  [    6.454664] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.454680] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
  [    6.454689] ----- cycle: end -----
  [    6.454692] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: Fixed dependency cycle(s) with /soc/usb@4c010010/usb@4c100000
  [    6.454706] device: 'platform:4c100000.usb--i2c:1-0052': device_add
  [    6.454763] i2c 1-0052: Linked as a sync state only consumer to 4c100000.usb
  [    6.454770] ----- cycle: start -----
  [    6.454773] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
  [    6.454786] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.454795] ----- cycle: end -----
  [    6.454797] /soc/usb@4c010010/usb@4c100000: Fixed dependency cycle(s) with /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.455132] imx8mp-dwc3 4c010010.usb: error -EPROBE_DEFER: failed to get dwc3 platform data
  [    6.455211] i2c 1-0052: Dropping the link to 4c100000.usb
  [    6.455215] device: 'platform:4c100000.usb--i2c:1-0052': device_unregister
  [    6.455831] devices_kset: Moving 4c010010.usb to end of list
  [    6.456354] device: '4c100000.usb': device_add
  [    6.456458] ----- cycle: start -----
  [    6.456463] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.456479] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
  [    6.456488] ----- cycle: end -----
  [    6.456491] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: Fixed dependency cycle(s) with /soc/usb@4c010010/usb@4c100000
  [    6.456505] device: 'platform:4c100000.usb--i2c:1-0052': device_add
  [    6.456563] i2c 1-0052: Linked as a sync state only consumer to 4c100000.usb
  [    6.456571] ----- cycle: start -----
  [    6.456573] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
  [    6.456586] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.456595] ----- cycle: end -----
  [    6.456598] /soc/usb@4c010010/usb@4c100000: Fixed dependency cycle(s) with /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.456940] imx8mp-dwc3 4c010010.usb: error -EPROBE_DEFER: failed to get dwc3 platform data
  [    6.457022] i2c 1-0052: Dropping the link to 4c100000.usb
  [    6.457026] device: 'platform:4c100000.usb--i2c:1-0052': device_unregister
  [    6.474614] devices_kset: Moving 4c010010.usb to end of list
  [    6.522012] device: '4c100000.usb': device_add
  [    6.522299] ----- cycle: start -----
  [    6.522317] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.522335] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
  [    6.522347] ----- cycle: end -----
  [    6.522454] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: Fixed dependency cycle(s) with /soc/usb@4c010010/usb@4c100000
  [    6.533826] device: 'platform:4c100000.usb--i2c:1-0052': device_add
  [    6.534139] i2c 1-0052: Linked as a sync state only consumer to 4c100000.usb
  [    6.534164] ----- cycle: start -----
  [    6.534169] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
  [    6.534192] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.534203] ----- cycle: end -----
  [    6.534207] /soc/usb@4c010010/usb@4c100000: Fixed dependency cycle(s) with /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.545615] device: 'regulator:regulator.4--platform:4c1f0040.phy': device_add
  [    6.548513] devices_kset: Moving 4c1f0040.phy to end of list
  [    6.548537] devices_kset: Moving phy-4c1f0040.phy.0 to end of list
  [    6.548547] imx8mq-usb-phy 4c1f0040.phy: Linked as a consumer to regulator.4
  [    6.549386] device: '4c1f0040.phy-switch': device_add
  [    6.549395] imx8mp-dwc3 4c010010.usb: error -EPROBE_DEFER: failed to get dwc3 platform data
  [    6.558846] /soc/phy@4c1f0040 Dropping the fwnode link to /soc/bus@44000000/i2c@44350000/tcpc@52/connector
  [    6.568591] imx_usb 4c200000.usb: Linked as a consumer to regulator.5
  [    6.575430] ------------[ cut here ]------------
  [    6.580063] WARNING: drivers/base/core.c:1640 at device_del+0x2bc/0x38c, CPU#1: kworker/u24:7/85
  [    6.588847] Modules linked in: tcpci(+) tcpm gf128mul aead snd_soc_fsl_sai(+) fsl_imx9_ddr_perf ci_hdrc_imx(+) ina2xx(+) amc6821(+) imx_pcm_dma
  snd_soc4
  [    6.636591] CPU: 1 UID: 0 PID: 85 Comm: kworker/u24:7 Not tainted 7.1.0-rc4+ #14 PREEMPT
  [    6.644767] Hardware name: Aquila iMX95 on Aquila Development Board (DT)
  [    6.651466] Workqueue: events_unbound deferred_probe_work_func
  [    6.657300] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  [    6.664250] pc : device_del+0x2bc/0x38c
  [    6.668094] lr : device_del+0x18c/0x38c
  [    6.671934] sp : ffff800080b0b9b0
  [    6.675237] x29: ffff800080b0b9d0 x28: 0000000000000000 x27: 0000000000000000
  [    6.682372] x26: 0000000000000000 x25: 0000000000000000 x24: ffff000086c15cc8
  [    6.689504] x23: ffff000086c15cc0 x22: ffff000080a71010 x21: 0000000004208060
  [    6.696637] x20: ffffd5f0e544ab58 x19: ffff000086c15c10 x18: 0000000000000000
  [    6.703770] x17: 0000000000000000 x16: 0000000000000003 x15: 0000000000000400
  [    6.710902] x14: ffff000081b3e7d0 x13: 0000000000000000 x12: ffff00008316d380
  [    6.718035] x11: ffff00008012d910 x10: ffff00008316d240 x9 : 0000000000000017
  [    6.725175] x8 : ffff800080b0b8f8 x7 : 0000000000000000 x6 : fefefefefefeff64
  [    6.732301] x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffff00008746ff00
  [    6.739433] x2 : ffff000081b3e740 x1 : 0000000000000003 x0 : ffff000086c15800
  [    6.746573] Call trace:
  [    6.749024]  device_del+0x2bc/0x38c (P)
  [    6.752857]  platform_device_del+0x2c/0x9c
  [    6.756947]  platform_device_unregister+0x14/0x3c
  [    6.761652]  of_platform_device_destroy+0xf0/0x100
  [    6.766438]  device_for_each_child_reverse+0x70/0xc8
  [    6.771402]  of_platform_depopulate+0x34/0x78
  [    6.775761]  dwc3_imx8mp_probe+0x234/0x3c0 [dwc3_imx8mp]
  [    6.781073]  platform_probe+0x5c/0xa4
  [    6.784738]  really_probe+0xc0/0x3dc
  [    6.788312]  __driver_probe_device+0x88/0x1a0
  [    6.792663]  driver_probe_device+0x3c/0x11c
  [    6.796840]  __device_attach_driver+0xbc/0x17c
  [    6.801281]  bus_for_each_drv+0x88/0xe8
  [    6.805108]  __device_attach+0x9c/0x1cc
  [    6.808939]  device_initial_probe+0x54/0x60
  [    6.810462] ci_hdrc ci_hdrc.0: EHCI Host Controller
  [    6.813112]  bus_probe_device+0x34/0xa0
  [    6.821216] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
  [    6.821796]  deferred_probe_work_func+0xa8/0x104
  [    6.821802]  process_one_work+0x15c/0x2a0
  [    6.821810]  worker_thread+0x18c/0x300
  [    6.821814]  kthread+0x118/0x124
  [    6.821822]  ret_from_fork+0x10/0x20
  [    6.833454] ---[ end trace 0000000000000000 ]--

Log with commit reverted:

[    6.370196] device: '4c100000.usb': device_add
[    6.378088] ----- cycle: start -----
[    6.378095] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
[    6.378109] ----- cycle: start -----
[    6.378111] /soc/phy@4c1f0040: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
[    6.378129] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/phy@4c1f0040
[    6.378138] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
[    6.378148] ----- cycle: end -----
[    6.378151] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: Fixed dependency cycle(s) with /soc/usb@4c010010/usb@4c100000
[    6.378166] device: 'platform:4c100000.usb--i2c:1-0052': device_add
[    6.378233] i2c 1-0052: Linked as a sync state only consumer to 4c100000.usb
[    6.378240] ----- cycle: start -----
[    6.378243] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
[    6.378255] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
[    6.378265] ----- cycle: end -----
[    6.378267] /soc/usb@4c010010/usb@4c100000: Fixed dependency cycle(s) with /soc/bus@44000000/i2c@44350000/tcpc@52/connector
[    6.378277] ----- cycle: start -----
[    6.378280] /soc/bus@44000000/i2c@44350000/tcpc@52/connector: cycle: depends on /soc/usb@4c010010/usb@4c100000
[    6.378289] /soc/phy@4c1f0040: cycle: depends on /soc/bus@44000000/i2c@44350000/tcpc@52/connector
[    6.378298] /soc/usb@4c010010/usb@4c100000: cycle: depends on /soc/phy@4c1f0040
[    6.378305] ----- cycle: end -----
[    6.378307] /soc/usb@4c010010/usb@4c100000: Fixed dependency cycle(s) with /soc/phy@4c1f0040
[    6.378317] device: 'platform:4c1f0040.phy--platform:4c100000.usb': device_add
[    6.378365] platform 4c100000.usb: Linked as a sync state only consumer to 4c1f0040.phy
[    6.378369] /soc/usb@4c010010/usb@4c100000 Dropping the fwnode link to /soc/phy@4c1f0040
[    6.378378] platform 4c100000.usb: Not linking /interrupt-controller@48000000 - might never become dev
[    6.378383] /soc/usb@4c010010/usb@4c100000 Dropping the fwnode link to /interrupt-controller@48000000
[    6.378402] device: 'scmi_protocol:scmi_dev.7--platform:4c100000.usb': device_add
[    6.378448] devices_kset: Moving 4c100000.usb to end of list
[    6.378454] platform 4c100000.usb: Linked as a consumer to scmi_dev.7
[    6.378457] /soc/usb@4c010010/usb@4c100000 Dropping the fwnode link to /firmware/scmi/protocol@14
[    6.412551] imx8mp-dwc3 4c010010.usb: Dropping the link to 4c1f0040.phy
[    6.420383] device: 'platform:4c1f0040.phy--platform:4c010010.usb': device_unregister
[    6.448740] /soc/phy@4c1f0040 Dropping the fwnode link to /soc/bus@44000000/i2c@44350000/tcpc@52/connector
[    6.455463] /soc/usb@4c010010/usb@4c100000 Dropping the fwnode link to /soc/bus@44000000/i2c@44350000/tcpc@52/connector
[    6.466316] wm8904 1-001a: Linked as a consumer to regulator.2
[    6.467099] device: 'phy-4c1f0040.phy.0': device_add
[    6.467280] device: 'regulator:regulator.4--platform:4c1f0040.phy': device_add
[    6.469337] devices_kset: Moving 4c1f0040.phy to end of list
[    6.477641] devices_kset: Moving phy-4c1f0040.phy.0 to end of list
[    6.477672] imx8mq-usb-phy 4c1f0040.phy: Linked as a consumer to regulator.4
[    6.477755] device: '4c1f0040.phy-switch': device_add
[    6.479392] imx_usb 4c200000.usb: Linked as a consumer to regulator.5
[    6.653448] spi-nor spi0.0: Linked as a consumer to regulator.0
[    6.655937] device: 'phy:phy-4c1f0040.phy.0--platform:4c100000.usb': device_add
[    6.656027] devices_kset: Moving 4c100000.usb to end of list
[    6.656039] dwc3 4c100000.usb: Linked as a consumer to phy-4c1f0040.phy.0
[    6.662812] device: '4c100000.usb': device_add
[    6.665219] device: '4c100000.usb-role-switch': device_add


Kind regards,

Franz

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

[Xu Yang]

On Tue, May 19, 2026 at 10:54:58AM +0200, Franz Schnyder wrote:
> Hi Xu
> 
> On Tue, May 12, 2026 at 05:53:57PM +0800, Xu Yang wrote:
> > 
> > OK. I mean, does dwc3_imx8mp_probe() still succeed after the kernel dumps
> > at the end?
> Ah yes, afterwards it still succeeds.
> 
> > 
> > OK. More debug information will be helpful.
> > 
> 
> I've attached the logs below with and without the commit. looking at 
> what happens before the warning I think the problem is that after probe
> deferral the depopulate path races with the device link state changes 
> from the fw_devlink cycle fixup.
> 
> One important thing to mention is, that we build dwc3 and typec as modules.
> If I build them as built-in I can't reproduce the kernel warning so far. 

Thank your for the information.

It's indeed an important finding. I can reproduce the issue when I build the
driver as modules.

But I guess it's a case that the driver core doesn't handle well. I will
seek help from the driver-core community to see how to improve it.

https://lore.kernel.org/driver-core/DU2PR04MB8822AF9D63FDC335D80DABC08C082@DU2PR04MB8822.eurprd04.prod.outlook.com/T/#u

Thanks,
Xu Yang

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

[Francesco Dolcini]

Hello Xu,

On Wed, May 27, 2026 at 02:33:05PM +0800, Xu Yang wrote:
> On Tue, May 19, 2026 at 10:54:58AM +0200, Franz Schnyder wrote:
> > On Tue, May 12, 2026 at 05:53:57PM +0800, Xu Yang wrote:
> > I've attached the logs below with and without the commit. looking at 
> > what happens before the warning I think the problem is that after probe
> > deferral the depopulate path races with the device link state changes 
> > from the fw_devlink cycle fixup.
> > 
> > One important thing to mention is, that we build dwc3 and typec as modules.
> > If I build them as built-in I can't reproduce the kernel warning so far. 
> 
> Thank your for the information.
> 
> It's indeed an important finding. I can reproduce the issue when I build the
> driver as modules.

Just a head-up on this

7.2.0-rc3 is not ok on this regard

```
[    6.285930] WARNING: /usr/src/kernel/drivers/base/core.c:1706 at device_del+0x2b4/0x388, CPU#5: (udev-worker)/409
[    6.285950] Modules linked in: ulpi(+) ehci_hcd amc6821(+) nvmem_imx_ocotp_ele tcpci(+) tcpm roles phy_fsl_imx8mq_usb usbmisc_imx ina2xx typec dwc3_imx8mp(+) lm75 imx93_adc spi_nxp_fspi i2c_mux_pca954x svc_i3c_master i3c flexcan spi_fsl_lpspi can_dev pwm_imx_tpm gpio_keys display_connector evdev fuse autofs4
[    6.286031] CPU: 5 UID: 0 PID: 409 Comm: (udev-worker) Not tainted 7.2.0-rc3-0.0.0-devel #1 PREEMPT
[    6.286039] Hardware name: Aquila iMX95 on Aquila Development Board (DT)
[    6.286044] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    6.286050] pc : device_del+0x2b4/0x388
[    6.286057] lr : device_del+0x1b8/0x388
[    6.286063] sp : ffff80008364b740
[    6.286067] x29: ffff80008364b760 x28: 000000000000000c x27: ffff800081347ea8
[    6.286078] x26: 0000000000000000 x25: 0000000000000000 x24: ffff000087ae28c8
[    6.286088] x23: ffff000087ae28c0 x22: ffff000080a6c010 x21: 0000000000400140
[    6.286099] x20: ffff8000814c8e60 x19: ffff000087ae2810 x18: 0000000000000000
[    6.286110] x17: 0000000000000000 x16: 00000000000017fb x15: 0003a7018ef1930c
[    6.286120] x14: 0000000000000225 x13: ffff800080d6f068 x12: 0000000000000000
[    6.286130] x11: 00000000000000c0 x10: 0000000000000a30 x9 : 000000000000003c
[    6.286141] x8 : ffff80008364b640 x7 : ffff000080001540 x6 : fffffdffc22a7600
[    6.286151] x5 : ffff800080232cac x4 : ffff00008001fe00 x3 : ffff00008a9d8280
[    6.286161] x2 : ffff000087ae28b8 x1 : 0000000000000003 x0 : ffff0000813fb800
[    6.286172] Call trace:
[    6.286177]  device_del+0x2b4/0x388 (P)
[    6.286185]  platform_device_del+0x2c/0xa0
[    6.286194]  platform_device_unregister+0x14/0x3c
[    6.286202]  of_platform_device_destroy+0xf0/0x100
[    6.286211]  device_for_each_child_reverse+0x6c/0xc4
[    6.286219]  of_platform_depopulate+0x34/0x80
[    6.286225]  dwc3_imx8mp_probe+0x268/0x3f0 [dwc3_imx8mp]
[    6.286241]  platform_probe+0x80/0xac
[    6.286248]  really_probe+0xc0/0x3e0
[    6.286255]  __driver_probe_device+0x164/0x1bc
[    6.286261]  driver_probe_device+0x3c/0x118
[    6.286268]  __driver_attach+0xc8/0x21c
[    6.286274]  bus_for_each_dev+0x7c/0xdc
[    6.286282]  driver_attach+0x24/0x30
[    6.286288]  bus_add_driver+0x11c/0x260
[    6.286294]  driver_register+0x68/0x124
[    6.286301]  __platform_driver_register+0x24/0x30
[    6.286307]  dwc3_imx8mp_driver_init+0x28/0xfdc [dwc3_imx8mp]
[    6.286317]  do_one_initcall+0x60/0x1d4
[    6.286327]  do_init_module+0x54/0x244
[    6.286336]  load_module+0x18a0/0x2040
[    6.286342]  init_module_from_file+0xd8/0xf0
[    6.286349]  __arm64_sys_finit_module+0x208/0x35c
[    6.286356]  invoke_syscall.constprop.0+0x48/0xe4
[    6.286364]  do_el0_svc+0xa8/0xbc
[    6.286371]  el0_svc+0x40/0x228
[    6.286379]  el0t_64_sync_handler+0xa0/0xe4
[    6.286385]  el0t_64_sync+0x198/0x19c
[    6.286394] ---[ end trace 0000000000000000 ]---
```