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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
