On 10/28/2015 08:40 PM, Greg Kroah-Hartman wrote:
+static const char *get_extcap_desc(u32 cap_id) >+{ >+ switch (cap_id) { >+ case XHCI_EXT_CAPS_LEGACY: >+ return "USB Legacy Support"; >+ case XHCI_EXT_CAPS_PROTOCOL: >+ return "Supported Protocol"; >+ case XHCI_EXT_CAPS_PM: >+ return "Extended Power Management"; >+ case XHCI_EXT_CAPS_VIRT: >+ return "I/O Virtualization (xHCI-IOV)"; >+ case XHCI_EXT_CAPS_ROUTE: >+ return "Message Interrupt"; >+ case XHCI_EXT_CAPS_LOCALMEM: >+ return "Local Memory"; >+ case XHCI_EXT_CAPS_DEBUG: >+ return "USB Debug Capability";This is a lot more stuff than just debug port, it should be in sysfs as individual files, not one big one that you somehow have to parse in order to determine this information.
Hi Greg, It's hard to put each extended capability into a individual sysfs file. The extended capabilities are optional. One extended capability might be supported in one hardware, but not in another. Also, there are many "vendor defined" capabilities (ID range 192-255). The vendor defined capabilities are not defined in xhci spec and they could be used by the hardware vendor for various purposes. The purpose of this patch is to let user know what kind of extended capabilities does a host controller supported. For example, on one of my develop machines, it prints, @addr(virt) CAP_ID Description @ffffc90001c88000 02 Supported Protocol @ffffc90001c88020 02 Supported Protocol @ffffc90001c88070 c0 Vendor Defined @ffffc90001c8846c 01 USB Legacy Support @ffffc90001c884f4 c6 Vendor Defined @ffffc90001c88500 c7 Vendor Defined @ffffc90001c88600 c2 Vendor Defined @ffffc90001c88700 0a USB Debug Capability @ffffc90001c88740 c3 Vendor Defined @ffffc90001c88800 c4 Vendor Defined @ffffc90001c88900 c5 Vendor Defined With this output I know that "USB Debug Capability" is supported in my machine. Thanks, Baolu -- 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
