On Mon, 1 Jul 2013, Greg KH wrote: > On Mon, Jul 01, 2013 at 08:25:20PM -0700, Sarah Sharp wrote: > > On Mon, Jun 24, 2013 at 02:14:04PM -0400, Alan Stern wrote: > > > If the hardware doesn't expect global suspend, that's a hardware issue. > > > After all, global suspend is part of the USB-2 spec and we're talking > > > about USB-2 hubs. > > > > The response I got from the hardware team was basically: "Windows > > doesn't do global suspend. Other external USB 2.0 hubs are likely to > > have issues as well." Basically, a polite way of saying, "You're in > > uncharted territory, and likely to run into more bugs." Unfortunately, the hardware people are right. Hubs made by Genesys Logic have a similar bug, and I wouldn't be surprised if other hubs do too. > > I would really really recommend not going down the global suspend path. > > I would *strongly* recommend we just revert the global suspend patches. > > Ick, if Windows doesn't do it, we will run into problems, that's not > good at all. How much work is it to revert things? 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. 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. 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? Alan Stern 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. -- 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
