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