lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 11 Aug 2022 16:07:06 +0800 (CST)
From:   "Slark Xiao" <>
To:     Bjørn Mork <>
Subject: Re:Re: [PATCH] net: usb: qmi_wwan: Add support for Cinterion MV32

At 2022-08-10 20:35:24, "Bjørn Mork" <> wrote:
>"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 
>>>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,
>>  right? 
>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 
>>>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.

Then please help me apply it directly. There is no more commit 
request for MV32 serials if they don't update base line.


Powered by blists - more mailing lists