linux.git/net/mac80211/work.c, branch v2.6.38 Linux kernel source tree Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 2010-12-17T20:27:22+00:00 David S. Miller davem@davemloft.net 2010-12-17T20:27:22+00:00 b4aa9e05a61b845541fa6f5b1d246976922601f0 Conflicts: drivers/net/bnx2x/bnx2x.h drivers/net/wireless/iwlwifi/iwl-1000.c drivers/net/wireless/iwlwifi/iwl-6000.c drivers/net/wireless/iwlwifi/iwl-core.h drivers/vhost/vhost.c 
Conflicts:
	drivers/net/bnx2x/bnx2x.h
	drivers/net/wireless/iwlwifi/iwl-1000.c
	drivers/net/wireless/iwlwifi/iwl-6000.c
	drivers/net/wireless/iwlwifi/iwl-core.h
	drivers/vhost/vhost.c
mac80211: avoid calling ieee80211_work_work unconditionally 2010-12-13T19:55:08+00:00 Herton Ronaldo Krzesinski herton@mandriva.com.br 2010-12-13T13:43:51+00:00 8808f64171deec62346888e156e3adb636e2a31a 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 <herton@mandriva.com.br> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
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 <herton@mandriva.com.br>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: Show max number of probe tries in debug message. 2010-12-08T20:38:44+00:00 Ben Greear greearb@candelatech.com 2010-12-07T19:27:01+00:00 2f886750118c1781d3b53268bf25519aef1d4d71 Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: implement off-channel mgmt TX 2010-11-29T20:24:35+00:00 Johannes Berg johannes.berg@intel.com 2010-11-25T09:02:30+00:00 f30221e4ec62d905b56d5e8f7ccab6b406a97cf5 This implements the new off-channel TX API in mac80211 with a new work item type. The operation doesn't add a new work item when we're on the right channel and there's no wait time so that for example p2p probe responses will be transmitted without delay. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
This implements the new off-channel TX API
in mac80211 with a new work item type. The
operation doesn't add a new work item when
we're on the right channel and there's no
wait time so that for example p2p probe
responses will be transmitted without delay.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: per interface idle notification 2010-08-16T19:26:40+00:00 Johannes Berg johannes.berg@intel.com 2010-08-05T15:02:38+00:00 7da7cc1d42d8ce02cca16df8c021e6d657f1f8fd 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 <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
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 <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: unify scan and work mutexes 2010-08-16T19:26:37+00:00 Johannes Berg johannes.berg@intel.com 2010-07-30T14:46:07+00:00 a1699b75a1db31a1da2f0fc610ee696d02a19280 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 <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
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 <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: allow drivers to request DTIM period 2010-07-29T16:55:00+00:00 Johannes Berg johannes.berg@intel.com 2010-07-29T14:08:55+00:00 e5b900d228b76d445a4240d9aeb3cd8f79205a91 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 <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
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 <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 2010-06-17T20:21:14+00:00 John W. Linville linville@tuxdriver.com 2010-06-17T20:21:14+00:00 abf52f86aa0a49a7377350cafa8f218c4cd227e7 Conflicts: net/mac80211/mlme.c 
Conflicts:
	net/mac80211/mlme.c
mac80211: fix warn, enum may be used uninitialized 2010-06-16T19:49:16+00:00 Christoph Fritz chf.fritz@googlemail.com 2010-06-16T14:37:34+00:00 021570e55b7152843376b9d9f60624e3e05ac054 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 <chf.fritz@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
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 <chf.fritz@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
wireless: fix several minor description typos 2010-06-02T20:13:18+00:00 Walter Goldens goldenstranger@yahoo.com 2010-05-18T11:44:54+00:00 77c2061d10a408d0220c2b0e7faefe52d9c41008 Signed-off-by: Walter Goldens <goldenstranger@yahoo.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
Signed-off-by: Walter Goldens <goldenstranger@yahoo.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>