netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).