linux-kernel - Re: [PATCH] USB: serial: option: adding support for ublox R410M

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:   Thu, 26 Apr 2018 13:19:17 +0200
From:   Bjørn Mork <bjorn@...k.no>
To:     Johan Hovold <johan@...nel.org>
Cc:     Lars Melin <larsm17@...il.com>,
        SZ Lin (林上智) <sz.lin@...a.com>,
        stable <stable@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        Dan Williams <dcbw@...hat.com>
Subject: Re: [PATCH] USB: serial: option: adding support for ublox R410M

Johan Hovold <johan@...nel.org> writes:
> On Thu, Apr 26, 2018 at 02:48:54PM +0700, Lars Melin wrote:
>> On 4/26/2018 14:09, Johan Hovold wrote:
>> > On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
>> >> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
>> >> driver, this module supports LTE Cat M1 / NB1.
>> >>
>> >> Interface layout:
>> >> 0: QCDM/DIAG
>> >> 1: ADB
>> >> 2: AT
>> >> 3: RMNET
>> >>
>> >> Signed-off-by: SZ Lin (林上智) <sz.lin@...a.com>
>> >> Cc: stable <stable@...r.kernel.org>
>> > 
>> > Applied, thanks.
>> > 
>> > Johan
>> 
>> With a Qualcomm Device Management interface, shouldn't this modem be 
>> driven by qcserial?
>
> Hmm, we already have some QCDM interfaces handled by option and qcaux so
> it's not that clear-cut.
>
> Dan and Björn had a discussion about this a while back, so adding them
> on CC. It seems to me that this device does not fit the intended use (or
> Gobi 1000 layout) for qcserial, but I may be mistaken.

tl;dr; I don't think qcserial is relevant unless a device matches one of
the pre-defined layout schemes.

But I'm too new in this game to say anything about the initial
intentions... 

My view of the present situation is that qcserial handles interface
layouts shared among many devices, while option handles interface
layouts which are unique per device, and vendor+class based function
mappings.  But I could be wrong.

Anyway, Qualcomm based designs are definitely handled by both drivers.
Using qcserial only makes sense if the interface layout matches one of
the defined shared schemes, which currently are:

	QCSERIAL_G2K = 0,	/* Gobi 2000 */
	QCSERIAL_G1K = 1,	/* Gobi 1000 */
	QCSERIAL_SWI = 2,	/* Sierra Wireless */
	QCSERIAL_HWI = 3,	/* Huawei */

or if similar logic is added for a new vendor/shceme

And I see multi-vendor-id usage as the main reason for these
schemes. There isn't much reason if you can make it a single match
against a vendor-id.

The original Gobi devices are obviously multi-vendor, and Sierra
Wireless and Huwaei are OEMs making devices for a number of laptop
vendors. This causes traditional vendor-id matching to fail, as e.g. a
HP device can be made by either OEMs (or others). qcserial has become a
convenient way to map a long list of full device IDs to a specific OEM
layout.

Bjørn