[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