From: Igor Mammedov <imammedo@redhat.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: "Huacai Chen" <chenhuacai@kernel.org>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
qemu-devel@nongnu.org
Subject: Re: [PATCH 05/12] vt82c686: Make vt82c686b-pm an abstract base class and add vt8231-pm based on it
Date: Thu, 7 Jan 2021 11:56:15 +0100 [thread overview]
Message-ID: <20210107115615.3cac27b3@redhat.com> (raw)
In-Reply-To: <93a8537e-64c1-1a3-8eeb-2114a46458d@eik.bme.hu>
On Thu, 7 Jan 2021 11:38:21 +0100 (CET)
BALATON Zoltan <balaton@eik.bme.hu> wrote:
> On Thu, 7 Jan 2021, Philippe Mathieu-Daudé wrote:
> > Hi Zoltan,
> >
> > On 1/6/21 10:13 PM, BALATON Zoltan wrote:
> >> The vt82c686b-pm model can be shared between VT82C686B and VT8231. The
> >> only difference between the two is the device id in what we emulate so
> >> make an abstract via-pm model by renaming appropriately and add types
> >> for vt82c686b-pm and vt8231-pm based on it.
> >>
> >> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> >> ---
> >> hw/isa/vt82c686.c | 87 ++++++++++++++++++++++++++-------------
> >> include/hw/isa/vt82c686.h | 1 +
> >> 2 files changed, 59 insertions(+), 29 deletions(-)
> > ...
> >
> >> +typedef struct via_pm_init_info {
> >> + uint16_t device_id;
> >> +} ViaPMInitInfo;
> >> +
> >> static void via_pm_class_init(ObjectClass *klass, void *data)
> >> {
> >> DeviceClass *dc = DEVICE_CLASS(klass);
> >> PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> >> + ViaPMInitInfo *info = data;
> >>
> >> - k->realize = vt82c686b_pm_realize;
> >> + k->realize = via_pm_realize;
> >> k->config_write = pm_write_config;
> >> k->vendor_id = PCI_VENDOR_ID_VIA;
> >> - k->device_id = PCI_DEVICE_ID_VIA_ACPI;
> >> + k->device_id = info->device_id;
> >> k->class_id = PCI_CLASS_BRIDGE_OTHER;
> >> k->revision = 0x40;
> >> - dc->reset = vt82c686b_pm_reset;
> >> - dc->desc = "PM";
> >> + dc->reset = via_pm_reset;
> >
> >> + /* Reason: part of VIA south bridge, does not exist stand alone */
> >> + dc->user_creatable = false;
> >> dc->vmsd = &vmstate_acpi;
> >> - set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
> >
> > Please do this change in a previous patch.
>
> OK, done.
>
> >> }
> >>
> >> static const TypeInfo via_pm_info = {
> >> - .name = TYPE_VT82C686B_PM,
> >> + .name = TYPE_VIA_PM,
> >> .parent = TYPE_PCI_DEVICE,
> >> - .instance_size = sizeof(VT686PMState),
> >> - .class_init = via_pm_class_init,
> >> + .instance_size = sizeof(ViaPMState),
> >> + .abstract = true,
> >> .interfaces = (InterfaceInfo[]) {
> >> { INTERFACE_CONVENTIONAL_PCI_DEVICE },
> >> { },
> >> },
> >> };
> >>
> >> +static const ViaPMInitInfo vt82c686b_pm_init_info = {
> >> + .device_id = PCI_DEVICE_ID_VIA_ACPI,
> >> +};
> >> +
> >> +static const TypeInfo vt82c686b_pm_info = {
> >> + .name = TYPE_VT82C686B_PM,
> >> + .parent = TYPE_VIA_PM,
> >> + .class_init = via_pm_class_init,
> >> + .class_data = (void *)&vt82c686b_pm_init_info,
> >
> > Igor said new code should avoid using .class_data:
> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg678305.html
> > Can you convert to "leaf class"? Then this patch is good to go.
>
> That says for machines it is not advised (and Igor generally prefers init
> funcs everywhere) but this is a device model. Is it still not allowed to
> use class_data here? I think this is shorter this way than with an init
> function but I may try to convert if absolutely necessary.
For this simple case class_init would be cleaner as it doesn't need casting (void*).
But I'm fine with either approaches here.
> Regards,
> BALATON Zoltan
>
> > A trivial example of conversion is commit f0eeb4b6154
> > ("hw/arm/raspi: Avoid using TypeInfo::class_data pointer").
> >
> >> +};
> >> +
> >> +static const ViaPMInitInfo vt8231_pm_init_info = {
> >> + .device_id = 0x8235,
Is it possible to replace magic number with a human readable macro?
> >> +};
> >> +
> >> +static const TypeInfo vt8231_pm_info = {
> >> + .name = TYPE_VT8231_PM,
> >> + .parent = TYPE_VIA_PM,
> >> + .class_init = via_pm_class_init,
> >> + .class_data = (void *)&vt8231_pm_init_info,
> >> +};
> >>
> >>
> >
> >
next prev parent reply other threads:[~2021-01-07 10:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 21:13 [PATCH 00/12] vt82c686b clean ups and vt8231 emulation BALATON Zoltan
2021-01-06 21:13 ` [PATCH 03/12] vt82c686: Fix SMBus IO base and configuration registers BALATON Zoltan
2021-01-06 21:13 ` [PATCH 08/12] vt82c686: Fix superio_cfg_{read,write}() functions BALATON Zoltan
2021-01-06 21:13 ` [PATCH 05/12] vt82c686: Make vt82c686b-pm an abstract base class and add vt8231-pm based on it BALATON Zoltan
2021-01-07 8:02 ` Philippe Mathieu-Daudé
2021-01-07 10:38 ` BALATON Zoltan
2021-01-07 10:56 ` Igor Mammedov [this message]
2021-01-07 19:57 ` BALATON Zoltan
2021-01-06 21:13 ` [PATCH 01/12] vt82c686: Move superio memory region to SuperIOConfig struct BALATON Zoltan
2021-01-06 21:13 ` [PATCH 04/12] vt82c686: Fix up power management io base and config BALATON Zoltan
2021-01-06 21:13 ` [PATCH 06/12] vt82c686: Simplify vt82c686b_realize() BALATON Zoltan
2021-01-07 8:11 ` Philippe Mathieu-Daudé
2021-01-06 21:13 ` [PATCH 02/12] vt82c686: Reorganise code BALATON Zoltan
2021-01-07 8:07 ` Philippe Mathieu-Daudé
2021-01-07 9:47 ` BALATON Zoltan
2021-01-06 21:13 ` [PATCH 07/12] vt82c686: Move creation of ISA devices to the ISA bridge BALATON Zoltan
2021-01-06 21:13 ` [PATCH 12/12] vt82c686: Add emulation of VT8231 south bridge BALATON Zoltan
2021-01-06 21:13 ` [PATCH 09/12] vt82c686: Implement control of serial port io ranges via config regs BALATON Zoltan
2021-01-06 21:13 ` [PATCH 11/12] vt82c686: Add VT8231_SUPERIO based on VIA_SUPERIO BALATON Zoltan
2021-01-06 21:13 ` [PATCH 10/12] vt82c686: QOM-ify superio related functionality BALATON Zoltan
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=20210107115615.3cac27b3@redhat.com \
--to=imammedo@redhat.com \
--cc=balaton@eik.bme.hu \
--cc=chenhuacai@kernel.org \
--cc=f4bug@amsat.org \
--cc=qemu-devel@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).