From: Takashi Iwai <tiwai@suse.de>
To: Ming Lei <ming.lei@canonical.com>
Cc: "Luis R. Rodriguez" <mcgrof@suse.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>,
"Jie, Yang" <yang.jie@intel.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
"joonas.lahtinen@linux.intel.com"
<joonas.lahtinen@linux.intel.com>, Tom Gundersen <teg@jklm.no>,
Al Viro <viro@zeniv.linux.org.uk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kay Sievers <kay@vrfy.org>, David Woodhouse <dwmw2@infradead.org>,
Luis Rodriguez <mcgrof@do-not-panic.com>,
lkml <linux-kernel@vger.kernel.org>,
yalin wang <yalin.wang2010@gmail.com>
Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
Date: Sat, 29 Aug 2015 09:11:27 +0200 [thread overview]
Message-ID: <s5hzj1algbk.wl-tiwai@suse.de> (raw)
In-Reply-To: <CACVXFVMp88FtcC0vGr802aG9p7bG3S2Gm0ZAKKkcikCK6ygPeQ@mail.gmail.com>
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
next prev parent reply other threads:[~2015-08-29 7:11 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1440449403.2469.35.camel@loki>
[not found] ` <1440489900.2419.4.camel@loki>
[not found] ` <rbhuamrc6ajy3l1qereb60l8.1440494220682@email.android.com>
2015-08-25 19:34 ` Problems loading firmware using built-in drivers with kernels that use initramfs Luis R. Rodriguez
2015-08-25 19:46 ` Takashi Iwai
2015-08-25 19:58 ` Dmitry Torokhov
2015-08-25 20:26 ` Linus Torvalds
2015-08-26 5:30 ` yalin wang
2015-08-26 5:12 ` Jie, Yang
2015-08-26 5:32 ` Takashi Iwai
2015-08-26 6:17 ` Jie, Yang
2015-08-26 8:06 ` Liam Girdwood
2015-08-26 8:29 ` Jie, Yang
2015-08-26 9:00 ` Liam Girdwood
2015-08-27 1:50 ` Lin, Mengdong
2015-08-27 7:09 ` Liam Girdwood
2015-08-26 18:07 ` Linus Torvalds
2015-08-27 0:55 ` Ming Lei
2015-08-29 1:11 ` Luis R. Rodriguez
2015-08-29 4:09 ` Ming Lei
2015-08-29 7:11 ` Takashi Iwai [this message]
2015-08-29 8:50 ` Arend van Spriel
2015-08-29 10:38 ` Ming Lei
2015-08-30 8:25 ` Arend van Spriel
2015-08-30 18:11 ` Linus Torvalds
2015-12-17 19:24 ` Luis R. Rodriguez
2015-08-31 14:21 ` Ming Lei
2015-09-02 1:19 ` Luis R. Rodriguez
2015-09-02 12:09 ` Arend van Spriel
2015-09-02 12:13 ` Arend van Spriel
2015-09-02 18:58 ` Luis R. Rodriguez
2015-09-02 21:03 ` Arend van Spriel
2015-09-02 23:13 ` Dmitry Torokhov
2015-09-02 23:22 ` Luis R. Rodriguez
2015-09-02 23:29 ` Dmitry Torokhov
2015-09-02 23:46 ` Luis R. Rodriguez
2015-09-03 17:23 ` Arend van Spriel
2015-09-03 17:33 ` Dmitry Torokhov
2015-10-16 19:35 ` Luis R. Rodriguez
2015-10-16 21:05 ` Luis R. Rodriguez
2015-10-17 8:31 ` Arend van Spriel
2015-09-02 20:43 ` Dmitry Torokhov
2015-09-02 0:39 ` Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hzj1algbk.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=dmitry.torokhov@gmail.com \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kay@vrfy.org \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@do-not-panic.com \
--cc=mcgrof@suse.com \
--cc=ming.lei@canonical.com \
--cc=teg@jklm.no \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=yalin.wang2010@gmail.com \
--cc=yang.jie@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).