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...? > 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. What sorts of trouble do you expect, aside from a large coding effort? > > 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? 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
