On Thu, Sep 01, 2011 at 11:32:54AM +0300, Felipe Balbi wrote: > On Wed, Aug 31, 2011 at 10:53:01PM -0400, Alan Stern wrote: > > Consider xHCI as an example. To what extent does it make sense to > > suspend/resume the low/full/high-speed bus independently of the > > SuperSpeed bus? I don't know enough about xHCI to say. The xHCI PCI host can only be put in D3 when all ports (USB 3.0 and USB 2.0) are suspended. So it really makes no sense to suspend the two buses separately. > Me neither, but I guess it shouldn't be a problem to keep both buses > suspended and enable them whenever we see a new device. After we know > the kind of device, we switch off the unused bus. I mean, if we're > attached directly to a superspeed device, we can suspend the > low/full/high-speed side, if we're connected to a low/full/high-speed > device, we can suspend the superspeed side and if we're connected to a > hub, we keep both sides resumed. The xHCI host controller advertises which ports handle USB 3.0 devices and which handle USB 2.0 devices, and the ports never switch roles, so the xHCI driver always knows whether a SuperSpeed or non-SuperSpeed device is attached on a port. > > Anyway, the changes I'm talking about are minimal. Just how minimal > > it's hard to say without doing some serious thinking about the proposed > > new software design, but I bet they could be made pretty small. > > Ok, I would need to see them. But as of now, I think it's unnecessary > :-p I do think separating the usb_hcd and usb_bus structure is necessary (they were a *horrible* mess to work with while splitting the xHCI roothub), but I'm not yet convinced it's the correct solution to the issue with non-PCI hosts. 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
