From: "Bjørn Mork" <bjorn@mork.no>
To: Aleksander Morgado <aleksander@aleksander.es>
Cc: David Miller <davem@redhat.com>,
Kristian Evensen <kristian.evensen@gmail.com>,
"netdev\@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI
Date: Tue, 10 Feb 2015 10:10:40 +0100 [thread overview]
Message-ID: <87r3tyb08f.fsf@nemi.mork.no> (raw)
In-Reply-To: <CAAP7ucJo3CMwAZqkJ8jPHZgP0Sdh5_twdgPRu87p69nPXmGMpw@mail.gmail.com> (Aleksander Morgado's message of "Tue, 10 Feb 2015 09:51:31 +0100")
Aleksander Morgado <aleksander@aleksander.es> writes:
> On Tue, Feb 10, 2015 at 9:43 AM, Aleksander Morgado
> <aleksander@aleksander.es> wrote:
>> On Tue, Feb 10, 2015 at 8:49 AM, Bjørn Mork <bjorn@mork.no> wrote:
>>
>>> I am hoping to get a second opinion from Aleksander.
>>
>> I have a MC7304 and a MC7354 and both work with interfaces #8 and #10,
>> the only difference being that #10 ends up being raw-ip by default
>> instead of 802.3. I previously had old firmware in both, from early
>> last year IIRC, but last week I upgraded both to the latest firmware
>> available.
>>
>> The only case in which I've seen such a modem (a MC7304) with 1 single
>> valid QMI interface (actually being #8) is when the modem is put in
>> "single-qmi" interface mode, which you can do forcing it to get the
>> MC7710 PID, e.g. AT!UDPID=68A2. But otherwise, if the modem was
>> exposed as 0x68c0, if#10 always worked for me...
>
>
> BTW, regarding the patch... if interface #10 ends up being usable only
> in some 73xx models, I would still leave it available anyway in the
> kernel driver. Userspace can always figure out whether the interface
> is usable or not (e.g. MM does some QMI probing on the interface
> before flagging it as usable).
Yes, agreed. Thanks for the testing. Sorry Kristian, but if interface #10
is usable on some modems with this device ID, then the driver should
support those modems.
So this is a NAK on the patch.
> A similar issue we had with if#11 IIRC, which the sierra driver marked
> it as being QMI but we never made it work once, so we ended up
> removing it from qmi_wwan (see commit fc0d6e9cd0a). Now I wonder if we
> should have done that only by testing it once with my hw.
Yes, it would be nice if you could revisit that just to be 103% sure.
I believe the driver will bind to any unbound QMI interfaces if you add
the device ID using the "new_id" sysfs file, so it should be testable
without rebuilding the kernel. At least on newer kernels, where the
dynamic USB ids override the built-in ones.
But contrary to the interface #10 situation, we have no indications that
#11 has ever worked for anyone.
Bjørn
next prev parent reply other threads:[~2015-02-10 9:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-09 10:17 [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI Kristian Evensen
2015-02-09 11:51 ` Bjørn Mork
2015-02-09 11:55 ` Kristian Evensen
2015-02-09 12:26 ` Kristian Evensen
2015-02-09 13:33 ` Bjørn Mork
2015-02-09 14:30 ` Kristian Evensen
2015-02-09 22:19 ` David Miller
2015-02-10 6:04 ` Kristian Evensen
2015-02-10 7:49 ` Bjørn Mork
2015-02-10 8:43 ` Aleksander Morgado
2015-02-10 8:51 ` Aleksander Morgado
2015-02-10 9:10 ` Bjørn Mork [this message]
2015-02-10 9:19 ` Kristian Evensen
2015-02-10 9:18 ` Kristian Evensen
2015-02-10 10:37 ` Aleksander Morgado
2015-02-10 10:53 ` Kristian Evensen
2015-02-10 11:39 ` Bjørn Mork
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=87r3tyb08f.fsf@nemi.mork.no \
--to=bjorn@mork.no \
--cc=aleksander@aleksander.es \
--cc=davem@redhat.com \
--cc=kristian.evensen@gmail.com \
--cc=netdev@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).