On Tue, 24 Oct 2017, Uwe [iso-8859-1] Kleine-K� wrote: > 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? I think we expected that if the overcurrent situation was still present then USB_PORT_STAT_C_OVERCURRENT would be set again after the power was turned on. If it's not set then there's a bug somewhere, either in the hardware or in our understanding of the spec. > > > > 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. Me either, especially since we don't have a really clear idea of what should be done. The ideal approach would be to turn the port power off and leave it off until the overcurrent condition is fixed -- but that's impossible, since there's no way to tell whether the condition has been fixed while the power is off. Alan Stern -- 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
