lists.openwall.net   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  linux-hardening  linux-cve-announce  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]
Message-ID: <87r3tyb08f.fsf@nemi.mork.no>
Date:	Tue, 10 Feb 2015 10:10:40 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	Aleksander Morgado <aleksander@...ksander.es>
Cc:	David Miller <davem@...hat.com>,
	Kristian Evensen <kristian.evensen@...il.com>,
	"netdev\@vger.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists