linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Drivers that use synchronous firmware loading
@ 2012-01-29  3:39 Larry Finger
  2012-01-29 17:35 ` Kalle Valo
  0 siblings, 1 reply; 4+ messages in thread
From: Larry Finger @ 2012-01-29  3:39 UTC (permalink / raw)
  To: wireless

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Drivers that use synchronous firmware loading
  2012-01-29  3:39 Drivers that use synchronous firmware loading Larry Finger
@ 2012-01-29 17:35 ` Kalle Valo
  2012-01-29 18:00   ` Larry Finger
  0 siblings, 1 reply; 4+ messages in thread
From: Kalle Valo @ 2012-01-29 17:35 UTC (permalink / raw)
  To: Larry Finger; +Cc: wireless

Larry Finger <Larry.Finger@lwfinger.net> 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Drivers that use synchronous firmware loading
  2012-01-29 17:35 ` Kalle Valo
@ 2012-01-29 18:00   ` Larry Finger
  2012-01-30  7:01     ` Luciano Coelho
  0 siblings, 1 reply; 4+ messages in thread
From: Larry Finger @ 2012-01-29 18:00 UTC (permalink / raw)
  To: Kalle Valo; +Cc: wireless

On 01/29/2012 11:35 AM, Kalle Valo wrote:
> Larry Finger<Larry.Finger@lwfinger.net>  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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Drivers that use synchronous firmware loading
  2012-01-29 18:00   ` Larry Finger
@ 2012-01-30  7:01     ` Luciano Coelho
  0 siblings, 0 replies; 4+ messages in thread
From: Luciano Coelho @ 2012-01-30  7:01 UTC (permalink / raw)
  To: Larry Finger; +Cc: Kalle Valo, wireless

On Sun, 2012-01-29 at 12:00 -0600, Larry Finger wrote: 
> On 01/29/2012 11:35 AM, Kalle Valo wrote:
> > Larry Finger<Larry.Finger@lwfinger.net>  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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-01-30  7:01 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-29  3:39 Drivers that use synchronous firmware loading Larry Finger
2012-01-29 17:35 ` Kalle Valo
2012-01-29 18:00   ` Larry Finger
2012-01-30  7:01     ` Luciano Coelho

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).