Greg KH wrote:
On Mon, Oct 18, 2010 at 06:14:34PM -0700, Brett Rudley wrote:
-----Original Message-----
From: Greg KH [mailto:greg@xxxxxxxxx]
Sent: Monday, October 18, 2010 5:41 PM
To: Grant Grundler
Cc: Nohee Ko; devel@xxxxxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxx> 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.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
