Search Linux Wireless

Re: [RFC][PATCH] ssb: separate common scanning functions

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

 



> 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


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux