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

["Andreas Färber" <afaerber@suse.de>]

Am 30.10.2012 09:24, schrieb Peter Crosthwaite:
> On Tue, Oct 30, 2012 at 5:20 PM, Gerd Hoffmann <kraxel@redhat.com> 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.

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.

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


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg