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

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

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..
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]