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? > 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? 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
