* usb hub driver bug in overcurrent handling?
@ 2018-07-13 20:35 Alan Stern
0 siblings, 0 replies; 4+ messages in thread
From: Alan Stern @ 2018-07-13 20:35 UTC (permalink / raw)
To: Bin Liu; +Cc: linux-usb
On Fri, 13 Jul 2018, Bin Liu wrote:
> Hi,
>
> I got a report saying that when overcurrent happens in one of the hub
> downstream ports, USB_PORT_STAT_OVERCURRENT is not set in portstatus,
> instead USB_PORT_STAT_C_OVERCURRENT is set in portchange, then the
> overcurrent condition is not handled in hub_event().
>
> The following patch solves the issue.
>
> t a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 442be7f312f6..118557acc74b 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1144,7 +1144,8 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
> * check for a new connection
> */
> if (udev || (portstatus & USB_PORT_STAT_CONNECTION) ||
> - (portstatus & USB_PORT_STAT_OVERCURRENT))
> + (portstatus & USB_PORT_STAT_OVERCURRENT) ||
> + (portchange & USB_PORT_STAT_C_OVERCURRENT))
> set_bit(port1, hub->change_bits);
>
> } else if (portstatus & USB_PORT_STAT_ENABLE) {
Please also update the immediately preceding comment.
> The usb2.0 spec section 11.12.5 states
> "If a hub has per-port power switching and per-port current limiting, an
> over-current on one port may still cause the power on another port to
> fall below specific minimums. In this case, the affected port is placed
> in the Power-Off state and C_PORT_OVER_CURRENT is set for the port, but
> PORT_OVER_CURRENT is not set."
>
> So is the patch above a proper fix? or something else might be missing?
It certainly seems like a reasonable thing to do. If you say it fixes
the problem, we can add it in.
Alan Stern
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* usb hub driver bug in overcurrent handling?
@ 2018-07-18 14:42 Bin Liu
0 siblings, 0 replies; 4+ messages in thread
From: Bin Liu @ 2018-07-18 14:42 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb
On Fri, Jul 13, 2018 at 04:35:33PM -0400, Alan Stern wrote:
> On Fri, 13 Jul 2018, Bin Liu wrote:
>
> > Hi,
> >
> > I got a report saying that when overcurrent happens in one of the hub
> > downstream ports, USB_PORT_STAT_OVERCURRENT is not set in portstatus,
> > instead USB_PORT_STAT_C_OVERCURRENT is set in portchange, then the
> > overcurrent condition is not handled in hub_event().
> >
> > The following patch solves the issue.
> >
> > t a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index 442be7f312f6..118557acc74b 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -1144,7 +1144,8 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
> > * check for a new connection
> > */
> > if (udev || (portstatus & USB_PORT_STAT_CONNECTION) ||
> > - (portstatus & USB_PORT_STAT_OVERCURRENT))
> > + (portstatus & USB_PORT_STAT_OVERCURRENT) ||
> > + (portchange & USB_PORT_STAT_C_OVERCURRENT))
> > set_bit(port1, hub->change_bits);
> >
> > } else if (portstatus & USB_PORT_STAT_ENABLE) {
>
> Please also update the immediately preceding comment.
Sure.
>
> > The usb2.0 spec section 11.12.5 states
> > "If a hub has per-port power switching and per-port current limiting, an
> > over-current on one port may still cause the power on another port to
> > fall below specific minimums. In this case, the affected port is placed
> > in the Power-Off state and C_PORT_OVER_CURRENT is set for the port, but
> > PORT_OVER_CURRENT is not set."
> >
> > So is the patch above a proper fix? or something else might be missing?
>
> It certainly seems like a reasonable thing to do. If you say it fixes
> the problem, we can add it in.
Will send the patch.
Thanks,
-Bin.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* usb hub driver bug in overcurrent handling?
@ 2018-07-13 19:26 Bin Liu
0 siblings, 0 replies; 4+ messages in thread
From: Bin Liu @ 2018-07-13 19:26 UTC (permalink / raw)
To: linux-usb
On Fri, Jul 13, 2018 at 02:22:32PM -0500, Bin Liu wrote:
> Hi,
>
> I got a report saying that when overcurrent happens in one of the hub
> downstream ports, USB_PORT_STAT_OVERCURRENT is not set in portstatus,
> instead USB_PORT_STAT_C_OVERCURRENT is set in portchange, then the
> overcurrent condition is not handled in hub_event().
not handled because neither hub->change_bits nor hub->event_bits is set.
> The following patch solves the issue.
>
> t a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 442be7f312f6..118557acc74b 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1144,7 +1144,8 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
> * check for a new connection
> */
> if (udev || (portstatus & USB_PORT_STAT_CONNECTION) ||
> - (portstatus & USB_PORT_STAT_OVERCURRENT))
> + (portstatus & USB_PORT_STAT_OVERCURRENT) ||
> + (portchange & USB_PORT_STAT_C_OVERCURRENT))
> set_bit(port1, hub->change_bits);
>
> } else if (portstatus & USB_PORT_STAT_ENABLE) {
>
> The usb2.0 spec section 11.12.5 states
> "If a hub has per-port power switching and per-port current limiting, an
> over-current on one port may still cause the power on another port to
> fall below specific minimums. In this case, the affected port is placed
> in the Power-Off state and C_PORT_OVER_CURRENT is set for the port, but
> PORT_OVER_CURRENT is not set."
>
> So is the patch above a proper fix? or something else might be missing?
>
> Thanks,
> -Bin.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* usb hub driver bug in overcurrent handling?
@ 2018-07-13 19:22 Bin Liu
0 siblings, 0 replies; 4+ messages in thread
From: Bin Liu @ 2018-07-13 19:22 UTC (permalink / raw)
To: linux-usb
Hi,
I got a report saying that when overcurrent happens in one of the hub
downstream ports, USB_PORT_STAT_OVERCURRENT is not set in portstatus,
instead USB_PORT_STAT_C_OVERCURRENT is set in portchange, then the
overcurrent condition is not handled in hub_event().
The following patch solves the issue.
t a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 442be7f312f6..118557acc74b 100644
The usb2.0 spec section 11.12.5 states
"If a hub has per-port power switching and per-port current limiting, an
over-current on one port may still cause the power on another port to
fall below specific minimums. In this case, the affected port is placed
in the Power-Off state and C_PORT_OVER_CURRENT is set for the port, but
PORT_OVER_CURRENT is not set."
So is the patch above a proper fix? or something else might be missing?
Thanks,
-Bin.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1144,7 +1144,8 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
* check for a new connection
*/
if (udev || (portstatus & USB_PORT_STAT_CONNECTION) ||
- (portstatus & USB_PORT_STAT_OVERCURRENT))
+ (portstatus & USB_PORT_STAT_OVERCURRENT) ||
+ (portchange & USB_PORT_STAT_C_OVERCURRENT))
set_bit(port1, hub->change_bits);
} else if (portstatus & USB_PORT_STAT_ENABLE) {
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-07-18 14:42 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-13 20:35 usb hub driver bug in overcurrent handling? Alan Stern
-- strict thread matches above, loose matches on Subject: below --
2018-07-18 14:42 Bin Liu
2018-07-13 19:26 Bin Liu
2018-07-13 19:22 Bin Liu
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.