Hi Kai-Heng,
Many thanks for reporting the issue!
On Tue, May 12, 2020 at 09:36:07PM +0800, Kai-Heng Feng wrote:
> This patch prevents my Raven Ridge xHCI from getting runtime suspend.
>
> > On Feb 6, 2020, at 19:49, Hardik Gajjar <hgajjar@xxxxxxxxxxxxxx> wrote:
> >
> > Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able
> > to detect the USB3.0 mass storage devices or is detecting those as
> > USB2.0 high speed devices.
> >
> > The explanation given by Renesas is that, due to a HW issue, the XHCI
> > driver does not wake up after going to sleep on connecting a USB3.0
> > device.
>
> Since the issue is already root caused to xHCI, sounds the workaround should be implemented in xHCI?
>
> Functions like xhci_alloc_dev() can be a better place to instrument the workaround.
To my understanding, based on the USB Vendor ID used in this patch and
on the lsusb output [1] got on the original arm64 board, we are talking
about a hub device [2], hence drivers/usb/core/hub.c seems an
appropriate placement.
> > +#define USB_VENDOR_SMSC 0x0424
Based on the output [1], I believe the quirk could be made specific
to USB Product IDs '2134' and '5534'?
Could you please share the output of 'lsusb | grep 0424' on the machine
you experienced the regression?
Question to both USB and Renesas people. Does anybody expect SMSC hub
Product ID to vary across different Kingfisher [3] board samples?
> > static const struct usb_device_id hub_id_table[] = {
> > + { .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_CLASS,
> > + .idVendor = USB_VENDOR_SMSC,
> > + .bInterfaceClass = USB_CLASS_HUB,
> > + .driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND},
[1] h3ulcb-kf #> lsusb | grep 0424
Bus 006 Device 002: ID 0424:5534 Standard Microsystems Corp. Hub
Bus 005 Device 002: ID 0424:2134 Standard Microsystems Corp. Hub
[2] https://devicehunt.com/search/type/usb/vendor/0424/device/any
[3] https://elinux.org/R-Car/Boards/Kingfisher
--
Best regards,
Eugeniu Rosca
