[PATCH 00/20] staging: brcm80211: 7th reaction for mainline patch #2
Arend Van Spriel
arend at broadcom.com
Thu Sep 22 08:53:11 UTC 2011
> From: linux-wireless-owner at vger.kernel.org [mailto:linux-wireless-
> owner at vger.kernel.org] On Behalf Of Michael Büsch
> Sent: donderdag 22 september 2011 1:29
> To: Brett Rudley
> Cc: Rafał Miłecki; Greg KH; John W. Linville; Franky (Zhenhui) Lin;
> gregkh at suse.de; devel at linuxdriverproject.org; linux-
> wireless at vger.kernel.org
> Subject: Re: [PATCH 00/20] staging: brcm80211: 7th reaction for
> mainline patch #2
> On Wed, 21 Sep 2011 16:15:10 -0700
> "Brett Rudley" <brudley at broadcom.com> wrote:
> > We did however initially propose (and implement) a dividing line of
> ssb chips for b43 and AXI based chips for brcmsmac but b43 team chose
> to ignore/reject that.
> Well, what about embedded, for instance?
The brcmsmac driver has been tested on a MIPS platform by Jonas Gorski
although only in STA mode (on a bcm63xx). Not having AP mode has been
explained in other emails.
Also we fully intend to transition to BCMA but that would also be new
feature added. Having AP mode and BCMA would enable you guys for using
it in the embedded targets, right?
> > I'm not totally opposed to that idea but it does not solve the
> primary issue of conflicting b43 and brcmsmac modules.
> I'm not convinced that this is an issue at all and I'm not convinced
> that it has to be resolved.
> At least not now.
It never hurts to look ahead. Both drivers have their use in the linux
tree and we should align which driver is doing what. Apparently we should
have yelled really hard when b43 was adding bcma support, because then
it snatched the chipsets we support as well. You learn your lessons the
hard way in Linux land, or so it seems ;-)
More information about the devel