On Mon, Dec 10, 2012 at 02:10:34PM -0500, Alan Stern wrote: > You seem to be saying that core/acpi.c can figure out everything it > needs, given the list of port speeds as described in the xHCI extended > capabilities. But the problem was caused originally by the way we > split the xHCI root hub into two. Since that split is implemented in > xhci-hcd, it seems to me that the xhci-hcd ought to be responsible for > providing a way to get at the underlying "raw" port list. Yes, that's exactly it. If we hadn't abstracted the xHCI driver into two roothubs, the ACPI code would be able to directly map the roothub ports to the ACPI methods that powered them off. > So I suggest a new HCD callback: Given a usb_hcd structure and a port > number, return the corresponding "raw" port number. In the absence of > a callback pointer, we can assume the two values are the same. Ok, sounds reasonable. > Do you think we will ever need to do the mapping in the other > direction? Meaning the xHCI driver would need to know which ACPI method was attached to a raw port? I don't think so. The code in usb-acpi.c should abstract that away from the xHCI driver. 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
