[PATCH] staging:brcm80211:brcmfmac:add debugfs
greg at kroah.com
Mon Oct 18 17:41:10 PDT 2010
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
> 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
Nohee, am I totally wrong here?
More information about the devel