Track down EHCI and companion errors on rk3xxx systems

[Diederik de Haas]

On Tue Jan 13, 2026 at 4:47 PM CET, Alan Stern wrote:
> On Tue, Jan 13, 2026 at 02:35:21PM +0100, Diederik de Haas wrote:
>> Got my (gtkgreet) login screen and plugged in my keyboard adapter in the
>> *bottom* USB2 port ... and that did NOT work.
>> 
>> Logged in via SSH and noticed it was indeed not listed in ``lsusb``.
>> Checked ``lsmod`` and ``dmesg | tail`` ... and noticed the kernel *did*
>> notice plugging in the keyboard adapter, so did ``lsusb`` *again* and
>> then it *did* list my keyboard adapter.
>> I did NOT employ my usual 'workaround' by plugging it into a USB3 port.
>> 
>> So it may be that it would have always worked ... eventually ... if I
>> had just waited long enough?
>> While 'dmesg' seems to suggest it took little over 0.5 seconds, I'm
>> really not that fast ;-P (or that impatient)
>
> Is this repeatable?

It doesn't happen every time, but it did actually happen another time.
After that test, I shutdown the device and unplugged the keyboard
adapter. Then I powered on the device and waited till it had completed
the boot process.
Logged in via SSH, retrieved my usual boot process data (what you saw in
my 'paste' starting with ``uname -a``) and then did ``dmesg -W``.

Then I plugged in my keyboard adapter in the bottom port and noticed it
didn't work (straight away). This time I waited, pressed various keys on
my keyboard, turned the keyboard off and on again, pressed some more
keys ... and after ~20 (or 30?) seconds, my keyboard started to work.
When I then switched back to my SSH session, I saw dmesg had (then)
printed messages indicating it saw the adapter plugged in and ``lsusb``
did see the device.

But that ~20 seconds is key here. Normally I would conclude that "it
doesn't work" after (say) >5 seconds of nothing happening.

> If it is, try doing the following.  After a fresh boot, log in via SSH 
> and turn on dynamic debugging for USB:
>
> 	echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control
>
> and clear the kernel's log buffer:
>
> 	dmesg -C

Would ``dmesg -W`` also work?

> Then plug the keyboard adapter into the non-working bottom USB2 port and 
> wait a short time (say, 30 seconds).
>
> Then get a copy of the dmesg output and post it here.  Also, check to 
> see whether the keyboard is working.  In fact, you should check the 
> keyboard during that 30-second wait, so you will know just how long the 
> delay was before it started working.

Normally my SSH session is displayed on the same monitor as the desktop
session of the Quartz64-A (I switch between HDMI-1 and HDMI-2 input
sources of my monitor). This makes doing any kind of precise timing
activity impossible. I'll try doing the SSH session via my laptop, which
hopefully allows timings to be closer (but likely still not precise).

> Another thing you can try is to force the necessary module(s) to load 
> before plugging in the keyboard adapter.  For now, a simple modprobe 
> issued over the SSH connection will do the job.  If this turns out to 
> help, you can configure modprobe to load the module(s) automatically at 
> boot time.

I was already planning to make it built-in as the chances of me not
needing USB2 in some way, are quite slim. And they should (hopefully)
prevent such issues and I'd have a warning less in dmesg.

Cheers,
  Diederik