Re: Dscape ieee80211: enabling/disabling the radio

[Ivo van Doorn <ivdoorn@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3171 bytes --]

> While working on the rt2x00 driver, I keep hitting against some problems with scanning.
> Basicly the dscape stack handles scanning in 2 ways, through the
> passive_scan() handler in the ieee80211_hw structure, and by calling
> the config() handler in the ieee80211_hw stucture.
> 
> The usage of the first handler, does not give any problems at this time.
> The main source of problems during scanning in rt2x00 seems to come
> when the config() handler is used.
> 
> In rt2x00 the config() handler schedules all configuration changes by using a workqueue,
> this is required since several configuration changes in rt2x00 need sleeping and for
> USB devices all register access requires sleeping. And the config() handler is often
> called from interrupt context so it complains a lot when the workqueue is not used.
> 
> This seemed fine, untill the radio_enabled field was introduced to the configuration structure.
> When the radio_enable field is set, the radio must be enabled, but enabling
> the radio is something that can (at least in rt2x00) fail. So scheduling the enabling of the radio
> to the workqueue is not something that is desired since the stack can not be notified that the
> device is not able to enable the radio.
> 
> Moving the enabling of the radio outside the workqueue function and into the config()
> handler results in scheduling while atomic issues since the enabling of the radio requires
> sleeping for both PCI and USB devices.
> 
> Instead of using a config field radio_enabled, wouldn't it be better to add 2 handlers
> to the ieee80211_hw structure, something like enable_radio() and disable_radio()?
> If these functions are called from normal context the dscape stack can still enable
> and disable the radio whenever it is desired, and it is able to check the return value
> to see if the request has actually succeeded.
> 
> What I am wondering about afterwards is what exactly should happen when the open()
> and stop() handlers are being called? Because those are basicly intented to enable
> and stop the radio as well. I checked bcm43xx to see what they do, and they don't seem
> to check the radio_enabled field, so I don't know what they do besides enabling the radio.
> 
> Well this was just some stuff I have been trying to figure out while trying to solve several
> rt2x00 bugs... ;)

A user on the forums Olivier Cornu (added to the CC list) has done some investigation into the
scanning behaviour of the dscape stack.
Basicly the dscape stack is performing active scanning while the device is down,
but during the active scan it is sending packets out, or at least attempting to do so.
Besides the question if active scanning is preferred over passive scanning while interface is down,
active scanning fails because the packets that should be send are being send through the regular
xmit routines of the interface. (IFF_UP is not set for the interface)

This means that besides enabling the radio which should be done in the driver, the stack should either bring
up the interface when doing an active scan, or resort to passive scanning while interface is down.

Ivo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]