qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 0/8] Sysbus EHCI + Zynq USB.


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v1 0/8] Sysbus EHCI + Zynq USB.
Date: Tue, 30 Oct 2012 18:24:10 +1000

On Tue, Oct 30, 2012 at 5:20 PM, Gerd Hoffmann <address@hidden> wrote:
> 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 of
>> 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).
>

Hi Gerd,

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.

Andreas, Anthony,

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.

Regards,
Peter

> 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
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]