[PATCH v2] Move brcm80211 to mainline
zajec5 at gmail.com
Thu Aug 25 14:07:44 PDT 2011
2011/8/25 Jonas Gorski <jonas.gorski at gmail.com>:
> On 25 August 2011 02:20, Henry Ptasinski <henryp at broadcom.com> wrote:
>> On Wed, Aug 24, 2011 at 04:41:54PM -0700, Jonas Gorski wrote:
>>> Hi Henry,
>>> On 25 August 2011 00:28, Henry Ptasinski <henryp at broadcom.com> wrote:
>>> > With the latest series of cleanup patches merged in by Greg KH, I'd like to
>>> > once again propose moving brcm80211 out of staging and into mainline.
>>> While I like the Idea of brcm80211 going mainline, I'd like to throw
>>> in the suggestion that brcm80211 should be made a bcma/ssb driver
>>> first (AFACT brcmfmac would use ssb, not bcma, therefore both).
>>> My reasoning is that it needs to be done eventually anyway, and the
>>> earlier this is done the less work it will be in the long term, also
>>> it would reduce the duplicate code in bcma, ssb, and brcm80211.
>>> Of course this is just a suggestion, and it's yours and Greg's call
>>> whether you agree with me or not (since it's quite late in the game to
>>> add a new TODO, and I suspect a rather big one).
>> We started converting brcmsmac to bcma, but bcma is evolving rapidly in the
>> wireless-testing tree. Since wireless-testing and staging-next only get in
>> sync during a kernel merge, the version of bcma we have to work with in staging
>> is usually quit outdated. Unless Greg and John want to come up with a process
>> for keeping bcma consistent between their two repos, I don't really see how we
>> can productively use bcma until we cross over. We do intend to switch to using
>> bcma as soon as possible.
> Okay, then no objections from me. The keeping in sync is a valid
> reason. I'm looking forward to seeing your bcma patches :-)
>> I believe the only SB bus functions that brcmfmac uses are the core reset and
>> disable functions, and only when initializing the chip to download firmware
>> (all other management of the bus is handled by the on-chip CPU). Is it
>> possible to use those funtions from ssb, without the ssb module trying to
>> manage the bus?
> I haven't really looked at how much the brcmfmac driver uses ssb; I
> just saw s(s)b_* stuff in there and remembered that ssb supports SDIO
> host, so I assumed that there's part of the stack hidden in brcmfmac.
> But if it's only core reset and disable, then what Michael said
> applies ;-)
Still, is there any good reason for duplicating that code?
I think that it's not only about duplicating enable/disable/reset.
What about managing sliding window? Reading available cores? Clocks
management? Requesting & releasing device? Interrupts management?
About the code quality, short question: is the duplication of the code
done on purpose between dhd_siod.c and bcmsdh.c? Two identical
More information about the devel