Re: [PATCH] leds: core: use deferred probing if default trigger isn't available yet

[Jacek Anaszewski <jacek.anaszewski@gmail.com>]

On 02/26/2017 10:00 PM, Pavel Machek wrote:
> On Sun 2017-02-26 18:10:56, Jacek Anaszewski wrote:
>> On 02/23/2017 10:23 PM, Heiner Kallweit wrote:
>>> Am 23.02.2017 um 22:08 schrieb Pavel Machek:
>>>> On Wed 2017-02-22 21:35:52, Heiner Kallweit wrote:
>>>>> When registering a LED device we have the option to set a default trigger.
>>>>> Depending on load order of drivers this trigger may not be available yet.
>>>>> (affected LED device in my case: a DT-configured GPIO LED)
>>>>> So far if the default trigger can't be found this error is silently
>>>>> ignored.
>>>>>
>>>>> Let's change this to return EPROBE_DEFER if the default trigger can't be
>>>>> found. This gives the system the chance to probe the LED device later
>>>>> once the trigger is available.
>>>>
>>>> I see a lot of EPROBE_DEFERs on N900, and it is quite nasty, as it
>>>> spams a log a lot.
>>>>
>>> Usually error messages are printed only if there is an error and it is not
>>> EPROBE_DEFER. However indeed there still may be several drivers not
>>> taking into account that a subsystem they depend on may return
>>> EPROBE_DEFER and this should not be treated as "hard error".
>>>
>>>> Rather then re-trying LED registration few times, could we make sure
>>>> leds are always registered after triggers or something like that?
>>>>
>>> I'm afraid if guaranteeing a particular order would be possible w/o
>>> significant effort then the whole deferred probing concept wouldn't exist.
>>>
>>> I could imagine that we can try reordering definitions in the DTS to
>>> ensure a certain load order. But this might be somewhat fragile.
>>> So using the existing concept of deferred probing seems to me to be
>>> the cleaner solution.
>>
>> We could go for a solution similar to v4l2-async.c mechanism which
>> allows for deferring video pipeline linking until all video pipeline
>> entities are probed, but in the LED subsystem case I think it would be
>> an overengineering. V4L2 media device has to wait for completion of
>> probing of several v4l2 drivers, whereas here we've got to wait for
>> a single driver. EPROBE_DEFER seems to fit for that ideally.
> 
> I was more thinking of ... just initialize all triggers earlier then
> all LEDs?
> 
> Initcalls do have few levels we could use..

All LED triggers are registered from initialization functions
(marked with __init), and there are some LED class drivers that
are also probed from similar functions. We could e.g. try to move
triggers to subsys_initcall, but it would require thorough testing
to assure that we're not breaking anything.

-- 
Best regards,
Jacek Anaszewski