On 22.01.2013, at 02:53, Scott Wood wrote:

> The compatible string is changed to fsl,mpic on all e500 platforms, to
> advertise the existence of BRR1.  This matches what the device tree will
> have on real hardware.
> 
> With MPIC v4.2 max_cpu can be increased from 15 to 32.
> 
> Signed-off-by: Scott Wood <scottw...@freescale.com>
> ---
> hw/ppc/e500.c      |    4 ++--
> hw/ppc/e500.h      |    2 ++
> hw/ppc/e500plat.c  |    4 +++-
> hw/ppc/mpc8544ds.c |    2 ++
> 4 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
> index 530f929..b7474c0 100644
> --- a/hw/ppc/e500.c
> +++ b/hw/ppc/e500.c
> @@ -297,7 +297,7 @@ static int ppce500_load_device_tree(CPUPPCState *env,
>     snprintf(mpic, sizeof(mpic), "%s/pic@%llx", soc, 
> MPC8544_MPIC_REGS_OFFSET);
>     qemu_devtree_add_subnode(fdt, mpic);
>     qemu_devtree_setprop_string(fdt, mpic, "device_type", "open-pic");
> -    qemu_devtree_setprop_string(fdt, mpic, "compatible", "chrp,open-pic");
> +    qemu_devtree_setprop_string(fdt, mpic, "compatible", "fsl,mpic");

Actually, thinking about this once more, would older kernels continue to work 
with "fsl,mpic"? Did the kernels that first introduced the qemu ppc machine 
already support "fsl,mpic" or would they rely on "chrp,open-pic"?

In case of the latter, we should provide both compatibles, right?


Alex


Reply via email to