linux-kernel - Re: [PATCH] net: usb: qmi_wwan: Add support for Cinterion MV32

lists.openwall.net		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:   Wed, 10 Aug 2022 08:55:42 +0200
From:   Bjørn Mork <bjorn@...k.no>
To:     Slark Xiao <slark_xiao@....com>
Cc:     davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com, netdev@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: usb: qmi_wwan: Add support for Cinterion MV32

Slark Xiao <slark_xiao@....com> writes:

> There are 2 models for MV32 serials. MV32-W-A is designed
> based on Qualcomm SDX62 chip, and MV32-W-B is designed based
> on Qualcomm SDX65 chip. So we use 2 different PID to separate it.
>
> Test evidence as below:
> T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=03 Dev#=  3 Spd=480 MxCh= 0
> D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
> P:  Vendor=1e2d ProdID=00f3 Rev=05.04
> S:  Manufacturer=Cinterion
> S:  Product=Cinterion PID 0x00F3 USB Mobile Broadband
> S:  SerialNumber=d7b4be8d
> C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA
> I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
> I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
> I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
> I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option

The patch looks nice, but I have a couple of questions since you're one
of the first pushing one of these SDX6x modems.

Is that protocol pattern fixed on this generation of Qualcomm chips?  It
looks like an extension of what they started with the SDX55 generation,
where the DIAG port was identified by ff/ff/30 across multiple vendors.

Specifically wrt this driver and patch, I wonder if we can/should match
on ff/ff/50 instead of interface number here?  I note that the interface
numbers are allocated sequentionally. Probably in the order these
function are enabled by the firmware? If so, are we sure this is static?
Or could we risk config variants where the RMNET/QMI function have a
different interface number for the same PIDs?

And another possibility you might consider.  Assuming that ff/ff/50
uniquely identifies RMNET/QMI functions regardless of PID, would you
consider a VID+class match to catch all of them?  This would not only
support both the PIDs of this patch in one go, but also any future PIDs
without the need for further driver patches.

Bjørn