Track down EHCI and companion errors on rk3xxx systems

[Alan Stern]

On Wed, Jan 14, 2026 at 03:59:28PM +0100, Diederik de Haas wrote:
> On Wed Jan 14, 2026 at 4:20 AM CET, Alan Stern wrote:
> > On Tue, Jan 13, 2026 at 10:15:59PM +0100, Diederik de Haas wrote:
> >> I'm now wondering if there's something wrong with the Quartz64-A ...
> >> I already thought that it took way too long before I got a login prompt.
> >> 
> >> In my first attempt I noticed I did NOT have the "Warning! ehci_hcd
> >> should always be loaded before uhci_hcd and ohci_hcd, not after"
> >> It took so long I forgot to keep counting, but most of all I forgot the
> >> dynamic debug command, so I tried again ...
> 
> I know it didn't result in the requested dmesg log, but isn't it
> significant I had the problem *without* the warning? IOW: the connection
> (correlation or causation) I thought there was, (possibly) isn't there?

I told you much earlier in this discussion that the warning message was 
unlikely to be connected with the problem you were seeing.

> This was with a 6.19-rc5 based kernel (with mostly media patches added
> on top) and on a Rock64 (rk3328) I got a whole bunch of these warnings:
> 
> WARNING: drivers/gpio/gpiolib.c:3523 at gpiod_get_value+0x64/0x98, CPU#0: swapper/0/0
> 
> log of a few of them:
> https://paste.sr.ht/~diederik/154c5023a3a50d77f1da2195e7bb9a96f6a88555
> 
> and I suspect (but don't KNOW!) this commit is relevant:
> 20cf2aed89ac ("gpio: rockchip: mark the GPIO controller as sleeping")
> 
> So I'll switch to a 6.19-rc4 based kernel, which is mostly the same,
> but doesn't have that commit.

It's very hard to tell whether this is at all connected to your problem.  
It could easily be a totally separate issue.

> FWIW: I'd expect to see sth in dmesg within a second of me plugging sth
> in, so I was surprised by you calling '30 secs' a short period.

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.

Alan Stern