qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>
Cc: vineshp@xilinx.com, peter.maydell@linaro.org,
	Jason Baron <jbaron@redhat.com>,
	qemu-devel@nongnu.org, john.williams@xilinx.com,
	edgar.iglesias@gmail.com
Subject: Re: [Qemu-devel] [PATCH v3 2/8] usb/ehci: Use class_data to init PCI variations
Date: Mon, 29 Oct 2012 10:35:18 +0100	[thread overview]
Message-ID: <508E4DD6.2030407@suse.de> (raw)
In-Reply-To: <e0b8c06e00ab35dad06f672fb266088bff5028ac.1351473902.git.peter.crosthwaite@xilinx.com>

Am 29.10.2012 02:34, schrieb Peter Crosthwaite:
> Got rid of the duplication of the class init functions for the two PCI EHCI
> variants. The PCI specifics are passed in as as class_data and set by a common
> class_init function.
> 
> Premeptively defined a new Class "EHCICLass" for the upcomming addition of new

"Preemptively", "upcoming"

> fields. The class_data is an instance of EHCICLass that forms a template for the
> class to generate.

Using "EHCI[PCI]Class" to template itself seems a bit awkward, Anthony
do you have any thoughts on this? The usual way would be to have a
dedicated EHCIInfo struct or so.

> 
> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> ---
> Got rid of union for sharing EHCIClassDefinition - made PCI specific
> Simplified literal class_data arrays in ehci_info accordingly
> removed null sentinel from ehci_info and used ARRAY_SIZE for type_regsiter loop
> 	bound instead
> 
>  hw/usb/hcd-ehci.c |   76 ++++++++++++++++++++++++++++------------------------
>  1 files changed, 41 insertions(+), 35 deletions(-)
> 
> diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
> index 6c65a73..274225b 100644
> --- a/hw/usb/hcd-ehci.c
> +++ b/hw/usb/hcd-ehci.c
> @@ -2641,46 +2641,49 @@ static Property ehci_properties[] = {
>      DEFINE_PROP_END_OF_LIST(),
>  };
>  
> -static void ehci_class_init(ObjectClass *klass, void *data)
> -{
> -    DeviceClass *dc = DEVICE_CLASS(klass);
> -    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> -
> -    k->init = usb_ehci_initfn;
> -    k->vendor_id = PCI_VENDOR_ID_INTEL;
> -    k->device_id = PCI_DEVICE_ID_INTEL_82801D; /* ich4 */
> -    k->revision = 0x10;
> -    k->class_id = PCI_CLASS_SERIAL_USB;
> -    dc->vmsd = &vmstate_ehci;
> -    dc->props = ehci_properties;
> -}
> +typedef struct EHCIPCIClass {
> +    PCIDeviceClass pci;
> +} EHCIPCIClass;
>  
> -static TypeInfo ehci_info = {
> -    .name          = "usb-ehci",
> -    .parent        = TYPE_PCI_DEVICE,
> -    .instance_size = sizeof(EHCIState),
> -    .class_init    = ehci_class_init,
> -};
> -
> -static void ich9_ehci_class_init(ObjectClass *klass, void *data)
> +static void ehci_class_init(ObjectClass *klass, void *data)
>  {
>      DeviceClass *dc = DEVICE_CLASS(klass);
> -    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> -
> -    k->init = usb_ehci_initfn;
> -    k->vendor_id = PCI_VENDOR_ID_INTEL;
> -    k->device_id = PCI_DEVICE_ID_INTEL_82801I_EHCI1;
> -    k->revision = 0x03;
> -    k->class_id = PCI_CLASS_SERIAL_USB;
> +    EHCIPCIClass *k = (EHCIPCIClass *)klass;

Please use a proper QOM cast macro: EHCI_PCI_CLASS(klass)

In this case however, please keep using PCIDeviceClass rather than
trying to access it through a named member. If we need to access any
dedicated EHCIPCIClass fields later in the series we can add additional
variables the QOM way.

> +    EHCIPCIClass *template = data;
> +
> +    k->pci.init = usb_ehci_initfn;
> +    k->pci.vendor_id = template->pci.vendor_id;
> +    k->pci.device_id = template->pci.device_id; /* ich4 */
> +    k->pci.revision = template->pci.revision;
> +    k->pci.class_id = PCI_CLASS_SERIAL_USB;
>      dc->vmsd = &vmstate_ehci;
>      dc->props = ehci_properties;
>  }
>  
> -static TypeInfo ich9_ehci_info = {
> -    .name          = "ich9-usb-ehci1",
> -    .parent        = TYPE_PCI_DEVICE,
> -    .instance_size = sizeof(EHCIState),
> -    .class_init    = ich9_ehci_class_init,
> +static TypeInfo ehci_info[] = {

Can this still be made const despite the embedded class_data?

> +    {
> +        .name          = "usb-ehci",
> +        .parent        = TYPE_PCI_DEVICE,
> +        .instance_size = sizeof(EHCIState),
> +        .class_init    = ehci_class_init,
> +        .class_size    = sizeof(EHCIPCIClass),
> +        .class_data    = (EHCIPCIClass[]) {{
> +            .pci.vendor_id = PCI_VENDOR_ID_INTEL,
> +            .pci.device_id = PCI_DEVICE_ID_INTEL_82801D,
> +            .pci.revision  = 0x10,
> +        } }
> +    }, {
> +        .name          = "ich9-usb-ehci1",

Do we have a suitable header to introduce TYPE_* constants for these
while at it? That would benefit q35.

Andreas

> +        .parent        = TYPE_PCI_DEVICE,
> +        .instance_size = sizeof(EHCIState),
> +        .class_init    = ehci_class_init,
> +        .class_size    = sizeof(EHCIPCIClass),
> +        .class_data    = (EHCIPCIClass[]) {{
> +            .pci.vendor_id = PCI_VENDOR_ID_INTEL,
> +            .pci.device_id = PCI_DEVICE_ID_INTEL_82801I_EHCI1,
> +            .pci.revision  = 0x03,
> +        } }
> +    },
>  };
>  
>  static int usb_ehci_initfn(PCIDevice *dev)
> @@ -2769,8 +2772,11 @@ static int usb_ehci_initfn(PCIDevice *dev)
>  
>  static void ehci_register_types(void)
>  {
> -    type_register_static(&ehci_info);
> -    type_register_static(&ich9_ehci_info);
> +    int i;
> +
> +    for (i = 0; i < ARRAY_SIZE(ehci_info); i++) {
> +        type_register_static(&ehci_info[i]);
> +    }
>  }
>  
>  type_init(ehci_register_types)
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  reply	other threads:[~2012-10-29  9:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-29  1:34 [Qemu-devel] [PATCH v3 0/8] Sysbus EHCI + Zynq USB Peter Crosthwaite
2012-10-29  1:34 ` [Qemu-devel] [PATCH v3 1/8] dma: Define dma_context_memory and use in sysbus-ohci Peter Crosthwaite
2012-10-29  1:34 ` [Qemu-devel] [PATCH v3 2/8] usb/ehci: Use class_data to init PCI variations Peter Crosthwaite
2012-10-29  9:35   ` Andreas Färber [this message]
2012-10-29 11:43     ` Peter Crosthwaite
2012-10-29 13:21       ` Andreas Färber
2012-10-29  1:34 ` [Qemu-devel] [PATCH v3 3/8] usb/ehci: parameterise the register region offsets Peter Crosthwaite
2012-10-29  1:34 ` [Qemu-devel] [PATCH v3 4/8] usb/ehci: Abstract away PCI DMA API Peter Crosthwaite
2012-10-29  1:34 ` [Qemu-devel] [PATCH v3 5/8] usb/ehci: seperate out PCIisms Peter Crosthwaite
2012-10-29  1:34 ` [Qemu-devel] [PATCH v3 6/8] usb/ehci: Add Sysbus variant and Xilinx Zynq USB Peter Crosthwaite
2012-10-29  1:34 ` [Qemu-devel] [PATCH v3 7/8] xilinx_zynq: add USB controllers Peter Crosthwaite
2012-10-29  1:34 ` [Qemu-devel] [PATCH v3 8/8] usb/ehci: Guard definition of EHCI_DEBUG Peter Crosthwaite
2012-10-29  7:48 ` [Qemu-devel] [PATCH v3 0/8] Sysbus EHCI + Zynq USB Gerd Hoffmann
2012-10-29  8:53   ` Andreas Färber
2012-10-29  9:41     ` Gerd Hoffmann

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=508E4DD6.2030407@suse.de \
    --to=afaerber@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=edgar.iglesias@gmail.com \
    --cc=jbaron@redhat.com \
    --cc=john.williams@xilinx.com \
    --cc=kraxel@redhat.com \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vineshp@xilinx.com \
    /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).