RE: [PATCH 00/20] staging: brcm80211: 7th reaction for mainline patch #2

> On Tue, Sep 20, 2011 at 09:22:03AM -0400, John W. Linville wrote:
> > On Tue, Sep 20, 2011 at 06:03:38AM -0700, Greg KH wrote:
> > > On Mon, Sep 19, 2011 at 02:25:48PM -0700, Franky Lin wrote:
> > > > Code clean up for fullmac.
> > >
> > > Ok, this is the 7th patch series since the last round of "how do we
> get
> > > our driver into mainline" happened.
> > >
> > > And while code is great and nice, I still haven't seen any real
> answers
> > > to all of the questions that were asked of the Broadcom driver team
> > > during that review by the linux-wireless developers about how things
> > > will be handled properly due to the overlap in functionality with the
> > > existing "real" driver in the tree.
> > >
> > > So, can you please start answering these questions?  I'm loath to
> keep
> > > accepting patches until that all gets straightened out as it
> potentially
> > > wastes my, and your, time by doing so.
> > >
> > > In other words, I'm not going to apply any more patches until this
> gets
> > > resolved.  Consider this patchset dropped from my to-apply queue for
> now
> > > because of that.
> >
> > I think most of the outstanding series from Broadcom are
> > (almost?) exclusively for their fullmac driver, which has not overlap
> > with b43.  We should be moving forward toward getting the fullmac
> > driver into wireless-next.
> 
> Ok, that's great, but again, no one from Broadcom has said what their
> plans are, only sent lots of patches, which while wonderful, has caused
> some confusion on my and other parts.
> 
> greg k-h

Our original plan was to remain a separate driver from b43. We were aware of
it and all the good work that had been done to create it and we had no
intention of interfering with it.  At that point there had not been very much
recent movement in b43 and it did not support any of our AXI based chips.  We
figured that ssb vs AXI was a good dividing line and there would be no
conflict, and there wasn't initially.

Internally, prior to releasing to staging tree, development had gone quickly
and it didn't take long at all to get the driver up and running.  We did not
anticipate that things would go somewhat slower in the staging tree and a
year (and hundreds of patches) later we are still there.  During that year
b43 got some limited support for the same new chips brcmsmac already had,
into its driver.  So now, here we are... both drivers supporting the new
chips and b43 also supporting the old.  

We have seen the requests for us to add AXI based chipset support into b43.
I don't think that will happen in a substantial way:
- Our driver is already stable and performance is better than b43 in terms of
AXI chips.  B43 seems quite raw: its full of TODO and FIXME notes and
performance is 1/10th of brcmsmac on our testing. Spending another round of
time and effort on b43 to get it to the place where smac already is, seems
redundant and unattractive. 

- Much of brcmsmac code comes from our internal source which has whole
organizations charged with testing it for compliance, compatibility,
performance, etc. We understand that that is of no direct consequence but
since brcmsmac code is a direct descendent of that code, much of that
background still applies. Switching to b43 would mean throwing all that
infrastructure and testing away and going with a driver that has none of that
(that I know of).

- Most of the recent b43 additions support comes from a single person doing
reverse engineering. brcmsmac has a few software people working on it
directly and hundreds of people working on it indirectly (through the
internal version) including engineers working on firmware, RTL, testing, etc.

- B43 team has made the case several times that it has more features than
brcmsmac.  A reminder: We were specifically asked NOT to add features while
in staging tree and we have held back on features to honor that request.  AP,
IBSS, 40 Mhz, using bcma, hw crypto and others, are all features we have been
waiting to do.   We also have a backlog of several new chips we want to add.
And of course, we will would be adding future chips and features as they come
out.

We invested a year trying to be good Linux citizens, laying out our initial
plans, following the rules, working transparently, folding in feedback,
submitting hundreds of patches in plain sight of everyone and now folks are
asking about our plan.  Our plan is get the brcmsmac and brcmfmac into
mainline and keep following that up with new features, new chips and
continuing support.

Other than barely supporting one of our chips first in mainline, I would
really like to understand what are the benefits and justifications of using
b43 over brcmsmac for AXI based chips in the long run.  Can someone explain
them?


Brett


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html