Hi, I have a LAN9514 (rebranded SMSC9514) USB hub which has per port over-current protection. I'm using this hub within my embedded device, and I would like the hub to continue working if any single port experiences an over-current or short condition. In testing this behavior by shorting out a port, I've noticed that the Linux USB driver continually fights against the protection in the hub and attempts to repower the shorted port. Looking through the hub driver and tracing the execution flow, as far as I can tell, this is the list of events that seem to be occurring: 1. I short out a single port 2. The hub (through a power switch) detects the short and disables the port 3. The hub sends an over-current event to the driver 4. The driver gets the event in the `port_event` function 5. The driver then sleeps for 100ms (for 'cool down'?) before powering the port back on 6. Repeat from top, until the short is removed I've tested this on Kernel versions 4.14 and 5.3.0 and the behavior is the same. There doesn't appear to be any differences in logical flow in the very latest kernel version, either, so I believe the behavior would be the same there too. Is this 'repeated re-enable' the intended behavior of the driver? Or is my hub operating in some way that's confusing the driver? I appreciate that this might not be true in the general case, but in my product it would be nice if the offending port was shut off until it was manually re-enabled (maybe through userspace?). The repeated re-enabling of the faulty port seems to be causing other issues on my board, communications to the hub eventually timeout while a port is shorted out and the driver is trying to power it. This makes me completely lose all devices connected to the hub. This might be an issue with the hardware design of the board or perhaps it could be an issue with the driver but it does seem to be induced by the repeated re-enabling from the driver. I've tried manually patching the hub driver to not re-enable power to the port (basically by removing the `hub_power_on` call in the `port_event` function) and this seems to improve the situation a lot. If the 'repeated re-enabling' behavior is what is intended, would there be any interest in adding configuration to not re-enable a faulty port? Or trying a set amount of times before giving up and raising an issue to the user? From what I've seen, I believe the latter is how Windows deals with over-current conditions on a port.
