> 2011/3/18 George Kashperko <george@xxxxxxxxxxx>: > >> 2011/3/18 George Kashperko <george@xxxxxxxxxxx>: > >> > Current ssb code ideology isn't really good place to start with support > >> > for ai backplanes. Its really great to see you willing to get ai > >> > supported in mainline but I'm sure this should be done apart from the > >> > ssb code and not even with one as the design decisions origin. Several > >> > concepts the ssb is based on are not designed to support anything else > >> > than ocp/sb and will require workarounds to suport ai. > >> > Thanks to Michael I had a time to think over the possibly code > >> > abstraction for shared sb and ai support. And while I'm still sure the > >> > patchwork for ai over ssb support is of good use as some intermediate > >> > decision to support ai-based hardware in sertain distributions but now I > >> > support Michael in that such (hopefully) a temporary buildups should not > >> > be in mainline. > >> > >> Please, give some concrete arguments, which part of design does not match AI. > > SSB design is core-centric, where all the bus activities are made in > > regard to the cores. This mostly is correct as most of the time > > bus/drivers code work with cores. > > So finally, is there anything wrong about that? Nothing wrong as soon as technically imperfect solution is not intended to be in mainline :) Otherwise my latest AI RFC already ready to merge. > >> My patch has shown we need to duplicate 40% of SSB's scanning code. > >> What for example about pci.c? Which functions from that file won't be > >> duplicated in totally separated? > >> > > Going further in extending ssb to support ai will either require the > > host to be confident of the backplane type and layout (see > > drivers/staging/brcm80211/utils for the good example of messup it will > > lead to) or will reguire the backplane-specific code to break into the > > host code (brcm80211/utils again). > > I don't want to extend ssb, I said that with my patch message. I > wanted separated drivers sharing some functions, please take a look at > my comment included in patch. I think we could also create *separated* > host drivers sharing most of the code. My english is awful therefore seems we missunderstood each other. I'm sure I got your point right - you plan to start up the new (bcmb) project for both sb and ai support. My point here is - this is great but making design decisions on ssb code model is wrong. Have nice day, George -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html