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

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

 



2011/9/22 Arend Van Spriel <arend@xxxxxxxxxxxx>:
>> From: Rafał Miłecki [mailto:zajec5@xxxxxxxxx]
>> 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@xxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; linux-
>> wireless@xxxxxxxxxxxxxxx; jonas.gorski@xxxxxxxxx
>> 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@xxxxxxxxxxxx> napisał:
>> >> From: linux-wireless-owner@xxxxxxxxxxxxxxx [mailto:linux-wireless-
>> >> owner@xxxxxxxxxxxxxxx] 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@xxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; linux-
>> >> wireless@xxxxxxxxxxxxxxx
>> >> 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@xxxxxxxxxxxx> 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 ;-)
>>
>> 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.
>>
>> --
>> Rafał
>
> 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.).

-- 
Rafał
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux