RE: RFC: top level compatibles for virtual platforms

-----Original Message-----
From: Wood Scott-B07421
Sent: Monday, July 11, 2011 1:05 PM
To: Yoder Stuart-B08248
Cc: Wood Scott-B07421; Tabi Timur-B04825; Grant Likely; Benjamin Herrensc=

hmidt; Gala Kumar-

B11780; Alexander Graf; linuxppc-dev@ozlabs.org
Subject: Re: RFC: top level compatibles for virtual platforms
=20
On Mon, 11 Jul 2011 12:41:20 -0500
Yoder Stuart-B08248 [off-list ref] wrote:
=20

quoted

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.

quoted

But there is a concept in Linux of a platform 'machine':

=20
So have a Linux "machine" that is used when no other one matches.  That d=

oesn't justify making

something up in the device tree.
=20

quoted

define_machine(p4080_ds) {
        .name                   =3D "P4080 DS",
        .probe                  =3D p4080_ds_probe,
        .setup_arch             =3D corenet_ds_setup_arch,
        .init_IRQ               =3D corenet_ds_pic_init,
#ifdef CONFIG_PCI
        .pcibios_fixup_bus      =3D fsl_pcibios_fixup_bus,
#endif
        .get_irq                =3D mpic_get_coreint_irq,
        .restart                =3D fsl_rstcr_restart,
        .calibrate_decr         =3D generic_calibrate_decr,
        .progress               =3D 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().

=20
Just because Linux does it that way now doesn't mean it needs to.  The in=

terrupt controller

has a compatible property.  Match on it like any other device.  You can f=

ind which one is the

root interrupt controller by looking for nodes with the interrupt-control=

ler property that

doesn't have an explicit interrupt-parent (or an interrupts property?  se=

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

However, they _are_ compatible with MPC8544DS and P4080DS so maybe
leaving the compatible string alone is ok for now.

Stuart