ARM machine specific DT probing

[Scott Wood]

On Thu, 16 Sep 2010 11:40:20 -0600
Grant Likely <grant.likely at secretlab.ca> wrote:

> However, what does compatible mean at the board level?  Can a
> BeagleBoard-xM claim compatibility with the original BeagleBoard?  Or
> even can a -b1 BeagleBoard claim compatibility with the original -a1
> revision?  The -b1 has more SDRAM than the original, and the -xM has
> removed the on board NAND flash.  Neither change can be considered to
> be "100% backwards compatible", so is it valid to claim compatibility
> with the older board?  Clearly the difference between the boards is
> still described in the body of the tree so claiming compatibility
> appears to be the Right Thing To Do, but a strict reading would say
> no.

It gets even uglier with virtualization, where you can have arbitrary
subsets of a particular board's devices available -- and things like
the interrupt controller that are currently normally hardcoded in the
platform file may be swapped out for a paravirt interface.

> benh has also been strongly against powerpc embedded board support
> that can match against a family of boards or SoCs.  Instead, he has
> required that each platform code have a list of specific boards that
> it works with.  Example: arch/powerpc/platforms/5200/mpc5200_simple.c.
> He doesn't want to get back into the situation where each machine type
> gets a whole bunch of complex board-specific workarounds. 

Even as things are now, such workarounds can still be pretty awkward.

They may actually be SoC (family) workarounds (and thus you end up with
a bunch of identical machine_initcalls or similar), or it may need to
go in the middle of code that doesn't normally go in the platform file,
etc.

And it excuses ordinary, non-workaround code (PCI and interrupt setup)
sitting around duplicated in a bunch of platform files instead of being
device-tree-based.

> - Revisit the meaning of top-level compatible.
>   - I still don't think it makes sense for one board to claim
>     compatibility with another,

Most of the time it doesn't, but there may be circumstances where things
are only added, or where a new revision just fixes bugs but software
that works around the bugs will still work.

If we don't allow claiming compatibility in those cases, it may
encourage people to lie and claim to just be that old board with no
more specific entry in the list (or just not put the board rev in the
name at all -- which might be reasonable if the rev info is presented
in a separate property, allowing things like greater-than/less-than
comparisons).

>     but it may be reasonable for the
>     board level to claim compatibility with the SoC used.

Or a family of SoCs, or a family of boards, etc... The criteria simply
ought to be that it is well documented what it means to be compatible
with that string, and that there be something very specific that code
can match on instead if^H^Hwhen things go wrong.

-Scott