On 11/23/23 12:24, Shantur Rathore wrote:
Hi Marek,
On Thu, Nov 23, 2023 at 12:06 AM Marek Vasut marex@denx.de wrote:
On 11/20/23 00:03, Shantur Rathore wrote:
Hi Marek,
Hi,
On Sun, Nov 19, 2023 at 8:53 PM Marek Vasut marex@denx.de wrote:
On 11/10/23 15:13, Shantur Rathore wrote:
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.
OK
Mostly in these scenarios the hub port is powered before the USB controller is enabled, this can lead to some devices in unexpected state.
This ^ part needs clarification.
Which devices are in incorrect state, the ones connected to the hub downstream facing ports ?
In my case RockPro64, the power to usb ports onboard is controlled by a regulator. This regulator is enabled as part of init as here https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-rockpro64.d...
On init, the usb devices connected to the port are powered up, in my case AM8180 (a RTL9210 based ) NVMe to USB enclosure with UAS. But the usb controller is only enabled at 'usb start' and by this time the device is in some state that it doesn't get detected.
One way to make sure the devices connected to the ports are in an initialising state is by issuing a port reset before scanning the port.
Why not remove this regulator-always-on and let the PHY driver turn the VBUS ON only when it is needed ?
Wouldn't that solve the problem too AND remove unnecessarily enabled regulator ?
[...]
Removing the regulator-always-on does make it work but there are few issues
- regulator is used to control power to multiple ports ( USB3.0 and
USB2.0 in RockPro64 ), so this could lead to all ports turning off if a phy resets / turns off power
I vaguely recall seeing some refcounting patch for regulator subsystem, would that help ?
- Even with regulator-always-on and without this reset port patch,
linux was always able to detect the drive on the port, so there is something missing in u-boot. 3. Looking at usb hub code in Linux, I found that for USB3.0 it tries to reset the port before scanning. The comment says
/* Is a USB 3.0 port in the Inactive or Compliance Mode state?
- Port warm reset is required to recover
*/
i. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L5736 ii. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2836
I believe this isn't implemented in u-boot and hence explicit reset of a port fixes the issue.
I feel this is separate issue and what needs to be fixed first is the hard-wired VBus control.