On Mon, 10 Dec 2012, Sarah Sharp wrote: > > Is there any reason the ACPI port number should have any connection > > with the port numbers used by usbcore, even for USB-2 controllers? > > If there is no connection at all, how is Windows supposed to know which > ACPI method turns off which port? You're asking _me_ questions about Windows? :-) Yes, I realize that was meant to be a rhetorical question. I was really asking if the connection might be embedded as code in an ACPI driver somewhere, instead of data in some tables. I guess the answer is "No". > > What about hubs that aren't root hubs but are still represented in > > ACPI? > > I'm not sure how integrated non-roothub hubs (like rate matching hubs or > integrated USB 3.0 hubs) will be represented in the ACPI table. From a > bus perspective, the external USB 3.0 hubs are two separate devices, but > physically they're the same device. Maybe Tianyu can give an example of > how the ACPI specification says they are supposed to be laid out. > > If the non-roothub USB 3.0 hubs are represented by one ACPI object, that > could be problematic. Right now, the USB core isn't able to track the > USB 3.0 hub with its physical USB 2.0 hub partner. We can't rely on > matching with USB 3.0 and USB 2.0 bus topology because xHCI hosts can > introduce a tier-mismatch by including a rate-matching attached one USB > 2.0 port. > > Theoretically, you're supposed to be able to match partner hubs by > looking at the Container ID. It's supposed to be a serial number that > both the USB 2.0 hub and the USB 3.0 hub implement. The serial number > for each physical hub is supposed to be unique across all hubs from a > particular manufacturer. And guess what is all-zeroes in the VIA hubs > I've bought off the market? Yep, the Container ID. Well, if we can't solve that problem then let's ignore it. :-) 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. 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. Do you think we will ever need to do the mapping in the other direction? 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
