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

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