On Mon, Dec 10, 2012 at 06:53:04AM -0800, Greg Kroah-Hartman wrote: > On Mon, Dec 10, 2012 at 04:42:23PM +0800, 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. > > Why do you care that the numbers don't match, you shouldn't ever be > relying on these numbers for anything "real" anyway. What do you need > them for? > > > 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. > > Why would you need this? What are you trying to solve here that this > matters? The problem is that the ACPI table treats the roothub (with both USB 3.0 and USB 2.0 ports) as one object. The USB core breaks them up into two roothub objects (one USB 3.0-only roothub, and one USB 2.0 roothub). So the basic problem is how do we map the ports from the two USB core roothubs to the ACPI method that powers the port off? The first (not so great) pass was to just assume that USB 2.0 ports will always be listed before USB 3.0 ports in the ACPI table. However, the xHCI spec has no requirements that this will always be true. The xHCI extended capabilities lists each block of ports and what their speed is. They're actually set up so that hosts could (potentially) have a block of USB 3.0 registers, followed by a block of USB 2.0 registers, followed by another block of USB 3.0 registers, etc. This is further complicated by the fact that you can't tell from the ACPI table which speed a port is. It's just not designed into the ACPI spec. *Head-desk* However, for the Windows code to work at all, the ACPI table has to be in the same order that the xHCI port registers are in. So the problem Tianyu and I were trying to solve is how do we export the USB port speed list from the xHCI extended capabilities to the USB core ACPI code that matches USB ports to their ACPI power off method? As Tianyu mentioned, we think there are two options. Either we add a new HCD callback that tells the ACPI core what speed the raw port number is (and by raw I mean the port number from the xHCI extended capabilities). Or we can add a dynamically allocated list of the raw port speeds, and share that between the usb_hcd structures. 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
