netdev - Re: [PATCH v2] Add Qualcomm Gobi 2000 driver.

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]

Date:	Fri, 8 Oct 2010 19:03:10 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	David Miller <davem@...emloft.net>
Cc:	ellyjones@...gle.com, netdev@...r.kernel.org, jglasgow@...gle.com,
	msb@...gle.com, olofj@...gle.com
Subject: Re: [PATCH v2] Add Qualcomm Gobi 2000 driver.

On Fri, Oct 08, 2010 at 10:28:03AM -0700, David Miller wrote:

> I've looked at the gobi_loader code and it's simpler than many
> of the gigabit ethernet driver firmware loader sequences in
> the tree already.
> 
> Requiring udev et al. magic only makes this networking device
> that much harder to use from an initrd.
> 
> I understand how this might be a bit clumsy since we'd need to make a
> dependency on the serial device since that is the mechanism by which
> the firmware is uploaded, but really I'd like you to consider it
> seriously.

The device is capable of functioning in either UMTS or CDMA modes, and 
requires different firmware for each. Further, there's separate firmware 
images per carrier due to regulatory differences. To make things even 
more complicated, there's no consistency in the naming of the firmware 
(and we can't fix that, because the firmware is undistributable). The 
only way to do this in-kernel would seem to be to have a module 
parameter to pass a firmware name, which really doesn't seem elegant.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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