On Mon, Jul 14, 2014 at 10:47:55PM +0200, Oliver Neukum wrote: > On Mon, 2014-07-14 at 11:04 -0400, Alan Stern wrote: > > On Mon, 14 Jul 2014, Oliver Neukum wrote: > > > > > On Mon, 2014-07-14 at 07:50 -0700, Greg KH wrote: > > > > > > > So if I have hubs with the same "broken" port, I'll only get one > > > > message? What if I have 2 "broken" ports, I'll keep getting the > > > > messages? > > > > > > Well, hubs are not a problem. > > > > > > > I'm not suggesting that we have a "broken port" flag per port for each > > > > hub, but this really seems like it is just a half-fix for a specific > > > > piece of broken hardware :( > > > > > > The hardware in question cannot be fixed. Unfortunately > > > the problem is not as uncommon as one might wish. Yes, > > > I could come up with a more sophisticated fix for generic > > > brokenness, but what for? On the other hand there is a > > > significant number of broken systems out there. > > > > Maybe a "error during connect" counter in the usb_port structure > > wouldn't be such a bad idea. There have been other occasions where > > users logs have been spammed by repeated failures during device > > initialization attempts. > > > > Of course, then the question is: How long should the hub driver wait > > before trying the port again? > > I see no sane way to come up with numbers. > Unless you want to measure the time between spurious event. > But that would really be overkill. I'd rather fix a concrete > issue. I'm all for fixing a "real" issue, but not at the expense of getting it wrong. What hardware is "broken" here? Can we blacklist it somehow instead of being so general here? thanks, greg k-h -- 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
