Track down EHCI and companion errors on rk3xxx systems

[Alan Stern]

On Wed, Jan 14, 2026 at 04:41:13PM +0100, Diederik de Haas wrote:
> On Wed Jan 14, 2026 at 4:19 PM CET, Alan Stern wrote:
> > 30 seconds was a generous estimate on my part; 5 seconds probably would 
> > have been enough.  However, the USB subsystem does include some timeouts 
> > that are 2 seconds long and others that are 5 seconds long, and some of 
> > these timeouts are inside retry loops.  So a 30-second wait isn't 
> > unreasonable.
> 
> But that's all processing times *after* it detected a USB device?
> The thing that really surprised me that it took the kernel a minute to
> detect anything had happened at all. If that had taken 30 secs, that
> would've surprised me too. If it then took some time to make the device
> fully available and operational, sure, fine.

Well yes, I wanted you to wait long enough for all the initial 
processing (making the device fully available and operational) to finish 
up.

However, I agree: 30 seconds is _much_ longer than it should take to 
detect a newly plugged-in device.  It should take less than one second.  
One possibility is that something involved in waking up the EHCI host 
controller from its runtime suspend may have caused the delay -- that's 
why I asked you to try turning off the controller's runtime suspend. 

Also, I'm not at all familiar with the particular hardware used by your 
platform for receiving wakeup signals.  It's possible that a GPIO 
responsible for this wasn't working right and that's why you were 
getting all those warning messages.  Another reason for wanting to know 
what will happen if you take suspends and wakeups out of the picture.

Alan Stern