On 15 May 2015 at 09:02, Arend van Spriel <ar...@broadcom.com> 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.
I agree. > 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? I pointed you to the responsible files. 1) /etc/init.d/boot http://git.openwrt.org/?p=openwrt.git;a=blob;f=package/base-files/files/etc/init.d/boot;hb=HEAD As you already noticed, it calls "wifi detect" 2) /sbin/wifi http://git.openwrt.org/?p=openwrt.git;a=blob;f=package/base-files/files/sbin/wifi;hb=HEAD It calls driver specific (e.g. mac80211 which is really a cfg80211) function to detect wifi. 3) /lib/wifi/mac80211.sh http://git.openwrt.org/?p=openwrt.git;a=blob;f=package/kernel/mac80211/files/lib/wifi/mac80211.sh;hb=HEAD It implements detect_mac80211 which uses /sys/class/ieee80211/ and generates wifi config _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
