RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Monday, July 11, 2011 4:07 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Tabi Timur-B04825; Grant Likely; Benjamin Herrenschmidt; Gala Kumar-
> B11780; Alexander Graf; linuxppc-dev at ozlabs.org
> Subject: Re: RFC: top level compatibles for virtual platforms
> 
> On Mon, 11 Jul 2011 15:41:35 -0500
> Yoder Stuart-B08248 <B08248 at freescale.com> wrote:
> 
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Monday, July 11, 2011 1:05 PM
> > >
> > > Just because Linux does it that way now doesn't mean it needs to.
> > > The interrupt controller has a compatible property.  Match on it
> > > like any other device.  You can find which one is the root interrupt
> > > controller by looking for nodes with the interrupt-controller
> > > property that doesn't have an explicit interrupt-parent (or an interrupts property?  seems
> to be a conflict between ePAPR and the original interrupt mapping document).
> >
> > This may be the right long term thing to do, but restructuring how
> > Linux powerpc platforms work is a bigger effort.  I was looking for an
> > incremental improvement over what we do now, which is pass a
> > compatible of MPC8544DS and P4080DS for these virtual platforms.
> 
> A hack is usually easier than doing it right. :-)
> 
> Though often the effort required for the latter is overstated, and the "right long term thing"
> never makes the jump to "short term plan".
> 
> There are a few things that need to be driven off the device tree that currently aren't --
> using some mechanism other than the standard device model, if necessary (or as a first step) -
> - and then we need a does-nothing default platform as the match of last resort.
> 
> > However, they _are_ compatible with MPC8544DS and P4080DS so maybe
> > leaving the compatible string alone is ok for now.
> 
> The virtual platforms are not compatible with MPC8544DS or P4080DS.  Only a subset of what is
> on those boards is provided.  And in the case of direct device assignment, often the things
> that are present are incompatible (e.g.
> different type of eTSEC).

Hmm.  Perhaps what we need is a real binding that defines specifically
what those compatibles mean.   While not identical, a KVM
virtual machine is compatible in certain areas with those
boards.

The ePAPR defines the top level compatible as:

    Specifies a list of platform architectures with which this
    platform is compatible. This property can be used by
    operating systems in selecting platform specific code.

1275 doesn't mention compatible on the root from what I can
see.

Stuart