On Thu, 11 Jul 2013, Sarah Sharp wrote: > > 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. Does the USB-3 spec say what should happen when a remote wakeup signal on a downstream port in U3 races with a U0->U3 transition on the hub's upstream port? I tried to figure it out, but section 10.8 doesn't seem to consider that the upstream port might go into U3 while a downstream port is driving a remote wakeup signal. Figure 10-13 is ambiguous too. 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
