Hello, On Sun, Oct 22, 2017 at 09:03:34PM -0400, Alan Stern wrote: > On Sun, 22 Oct 2017, Uwe [iso-8859-1] Kleine-K?nig wrote: > > On Sat, Oct 21, 2017 at 11:08:39AM -0400, Alan Stern wrote: > > > On Fri, 20 Oct 2017, Uwe [iso-8859-1] Kleine-K?nig wrote: > > > > On Fri, Oct 20, 2017 at 03:47:37PM -0400, Alan Stern wrote: > > > > > On Fri, 20 Oct 2017, Uwe [iso-8859-1] Kleine-K?nig wrote: > > > > > > On Fri, Oct 20, 2017 at 05:27:09PM -0200, Fabio Estevam wrote: > > > > > > > On Fri, Oct 20, 2017 at 5:20 PM, Uwe Kleine-K?nig > > > > > > > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > It also works. However I wonder if it's right that I'm spammed by > > > > > > > > over-current messages now (independent of which fix I choose) as long as > > > > > > > > there is something connected to the port that draws too much power: > > > > > > > > > > > > > > > > [ 53.406833] usb usb1-port1: over-current condition > > > > > > > > [ 53.631749] usb usb1-port1: over-current condition > > > > > > > > [ 53.856720] usb usb1-port1: over-current condition > > > > > > > > [ 54.081732] usb usb1-port1: over-current condition > > > > > > > > [ 54.306727] usb usb1-port1: over-current condition > > > > > > > > [ 54.531722] usb usb1-port1: over-current condition > > > > > > > > [ 54.756722] usb usb1-port1: over-current condition > > > > > > > > > > > > > > > > It seems to be intended or am I missing something? > > > > > > > > > > Well, it does report a potentially hardware-damaging condition. But > > > > > you are right that excessive repetition doesn't do any good. Now after removing my instrumentation the situation isn't what I described before. Instead of being spammed by messages about over-current I get only a single message (good) and power stays on. I wonder if that is acceptable. When an over-current event happens, I first get portstatus = 0x108 and portchange = 0x8 in port_event() when they are read initially (but 0x100 is wrong as ehci_hub_control already called ehci_port_power(... false) which also made PORT_OC disappear), then the body of if (portchange & USB_PORT_STAT_C_OVERCURRENT) is entered, which first clears PORT_OCC, then sleeps for 100 ms and reenables power. This makes PORTSC change from 0xcc000000 to 0xcc001010, i.e. PORT_OC is set, but PORT_OCC is not. I guess the author of the over-current handling expected that this triggers a new event that is handled again because after dev_err(&port_dev->dev, "over-current condition\n"); nothing further is scheduled to disable power again. Is this a bug? > > > We could keep a per-port is_overcurrent flag. If the port has an > > > overcurrent status and the flag is clear, log the error and set the > > > flag. If the port doesn't have an overcurrent status, clear the flag. > > > In other words, report each overcurrent event only once. > > > > You need to be a bit clever here. As reaction to the over-current event > > the port's power is cut which makes the event go away. Then after > > reenabling power it takes some time (typically 3 ms) until the Micrel > > 2025 signals over-current again. > > That's right. It might be better to use an even longer timeout, like > 1000 ms. Would you like to write a patch to do this? Not sure I find the time to do this. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
