* USB hub driver over-current behavior
@ 2020-02-10 6:03 Sam Lewis
2020-02-10 9:53 ` Oliver Neukum
2020-02-10 10:29 ` Oliver Neukum
0 siblings, 2 replies; 6+ messages in thread
From: Sam Lewis @ 2020-02-10 6:03 UTC (permalink / raw)
To: linux-usb
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: USB hub driver over-current behavior
2020-02-10 6:03 USB hub driver over-current behavior Sam Lewis
@ 2020-02-10 9:53 ` Oliver Neukum
2020-02-10 10:29 ` Oliver Neukum
1 sibling, 0 replies; 6+ messages in thread
From: Oliver Neukum @ 2020-02-10 9:53 UTC (permalink / raw)
To: Sam Lewis, linux-usb
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: USB hub driver over-current behavior
2020-02-10 6:03 USB hub driver over-current behavior Sam Lewis
2020-02-10 9:53 ` Oliver Neukum
@ 2020-02-10 10:29 ` Oliver Neukum
2020-02-10 14:53 ` Alan Stern
1 sibling, 1 reply; 6+ messages in thread
From: Oliver Neukum @ 2020-02-10 10:29 UTC (permalink / raw)
To: Sam Lewis, linux-usb
Am Montag, den 10.02.2020, 17:03 +1100 schrieb Sam Lewis:
> 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
Hi,
error handling at this level has gotten little love.
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.
Regards
Oliver
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: USB hub driver over-current behavior
2020-02-10 10:29 ` Oliver Neukum
@ 2020-02-10 14:53 ` Alan Stern
2020-02-13 5:41 ` Sam Lewis
0 siblings, 1 reply; 6+ messages in thread
From: Alan Stern @ 2020-02-10 14:53 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Sam Lewis, linux-usb
On Mon, 10 Feb 2020, Oliver Neukum wrote:
> Am Montag, den 10.02.2020, 17:03 +1100 schrieb Sam Lewis:
> > 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
>
> Hi,
>
> 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.
> 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.
Alan Stern
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: USB hub driver over-current behavior
2020-02-10 14:53 ` Alan Stern
@ 2020-02-13 5:41 ` Sam Lewis
2020-02-13 14:49 ` Alan Stern
0 siblings, 1 reply; 6+ messages in thread
From: Sam Lewis @ 2020-02-13 5:41 UTC (permalink / raw)
To: Alan Stern; +Cc: Oliver Neukum, linux-usb
On Tue, 11 Feb 2020 at 01:53, Alan Stern <stern@rowland.harvard.edu> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: USB hub driver over-current behavior
2020-02-13 5:41 ` Sam Lewis
@ 2020-02-13 14:49 ` Alan Stern
0 siblings, 0 replies; 6+ messages in thread
From: Alan Stern @ 2020-02-13 14:49 UTC (permalink / raw)
To: Sam Lewis; +Cc: Oliver Neukum, linux-usb
On Thu, 13 Feb 2020, Sam Lewis wrote:
> On Tue, 11 Feb 2020 at 01:53, Alan Stern <stern@rowland.harvard.edu> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-02-13 14:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-10 6:03 USB hub driver over-current behavior Sam Lewis
2020-02-10 9:53 ` Oliver Neukum
2020-02-10 10:29 ` Oliver Neukum
2020-02-10 14:53 ` Alan Stern
2020-02-13 5:41 ` Sam Lewis
2020-02-13 14:49 ` Alan Stern
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.