Received: by 2002:a05:6359:322:b0:b3:69d0:12d8 with SMTP id ef34csp115634rwb; Wed, 10 Aug 2022 05:51:24 -0700 (PDT) X-Google-Smtp-Source: AA6agR6sUxnvnX50pBKe1180DW272T3Nv+WAGyuxua+cRj6EuKlCdO+Hl9pDNIjbRGmVqR8xw5Ij X-Received: by 2002:a17:902:e744:b0:170:d01d:df10 with SMTP id p4-20020a170902e74400b00170d01ddf10mr10605888plf.40.1660135884085; Wed, 10 Aug 2022 05:51:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660135884; cv=none; d=google.com; s=arc-20160816; b=UJuAHDTA0z/KvOo7Bnb0nLwoJ6kfQDY0MGwepnhn0Ocq9uPbB/OwfqdMzPk0/ANV+J mataPAnOAAnFnKESZzKsic0oz7NgVw4aycGa/nVw+tZeem9zyUwa6FnX25nGxCyCUdhd sHrfIkkNqw3EFwR35VejCWoRkdqw8clbzoXVcWgmrVkZucj0irof34Bx8Jq5jx9qDKm4 gBmoPSxOTZHt8HcWg+ONs8OFvR0ej4u+a6tQ0/EPVgKvVYxPbWhRVAd7EJxh62uQ9jry OMUmZTW7sknMzQ1pS+czJaNQshi9nINWN6bQRZ9K3DuVcp3yrJa99+El4F/jtAbaleMZ CDYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:message-id:in-reply-to:date:references:organization :subject:cc:to:from:dkim-signature; bh=PNPycATN8VpMrxdiigaDnAXZauhanlnMGxj1GP+uRdM=; b=guWLdd0L/0Dm6Vw/esMZSevoHKJ/LxLzoB+J1okaaKghH7Q3DPuQjDPk4mVISN67ns E8NnLTuOU5As4GIzalMI1VyOzxu9FQnfZRIQPE/Um4QpeZ6ugR57pUCFCNsJsckXBIbu YpNtgtflNz0DOc71v199O2FNEEIcqqIp1TE+AdgnvFosB0ar3iz41aU4zR8SLm95pI10 W6ItaZevngHRW/x1eXO6pboWmESAoAzCPSAvh7WWDzCQN5cHKEdDAAEbYAbkPzInZDey 9RU5kiyjbE5YXbYcicWMbB+gMcVgGgpQfLZaYpO237dxY3565jdwhb7VX9ZGMMXNqmIa 9ZBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mork.no header.s=b header.b=PAC5HFFS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mork.no Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d16-20020a056a00199000b0052f83ad2322si2799415pfl.216.2022.08.10.05.51.11; Wed, 10 Aug 2022 05:51:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@mork.no header.s=b header.b=PAC5HFFS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mork.no Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231785AbiHJMgZ (ORCPT + 99 others); Wed, 10 Aug 2022 08:36:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33028 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230366AbiHJMgY (ORCPT ); Wed, 10 Aug 2022 08:36:24 -0400 Received: from louie.mork.no (louie.mork.no [IPv6:2001:41c8:51:8a:feff:ff:fe00:e5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F4CB8053B; Wed, 10 Aug 2022 05:36:23 -0700 (PDT) Received: from canardo.dyn.mork.no ([IPv6:2a01:799:c9d:7e00:0:0:0:1]) (authenticated bits=0) by louie.mork.no (8.15.2/8.15.2) with ESMTPSA id 27ACZa9F599307 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Wed, 10 Aug 2022 13:35:37 +0100 Received: from miraculix.mork.no ([IPv6:2a01:799:961:910a:a293:6d6e:8bbf:c204]) (authenticated bits=0) by canardo.dyn.mork.no (8.15.2/8.15.2) with ESMTPSA id 27ACZUMD651068 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Wed, 10 Aug 2022 14:35:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1660134931; bh=PNPycATN8VpMrxdiigaDnAXZauhanlnMGxj1GP+uRdM=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=PAC5HFFSC/gd+dZIaXRmoAFqL8ui+F8zwmFf1sfSxzuenJRbPb7hV1EtUvNQygvJt UKAI5BbDcNYOVLxt2P5EOnT5J93FFQLFSwNONfcSh/+UMmAvGiYUK2RLIPcqqcB7Rr 8pcS7xo9RLU4tQqIbvw80+oqww5eSCX/67UdVa1E= Received: (nullmailer pid 484366 invoked by uid 1000); Wed, 10 Aug 2022 12:35:25 -0000 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Slark Xiao Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: usb: qmi_wwan: Add support for Cinterion MV32 Organization: m References: <20220810014521.9383-1-slark_xiao@163.com> <8735e4mvtd.fsf@miraculix.mork.no> <61ca0e63.3207.18287214d7a.Coremail.slark_xiao@163.com> Date: Wed, 10 Aug 2022 14:35:24 +0200 In-Reply-To: <61ca0e63.3207.18287214d7a.Coremail.slark_xiao@163.com> (Slark Xiao's message of "Wed, 10 Aug 2022 17:41:22 +0800 (CST)") Message-ID: <87mtccl1ir.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.103.6 at canardo X-Virus-Status: Clean X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Slark Xiao" writes: > At 2022-08-10 17:28:51, "Slark Xiao" wrote: > >>I have a concern, if Cinterion or other Vendors, like Quectel, use other= =20 >>chip (such as intel, mediateck and so on), this methods may won't work, > > My bad. QMI_WWAN driver is designed for Qualcomm based chips only, > =C2=A0right?=20 Yes, but your concern is still valid if any of them re-use ff/ff/50 for something which is not RMNET/QMI. We do not want this driver to start matching a non-Qualcomm based device. >>because they share a same VID. Also this may be changed once Qualcomm=20 >>update the protocol patterns for future chip. Yes, that' a risk since we have no knowledge of Qualcomm's plans or thoughts around this. It's all pure guesswork from my side. But as such, it doesn't differ from the rest of this driver :-) Qualcomm can change whatever they want and we'll just have to follow up with whatever is required. Like what happened when raw-ip became mandatory. I do find it unlikely that Qualcomm will ever change the meaning of this pattern now that they've started using it. That would not make any sense. If they need to create a new vendor specific function type, then they can just use one of the "free" protocol numbers (and also subclass if they run out of protocol numbers). But it's your call. If you want to play it safe and keep the VID+PID matching, then I'm fine with that too. Bj=C3=B8rn