From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTAi1-0003Ml-U2 for qemu-devel@nongnu.org; Tue, 30 Oct 2012 08:14:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTAhz-0003Id-NA for qemu-devel@nongnu.org; Tue, 30 Oct 2012 08:14:17 -0400 Received: from cantor2.suse.de ([195.135.220.15]:51168 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTAhz-0003Hs-Ca for qemu-devel@nongnu.org; Tue, 30 Oct 2012 08:14:15 -0400 Message-ID: <508FC48A.4080502@suse.de> Date: Tue, 30 Oct 2012 13:14:02 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <508F7FC6.1060608@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v1 0/8] Sysbus EHCI + Zynq USB. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: vineshp@xilinx.com, peter.maydell@linaro.org, Anthony Liguori , qemu-devel@nongnu.org, john.williams@xilinx.com, Gerd Hoffmann , edgar.iglesias@gmail.com Am 30.10.2012 09:24, schrieb Peter Crosthwaite: > On Tue, Oct 30, 2012 at 5:20 PM, Gerd Hoffmann wrot= e: >> On 10/29/12 15:08, Peter Crosthwaite wrote: >>> Ping! >>> >>> This is the first version of the EHCI sysbus series which takes a >>> property based approach rather than the dynamic class approach. >>> >>> No refactoring of the PCI stuff is done here (introduced v2) but >>> following on from the discussion on IRC about how to do and the >>> suggestion we take a property based approach, could we get a review o= f >>> this and mix and match between this and V3 for the solution? >> >> I like the EHCI{Pci,Sysbus}State approach in the v3 series, also the >> sysbus restruction so sysbus_create_simple() can be used in v2+. >> >> I'd suggest to drop all the controversial stuff: >> >> - v3 patch #1 (go with NULL like ohci does for the time being, >> when we finally figured+agreed on how to fix it we can change >> both ehci+ohci). >> - v3 patch #2 (class_data for pci). >> >=20 > Hi Gerd, >=20 > Its difficult to drop this patch, as it defines struct EHCIPCIClass > which is needed to hold the capabase and opregbase properties > introduced later. If the only objection is the class_data then I can > revert to the old code driven approach with separate class_init fns > for each, but if this inheritance heirachy I have set up and the way > the properties are handled is under debate (which after IRC discussion > last night they were) then we are blocked. The key distinction from > UHCI is that there are EHCI specific props that we want to pass > through which means the definition of a new class EHCIPCIClass, which > is the point debate. There was disagreement on that. I think the > class_data was the secondary issue in the end. >=20 > Andreas, Anthony, >=20 > Can we get a decisive action plan here even if its just "do It > Andreas' way" - I dont mind fixing it, its just there were multiple > solutions kicked around and no agreement reached, so at the moment > whatever I do from here it appears one maintainer or the other is > going to block. Last I read Anthony was pro device properties, which > is close to v1 of the series, Andreas was against it, with proposed > modifications to the Class heirachy set up by v3 of the series - > mostly organsiational nothing fundamental. Erm, I'm not against properties, I just doubted it would work in the described scenario, but Anthony said there were some magic that would make it work. If it works overridably, then fine with me! What I am strongly against was the union parent approach, and in the last iteration I requested some formal cleanups / patch minimizations (not yet fully reviewed, /me cooking up a CPU pull). Cheers, Andreas P.S. Thanks for digging out the SDHCI series; I rebased that on my end and was about to ask. >=20 > Regards, > Peter >=20 >> With patch #2 being gone patch #6 needs to be changed too of course. >> Just do it the classic way for now and lets worry later about how to >> dynamically generate variants. >> >> Have you tested the patch for the unmapped-register access I've sent? >> >> cheers, >> Gerd >> >> --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg