[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20190913.210914.459044600119292225.davem@davemloft.net>
Date: Fri, 13 Sep 2019 21:09:14 +0100 (WEST)
From: David Miller <davem@...emloft.net>
To: bjorn@...k.no
Cc: netdev@...r.kernel.org, oliver@...kum.org,
linux-usb@...r.kernel.org, larsm17@...il.com
Subject: Re: [PATCH net,stable] cdc_ether: fix rndis support for Mediatek
based smartphones
From: Bjørn Mork <bjorn@...k.no>
Date: Thu, 12 Sep 2019 10:42:00 +0200
> A Mediatek based smartphone owner reports problems with USB
> tethering in Linux. The verbose USB listing shows a rndis_host
> interface pair (e0/01/03 + 10/00/00), but the driver fails to
> bind with
>
> [ 355.960428] usb 1-4: bad CDC descriptors
>
> The problem is a failsafe test intended to filter out ACM serial
> functions using the same 02/02/ff class/subclass/protocol as RNDIS.
> The serial functions are recognized by their non-zero bmCapabilities.
>
> No RNDIS function with non-zero bmCapabilities were known at the time
> this failsafe was added. But it turns out that some Wireless class
> RNDIS functions are using the bmCapabilities field. These functions
> are uniquely identified as RNDIS by their class/subclass/protocol, so
> the failing test can safely be disabled. The same applies to the two
> types of Misc class RNDIS functions.
>
> Applying the failsafe to Communication class functions only retains
> the original functionality, and fixes the problem for the Mediatek based
> smartphone.
>
> Tow examples of CDC functional descriptors with non-zero bmCapabilities
> from Wireless class RNDIS functions are:
...
> The Mediatek example is believed to apply to most smartphones with
> Mediatek firmware. The ZTE example is most likely also part of a larger
> family of devices/firmwares.
>
> Suggested-by: Lars Melin <larsm17@...il.com>
> Signed-off-by: Bjørn Mork <bjorn@...k.no>
Applied and queued up for -stable, thanks.
Powered by blists - more mailing lists