On Mon, Dec 10, 2012 at 11:29:38AM -0500, Alan Stern wrote: > On Mon, 10 Dec 2012, Lan Tianyu wrote: > > > Hi Alan&Greg: > > We meet a problem that bind usb3.0 port(supper-speed port) with ACPI. > > The main problem is that the port index num of ss port in the usb ocre > > is mismatched with its counterpart in the ACPI table. > > The xhci usb3.0 root hub port's index num is based on 0 in the usb > > core(xhci's usb3.0 and usb2.0 hub are separate usb device in the usb > > core). But in the ACPI table, it is based on the the port num of xhci > > usb2.0 port num. Following is the ACPI table code, _ADR is the port > > index num. The ss ports start from 0x0F. Just follow the high-speed port > > num. This sequence is matched with ports' sequence in the xhci extended > > capabilities table. So we have a idea that add a new callback of "struct > > hc_driver" to convert the port index num to the one of hc's extended > > capabilities table. > > 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? > > Another idea would be to dynamically allocate an array of ports in > > usb_hcd, and fill the port sequence of hc extended capabilities in with > > the speed of each rootport. That array pointer could be shared between > > the primary and shared usb_hcd structures. The xHCI driver already does > > this, by initializing xhci->port_array in > > drivers/usb/host/xhci-mem.c:xhci_setup_port_arrays(). > > The ACPI code needs to figure out the correct mapping. If you need an > extra callback to do this, that's okay. > > 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. 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
