On Mon, Dec 10, 2012 at 09:59:32AM -0800, Sarah Sharp wrote: > 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? Why is this being driven from ACPI, shouldn't it be the other way around, the OS asks the controller to shut itself down? Why is the ACPI core getting involved here? What exactly are you trying to do? thanks, greg k-h -- 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
