[PATCH] staging:brcm80211:brcmfmac:add debugfs

[jason]

Greg KH wrote:
> On Mon, Oct 18, 2010 at 06:14:34PM -0700, Brett Rudley wrote:
>>> -----Original Message-----
>>> From: Greg KH [mailto:greg at kroah.com]
>>> Sent: Monday, October 18, 2010 5:41 PM
>>> To: Grant Grundler
>>> Cc: Nohee Ko; devel at linuxdriverproject.org; Henry Ptasinski; Brett
>>> Rudley; Venkat Rao
>>> Subject: Re: [PATCH] staging:brcm80211:brcmfmac:add debugfs
>>>
>>> On Mon, Oct 18, 2010 at 11:36:12AM -0700, Grant Grundler wrote:
>>>> On Mon, Oct 18, 2010 at 7:08 AM, Greg KH <greg at kroah.com> wrote:
>>>>> On Sun, Oct 17, 2010 at 03:10:33PM -0700, Grant Grundler wrote:
>>>>>> ...
>>>>>>> In short, I think you mixed a few different things in this patch.
>>>>>>>
>>>>>>> Please break it up into logical steps, one perhaps adding some new
>>>>>>> infrastructure that you will then, in a later patch, expose using
>>>>>>> debugfs.
>>>>>>>
>>>>>>> It should be two patches at the very least, possibly three, right?
>>>>>> Here's what I see...please suggest something different if you think
>>>>>> I've missed something:
>>>>>> 1) clean up use of active_scan in wl_do_iscan()/__wl_cfg80211_scan
>>>>>> 2) add DEBUGFS support equivalent to what mac80211 provides.
>>>>> Um, no, how about:
>>>>> ?? ?? ?? ??2) move the driver to use the mac80211 layer
>>>>>
>>>>> Don't try to emulate the existing core debugfs functionality, it will
>>> be
>>>>> a constantly loosing proposition of keeping it in sync. ??As the
>>> driver
>>>>> needs to be moved to us the layer in order to get out of the staging
>>>>> tree, might as well work on that first, right?
>>>> No. The point of this device is it provides the same functionality as
>>>> mac80211 but in device firmware instead of in OS SW. This is
>>>> comparable to other forms of offload (and has similar issues - people
>>>> may not always be able to use offloaded functionality.)
>>> Ah, ok, that makes sense, much like the other full-mac drivers in the
>>> kernel today?
>>>
>>>> My understanding was the brcm80211 driver would eventually support the
>>>> same HW and people could chose if they wanted to use kernel mac80211
>>>> or device MAC support by using a different driver.
>>> No, I do not think that is the issue at all here.  They seem to both
>>> work on different types of hardware, not for the same type of device at
>>> all.
>>>
>>> Nohee, am I totally wrong here?
>>>
>>> thanks,
>>>
>>> greg k-h
>> Yes we can run a some chips with either fullmac or softmac driver
>> models (using our splitmac bmac driver model.  This is what the
>> HIGH_ONLY, LOW, etc #defines sprinkled around the code are all about.
>> Its also another reason there seems to be so many layers of code in
>> our driver.  
>>
>> Currently, we have only released the 4329 fullmac driver.  The 4329
>> can also run as a softmac running under mac80211 using the bmac
>> driver.
>>
>> But we haven't released much bmac code yet, primarily because
>> weren't/aren't sure how to support multiple drivers for a single chip.
>> (Basically, which driver should get loaded?)
> 

I would suggest releasing it as staging/brcm80211/bmac, and initially, allow all three drivers to be compiled as modules.  Then, have a test on module load as to whether the device is claimed or not.  Most people will blacklist the one they don't want, and the kernel will autoload the other (eg madwifi/ath5k).

I'd say in 90%+ scenarios, folks only have one wifi chipset, so there is only one device to worry about.  There most likely won't be a scenario where two Broadcom drivers need to be loaded for two different chipsets.  The remaining 10% know they have a weird setup and are (should be) prepared to deal with that, and submit patches. ;-)

> Why would you ever want to do that?  Why wouldn't you just use softmac
> like other wireless drivers in the kernel?
> 
> You are going to have to make a choice here, and drop one of them for
> this driver.  Keeping both is crazy, as you are finding out :)
> 

Agreed.  I vote softmac.

thx,

Jason.