From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:49511)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1TRNoR-0005Bh-Uz
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:49:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1TRNoL-0007a1-IA
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:49:31 -0400
Received: from mx1.redhat.com ([209.132.183.28]:63418)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1TRNoL-0007Zt-8w
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:49:25 -0400
Message-ID: <50894360.906@redhat.com>
Date: Thu, 25 Oct 2012 15:49:20 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <cover.1351157627.git.peter.crosthwaite@xilinx.com>
	<e47518863bca237dd485619a6812d5df31ce16db.1351157627.git.peter.crosthwaite@xilinx.com>
	<50892CB0.6020706@redhat.com>
	<CAFEAcA8b=dyG85o2FJ_VFENXV_nJXC=D=bbM7R2KcASXCg8A_A@mail.gmail.com>
	<CAEgOgz7ey4EXFEuVfb3DtDV7RTX8+kQ=d5Yir9icBAfaYN7-Yg@mail.gmail.com>
	<50893B33.5000908@redhat.com>
	<CAEgOgz7K5_BVb+RNXpiW2H3nY1DyS9K68-=j9E5sQEUxADY+NQ@mail.gmail.com>
In-Reply-To: <CAEgOgz7K5_BVb+RNXpiW2H3nY1DyS9K68-=j9E5sQEUxADY+NQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v1 5/8] xilinx_zynq: add USB controllers
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: vineshp@xilinx.com, Peter Maydell <peter.maydell@linaro.org>, john.williams@xilinx.com, qemu-devel@nongnu.org, edgar.iglesias@gmail.com

  Hi,

>>> Yes I agree. Creating a now QOM definition for every variant of a
>>> device is tedious. EHCI provides a nice abstraction which should not
>>> have awareness of its particular implementations.
>>
>> Maybe "zynq" is the wrong abstraction and this should be named by the
>> actual ehci chip implementation (which could be the same for a bunch of
>> sysbus boards).
>>
>> But, yes, different chips should have different QOM definitions.  Like
>> we have a bunch of different uhci variants with a QOM definition for
>> each of them.
> 
> Can we at least take a data driven approach to this?

Ahem.  Well.  I'd love to.  It even used to be that way, before QOM.
uhci had a simple PCIDeviceInfo table, with an entry for each variant.
QOM turned that a bunch of class_init functions ...

Looking a bit closer (at include/qemu/object.h): seems we can pass
additional data to TypeInfo->class_init via TypeInfo->class_data.  That
should help here.

I'll go try that to simplify uhci ...

cheers,
  Gerd