Microchip USB2642 Hub not resuming from USB autosuspend

Martin Kepplinger martin.kepplinger at puri.sm
Tue Jun 23 09:48:01 EDT 2020

On 26.05.20 09:04, Martin Kepplinger wrote:
> hi all,
> our Librem 5 includes the microchip USB2642 hub with
> integrated/connected SD cardcreader (and we connect the baseband modem
> to it): https://www.microchip.com/wwwproducts/en/USB2642
> When we remove the (integrated) SD cardreader entirely (in sysfs), the
> Hub suspends as long as the modem doesn't need a connection. But then
> the modem fails to *resume* the Hub. Linux xhci host times out and dies
> during resuming, which leaves a system without the Hub entirely. You can
> see some logs and tests here
> https://source.puri.sm/Librem5/linux-next/issues/170#note_89808 (when
> scrolling down).
> Microchip says the their product has the following bug which results in
> our problem:
> https://microchipsupport.force.com/s/article/Device-attached-to-Hub-Downstream-Facing-Port-does-not-Resume-from-Suspend
> (that may or may not be the real and only reason for our problem)
> That issue suggests working around it in the HC by somehow
> sending "HS SOF as soon as possible after the HS RESUME EOP".
> We use imx8mq and the dwc3 driver for the designware USB hardware that
> NXP documents in chapter 11.1.3 of the reference manual:
> https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8m-family-armcortex-a53-cortex-m4-audio-voice-video:i.MX8M?tab=Documentation_Tab
> What can we try to change in dwc3 or xhci drivers in order to achieve
> sending SOF earlier after resume?
> What else that I don't currently think of could lead to the USB
> suspend/resume problem here?

For future reference: We've been able to make the Hub resume when not
applying any quirks to dwc3.

> p.s.:  A follow-up for Microchip: The Hub doesn't suspend when the SD
> cardreader is connected *without* and SD card inserted (as described
> above, we remove the cardreader for testing here). What could cause this?

We've resolved this issue too. When scsi (sd) runtime pm is not enabled
by default, it needs to be enabled of course and events_dfl_poll_msecs
for the block layer set to 0.

scsi sd has until now incomplete support for runtime pm and this
addition makes it work, i.e. suspend when not mounted:
the whole USB path is suspended as a consequence - and woken up if opened.


More information about the linux-arm-kernel mailing list