On Tue, Jul 02, 2013 at 10:47:13AM -0400, Alan Stern wrote: > I think reverting the "global suspend" commit would be pretty easy. > But there is a problem. > > The commit was added at the time when I removed the CONFIG_USB_SUSPEND > option. Apparently some embedded systems were normally built with that > option disabled. This means when those systems went into suspend, they > would use a global suspend for the USB buses -- without > CONFIG_USB_SUSPEND there was no support for selective suspend. > > Now they have no choice; CONFIG_USB_SUSPEND is effectively always > enabled. As a result, when going into system suspend, each individual > USB device is selectively suspended. This slows down the system > suspend and resume transitions -- not good for embedded systems. I > figured we could speed them back up again by adding explicit support > for global USB suspend. But since it interferes with remote wakeup, > that's not feasible. > > In theory, we could avoid using selective suspend on a device if > neither that device nor any of its descendants was enabled for remote > wakeup. That ought to give us the best of both worlds. I'll try to > write a patch to do this. That could work. > On a side note, there is still one disadvantage. Some USB hubs are > known to mess up if they are suspended at the same time as they receive > a wakeup request from a child device. They can lose the wakeup request > and maybe even disable the child's port. The only reliable way to > avoid this race is to use global suspend -- but now we see that this > leads to even worse problems! > > Given a choice between non-working wakeup and possible wakeup races, we > have to go for the lesser of two evils. Wakeup with occasional races > is better than no wakeup at all. I agree. > 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? 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? > P.S.: Sarah, to allay any possible concerns, I'm talking strictly about > non-SuperSpeed buses here. None of this applies in a SuperSpeed > environment, where there's no such thing as global suspend anyway. The hardware people were really only warning me about high speed hubs. SuperSpeed hubs were not their concern. 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
