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

[Arend van Spriel]

On 05/15/15 21:28, Felix Fietkau wrote:
> 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.

Hi Felix,

Thanks for the explanation. Although it goes a bit further as you rely 
on the wiphy being registered during the probe and I suspect the probe 
should be done in PID=0 context, right? This is also not true for 
brcmfmac which schedules a work during module init and the work does the 
driver registration.

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