linux.git/net/wireless/core.c, branch v2.6.32

headers: remove sched.h from interrupt.h

2009-10-11T18:20:58+00:00

After m68k's task_thread_info() doesn't refer to current,
it's possible to remove sched.h from interrupt.h and not break m68k!
Many thanks to Heiko Carstens for allowing this.

Signed-off-by: Alexey Dobriyan

cfg80211: clean up properly on interface type change

2009-08-28T18:40:31+00:00

When the interface type changes while connected, and the
driver does not require the interface to be down for a
type change, it is currently possible to get very strange
results unless the driver takes special care, which it
shouldn't have to.

To fix this, take care to disconnect/leave IBSS when
changing the interface type -- even if the driver may fail
the call. Also process all events that may be pending to
avoid running into a situation where an event is reported
but only processed after the type has already changed,
which would lead to missing events and warnings.

A side effect of this is that you will have disconnected
or left the IBSS even if the mode change ultimately fails,
but since the intention was to change it and thus leave or
disconnect, this is not a problem.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: check lost scans later, fix bug

2009-08-28T18:40:25+00:00

When we lose a scan, cfg80211 tries to clean up after
the driver. However, it currently does this too early,
it does this in GOING_DOWN already instead of DOWN, so
it may happen with mac80211. Besides fixing this, also
make it more robust by leaking the scan request so if
the driver later actually finishes the scan, it won't
crash. Also check in ___cfg80211_scan_done whether a
scan request is still pending and exit if not.

Reported-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Tested-by: Felix Fietkau 
Signed-off-by: John W. Linville

cfg80211: allow cfg80211_connect_result with bssid == NULL

2009-08-20T15:36:07+00:00

In case of connection failure, the bssid info is not a must have.

Signed-off-by: Zhu Yi 
Acked-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: fix dangling scan request checking

2009-08-20T15:36:05+00:00

My patch "cfg80211: fix deadlock" broke the code it
was supposed to fix, the scan request checking. But
it's not trivial to put it back the way it was, since
the original patch had a deadlock.

Now do it in a completely new way: queue the check
off to a work struct, where we can freely lock. But
that has some more complications, like needing to
wait for it to be done before the wiphy/rdev can be
destroyed, so some code is required to handle that.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: fix deadlock

2009-08-20T15:35:56+00:00

When removing an interface with nl80211, cfg80211 will
deadlock in the netdev notifier because we're already
holding rdev->mtx and try to acquire it again to verify
the scan has been done.

This bug was introduced by my patch
"cfg80211: check for and abort dangling scan requests".

To fix this, move the dangling scan request check into
wiphy_unregister(). This will not be able to catch all
cases right away, but if the scan problem happens with
a manual ifdown or so it will be possible to remedy it
by removing the module/device.

Additionally, add comments about the deadlock scenario.

Reported-by: Christian Lamparter 
Signed-off-by: Johannes Berg 
Tested-by: Christian Lamparter 
Tested-by: Kalle Valo 
Signed-off-by: John W. Linville

cfg80211: allow driver to override PS default

2009-08-14T13:14:08+00:00

Sometimes drivers might have a good reason to override
the PS default, like iwlwifi right now where it affects
RX performance significantly at this point. This will
allow them to override the default, if desired, in a
way that users can still change it according to their
trade-off choices, not the driver's, like would happen
if the driver just disabled PS completely then.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: check for and abort dangling scan requests

2009-08-14T13:14:07+00:00

If you trigger a scan request on an interface and then
take it down, or rmmod the module or unplug the device
the driver might "forget" to cancel the scan request.
That is a bug in the driver, but the current behaviour
is that we just hang endlessly waiting for the netdev
refcount to become 0 which it never will. To improve
robustness, check for this situation in cfg80211, warn
about it and clean up behind the driver. I don't just
clean up silently because it's likely that the driver
also has some internal state it has now leaked.

Additionally, this fixes a locking bug, clearing the
scan_req pointer should be done under the rdev lock.

Finally, we also need to _wait_ for the scan work and
not just abort it since it might be pending and wanting
to do a cleanup.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: add missing device list locking

2009-08-14T13:13:54+00:00

When calling into the wext code from the NETDEV_UP
notifier, we need to hold the devlist_mtx mutex as
the wext code ends up calling into channel checks.

Reported-by: Kalle Valo 
Signed-off-by: Johannes Berg 
Tested-by: Kalle Valo 
Signed-off-by: John W. Linville

nl80211: add generation number to all dumps

2009-08-14T13:13:43+00:00

In order for userspace to be able to figure out whether
it obtained a consistent snapshot of data or not when
using netlink dumps, we need to have a generation number
in each dump message that indicates whether the list has
changed or not -- its value is arbitrary.

This patch adds such a number to all dumps, this needs
some mac80211 involvement to keep track of a generation
number to start with when adding/removing mesh paths or
stations.

The wiphy and netdev lists can be fully handled within
cfg80211, of course, but generation numbers need to be
stored there as well.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville