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

From: Arend van Spriel
Date: Sat Aug 29 2015 - 04:50:47 EST

On 08/29/2015 09:11 AM, Takashi Iwai wrote:
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@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

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

Not sure how this is going to work with request_firmware_nowait(). We use that in our drivers to get rid of ~60 sec. delay in probe and consequently boot time when built-in. So basically we return 0 on probe lacking better knowledge. Guess we can always move back to request_firmware calls when defer_probe support is available.


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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at