aboutsummaryrefslogtreecommitdiff
path: root/net/wireless/chan.c
AgeCommit message (Collapse)Author
2014-12-12cfg80211: Fix 160 MHz channels with 80+80 and 160 MHz driversJouni Malinen
The VHT supported channel width field is a two bit integer, not a bitfield. cfg80211_chandef_usable() was interpreting it incorrectly and ended up rejecting 160 MHz channel width if the driver indicated support for both 160 and 80+80 MHz channels. Cc: stable@vger.kernel.org (3.16+) Fixes: 3d9d1d6656a73 ("nl80211/cfg80211: support VHT channel configuration") (however, no real drivers had 160 MHz support it until 3.16) Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-11-04cfg80211: 802.11p OCB mode handlingRostislav Lisovy
This patch adds new iface type (NL80211_IFTYPE_OCB) representing the OCB (Outside the Context of a BSS) mode. When establishing a connection to the network a cfg80211_join_ocb function is called (particular nl80211_command is added as well). A mandatory parameters during the ocb_join operation are 'center frequency' and 'channel width (5/10 MHz)'. Changes done in mac80211 are minimal possible required to avoid many warnings (warning: enumeration value 'NL80211_IFTYPE_OCB' not handled in switch) during compilation. Full functionality (where needed) is added in the following patch. Signed-off-by: Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-10-29cfg80211: fix integer signedness in chandef_primary_freqs()Johannes Berg
The helper function can't ever create negative values, so use u32 pointers as the function arguments as the caller does. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-09-05cfg80211: add Intel Mobile Communications copyrightJohannes Berg
Our legal structure changed at some point (see wikipedia), but we forgot to immediately switch over to the new copyright notice. For files that we have modified in the time since the change, add the proper copyright notice now. Signed-off-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>
2014-05-15cfg80211: pass the actual iftype when calling cfg80211_chandef_dfs_required()Luciano Coelho
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: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-14cfg80211: fix start_radar_detection issueJanusz Dziedzic
After patch: cfg80211/mac80211: refactor cfg80211_chandef_dfs_required() start_radar_detection always fail with -EINVAL. Acked-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25cfg80211: Add attributes describing prohibited channel bandwidthRostislav Lisovy
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: Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25cfg80211: change wiphy_to_dev function nameZhao, Gang
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 <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-25cfg80211: Fix GO Concurrent relaxation on UNII-3Ilan Peer
At some locations, channels 149-165 are considered a single bundle, while at some other locations, e.g., Indonesia, channels 149-161 are considered a single bundle, while channel 165 belongs to a different bundle. This means that: 1. A station interface connection to an AP on channel 165 allows the instantiation of a P2P GO on channels 149-165. 2. A station interface connection to an AP on channels 149-161 does NOT allow the instantiation of a P2P GO on channel 165. Fix this. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-09cfg80211/mac80211: refactor cfg80211_chandef_dfs_required()Luciano Coelho
Some interface types don't require DFS (such as STATION, P2P_CLIENT etc). In order to centralize these decisions, make cfg80211_chandef_dfs_required() take the iftype into consideration. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-09cfg80211: Enable GO operation on indoor channelsIlan Peer
Allow GO operation on a channel marked with IEEE80211_CHAN_INDOOR_ONLY iff there is a user hint indicating that the platform is operating in an indoor environment, i.e., the platform is a printer or media center device. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-09cfg80211: Enable GO operation on additional channelsIlan Peer
Allow GO operation on a channel marked with IEEE80211_CHAN_GO_CONCURRENT iff there is an active station interface that is associated to an AP operating on the same channel in the 2 GHz band or the same UNII band (in the 5 GHz band). This relaxation is not allowed if the channel is marked with IEEE80211_CHAN_RADAR. Note that this is a permissive approach to the FCC definitions, that require a clear assessment that the device operating the AP is an authorized master, i.e., with radar detection and DFS capabilities. It is assumed that such restrictions are enforced by user space. Furthermore, it is assumed, that if the conditions that allowed for the operation of the GO on such a channel change, i.e., the station interface disconnected from the AP, it is the responsibility of user space to evacuate the GO from the channel. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-03-21Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
2014-03-13Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem Conflicts: drivers/net/wireless/ath/ath9k/recv.c
2014-02-25cfg80211: DFS get CAC time from regulatory databaseJanusz Dziedzic
Send Channel Availability Check time as a parameter of start_radar_detection() callback. Get CAC time from regulatory database. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-02-20Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
2014-02-13net: remove unnecessary return'sstephen hemminger
One of my pet coding style peeves is the practice of adding extra return; at the end of function. Kill several instances of this in network code. I suppose some coccinelle wizardy could do this automatically. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-12cfg80211: remove NL80211_FEATURE_P2P_DEVICE_NEEDS_CHANNELJohannes Berg
There's no driver using this flag and consequently no userspace application is actually looking at it. As it seems unlikely for any driver to start using it, remove it and the (very little) code that used it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-02-04cfg80211: consider existing DFS interfacesMichal Kazior
It was possible to break interface combinations in the following way: combo 1: iftype = AP, num_ifaces = 2, num_chans = 2, combo 2: iftype = AP, num_ifaces = 1, num_chans = 1, radar = HT20 With the above interface combinations it was possible to: step 1. start AP on DFS channel by matching combo 2 step 2. start AP on non-DFS channel by matching combo 1 This was possible beacuse (step 2) did not consider if other interfaces require radar detection. The patch changes how cfg80211 tracks channels - instead of channel itself now a complete chandef is stored. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-25cfg80211: allow beaconing after DFS CACJanusz Dziedzic
Allow beconing after we pass Channel Availability Check (CAC). Allow non-DFS and DFS channels mix. All DFS channels have to be in NL80211_DFS_AVAILABLE state (pass CAC). Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-25cfg80211: add missing break in cfg80211_get_chan_state()Johannes Berg
Improve readability of the function by adding the break, there's no functional impact but it's confusing to fall through. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-25cfg80211: DFS check chandef usable before CACJanusz Dziedzic
Check chandef we get in CAC request is usable for CAC. All channels have to be DFS channels. Allow DFS_USABLE and DFS_AVAILABLE channels mix. At least one channel has to be DFS_USABLE (require CAC). Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-25cfg80211: add helper functions for start/end freqJanusz Dziedzic
Add helper fuctions for start/end freq. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-25cfg80211: consolidate passive-scan and no-ibss flagsLuis R. Rodriguez
These two flags are used for the same purpose, just combine them into a no-ir flag to annotate no initiating radiation is allowed. Old userspace sending either flag will have it treated as the no-ir flag. To be considerate to older userspace we also send both the no-ir flag and the old no-ibss flags. Newer userspace will have to be aware of older kernels. Update all places in the tree using these flags with the following semantic patch: @@ @@ -NL80211_RRF_PASSIVE_SCAN +NL80211_RRF_NO_IR @@ @@ -NL80211_RRF_NO_IBSS +NL80211_RRF_NO_IR @@ @@ -IEEE80211_CHAN_PASSIVE_SCAN +IEEE80211_CHAN_NO_IR @@ @@ -IEEE80211_CHAN_NO_IBSS +IEEE80211_CHAN_NO_IR @@ @@ -NL80211_RRF_NO_IR | NL80211_RRF_NO_IR +NL80211_RRF_NO_IR @@ @@ -IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_NO_IR +IEEE80211_CHAN_NO_IR @@ @@ -(NL80211_RRF_NO_IR) +NL80211_RRF_NO_IR @@ @@ -(IEEE80211_CHAN_NO_IR) +IEEE80211_CHAN_NO_IR Along with some hand-optimisations in documentation, to remove duplicates and to fix some indentation. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> [do all the driver updates in one go] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-10-28nl80211/cfg80211: enable DFS for IBSS modeSimon Wunderlich
To use DFS in IBSS mode, userspace is required to react to radar events. It can inform nl80211 that it is capable of doing so by adding a NL80211_ATTR_HANDLE_DFS attribute when joining the IBSS. This attribute is supplied to let the kernelspace know that the userspace application can and will handle radar events, e.g. by intiating channel switches to a valid channel. DFS channels may only be used if this attribute is supplied and the driver supports it. Driver support will be checked even if a channel without DFS will be initially joined, as a DFS channel may be chosen later. Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> [fix attribute name in commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-09-26cfg80211: export cfg80211_chandef_dfs_requiredSimon Wunderlich
It will be used later by the IBSS CSA implementation of mac80211. Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-06-18nl80211/cfg80211: add 5 and 10 MHz defines and wiphy flagSimon Wunderlich
Add defines for 5 and 10 MHz channel width and fix channel handling functions accordingly. Also check for and report the WIPHY_FLAG_SUPPORTS_5_10_MHZ capability. Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> [fix spelling in comment] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15cfg80211: allow drivers to selectively disable 80/160 MHzJohannes Berg
Some drivers might support 80 or 160 MHz only on some channels for whatever reason, so allow them to disable these channel widths. Also maintain the new flags when regulatory bandwidth limitations would disable these wide channels. Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15nl80211/cfg80211: add radar detection command/eventSimon Wunderlich
Add new NL80211_CMD_RADAR_DETECT, which starts the Channel Availability Check (CAC). This command will also notify the usermode about events (CAC finished, CAC aborted, radar detected, NOP finished). Once radar detection has started it should continuously monitor for radars as long as the channel is active. This patch enables DFS for AP mode in nl80211/cfg80211. Based on original patch by Victor Goldenshtein <victorg@ti.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> [remove WIPHY_FLAG_HAS_RADAR_DETECT again -- my mistake] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-03cfg80211: adjacent 80+80 MHz channel segments are invalidJohannes Berg
In that case, it's really a 160 MHz channel, so disallow this configuration. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-12-04cfg80211: check no-OFDM flag for channels wider than 20 MHzJohannes Berg
For channels wider than 20 MHz OFDM will be used, so when checking whether or not a channel is usable, check for the no-OFDM flag if the channel is wider than 20 MHz. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-27cfg80211: rework chandef checking and export itJohannes Berg
Some of the chandef checking that we do in cfg80211 to check if a channel is supported or not is also needed in mac80211, so rework that a bit and export the functions that are needed. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-26nl80211/cfg80211: support VHT channel configurationJohannes Berg
Change nl80211 to support specifying a VHT (or HT) using the control channel frequency (as before) and new attributes for the channel width and first and second center frequency. The old channel type is of course still supported for HT. Also change the cfg80211 channel definition struct to support these by adding the relevant fields to it (and removing the _type field.) This also adds new helper functions: - cfg80211_chandef_create to create a channel def struct given the control channel and channel type, - cfg80211_chandef_identical to check if two channel definitions are identical - cfg80211_chandef_compatible to check if the given channel definitions are compatible, and return the wider of the two This isn't entirely complete, but that doesn't matter until we have a driver using it. In particular, it's missing - regulatory checks on the usable bandwidth (if that even makes sense) - regulatory TX power (database can't deal with it) - a proper channel compatibility calculation for the new channel types Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-26cfg80211: pass a channel definition structJohannes Berg
Instead of passing a channel pointer and channel type to all functions and driver methods, pass a new channel definition struct. Right now, this struct contains just the control channel and channel type, but for VHT this will change. Also, add a small inline cfg80211_get_chandef_type() so that drivers don't need to use the _type field of the new structure all the time, which will change. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-10-18cfg80211: add cfg80211 exported function tracingBeni Lev
Also add tracing to the API functions that drivers (and mac80211) can call in cfg80211. Signed-off-by: Beni Lev <beni.lev@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-10-18cfg80211: add wrappers for registered_device_opsHila Gonen
This will allow adding central tracing like in mac80211. Signed-off-by: Hila Gonen <hila.gonen@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-08-20cfg80211: add P2P Device abstractionJohannes Berg
In order to support using a different MAC address for the P2P Device address we must first have a P2P Device abstraction that can be assigned a MAC address. This abstraction will also be useful to support offloading P2P operations to the device, e.g. periodic listen for discoverability. Currently, the driver is responsible for assigning a MAC address to the P2P Device, but this could be changed by allowing a MAC address to be given to the NEW_INTERFACE command. As it has no associated netdev, a P2P Device can only be identified by its wdev identifier but the previous patches allowed using the wdev identifier in various APIs, e.g. remain-on-channel. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-13cfg80211: reduce monitor interface trackingJohannes Berg
Revert commit b78e8ceac23655e1e06b30aa95ab11742d1ac7c0 ("cfg80211: track monitor channel") and remove the set_monitor_enabled() callback. Due to the tracking happening in NETDEV_PRE_UP, it had introduced bugs because the monitor interface callback would be called before the device was started. It looks like there's no way to fix this, and using NETDEV_PRE_UP is broken anyway (since there's no NETDEV_UP_FAIL), so remove all that code, track interfaces in NETDEV_UP and also stop tracking the monitor channel in cfg80211. This mostly reverts to before the tracking, except that we keep the interface count tracking so that setting the monitor channel can be rejected properly. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-12cfg80211: ignore channel state for stopped AP/mesh interfacesFelix Fietkau
Without this change, running AP + station on the same wiphy does not work since the commit "cfg80211: add channel checking for iface combinations". The stopped AP prevents the client from connecting to an AP on a different channel. Signed-off-by: Felix Fietkau <nbd@openwrt.org> [line-break commit message to < 72 chars] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-12cfg80211: fix locking and lockdep complaintsJohannes Berg
To call cfg80211_get_chan_state() we need to lock the wdev, so we need to lock the wdev_iter mutex in cfg80211_can_use_iftype_chan(). This needs to use nested locking for lockdep. Also, cfg80211_get_chan_state() doesn't actually use the rdev, so remove that completely including the lock assertion that isn't needed. Reported-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-29cfg80211: track monitor channelMichal Kazior
Make it even more obvious we support single monitor channel. This will allow us to remove .get_channel. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-29cfg80211: refuse to .set_monitor_channel when non-monitors are presentMichal Kazior
Having .set_monitor_channel work with non-monitor interfaces running would make interface combinations accounting ambiguous. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-29cfg80211: introduce cfg80211_get_chan_stateMichal Kazior
Helper function for finding out which channel is used by a given interface. An exclusive channel can be used only by a single interface. This is mainly for non-fixed channel IBSS handling. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-06cfg80211: clarify set_channel APIsJohannes Berg
Now that we've removed all uses of the set_channel API except for the monitor channel and in libertas, clarify this. Split the libertas mesh use into a new libertas_set_mesh_channel() operation, just to keep backward compatibility, and rename the normal set_channel() to set_monitor_channel(). Also describe the desired set_monitor_channel() semantics more clearly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05cfg80211: simplify cfg80211_can_beacon_sec_chan APIJohannes Berg
Change cfg80211_can_beacon_sec_chan() to return true if there is no secondary channel to simplify all the current users of it. They all check the channel type before calling the function because it returns false if there's no secondary channel. Also actually document the return value. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-05-16cfg80211: fix cfg80211_can_beacon_sec_chan prototypeJohannes Berg
It should return bool, not int. The function even does return true/false. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-06nl80211: Parse channel type attribute in an ibss join requestAlexander Simon
Prepare cfg80211 for IBSS HT: * extend cfg80211 ibss struct with channel_type * Check if extension channel can be used * Export can_beacon_sec_chan for use in mac80211 (will be called from ibss.c later). Signed-off-by: Alexander Simon <an.alexsimon@googlemail.com> [siwu@hrz.tu-chemnitz.de: Updates] * fix cfg80211_can_beacon_ext_chan comment * remove implicit channel_type enum assumptions * remove radar channel flags check * add HT IBSS feature flag * reword commit message Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-11-18cfg80211: fix can_beacon_sec_chan, reenable HT40Mark Mentovai
This follows wireless-testing 9236d838c920e90708570d9bbd7bb82d30a38130 ("cfg80211: fix extension channel checks to initiate communication") and fixes accidental case fall-through. Without this fix, HT40 is entirely blocked. Signed-off-by: Mark Mentovai <mark@moxienet.com> Cc: stable@kernel.org Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-11-16cfg80211: fix extension channel checks to initiate communicationLuis R. Rodriguez
When operating in a mode that initiates communication and using HT40 we should fail if we cannot use both primary and secondary channels to initiate communication. Our current ht40 allowmap only covers STA mode of operation, for beaconing modes we need a check on the fly as the mode of operation is dynamic and there other flags other than disable which we should read to check if we can initiate communication. Do not allow for initiating communication if our secondary HT40 channel has is either disabled, has a passive scan flag, a no-ibss flag or is a radar channel. Userspace now has similar checks but this is also needed in-kernel. Reported-by: Jouni Malinen <jouni.malinen@atheros.com> Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-06-02cfg80211: don't refuse HT20 channels on devices that don't support HT40Helmut Schaa
Don't refuse HT20 channels on devices that don't support HT40. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-17 03:28:26 +0000