UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/net/mac80211/chan.c

734 lines
19 KiB
C
Raw Normal View History

cfg80211/mac80211: better channel handling Currently (all tested with hwsim) you can do stupid things like setting up an AP on a certain channel, then adding another virtual interface and making that associate on another channel -- this will make the beaconing to move channel but obviously without the necessary IEs data update. In order to improve this situation, first make the configuration APIs (cfg80211 and nl80211) aware of multi-channel operation -- we'll eventually need that in the future anyway. There's one userland API change and one API addition. The API change is that now SET_WIPHY must be called with virtual interface index rather than only wiphy index in order to take effect for that interface -- luckily all current users (hostapd) do that. For monitor interfaces, the old setting is preserved, but monitors are always slaved to other devices anyway so no guarantees. The second userland API change is the introduction of a per virtual interface SET_CHANNEL command, that hostapd should use going forward to make it easier to understand what's going on (it can automatically detect a kernel with this command). Other than mac80211, no existing cfg80211 drivers are affected by this change because they only allow a single virtual interface. mac80211, however, now needs to be aware that the channel settings are per interface now, and needs to disallow (for now) real multi-channel operation, which is another important part of this patch. One of the immediate benefits is that you can now start hostapd to operate on a hardware that already has a connection on another virtual interface, as long as you specify the same channel. Note that two things are left unhandled (this is an improvement -- not a complete fix): * different HT/no-HT modes currently you could start an HT AP and then connect to a non-HT network on the same channel which would configure the hardware for no HT; that can be fixed fairly easily * CSA An AP we're connected to on a virtual interface might indicate switching channels, and in that case we would follow it, regardless of how many other interfaces are operating; this requires more effort to fix but is pretty rare after all Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:25:02 +08:00
/*
* mac80211 - channel management
*/
mac80211: improve HT channel handling Currently, when one interface switches HT mode, all others will follow along. This is clearly undesirable, since the new one might switch to no-HT while another one is operating in HT. Address this issue by keeping track of the HT mode per interface, and allowing only changes that are compatible, i.e. switching into HT40+ is not possible when another interface is in HT40-, in that case the second one needs to fall back to HT20. Also, to allow drivers to know what's going on, store the per-interface HT mode (channel type) in the virtual interface's bss_conf. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:28:27 +08:00
#include <linux/nl80211.h>
mac80211: add channel context iterator Drivers may need to iterate the active channel contexts, export an iterator function to allow that. To make it possible, use RCU-safe list functions. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 23:57:42 +08:00
#include <linux/export.h>
mac80211: assign VLAN channel contexts Make AP_VLAN type interfaces track the AP master channel context so they have one assigned for the various lookups. Don't give them their own refcount etc. since they're just slaves to the AP master. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-12-12 03:38:41 +08:00
#include <linux/rtnetlink.h>
mac80211: Don't let regulatory make us deaf When regulatory information changes our HT behavior (e.g, when we get a country code from the AP we have just associated with), we should use this information to change the power with which we transmit, and what channels we transmit. Sometimes the channel parameters we derive from regulatory information contradicts the parameters we used in association. For example, we could have associated specifying HT40, but the regulatory rules we apply may forbid HT40 operation. In the situation above, we should reconfigure ourselves to transmit in HT20 only, however it makes no sense for us to disable receive in HT40, since if we associated with these parameters, the AP has every reason to expect we can and will receive packets this way. The code in mac80211 does not have the capability of sending the appropriate action frames to signal a change in HT behaviour so the AP has no clue we can no longer receive frames encoded this way. In some broken AP implementations, this can leave us effectively deaf if the AP never retries in lower HT rates. This change breaks up the channel_type parameter in the ieee80211_enable_ht function into a separate receive and transmit part. It honors the channel flags set by regulatory in order to configure the rate control algorithm, but uses the capability flags to configure the channel on the radio, since these were used in association to set the AP's transmit rate. Signed-off-by: Paul Stewart <pstew@chromium.org> Cc: Sam Leffler <sleffler@chromium.org> Cc: Johannes Berg <johannes@sipsolutions.net> Reviewed-by: Luis R Rodriguez <mcgrof@frijolero.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-03-13 22:46:18 +08:00
#include <net/cfg80211.h>
cfg80211/mac80211: better channel handling Currently (all tested with hwsim) you can do stupid things like setting up an AP on a certain channel, then adding another virtual interface and making that associate on another channel -- this will make the beaconing to move channel but obviously without the necessary IEs data update. In order to improve this situation, first make the configuration APIs (cfg80211 and nl80211) aware of multi-channel operation -- we'll eventually need that in the future anyway. There's one userland API change and one API addition. The API change is that now SET_WIPHY must be called with virtual interface index rather than only wiphy index in order to take effect for that interface -- luckily all current users (hostapd) do that. For monitor interfaces, the old setting is preserved, but monitors are always slaved to other devices anyway so no guarantees. The second userland API change is the introduction of a per virtual interface SET_CHANNEL command, that hostapd should use going forward to make it easier to understand what's going on (it can automatically detect a kernel with this command). Other than mac80211, no existing cfg80211 drivers are affected by this change because they only allow a single virtual interface. mac80211, however, now needs to be aware that the channel settings are per interface now, and needs to disallow (for now) real multi-channel operation, which is another important part of this patch. One of the immediate benefits is that you can now start hostapd to operate on a hardware that already has a connection on another virtual interface, as long as you specify the same channel. Note that two things are left unhandled (this is an improvement -- not a complete fix): * different HT/no-HT modes currently you could start an HT AP and then connect to a non-HT network on the same channel which would configure the hardware for no HT; that can be fixed fairly easily * CSA An AP we're connected to on a virtual interface might indicate switching channels, and in that case we would follow it, regardless of how many other interfaces are operating; this requires more effort to fix but is pretty rare after all Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:25:02 +08:00
#include "ieee80211_i.h"
mac80211: use channel context notifications Channel context pointer will be accessible on both assign and unassign events. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:20 +08:00
#include "driver-ops.h"
cfg80211/mac80211: better channel handling Currently (all tested with hwsim) you can do stupid things like setting up an AP on a certain channel, then adding another virtual interface and making that associate on another channel -- this will make the beaconing to move channel but obviously without the necessary IEs data update. In order to improve this situation, first make the configuration APIs (cfg80211 and nl80211) aware of multi-channel operation -- we'll eventually need that in the future anyway. There's one userland API change and one API addition. The API change is that now SET_WIPHY must be called with virtual interface index rather than only wiphy index in order to take effect for that interface -- luckily all current users (hostapd) do that. For monitor interfaces, the old setting is preserved, but monitors are always slaved to other devices anyway so no guarantees. The second userland API change is the introduction of a per virtual interface SET_CHANNEL command, that hostapd should use going forward to make it easier to understand what's going on (it can automatically detect a kernel with this command). Other than mac80211, no existing cfg80211 drivers are affected by this change because they only allow a single virtual interface. mac80211, however, now needs to be aware that the channel settings are per interface now, and needs to disallow (for now) real multi-channel operation, which is another important part of this patch. One of the immediate benefits is that you can now start hostapd to operate on a hardware that already has a connection on another virtual interface, as long as you specify the same channel. Note that two things are left unhandled (this is an improvement -- not a complete fix): * different HT/no-HT modes currently you could start an HT AP and then connect to a non-HT network on the same channel which would configure the hardware for no HT; that can be fixed fairly easily * CSA An AP we're connected to on a virtual interface might indicate switching channels, and in that case we would follow it, regardless of how many other interfaces are operating; this requires more effort to fix but is pretty rare after all Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:25:02 +08:00
mac80211: add min required channel definition field Add a new field to ieee80211_chanctx_conf to indicate the min required channel configuration. Tuning to a narrower channel might help reducing the noise level and saving some power. The min required channel definition is the max of all min required channel definitions of the interfaces bound to this channel context. In AP mode, use 20MHz when there are no connected station. When a new station is added/removed, calculate the new max bandwidth supported by any of the stations (e.g. 80MHz when 80MHz and 40MHz stations are connected). In other cases, simply use bss_conf.chandef as the min required chandef. Notify drivers about changes to this field by calling drv_change_chanctx with a new CHANGE_MIN_WIDTH notification. Signed-off-by: Eliad Peller <eliad@wizery.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-12 02:14:01 +08:00
static enum nl80211_chan_width ieee80211_get_sta_bw(struct ieee80211_sta *sta)
{
switch (sta->bandwidth) {
case IEEE80211_STA_RX_BW_20:
if (sta->ht_cap.ht_supported)
return NL80211_CHAN_WIDTH_20;
else
return NL80211_CHAN_WIDTH_20_NOHT;
case IEEE80211_STA_RX_BW_40:
return NL80211_CHAN_WIDTH_40;
case IEEE80211_STA_RX_BW_80:
return NL80211_CHAN_WIDTH_80;
case IEEE80211_STA_RX_BW_160:
/*
* This applied for both 160 and 80+80. since we use
* the returned value to consider degradation of
* ctx->conf.min_def, we have to make sure to take
* the bigger one (NL80211_CHAN_WIDTH_160).
* Otherwise we might try degrading even when not
* needed, as the max required sta_bw returned (80+80)
* might be smaller than the configured bw (160).
*/
return NL80211_CHAN_WIDTH_160;
default:
WARN_ON(1);
return NL80211_CHAN_WIDTH_20;
}
}
static enum nl80211_chan_width
ieee80211_get_max_required_bw(struct ieee80211_sub_if_data *sdata)
{
enum nl80211_chan_width max_bw = NL80211_CHAN_WIDTH_20_NOHT;
struct sta_info *sta;
rcu_read_lock();
list_for_each_entry_rcu(sta, &sdata->local->sta_list, list) {
if (sdata != sta->sdata &&
!(sta->sdata->bss && sta->sdata->bss == sdata->bss))
continue;
if (!sta->uploaded)
continue;
max_bw = max(max_bw, ieee80211_get_sta_bw(&sta->sta));
}
rcu_read_unlock();
return max_bw;
}
static enum nl80211_chan_width
ieee80211_get_chanctx_max_required_bw(struct ieee80211_local *local,
struct ieee80211_chanctx_conf *conf)
{
struct ieee80211_sub_if_data *sdata;
enum nl80211_chan_width max_bw = NL80211_CHAN_WIDTH_20_NOHT;
rcu_read_lock();
list_for_each_entry_rcu(sdata, &local->interfaces, list) {
struct ieee80211_vif *vif = &sdata->vif;
enum nl80211_chan_width width = NL80211_CHAN_WIDTH_20_NOHT;
if (!ieee80211_sdata_running(sdata))
continue;
if (rcu_access_pointer(sdata->vif.chanctx_conf) != conf)
continue;
switch (vif->type) {
case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_AP_VLAN:
width = ieee80211_get_max_required_bw(sdata);
break;
case NL80211_IFTYPE_P2P_DEVICE:
continue;
case NL80211_IFTYPE_STATION:
case NL80211_IFTYPE_ADHOC:
case NL80211_IFTYPE_WDS:
case NL80211_IFTYPE_MESH_POINT:
width = vif->bss_conf.chandef.width;
break;
case NL80211_IFTYPE_UNSPECIFIED:
case NUM_NL80211_IFTYPES:
case NL80211_IFTYPE_MONITOR:
case NL80211_IFTYPE_P2P_CLIENT:
case NL80211_IFTYPE_P2P_GO:
WARN_ON_ONCE(1);
}
max_bw = max(max_bw, width);
}
rcu_read_unlock();
return max_bw;
}
/*
* recalc the min required chan width of the channel context, which is
* the max of min required widths of all the interfaces bound to this
* channel context.
*/
void ieee80211_recalc_chanctx_min_def(struct ieee80211_local *local,
struct ieee80211_chanctx *ctx)
{
enum nl80211_chan_width max_bw;
struct cfg80211_chan_def min_def;
lockdep_assert_held(&local->chanctx_mtx);
/* don't optimize 5MHz, 10MHz, and radar_enabled confs */
if (ctx->conf.def.width == NL80211_CHAN_WIDTH_5 ||
ctx->conf.def.width == NL80211_CHAN_WIDTH_10 ||
ctx->conf.radar_enabled) {
ctx->conf.min_def = ctx->conf.def;
return;
}
max_bw = ieee80211_get_chanctx_max_required_bw(local, &ctx->conf);
/* downgrade chandef up to max_bw */
min_def = ctx->conf.def;
while (min_def.width > max_bw)
ieee80211_chandef_downgrade(&min_def);
if (cfg80211_chandef_identical(&ctx->conf.min_def, &min_def))
return;
ctx->conf.min_def = min_def;
if (!ctx->driver_present)
return;
drv_change_chanctx(local, ctx, IEEE80211_CHANCTX_CHANGE_MIN_WIDTH);
}
mac80211: fix ieee80211_change_chandef name This should be called ieee80211_change_chanctx() since it changes the channel context, not a chandef. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-08 04:30:37 +08:00
static void ieee80211_change_chanctx(struct ieee80211_local *local,
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
struct ieee80211_chanctx *ctx,
const struct cfg80211_chan_def *chandef)
mac80211: refactor set_channel_type Split functionality for further reuse. Will prevent code duplication when channel context channel_type merging is introduced. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:21 +08:00
{
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
if (cfg80211_chandef_identical(&ctx->conf.def, chandef))
mac80211: reuse channels for channel contexts Reuse channels with compatible channel types. Some channel types are compatible and can be used concurrently. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:22 +08:00
return;
mac80211: improve HT channel handling Currently, when one interface switches HT mode, all others will follow along. This is clearly undesirable, since the new one might switch to no-HT while another one is operating in HT. Address this issue by keeping track of the HT mode per interface, and allowing only changes that are compatible, i.e. switching into HT40+ is not possible when another interface is in HT40-, in that case the second one needs to fall back to HT20. Also, to allow drivers to know what's going on, store the per-interface HT mode (channel type) in the virtual interface's bss_conf. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:28:27 +08:00
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
WARN_ON(!cfg80211_chandef_compatible(&ctx->conf.def, chandef));
ctx->conf.def = *chandef;
drv_change_chanctx(local, ctx, IEEE80211_CHANCTX_CHANGE_WIDTH);
mac80211: add min required channel definition field Add a new field to ieee80211_chanctx_conf to indicate the min required channel configuration. Tuning to a narrower channel might help reducing the noise level and saving some power. The min required channel definition is the max of all min required channel definitions of the interfaces bound to this channel context. In AP mode, use 20MHz when there are no connected station. When a new station is added/removed, calculate the new max bandwidth supported by any of the stations (e.g. 80MHz when 80MHz and 40MHz stations are connected). In other cases, simply use bss_conf.chandef as the min required chandef. Notify drivers about changes to this field by calling drv_change_chanctx with a new CHANGE_MIN_WIDTH notification. Signed-off-by: Eliad Peller <eliad@wizery.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-12 02:14:01 +08:00
ieee80211_recalc_chanctx_min_def(local, ctx);
mac80211: use channel contexts Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-26 23:24:39 +08:00
if (!local->use_chanctx) {
mac80211: Use a cfg80211_chan_def in ieee80211_hw_conf_chan Drivers that don't use chanctxes cannot perform VHT association because they still use a "backward compatibility" pair of {ieee80211_channel, nl80211_channel_type} in ieee80211_conf and ieee80211_local. Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com> [fix kernel-doc] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-25 23:26:57 +08:00
local->_oper_chandef = *chandef;
mac80211: use channel contexts Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-26 23:24:39 +08:00
ieee80211_hw_config(local, 0);
}
mac80211: improve HT channel handling Currently, when one interface switches HT mode, all others will follow along. This is clearly undesirable, since the new one might switch to no-HT while another one is operating in HT. Address this issue by keeping track of the HT mode per interface, and allowing only changes that are compatible, i.e. switching into HT40+ is not possible when another interface is in HT40-, in that case the second one needs to fall back to HT20. Also, to allow drivers to know what's going on, store the per-interface HT mode (channel type) in the virtual interface's bss_conf. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:28:27 +08:00
}
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
static struct ieee80211_chanctx *
ieee80211_find_chanctx(struct ieee80211_local *local,
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
const struct cfg80211_chan_def *chandef,
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
enum ieee80211_chanctx_mode mode)
{
struct ieee80211_chanctx *ctx;
lockdep_assert_held(&local->chanctx_mtx);
if (mode == IEEE80211_CHANCTX_EXCLUSIVE)
return NULL;
list_for_each_entry(ctx, &local->chanctx_list, list) {
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
const struct cfg80211_chan_def *compat;
mac80211: reuse channels for channel contexts Reuse channels with compatible channel types. Some channel types are compatible and can be used concurrently. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:22 +08:00
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
if (ctx->mode == IEEE80211_CHANCTX_EXCLUSIVE)
continue;
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
compat = cfg80211_chandef_compatible(&ctx->conf.def, chandef);
if (!compat)
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
continue;
mac80211: fix ieee80211_change_chandef name This should be called ieee80211_change_chanctx() since it changes the channel context, not a chandef. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-08 04:30:37 +08:00
ieee80211_change_chanctx(local, ctx, compat);
mac80211: reuse channels for channel contexts Reuse channels with compatible channel types. Some channel types are compatible and can be used concurrently. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:22 +08:00
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
return ctx;
}
return NULL;
}
mac80211: fix recalc_radar hwconf sync problem local->hw.conf maybe not be synced when recalcing whether radar is enabled, sometimes leaving radar enabled even if it's not neccesary anymore. Fix this by: * setting radar_enabled when creating the chanctx * turning radar_enabled off before destroying the last channel context Reported-by: Zefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-04-09 04:43:16 +08:00
static bool ieee80211_is_radar_required(struct ieee80211_local *local)
{
struct ieee80211_sub_if_data *sdata;
rcu_read_lock();
list_for_each_entry_rcu(sdata, &local->interfaces, list) {
if (sdata->radar_required) {
rcu_read_unlock();
return true;
}
}
rcu_read_unlock();
return false;
}
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
static struct ieee80211_chanctx *
ieee80211_new_chanctx(struct ieee80211_local *local,
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
const struct cfg80211_chan_def *chandef,
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
enum ieee80211_chanctx_mode mode)
{
struct ieee80211_chanctx *ctx;
mac80211: fix idle handling sequence Corey Richardson reported that my idle handling cleanup (commit fd0f979a1b, "mac80211: simplify idle handling") broke ath9k_htc. The reason appears to be that it wants to go out of idle before switching channels. To fix it, reimplement that sequence. Reported-by: Corey Richardson <corey@octayn.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-23 05:30:09 +08:00
u32 changed;
mac80211: use channel context notifications Channel context pointer will be accessible on both assign and unassign events. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:20 +08:00
int err;
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
lockdep_assert_held(&local->chanctx_mtx);
ctx = kzalloc(sizeof(*ctx) + local->hw.chanctx_data_size, GFP_KERNEL);
if (!ctx)
return ERR_PTR(-ENOMEM);
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
ctx->conf.def = *chandef;
mac80211: track needed RX chains for channel contexts On each channel that the device is operating on, it may need to listen using one or more chains depending on the SMPS settings of the interfaces using it. The previous channel context changes completely removed this ability (before, it was available as the SMPS mode). Add per-context tracking of the required static and dynamic RX chains and notify the driver on changes. To achieve this, track the chains and SMPS mode used on each virtual interface and update the channel context whenever this changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 20:34:12 +08:00
ctx->conf.rx_chains_static = 1;
ctx->conf.rx_chains_dynamic = 1;
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
ctx->mode = mode;
mac80211: fix recalc_radar hwconf sync problem local->hw.conf maybe not be synced when recalcing whether radar is enabled, sometimes leaving radar enabled even if it's not neccesary anymore. Fix this by: * setting radar_enabled when creating the chanctx * turning radar_enabled off before destroying the last channel context Reported-by: Zefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-04-09 04:43:16 +08:00
ctx->conf.radar_enabled = ieee80211_is_radar_required(local);
mac80211: add min required channel definition field Add a new field to ieee80211_chanctx_conf to indicate the min required channel configuration. Tuning to a narrower channel might help reducing the noise level and saving some power. The min required channel definition is the max of all min required channel definitions of the interfaces bound to this channel context. In AP mode, use 20MHz when there are no connected station. When a new station is added/removed, calculate the new max bandwidth supported by any of the stations (e.g. 80MHz when 80MHz and 40MHz stations are connected). In other cases, simply use bss_conf.chandef as the min required chandef. Notify drivers about changes to this field by calling drv_change_chanctx with a new CHANGE_MIN_WIDTH notification. Signed-off-by: Eliad Peller <eliad@wizery.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-12 02:14:01 +08:00
ieee80211_recalc_chanctx_min_def(local, ctx);
mac80211: fix recalc_radar hwconf sync problem local->hw.conf maybe not be synced when recalcing whether radar is enabled, sometimes leaving radar enabled even if it's not neccesary anymore. Fix this by: * setting radar_enabled when creating the chanctx * turning radar_enabled off before destroying the last channel context Reported-by: Zefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-04-09 04:43:16 +08:00
if (!local->use_chanctx)
local->hw.conf.radar_enabled = ctx->conf.radar_enabled;
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
mac80211: fix iflist_mtx/mtx locking in radar detection The scan code creates an iflist_mtx -> mtx locking dependency, and a few other places, notably radar detection, were creating the opposite dependency, causing lockdep to complain. As scan and radar detection are mutually exclusive, the deadlock can't really happen in practice, but it's still bad form. A similar issue exists in the monitor mode code, but this is only used by channel-context drivers right now and those have to have hardware scan, so that also can't happen. Still, fix these issues by making some of the channel context code require the mtx to be held rather than acquiring it, thus allowing the monitor/radar callers to keep the iflist_mtx->mtx lock ordering. While at it, also fix access to the local->scanning variable in the radar code, and document that radar_detect_enabled is now properly protected by the mtx. All this would now introduce an ABBA deadlock between the DFS work cancelling and local->mtx, so change the locking there a bit to not need to use cancel_delayed_work_sync() but be able to just use cancel_delayed_work(). The work is also safely stopped/removed when the interface is stopped, so no extra changes are needed. Reported-by: Kalle Valo <kvalo@qca.qualcomm.com> Tested-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-12-18 16:43:33 +08:00
/* we hold the mutex to prevent idle from changing */
lockdep_assert_held(&local->mtx);
mac80211: fix idle handling sequence Corey Richardson reported that my idle handling cleanup (commit fd0f979a1b, "mac80211: simplify idle handling") broke ath9k_htc. The reason appears to be that it wants to go out of idle before switching channels. To fix it, reimplement that sequence. Reported-by: Corey Richardson <corey@octayn.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-23 05:30:09 +08:00
/* turn idle off *before* setting channel -- some drivers need that */
changed = ieee80211_idle_off(local);
if (changed)
ieee80211_hw_config(local, changed);
mac80211: use channel contexts Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-26 23:24:39 +08:00
if (!local->use_chanctx) {
mac80211: Use a cfg80211_chan_def in ieee80211_hw_conf_chan Drivers that don't use chanctxes cannot perform VHT association because they still use a "backward compatibility" pair of {ieee80211_channel, nl80211_channel_type} in ieee80211_conf and ieee80211_local. Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com> [fix kernel-doc] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-25 23:26:57 +08:00
local->_oper_chandef = *chandef;
mac80211: use channel contexts Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-26 23:24:39 +08:00
ieee80211_hw_config(local, 0);
} else {
err = drv_add_chanctx(local, ctx);
if (err) {
kfree(ctx);
mac80211: fix idle handling sequence Corey Richardson reported that my idle handling cleanup (commit fd0f979a1b, "mac80211: simplify idle handling") broke ath9k_htc. The reason appears to be that it wants to go out of idle before switching channels. To fix it, reimplement that sequence. Reported-by: Corey Richardson <corey@octayn.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-23 05:30:09 +08:00
ieee80211_recalc_idle(local);
mac80211: fix iflist_mtx/mtx locking in radar detection The scan code creates an iflist_mtx -> mtx locking dependency, and a few other places, notably radar detection, were creating the opposite dependency, causing lockdep to complain. As scan and radar detection are mutually exclusive, the deadlock can't really happen in practice, but it's still bad form. A similar issue exists in the monitor mode code, but this is only used by channel-context drivers right now and those have to have hardware scan, so that also can't happen. Still, fix these issues by making some of the channel context code require the mtx to be held rather than acquiring it, thus allowing the monitor/radar callers to keep the iflist_mtx->mtx lock ordering. While at it, also fix access to the local->scanning variable in the radar code, and document that radar_detect_enabled is now properly protected by the mtx. All this would now introduce an ABBA deadlock between the DFS work cancelling and local->mtx, so change the locking there a bit to not need to use cancel_delayed_work_sync() but be able to just use cancel_delayed_work(). The work is also safely stopped/removed when the interface is stopped, so no extra changes are needed. Reported-by: Kalle Valo <kvalo@qca.qualcomm.com> Tested-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-12-18 16:43:33 +08:00
return ERR_PTR(err);
mac80211: use channel contexts Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-26 23:24:39 +08:00
}
mac80211: use channel context notifications Channel context pointer will be accessible on both assign and unassign events. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:20 +08:00
}
mac80211: fix idle handling sequence Corey Richardson reported that my idle handling cleanup (commit fd0f979a1b, "mac80211: simplify idle handling") broke ath9k_htc. The reason appears to be that it wants to go out of idle before switching channels. To fix it, reimplement that sequence. Reported-by: Corey Richardson <corey@octayn.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-23 05:30:09 +08:00
/* and keep the mutex held until the new chanctx is on the list */
mac80211: add channel context iterator Drivers may need to iterate the active channel contexts, export an iterator function to allow that. To make it possible, use RCU-safe list functions. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 23:57:42 +08:00
list_add_rcu(&ctx->list, &local->chanctx_list);
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
return ctx;
}
static void ieee80211_free_chanctx(struct ieee80211_local *local,
struct ieee80211_chanctx *ctx)
{
mac80211: fix recalc_radar hwconf sync problem local->hw.conf maybe not be synced when recalcing whether radar is enabled, sometimes leaving radar enabled even if it's not neccesary anymore. Fix this by: * setting radar_enabled when creating the chanctx * turning radar_enabled off before destroying the last channel context Reported-by: Zefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-04-09 04:43:16 +08:00
bool check_single_channel = false;
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
lockdep_assert_held(&local->chanctx_mtx);
WARN_ON_ONCE(ctx->refcount != 0);
mac80211: use channel contexts Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-26 23:24:39 +08:00
if (!local->use_chanctx) {
mac80211: Use a cfg80211_chan_def in ieee80211_hw_conf_chan Drivers that don't use chanctxes cannot perform VHT association because they still use a "backward compatibility" pair of {ieee80211_channel, nl80211_channel_type} in ieee80211_conf and ieee80211_local. Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com> [fix kernel-doc] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-25 23:26:57 +08:00
struct cfg80211_chan_def *chandef = &local->_oper_chandef;
chandef->width = NL80211_CHAN_WIDTH_20_NOHT;
chandef->center_freq1 = chandef->chan->center_freq;
chandef->center_freq2 = 0;
mac80211: fix recalc_radar hwconf sync problem local->hw.conf maybe not be synced when recalcing whether radar is enabled, sometimes leaving radar enabled even if it's not neccesary anymore. Fix this by: * setting radar_enabled when creating the chanctx * turning radar_enabled off before destroying the last channel context Reported-by: Zefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-04-09 04:43:16 +08:00
/* NOTE: Disabling radar is only valid here for
* single channel context. To be sure, check it ...
*/
if (local->hw.conf.radar_enabled)
check_single_channel = true;
local->hw.conf.radar_enabled = false;
mac80211: use channel contexts Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-26 23:24:39 +08:00
ieee80211_hw_config(local, 0);
} else {
drv_remove_chanctx(local, ctx);
}
mac80211: use channel context notifications Channel context pointer will be accessible on both assign and unassign events. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:20 +08:00
mac80211: add channel context iterator Drivers may need to iterate the active channel contexts, export an iterator function to allow that. To make it possible, use RCU-safe list functions. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 23:57:42 +08:00
list_del_rcu(&ctx->list);
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
kfree_rcu(ctx, rcu_head);
mac80211: simplify idle handling Now that we have channel contexts, idle is (pretty much) equivalent to not having a channel context. Change the code to use this relation so that there no longer is a need for a lot of idle recalculate calls everywhere. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-07 07:14:51 +08:00
mac80211: fix recalc_radar hwconf sync problem local->hw.conf maybe not be synced when recalcing whether radar is enabled, sometimes leaving radar enabled even if it's not neccesary anymore. Fix this by: * setting radar_enabled when creating the chanctx * turning radar_enabled off before destroying the last channel context Reported-by: Zefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-04-09 04:43:16 +08:00
/* throw a warning if this wasn't the only channel context. */
WARN_ON(check_single_channel && !list_empty(&local->chanctx_list));
mac80211: simplify idle handling Now that we have channel contexts, idle is (pretty much) equivalent to not having a channel context. Change the code to use this relation so that there no longer is a need for a lot of idle recalculate calls everywhere. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-07 07:14:51 +08:00
ieee80211_recalc_idle(local);
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
}
static int ieee80211_assign_vif_chanctx(struct ieee80211_sub_if_data *sdata,
struct ieee80211_chanctx *ctx)
{
mac80211: use channel context notifications Channel context pointer will be accessible on both assign and unassign events. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:20 +08:00
struct ieee80211_local *local = sdata->local;
int ret;
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
lockdep_assert_held(&local->chanctx_mtx);
mac80211: use channel context notifications Channel context pointer will be accessible on both assign and unassign events. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:20 +08:00
ret = drv_assign_vif_chanctx(local, sdata, ctx);
if (ret)
return ret;
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
rcu_assign_pointer(sdata->vif.chanctx_conf, &ctx->conf);
ctx->refcount++;
mac80211: handle TX power per virtual interface Even before channel contexts/multi-channel, having a single global TX power limit was already problematic, in particular if two managed interfaces connected to two APs with different power constraints. The channel context introduction completely broke this though and in fact I had disabled TX power configuration there for drivers using channel contexts. Change everything to track TX power per interface so that different user settings and different channel maxima are treated correctly. Also continue tracking the global TX power though for compatibility with applications that attempt to configure the wiphy's TX power globally. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-10-24 16:59:25 +08:00
ieee80211_recalc_txpower(sdata);
mac80211: add min required channel definition field Add a new field to ieee80211_chanctx_conf to indicate the min required channel configuration. Tuning to a narrower channel might help reducing the noise level and saving some power. The min required channel definition is the max of all min required channel definitions of the interfaces bound to this channel context. In AP mode, use 20MHz when there are no connected station. When a new station is added/removed, calculate the new max bandwidth supported by any of the stations (e.g. 80MHz when 80MHz and 40MHz stations are connected). In other cases, simply use bss_conf.chandef as the min required chandef. Notify drivers about changes to this field by calling drv_change_chanctx with a new CHANGE_MIN_WIDTH notification. Signed-off-by: Eliad Peller <eliad@wizery.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-12 02:14:01 +08:00
ieee80211_recalc_chanctx_min_def(local, ctx);
mac80211: simplify idle handling Now that we have channel contexts, idle is (pretty much) equivalent to not having a channel context. Change the code to use this relation so that there no longer is a need for a lot of idle recalculate calls everywhere. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-07 07:14:51 +08:00
sdata->vif.bss_conf.idle = false;
mac80211: don't call bss_info_changed on p2p-device/monitor Since the idle decision rework, mac80211 started calling bss_info_changed() for the driver's monitor interface, which causes a crash for iwlwifi, but drivers generally don't expect this to happen. Therefore, avoid it. While at it, also prevent calling it in such cases and only print a warning. For the P2P Device interface the idle will no longer be called (no channel context), so also prevent that and warn on it. Reported-by: Chaitanya <chaitanya.mgit@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-13 20:50:51 +08:00
if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE &&
sdata->vif.type != NL80211_IFTYPE_MONITOR)
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_IDLE);
mac80211: handle TX power per virtual interface Even before channel contexts/multi-channel, having a single global TX power limit was already problematic, in particular if two managed interfaces connected to two APs with different power constraints. The channel context introduction completely broke this though and in fact I had disabled TX power configuration there for drivers using channel contexts. Change everything to track TX power per interface so that different user settings and different channel maxima are treated correctly. Also continue tracking the global TX power though for compatibility with applications that attempt to configure the wiphy's TX power globally. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-10-24 16:59:25 +08:00
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
return 0;
}
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
static void ieee80211_recalc_chanctx_chantype(struct ieee80211_local *local,
struct ieee80211_chanctx *ctx)
mac80211: reuse channels for channel contexts Reuse channels with compatible channel types. Some channel types are compatible and can be used concurrently. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:22 +08:00
{
struct ieee80211_chanctx_conf *conf = &ctx->conf;
struct ieee80211_sub_if_data *sdata;
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
const struct cfg80211_chan_def *compat = NULL;
mac80211: reuse channels for channel contexts Reuse channels with compatible channel types. Some channel types are compatible and can be used concurrently. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:22 +08:00
lockdep_assert_held(&local->chanctx_mtx);
rcu_read_lock();
list_for_each_entry_rcu(sdata, &local->interfaces, list) {
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
mac80211: reuse channels for channel contexts Reuse channels with compatible channel types. Some channel types are compatible and can be used concurrently. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:22 +08:00
if (!ieee80211_sdata_running(sdata))
continue;
if (rcu_access_pointer(sdata->vif.chanctx_conf) != conf)
continue;
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
if (!compat)
compat = &sdata->vif.bss_conf.chandef;
compat = cfg80211_chandef_compatible(
&sdata->vif.bss_conf.chandef, compat);
if (!compat)
break;
mac80211: reuse channels for channel contexts Reuse channels with compatible channel types. Some channel types are compatible and can be used concurrently. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:22 +08:00
}
rcu_read_unlock();
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
if (WARN_ON_ONCE(!compat))
return;
mac80211: reuse channels for channel contexts Reuse channels with compatible channel types. Some channel types are compatible and can be used concurrently. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:22 +08:00
mac80211: fix ieee80211_change_chandef name This should be called ieee80211_change_chanctx() since it changes the channel context, not a chandef. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-08 04:30:37 +08:00
ieee80211_change_chanctx(local, ctx, compat);
mac80211: reuse channels for channel contexts Reuse channels with compatible channel types. Some channel types are compatible and can be used concurrently. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:22 +08:00
}
mac80211: make ieee80211_recalc_radar_chanctx static The function is only used in one file, so move it up a bit to avoid forward declarations and make it static. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-12-18 16:36:09 +08:00
static void ieee80211_recalc_radar_chanctx(struct ieee80211_local *local,
struct ieee80211_chanctx *chanctx)
{
bool radar_enabled;
lockdep_assert_held(&local->chanctx_mtx);
mac80211: fix iflist_mtx/mtx locking in radar detection The scan code creates an iflist_mtx -> mtx locking dependency, and a few other places, notably radar detection, were creating the opposite dependency, causing lockdep to complain. As scan and radar detection are mutually exclusive, the deadlock can't really happen in practice, but it's still bad form. A similar issue exists in the monitor mode code, but this is only used by channel-context drivers right now and those have to have hardware scan, so that also can't happen. Still, fix these issues by making some of the channel context code require the mtx to be held rather than acquiring it, thus allowing the monitor/radar callers to keep the iflist_mtx->mtx lock ordering. While at it, also fix access to the local->scanning variable in the radar code, and document that radar_detect_enabled is now properly protected by the mtx. All this would now introduce an ABBA deadlock between the DFS work cancelling and local->mtx, so change the locking there a bit to not need to use cancel_delayed_work_sync() but be able to just use cancel_delayed_work(). The work is also safely stopped/removed when the interface is stopped, so no extra changes are needed. Reported-by: Kalle Valo <kvalo@qca.qualcomm.com> Tested-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-12-18 16:43:33 +08:00
/* for setting local->radar_detect_enabled */
lockdep_assert_held(&local->mtx);
mac80211: make ieee80211_recalc_radar_chanctx static The function is only used in one file, so move it up a bit to avoid forward declarations and make it static. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-12-18 16:36:09 +08:00
radar_enabled = ieee80211_is_radar_required(local);
if (radar_enabled == chanctx->conf.radar_enabled)
return;
chanctx->conf.radar_enabled = radar_enabled;
local->radar_detect_enabled = chanctx->conf.radar_enabled;
if (!local->use_chanctx) {
local->hw.conf.radar_enabled = chanctx->conf.radar_enabled;
ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
}
drv_change_chanctx(local, chanctx, IEEE80211_CHANCTX_CHANGE_RADAR);
}
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
static void ieee80211_unassign_vif_chanctx(struct ieee80211_sub_if_data *sdata,
struct ieee80211_chanctx *ctx)
{
mac80211: use channel context notifications Channel context pointer will be accessible on both assign and unassign events. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:20 +08:00
struct ieee80211_local *local = sdata->local;
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
lockdep_assert_held(&local->chanctx_mtx);
ctx->refcount--;
rcu_assign_pointer(sdata->vif.chanctx_conf, NULL);
mac80211: use channel context notifications Channel context pointer will be accessible on both assign and unassign events. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:20 +08:00
mac80211: simplify idle handling Now that we have channel contexts, idle is (pretty much) equivalent to not having a channel context. Change the code to use this relation so that there no longer is a need for a lot of idle recalculate calls everywhere. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-07 07:14:51 +08:00
sdata->vif.bss_conf.idle = true;
mac80211: don't call bss_info_changed on p2p-device/monitor Since the idle decision rework, mac80211 started calling bss_info_changed() for the driver's monitor interface, which causes a crash for iwlwifi, but drivers generally don't expect this to happen. Therefore, avoid it. While at it, also prevent calling it in such cases and only print a warning. For the P2P Device interface the idle will no longer be called (no channel context), so also prevent that and warn on it. Reported-by: Chaitanya <chaitanya.mgit@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-13 20:50:51 +08:00
if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE &&
sdata->vif.type != NL80211_IFTYPE_MONITOR)
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_IDLE);
mac80211: simplify idle handling Now that we have channel contexts, idle is (pretty much) equivalent to not having a channel context. Change the code to use this relation so that there no longer is a need for a lot of idle recalculate calls everywhere. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-07 07:14:51 +08:00
mac80211: use channel context notifications Channel context pointer will be accessible on both assign and unassign events. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:20 +08:00
drv_unassign_vif_chanctx(local, sdata, ctx);
mac80211: reuse channels for channel contexts Reuse channels with compatible channel types. Some channel types are compatible and can be used concurrently. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:22 +08:00
mac80211: track needed RX chains for channel contexts On each channel that the device is operating on, it may need to listen using one or more chains depending on the SMPS settings of the interfaces using it. The previous channel context changes completely removed this ability (before, it was available as the SMPS mode). Add per-context tracking of the required static and dynamic RX chains and notify the driver on changes. To achieve this, track the chains and SMPS mode used on each virtual interface and update the channel context whenever this changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 20:34:12 +08:00
if (ctx->refcount > 0) {
mac80211: reuse channels for channel contexts Reuse channels with compatible channel types. Some channel types are compatible and can be used concurrently. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:22 +08:00
ieee80211_recalc_chanctx_chantype(sdata->local, ctx);
mac80211: track needed RX chains for channel contexts On each channel that the device is operating on, it may need to listen using one or more chains depending on the SMPS settings of the interfaces using it. The previous channel context changes completely removed this ability (before, it was available as the SMPS mode). Add per-context tracking of the required static and dynamic RX chains and notify the driver on changes. To achieve this, track the chains and SMPS mode used on each virtual interface and update the channel context whenever this changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 20:34:12 +08:00
ieee80211_recalc_smps_chanctx(local, ctx);
mac80211: add radar detection command/event Add command to trigger radar detection in the driver/FW. Once radar detection is started it should continuously monitor for radars as long as the channel active. If radar is detected usermode notified with 'radar detected' event. Scanning and remain on channel functionality must be disabled while doing radar detection/scanning, and vice versa. Based on original patch by Victor Goldenshtein <victorg@ti.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-09 01:16:20 +08:00
ieee80211_recalc_radar_chanctx(local, ctx);
mac80211: add min required channel definition field Add a new field to ieee80211_chanctx_conf to indicate the min required channel configuration. Tuning to a narrower channel might help reducing the noise level and saving some power. The min required channel definition is the max of all min required channel definitions of the interfaces bound to this channel context. In AP mode, use 20MHz when there are no connected station. When a new station is added/removed, calculate the new max bandwidth supported by any of the stations (e.g. 80MHz when 80MHz and 40MHz stations are connected). In other cases, simply use bss_conf.chandef as the min required chandef. Notify drivers about changes to this field by calling drv_change_chanctx with a new CHANGE_MIN_WIDTH notification. Signed-off-by: Eliad Peller <eliad@wizery.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-12 02:14:01 +08:00
ieee80211_recalc_chanctx_min_def(local, ctx);
mac80211: track needed RX chains for channel contexts On each channel that the device is operating on, it may need to listen using one or more chains depending on the SMPS settings of the interfaces using it. The previous channel context changes completely removed this ability (before, it was available as the SMPS mode). Add per-context tracking of the required static and dynamic RX chains and notify the driver on changes. To achieve this, track the chains and SMPS mode used on each virtual interface and update the channel context whenever this changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 20:34:12 +08:00
}
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
}
static void __ieee80211_vif_release_channel(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_chanctx_conf *conf;
struct ieee80211_chanctx *ctx;
lockdep_assert_held(&local->chanctx_mtx);
conf = rcu_dereference_protected(sdata->vif.chanctx_conf,
lockdep_is_held(&local->chanctx_mtx));
if (!conf)
return;
ctx = container_of(conf, struct ieee80211_chanctx, conf);
ieee80211_unassign_vif_chanctx(sdata, ctx);
if (ctx->refcount == 0)
ieee80211_free_chanctx(local, ctx);
}
mac80211: track needed RX chains for channel contexts On each channel that the device is operating on, it may need to listen using one or more chains depending on the SMPS settings of the interfaces using it. The previous channel context changes completely removed this ability (before, it was available as the SMPS mode). Add per-context tracking of the required static and dynamic RX chains and notify the driver on changes. To achieve this, track the chains and SMPS mode used on each virtual interface and update the channel context whenever this changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 20:34:12 +08:00
void ieee80211_recalc_smps_chanctx(struct ieee80211_local *local,
struct ieee80211_chanctx *chanctx)
{
struct ieee80211_sub_if_data *sdata;
u8 rx_chains_static, rx_chains_dynamic;
lockdep_assert_held(&local->chanctx_mtx);
rx_chains_static = 1;
rx_chains_dynamic = 1;
rcu_read_lock();
list_for_each_entry_rcu(sdata, &local->interfaces, list) {
u8 needed_static, needed_dynamic;
if (!ieee80211_sdata_running(sdata))
continue;
if (rcu_access_pointer(sdata->vif.chanctx_conf) !=
&chanctx->conf)
continue;
switch (sdata->vif.type) {
case NL80211_IFTYPE_P2P_DEVICE:
continue;
case NL80211_IFTYPE_STATION:
if (!sdata->u.mgd.associated)
continue;
break;
case NL80211_IFTYPE_AP_VLAN:
continue;
case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_ADHOC:
case NL80211_IFTYPE_WDS:
case NL80211_IFTYPE_MESH_POINT:
break;
default:
WARN_ON_ONCE(1);
}
switch (sdata->smps_mode) {
default:
WARN_ONCE(1, "Invalid SMPS mode %d\n",
sdata->smps_mode);
/* fall through */
case IEEE80211_SMPS_OFF:
needed_static = sdata->needed_rx_chains;
needed_dynamic = sdata->needed_rx_chains;
break;
case IEEE80211_SMPS_DYNAMIC:
needed_static = 1;
needed_dynamic = sdata->needed_rx_chains;
break;
case IEEE80211_SMPS_STATIC:
needed_static = 1;
needed_dynamic = 1;
break;
}
rx_chains_static = max(rx_chains_static, needed_static);
rx_chains_dynamic = max(rx_chains_dynamic, needed_dynamic);
}
rcu_read_unlock();
if (!local->use_chanctx) {
if (rx_chains_static > 1)
local->smps_mode = IEEE80211_SMPS_OFF;
else if (rx_chains_dynamic > 1)
local->smps_mode = IEEE80211_SMPS_DYNAMIC;
else
local->smps_mode = IEEE80211_SMPS_STATIC;
ieee80211_hw_config(local, 0);
}
if (rx_chains_static == chanctx->conf.rx_chains_static &&
rx_chains_dynamic == chanctx->conf.rx_chains_dynamic)
return;
chanctx->conf.rx_chains_static = rx_chains_static;
chanctx->conf.rx_chains_dynamic = rx_chains_dynamic;
drv_change_chanctx(local, chanctx, IEEE80211_CHANCTX_CHANGE_RX_CHAINS);
}
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
int ieee80211_vif_use_channel(struct ieee80211_sub_if_data *sdata,
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
const struct cfg80211_chan_def *chandef,
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
enum ieee80211_chanctx_mode mode)
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_chanctx *ctx;
int ret;
mac80211: fix iflist_mtx/mtx locking in radar detection The scan code creates an iflist_mtx -> mtx locking dependency, and a few other places, notably radar detection, were creating the opposite dependency, causing lockdep to complain. As scan and radar detection are mutually exclusive, the deadlock can't really happen in practice, but it's still bad form. A similar issue exists in the monitor mode code, but this is only used by channel-context drivers right now and those have to have hardware scan, so that also can't happen. Still, fix these issues by making some of the channel context code require the mtx to be held rather than acquiring it, thus allowing the monitor/radar callers to keep the iflist_mtx->mtx lock ordering. While at it, also fix access to the local->scanning variable in the radar code, and document that radar_detect_enabled is now properly protected by the mtx. All this would now introduce an ABBA deadlock between the DFS work cancelling and local->mtx, so change the locking there a bit to not need to use cancel_delayed_work_sync() but be able to just use cancel_delayed_work(). The work is also safely stopped/removed when the interface is stopped, so no extra changes are needed. Reported-by: Kalle Valo <kvalo@qca.qualcomm.com> Tested-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-12-18 16:43:33 +08:00
lockdep_assert_held(&local->mtx);
mac80211: use channel contexts Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-26 23:24:39 +08:00
WARN_ON(sdata->dev && netif_carrier_ok(sdata->dev));
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
mutex_lock(&local->chanctx_mtx);
__ieee80211_vif_release_channel(sdata);
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
ctx = ieee80211_find_chanctx(local, chandef, mode);
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
if (!ctx)
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
ctx = ieee80211_new_chanctx(local, chandef, mode);
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
if (IS_ERR(ctx)) {
ret = PTR_ERR(ctx);
goto out;
}
mac80211: convert to channel definition struct Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-09 18:39:59 +08:00
sdata->vif.bss_conf.chandef = *chandef;
mac80211: use channel contexts Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-26 23:24:39 +08:00
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
ret = ieee80211_assign_vif_chanctx(sdata, ctx);
if (ret) {
/* if assign fails refcount stays the same */
if (ctx->refcount == 0)
ieee80211_free_chanctx(local, ctx);
goto out;
}
mac80211: track needed RX chains for channel contexts On each channel that the device is operating on, it may need to listen using one or more chains depending on the SMPS settings of the interfaces using it. The previous channel context changes completely removed this ability (before, it was available as the SMPS mode). Add per-context tracking of the required static and dynamic RX chains and notify the driver on changes. To achieve this, track the chains and SMPS mode used on each virtual interface and update the channel context whenever this changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 20:34:12 +08:00
ieee80211_recalc_smps_chanctx(local, ctx);
mac80211: add radar detection command/event Add command to trigger radar detection in the driver/FW. Once radar detection is started it should continuously monitor for radars as long as the channel active. If radar is detected usermode notified with 'radar detected' event. Scanning and remain on channel functionality must be disabled while doing radar detection/scanning, and vice versa. Based on original patch by Victor Goldenshtein <victorg@ti.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-09 01:16:20 +08:00
ieee80211_recalc_radar_chanctx(local, ctx);
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
out:
mutex_unlock(&local->chanctx_mtx);
return ret;
}
mac80211: add channel switch command and beacon callbacks The count field in CSA must be decremented with each beacon transmitted. This patch implements the functionality for drivers using ieee80211_beacon_get(). Other drivers must call back manually after reaching count == 0. This patch also contains the handling and finish worker for the channel switch command, and mac80211/chanctx code to allow to change a channel definition of an active channel context. Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> [small cleanups, catch identical chandef] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-07-11 22:09:06 +08:00
int ieee80211_vif_change_channel(struct ieee80211_sub_if_data *sdata,
u32 *changed)
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_chanctx_conf *conf;
struct ieee80211_chanctx *ctx;
mac80211: move csa_chandef to sdata There is no reason why we should have only one channel switch announcement at a time for a single phy. When support for channel switch with multiple contexts and multiple vifs per context is implemented, we will need the chandef data for each vif. Move the csa_chandef structure to sdata to prepare for this. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> [Fixed compilation with mesh] Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-12 02:34:54 +08:00
const struct cfg80211_chan_def *chandef = &sdata->csa_chandef;
mac80211: add channel switch command and beacon callbacks The count field in CSA must be decremented with each beacon transmitted. This patch implements the functionality for drivers using ieee80211_beacon_get(). Other drivers must call back manually after reaching count == 0. This patch also contains the handling and finish worker for the channel switch command, and mac80211/chanctx code to allow to change a channel definition of an active channel context. Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> [small cleanups, catch identical chandef] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-07-11 22:09:06 +08:00
int ret;
u32 chanctx_changed = 0;
mac80211: fix iflist_mtx/mtx locking in radar detection The scan code creates an iflist_mtx -> mtx locking dependency, and a few other places, notably radar detection, were creating the opposite dependency, causing lockdep to complain. As scan and radar detection are mutually exclusive, the deadlock can't really happen in practice, but it's still bad form. A similar issue exists in the monitor mode code, but this is only used by channel-context drivers right now and those have to have hardware scan, so that also can't happen. Still, fix these issues by making some of the channel context code require the mtx to be held rather than acquiring it, thus allowing the monitor/radar callers to keep the iflist_mtx->mtx lock ordering. While at it, also fix access to the local->scanning variable in the radar code, and document that radar_detect_enabled is now properly protected by the mtx. All this would now introduce an ABBA deadlock between the DFS work cancelling and local->mtx, so change the locking there a bit to not need to use cancel_delayed_work_sync() but be able to just use cancel_delayed_work(). The work is also safely stopped/removed when the interface is stopped, so no extra changes are needed. Reported-by: Kalle Valo <kvalo@qca.qualcomm.com> Tested-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-12-18 16:43:33 +08:00
lockdep_assert_held(&local->mtx);
mac80211: add channel switch command and beacon callbacks The count field in CSA must be decremented with each beacon transmitted. This patch implements the functionality for drivers using ieee80211_beacon_get(). Other drivers must call back manually after reaching count == 0. This patch also contains the handling and finish worker for the channel switch command, and mac80211/chanctx code to allow to change a channel definition of an active channel context. Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> [small cleanups, catch identical chandef] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-07-11 22:09:06 +08:00
/* should never be called if not performing a channel switch. */
if (WARN_ON(!sdata->vif.csa_active))
return -EINVAL;
if (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
IEEE80211_CHAN_DISABLED))
return -EINVAL;
mutex_lock(&local->chanctx_mtx);
conf = rcu_dereference_protected(sdata->vif.chanctx_conf,
lockdep_is_held(&local->chanctx_mtx));
if (!conf) {
ret = -EINVAL;
goto out;
}
ctx = container_of(conf, struct ieee80211_chanctx, conf);
if (ctx->refcount != 1) {
ret = -EINVAL;
goto out;
}
if (sdata->vif.bss_conf.chandef.width != chandef->width) {
chanctx_changed = IEEE80211_CHANCTX_CHANGE_WIDTH;
*changed |= BSS_CHANGED_BANDWIDTH;
}
sdata->vif.bss_conf.chandef = *chandef;
ctx->conf.def = *chandef;
chanctx_changed |= IEEE80211_CHANCTX_CHANGE_CHANNEL;
drv_change_chanctx(local, ctx, chanctx_changed);
ieee80211_recalc_chanctx_chantype(local, ctx);
ieee80211_recalc_smps_chanctx(local, ctx);
ieee80211_recalc_radar_chanctx(local, ctx);
mac80211: add min required channel definition field Add a new field to ieee80211_chanctx_conf to indicate the min required channel configuration. Tuning to a narrower channel might help reducing the noise level and saving some power. The min required channel definition is the max of all min required channel definitions of the interfaces bound to this channel context. In AP mode, use 20MHz when there are no connected station. When a new station is added/removed, calculate the new max bandwidth supported by any of the stations (e.g. 80MHz when 80MHz and 40MHz stations are connected). In other cases, simply use bss_conf.chandef as the min required chandef. Notify drivers about changes to this field by calling drv_change_chanctx with a new CHANGE_MIN_WIDTH notification. Signed-off-by: Eliad Peller <eliad@wizery.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-12 02:14:01 +08:00
ieee80211_recalc_chanctx_min_def(local, ctx);
mac80211: add channel switch command and beacon callbacks The count field in CSA must be decremented with each beacon transmitted. This patch implements the functionality for drivers using ieee80211_beacon_get(). Other drivers must call back manually after reaching count == 0. This patch also contains the handling and finish worker for the channel switch command, and mac80211/chanctx code to allow to change a channel definition of an active channel context. Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> [small cleanups, catch identical chandef] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-07-11 22:09:06 +08:00
ret = 0;
out:
mutex_unlock(&local->chanctx_mtx);
return ret;
}
mac80211: add ieee80211_vif_change_bandwidth For HT and VHT the current bandwidth can change, add the function ieee80211_vif_change_bandwidth() to take care of this. It returns a failure if the new bandwidth isn't compatible with the existing channel context, the caller has to handle that. When it happens, also inform the driver that the bandwidth changed for this virtual interface (no drivers would actually care today though.) Changing to/from HT/VHT isn't allowed though. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-08 04:37:29 +08:00
int ieee80211_vif_change_bandwidth(struct ieee80211_sub_if_data *sdata,
const struct cfg80211_chan_def *chandef,
u32 *changed)
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_chanctx_conf *conf;
struct ieee80211_chanctx *ctx;
int ret;
if (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
IEEE80211_CHAN_DISABLED))
return -EINVAL;
mutex_lock(&local->chanctx_mtx);
if (cfg80211_chandef_identical(chandef, &sdata->vif.bss_conf.chandef)) {
ret = 0;
goto out;
}
if (chandef->width == NL80211_CHAN_WIDTH_20_NOHT ||
sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT) {
ret = -EINVAL;
goto out;
}
conf = rcu_dereference_protected(sdata->vif.chanctx_conf,
lockdep_is_held(&local->chanctx_mtx));
if (!conf) {
ret = -EINVAL;
goto out;
}
ctx = container_of(conf, struct ieee80211_chanctx, conf);
if (!cfg80211_chandef_compatible(&conf->def, chandef)) {
ret = -EINVAL;
goto out;
}
sdata->vif.bss_conf.chandef = *chandef;
ieee80211_recalc_chanctx_chantype(local, ctx);
*changed |= BSS_CHANGED_BANDWIDTH;
ret = 0;
out:
mutex_unlock(&local->chanctx_mtx);
return ret;
}
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
void ieee80211_vif_release_channel(struct ieee80211_sub_if_data *sdata)
{
mac80211: use channel contexts Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-26 23:24:39 +08:00
WARN_ON(sdata->dev && netif_carrier_ok(sdata->dev));
mac80211: fix iflist_mtx/mtx locking in radar detection The scan code creates an iflist_mtx -> mtx locking dependency, and a few other places, notably radar detection, were creating the opposite dependency, causing lockdep to complain. As scan and radar detection are mutually exclusive, the deadlock can't really happen in practice, but it's still bad form. A similar issue exists in the monitor mode code, but this is only used by channel-context drivers right now and those have to have hardware scan, so that also can't happen. Still, fix these issues by making some of the channel context code require the mtx to be held rather than acquiring it, thus allowing the monitor/radar callers to keep the iflist_mtx->mtx lock ordering. While at it, also fix access to the local->scanning variable in the radar code, and document that radar_detect_enabled is now properly protected by the mtx. All this would now introduce an ABBA deadlock between the DFS work cancelling and local->mtx, so change the locking there a bit to not need to use cancel_delayed_work_sync() but be able to just use cancel_delayed_work(). The work is also safely stopped/removed when the interface is stopped, so no extra changes are needed. Reported-by: Kalle Valo <kvalo@qca.qualcomm.com> Tested-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-12-18 16:43:33 +08:00
lockdep_assert_held(&sdata->local->mtx);
mac80211: introduce channel context skeleton code Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-26 20:37:16 +08:00
mutex_lock(&sdata->local->chanctx_mtx);
__ieee80211_vif_release_channel(sdata);
mutex_unlock(&sdata->local->chanctx_mtx);
}
mac80211: add channel context iterator Drivers may need to iterate the active channel contexts, export an iterator function to allow that. To make it possible, use RCU-safe list functions. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 23:57:42 +08:00
mac80211: assign VLAN channel contexts Make AP_VLAN type interfaces track the AP master channel context so they have one assigned for the various lookups. Don't give them their own refcount etc. since they're just slaves to the AP master. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-12-12 03:38:41 +08:00
void ieee80211_vif_vlan_copy_chanctx(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_sub_if_data *ap;
struct ieee80211_chanctx_conf *conf;
if (WARN_ON(sdata->vif.type != NL80211_IFTYPE_AP_VLAN || !sdata->bss))
return;
ap = container_of(sdata->bss, struct ieee80211_sub_if_data, u.ap);
mutex_lock(&local->chanctx_mtx);
conf = rcu_dereference_protected(ap->vif.chanctx_conf,
lockdep_is_held(&local->chanctx_mtx));
rcu_assign_pointer(sdata->vif.chanctx_conf, conf);
mutex_unlock(&local->chanctx_mtx);
}
mac80211: explicitly copy channels to VLANs where needed Currently the code assigns channel contexts to VLANs (for use by the TX/RX code) when the AP master gets its channel context assigned. This works fine, but in the upcoming radar detection work the VLANs don't require a channel context (during radar detection) and assigning one to them anyway causes issues with locking and also inconsistencies -- a VLAN interface that is added before radar detection would get the channel context, while one added during it wouldn't. Fix these issues moving the channel context copying to a new explicit operation that will not be used in the radar detection code. Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-08 19:07:44 +08:00
void ieee80211_vif_copy_chanctx_to_vlans(struct ieee80211_sub_if_data *sdata,
bool clear)
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_sub_if_data *vlan;
struct ieee80211_chanctx_conf *conf;
ASSERT_RTNL();
if (WARN_ON(sdata->vif.type != NL80211_IFTYPE_AP))
return;
mutex_lock(&local->chanctx_mtx);
/*
* Check that conf exists, even when clearing this function
* must be called with the AP's channel context still there
* as it would otherwise cause VLANs to have an invalid
* channel context pointer for a while, possibly pointing
* to a channel context that has already been freed.
*/
conf = rcu_dereference_protected(sdata->vif.chanctx_conf,
lockdep_is_held(&local->chanctx_mtx));
WARN_ON(!conf);
if (clear)
conf = NULL;
list_for_each_entry(vlan, &sdata->u.ap.vlans, u.vlan.list)
rcu_assign_pointer(vlan->vif.chanctx_conf, conf);
mutex_unlock(&local->chanctx_mtx);
}
mac80211: add channel context iterator Drivers may need to iterate the active channel contexts, export an iterator function to allow that. To make it possible, use RCU-safe list functions. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 23:57:42 +08:00
void ieee80211_iter_chan_contexts_atomic(
struct ieee80211_hw *hw,
void (*iter)(struct ieee80211_hw *hw,
struct ieee80211_chanctx_conf *chanctx_conf,
void *data),
void *iter_data)
{
struct ieee80211_local *local = hw_to_local(hw);
struct ieee80211_chanctx *ctx;
rcu_read_lock();
list_for_each_entry_rcu(ctx, &local->chanctx_list, list)
mac80211: fix channel context iteration During suspend/resume channel contexts might be iterated even if they haven't been re-added to the driver, keep track of this and skip them in iteration. Also use the new status for sanity checks. Also clarify the fact that during HW restart all contexts are iterated over (thanks Eliad.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-12-14 00:42:30 +08:00
if (ctx->driver_present)
iter(hw, &ctx->conf, iter_data);
mac80211: add channel context iterator Drivers may need to iterate the active channel contexts, export an iterator function to allow that. To make it possible, use RCU-safe list functions. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-11 23:57:42 +08:00
rcu_read_unlock();
}
EXPORT_SYMBOL_GPL(ieee80211_iter_chan_contexts_atomic);