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@xxxxxxxxxxxx>
> > Signed-off-by: Xu Yang <xu.yang_2@xxxxxxx>
> 
> 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