[PATCH 00/20] staging: brcm80211: 7th reaction for mainline patch #2
zajec5 at gmail.com
Thu Sep 22 02:12:41 PDT 2011
2011/9/22 Arend Van Spriel <arend at broadcom.com>:
>> From: Rafał Miłecki [mailto:zajec5 at gmail.com]
>> Sent: donderdag 22 september 2011 10:57
>> To: Arend Van Spriel
>> Cc: Michael Büsch; Brett Rudley; Greg KH; John W. Linville; Franky
>> (Zhenhui) Lin; gregkh at suse.de; devel at linuxdriverproject.org; linux-
>> wireless at vger.kernel.org; jonas.gorski at gmail.com
>> Subject: Re: [PATCH 00/20] staging: brcm80211: 7th reaction for
>> mainline patch #2
>> W dniu 22 września 2011 10:53 użytkownik Arend Van Spriel
>> <arend at broadcom.com> napisał:
>> >> 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
>> >> ssb chips for b43 and AXI based chips for brcmsmac but b43 team
>> >> to ignore/reject that.
>> >> Well, what about embedded, for instance?
>> > The brcmsmac driver has been tested on a MIPS platform by Jonas
>> > 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
>> > 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
>> > tree and we should align which driver is doing what. Apparently we
>> > have yelled really hard when b43 was adding bcma support, because
>> > it snatched the chipsets we support as well. You learn your lessons
>> > hard way in Linux land, or so it seems ;-)
>> And I should have notice you add code for N-PHY with your initial
>> brcm80211 commit ;) There's always something that you won't notice at
>> the correct time.
> Were you unaware of the chipsets that brcmsmac was supporting? When you
> Were working on N-PHY it was to enable certain chipsets, right? Was that
> in ssb context?
I was aware of supported chipsets (by their names), but I got no idea
that they (BCM43224 and BCM43225) are N-PHY based ones. I though that
that are some totally new PHYs (like SSLPN/HT/LCN/LCNXN/etc.).
More information about the devel