From: Johan Hovold <johan@kernel.org>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: Johan Hovold <johan@kernel.org>,
linux-usb@vger.kernel.org, AceLan Kao <acelan.kao@canonical.com>,
Sebastian Sjoholm <ssjoholm@mac.com>,
Dan Williams <dcbw@redhat.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] USB: serial: option: support dynamic Quectel USB compositions
Date: Mon, 31 Aug 2020 08:44:52 +0200 [thread overview]
Message-ID: <20200831064452.GO21288@localhost> (raw)
In-Reply-To: <20200829134250.59118-1-bjorn@mork.no>
On Sat, Aug 29, 2020 at 03:42:50PM +0200, Bjørn Mork wrote:
> The USB composition, defining the set of exported functions, is dynamic
> in newer Quectel modems. Default functions can be disabled and
> alternative functions can be enabled instead. The alternatives
> includes class functions using interface pairs, which should be
> handled by the respective class drivers.
>
> Active interfaces are numbered consecutively, so static
> blacklisting based on interface numbers will fail when the
> composition changes. An example of such an error, where the
> option driver has bound to the CDC ECM data interface,
> preventing cdc_ether from handling this function:
>
> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
> D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=2c7c ProdID=0125 Rev= 3.18
> S: Manufacturer=Quectel
> S: Product=EC25-AF
> C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
> A: FirstIf#= 4 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
> E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
> E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 4 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=(none)
> E: Ad=89(I) Atr=03(Int.) MxPS= 16 Ivl=32ms
> I:* If#= 5 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=option
> I: If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=option
> E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>
> Another device with the same id gets correct drivers, since the
> interface of the network function happens to be blacklisted by option:
>
> T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
> D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=2c7c ProdID=0125 Rev= 3.18
> S: Manufacturer=Android
> S: Product=Android
> C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
> E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
> E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
> E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
> E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>
> Change rules for EC21, EC25, BG96 and EG95 to match vendor specific
> serial functions only, to prevent binding to class functions. Require
> 2 endpoints on ff/ff/ff functions, avoiding the 3 endpoint QMI/RMNET
> network functions.
>
> Cc: AceLan Kao <acelan.kao@canonical.com>
> Cc: Sebastian Sjoholm <ssjoholm@mac.com>
> Cc: Dan Williams <dcbw@redhat.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Thanks, Bjørn. Now applied.
Johan
prev parent reply other threads:[~2020-08-31 6:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-29 13:42 [PATCH] USB: serial: option: support dynamic Quectel USB compositions Bjørn Mork
2020-08-29 21:59 ` Sasha Levin
2020-08-31 6:44 ` Johan Hovold [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200831064452.GO21288@localhost \
--to=johan@kernel.org \
--cc=acelan.kao@canonical.com \
--cc=bjorn@mork.no \
--cc=dcbw@redhat.com \
--cc=linux-usb@vger.kernel.org \
--cc=ssjoholm@mac.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).