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 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 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 06/12] vt82c686: Simplify vt82c686b_realize() BALATON Zoltan
2021-01-07 8:11 ` Philippe Mathieu-Daudé
2021-01-06 21:13 ` [PATCH 03/12] vt82c686: Fix SMBus IO base and configuration registers BALATON Zoltan
2021-01-06 21:13 ` [PATCH 10/12] vt82c686: QOM-ify superio related functionality 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 12/12] vt82c686: Add emulation of VT8231 south bridge BALATON Zoltan
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 08/12] vt82c686: Fix superio_cfg_{read,write}() functions 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 07/12] vt82c686: Move creation of ISA devices to the ISA bridge 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.