diff options
author | Johannes Berg <johannes.berg@intel.com> | 2010-06-10 10:21:29 +0200 |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2010-06-14 15:38:16 -0400 |
commit | 2a419056c15478d2df3f3e9d4fa64e34eb1faa7d (patch) | |
tree | 680342d6b883c18eec9003f2b93abd8ffd1e6ae6 /include/media | |
parent | 9d38d85de0270e3927bffab94973a9c78d1dc800 (diff) | |
download | talos-op-linux-2a419056c15478d2df3f3e9d4fa64e34eb1faa7d.tar.gz talos-op-linux-2a419056c15478d2df3f3e9d4fa64e34eb1faa7d.zip |
mac80211: simplify station/aggregation code
A number of places use RCU locking for accessing
the station list, even though they do not need
to. Use mutex locking instead to prepare for the
locking changes I want to make. The mlme code is
also using a WLAN_STA_DISASSOC flag that has the
same meaning as WLAN_STA_BLOCK_BA, so use that.
While doing so, combine places where we loop
over stations twice, and optimise away some of
the loops by checking if the hardware supports
aggregation at all first.
Also fix a more theoretical race condition: right
now we could resume, set up an aggregation session,
and right after tear it down again due to the code
that is needed for hardware reconfiguration here.
Also mark add a comment to that code marking it as
a workaround.
Finally, remove a pointless aggregation disabling
loop when an interface is stopped, directly after
that we remove all stations from it which will also
disable all aggregation sessions that may still be
active, and does so in a race-free way unlike the
current loop that doesn't block new sessions.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'include/media')
0 files changed, 0 insertions, 0 deletions