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;
From:   =?utf-8?Q?Bj=C3=B8rn_Mork?= <bjorn@mork.no>
To:     Slark Xiao <slark_xiao@163.com>
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>
        <e7fdcfc.30e7.1828715d7af.Coremail.slark_xiao@163.com>
        <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
Precedence: bulk

"Slark Xiao" <slark_xiao@163.com> writes:
> At 2022-08-10 17:28:51, "Slark Xiao" <slark_xiao@163.com> 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