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: 907691 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=mork.no Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=mork.no header.i=@mork.no header.b="BCynDcic"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 40bqTm1G8yz9s27 for ; Thu, 3 May 2018 06:23:07 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751084AbeEBUXF (ORCPT ); Wed, 2 May 2018 16:23:05 -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_Mork?= To: netdev@vger.kernel.org Cc: linux-usb@vger.kernel.org, =?utf-8?q?Bj=C3=B8rn_Mork?= 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: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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");