netdev - Re: calling request_firmware() from module init will not work with recent/future udev versions

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: <CANUX_P2OGvazES0pGA+RnfWnHNJ6+0Rre9j0SOav_7idHNM-2A@mail.gmail.com>
Date:	Sat, 14 Jan 2012 22:15:19 +0200
From:	Emmanuel Grumbach <egrumbach@...il.com>
To:	Larry Finger <Larry.Finger@...inger.net>
Cc:	Arend van Spriel <arend@...adcom.com>,
	"John W. Linville" <linville@...driver.com>,
	Kay Sievers <kay.sievers@...y.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	Tom Gundersen <teg@...m.no>,
	Andy Whitcroft <apw@...onical.com>,
	Johannes Berg <johannes@...solutions.net>
Subject: Re: calling request_firmware() from module init will not work with
 recent/future udev versions

On Sat, Jan 14, 2012 at 22:13, Larry Finger <Larry.Finger@...inger.net> wrote:
> On 01/14/2012 01:59 PM, Arend van Spriel wrote:
>>
>> On 01/14/2012 07:20 PM, Larry Finger wrote:
>>>
>>> On 01/14/2012 11:58 AM, John W. Linville wrote:
>>>>
>>>> Kay, thanks for the reports.  Drivers should definitely be loading
>>>> firmware at IFF_UP time.
>>>
>>>
>>> As the maintainer for several drivers with this problem, I need to make
>>> some
>>> changes. What call from mac80211 corresponds to IFF_UP?
>>
>>
>> Hi, Larry
>>
>> The mac80211 start callback describes following:
>>
>>  * @start: Called before the first netdevice attached to the hardware
>>  *     is enabled. This should turn on the hardware and must turn on
>>  *     frame reception (for possibly enabled monitor interfaces.)
>>  *     Returns negative error codes, these may be seen in userspace,
>>  *     or zero.
>>  *     When the device is started it should not have a MAC address
>>  *     to avoid acknowledging frames before a non-monitor device
>>  *     is added.
>>  *     Must be implemented and can sleep.
>>
>> Seems to me a good place to do the firmware loading although it is not
>> really IFF_UP.
>>
>>> I have looked into using asynchronous firmware loading, but I have not
>>> yet found
>>> a good implementation.
>>>
>>> Larry
>>
>>
>> In brcmsmac we request the firmware in the probe function so not in
>> module_init, but I guess upon driver registration in the module_init the
>> probe is called.
>
>

I looked once at the pci_register_driver, and if I remember well, the
probe in called in the same context of pci_register_driver. The driver
registration fires a bus enumeration.
FWIW, drivers might need to fetch their fw before registering
mac80211. This can happen if they need their fw to know their
capabilities...

>
> The rtlwifi drivers also load the firmware in the probe function, but do so
> synchronously, which is where they get in trouble with the new udev.
>
> I'm planning on converting to asynchronous firmware loading with a check in
> the start routine.
>

so does iwlwifi
--
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