From: Johan Hovold <johan@kernel.org>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: Dan Williams <dcbw@redhat.com>, Lars Melin <larsm17@gmail.com>,
Kristian Evensen <kristian.evensen@gmail.com>,
Johan Hovold <johan@kernel.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: option: Improve Quectel EP06 detection
Date: Thu, 13 Sep 2018 11:17:53 +0200 [thread overview]
Message-ID: <20180913091753.GA3443@localhost> (raw)
On Wed, Sep 12, 2018 at 10:34:43PM +0200, Bjørn Mork wrote:
> Dan Williams <dcbw@redhat.com> writes:
>
> > The fact that the firmware implementation has the ability to change the
> > endpoints is unrelated to Kristian's case, and that alone is
> > justification for this to be quirked in the driver. People other than
> > Kristian will undoubtedly use the functionality, on platforms less
> > limited.
>
> FWIW, I agree with Dan and Kristian on this. It's a documented feature,
> and it will be used. The reasons are irrelevant. The firmware
> implementation is inconvenient, but we should still strive to make it
> Just Work in Linux. Kristian's solution does that.
>
> > Also most Huawei modems have the ability to change their layout and
> > configuration just like the EP06 via the U2DIAG and SETPORT commands.
>
> Yes, but they are nice enough to use unique class/subclass/protocol
> triplets for their functions so it's easy to support the changing
> layout. At least as long as they use their own VID and not some laptop
> vendor's..
>
> The Sierra Wireless strategy, using fixed interface numbers leaving
> "holes" is another fine solution to the problem. Or they could have
> allocated unique VIDs per function combination, as long as the number of
> valid combinations are low. But they didn't. It's not like it's the
> first bad firmware design we've had to deal with. Let's just work
> around it, like we always do. No need to make life difficult for end
> users just because Quectel makes life difficult for us.
Ok, thanks for everyone for your input. As Lars I was sceptical about
this, but if this is contained to Quectel and we have a solutions which
hopefully covers all permutations for their other devices, let's go
along with this.
I'd prefer seeing this contained in the device-id table as far as
possible rather than maintaining a second table of product ids in
probe() so I've cooked up a patch (on top of this one) adding a new
device-id match flag.
Kristian would you mind giving it a try?
Oh, also note that I dropped the RSVD(5) for the ADB interface in your
patch since it uses a different subclass anyway. I'll submit both
patches in a series.
Thanks,
Johan
next reply other threads:[~2018-09-13 9:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-13 9:17 Johan Hovold [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-09-14 8:42 option: Improve Quectel EP06 detection Johan Hovold
2018-09-14 7:53 Kristian Evensen
2018-09-14 7:51 Johan Hovold
2018-09-13 15:13 Kristian Evensen
2018-09-13 9:44 Kristian Evensen
2018-09-12 20:34 Bjørn Mork
2018-09-12 19:18 Dan Williams
2018-09-12 18:25 Lars Melin
2018-09-12 16:57 Kristian Evensen
2018-09-12 16:32 Lars Melin
2018-09-11 14:34 Kristian Evensen
2018-09-11 14:00 Lars Melin
2018-09-10 14:43 Dan Williams
2018-09-10 11:39 Kristian Evensen
2018-09-10 10:30 Johan Hovold
2018-09-08 12:57 Kristian Evensen
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=20180913091753.GA3443@localhost \
--to=johan@kernel.org \
--cc=bjorn@mork.no \
--cc=dcbw@redhat.com \
--cc=kristian.evensen@gmail.com \
--cc=larsm17@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@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).