On Mon, 24 Jun 2013, Sarah Sharp wrote: > 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. Sure. The problem I'm talking about is specific to USB-2 hubs. Or more precisely, to non-SuperSpeed hubs -- it may well apply to the non-SuperSpeed portions of a USB-3 hub (I don't have any to test). In this case, I'm particularly concerned about the "rate-matching" hubs used in Intel chipsets; these are always USB-2 because they are hard-wired to the EHCI controllers. [Is there any reason you can't use global suspend with a USB-3 hub if it is attached to the computer by a USB-2 cable? As I understand it, in that case the hub's behavior is supposed to be governed by the USB-2 spec. Or is there any reason you can't use global suspend with the ports on a USB-3 hub that are currently connected at low, full, or high speed?] > > 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? Keyboards are enabled for remote wakeup by default. If you used a mouse instead of a keyboard then yes, you would have to enable it manually. > > 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. 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. > I will ask the hardware engineers I know > about it though. Thanks. Alan Stern -- 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
