On Tue, 11 Feb 2020 at 01:53, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 10 Feb 2020, Oliver Neukum wrote: > > error handling at this level has gotten little love. > > Indeed. This is mostly because the issue does not crop up in normal > usage very often. And most hubs don't have very good over-current > protection anyway. > > I believe the original expectation was that over-current events would > generally be intermittent and very short-lived. So when an event did > occur, it would make sense to wait a little while and then try to > switch the port back on. Nobody ever bothered to implement a total > time or retry limit on this behavior, probably because there weren't > any complaints. Thanks for the responses. This makes sense, especially if most consumer hubs aren't very high quality. > > The basic problem is that we have no good way to switch a portback on > > after we have given up on it. Feel free to propose a patch to the > > kernel and a tool to use it and we can discuss them. > > Yes, patches are welcome. > How receptive would you (and other contributors/maintainers) be to a patch that adds configuration that allows a port to stay off if it receives an OC event? This obviously wouldn't be the desired behaviour in the general case, but could be useful for embedded devices (such as mine) where the design of the hub electronics are such that you can be confident that an OC event is not just an glitch and is indicative of a real problem. If it isn't acceptable to have a USB port off until the system is rebooted, what would be the appropriate mechanism of allowing a userspace application to manually turn the port back on? Sam
