[RFC,PATCH 0/2] Allow late mdesc detection

[Russell King - ARM Linux]

On Tue, Jul 13, 2010 at 05:02:26PM +0800, Jeremy Kerr wrote:
> It's been about 5 months since I started work on DT on ARM; I'm not sure
> who's been working on it previously, if anyone.

Grant promised me a DT implementation on a 'real platform' quite
some time ago.

> So far, most of the time has been preparation work - things like the clk
> infrastructure, and smaller bits like these addruart patches. We're (me,
> gcl and nico) also working carefully to specify the interfaces and
> standards correctly, for example getting the boot interface right, and
> standard formats for ARM device representation in the DT.

Things like a grand unification of the clk infrastructure, addruart,
and boot interface all seem to be relatively minor things compared
to determining whether platform support really benefits from DT,
which is whole point of my statement on wanting to see a real
implementation of it.

What I'm interested in its impact on the numerous board support files
that we currently have - some 348 of them at the present time.  For
example, currently these are used to provide small fragments of code
to drivers to support what are effectively board quirks.  What I'm
particularly interested in is how these quirks get attached to their
relevant drivers - and whether this becomes easier with DT or harder
with it.

If it makes this stuff simpler, then all well and good - it's a net
benefit.  If it makes this a lot more complicated - eg, because we
need to declare every bit of quirk code into some kind of table for
DT to pick up and bind in some manner to a driver - then moving to
DT will be a disaster for maintainability and readability, and we
lose type checking on these quirk functions.

It's this area, and related areas to it that I'm really interested
in, rather than these grand unification schemes which seem to be top
priority at the moment.

What really concerns me at the moment is that there's soo much work
being put into the peripheral DT issues without first answering the
question about whether DT on ARM is viable by providing a working
real complex platform implementation.