Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   =?utf-8?Q?Bj=C3=B8rn_Mork?= <bjorn@mork.no>
To:     Johan Hovold <johan@kernel.org>
Cc:     Lars Melin <larsm17@gmail.com>,
        SZ Lin =?utf-8?B?KOael+S4iuaZuik=?= <sz.lin@moxa.com>,
        stable <stable@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
        Dan Williams <dcbw@redhat.com>
Subject: Re: [PATCH] USB: serial: option: adding support for ublox R410M
Organization: m
References: <20180426062831.320-1-sz.lin@moxa.com>
        <20180426070927.GT4615@localhost>
        <72c63853-aa2d-e74c-1112-36d54ef52a85@gmail.com>
        <20180426081403.GA335@localhost>
Date:   Thu, 26 Apr 2018 13:19:17 +0200
In-Reply-To: <20180426081403.GA335@localhost> (Johan Hovold's message of "Thu,
        26 Apr 2018 10:14:03 +0200")
Message-ID: <87r2n25i6i.fsf@miraculix.mork.no>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Johan Hovold <johan@kernel.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 (=E6=9E=97=E4=B8=8A=
=E6=99=BA) 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 (=E6=9E=97=E4=B8=8A=E6=99=BA) <sz.lin@moxa.com>
>> >> Cc: stable <stable@vger.kernel.org>
>> >=20
>> > Applied, thanks.
>> >=20
>> > Johan
>>=20
>> With a Qualcomm Device Management interface, shouldn't this modem be=20
>> 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=C3=B6rn had a discussion about this a while back, so adding th=
em
> 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...=20

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 =3D 0,	/* Gobi 2000 */
	QCSERIAL_G1K =3D 1,	/* Gobi 1000 */
	QCSERIAL_SWI =3D 2,	/* Sierra Wireless */
	QCSERIAL_HWI =3D 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=C3=B8rn