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

[Luis R. Rodriguez]

On Sat, Aug 29, 2015 at 12:09:01PM +0800, Ming Lei wrote:
> On Sat, Aug 29, 2015 at 9:11 AM, Luis R. Rodriguez <mcgrof@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> wrote:
> >> > On Wed, Aug 26, 2015 at 1:06 AM, Liam Girdwood
> >> > <liam.r.girdwood@xxxxxxxxxxxxxxx> 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?

I'm glad you asked, it begs the question if we could have done something better
for these other components. In short its a matter of if we have an interface
that would let devices coming up ask: are my requirements available yet? Reason
we kick -EPROBE_DEFER is we can't answer this as we have no way to map some
of these requirements pricely so -EPROBE_DEFER is the best we can do at times.

It doesn't mean we shouldn't think harder, and for firmware I think we can and
should try harder to answer these questions.

I'm arguing that its a viable solution to use -EPROBE_DEFER but I don't think
its the best we can do but also I worry about the lack of semantics that would
be implied by user if they start doing this all over. In terms of semantics
I'd want at least some undestanding by the caller over certain guarantees of
what we are going to try to do for them by using -EPROBE_DEFER.

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

And there may be cases where the fs might already be available, so it would
be pointless to retry if the error was true. To me that's a bit sloppy, and
part of the sloppiness comes from the lack of clear semantics. Its why we are
having this discussion. Its also not the first of its case and its why I'm kind
of trying to be a bit pedantic. I would prefer to avoid just a bandaid.

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

Now we're talking, that's the sort of line of solution I'd much prefer, but again
that's building on top of a use case that I think we should try to avoid. I think
the strategy is sound but not the way we're deferring probe. I think that's prone
to error and the solution lacks clarity.

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