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:   Fri, 29 Jul 2022 14:13:56 +0800
From:   sdlyyxy <sdlyyxy@...t.edu.cn>
To:     Johan Hovold <johan@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Reinhard Speyerer <rspmn@...or.de>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: usb-serial-simple: add new device id for OPPO R11


> On Jul 24, 2022, at 22:26, Johan Hovold <johan@...nel.org> wrote:
> 
> On Sun, Jul 24, 2022 at 04:00:36PM +0200, Greg Kroah-Hartman wrote:
>> On Sat, Jul 23, 2022 at 06:36:25PM +0200, Johan Hovold wrote:
>>> On Mon, Jul 18, 2022 at 10:47:24PM +0200, Reinhard Speyerer wrote:
> 
>>>> Please don't give the OPPO R11 diag port on Linux a bad name by letting
>>>> the usb-serial-simple driver handle it.
>>> 
>>> So while I'm not sure bandwidth is really a problem, I still tend to
>>> agree that we should add this one to the option driver for now as that
>>> is how we handle (non-GOBI) Qualcomm modems and their QCDM ports.
>> 
>> If you want it to stay on the option driver, that's fine, but I still
>> think it feels odd as it obviously does not follow the vendor-specific
>> protocol that the option driver supports.
> 
> But we've been dumping modem device-id entries in there since forever.
> 
> The entries added to option have been for devices whose interfaces did
> not follow any particular pattern (e.g. unlike the old GOBI modems).
> 
> And as Reinhard mentioned, the line-control requests (which follow CDC)
> are actually required by some Qualcomm modems so moving things out would
> need to be done carefully.
> 
> On the other hand, that request likely isn't needed for any QCDM/DIAG
> ports, but who knows for sure.

Test result for bandwidth problem:
Sending 0x1f mask (diag command: 0x7d0500001f000000) and running LTE
speedtest on the device, both option and simple can dump more than 80Mbps.
The CRC of diag packets is OK at this high speed, so it seems that
there is no message loss. I think this bandwidth is enough.

For the flow control problem, it seems the SetControlLineState request
send by option (usb_wwan) has no effect on the device. Both with and
without this request the diag port works the same.

Hope this can help you decide which driver to choose :)

Thanks,
sdlyyxy


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ