Groups > linux.kernel > #1213275 > unrolled thread

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

Started by	"Luis R. Rodriguez" <mcgrof@suse.com>
First post	2015-08-25 21:40 +0200
Last post	2015-09-02 02:40 +0200
Articles	20 on this page of 36 — 10 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Page 1 of 2 [1] 2 Next page →

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

From	"Luis R. Rodriguez" <mcgrof@suse.com>
Date	2015-08-25 21:40 +0200
Subject	Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
Message-ID	<q1seC-7G4-3@gated-at.bofh.it>

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.

More on this below.

> I can also take a look next week when I'm home from vacation.

No worries, I'll look at it.

> From:Liam Girdwood <liam.r.girdwood@intel.com>
> Sent:Tue, 25 Aug 2015 09:05:00 +0100
> To:"Jie, Yang" <yang.jie@intel.com>,dwmw2@infradead.org,"joonas.lahtinen	" <joonas.lahtinen@linux.intel.com>
> Subject:Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
> 
> >On Mon, 2015-08-24 at 21:50 +0100, Liam Girdwood wrote:
> >> Currently firmware loading with built-in drivers is failing on systems
> >> that mount an initramfs before the root FS is mounted (that contains the
> >> firmware file). Modular drivers work fine.
> >> 
> >> Keyon (Jie, Yang) has done some testing with the Intel audio DSP driver
> >> and found that the built-in firmware loading only works if the firmware
> >> is included as part of the initramfs.

Note that works.

> >> The same has been seen with other
> >> Intel drivers that use firmware.
> >> 
> >> In this case it looks like userspace (udevd ?) is checking initramfs for
> >> pending firmware requests and returning not found if it cant find the
> >> files, but it's not re-checking for any pending firmware requests once
> >> the real FS is mounted. Is it possible to have udevd re-check the
> >> pending firmware requests after the real FS is mounted ?

We are phasing out CONFIG_FW_LOADER_USER_HELPER support in the kernel, support
for udev helper firmware loading was removed from systemd, the only requirement
for it now is the dell rbu driver.

Without CONFIG_FW_LOADER_USER_HELPER it its up to userspace or system
integrators to do the right thing and you have a few options if you are
enabling drivers as built-in:

  * stuff firmware in initramfs
  * built firmware into the kernel

We don't do anything special for pivot_root for built-in, I am not sure if
we should, I don't think we should... can you not do any of the above
two options?

Since folks can stuff firmware into initramfs and that's outside the scope of
how we build the kernel we can't always ensure folks will do one of the above
two options at build time for built-in drivers. If we don't want to do
something for pivot_root the only thing I think we can do is document the
expecations clearly, unless there are other ideas of course.

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

[toc] | [next] | [standalone]

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

From	Takashi Iwai <tiwai@suse.de>
Date	2015-08-25 21:50 +0200
Subject	Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
Message-ID	<q1soh-7Tn-7@gated-at.bofh.it>
In reply to	#1213275

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.


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/

[toc] | [prev] | [next] | [standalone]

#1213287

From	Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date	2015-08-25 22:00 +0200
Message-ID	<q1sxZ-870-23@gated-at.bofh.it>
In reply to	#1213277

On Tue, Aug 25, 2015 at 12:46 PM, Takashi Iwai <tiwai@suse.de> 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.

Either build firmware in the kernel or ramdisk (so it is always
available), or make sure request_firmware() calls are not in driver's
probe() paths.

Thanks.

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

[toc] | [prev] | [next] | [standalone]

#1213317

From	Linus Torvalds <torvalds@linux-foundation.org>
Date	2015-08-25 22:30 +0200
Message-ID	<q1t10-vU-29@gated-at.bofh.it>
In reply to	#1213287

On Tue, Aug 25, 2015 at 12:58 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Either build firmware in the kernel or ramdisk (so it is always
> available), or make sure request_firmware() calls are not in driver's
> probe() paths.

The correct answer is almost always that second one.

Drivers that load firmware in their probe parts are generally doign
things wrong.

It's very occasionally the right thing to do - there are a few pieces
of hardware where just about _everything_ about the device is in the
firmware, and you simply can't even problem them before that, because
you don't know what they *are* before the firmware has been loaded.
The extreme case of that might be something like the base hardware
being an FPGA that has a USB interface, but before the FPGA has been
loaded, it basically has no identity. So there are probably valid
cases in theory for loading firmware at probe time, but pretty much
every single case I've ever actually seen, the probe knows what the
actual hardware is from some identifiable piece, and the actual
firmware loading should be delayed until the piece of hardware is
actually opened.

So the "load firmware in probe routine" happens, and we shouldn't
disallow it, but it should be considered a "last resort" kind of
thing.

In general, things like sound drivers should *not* need to have their
firmware in the initrd, even if you build them into the kernel. A disk
driver? Yes. Maybe the root filesystem is on that disk, and you need
the firmware for the disk driver to load it. But a sound device?
Please just make sure that you load the firmware as late as possible.

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

[toc] | [prev] | [next] | [standalone]

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

From	yalin wang <yalin.wang2010@gmail.com>
Date	2015-08-26 07:40 +0200
Subject	Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
Message-ID	<q1BBf-4SM-3@gated-at.bofh.it>
In reply to	#1213317

> On Aug 26, 2015, at 04:26, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> On Tue, Aug 25, 2015 at 12:58 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> 
>> Either build firmware in the kernel or ramdisk (so it is always
>> available), or make sure request_firmware() calls are not in driver's
>> probe() paths.
> 
> The correct answer is almost always that second one.
> 
> Drivers that load firmware in their probe parts are generally doign
> things wrong.
> 
> It's very occasionally the right thing to do - there are a few pieces
> of hardware where just about _everything_ about the device is in the
> firmware, and you simply can't even problem them before that, because
> you don't know what they *are* before the firmware has been loaded.
> The extreme case of that might be something like the base hardware
> being an FPGA that has a USB interface, but before the FPGA has been
> loaded, it basically has no identity. So there are probably valid
> cases in theory for loading firmware at probe time, but pretty much
> every single case I've ever actually seen, the probe knows what the
> actual hardware is from some identifiable piece, and the actual
> firmware loading should be delayed until the piece of hardware is
> actually opened.
> 
> So the "load firmware in probe routine" happens, and we shouldn't
> disallow it, but it should be considered a "last resort" kind of
> thing.
> 
> In general, things like sound drivers should *not* need to have their
> firmware in the initrd, even if you build them into the kernel. A disk
> driver? Yes. Maybe the root filesystem is on that disk, and you need
> the firmware for the disk driver to load it. But a sound device?
> Please just make sure that you load the firmware as late as possible.
> 
i remember lots of drivers load their firmware when some user space process
open the device node, that is to say, they load the firmware in 
->open() function, at this time , you can make sure the real filesystem is ready in
most time.  

i think your dsp firmware can also do like this.
you can refer to msm gnu driver:

static void load_gpu(struct drm_device *dev)
{
	static DEFINE_MUTEX(init_lock);
	struct msm_drm_private *priv = dev->dev_private;

	mutex_lock(&init_lock);

	if (!priv->gpu)
		priv->gpu = adreno_load_gpu(dev);

	mutex_unlock(&init_lock);
}

static int msm_open(struct drm_device *dev, struct drm_file *file)
{
	struct msm_file_private *ctx;

	/* For now, load gpu on open.. to avoid the requirement of having
	 * firmware in the initrd.
	 */
	load_gpu(dev);

	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
	if (!ctx)
		return -ENOMEM;

	file->driver_priv = ctx;

	return 0;
}
it load the firmware in open() function.

Thanks











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

[toc] | [prev] | [next] | [standalone]

#1213543

From	"Jie, Yang" <yang.jie@intel.com>
Date	2015-08-26 07:20 +0200
Message-ID	<q1BhU-4vP-9@gated-at.bofh.it>
In reply to	#1213287

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEbWl0cnkgVG9yb2tob3YgW21h
aWx0bzpkbWl0cnkudG9yb2tob3ZAZ21haWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3Vz
dCAyNiwgMjAxNSAzOjU4IEFNDQo+IFRvOiBUYWthc2hpIEl3YWkNCj4gQ2M6IEx1aXMgUi4gUm9k
cmlndWV6OyBHaXJkd29vZCwgTGlhbSBSOyBKaWUsIFlhbmc7DQo+IGpvb25hcy5sYWh0aW5lbkBs
aW51eC5pbnRlbC5jb207IFRvbSBHdW5kZXJzZW47IE1pbmcgTGVpOyBBbCBWaXJvOyBHcmVnDQo+
IEtyb2FoLUhhcnRtYW47IEtheSBTaWV2ZXJzOyBMaW51cyBUb3J2YWxkczsgRGF2aWQgV29vZGhv
dXNlOyBMdWlzDQo+IFJvZHJpZ3VlejsgbGttbA0KPiBTdWJqZWN0OiBSZTogUHJvYmxlbXMgbG9h
ZGluZyBmaXJtd2FyZSB1c2luZyBidWlsdC1pbiBkcml2ZXJzIHdpdGgga2VybmVscw0KPiB0aGF0
IHVzZSBpbml0cmFtZnMuDQo+IA0KPiBPbiBUdWUsIEF1ZyAyNSwgMjAxNSBhdCAxMjo0NiBQTSwg
VGFrYXNoaSBJd2FpIDx0aXdhaUBzdXNlLmRlPiB3cm90ZToNCj4gPiBPbiBUdWUsIDI1IEF1ZyAy
MDE1IDIxOjM0OjA4ICswMjAwLA0KPiA+IEx1aXMgUi4gUm9kcmlndWV6IHdyb3RlOg0KPiA+Pg0K
PiA+PiBPbiBUdWUsIEF1ZyAyNSwgMjAxNSBhdCAxMDoxNzowMEFNICswMTAwLCBEYXZpZCBXb29k
aG91c2Ugd3JvdGU6DQo+ID4+ID4gTHVpcywgZGlkIHlvdSB0ZWxsIG1lIHRoZSBvdGhlciBkYXkg
dGhhdCB5b3UgbWFkZSB0aGUga2VybmVsIGdldA0KPiA+PiA+IGZpcm13YXJlIGRpcmVjdGx5IGZy
b20gdGhlIGZpbGUgc3lzdGVtPyBUaGlzIHJlZ3Jlc3Npb24gd291bGQgYmUgeW91cnMNCj4gdGhl
bj8NCj4gPj4NCj4gPj4gSSBkaWRuJ3QgaW1wbGVtZW50IHRoYXQsIExpbnVzIGRpZCBpbiAyMDEy
IChzZWUgY29tbWl0IGFiYjEzOWU3NWMyYw0KPiA+PiB0aXRsZWQNCj4gPj4gImZpcm13YXJlOiB0
ZWFjaCB0aGUga2VybmVsIHRvIGxvYWQgZmlybXdhcmUgZmlsZXMgZGlyZWN0bHkgZnJvbSB0aGUN
Cj4gPj4gZmlsZXN5c3RlbSIpLiBCdXQgd2UgdXNlZCB0byBmYWxsYmFjayB0byBhIHVzZXJzcGFj
ZSBoZWxwZXIgd2hlbiB0aGUNCj4gPj4gZncgd2FzIG5vdCBwcmVzZW50IGFuZCB0aGVuIFRha2Fz
aGkgbWFkZSB0aGlzIG9wdGlvbmFsIHZpYSBjb21taXQNCj4gPj4gN2IxMjY5Zjc3ODc4MmQgdGl0
bGVkICJmaXJtd2FyZTogTWFrZSB1c2VyLW1vZGUgaGVscGVyIG9wdGlvbmFsIi4NCj4gPj4gVGFr
YXNoaSBub3RlZCBpbiB0aGUgS2NvbmZpZyAiVGhlIHVzZXItbW9kZSBoZWxwZXIgaXMgbm8gbG9u
Z2VyDQo+ID4+IHJlcXVpcmVkIHVubGVzcyB5b3UgaGF2ZSBhIHNwZWNpYWwgZmlybXdhcmUgZmls
ZSB0aGF0IHJlc2lkZXMgaW4gYQ0KPiA+PiBub24tc3RhbmRhcmQgcGF0aCIuIEl0IHdhcyBub3Qg
Y2xhcmlmaWVkIHdoeSB0aGF0J3MgdHJ1ZSB0aG91Z2gsIG9yDQo+ID4+IHdoYXQgeW91J2QgbmVl
ZCB0byBkbyB0byBlbnN1cmUgdGhhdCB0aGUgZncgd291bGQgYmUgYXZhaWxhYmxlLiBJdA0KPiA+
PiB3b3VsZCBiZSBnb29kIGZvciB1cyB0byBlbGFib3JhdGUgb24gdGhhdC4NCj4gPg0KPiA+IFRo
ZSByZWNlbnQgdWRldiBhbHJlYWR5IGRyb3BwZWQgdGhlIGZpcm13YXJlIGxvYWRpbmcgZmVhdHVy
ZS4NCj4gDQo+IE5vdGUgdGhhdCBldmVuIHdoZW4gd2UgaGFkIHVkZXYgaGVscGVyIHRvIGxvYWQg
dGhlIGZpcm13YXJlIGl0IHdhcyBub3QNCj4gYWx3YXlzIHJlbGlhYmxlIGRlcGVuZGluZyBvbiB0
aGUgZXhhY3QgcG9pbnQgd2hlcmUgd2UgcmVxdWVzdGVkIGZpcm13YXJlLg0KPiBJZiByZXF1ZXN0
IGhhcHBlbmVkIGluIHByb2JlKCkgcGF0aCBiZWZvcmUgd2UgbW91bnRlZCByb290IGZzIHRoZW4g
d2UnZA0KPiBuZXZlciBnZXQgaXQgbG9hZGVkIGJlY2F1c2Ugd2UnZCBiZSB3YWl0aW5nIGZvciBk
ZXZpY2VzIHNldHRsZSBiZWZvcmUNCj4gbW91bnRpbmcgcm9vdGZzLg0KDQpGb3IgcmVxdWVzdCBp
biBwcm9iZSgpLCBpcyBpdCBwb3NzaWJsZSB0byB1c2UgcmVxdWVzdF9maXJtd2FyZV9ub3dhaXQo
KSB0bw0Kd2FpdCByb290ZnMgbW91bnRlZCBvciB0aW1lb3V0IGluIGFub3RoZXIgdGhyZWFkPw0K
DQpJdCBsb29rcyB1c2VybW9kZWhlbHBlcl9kaXNhYmxlZCBpcyAwKGF0IHByb2JlKCkpIGF0IHRo
aXMgY2FzZSB0aGVuIG5vIHdhaXRpbmcgb2NjdXJzDQpoZXJlIGluIG91ciB0ZXN0aW5nLg0KDQpU
aGFua3MsDQp+S2V5b24NCg0KPiANCj4gRWl0aGVyIGJ1aWxkIGZpcm13YXJlIGluIHRoZSBrZXJu
ZWwgb3IgcmFtZGlzayAoc28gaXQgaXMgYWx3YXlzIGF2YWlsYWJsZSksIG9yDQo+IG1ha2Ugc3Vy
ZSByZXF1ZXN0X2Zpcm13YXJlKCkgY2FsbHMgYXJlIG5vdCBpbiBkcml2ZXIncw0KPiBwcm9iZSgp
IHBhdGhzLg0KPiANCj4gVGhhbmtzLg0KPiANCj4gLS0NCj4gRG1pdHJ5DQo=
--
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/

[toc] | [prev] | [next] | [standalone]

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

From	Takashi Iwai <tiwai@suse.de>
Date	2015-08-26 07:40 +0200
Subject	Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
Message-ID	<q1BBg-4SM-11@gated-at.bofh.it>
In reply to	#1213543

On Wed, 26 Aug 2015 07:12:46 +0200,
Jie, Yang wrote:
> 
> > -----Original Message-----
> > From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> > Sent: Wednesday, August 26, 2015 3:58 AM
> > To: Takashi Iwai
> > Cc: Luis R. Rodriguez; Girdwood, Liam R; Jie, Yang;
> > joonas.lahtinen@linux.intel.com; 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@suse.de> 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.


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/

[toc] | [prev] | [next] | [standalone]

#1213567

From	"Jie, Yang" <yang.jie@intel.com>
Date	2015-08-26 08:20 +0200
Message-ID	<q1CdY-5RD-9@gated-at.bofh.it>
In reply to	#1213547

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Wednesday, August 26, 2015 1:33 PM
> To: Jie, Yang
> Cc: Dmitry Torokhov; Luis R. Rodriguez; Girdwood, Liam R;
> joonas.lahtinen@linux.intel.com; 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@gmail.com]
> > > Sent: Wednesday, August 26, 2015 3:58 AM
> > > To: Takashi Iwai
> > > Cc: Luis R. Rodriguez; Girdwood, Liam R; Jie, Yang;
> > > joonas.lahtinen@linux.intel.com; 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@suse.de> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1213642

From	Liam Girdwood <liam.r.girdwood@linux.intel.com>
Date	2015-08-26 10:10 +0200
Message-ID	<q1DWq-8lX-11@gated-at.bofh.it>
In reply to	#1213567

On Wed, 2015-08-26 at 07:17 +0100, Jie, Yang wrote:
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de]
> > Sent: Wednesday, August 26, 2015 1:33 PM
> > To: Jie, Yang
> > Cc: Dmitry Torokhov; Luis R. Rodriguez; Girdwood, Liam R;
> > joonas.lahtinen@linux.intel.com; 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@gmail.com]
> > > > Sent: Wednesday, August 26, 2015 3:58 AM
> > > > To: Takashi Iwai
> > > > Cc: Luis R. Rodriguez; Girdwood, Liam R; Jie, Yang;
> > > > joonas.lahtinen@linux.intel.com; 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@suse.de> 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.

Keyon, we have a similar situation to that of the FPGA example that
Linus described when the DSP driver uses topology data. i.e. the audio
driver will have no PCM devices that can be opened (to initiate the FW
loading) until after the FW is loaded. The topology data is part of the
FW and contains the PCMs, kcontrols, graphs etc. i.e. a PCM device is
created for every PCM description found in the FW topology data. 

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.

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. 

Liam


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

[toc] | [prev] | [next] | [standalone]

#1213669

From	"Jie, Yang" <yang.jie@intel.com>
Date	2015-08-26 10:40 +0200
Message-ID	<q1Eps-s9-5@gated-at.bofh.it>
In reply to	#1213642

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMaWFtIEdpcmR3b29kIFttYWls
dG86bGlhbS5yLmdpcmR3b29kQGxpbnV4LmludGVsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBB
dWd1c3QgMjYsIDIwMTUgNDowNyBQTQ0KPiBUbzogSmllLCBZYW5nDQo+IENjOiBUYWthc2hpIEl3
YWk7IERtaXRyeSBUb3Jva2hvdjsgTHVpcyBSLiBSb2RyaWd1ZXo7DQo+IGpvb25hcy5sYWh0aW5l
bkBsaW51eC5pbnRlbC5jb207IFRvbSBHdW5kZXJzZW47IE1pbmcgTGVpOyBBbCBWaXJvOyBHcmVn
DQo+IEtyb2FoLUhhcnRtYW47IEtheSBTaWV2ZXJzOyBMaW51cyBUb3J2YWxkczsgRGF2aWQgV29v
ZGhvdXNlOyBMdWlzDQo+IFJvZHJpZ3VlejsgbGttbDsgeWFsaW4gd2FuZw0KPiBTdWJqZWN0OiBS
ZTogUHJvYmxlbXMgbG9hZGluZyBmaXJtd2FyZSB1c2luZyBidWlsdC1pbiBkcml2ZXJzIHdpdGgg
a2VybmVscw0KPiB0aGF0IHVzZSBpbml0cmFtZnMuDQo+IA0KPiBPbiBXZWQsIDIwMTUtMDgtMjYg
YXQgMDc6MTcgKzAxMDAsIEppZSwgWWFuZyB3cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBUYWthc2hpIEl3YWkgW21haWx0bzp0aXdhaUBzdXNlLmRl
XQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjYsIDIwMTUgMTozMyBQTQ0KPiA+ID4g
VG86IEppZSwgWWFuZw0KPiA+ID4gQ2M6IERtaXRyeSBUb3Jva2hvdjsgTHVpcyBSLiBSb2RyaWd1
ZXo7IEdpcmR3b29kLCBMaWFtIFI7DQo+ID4gPiBqb29uYXMubGFodGluZW5AbGludXguaW50ZWwu
Y29tOyBUb20gR3VuZGVyc2VuOyBNaW5nIExlaTsgQWwgVmlybzsNCj4gPiA+IEdyZWcgS3JvYWgt
SGFydG1hbjsgS2F5IFNpZXZlcnM7IExpbnVzIFRvcnZhbGRzOyBEYXZpZCBXb29kaG91c2U7DQo+
ID4gPiBMdWlzIFJvZHJpZ3VlejsgbGttbA0KPiA+ID4gU3ViamVjdDogUmU6IFByb2JsZW1zIGxv
YWRpbmcgZmlybXdhcmUgdXNpbmcgYnVpbHQtaW4gZHJpdmVycyB3aXRoDQo+ID4gPiBrZXJuZWxz
IHRoYXQgdXNlIGluaXRyYW1mcy4NCj4gPiA+DQo+ID4gPiBJdCdzIHBvc3NpYmxlIC0tIGFuZCBl
dmVuIHdpdGggdGhlIG5vcm1hbCByZXF1ZXN0X2Zpcm13YXJlKCksIGluDQo+ID4gPiB0aGVvcnku
ICBUaGUgbWlzc2luZyBwaWVjZSBpcyB0aGF0IHlvdSBuZWVkIHRvIGluZm9ybSB0aGUgaGVscGVy
IHRvIHJldHJ5DQo+IHRoZSBmL3cgbG9hZGluZy4NCj4gPiA+IEN1cnJlbnRseSB0aGUgZGlyZWN0
IGYvdyBsb2FkZXIgYXNzdW1lcyB0aGF0IHRoZSBmaWxlIGlzIHRoZXJlIGFuZA0KPiA+ID4gcmV0
dXJucyBlcnJvciBpZiBub3QgcHJlc2VudC4NCj4gPiA+DQo+ID4gPiBJZiB3ZSBpbXBsZW1lbnQg
YSByZXRyeSwgYW5vdGhlciBxdWVzdGlvbiBpcyBob3cgdG8gdHJpZ2dlciBpdCwgaS5lLg0KPiA+
ID4gaG93IHRoZSBoZWxwZXIgY2FuIGtub3cgd2hlbiBhIGZzIGlzIG1vdW50ZWQgYSBuZXcgZmls
ZSBpcyBwcmVzZW50Lg0KPiA+DQo+ID4gR290IGl0LCB0aGFua3MgVGFrYXNoaSBhbmQgYWxsLg0K
PiA+DQo+ID4gU28gbG9va3Mgd2Ugc2hvdWxkKGFuZCBhbHJlYWR5IGRvbmUgZm9yIG1vc3QgYXVk
aW8gZmlybXdhcmUpIGltcGxlbWVudA0KPiA+IGl0IGFzIERtaXRyeSBhbmQgTGludXMgcHJvcG9z
ZWQsIHRoYXQgaXMgdG8gbWFrZSBzdXJlDQo+ID4gcmVxdWVzdF9maXJtd2FyZSgpIGNhbGxzIGFy
ZSBub3QgaW4gZHJpdmVyJ3MgcHJvYmUoKSBwYXRocy4NCj4gPg0KPiA+IFlhbGluIGhlbHAgcG9z
dGVkIHNhbXBsZSBjb2RlIGZvciB0aGlzIGltcGxlbWVudGF0aW9uKHRvIHJlcXVlc3QNCj4gPiBm
aXJtd2FyZSBpbiBkZXZpY2Ugbm9kZSBvcGVuKSBhbmQgYWN0dWFsbHkgSSBhbHNvIGRpZCBzaW1p
bGFyIGZvcg0KPiA+IEJyb2Fkd2VsbCBBRFNQIGRyaXZlciBhbmQgd2lsbCBzZW5kIG91dCBsYXRl
ciwgdGhhbmsgeW91IGFsbC4NCj4gDQo+IEtleW9uLCB3ZSBoYXZlIGEgc2ltaWxhciBzaXR1YXRp
b24gdG8gdGhhdCBvZiB0aGUgRlBHQSBleGFtcGxlIHRoYXQgTGludXMNCj4gZGVzY3JpYmVkIHdo
ZW4gdGhlIERTUCBkcml2ZXIgdXNlcyB0b3BvbG9neSBkYXRhLiBpLmUuIHRoZSBhdWRpbyBkcml2
ZXIgd2lsbA0KPiBoYXZlIG5vIFBDTSBkZXZpY2VzIHRoYXQgY2FuIGJlIG9wZW5lZCAodG8gaW5p
dGlhdGUgdGhlIEZXDQo+IGxvYWRpbmcpIHVudGlsIGFmdGVyIHRoZSBGVyBpcyBsb2FkZWQuIFRo
ZSB0b3BvbG9neSBkYXRhIGlzIHBhcnQgb2YgdGhlIEZXIGFuZA0KPiBjb250YWlucyB0aGUgUENN
cywga2NvbnRyb2xzLCBncmFwaHMgZXRjLiBpLmUuIGEgUENNIGRldmljZSBpcyBjcmVhdGVkIGZv
cg0KPiBldmVyeSBQQ00gZGVzY3JpcHRpb24gZm91bmQgaW4gdGhlIEZXIHRvcG9sb2d5IGRhdGEu
DQo+IA0KPiBJIHRoaW5rIHRoZSBvcHRpb25zIGFyZSB0byBlaXRoZXIgOi0NCj4gDQo+IDEpIERv
biBub3Qgc3VwcG9ydCBhdWRpbyBEU1AgZHJpdmVycyB1c2luZyB0b3BvbG9neSBkYXRhIGFzIGJ1
aWx0LWluIGRyaXZlcnMuDQo+IEF1ZGlvIGlzIG5vdCByZWFsbHkgYSBjcml0aWNhbCBzeXN0ZW0g
cmVxdWlyZWQgZm9yIGJvb3RpbmcgYW55d2F5Lg0KPiANCj4gMikgQ3JlYXRlIGEgZGVmYXVsdCBQ
Q00gZm9yIGV2ZXJ5IGRyaXZlciB0aGF0IGhhcyB0b3BvbG9neSBkYXRhIG9uIHRoZQ0KPiBhc3N1
bXB0aW9uIHRoYXQgZXZlcnkgc291bmQgY2FyZCB3aWxsIGF0IGxlYXN0IDEgUENNLiBUaGlzIFBD
TSBjYW4gdGhlbiBiZQ0KPiByZS1jb25maWd1cmVkIHdoZW4gdGhlIEZXIGlzIGxvYWRlZC4NCg0K
WWVwLCB0aGlzIGNhc2UgaXMgcXVpdGUgc2ltaWxhciB3aXRoIHdoYXQgTGludXMgZGVzY3JpYmVk
Lg0KIA0KSXMgaXQgcG9zc2libGUgdGhhdCB3ZSBjYW4gcHJvYmUgcGNtIGRldmljZSBhZnRlciBm
aXJtd2FyZSBpcyBsb2FkZWQgZm9yIHRoaXMNCmNhc2U/DQoNCldoYXQgSSBhbSB0aGlua2luZyBh
Ym91dCBpcyBwb3N0cG9uaW5nIGFsbCBmaXJtd2FyZSByZWxhdGVkKGUuZy4gcGNtIHByb2Jpbmcs
DQpkbWEvZHNwL2lwYyBpbml0aWFsaXphdGlvbiwgLi4uKSBjb2RlIHRvIHRoYXQgcm9vdGZzIGlz
IHJlYWR5IGFuZCBGVyBpcyBsb2FkZWQuDQoNCn5LZXlvbg0KDQo+IA0KPiBMaWFtDQo+IA0KDQo=
--
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/

[toc] | [prev] | [next] | [standalone]

#1213680

From	Liam Girdwood <liam.r.girdwood@linux.intel.com>
Date	2015-08-26 11:10 +0200
Message-ID	<q1ESv-1fe-23@gated-at.bofh.it>
In reply to	#1213669

On Wed, 2015-08-26 at 08:29 +0000, Jie, Yang wrote:
> > -----Original Message-----
> > From: Liam Girdwood [mailto:liam.r.girdwood@linux.intel.com]

> > 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.
> > 
> > 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.
> 
> Yep, this case is quite similar with what Linus described.
>  
> Is it possible that we can probe pcm device after firmware is loaded for this
> case?
> 

The PCM devices are defined in the topology data so it is only possible
to create the PCM device *after* the firmware is loaded in these
drivers. 

Liam

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

[toc] | [prev] | [next] | [standalone]

#1214277

From	"Lin, Mengdong" <mengdong.lin@intel.com>
Date	2015-08-27 04:00 +0200
Message-ID	<q1UDU-6OO-21@gated-at.bofh.it>
In reply to	#1213680

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMaWFtIEdpcmR3b29kIFttYWls
dG86bGlhbS5yLmdpcmR3b29kQGxpbnV4LmludGVsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBB
dWd1c3QgMjYsIDIwMTUgNTowMSBQTQ0KPiBUbzogSmllLCBZYW5nDQo+IENjOiBUYWthc2hpIEl3
YWk7IERtaXRyeSBUb3Jva2hvdjsgTHVpcyBSLiBSb2RyaWd1ZXo7DQo+IGpvb25hcy5sYWh0aW5l
bkBsaW51eC5pbnRlbC5jb207IFRvbSBHdW5kZXJzZW47IE1pbmcgTGVpOyBBbCBWaXJvOyBHcmVn
DQo+IEtyb2FoLUhhcnRtYW47IEtheSBTaWV2ZXJzOyBMaW51cyBUb3J2YWxkczsgRGF2aWQgV29v
ZGhvdXNlOyBMdWlzIFJvZHJpZ3VlejsNCj4gbGttbDsgeWFsaW4gd2FuZzsgTGluLCBNZW5nZG9u
Zw0KPiBTdWJqZWN0OiBSZTogUHJvYmxlbXMgbG9hZGluZyBmaXJtd2FyZSB1c2luZyBidWlsdC1p
biBkcml2ZXJzIHdpdGgga2VybmVscyB0aGF0DQo+IHVzZSBpbml0cmFtZnMuDQo+IA0KPiBPbiBX
ZWQsIDIwMTUtMDgtMjYgYXQgMDg6MjkgKzAwMDAsIEppZSwgWWFuZyB3cm90ZToNCj4gPiA+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBMaWFtIEdpcmR3b29kIFttYWls
dG86bGlhbS5yLmdpcmR3b29kQGxpbnV4LmludGVsLmNvbV0NCj4gDQo+ID4gPiBJIHRoaW5rIHRo
ZSBvcHRpb25zIGFyZSB0byBlaXRoZXIgOi0NCj4gPiA+DQo+ID4gPiAxKSBEb24gbm90IHN1cHBv
cnQgYXVkaW8gRFNQIGRyaXZlcnMgdXNpbmcgdG9wb2xvZ3kgZGF0YSBhcyBidWlsdC1pbg0KPiBk
cml2ZXJzLg0KPiA+ID4gQXVkaW8gaXMgbm90IHJlYWxseSBhIGNyaXRpY2FsIHN5c3RlbSByZXF1
aXJlZCBmb3IgYm9vdGluZyBhbnl3YXkuDQo+ID4gPg0KPiA+ID4gMikgQ3JlYXRlIGEgZGVmYXVs
dCBQQ00gZm9yIGV2ZXJ5IGRyaXZlciB0aGF0IGhhcyB0b3BvbG9neSBkYXRhIG9uDQo+ID4gPiB0
aGUgYXNzdW1wdGlvbiB0aGF0IGV2ZXJ5IHNvdW5kIGNhcmQgd2lsbCBhdCBsZWFzdCAxIFBDTS4g
VGhpcyBQQ00NCj4gPiA+IGNhbiB0aGVuIGJlIHJlLWNvbmZpZ3VyZWQgd2hlbiB0aGUgRlcgaXMg
bG9hZGVkLg0KPiA+DQo+ID4gWWVwLCB0aGlzIGNhc2UgaXMgcXVpdGUgc2ltaWxhciB3aXRoIHdo
YXQgTGludXMgZGVzY3JpYmVkLg0KPiA+DQo+ID4gSXMgaXQgcG9zc2libGUgdGhhdCB3ZSBjYW4g
cHJvYmUgcGNtIGRldmljZSBhZnRlciBmaXJtd2FyZSBpcyBsb2FkZWQNCj4gPiBmb3IgdGhpcyBj
YXNlPw0KPiA+DQo+IA0KPiBUaGUgUENNIGRldmljZXMgYXJlIGRlZmluZWQgaW4gdGhlIHRvcG9s
b2d5IGRhdGEgc28gaXQgaXMgb25seSBwb3NzaWJsZSB0bw0KPiBjcmVhdGUgdGhlIFBDTSBkZXZp
Y2UgKmFmdGVyKiB0aGUgZmlybXdhcmUgaXMgbG9hZGVkIGluIHRoZXNlIGRyaXZlcnMuDQo+IA0K
PiBMaWFtDQoNCkl0IHNlZW1zIHRoaXMgY2FuIHByZXZlbnQgYXVkaW8gZGV2aWNlIGRyaXZlciBp
biBidWlsdC1pbiBtb2RlIHRvIHVzZSB0b3BvbG9neSBkcml2ZXJzLg0KDQpJZiB0b3BvbG9neSBp
cyBwcmVzZW50LCB0aGUgdmVuZG9yIGRyaXZlciBhbHNvIHVzZXMgcmVxdWVzdF9maXJtd2FyZSgp
IHRvIGxvYWQgdGhlIHRvcG9sb2d5IGRhdGEgZmlsZSBpbiB0aGUgcHJvYmUgcGhhc2UuIFRoZW4g
QVNvQyBjb3JlIHdpbGwgY3JlYXRlIHRoZSBzb3VuZCBjYXJkIGFuZCBpdHMgUENNIGRldmljZXMu
IA0KDQpTaGFsbCB3ZSBmb3JjZSB0aGUgZGV2aWNlIGRyaXZlcnMgdGhhdCBkZXBlbmRzIG9uIHRv
cG9sb2d5IHRvIGJlIGNvbmZpZ3VyZWQgYXMgbW9kdWxlcz8NCg0KVGhhbmtzDQpNZW5nZG9uZyAN
Cg0K
--
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/

[toc] | [prev] | [next] | [standalone]

#1214357

From	Liam Girdwood <liam.r.girdwood@linux.intel.com>
Date	2015-08-27 09:10 +0200
Message-ID	<q1ZtU-5E6-17@gated-at.bofh.it>
In reply to	#1214277

On Thu, 2015-08-27 at 01:50 +0000, Lin, Mengdong wrote:
> > -----Original Message-----
> > From: Liam Girdwood [mailto:liam.r.girdwood@linux.intel.com]
> > Sent: Wednesday, August 26, 2015 5:01 PM
> > To: Jie, Yang
> > Cc: Takashi Iwai; Dmitry Torokhov; Luis R. Rodriguez;
> > joonas.lahtinen@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg
> > Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis Rodriguez;
> > lkml; yalin wang; Lin, Mengdong
> > Subject: Re: Problems loading firmware using built-in drivers with kernels that
> > use initramfs.
> > 
> > On Wed, 2015-08-26 at 08:29 +0000, Jie, Yang wrote:
> > > > -----Original Message-----
> > > > From: Liam Girdwood [mailto:liam.r.girdwood@linux.intel.com]
> > 
> > > > 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.
> > > >
> > > > 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.
> > >
> > > Yep, this case is quite similar with what Linus described.
> > >
> > > Is it possible that we can probe pcm device after firmware is loaded
> > > for this case?
> > >
> > 
> > The PCM devices are defined in the topology data so it is only possible to
> > create the PCM device *after* the firmware is loaded in these drivers.
> > 
> > Liam
> 
> It seems this can prevent audio device driver in built-in mode to use topology drivers.
> 
> If topology is present, the vendor driver also uses request_firmware() to load the topology data file in the probe phase. Then ASoC core will create the sound card and its PCM devices. 
> 
> Shall we force the device drivers that depends on topology to be configured as modules?

Yes, this is probably the best/quickest solution for the short term
until we can implement and test option 2.

Liam

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

[toc] | [prev] | [next] | [standalone]

#1214088

From	Linus Torvalds <torvalds@linux-foundation.org>
Date	2015-08-26 20:10 +0200
Message-ID	<q1Nj4-4Uz-7@gated-at.bofh.it>
In reply to	#1213642

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.

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

[toc] | [prev] | [next] | [standalone]

#1214260

From	Ming Lei <ming.lei@canonical.com>
Date	2015-08-27 03:00 +0200
Message-ID	<q1THP-5rs-11@gated-at.bofh.it>
In reply to	#1214088

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.

thanks,
--
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/

[toc] | [prev] | [next] | [standalone]

#1215633

From	"Luis R. Rodriguez" <mcgrof@suse.com>
Date	2015-08-29 03:20 +0200
Message-ID	<q2CYh-3wH-1@gated-at.bofh.it>
In reply to	#1214260

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
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 should instead strive to be clear about expectations and requirements both
through documentation and when possible through APIs. I'll send out an RFC
which adds some grammar rules which can help us police this. I currently only
spot two drivers that require fixing.

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

[toc] | [prev] | [next] | [standalone]

#1215683

From	Ming Lei <ming.lei@canonical.com>
Date	2015-08-29 06:10 +0200
Message-ID	<q2FCN-7rY-7@gated-at.bofh.it>
In reply to	#1215633

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.

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

>
> We should instead strive to be clear about expectations and requirements both
> through documentation and when possible through APIs. I'll send out an RFC
> which adds some grammar rules which can help us police this. I currently only
> spot two drivers that require fixing.
>
>   Luis
--
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/

[toc] | [prev] | [next] | [standalone]

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

From	Takashi Iwai <tiwai@suse.de>
Date	2015-08-29 09:20 +0200
Subject	Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
Message-ID	<q2IAG-3ek-9@gated-at.bofh.it>
In reply to	#1215683

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/

[toc] | [prev] | [next] | [standalone]

#1215725

From	Arend van Spriel <arend@broadcom.com>
Date	2015-08-29 11:00 +0200
Message-ID	<q2K9s-5hS-9@gated-at.bofh.it>
In reply to	#1215719

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

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.

Regards,
Arend

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

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

[toc] | [prev] | [next] | [standalone]

#1215752

From	Ming Lei <ming.lei@canonical.com>
Date	2015-08-29 12:40 +0200
Message-ID	<q2LIe-7CJ-21@gated-at.bofh.it>
In reply to	#1215725

On Sat, 29 Aug 2015 10:50:22 +0200
Arend van Spriel <arend@broadcom.com> wrote:

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

How about the following untested draft patch?

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index be0eb46..f66912f 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -171,6 +171,12 @@ static void driver_deferred_probe_trigger(void)
 	queue_work(deferred_wq, &deferred_probe_work);
 }
 
+void driver_trigger_fw_load()
+{
+	driver_deferred_probe_trigger();
+}
+EXPORT_SYMBOL_GPL(driver_trigger_fw_load);
+
 /**
  * deferred_probe_initcall() - Enable probing of deferred devices
  *
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8524450..f879a07 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1132,6 +1132,11 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
 	if (ret <= 0) /* error or already assigned */
 		goto out;
 
+	if (system_state == SYSTEM_BOOTING) {
+		ret = -EPROBE_DEFER;
+		goto out;
+	}
+
 	ret = 0;
 	timeout = firmware_loading_timeout();
 	if (opt_flags & FW_OPT_NOWAIT) {
@@ -1311,6 +1316,9 @@ request_firmware_nowait(
 {
 	struct firmware_work *fw_work;
 
+	if (system_state == SYSTEM_BOOTING)
+		return -EPROBE_DEFER;
+
 	fw_work = kzalloc(sizeof(struct firmware_work), gfp);
 	if (!fw_work)
 		return -ENOMEM;
diff --git a/include/linux/device.h b/include/linux/device.h
index 5d7bc63..1c189fe 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -289,6 +289,7 @@ extern struct device_driver *driver_find(const char *name,
 					 struct bus_type *bus);
 extern int driver_probe_done(void);
 extern void wait_for_device_probe(void);
+extern void driver_trigger_fw_load(void);
 
 
 /* sysfs interface for exporting driver attributes */
diff --git a/init/main.c b/init/main.c
index 9e64d70..be8411b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -943,6 +943,9 @@ static int __ref kernel_init(void *unused)
 
 	flush_delayed_fput();
 
+	/* trigger probe for request_firmware and its no_wait pair */
+	driver_trigger_fw_load();
+
 	if (ramdisk_execute_command) {
 		ret = run_init_process(ramdisk_execute_command);
 		if (!ret)



Thanks,
--
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/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2 [1] 2 Next page →

csiph-web

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

Contents

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

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

#1213287

#1213317

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

#1213543

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

#1213567

#1213642

#1213669

#1213680

#1214277

#1214357

#1214088

#1214260

#1215633

#1215683

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

#1215725

#1215752