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. > Originally, my idea was to set the speed of the roothub USB device > (usb_bus->root_hub) to either USB 3.0 or USB 2.0, and key off that in > the xHCI hub functions to determine whether the driver should be > returning the port status for the USB 3.0 ports, or the USB 2.0 ports. > Only it turns out hub_status_data() and hub_control() are called with > the usb_hcd pointer, not the usb_bus pointer. This means I have to > modify all the hub functions of all the hosts to straighten that out. > > Plus, there are other ways that the "hcd is-a bus" mentality has blurred > the line between the host and the bus. The status urb and timer for the > roothub are currently in usb_hcd, and would need to be moved into > usb_bus. I would have create a pointer back to usb_hcd in usb_bus, > since the preferred way to get an hcd from a bus is to use > container_of(), which won't work if there is a second bus. Having two usb_hcd structures will solve all of this. 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... > 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(). 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
