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 ?

Reply via email to