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@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
