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

From	Arend van Spriel <arend@broadcom.com>
Newsgroups	linux.kernel
Subject	Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
Date	2015-09-02 14:20 +0200
Message-ID	<q4fbd-4Me-27@gated-at.bofh.it> (permalink)
References	(6 earlier) <q2K9s-5hS-9@gated-at.bofh.it> <q2LIe-7CJ-21@gated-at.bofh.it> <q369Y-3wN-9@gated-at.bofh.it> <q3yfV-1QK-27@gated-at.bofh.it> <q44Sv-6P9-31@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thread

csiph-web