[PATCH v3] common: usb-hub: Reset hub port before scanning

[Shantur Rathore]

On Thu, Feb 1, 2024 at 2:53 PM Marek Vasut <marex at denx.de> wrote:
>
> On 2/1/24 12:18, Shantur Rathore wrote:
> > On Thu, Feb 1, 2024 at 11:13 AM Marek Vasut <marex at denx.de> wrote:
> >>
> >> On 2/1/24 10:39, Shantur Rathore wrote:
> >>> Hi Andre,
> >>>
> >>> On Tue, Jan 30, 2024 at 2:01 PM Andre Przywara <andre.przywara at arm.com> wrote:
> >>>>
> >>>> On Sat,  9 Dec 2023 18:10:56 +0000
> >>>> Shantur Rathore <i at shantur.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>> Currently when a hub is turned on, all the ports are powered on.
> >>>>> This works well for hubs which have individual power control.
> >>>>>
> >>>>> For the hubs without individual power control this has no effect.
> >>>>> Mostly in these scenarios the hub port is powered before the USB
> >>>>> controller is enabled, this can lead to some devices in unexpected
> >>>>> state.
> >>>>>
> >>>>> With this patch, we explicitly reset the port while powering up hub
> >>>>> This resets the port for hubs without port power control and has
> >>>>> no effect on hubs with port power control as the port is still off.
> >>>>>
> >>>>> Before this patch AMicro AM8180 based NVME to USB adapter won't be
> >>>>> detected as a USB3.0 Mass Storage device but with this it works as
> >>>>> expected.
> >>>>>
> >>>>> Tested working after this patch:
> >>>>> 1. AMicro AM8180 based NVME to USB Adapter
> >>>>> 2. Kingston DataTraveler 3.0
> >>>>> 3. GenesysLogic USB3.0 Hub
> >>>>>
> >>>>> The drives were tested while connected directly and via the hub.
> >>>>
> >>>> so this broke USB operation on some Allwinner boards. The ports still
> >>>> enumerate correctly, but no devices are detected. With mainline
> >>>> (containing this patch), and a USB stick connected:
> >>>> starting USB...
> >>>> Bus usb at 5200000: USB EHCI 1.00
> >>>> Bus usb at 5200400: USB OHCI 1.0
> >>>> scanning bus usb at 5200000 for devices... 1 USB Device(s) found
> >>>> scanning bus usb at 5200400 for devices... 1 USB Device(s) found
> >>>>          scanning usb for storage devices... 0 Storage Device(s) found
> >>>>
> >>>> With this patch here reverted:
> >>>> starting USB...
> >>>> Bus usb at 5200000: USB EHCI 1.00
> >>>> Bus usb at 5200400: USB OHCI 1.0
> >>>> scanning bus usb at 5200000 for devices... 2 USB Device(s) found
> >>>> scanning bus usb at 5200400 for devices... 1 USB Device(s) found
> >>>>          scanning usb for storage devices... 1 Storage Device(s) found
> >>>>
> >>>> I have no clue why this happens, there is no discrete hub anywhere in this
> >>>> setup, so I guess the code runs for the root hub here?
> >>>> I am attaching a log with DEBUG enabled for common/usb_hub.c, for both
> >>>> cases.
> >>>>
> >>>> Any clues, debug suggestions, or even a fix are warmly welcome.
> >>>>
> >>>
> >>> Which USB disk are you using? Is it a USB 2.0 disk ?
> >>> Can you try with any other USB disk to confirm?
> >>
> >> I don't think this is device specific, see the logs. Hardware from Andre
> >> worked before this patch, does not work after this patch. There seem to
> >> be no connection event with this patch.
> >
> > I am trying to evaluate if this is happening due to a USB 2.0 device.
> > I see that the host is USB 2.0. I have tested this on my RK3399 board on both
> > USB 2.0 and USB 3.0 ports.
> > If this is not behaving on USB 2.0 ports then I can put a condition
> > for this to happen
> > only on USB 3.0 ports.
>
> Doesn't Linux perform this reset for all ports unconditionally ?


Looks like it doesn't
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2841