Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
From: Mark Rutland
Date: Tue Aug 26 2014 - 05:57:03 EST
On Mon, Aug 25, 2014 at 10:39:32AM +0100, Thierry Reding wrote:
> On Fri, Aug 22, 2014 at 02:19:19PM +0100, Mark Rutland wrote:
> > On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote:
> > > Am 21.08.2014 16:02, schrieb Thierry Reding:
> > >
> > > > Anyway, those are all fairly standard reasons for where deferred probe
> > > > triggers, and since I do like deferred probe for it's simplicity and
> > > > reliability I'd rather not try to work around it if boot time is all
> > > > that people are concerned about.
> > >
> > > It's neither simple nor reliable. It's non deterministic brutforcing
> > > while making it almost impossible to identify real errors.
> >
> > It's horrible, yes.
> >
> > > In my humble opinion the worst way to solve something. I'm pretty sure
> > > if I would have suggest such a solution, the maintainer crowd would have
> > > eaten me without cooking.
> >
> > We didn't have a better workable solution at the time.
>
> You make it sound like we've come up with a better workable solution in
> the meantime.
That wasn't the intention, but my sloppy wording does make it come
across that way.
> > Having a hack that got boards booting was considered better than not
> > having them boot.
> > I don't remember people being particularly enthralled by the idea.
>
> Odd, I remember things quite differently.
Then perhaps my memory is faulty. :)
> Anyway, instead of going back and forth between "deferred probe is good"
> and "deferred probe is bad", how about we do something useful now and
> concentrate on how to make use of the information we have in DT with the
> goal to reduce the number of cases where deferred probing is required?
Certainly.
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/