qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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,
> >> +};
> >>
> >>  
> >
> >  



  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).