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

[Jie, Yang]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@xxxxxxx]
> Sent: Wednesday, August 26, 2015 1:33 PM
> To: Jie, Yang
> Cc: Dmitry Torokhov; Luis R. Rodriguez; Girdwood, Liam R;
> joonas.lahtinen@xxxxxxxxxxxxxxx; Tom Gundersen; Ming Lei; Al Viro; Greg
> Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis
> Rodriguez; lkml
> Subject: Re: Problems loading firmware using built-in drivers with kernels
> that use initramfs.
> 
> On Wed, 26 Aug 2015 07:12:46 +0200,
> Jie, Yang wrote:
> >
> > > -----Original Message-----
> > > From: Dmitry Torokhov [mailto:dmitry.torokhov@xxxxxxxxx]
> > > Sent: Wednesday, August 26, 2015 3:58 AM
> > > To: Takashi Iwai
> > > Cc: Luis R. Rodriguez; Girdwood, Liam R; Jie, Yang;
> > > joonas.lahtinen@xxxxxxxxxxxxxxx; Tom Gundersen; Ming Lei; Al Viro;
> > > Greg Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse;
> > > Luis Rodriguez; lkml
> > > Subject: Re: Problems loading firmware using built-in drivers with
> > > kernels that use initramfs.
> > >
> > > On Tue, Aug 25, 2015 at 12:46 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> > > > On Tue, 25 Aug 2015 21:34:08 +0200, Luis R. Rodriguez wrote:
> > > >>
> > > >> On Tue, Aug 25, 2015 at 10:17:00AM +0100, David Woodhouse wrote:
> > > >> > Luis, did you tell me the other day that you made the kernel
> > > >> > get firmware directly from the file system? This regression
> > > >> > would be yours
> > > then?
> > > >>
> > > >> I didn't implement that, Linus did in 2012 (see commit
> > > >> abb139e75c2c titled
> > > >> "firmware: teach the kernel to load firmware files directly from
> > > >> the filesystem"). But we used to fallback to a userspace helper
> > > >> when the fw was not present and then Takashi made this optional
> > > >> via commit 7b1269f778782d titled "firmware: Make user-mode helper
> optional".
> > > >> Takashi noted in the Kconfig "The user-mode helper is no longer
> > > >> required unless you have a special firmware file that resides in
> > > >> a non-standard path". It was not clarified why that's true
> > > >> though, or what you'd need to do to ensure that the fw would be
> > > >> available. It would be good for us to elaborate on that.
> > > >
> > > > The recent udev already dropped the firmware loading feature.
> > >
> > > Note that even when we had udev helper to load the firmware it was
> > > not always reliable depending on the exact point where we requested
> firmware.
> > > If request happened in probe() path before we mounted root fs then
> > > we'd never get it loaded because we'd be waiting for devices settle
> > > before mounting rootfs.
> >
> > For request in probe(), is it possible to use
> > request_firmware_nowait() to wait rootfs mounted or timeout in another
> thread?
> >
> > It looks usermodehelper_disabled is 0(at probe()) at this case then no
> > waiting occurs here in our testing.
> 
> It's possible -- and even with the normal request_firmware(), in theory.  The
> missing piece is that you need to inform the helper to retry the f/w loading.
> Currently the direct f/w loader assumes that the file is there and returns
> error if not present.
> 
> If we implement a retry, another question is how to trigger it, i.e. how the
> helper can know when a fs is mounted a new file is present.
 
Got it, thanks Takashi and all.

So looks we should(and already done for most audio firmware) implement it 
as Dmitry and Linus proposed, that is to make sure request_firmware() calls
are not in driver's probe() paths.

Yalin help posted sample code for this implementation(to request firmware
in device node open) and actually I also did similar for Broadwell ADSP driver
and will send out later, thank you all.

Thanks,
~Keyon

> 
> 
> Takashi
--
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/