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
