netdev - Re: [PATCH net-next] qmi_wwan: Add quirk for Quectel dynamic config

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 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:   Sun, 07 Apr 2019 17:27:11 +0200
From:   Bjørn Mork <bjorn@...k.no>
To:     Kristian Evensen <kristian.evensen@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next] qmi_wwan: Add quirk for Quectel dynamic config

Kristian Evensen <kristian.evensen@...il.com> writes:

> Most, if not all, Quectel devices use dynamic interface numbers, and
> users are able to change the USB configuration at will. Matching on for
> example interface number is therefore not possible.
>
> Instead, the QMI device can be identified by looking at the interface
> class, subclass and protocol (all 0xff), as well as the number of
> endpoints. The reason we need to look at the number of endpoints, is
> that the diagnostic port interface has the same class, subclass and
> protocol as QMI. However, the diagnostic port only has two endpoints,
> while QMI has three.
>
> Until now, we have identified the QMI device by combining a match on
> class, subclass and protocol, with a call to the function
> quectel_diag_detect(). In quectel_diag_detect(), we check if the number
> of endpoints matches for known Quectel vendor/product ids.
>
> Adding new vendor/product ids to quectel_diag_detect() is not a good
> long-term solution. This commit replaces the function with a quirk, and
> applies the quirk to affected Quectel devices that I have been able to
> test the change with (EP06, EM12 and EC25). If the quirk is set and the
> number of endpoints equal two, we return from qmi_wwan_probe() with
> -ENODEV.
>
> Signed-off-by: Kristian Evensen <kristian.evensen@...il.com>

Looking really good to me.  Thanks for doing this.

I guess this has to go to (at least some of) the stable trees
eventually, but assume you directed it to net-next for more thorough
testing first?

Acked-by: Bjørn Mork <bjorn@...k.no>