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? 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. 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. 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. Do you see a better alternative than adding a second usb_bus to usb_hcd? 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
