1 From foo@baz Wed May 16 16:57:32 CEST 2018
2 From: "Bjørn Mork" <bjorn@mork.no>
3 Date: Wed, 2 May 2018 22:22:54 +0200
4 Subject: qmi_wwan: do not steal interfaces from class drivers
6 From: "Bjørn Mork" <bjorn@mork.no>
8 [ Upstream commit 5697db4a696c41601a1d15c1922150b4dbf5726c ]
10 The USB_DEVICE_INTERFACE_NUMBER matching macro assumes that
11 the { vendorid, productid, interfacenumber } set uniquely
12 identifies one specific function. This has proven to fail
13 for some configurable devices. One example is the Quectel
14 EM06/EP06 where the same interface number can be either
15 QMI or MBIM, without the device ID changing either.
17 Fix by requiring the vendor-specific class for interface number
18 based matching. Functions of other classes can and should use
19 class based matching instead.
21 Fixes: 03304bcb5ec4 ("net: qmi_wwan: use fixed interface number matching")
22 Signed-off-by: Bjørn Mork <bjorn@mork.no>
23 Signed-off-by: David S. Miller <davem@davemloft.net>
24 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
26 drivers/net/usb/qmi_wwan.c | 12 ++++++++++++
27 1 file changed, 12 insertions(+)
29 --- a/drivers/net/usb/qmi_wwan.c
30 +++ b/drivers/net/usb/qmi_wwan.c
31 @@ -855,6 +855,18 @@ static int qmi_wwan_probe(struct usb_int
32 id->driver_info = (unsigned long)&qmi_wwan_info;
35 + /* There are devices where the same interface number can be
36 + * configured as different functions. We should only bind to
37 + * vendor specific functions when matching on interface number
39 + if (id->match_flags & USB_DEVICE_ID_MATCH_INT_NUMBER &&
40 + desc->bInterfaceClass != USB_CLASS_VENDOR_SPEC) {
42 + "Rejecting interface number match for class %02x\n",
43 + desc->bInterfaceClass);
47 /* Quectel EC20 quirk where we've QMI on interface 4 instead of 0 */
48 if (quectel_ec20_detected(intf) && desc->bInterfaceNumber == 0) {
49 dev_dbg(&intf->dev, "Quectel EC20 quirk, skipping interface 0\n");