On Thu, 13 Feb 2020, Sam Lewis wrote: > 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. That would be okay. You could even do something where the port would stay powered off until the user tells the kernel to turn it back on. > 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? A sysfs attribute file is the way to go. Probably under the port device. Alan Stern
