Track down EHCI and companion errors on rk3xxx systems

[Diederik de Haas]

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?
 
>> This time I did the dynamic debug command and the above "Warning!" was
>> present. Plugged in the keyboard adapter, started a stopwatch on my
>> phone and monitored the ``dmesg -W`` for any changes ...
>> 
>> It took slightly more then a MINUTE for anything to appear in dmesg :-O
>> 
>> ```
>> root at quartz64a:~# dmesg -W
>> [  357.343890] usb usb4: usb wakeup-resume
>> [  357.343970] usb usb4: usb auto-resume
>> [  357.344023] hub 4-0:1.0: hub_resume
>> [  357.344243] usb usb4-port1: status 0501 change 0001
>> [  357.446845] hub 4-0:1.0: state 7 ports 1 chg 0002 evt 0000
>> [  357.447094] usb usb4-port1: status 0501, change 0000, 480 Mb/s
>
> That's the EHCI controller detecting the new connection.  If this took 
> more than a minute to happen then something is wrong with the EHCI 
> controller or its associated hardware.  Or possibly with the way the 
> computer handles wakeup signals.

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.

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.

I'll re-do the test and the addional tests you requested, but right now
I need to focus on some other things, so may take a few days.

Cheers,
  Diederik

>> [  357.510889] hub 4-0:1.0: port_wait_reset: err = -16
>> [  357.510909] usb usb2: usb wakeup-resume
>> [  357.510956] usb usb4-port1: not enabled, trying reset again...
>> [  357.510980] usb usb2: usb auto-resume
>> [  357.586708] hub 2-0:1.0: hub_resume
>> [  357.586936] usb usb2-port1: status 0101 change 0001
>> [  357.690841] hub 2-0:1.0: state 7 ports 1 chg 0002 evt 0000
>> [  357.691090] usb usb2-port1: status 0101, change 0000, 12 Mb/s
>> [  357.714843] usb usb4-port1: not reset yet, waiting 200ms
>> [  357.874717] usb 2-1: new full-speed USB device number 2 using ohci-platform
>
> This usb2 stuff is the OHCI controller reacting to the new connection, 
> after the connection was switched from the EHCI controller to OHCI.
>
>> [  357.918838] usb usb4-port1: not reset yet, waiting 200ms
>
> These messages aren't supposed to occur.  The EHCI controller is 
> supposed to realize that there is no device connected to it any more, 
> now that the connection has been switched over to the OHCI controller.
>
>> [  358.082679] usb 2-1: ep0 maxpacket = 32
>> [  358.087855] usb 2-1: skipped 1 descriptor after interface
>> [  358.087926] usb 2-1: skipped 1 descriptor after interface
>> [  358.089798] usb 2-1: default language 0x0409
>> [  358.093839] usb 2-1: udev 2, busnum 2, minor = 129
>> [  358.093904] usb 2-1: New USB device found, idVendor=1997, idProduct=2433, bcdDevice= 1.06
>> [  358.094803] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
>> [  358.095481] usb 2-1: Product: mini keyboard
>> [  358.095889] usb 2-1: Manufacturer:
>> [  358.097629] usb 2-1: usb_probe_device
>> [  358.097691] usb 2-1: configuration #1 chosen from 1 choice
>> [  358.099335] usb 2-1: adding 2-1:1.0 (config #1, interface 0)
>> [  358.100603] usb 2-1: adding 2-1:1.1 (config #1, interface 1)
>> [  358.101371] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
>> [  358.126129] usb usb4-port1: not reset yet, waiting 200ms
>> [  358.203797] hid: raw HID events driver (C) Jiri Kosina
>> [  358.227055] usbhid 2-1:1.0: usb_probe_interface
>> [  358.227080] usbhid 2-1:1.0: usb_probe_interface - got id
>> [  358.231307] usbhid 2-1:1.1: usb_probe_interface
>> [  358.231331] usbhid 2-1:1.1: usb_probe_interface - got id
>> [  358.236333] usbcore: registered new interface driver usbhid
>> [  358.236850] usbhid: USB HID core driver
>> [  358.267050] input:   mini keyboard as /devices/platform/fd8c0000.usb/usb2/2-1/2-1:1.0/0003:1997:2433.0001/input/input2
>> [  358.326722] usb usb4-port1: not reset yet, waiting 200ms
>> [  358.326992] hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0002
>> [  358.327125] usb usb4-port1: status 0100, change 0001, 12 Mb/s
>
> And here is where the EHCI controller finally reported that nothing was 
> connected.
>
> It certainly looks like the EHCI controller isn't working right.  Just 
> as a test, you can try unloading the ehci-hcd module, together with any 
> modules depending on it, before you plug in the keyboard adapter.  It 
> would be interesting to see if that makes any difference.
>
> Another thing to try is to see if disabling EHCI runtime suspend changes 
> anything.  To do this, don't remove any modules.  Instead, before 
> plugging in the keyboard adapter, do:
>
> 	echo on >/sys/bus/usb/devices/usb4/power/control
>
> Alan Stern
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip