All of lore.kernel.org
 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 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.