On Wed, Jun 19, 2013 at 03:03:23PM -0400, Alan Stern wrote: > Sarah: > > This report surfaced in Bugzilla #59011 (see especially comments #38 > and #39). Toralf reports, among other things, that the integrated > "rate-matching" hub in his ThinkPad T420 (6 Series/C200 Series chipset) > isn't behaving the way it should. > > The particular symptom is that when the hub is suspended, it does not > relay wakeup requests from a downstream port to its upstream port, if > the downstream device is connected at low speed and the downstream > port's suspend feature isn't set. This happens with the 3.10-rc > kernels, because commit 0aa2832dd0d9 changed system suspend to do a USB > "global" bus suspend. None of the ports on non-SuperSpeed hubs are > explicitly put into suspend mode; instead, everything on the bus goes > into suspend when the root hub stops sending packets. You can't do the global suspend for USB 3.0 devices. Each USB 3.0 device has to be enabled for remote wakeup by sending it a Function Wake request, and then suspended. A global suspend will not work properly, because the devices will not be configured to send a wake request. That means that if you have a USB 3.0 hub that isn't suspended when the system is placed in S3, then it will not send remote wake requests. The other problem is that USB 3.0 hubs are all self-powered. What happens to their ports when the SoFs stop on the upstream port of the hub, but the downstream ports are still active? I'm not sure the USB 3.0 spec even defines this behavior. Perhaps that's the problem with the rate matching hub as well: it just isn't expecting to stop receiving SoFs when the downstream ports are in U0. > The problem is easy to test on any system running a 3.10-rc kernel. > Simply plug a low-speed USB keyboard (almost all keyboards are low > speed) into a USB-2 port, suspend the system, and then see if typing on > the keyboard will wake up the computer. You have to enable remote wakeup via a sysfs file as well, right? > I have tested a couple of external USB-2 hubs; one of them behaved > correctly and one didn't. Regardless, it was surprising to see > Toralf's report that an Intel hub doesn't work right. I don't have any > machines with a comparable chipset, so I can't test one of those > integrated hubs directly. > > Can somebody at Intel look into this? I don't think this is a hardware issue. I think the hardware just doesn't expect global suspend. I will ask the hardware engineers I know about it though. 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
