Skip to content

Commit

Permalink
qmi_wwan: do not steal interfaces from class drivers
Browse files Browse the repository at this point in the history
The USB_DEVICE_INTERFACE_NUMBER matching macro assumes that
the { vendorid, productid, interfacenumber } set uniquely
identifies one specific function.  This has proven to fail
for some configurable devices. One example is the Quectel
EM06/EP06 where the same interface number can be either
QMI or MBIM, without the device ID changing either.

Fix by requiring the vendor-specific class for interface number
based matching.  Functions of other classes can and should use
class based matching instead.

Fixes: 03304bc ("net: qmi_wwan: use fixed interface number matching")
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
  • Loading branch information
Bjørn Mork authored and David S. Miller committed May 3, 2018
1 parent 94720e3 commit 5697db4
Showing 1 changed file with 12 additions and 0 deletions.
12 changes: 12 additions & 0 deletions drivers/net/usb/qmi_wwan.c
Original file line number Diff line number Diff line change
Expand Up @@ -1344,6 +1344,18 @@ static int qmi_wwan_probe(struct usb_interface *intf,
id->driver_info = (unsigned long)&qmi_wwan_info;
}

/* There are devices where the same interface number can be
* configured as different functions. We should only bind to
* vendor specific functions when matching on interface number
*/
if (id->match_flags & USB_DEVICE_ID_MATCH_INT_NUMBER &&
desc->bInterfaceClass != USB_CLASS_VENDOR_SPEC) {
dev_dbg(&intf->dev,
"Rejecting interface number match for class %02x\n",
desc->bInterfaceClass);
return -ENODEV;
}

/* Quectel EC20 quirk where we've QMI on interface 4 instead of 0 */
if (quectel_ec20_detected(intf) && desc->bInterfaceNumber == 0) {
dev_dbg(&intf->dev, "Quectel EC20 quirk, skipping interface 0\n");
Expand Down

0 comments on commit 5697db4

Please sign in to comment.