Re: 3945 driver using d80211

["Jouni Malinen" <jkm@devicescape.com>]

On Tue, Aug 08, 2006 at 02:27:37PM -0700, Mohamed Abbas wrote:

> 1- I needed to use sta_info_get function to do rate scaling for 3945, 
> although this function is exported but it was missing from d80211.h, for 
> work around I had to copy more header files to my driver's directory, It 
> this plan to add this function to d80211.h ?

sta_info_get() (and well, any access to struct sta_info) was not
designed to be available for the rate control modules. Could you please
provide some more details on what kind of information you would need
from there?

> 2- Scanning; in 3945 driver, we can not tune to other channels while we 
> are connected, this will cause a firmware error. The firmware provides a 
> scanning command we call so the firmware will take care of switching of 
> the available channels and gather beacons and probe responses. The 
> current d80211 the stack will call config callback to switch to 
> different channel and send the probe requests. One of our engineers did 
> come up with a patch to add one more callback function if provided the 
> d80211 will call this function to allow the registered driver to perform 
> the scanning functionalities. For work around I currently check inside 
> config callback if the scanning flag set I will issues the scan command 
> then ignore the next config callback.

If the hardware/firmware has such limitation, providing an alternative
mechanism for this is indeed needed. However, I though 3945 did not have
much firmware on it and I was not expecting this kind of requirement
from it (though, I have to admit that I'm not at all familiar with the
details of its design). Anyway, there are other wireless cards that will
need similar mechanism, so this is needed to support more "full mac"
type designs.

> 3- I can not access beacon's info from current associated AP. 
> information I need to callback into the firmware like timestamp and aid, 
> work around I would parse incoming management frame and filter beacon 
> from associated AP to get this info. This is a duplicate code that 
> d80211 stack doing, maybe there is away to get these info that I don’t 
> know of. Also it will be nice to have some callback function on 
> association, disassociation.

What kind of information/events do you need in the low-level hardware
driver? It sounds reasonable to add this kind of event callbacks.

> 4- I am been using the driver for sometime right now and it seems to be 
> stable and liable although I am using SMP system. I hearted of some SMP 
> issues in d80211 and I have the machine and time to help in this. Do you 
> have any test script the cause this SMP problems? Or steps to reproduce it.

I have heard of open claims on there being SMP issues, but I don't think
I've ever seen any details on this. I've also added a dual core laptop
to my testbed, so it will be interesting to see whether I can trigger
any of the issues easily.

-- 
Jouni Malinen                                            PGP id EFC895FA