- 15 May, 2014 3 commits
-
-
Andrei Otcheretianski authored
Track current csa counter value and use it to update mgmt frames at the provided offsets. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
Luciano Coelho <luciano.coelho@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Andrei Otcheretianski authored
Add NL80211_ATTR_CSA_C_OFFSETS_TX which holds an array of offsets to the CSA counters which should be updated when sending a management frames with NL80211_CMD_FRAME. This API should be used by the drivers that wish to keep the CSA counter updated in probe responses, but do not implement probe response offloading and so, do not use ieee80211_proberesp_get function. Signed-off-by:
-
Luciano Coelho authored
There is no need to pass NL80211_IFTYPE_UNSPECIFIED when calling cfg80211_chandef_dfs_required() since we always already have the interface type. So, pass the actual interface type instead. Additionally, have cfg80211_chandef_dfs_required() WARN if the passed interface type is NL80211_IFTYPE_UNSPECIFIED, so we can detect problems more easily. Tested-by:
Janusz Dziedzic <janusz.dziedzic@tieto.com> Reported-by:
Eliad Peller <eliad@wizery.com> Signed-off-by:
-
- 14 May, 2014 1 commit
-
-
Janusz Dziedzic authored
After patch: cfg80211/mac80211: refactor cfg80211_chandef_dfs_required() start_radar_detection always fail with -EINVAL. Acked-by:
-
- 13 May, 2014 1 commit
-
-
Felix Fietkau authored
At the moment, the ath9k/ath10k DFS module only supports detecting ETSI radar patterns. Add a bitmap in the interface combinations, indicating which DFS regions are supported by the detector. If unset, support for all regions is assumed. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
- 09 May, 2014 1 commit
-
-
Johannes Berg authored
When the driver fails during HW restart or resume, the whole stack goes into a very confused state with interfaces being up while the hardware is down etc. Address this by shutting down everything; we'll run into a lot of warnings in the process but that's better than having the whole stack get messed up. Reviewed-by:
Arik Nemtsov <arik@wizery.com> Signed-off-by:
-
- 08 May, 2014 3 commits
-
-
Luciano Coelho authored
Commit 59af6928 (mac80211: fix CSA tx queue stopping) introduced a sparse warning: net/mac80211/cfg.c:3274:5: warning: symbol '__ieee80211_channel_switch' was not declared. Should it be static? Fix it by declaring the function static. Signed-off-by:
-
Luciano Coelho authored
When trying to generate documentation, at least xmldocs, we get the following warning: Warning(include/net/cfg80211.h:461): No description found for parameter 'nl80211_iftype' Fix it by adding the iftype argument name to the cfg80211_chandef_dfs_required() function declaration. Reported-and-tested-by:
Masanari Iida <standby24x7@gmail.com> Signed-off-by:
-
Michal Kazior authored
It doesn't make much sense to leave a crippled interface running. As a side effect this will unblock tx queues with CSA reason immediately after failure instead of until after userspace requests interface to stop. This also gives userspace an opportunity to indirectly see CSA failure. Signed-off-by:
Michal Kazior <michal.kazior@tieto.com> [small code cleanup] Signed-off-by:
-
- 07 May, 2014 2 commits
-
-
Loic Poulain authored
If gpio controller requires waiting for read and write GPIO values, then we have to use the gpio cansleep api. Fix the rfkill_gpio_set_power which calls only the nonsleep version (causing kernel warning). There is no problem to use the cansleep version here because we are not in IRQ handler or similar context (cf rfkill_set_block). Signed-off-by:
Loic Poulain <loic.poulain@intel.com> Signed-off-by:
-
Michal Kazior authored
It is not guaranteed that multi-vif channel switching is tightly synchronized. It makes sense to ignore cqm (missing beacons, et al) while csa is progressing and re-check it after it completes. Signed-off-by:
-
- 06 May, 2014 3 commits
-
-
Michal Kazior authored
This exports a new cfg80211_stop_iface() function. This is intended for driver internal interface combination management and channel switching. Due to locking issues (it re-enters driver) the call is asynchronous and uses cfg80211 event list/worker. Signed-off-by:
-
Michal Kazior authored
Improves readability and modularity. Signed-off-by:
-
Michal Kazior authored
It was possible for tx queues to be stuck stopped if AP CSA finalization failed. In that case neither stop_ap nor do_stop woke the queues up. This means it was impossible to perform tx at all until driver was reloaded or a successful CSA was performed later. It was possible to solve this in a simpler manner however this is more robust and future proof (having multi-vif CSA in mind). New sdata->csa_block_tx is introduced to keep track of which interfaces requested tx to be blocked for CSA. This is required because mac80211 stops all tx queues for that purpose. This means queues must be awoken only when last tx-blocking CSA interface is finished. It is still possible to have tx queues stopped after CSA failure but as soon as offending interfaces are stopped from userspace (stop_ap or ifdown) tx queues are woken up properly. Signed-off-by:
-
- 05 May, 2014 3 commits
-
-
Johannes Berg authored
The 'local' variable in __ieee80211_vif_copy_chanctx_to_vlans() is only used/needed when lockdep is compiled in, mark it as such to avoid compile warnings in the other case. While at it, fix some indentation where it's used. Reviewed-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Arik Nemtsov authored
With new additions planned, this code is getting too big for cfg.c. Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by:
-
Arik Nemtsov authored
Expose a new tdls flag for the public ieee80211_sta struct. This can be used in some rate control decisions. Signed-off-by:
-
- 29 Apr, 2014 2 commits
-
-
Johannes Berg authored
These BUG_ON statements should never trigger, but in the unlikely event that somebody does manage don't stop everything but simply exit the code path with an error. Leave the one BUG_ON where changing it would result in a NULL pointer dereference. Signed-off-by: -
Johannes Berg authored
These really can't trigger unless somebody messes up the code, but don't make debugging it needlessly complicated, WARN and return instead of BUG_ON(). Signed-off-by:
-
- 28 Apr, 2014 5 commits
-
-
Jouni Malinen authored
mac80211 takes care of all the needed steps for hwsim, so indicate support for this capability. Signed-off-by:
Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by:
-
Jouni Malinen authored
Implement the new cfg80211 capability to enable mac80211-based drivers to support for dynamic channel bandwidth changes (e.g., HT 20/40 MHz changes). Signed-off-by:
-
Jouni Malinen authored
This extends NL80211_CMD_SET_CHANNEL to allow dynamic channel bandwidth changes in AP mode (including P2P GO) during a lifetime of the BSS. This can be used to implement, e.g., HT 20/40 MHz co-existence rules on the 2.4 GHz band. Signed-off-by:
-
Zhao, Gang authored
P2P_DEVICE doesn't support ieee80211_bss_info_change_notify() for now, so it's not needed to set changed flags for P2P_DEVICE. Signed-off-by:
Zhao, Gang <gamerh2o@gmail.com> Signed-off-by:
-
Zhao, Gang authored
ieee80211_assign_chanctx() checks if local->use_chanctx is true, so the two code block related to ieee80211_assign_chanctx() can be moved into above if clause, emphasize that these code are executed only if local->use_chanctx is true. Signed-off-by:
-
- 25 Apr, 2014 16 commits
-
-
Rostislav Lisovy authored
Current code checks if the 20MHz bandwidth is allowed for particular channel -- if it is not, the channel is disabled. Since we need to use 5/10 MHz channels, this code is modified in the way that the default bandwidth to check is 5MHz. If the maximum bandwidth allowed by the channel is smaller than 5MHz, the channel is disabled. Otherwise the channel is used and the flags are set according to the bandwidth allowed by the channel. Signed-off-by:
Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz> Signed-off-by:
-
Rostislav Lisovy authored
Since there are frequency bands (e.g. 5.9GHz) allowing channels with only 10 or 5 MHz bandwidth, this patch adds attributes that allow keeping track about this information. When channel attributes are reported to user-space, make sure to not break old tools, i.e. if the 'split wiphy dump' is enabled, report the extra attributes (if present) describing the bandwidth restrictions. If the 'split wiphy dump' is not enabled, completely omit those channels that have flags set to either IEEE80211_CHAN_NO_10MHZ or IEEE80211_CHAN_NO_20MHZ. Add the check for new bandwidth restriction flags in cfg80211_chandef_usable() to comply with the restrictions. Signed-off-by:
-
Zhao, Gang authored
Return NOTIFY_DONE if we don't care this time's notification, return NOTIFY_OK if we successfully handled this time's notification. That's the formal way to do it. Signed-off-by:
-
Zhao, Gang authored
Return NOTIFY_DONE if we don't care this time's notification, return NOTIFY_OK if we successfully handled this time's notification. That's the formal way to do it. Signed-off-by:
-
Zhao, Gang authored
Name wiphy_to_rdev is more accurate to describe what the function does, i.e., return a pointer pointing to struct cfg80211_registered_device. Signed-off-by:
-
Zhao, Gang authored
Name "dev" is too common and ambiguous, let all the pointer name pointing to struct cfg80211_registered_device be "rdev". This can improve code readability and consistency(since other places have already called it rdev). Signed-off-by:
-
Zhao, Gang authored
The BUG_ON(!err) can't be triggered in the code path, so remove it. Signed-off-by:
-
Zhao, Gang authored
And some code style changes in the function, and correct a typo in comment. Signed-off-by:
-
Marek Kwaczynski authored
Some chips can encrypt managment frames in HW, but require generated IV in the frame. Add a key flag that allows us to achieve this. Signed-off-by:
Marek Kwaczynski <marek.kwaczynski@tieto.com> [use BIT(0) to fill that spot, fix indentation] Signed-off-by:
-
Michal Kazior authored
It doesn't make much sense to store refcount in the chanctx structure. One still needs to hold chanctx_mtx to get the value safely. Besides, refcount isn't on performance critical paths. This will make implementing chanctx reservation refcounting a little easier. Signed-off-by:
-
Michal Kazior authored
Channel context refcount is protected by chanctx_mtx. Accessing the value without holding the mutex is racy. RCU section didn't guarantee anything here. Theoretically ieee80211_channel_switch() could fail to see refcount change and read "1" instead of, e.g. "2". This means mac80211 could accept CSA even though it shouldn't have. Signed-off-by:
-
Michal Kazior authored
The function did a little too much. Split it up so the code can be easily reused in the future. Signed-off-by:
-
Michal Kazior authored
The function did a little too much. Split it up so the code can be easily reused in the future. Signed-off-by:
-
Michal Kazior authored
Use a separate function to look for reservation chanctx. For multi-interface/channel reservation search sematics differ slightly. The new routine allows reservations to be merged with chanctx that are already reserved by other interface(s). Signed-off-by:
-
Michal Kazior authored
This allows new vifs to be assigned to a chanctx as long as chanctx's reservation chandefs (if any) and chanctx's current chandef (implied by assigned vifs at the time, if any) and the new vif chandef are all compatible. This implies it is impossible to assign a new vif to an in-place reservation chanctx. This gives no advantages for single-channel hardware. It makes sense for multi-channel hardware only. Signed-off-by:
-
Michal Kazior authored
This can be useful. Provides a more straghtforward way to iterate over interfaces taking part in chanctx reservation and allows tracking chanctx usage explicitly. The structure is protected by local->chanctx_mtx. Signed-off-by:
-
