[OpenWrt-Devel] [PATCH] Give WiFi modules more time to settle

Arend van Spriel arend at broadcom.com
Fri May 15 03:02:16 EDT 2015

On 05/12/15 12:25, Hante Meuleman wrote:
> It is a bit more than just changing request_firmware_nowait into
> request_firmware. The worker in core.c needs to be removed. The
> function brcmf_pcie_setup needs to be updated as it cannot call
> device_release_driver during probe. As a result
> brcmf_fw_get_firmwares_pcie has to return the error, which means
> the api for brcmf_fw_get_firmwares_pcie will change, that will
> mean usb and sdio needs to patched as well. So it isn't going to be
> a small patch, but it can be done. I just wonder if it is worth the effort.
> The patch needs to be maintained as well.

I think it kinda sucks that a driver is restricted to use a kernel API 
because of some user-space app behaviour. So can we dive a bit deeper 
into that. Is the app detecting the wiphy instances dynamically (through 
/sys/class/ieee80211?) or does it have some expectation of the number of 
available wiphy instances. On the first run with OpenWRT it probably can 
not have such expectation so is that what we are trying to deal with here?


> -----Original Message-----
> From: Felix Fietkau [mailto:nbd at openwrt.org]
> On 2015-05-12 11:33, Hante Meuleman wrote:
>> Understood, what is wifi detect using as input? Do the netdevs have to
>> be up? Where is the information that wifi app is reading coming from?
> It looks for registered cfg80211 wiphys. It does not care about netdevs.
>> brcmfmac uses different method for firmware loading. It is not as
>> easily patched as the ath10k driver. But I would like to know exactly
>> what wifi detect uses as input. As in case of brcmfmac I expect that
>> firmware loading will not be the only asynchronous "problem".
> It should be enough to rework the request_firmware_nowait calls into
> request_firmware calls.
>> What would be easy is adding a delay of 2 seconds to the function
>> brcmfmac_module_init in core.c, but that won't guarantee it will work.
> Still seems more fragile and hackish.
> - Felix
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list