linux-kernel - Re: [PATCH] USB: serial: option: add Fibocom L7xx modules

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]

Message-ID: <ZUtf2CyQWY0RP0HK@hovoldconsulting.com>
Date:   Wed, 8 Nov 2023 11:15:52 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Victor Fragoso <victorffs@...mail.com>
Cc:     "larsm17@...il.com" <larsm17@...il.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] USB: serial: option: add Fibocom L7xx modules

On Tue, Nov 07, 2023 at 10:02:28PM +0000, Victor Fragoso wrote:
> On Sat, 2023-10-28 at 02:59 +0700, Lars Melin wrote:

> > Johan may have a different opinion from mine and he is the one to 
> > decide, my take is that there is no value in having a minor part of the 
> > list grouped by mfgr and the major part of the list sorted by USB Id.
> > We have also seen in the past that when a mfgr1 buys a chipset from 
> > mfgr2 and then sells his product with mfgr2 Id instead of using one of 
> > his own Id's then there is also not uncommon that mfgr3 is also buying 
> > the same chipset without changing Id. Hence "Manufacturer name" is not 
> > unique but the vid is..
> > 
> > The list should not be seen or used as a cross reference between 
> > mfgr:product name and vid:pid, anyone who needs to search the driver 
> > source to see if a device is supported ought to know its vid:pid so can 
> > search on those and that works much better if the list is sorted by 
> > vid:pid in ascending order. Personally I'd rather see a source without 
> > all the unnecessary defines, only vid:pid based and with the 
> > mfgr/product as an optional comment.
> > 
> > When adding Id's to the driver it is you who should know the devices you 
> > are adding, don't add Id's if you have not personally confirmed their 
> > interface composition and usage.
> > Those who told you add these Id's apparently also told you that there 
> > are two versions of 2cb7:0001, one with ECM interfaces and one with 
> > RNDIS interfaces but your usb-devices output show both to be identical.. 
> > There is no RNDIS interface in your listings, both of them will load
> > the cdc_ether driver.

> Lars, understood. Your point makes sense and I could accept it with no
> problems.
> 
> Johan, can you please share your opinion to decide?

I fully agree with Lars here.
 
> 1- Should I create a new commit inserting the PID grouped among to
> Fibocom's VID? Or separately on Fibocom's VID section and another one
> on ZTE's VID section?

So as Lars suggested, try to keep the list sorted by VID / PID (i.e.
split them up).

> 2- Should I remove the generic Fibocom product comment and add just the
> product/mode that I could test it? e.g. Fibocom L716-EU (ECM)

Yes, please do that.

Johan