Hi Peter,

On Mon, Jan 04, 2021 at 12:58:39AM +0000, Peter Chen wrote:

quoted

quoted

Hi Jack,

I am curious what features are broken if the functions are added with
not planned order?

Hi Peter,

This is mainly an issue for devices with functions that use vendor- specific
instead of standard class/subclass IDs for their interface descriptors. Android
ADB and Qualcomm QMI are a couple examples. So host interface drivers
would only be able to install or bind based on matching VID/PID and interface
position only. This is true for both Windows as well as Linux (see
USB_DEVICE_INTERFACE_NUMBER).

So if the gadget's function bind order gets jumbled up from the intended order,
the resulting assigned interface numbers would be different and the host would
not match its drivers to the correct interface. Instead we see the host driver
gets bound but the endpoints it communicates with are wrong as they are for a
completely different interface.

 
Thanks for your information, jack. But does Android ADB has specific host driver, I am
assumed it uses drivers/usb/core/devio.c, am I wrong?

That is true for the Linux ADB client; it does use usbdevfs directly,
and it does match based on the vendor Class/Subclass/Protocol so it's
generally not a problem for ADB connected to Linux hosts.

However for the Windows adb.exe client, it uses the native WinUSB
driver which typically needs an associated INF file to declare what
VID/PID/Interface is to be used for the ADB interface. (Alternatively,
the WinUSB driver can be automatically installed if the device provides
MSFT OS Descriptors during enumeration to indicate if an interface uses
WinUSB, so that might avoid requiring an INF file.) But regardless, in
either case the installed driver information gets stored in the Windows
registry and is always tied to VID/PID/Interface, so subsequent
connections to the same device must always enumerate in the same
function order otherwise the problem I stated above will happen.

Further, if a device has a QMI interface (we have downstream QMI
function drivers that many commercial Android devices use) that
drivers/net/usb/qmi_wwan.c is expecting to bind to, because the majority
of the usb_device_id entries in this driver uses QMI_FIXED_INTF /
USB_DEVICE_INTERFACE_NUMBER, these devices could unfortunately suffer
this problem if the function bind order is not guaranteed and the
interface appears in a different position than expected.

Thanks,
Jack
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project