All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Diederik de Haas" <diederik@cknow-tech.com>
To: "Alan Stern" <stern@rowland.harvard.edu>
Cc: "USB mailing list" <linux-usb@vger.kernel.org>,
	<linux-rockchip@lists.infradead.org>
Subject: Re: Track down EHCI and companion errors on rk3xxx systems
Date: Wed, 14 Jan 2026 18:31:23 +0100	[thread overview]
Message-ID: <DFOHOZTANT92.38TTTMCKWID54@cknow-tech.com> (raw)
In-Reply-To: <febe88e2-9abd-481e-af9d-3f0825ef204b@rowland.harvard.edu>

On Wed Jan 14, 2026 at 5:07 PM CET, Alan Stern wrote:
> 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. 

It may be completely natural, but I was surprised runtime suspend was
involved at all. So I'll definitely do a test by turning it off.

> 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.

I think GPIO is involved with wakeup signals ... sometimes at least.
I added the linux-rockchip ML precisely because I (strongly) suspect
there is Rockchip specific part to all this.

Cheers,
  Diederik

PS: I very much appreciate you taking the time for this 'debugging'
session :-)

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: "Diederik de Haas" <diederik@cknow-tech.com>
To: "Alan Stern" <stern@rowland.harvard.edu>
Cc: "USB mailing list" <linux-usb@vger.kernel.org>,
	<linux-rockchip@lists.infradead.org>
Subject: Re: Track down EHCI and companion errors on rk3xxx systems
Date: Wed, 14 Jan 2026 18:31:23 +0100	[thread overview]
Message-ID: <DFOHOZTANT92.38TTTMCKWID54@cknow-tech.com> (raw)
In-Reply-To: <febe88e2-9abd-481e-af9d-3f0825ef204b@rowland.harvard.edu>

On Wed Jan 14, 2026 at 5:07 PM CET, Alan Stern wrote:
> 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. 

It may be completely natural, but I was surprised runtime suspend was
involved at all. So I'll definitely do a test by turning it off.

> 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.

I think GPIO is involved with wakeup signals ... sometimes at least.
I added the linux-rockchip ML precisely because I (strongly) suspect
there is Rockchip specific part to all this.

Cheers,
  Diederik

PS: I very much appreciate you taking the time for this 'debugging'
session :-)

  reply	other threads:[~2026-01-14 17:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-03 16:52 Track down EHCI and companion errors on rk3xxx systems Alan Stern
2026-01-13 13:35 ` Diederik de Haas
2026-01-13 13:35   ` Diederik de Haas
2026-01-13 15:47   ` Alan Stern
2026-01-13 15:47     ` Alan Stern
2026-01-13 16:16     ` Diederik de Haas
2026-01-13 16:16       ` Diederik de Haas
2026-01-13 16:22       ` Alan Stern
2026-01-13 16:22         ` Alan Stern
2026-01-13 21:15         ` Diederik de Haas
2026-01-13 21:15           ` Diederik de Haas
2026-01-14  3:20           ` Alan Stern
2026-01-14  3:20             ` Alan Stern
2026-01-14 14:59             ` Diederik de Haas
2026-01-14 14:59               ` Diederik de Haas
2026-01-14 15:19               ` Alan Stern
2026-01-14 15:19                 ` Alan Stern
2026-01-14 15:41                 ` Diederik de Haas
2026-01-14 15:41                   ` Diederik de Haas
2026-01-14 16:07                   ` Alan Stern
2026-01-14 16:07                     ` Alan Stern
2026-01-14 17:31                     ` Diederik de Haas [this message]
2026-01-14 17:31                       ` Diederik de Haas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DFOHOZTANT92.38TTTMCKWID54@cknow-tech.com \
    --to=diederik@cknow-tech.com \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.