On Thu, Feb 1, 2024 at 2:53 PM Marek Vasut <ma...@denx.de> wrote: > > On 2/1/24 12:18, Shantur Rathore wrote: > > On Thu, Feb 1, 2024 at 11:13 AM Marek Vasut <ma...@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.przyw...@arm.com> > >>> wrote: > >>>> > >>>> On Sat, 9 Dec 2023 18:10:56 +0000 > >>>> Shantur Rathore <i...@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@5200000: USB EHCI 1.00 > >>>> Bus usb@5200400: USB OHCI 1.0 > >>>> scanning bus usb@5200000 for devices... 1 USB Device(s) found > >>>> scanning bus usb@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@5200000: USB EHCI 1.00 > >>>> Bus usb@5200400: USB OHCI 1.0 > >>>> scanning bus usb@5200000 for devices... 2 USB Device(s) found > >>>> scanning bus usb@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
