Hi Daniel,
On Thu, Aug 30, 2018 at 10:37 AM Daniel Lezcano
<daniel.lezc...@linaro.org> wrote:
> On 30/08/2018 10:27, Geert Uytterhoeven wrote:
> > On Thu, Aug 30, 2018 at 10:09 AM Daniel Lezcano
> > <daniel.lezc...@linaro.org> wrote:
> >> On 30/08/2018 09:54, Geert Uytterhoeven wrote:
> >>> On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano
> >>> <daniel.lezc...@linaro.org> 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 -- ge...@linux-m68k.org
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
