On Mon, 11 Jul 2011 12:41:20 -0500 Yoder Stuart-B08248 <b08...@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-...@ozlabs.org > > Subject: Re: RFC: top level compatibles for virtual platforms > > > > On Mon, 11 Jul 2011 10:45:47 -0500 > > Timur Tabi <ti...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev