Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)

From: Alexander Holler
Date: Wed Aug 27 2014 - 03:16:55 EST

Am 26.08.2014 15:58, schrieb Jon Loeliger:

I think we need to do the complete topsort *before* we attempt
to do any probing. So three steps:

1) Graph Construction
Add a new "emit dependencies" function to driver bindings.
Iterate over known devices or nodes in the DT in any order.
Call the "emit dependencies" function. It adds all
dependency edges to a global graph by knowing what
phandles or other pieces it will need.
A driver with no "emit dependencies" function can be
added to the graph anywhere without loss of generality.
Add any additional edges for whatever reason.

2) Topsort the generated driver graph

3) Call probe for real in topsort order

Alexander, I don't recall the details of your patch series.
Can you please remind us if it took this approach in the kernel?

Anyway, I'm leaving this discussion. I've already made a proposal
which solved most mentioned problems (imho) and even offered usable

Why should I? I've posted patches along with a lot of comments and
explanations, and e.g. you are just talking that it should be made like
my patches already did. And others do talk too like my patches and the
accompanying comments from me which explain most stuff never have existed and just repeat what the patches already do without refering to them.

Darn. I think you clearly have a pony in this race, and it
would be good if you still participated. Really.

Thanks. But I don't see it as a race and I don't want to take part in a race (and I usually avoid those silly contests which have become chic in the IT world). I just offered a solution (or at least a working starting point to a solution).

(ok, they suffer under the "not invented here" syndrom, but ...). ;)

There isn't a single thing in the entire Linux Kernel community
that was "invented here"; every aspect of it was NIH'ed by *someone*.
That's how it gets built, changed, maintained, fixed, etc.

Might be true in an ideal open source world and might have been true for past kernel development when most people weren't full time kernel developers. But nowadays it appears to me like many parts of the kernel have become in the hands of closed groups. And they build and enforce hurdles that high, that nobody else can take them without spending an idiotic amount of time. Just like many other "consortiums" do, you only have to build enough rules to protect from the outside while still looking open.

E.g. an example I've seen often is that someone spend a lot of time to examine and fix a bug and write a commented patch. And the only response from the maintainer was that he should add an emtpy line before a return statement and similiar silly things to enforce patch-ping-pong. Such just drives people on the other end crazy and they likely won't spend the time to post another patch (they still might fix other bugs, but just for themself).


Alexander Holler
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at