RFC: top level compatibles for virtual platforms

[Scott Wood]

On Mon, 11 Jul 2011 12:41:20 -0500
Yoder Stuart-B08248 <B08248 at freescale.com> wrote:

> 
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Monday, July 11, 2011 11:24 AM
> > To: Tabi Timur-B04825
> > Cc: Yoder Stuart-B08248; Grant Likely; Benjamin Herrenschmidt; Gala Kumar-B11780; Wood Scott-
> > B07421; Alexander Graf; linuxppc-dev at ozlabs.org
> > Subject: Re: RFC: top level compatibles for virtual platforms
> > 
> > On Mon, 11 Jul 2011 10:45:47 -0500
> > Timur Tabi <timur at freescale.com> wrote:
> > 
> > > >> Also, if these are KVM creations, shouldn't there be a "kvm" in the
> > > >> compatible string somewhere?
> > > >
> > > > There is nothing KVM specific about these platforms.  Any hypervisor
> > > > could create a similar virtual machine.
> > >
> > > True, but I think we're on a slippery slope, here.  Virtualization
> > > allows us to create "virtual platforms" that are not well defined.
> > > Linux requires a unique compatible string for each platform.
> > 
> > The device tree is supposed to describe the hardware (virtual or otherwise), not just supply
> > what Linux wants.  Perhaps there simply shouldn't be a toplevel compatible if there's nothing
> > appropriate to describe there -- and fix whatever issues Linux has with that.
> 
> But there is a concept in Linux of a platform 'machine':

So have a Linux "machine" that is used when no other one matches.  That
doesn't justify making something up in the device tree.

> define_machine(p4080_ds) {
>         .name                   = "P4080 DS",
>         .probe                  = p4080_ds_probe,
>         .setup_arch             = corenet_ds_setup_arch,
>         .init_IRQ               = corenet_ds_pic_init,
> #ifdef CONFIG_PCI
>         .pcibios_fixup_bus      = fsl_pcibios_fixup_bus,
> #endif
>         .get_irq                = mpic_get_coreint_irq,
>         .restart                = fsl_rstcr_restart,
>         .calibrate_decr         = generic_calibrate_decr,
>         .progress               = udbg_progress,
> };
> 
> Right now p4080_ds_probe needs something to match on to determine
> whether this is the machine type.   How would it work if 
> there was no top level compatible to match on?   Some 
> platforms (e.g. e500v2-type) need mpc85xx_ds_pic_init(),
> others need corenet_ds_pic_init().

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).

-Scott