From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRNGh-0007WU-Eg for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:14:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRNGc-0003ZQ-1X for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:14:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRNGb-0003Z3-Ow for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:14:33 -0400 Message-ID: <50893B33.5000908@redhat.com> Date: Thu, 25 Oct 2012 15:14:27 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <50892CB0.6020706@redhat.com> In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: vineshp@xilinx.com, Peter Maydell , john.williams@xilinx.com, qemu-devel@nongnu.org, edgar.iglesias@gmail.com On 10/25/12 14:56, Peter Crosthwaite wrote: > On Thu, Oct 25, 2012 at 10:16 PM, Peter Maydell > wrote: >> On 25 October 2012 13:12, Gerd Hoffmann wrote: >>>> +static inline void zynq_init_usb(uint32_t base_addr, qemu_irq irq) >>>> +{ >>>> + DeviceState *dev = qdev_create(NULL, "ehci-sysbus"); >>> >>> I'd suggest to have a "ehci-sysbus-zynq" device instead which sets >>> capsbase & opregbase in ->init() ... >>> >>>> + qdev_prop_set_uint16(dev, "capabase", 0x100); >>>> + qdev_prop_set_uint32(dev, "opregbase", 0x140); >>> >>> ... then drop these lines. >> >> That sounds weird to me -- properties are exactly the mechanism >> for having a device which is configurable. Why have two differently >> named devices which only differ in the value of a configurable >> property? > 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. cheers, Gerd