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 [off-list ref] wrote:

On 01/14/2012 01:59 PM, Arend van Spriel wrote:

quoted

On 01/14/2012 07:20 PM, Larry Finger wrote:

quoted

On 01/14/2012 11:58 AM, John W. Linville wrote:

quoted

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.

quoted

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