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

From	Takashi Iwai <tiwai@suse.de>
Newsgroups	linux.kernel
Subject	Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
Date	2015-08-29 09:20 +0200
Message-ID	<q2IAG-3ek-9@gated-at.bofh.it> (permalink)
References	(7 earlier) <q1DWq-8lX-11@gated-at.bofh.it> <q1Nj4-4Uz-7@gated-at.bofh.it> <q1THP-5rs-11@gated-at.bofh.it> <q2CYh-3wH-1@gated-at.bofh.it> <q2FCN-7rY-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Sat, 29 Aug 2015 06:09:01 +0200,
Ming Lei wrote:
> 
> On Sat, Aug 29, 2015 at 9:11 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> > On Thu, Aug 27, 2015 at 08:55:13AM +0800, Ming Lei wrote:
> >> On Thu, Aug 27, 2015 at 2:07 AM, Linus Torvalds
> >> <torvalds@linux-foundation.org> wrote:
> >> > On Wed, Aug 26, 2015 at 1:06 AM, Liam Girdwood
> >> > <liam.r.girdwood@linux.intel.com> wrote:
> >> >>
> >> >> I think the options are to either :-
> >> >>
> >> >> 1) Don not support audio DSP drivers using topology data as built-in
> >> >> drivers. Audio is not really a critical system required for booting
> >> >> anyway.
> >> >
> >> > Yes, forcing it to be a module and not letting people compile it in by
> >> > mistake (and then not have it work) is an option.
> >> >
> >> > That said, there are situations where people don't want to use
> >> > modules. I used to eschew them for security reasons, for example - now
> >> > I instead just do a one-time temporary key. But others may have other
> >> > reasons to try to avoid modules.
> >> >
> >> >> 2) Create a default PCM for every driver that has topology data on the
> >> >> assumption that every sound card will at least 1 PCM. This PCM can then
> >> >> be re-configured when the FW is loaded.
> >> >
> >> > That would seem to be the better option if it is reasonably implementable.
> >> >
> >> > Of course, some kind of timer-based retry (limited *somehow*) of the
> >> > fw loading could work too, but smells really really hacky.
> >>
> >> Yeah, years ago, we discussed to use -EPROBE_DEFER for the situation,
> >> which should be one kind of fix, but looks there were objections at that time.
> >
> > That would still be a hack. I'll note there is also asynchronous probe support
> > now but to use that would also be a hack for this issue. We don't want to
> 
> If we think firmware as one kind of resources like regulators, gpio and others,
> PROBE_DEFER is one good match for firmware loading case, and
> it has been used by lots of drivers, so why can't it be used for
> firmware loading?
> 
> One problem is that we need to convert drivers into returning -EPROBE_DEFER
> in case of request failure, and that may involve some work, but which
> should be mechanical.

I find such a delaying mechanism not so bad, too.  It's very
straightforward, at least, no big pain in the transition in the driver
side.

> > encourage folks to go down that road.  They'd be hacks for this issue as you
> > are simply delaying the driver probe for a later time and there is no guarantee
> > that any pivot_root() might have already been completed later to ensure your
> > driver's fw file is present. So it may work or it may not.
> 
> We can trigger defer probe explicitly once root fs is setup or other condition
> is met.

Right, how to trigger the reprobe (and relevant optimization) needs to
be considered on top of the current mechanism.


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

Thread

csiph-web