netdev - Re: [PATCH net] net: qmi_wwan: fix Gobi device probing

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: <87y5neidk1.fsf@nemi.mork.no>
Date:	Sat, 23 Jun 2012 11:26:54 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, linux-usb@...r.kernel.org,
	H.Siebmanns@...nline.de
Subject: Re: [PATCH net] net: qmi_wwan: fix Gobi device probing

David Miller <davem@...emloft.net> writes:

> From: Bjørn Mork <bjorn@...k.no>
> Date: Thu, 21 Jun 2012 14:45:58 +0200
>
>> Ignoring interfaces with additional descriptors is not a reliable
>> method for locating the correct interface on Gobi devices.  There
>> is at least one device where this method fails:
>> https://bbs.archlinux.org/viewtopic.php?id=143506
>> 
>> The result is that the AT command port (interface #2) is hidden
>> from qcserial, preventing traditional serial modem usage:
>  ...
>> Use static interface numbers taken from the interface map in
>> qcserial for all Gobi devices instead:
>  ...
>> This should be more reliable over all, and will also prevent the
>> noisy "probe failed" messages.  The whitelisting logic is expected
>> to be replaced by direct interface number matching in 3.6.
>> 
>> Reported-by: Heinrich Siebmanns (Harvey) <H.Siebmanns@...nline.de>
>> Cc: <stable@...r.kernel.org> # v3.4: 0000188 USB: qmi_wwan: Make forced int 4 whitelist generic
>> Cc: <stable@...r.kernel.org> # v3.4: f7142e6 USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
>> Cc: <stable@...r.kernel.org> # v3.4
>> Signed-off-by: Bjørn Mork <bjorn@...k.no>
>
> Applied.

Thanks.

Note that this patch will conflict with the qmi_wwan changes already in
net-next.  I can prepare a minimal forward port if you like.

But I would really prefer to rewrite it completely for 3.6 instead,
taking advantage of the USB interface number matching in usb-next.  That
will allow us to get rid of the ugly whitelisting logic and just match
directly on the USB interface number instead.  Would that be OK?  It
will depend on 

 81df2d5 USB: allow match on bInterfaceNumber
 fec1868 USB: properly pad out usb_device_id.driver_info

from usb-next, so those must go into net-next before this is possible.
Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
an option?

I can of course also do the basic forward port now and then fix it up
later during the 3.6 cycle if you prefer that.



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