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

[Felix Fietkau]

On 2015-05-15 09:02, Arend van Spriel wrote:
> 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?
Here's some context on this issue:
At boot time, a script looks for cfg80211 interfaces and creates a
default config. This needs to happen before the uci-defaults scripts
run, as they are allowed to make changes to the default config of wifi
interfaces.
As far as I know, there is no way for a script or utility to block until
all device probing actions have been completed.
We don't have a fancy per-wifi-device defaults override, and we don't
have any hotplug based config modifications yet (this might also lead to
some interesting race conditions), so we currently rely on core devices
having been probed after kernel modules are loaded.

- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel