Date:	Wed, 2 Sep 2015 03:19:12 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Ming Lei <ming.lei@...onical.com>
Cc:	Arend van Spriel <arend@...adcom.com>,
	Takashi Iwai <tiwai@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
	"Jie, Yang" <yang.jie@...el.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"joonas.lahtinen@...ux.intel.com" <joonas.lahtinen@...ux.intel.com>,
	Tom Gundersen <teg@...m.no>, Al Viro <viro@...iv.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kay Sievers <kay@...y.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Luis Rodriguez <mcgrof@...not-panic.com>,
	lkml <linux-kernel@...r.kernel.org>,
	yalin wang <yalin.wang2010@...il.com>
Subject: Re: Problems loading firmware using built-in drivers with kernels
 that use initramfs.

On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote:
> On Sun, Aug 30, 2015 at 4:25 PM, Arend van Spriel <arend@...adcom.com> wrote:
> > Does this mean a built-in driver can not get firmware from initramfs or
> > built in the kernel early. Seems a bit too aggressive. The problem stated in
> > this thread is when the firmware is not on initramfs but only on the rootfs.
> 
> Yes, strictly speaking, user mode request can't be handled with defer probe
> during booting because we don't know how the user helper handles the
> request,

FWIW I have a strategy in mind to help us compartamentalize the user mode
helper only to the dell-rbu driver, and as such phase out that code eventually
completely. Its part of the goals I have with the extensible firmware API I've
been proposing.

> that said even checking if the firmware exists in current path doesn't
> make sense for user mode request.
> 
> So the patch should have used defer proble for direct load only
> during booting.

What exact guarantees would we be giving to callers if they follow up on probe
with -EDEFER_PROBE ? I'd much prefer to try to avoid such uses in init / probe
(note that unless you're using async probe since we batch both so it doesn't really
matter where you place your code) all together and then for the few remaining
stragglers understand the requirements and provide an interface that lets them
claim their requirements and try to meets them.

A grammatical hunt for drivers who call fw API on init / probe can be
completed, although I know the hunt needs a bit more fine tuning it surely can
be completed. If we don't have many callers the compexity added for only a
few callers with rather loose criteria seems rather unnecessary, specially if
we can change the drivers and make these driver sthe exception rather than
a norm.

Then as for drivers *needing* the fw at probe why not have a proper interface
that does guarantee they get the requirements they ask for first ? For instance
a new probe type specified by the driver could enable the core to wait for say
an event and then tirgger a probe, kind of how we ended up defining the async
probe type preference:

static struct some_bus_driver some_driver = {                                  
        .probe = some_probe,                                              
        .id_table = some_id,                                              
        .driver = {                                                             
                .name = DEVICE_NAME,                                            
                .pm = &some_pm_ops,                                       
                .probe_type = PROBE_PREFER_POST_FOO,
        },                                                                      
}; 

Then we just don't try just hoping for completion but rather can do something
about the criteria passed.

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

Powered by blists - more mailing lists