lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 10 Feb 2015 10:10:40 +0100
From:	Bjørn Mork <>
To:	Aleksander Morgado <>
Cc:	David Miller <>,
	Kristian Evensen <>,
	"netdev\" <>
Subject: Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

Aleksander Morgado <> writes:
> On Tue, Feb 10, 2015 at 9:43 AM, Aleksander Morgado
> <> wrote:
>> On Tue, Feb 10, 2015 at 8:49 AM, Bjørn Mork <> 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.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists