On 2012年12月11日 01:59, 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? > >>> 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. Sorry, currently I have not seen such non-root usb3.0 hub on the board and ACPI spec has not said how to define the port num of its usb2.0 and usb3.0 ports. So I have no idea. But from my opinion, ACPI spec should contain rule to tell bios guy how to deal with this. From operation system side, we have a standard to bind usb3.0 hub ports with related ACPI nodes. I will try to push ACPI guys to pay more attention to this. Maybe there would a rule about this in the next ACPI spec. > > 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 > -- Best regards Tianyu Lan -- 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
