> -----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 > Herrenschmidt; Gala Kumar- > B11780; Alexander Graf; linuxppc-...@ozlabs.org > Subject: Re: RFC: top level compatibles for virtual platforms > > 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).
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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev