On Wed, Jul 03, 2013 at 10:07:13AM -0400, Alan Stern wrote: > On Tue, 2 Jul 2013, Sarah Sharp wrote: > > > > On the other hand, I know from personal experience that some companies > > > are worried about this race and insist on avoiding it. Should I add a > > > Kconfig option to force global suspend always? > > > > If we add a Kconfig option, I worry about a) confusing users and b) > > someone turning it on that has an Intel rate matching hub. I don't > > think the Kconfig option is a good one. How does a user know how to set > > the Kconfig option if they have both a rate matching hub and one of > > these hubs with a race condition? > > > > In the end, I suspect distros would leave the Kconfig option off, to > > avoid breaking Intel systems. How would anyone know to recompile their > > kernel and turn this option on? Can we detect these hubs with the race > > conditions and warn users to do so? Or dynamically turn on global > > suspend if we detect the hub and there's no Intel rate matching hub or > > Gensys hub attached? > > The Kconfig option would be intended for embedded systems only, and it > would say so in the help text. Distributions and normal users would be > expected to leave it disabled. Ok, I would be fine with a Kconfig option, if it was explicitly marked as being for embedded systems only. > There is no way to detect whether a hub suffers from the race condition > without special testing equipment. And I don't know whether any hubs > other than Intel and Genesys Logic have the wakeup bug, but it wouldn't > be surprising to find some that do. Makers of embedded systems are > presumably in a position to test their hardware and know exactly how it > performs. > > > It all starts to sound rather complicated. Perhaps people with hubs > > with the race condition will just have to live with it. How common are > > these hubs? > > I don't know. The real cause of the problem is that the USB-2 spec > never took this race into account. (AFAIK neither did the USB-3 spec; > didn't you face this problem at one point?) It contains detailed state > diagrams and explanations for how a hub should work, and any hub that > follows those instructions exactly will experience the problems I > described. I was dealing with a VIA USB 3.0 hub that didn't advertise remote wakeup at all, and thus probably wasn't actually designed to be suspended. I had hacked around its lack of remote wakeup to make the USB core suspend the USB 3.0 portion during runtime, and it kept sending wakeup requests whenever it was suspended. Basically, I don't think this issue was related to your issue. Sarah Sharp -- 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
