On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov <dmitry.torok...@gmail.com> wrote: > On Wed, Sep 2, 2015 at 4:22 PM, Luis R. Rodriguez <mcg...@suse.com> 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 <ar...@broadcom.com> 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 > available. OK, the folks wanting this mechanism can implement it then. Short of that we only have hacks. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/