On Tue, Oct 30, 2012 at 5:20 PM, Gerd Hoffmann <kra...@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. 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 > >