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

Marek Vasut marex at denx.de
Thu Feb 1 15:28:10 CET 2024


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 ?


More information about the U-Boot mailing list