Re: [PATCH 10/24] macio: Bury unwanted "macio-gpio" devices

[Mark Cave-Ayland]

On 18/05/2020 06:03, Markus Armbruster wrote:

> These devices go with the "via-pmu" device, which is controlled by
> property "has-pmu".  macio_newworld_init() creates it unconditionally,
> because the property has not been set then.  macio_newworld_realize()
> realizes it only when the property is true.  Works, although it can
> leave an unrealized device hanging around in the QOM composition tree.
> Affects machine mac99 with via=cuda (default).
> 
> Bury the unwanted device by making macio_newworld_realize() unparent
> it.  Visible in "info qom-tree":
> 
>      /machine (mac99-machine)
>        [...]
>        /unattached (container)
>          /device[9] (macio-newworld)
>            [...]
>            /escc-legacy-port[8] (qemu:memory-region)
>            /escc-legacy-port[9] (qemu:memory-region)
>            /escc-legacy[0] (qemu:memory-region)
>     -      /gpio (macio-gpio)
>     -        /gpio[0] (qemu:memory-region)
>            /ide[0] (macio-ide)
>              /ide.0 (IDE)
>              /pmac-ide[0] (qemu:memory-region)
> 
> Cc: Mark Cave-Ayland <address@hidden>
> Cc: David Gibson <address@hidden>
> Cc: address@hidden
> Signed-off-by: Markus Armbruster <address@hidden>
> ---
>  hw/misc/macio/macio.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c
> index 3779865ab2..b3dddf8be7 100644
> --- a/hw/misc/macio/macio.c
> +++ b/hw/misc/macio/macio.c
> @@ -368,6 +368,8 @@ static void macio_newworld_realize(PCIDevice *d, Error 
> **errp)
>          memory_region_add_subregion(&s->bar, 0x16000,
>                                      sysbus_mmio_get_region(sysbus_dev, 0));
>      } else {
> +        object_unparent(OBJECT(&ns->gpio));
> +
>          /* CUDA */
>          object_initialize_child(OBJECT(s), "cuda", &s->cuda, sizeof(s->cuda),
>                                  TYPE_CUDA, &error_abort, NULL);

This one is a little more interesting because it comes back to the previous
discussions around if you have a device that contains other devices, should you 
init
all the children in your container device init, and the realize all your 
children in
your container device realize?

If so I guess this patch isn't technically wrong, but it is somewhat misleading 
given
that the existing init/realize pattern here is incorrect. Perhaps it should go 
ahead
and make everything work the "right way"?


ATB,

Mark.