Hi Daniel, On Thu, Aug 30, 2018 at 10:37 AM Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> wrote: > On 30/08/2018 10:27, Geert Uytterhoeven wrote: > > On Thu, Aug 30, 2018 at 10:09 AM Daniel Lezcano > > <daniel.lezcano@xxxxxxxxxx> wrote: > >> On 30/08/2018 09:54, Geert Uytterhoeven wrote: > >>> On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano > >>> <daniel.lezcano@xxxxxxxxxx> wrote: > >>>> On 29/08/2018 17:44, Chris Brandt wrote: > >>>>> On Wednesday, August 29, 2018 1, Daniel Lezcano wrote: > >>>>>> Can the boot constraints [1] solve this issue instead of the changes you > >>>>>> are proposing ? > >>>>>> > >>>>>> [1] https://lwn.net/Articles/747250/ > >>>>> > >>>>> Thanks for the suggestion, but... > >>>>> > >>>>> I grepped for "boot_constraint" and it shows up nowhere in the current > >>>>> kernel. > >>>>> > >>>>> Also, this article was written Feb 16, 2018, and I can see that the > >>>>> patch series was still being submitted (V7) as of Feb 23, 2018. > >>>> > >>>> Ah ok, fair enough, I thought it was merged. In any case, after thinking > >>>> about it, it wouldn't have helped. > >>>> > >>>> My concern is if we can avoid changing the TIMER_OF_DECLARE because of > >>>> the boot order, it would be better. > >>>> > >>>> Can returning EPROBE_DEFER fix this issue? Or use the 'complex > >>>> dependencies' [1]? > >>> > >>> *_OF_DECLARE() is not compatible with EPROBE_DEFER, which causes > >>> issues with complex dependencies. > >> > >> What causes issues ? Add support for EPROBE_DEFER with OF_DECLARE or not > >> having support of it ? > > > > Driver init functions declared using *_OF_DECLARE() are called exactly once. > > Hence if they fail, they are never retried. Calling order among subsystems is > > hardcoded, and the actual order was determined by historical reasons (legacy > > PC systems with always-on clocks and power domains ;-). > > This breaks as soon as e.g. timers or interrupt controllers start depending > > on clocks and/or power domains. > > > > Drivers using the device driver framework are retried later when their init > > function returns -EPROBE_DEFER. So (eventually) they all succeed > > initialization. > > Yeah, I got this point. But it is the meaning of your sentence: "... > which causes issues with complex dependencies.". > > It is ambiguous *what* causes the issues. > > Did you meant an attempt was done to support EPROBE_DEFER with > *_OF_DECLARE but caused too much issues with the complex dependencies? > > Or the current situation is causing too much issues with the complex > dependencies? > > (I know the latter is true, it is about the meaning of the sentence). I meant the latter. AFAIK no attempt was done to support EPROBE_DEFER with *_OF_DECLARE. IMHO it would be pointless, as it would be much easier to just switch to real platform drivers. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
