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]

Message-ID: <5fb0b88573985caeb5ce2732ae217f60fbcfe965.camel@redhat.com>
Date:   Thu, 26 Apr 2018 14:12:32 -0500
From:   Dan Williams <dcbw@...hat.com>
To:     Johan Hovold <johan@...nel.org>, Lars Melin <larsm17@...il.com>
Cc:     Bjørn Mork <bjorn@...k.no>,
        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
Subject: Re: [PATCH] USB: serial: option: adding support for ublox R410M

On Thu, 2018-04-26 at 18:29 +0200, Johan Hovold wrote:
> On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> > On 4/26/2018 23:12, Johan Hovold wrote:
> > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> > > > On 4/26/2018 18:39, Lars Melin wrote:
> > > > > On 4/26/2018 18:19, Bjørn Mork wrote:
> > > > > > 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 */
> > > > > 
> > > > > It seems to me that this Quectel device matches the interface
> > > > > layout for
> > > > > Gobi1K:
> > > Yeah, but qcserial appears to select a different altsetting for
> > > the DM
> > > port for Gobi 1000, an altsetting which this particular device
> > > does not
> > > have.
> > > 
> > > I didn't re-read the full thread I referred to earlier, but I
> > > think in
> > > it, Dan mentioned Gobi 1000 device requiring firmware to be
> > > loaded too.
> > > 
> > > So if it's not a G1K device, we probably shouldn't be using
> > > qcserial
> > > even if the interface layout happens to match.
> > Good point, I forgot about the required firmware loading for
> > Gobi1K.
> > So this device should be handled by the option driver.
> 
> Yeah, we probably should document all of this at some point. :)
> 
> I didn't include the patch in this weeks -rc updates, but I've queued
> it
> up for the next batch.

Option is likely the right driver for this device.

qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as
the modem port and a secondary DIAG/DM port driven by qcaux.  The DM
port doesn't have an interrupt endpoint thus it's not a normal modem
port requiring the larger buffers of option and its control signaling.

qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with
the specific layouts and the firmware loading requirement where the 1K
and 2K devices start in a special 1-port mode waiting for firmware and
then become 4-port devices on firmware reboot.

Dan