Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

[Arend van Spriel]

On 09/03/2015 01:46 AM, Luis R. Rodriguez wrote:
> On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov
> <dmitry.torokhov@xxxxxxxxx> wrote:
> > 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.

Indeed. However, upon module_init we schedule a worker in which the 
driver are registered. We do that to make sure the probe is not done 
within module_init context. That could now be done with async probe. 
This is not the problem discussed here so let's not spend more time on this.

> > > 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.

So what does "userspace knows when firmware is available" mean here. The 
specific firmware file the driver wants or the collection of firmware 
files which may or may not have the specific firmware file the driver 
wants. I assume the latter and re-probe will fail as expected.

Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/