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

[Dmitry Torokhov]

On Wed, Sep 2, 2015 at 5:13 AM, Arend van Spriel <arend@xxxxxxxxxxxx> wrote:
> 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.

What will kernel do when it sees such an option? It does not know when
firmware will become available (if ever). We can only try and fail and
then userspace may try re-probing devices once firmware is available.
I guess the question is how to let userspace know what devices failed
to probe because of the lack of firmware.

Thanks.

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