On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov
On Wed, Sep 2, 2015 at 4:22 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
On Wed, Sep 02, 2015 at 04:13:51PM -0700, Dmitry Torokhov wrote:
On Wed, Sep 2, 2015 at 2:03 PM, Arend van Spriel <arend@xxxxxxxxxxxx> wrote:
Ok. So some background why we need it in brcm80211 drivers. So as a wireless
network device driver the answer we got when asking for an event to load
firware is upon IF_UP for a registered net device. Because we try to do
things smart we query the firmware running on the device for capabilities
before we can register the net device hence we request the firmware during
probe. This may be specific to wireless drivers (Intel has same approach if
not mistaken) but I suspect there may be more.
We have the same issue with input devices: before we can register one
we need to set their capabilities and to know their capabilities we
quite often need to load their firmware/config and query the device.
Should Arend's driver use async probe then?
What has async probe have to do with anything? We will still be
waiting for async probes to finish before we mount rootfs so it will
not change absolutely anything.
:) Right, its what I was alluding to as well.
IMHO its just as hacky as using -EPROBE_DEFER too, but its at least
preemptively hacky. Sadly I can't think of clear and clever way for the kernel
to know when firmware will be ready either... Would userspace know? Should the
kernel learn this from userspace ?
Yes. Given only userspace knows when firmware is available (I could
have it on a separate device and mount it at some time). So maybe
userpsace should simply try and scan busses for unbound devices and
tell them to re-probe when it decides that firmware is finally
OK, the folks wanting this mechanism can implement it then. Short of
that we only have hacks.