> -----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?) We'd love to hear any ideas on how we can go about that (without completely rewriting the drivers) Thanks Brett _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
