Hello, 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. > > > > > > Maybe we should keep track of the time interval between overcurrent > > > events on each port. If we see more than one event in a 10-second > > > window, leave the port permanently powered-off. (But then how would we > > > recover?) > > > > Maybe double the interval each time up to a maximum of 1 minute? > > I guess spamming the log once a minute is better than spamming it four > times a second. But it's still spam. If people don't react to the > error situation by removing the cause of the overcurrent, repeating the > message over and over won't help much. > > 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. 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