kernel.git/net/mac80211/work.c, branch linux-2.6.37.y

mac80211: avoid calling ieee80211_work_work unconditionally

2010-12-13T19:55:08Z

On suspend, there might be usb wireless drivers which wrongly trigger the warning in ieee80211_work_work. If an usb driver doesn't have a suspend hook, the usb stack will disconnect the device. On disconnect, a mac80211 driver calls ieee80211_unregister_hw, which calls dev_close, which calls ieee80211_stop, and in the end calls ieee80211_work_purge-> ieee80211_work_work. The problem is that this call to ieee80211_work_purge comes after mac80211 is suspended, triggering the warning even when we don't have work queued in work_list (the expected case when already suspended), because it always calls ieee80211_work_work. So, just call ieee80211_work_work in ieee80211_work_purge if we really have to abort work. This addresses the warning reported at https://bugzilla.kernel.org/show_bug.cgi?id=24402 Signed-off-by: Herton Ronaldo Krzesinski Signed-off-by: John W. Linville

mac80211: per interface idle notification

2010-08-16T19:26:40Z

Sometimes we don't just need to know whether or not the device is idle, but also per interface. This adds that reporting capability to mac80211. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

mac80211: unify scan and work mutexes

2010-08-16T19:26:37Z

Having both scan and work mutexes is not just a bit too fine grained, it also creates issues when there's code that needs both since they then need to be acquired in the right order, which can be hard to do. Therefore, use just a single mutex for both. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

mac80211: allow drivers to request DTIM period

2010-07-29T16:55:00Z

Some features require knowing the DTIM period before associating. This implements the ability to wait for a beacon in mac80211 before assoc to provide this value. It is optional since most likely not all drivers will need this. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6

2010-06-17T20:21:14Z

Conflicts: net/mac80211/mlme.c

mac80211: fix warn, enum may be used uninitialized

2010-06-16T19:49:16Z

regression introduced by b8d92c9c141ee3dc9b3537b1f0ffb4a54ea8d9b2 In function ‘ieee80211_work_rx_queued_mgmt’: warning: ‘rma’ may be used uninitialized in this function this re-adds default value WORK_ACT_NONE back to rma Signed-off-by: Christoph Fritz Signed-off-by: John W. Linville

wireless: fix several minor description typos

2010-06-02T20:13:18Z

Signed-off-by: Walter Goldens Signed-off-by: John W. Linville

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem

2010-05-17T17:57:43Z

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6

2010-05-17T17:31:05Z

mac80211: don't process work item with wrong frame

2010-05-12T20:28:52Z

When we process a frame, we currently just match it to the work struct by the MAC addresses, and not by the work type. This means that we can end up doing the work for an association request item when (for whatever reason) we receive another frame type, for example a probe response. Processing the wrong type of frame will lead to completely invalid data being processed, and will lead to various problems like thinking the association was successful even if the AP never sent an assocation response. Fix this by making each processing function check that it is invoked for the right work struct type only and continue processing otherwise (and drop frames that we didn't expect). This bug was uncovered during the debugging for https://bugzilla.kernel.org/show_bug.cgi?id=15862 but doesn't seem to be the cause for any of the various problems reported there. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville