Am 30.10.2012 09:24, schrieb Peter Crosthwaite: > On Tue, Oct 30, 2012 at 5:20 PM, Gerd Hoffmann <[email protected]> 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
