To all wireless developers:
As you may have noticed, the udev layer is being changed. One of the side
effects is that the kernel may timeout when a driver uses synchronous firmware
loading. My rtlwifi drivers were affected, and a kernel bugzilla has been logged
against rtl8192se. I suggest that the maintainers should be proactive, and
convert to asynchronous loading as soon as possible.
In wireless-testing, the files listed below contain calls to read_firmware()
rather than read_firmware_nowait():
drivers/net/wireless/at76c50x-usb.c
drivers/net/wireless/ath/ath6kl/init.c
drivers/net/wireless/ath/ath9k/hif_usb.c
drivers/net/wireless/atmel.c
drivers/net/wireless/b43/main.c
drivers/net/wireless/b43legacy/main.c
drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
drivers/net/wireless/ipw2x00/ipw2100.c
drivers/net/wireless/iwlegacy/3945-mac.c
drivers/net/wireless/iwlegacy/4965-mac.c
drivers/net/wireless/iwlwifi/iwl-agn.c
drivers/net/wireless/libertas/main.c
drivers/net/wireless/libertas/if_usb.c
drivers/net/wireless/libertas_tf/if_usb.c
drivers/net/wireless/mwifiex/main.c
drivers/net/wireless/mwl8k.c
drivers/net/wireless/orinoco/fw.c
drivers/net/wireless/orinoco/orinoco_usb.c
drivers/net/wireless/p54/p54spi.c
drivers/net/wireless/p54/p54usb.c
drivers/net/wireless/p54/p54pci.c
drivers/net/wireless/prism54/islpci_dev.c
drivers/net/wireless/rt2x00/rt2x00firmware.c
drivers/net/wireless/wl1251/main.c
drivers/net/wireless/zd1201.c
drivers/net/wireless/zd1211rw/zd_usb.c
Some of the drivers above may be exempt as their firmware is built into the
kernel. I did not check for that case.
When your driver loads only a single firmware file, the procedure is relatively
easy. I copied the flow used in iwlagn. In the firmware callback routine, the
kernel has loaded a copy of the firmware file. All you need to do is copy that
info into the driver's cached version of the firmware and free the kernel's
copy. Once the firmware is loaded, then start mac80211 with the
ieee80211_register_hw() call.
One additional step is to create a completion queue entry, that is initialized
in the probe routine. Once the firmware callback routine is entered, then you
call the complete() routine for that queue, and check for completion before the
driver is unloaded. This way, the case where the driver is unloaded while a
callback is pending is prevented.
I am currently working on b43legacy, which loads 4 different firmware files.
Using only a single callback routine is proving to be a little difficult, but I
hope to find a way to handle this case as well. Once I have b43legacy solved,
b43 will be easy.
Thanks,
Larry
On 01/29/2012 11:35 AM, Kalle Valo wrote:
> Larry Finger<[email protected]> writes:
>
>> To all wireless developers:
>>
>> As you may have noticed, the udev layer is being changed. One of the
>> side effects is that the kernel may timeout when a driver uses
>> synchronous firmware loading. My rtlwifi drivers were affected, and a
>> kernel bugzilla has been logged against rtl8192se. I suggest that the
>> maintainers should be proactive, and convert to asynchronous loading
>> as soon as possible.
>
> Thanks for the summary, this was really useful.
>
>> In wireless-testing, the files listed below contain calls to
>> read_firmware() rather than read_firmware_nowait():
>>
>> drivers/net/wireless/at76c50x-usb.c
>> drivers/net/wireless/ath/ath6kl/init.c
>> drivers/net/wireless/ath/ath9k/hif_usb.c
>> drivers/net/wireless/atmel.c
>> drivers/net/wireless/b43/main.c
>> drivers/net/wireless/b43legacy/main.c
>> drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
>> drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
>> drivers/net/wireless/ipw2x00/ipw2100.c
>> drivers/net/wireless/iwlegacy/3945-mac.c
>> drivers/net/wireless/iwlegacy/4965-mac.c
>> drivers/net/wireless/iwlwifi/iwl-agn.c
>> drivers/net/wireless/libertas/main.c
>> drivers/net/wireless/libertas/if_usb.c
>> drivers/net/wireless/libertas_tf/if_usb.c
>> drivers/net/wireless/mwifiex/main.c
>> drivers/net/wireless/mwl8k.c
>> drivers/net/wireless/orinoco/fw.c
>> drivers/net/wireless/orinoco/orinoco_usb.c
>> drivers/net/wireless/p54/p54spi.c
>> drivers/net/wireless/p54/p54usb.c
>> drivers/net/wireless/p54/p54pci.c
>> drivers/net/wireless/prism54/islpci_dev.c
>> drivers/net/wireless/rt2x00/rt2x00firmware.c
>> drivers/net/wireless/wl1251/main.c
>> drivers/net/wireless/zd1201.c
>> drivers/net/wireless/zd1211rw/zd_usb.c
>>
>> Some of the drivers above may be exempt as their firmware is built
>> into the kernel. I did not check for that case.
>
> But isn't the issue only when a firmware is requested synchronously
> during module init? For example, IIRC wl1251 loads the module during
> hw start and that should be safe, even when making a synchronous call.
> Or did I misunderstood something?
As I understand the situation, if userland is running when the firmware is
requested synchronously, then the request should be OK. Certainly, when firmware
loading is triggered from the probe routine, it will cause trouble.
I was just contacted this morning about problems with r8712u on Arch Linux.
Another driver for me to fix.
Larry
On Sun, 2012-01-29 at 12:00 -0600, Larry Finger wrote:
> On 01/29/2012 11:35 AM, Kalle Valo wrote:
> > Larry Finger<[email protected]> writes:
> >
> >> To all wireless developers:
> >>
> >> As you may have noticed, the udev layer is being changed. One of the
> >> side effects is that the kernel may timeout when a driver uses
> >> synchronous firmware loading. My rtlwifi drivers were affected, and a
> >> kernel bugzilla has been logged against rtl8192se. I suggest that the
> >> maintainers should be proactive, and convert to asynchronous loading
> >> as soon as possible.
> >
> > Thanks for the summary, this was really useful.
> >
> >> In wireless-testing, the files listed below contain calls to
> >> read_firmware() rather than read_firmware_nowait():
> >>
> >> drivers/net/wireless/at76c50x-usb.c
> >> drivers/net/wireless/ath/ath6kl/init.c
> >> drivers/net/wireless/ath/ath9k/hif_usb.c
> >> drivers/net/wireless/atmel.c
> >> drivers/net/wireless/b43/main.c
> >> drivers/net/wireless/b43legacy/main.c
> >> drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
> >> drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
> >> drivers/net/wireless/ipw2x00/ipw2100.c
> >> drivers/net/wireless/iwlegacy/3945-mac.c
> >> drivers/net/wireless/iwlegacy/4965-mac.c
> >> drivers/net/wireless/iwlwifi/iwl-agn.c
> >> drivers/net/wireless/libertas/main.c
> >> drivers/net/wireless/libertas/if_usb.c
> >> drivers/net/wireless/libertas_tf/if_usb.c
> >> drivers/net/wireless/mwifiex/main.c
> >> drivers/net/wireless/mwl8k.c
> >> drivers/net/wireless/orinoco/fw.c
> >> drivers/net/wireless/orinoco/orinoco_usb.c
> >> drivers/net/wireless/p54/p54spi.c
> >> drivers/net/wireless/p54/p54usb.c
> >> drivers/net/wireless/p54/p54pci.c
> >> drivers/net/wireless/prism54/islpci_dev.c
> >> drivers/net/wireless/rt2x00/rt2x00firmware.c
> >> drivers/net/wireless/wl1251/main.c
> >> drivers/net/wireless/zd1201.c
> >> drivers/net/wireless/zd1211rw/zd_usb.c
> >>
> >> Some of the drivers above may be exempt as their firmware is built
> >> into the kernel. I did not check for that case.
> >
> > But isn't the issue only when a firmware is requested synchronously
> > during module init? For example, IIRC wl1251 loads the module during
> > hw start and that should be safe, even when making a synchronous call.
> > Or did I misunderstood something?
>
> As I understand the situation, if userland is running when the firmware is
> requested synchronously, then the request should be OK. Certainly, when firmware
> loading is triggered from the probe routine, it will cause trouble.
>
> I was just contacted this morning about problems with r8712u on Arch Linux.
> Another driver for me to fix.
I echo Kalle's thanks for this summary.
As Kalle said, I think wl1251 is fine. It doesn't request any firmware
during the probe path, only when the interface is brought up.
In wl12xx, though, we have a problem. We request the *firmware* also
when the interface is brought up, but we get the "NVS file" (which
contains the MAC address) during probe. That must be fixed and is in my
TODO list.
--
Cheers,
Luca.
Larry Finger <[email protected]> writes:
> To all wireless developers:
>
> As you may have noticed, the udev layer is being changed. One of the
> side effects is that the kernel may timeout when a driver uses
> synchronous firmware loading. My rtlwifi drivers were affected, and a
> kernel bugzilla has been logged against rtl8192se. I suggest that the
> maintainers should be proactive, and convert to asynchronous loading
> as soon as possible.
Thanks for the summary, this was really useful.
> In wireless-testing, the files listed below contain calls to
> read_firmware() rather than read_firmware_nowait():
>
> drivers/net/wireless/at76c50x-usb.c
> drivers/net/wireless/ath/ath6kl/init.c
> drivers/net/wireless/ath/ath9k/hif_usb.c
> drivers/net/wireless/atmel.c
> drivers/net/wireless/b43/main.c
> drivers/net/wireless/b43legacy/main.c
> drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
> drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
> drivers/net/wireless/ipw2x00/ipw2100.c
> drivers/net/wireless/iwlegacy/3945-mac.c
> drivers/net/wireless/iwlegacy/4965-mac.c
> drivers/net/wireless/iwlwifi/iwl-agn.c
> drivers/net/wireless/libertas/main.c
> drivers/net/wireless/libertas/if_usb.c
> drivers/net/wireless/libertas_tf/if_usb.c
> drivers/net/wireless/mwifiex/main.c
> drivers/net/wireless/mwl8k.c
> drivers/net/wireless/orinoco/fw.c
> drivers/net/wireless/orinoco/orinoco_usb.c
> drivers/net/wireless/p54/p54spi.c
> drivers/net/wireless/p54/p54usb.c
> drivers/net/wireless/p54/p54pci.c
> drivers/net/wireless/prism54/islpci_dev.c
> drivers/net/wireless/rt2x00/rt2x00firmware.c
> drivers/net/wireless/wl1251/main.c
> drivers/net/wireless/zd1201.c
> drivers/net/wireless/zd1211rw/zd_usb.c
>
> Some of the drivers above may be exempt as their firmware is built
> into the kernel. I did not check for that case.
But isn't the issue only when a firmware is requested synchronously
during module init? For example, IIRC wl1251 loads the module during
hw start and that should be safe, even when making a synchronous call.
Or did I misunderstood something?
--
Kalle Valo