From: Miles Glenn <milesg@linux.vnet.ibm.com>
To: "Cédric Le Goater" <clg@kaod.org>,
qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Cc: "Nicholas Piggin" <npiggin@gmail.com>,
"Frédéric Barrat" <fbarrat@linux.ibm.com>
Subject: Re: [PATCH v4 03/11] ppc/pnv: New powernv10-rainier machine type
Date: Tue, 21 Nov 2023 11:58:41 -0600 [thread overview]
Message-ID: <fa293e804e3faaffbab8d54e817f50c40211bda4.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <67081798-658f-4a9f-b0be-ba8e4f3779db@kaod.org>
On Tue, 2023-11-21 at 07:46 +0100, Cédric Le Goater wrote:
> On 11/21/23 00:51, Glenn Miles wrote:
> > Create a new powernv machine type, powernv10-rainier, that
> > will contain rainier-specific devices.
> >
> > Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com>
> > ---
> > hw/ppc/pnv.c | 29 +++++++++++++++++++++++++++--
> > 1 file changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> > index 9c29727337..3481a1220e 100644
> > --- a/hw/ppc/pnv.c
> > +++ b/hw/ppc/pnv.c
> > @@ -2249,7 +2249,7 @@ static void
> > pnv_machine_power9_class_init(ObjectClass *oc, void *data)
> > machine_class_allow_dynamic_sysbus_dev(mc, TYPE_PNV_PHB);
> > }
> >
> > -static void pnv_machine_power10_class_init(ObjectClass *oc, void
> > *data)
> > +static void pnv_machine_p10_common_class_init(ObjectClass *oc,
> > void *data)
> > {
> > MachineClass *mc = MACHINE_CLASS(oc);
> > PnvMachineClass *pmc = PNV_MACHINE_CLASS(oc);
> > @@ -2261,7 +2261,6 @@ static void
> > pnv_machine_power10_class_init(ObjectClass *oc, void *data)
> > { TYPE_PNV_PHB_ROOT_PORT, "version", "5" },
> > };
> >
> > - mc->desc = "IBM PowerNV (Non-Virtualized) POWER10";
>
> I would keep this description because the "powernv10" machine still
> can
> be used, without I2C devices. Unless we don't want to ?
>
I'm not sure about the usefulness of the powernv10 machine, but the
description still exists in the pnv_machine_power10_class_init function
(and is unchanged). The pnv_machine_p10_common_class_init function was
created to hold initialization of things that are common between all
P10 machines, and is called by all power10 based machines (powernv10
and powernv10-rainier so far).
> > mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("power10_v2.0");
> > compat_props_add(mc->compat_props, phb_compat,
> > G_N_ELEMENTS(phb_compat));
> >
> > @@ -2274,6 +2273,23 @@ static void
> > pnv_machine_power10_class_init(ObjectClass *oc, void *data)
> > machine_class_allow_dynamic_sysbus_dev(mc, TYPE_PNV_PHB);
> > }
> >
> > +static void pnv_machine_power10_class_init(ObjectClass *oc, void
> > *data)
> > +{
> > + MachineClass *mc = MACHINE_CLASS(oc);
> > +
> > + pnv_machine_p10_common_class_init(oc, data);
> > + mc->desc = "IBM PowerNV (Non-Virtualized) POWER10";
> > +
>
> Superfluous white line.
>
Removed in v5.
> > +}
> > +
> > +static void pnv_machine_p10_rainier_class_init(ObjectClass *oc,
> > void *data)
> > +{
> > + MachineClass *mc = MACHINE_CLASS(oc);
> > +
> > + pnv_machine_p10_common_class_init(oc, data);
> > + mc->desc = "IBM PowerNV (Non-Virtualized) POWER10 rainier";
> > +}
> > +
> > static bool pnv_machine_get_hb(Object *obj, Error **errp)
> > {
> > PnvMachineState *pnv = PNV_MACHINE(obj);
> > @@ -2379,6 +2395,15 @@ static void
> > pnv_machine_class_init(ObjectClass *oc, void *data)
> > }
> >
> > static const TypeInfo types[] = {
> > + {
> > + .name = MACHINE_TYPE_NAME("powernv10-rainier"),
> > + .parent = TYPE_PNV_MACHINE,
>
> Could the parent be :
>
> .parent = MACHINE_TYPE_NAME("powernv10"),
>
> This should avoid the definition of the .interfaces below.
>
> Thanks,
>
> C.
>
Changed as suggested in v5.
Thanks,
Glenn
>
>
> > + .class_init = pnv_machine_p10_rainier_class_init,
> > + .interfaces = (InterfaceInfo[]) {
> > + { TYPE_XIVE_FABRIC },
> > + { },
> > + },
> > + },
> > {
> > .name = MACHINE_TYPE_NAME("powernv10"),
> > .parent = TYPE_PNV_MACHINE,
next prev parent reply other threads:[~2023-11-21 18:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-20 23:51 [PATCH v4 00/11] Add powernv10 I2C devices and tests Glenn Miles
2023-11-20 23:51 ` [PATCH v4 01/11] misc/pca9552: Fix inverted input status Glenn Miles
2023-11-20 23:51 ` [PATCH v4 02/11] misc/pca9552: Let external devices set pca9552 inputs Glenn Miles
2023-11-20 23:51 ` [PATCH v4 03/11] ppc/pnv: New powernv10-rainier machine type Glenn Miles
2023-11-21 1:33 ` Nicholas Piggin
2023-11-21 7:29 ` Cédric Le Goater
2023-11-21 16:36 ` Miles Glenn
2023-11-21 18:17 ` Cédric Le Goater
2023-11-21 18:26 ` Cédric Le Goater
2023-11-21 18:31 ` Miles Glenn
2023-11-23 1:46 ` Nicholas Piggin
2023-11-21 6:46 ` Cédric Le Goater
2023-11-21 17:58 ` Miles Glenn [this message]
2023-11-20 23:51 ` [PATCH v4 04/11] ppc/pnv: Add pca9552 to powernv10-rainier for PCIe hotplug power control Glenn Miles
2023-11-21 6:53 ` Cédric Le Goater
2023-11-20 23:51 ` [PATCH v4 05/11] ppc/pnv: Wire up pca9552 GPIO pins " Glenn Miles
2023-11-21 18:36 ` Cédric Le Goater
2023-11-21 20:03 ` Miles Glenn
2023-11-22 7:44 ` Cédric Le Goater
2023-11-20 23:51 ` [PATCH v4 06/11] ppc/pnv: PNV I2C engines assigned incorrect XSCOM addresses Glenn Miles
2023-11-21 18:18 ` Cédric Le Goater
2023-11-20 23:51 ` [PATCH v4 07/11] ppc/pnv: Fix PNV I2C invalid status after reset Glenn Miles
2023-11-21 18:19 ` Cédric Le Goater
2023-11-20 23:51 ` [PATCH v4 08/11] ppc/pnv: Use resettable interface to reset child I2C buses Glenn Miles
2023-11-21 18:20 ` Cédric Le Goater
2023-11-20 23:51 ` [PATCH v4 09/11] misc: Add a pca9554 GPIO device model Glenn Miles
2023-11-20 23:51 ` [PATCH v4 10/11] ppc/pnv: Add a pca9554 I2C device to powernv10-rainier Glenn Miles
2023-11-21 18:18 ` Cédric Le Goater
2023-11-20 23:51 ` [PATCH v4 11/11] ppc/pnv: Test pnv i2c master and connected devices Glenn Miles
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa293e804e3faaffbab8d54e817f50c40211bda4.camel@linux.vnet.ibm.com \
--to=milesg@linux.vnet.ibm.com \
--cc=clg@kaod.org \
--cc=fbarrat@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).