On Fri, 24 Sep 2010, Sarah Sharp wrote: > On Fri, Sep 24, 2010 at 11:04:50AM -0400, Alan Stern wrote: > > On Thu, 23 Sep 2010, Sarah Sharp wrote: > > > > > Hi Alan, > > > > > > I'm working on separating out the xHCI roothub into a USB 3.0 and a USB > > > 2.0 roothub, and it's turning out to touch way more code than I > > > expected. Before I go too far down the rabbit hole, can you check > > > whether my initial design is sane? > > > > Sure. > > > > > It turns out that the xHCI host has two completely separate busses for > > > USB 3.0 and non-SuperSpeed ports. So a USB 3.0 device can have the same > > > address as a USB 2.0 device under the same roothub. That to me sounds > > > like an argument for having separate usb_bus structures in struct > > > usb_hcd. > > > > I disagree; this approach will only lead to trouble -- as you have > > discovered. Since we essentially make no distinction between a usb_bus > > and a usb_hcd, you should have two of each. > > Hmm, what about the bandwidth_mutex in usb_hcd? That's supposed to keep > the actions of setting up the changed config/interface, sending the > control message to the device, and possibly reverting those changes if > they failed as one atomic operation. If there's two usb_hcd structures, > it seems like there ought to be a larger structure to hold the bandwidth > mutex. Unless one of the bandwidth mutexes could just point to the > other...? Is this really an issue? Don't the LS/FS/HS bus and the SS bus have totally independent bandwidth requirements? And doesn't that mean you can make simultaneous changes to both without interference? > > In retrospect the distinction between the two types of structures > > should have been made more carefully. But when the code was originally > > written, nobody foresaw the possibility of having one host controller > > running multiple buses. In fact, I can't think of any other sort of > > I/O bus where that happens. So now we have to live with the > > situation... > > Or I could see how difficult extracting the two structures are. It's > entirely possible we'll run into this issue again, now that the idea of > two buses has been introduced. You mean that USB-4.0 might add another four wires to the cable (making the connector that much larger) and force the controller to manage three buses? At what point does the madness stop? :-) > What sorts of trouble do you expect, > aside from a large coding effort? (And the possibility of introducing bugs while making such a widespread set of changes.) There might be some difficulty deciding which layer certain items belong in. Bear in mind that items which are controller-wide in USB-3.0 might change to be bus-specific in USB-4.0 -- then what will you do? > > > And then there's the question of what to do about power management for > > > the xHCI roothub. It's obvious we shouldn't suspend the PCI controller > > > until both buses are suspended, but I haven't looked at the suspend > > > code to see if it's even feasible. > > > > That's not a problem. The PM core won't suspend the PCI device unless > > all its children (i.e., both root hubs) are already suspended. > > > > The problem is that the pci_dev structure has room for only one > > driver-data pointer, and you will presumably set it to point to the > > usb_hcd for the USB-3.0 bus. Its suspend and resume routines will have > > to manage the hardware for both buses. This will mean repeating one or > > two of the tests in core/hcd-pci.c:suspend_common(). > > You mean like calling check_root_hub_suspended() for both roothubs? Yes, although that particular check probably isn't needed any more. I was thinking more of the HCD_WAKEUP_PENDING things. 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
