Re: [PATCH] staging:brcm80211:brcmfmac:add debugfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux