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

[Arend van Spriel]

On 09/02/2015 02:09 PM, Arend van Spriel wrote:
> On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote:
> > 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@xxxxxxxxxxxx> 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.

So should the probe type indicate some event or should it just indicate 
what the driver needs, ie. .probe_type = PROBE_TYPE_NEED_FW.

Regards,
Arend

> That sounds good to me and learning about the async probe type. We do a
> schedule work in our module_init to avoid the probe being done in init
> context. Guess we can change that using the async probe type :-p
>
> Regards,
> Arend
> --
> 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/

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