Re: [PATCH v2] Move brcm80211 to mainline

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

 



W dniu 25 sierpnia 2011 23:07 użytkownik Rafał Miłecki
<zajec5@xxxxxxxxx> napisał:
> 2011/8/25 Jonas Gorski <jonas.gorski@xxxxxxxxx>:
>> Hi,
>>
>> On 25 August 2011 02:20, Henry Ptasinski <henryp@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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?

Also what about embedded devices? Shouldn't we have core drivers for
them? I mean, to be able to easily choose driver for a given core?

Let's say I want to use some ssb-core-based driver for Ethernet port
(like gige) but I also want to use brcmsmac fo 80211. Is that possible
without brcmsmac using bcma?

-- 
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