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  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:	Sat, 14 Jan 2012 22:15:19 +0200
From:	Emmanuel Grumbach <>
To:	Larry Finger <>
Cc:	Arend van Spriel <>,
	"John W. Linville" <>,
	Kay Sievers <>,
	"" <>,
	"" <>,
	Tom Gundersen <>,
	Andy Whitcroft <>,
	Johannes Berg <>
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 <> 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

> 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
More majordomo info at

Powered by blists - more mailing lists