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:

quoted

On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote:

quoted

Am 21.08.2014 16:02, schrieb Thierry Reding:

quoted

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.

quoted

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.

quoted

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.