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
patches
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).
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
