On Tue, Oct 19, 2010 at 3:14 AM, Brett Rudley <brudley@xxxxxxxxxxxx> 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?) See libertas and libertas_tf for an example. > > 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 > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
