[PATCH] staging:brcm80211:brcmfmac:add debugfs

[Greg KH]

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