So, like, the other day Gabriel Paubert mumbled:
This said, I'm looking at device trees right now, and I can understand
that interrupt-parent of the 8259 is &mpic in mpc8641_hpcn.dts, but
I don't understand at all why it is &pci1 on the mpc85??cds.dts.
But the definition of the ISA bridge in these files is very strange to
start with: I've never seen an ISA bridge with only an interrupt controller
on it, no interrupts are connected to it and its reg property is
almost certainly wrong. Maybe it is an example of things that should
not be done.
I think this is an example of Early Days Misunderstanding Creep.
It was likely one of the very first attempts to write the file for
any FSL embedded part, and as such, it was probably not so good.
Likely, it could use some cleanup. Patches and suggestions welcome.
jdl
I think this is an example of Early Days Misunderstanding Creep.
Is that the official name? :-)
It was likely one of the very first attempts to write the file for
any FSL embedded part, and as such, it was probably not so good.
But it also probably worked just fine, given all the
big fat workarounds in the Linux tree parsing code,
which are applied on *all* boards -- this will have
to change sooner or later, just like you don't run
all PCI quirks on all boards: it simply doesn't scale
and the side effects make everything impossible to
understand. In almost all cases, simply fixing the
device tree (Linux' runtime copy, anyway) in some
pre-processing pass is conceptually a much simpler
solution as well.
Likely, it could use some cleanup. Patches and suggestions welcome.
I rather just wait until things break and then
deprecate (and later remove) support for those
boards. Unless the respective maintainers for
those boards fix things up, all is fine then
of course ;-)
Slightly more seriously -- since there are so
many DTS files, and their number grows real fast;
and since they are non-modular, and mostly copy-
and-paste; most fixes have to be made to lots
of separate DTS files. And that is something
no one can do, since no one can *test* those fixes,
since you need the hardware to do that.
Segher