From patchwork Wed May 2 20:22:54 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Bj=C3=B8rn_Mork?= X-Patchwork-Id: 10376421 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 224FC60384 for ; Wed, 2 May 2018 20:23:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 112A128E1E for ; Wed, 2 May 2018 20:23:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 024C028EAF; Wed, 2 May 2018 20:23:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 85C8628E1E for ; Wed, 2 May 2018 20:23:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751004AbeEBUXD (ORCPT ); Wed, 2 May 2018 16:23:03 -0400 Received: from canardo.mork.no ([148.122.252.1]:40187 "EHLO canardo.mork.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750939AbeEBUXD (ORCPT ); Wed, 2 May 2018 16:23:03 -0400 Received: from miraculix.mork.no (miraculix.mork.no [IPv6:2001:4641:0:2:7627:374e:db74:e353]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id w42KN1To003953 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 May 2018 22:23:01 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1525292581; bh=Nsy48cQzjU9kE1A8cwo4bWMAjfklBjuS1Q3J0AVnBSM=; h=From:To:Cc:Subject:Date:Message-Id:From; b=BCynDcicEZj0helh3yK+RPXMEPlf4BZntrljrpQN5KC/cMFe4v6kGQskzhq22x7wF uvCCWSj6DwBM+hZBQrwOHu0EUNW8TmVEIjolX20b+saWqpMqL/R9US88ItbjJdlNdn NuUlWOwHAmrPyxw8s39roC/j51mfQRpt6GYrIeEw= Received: from bjorn by miraculix.mork.no with local (Exim 4.89) (envelope-from ) id 1fDyHF-0000nQ-4Z; Wed, 02 May 2018 22:23:01 +0200 From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= To: netdev@vger.kernel.org Cc: linux-usb@vger.kernel.org, =?UTF-8?q?Bj=C3=B8rn=20Mork?= Subject: [PATCH net, stable] qmi_wwan: do not steal interfaces from class drivers Date: Wed, 2 May 2018 22:22:54 +0200 Message-Id: <20180502202254.3021-1-bjorn@mork.no> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.99.3 at canardo X-Virus-Status: Clean Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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: 03304bcb5ec4 ("net: qmi_wwan: use fixed interface number matching") Signed-off-by: Bjørn Mork --- It's quite possible that the fix should be integrated in the USB_DEVICE_INTERFACE_NUMBER macro instead. But that has grown a few other users since it was added, so changing it now seems risky. Another option is of course adding a new match macro with the USB_CLASS_VENDOR_SPEC match integrated. Maybe best? But I'm proposing this as-is for now, since this quickfix seems most suitable for stable backporting. drivers/net/usb/qmi_wwan.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 51c68fc416fa..42565dd33aa6 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -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");