Re: RFC: top level compatibles for virtual platforms

On Mon, 11 Jul 2011 12:41:20 -0500
Yoder Stuart-B08248 [off-list ref] wrote:

quoted

-----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@ozlabs.org
Subject: Re: RFC: top level compatibles for virtual platforms

On Mon, 11 Jul 2011 10:45:47 -0500
Timur Tabi [off-list ref] wrote:

quoted

quoted

quoted

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