- 25 Nov, 2013 40 commits
-
-
Luis R. Rodriguez authored
Certain vendors may want to disable the processing of country IEs so that they can continue using the regulatory domain the driver or user has set. Currently there is no way to stop the core from processing country IEs, so add support to the core to ignore country IE hints. Cc: Mihir Shete <smihir@qti.qualcomm.com> Cc: Henri Bahini <hbahini@qca.qualcomm.com> Cc: Tushnim Bhattacharyya <tushnimb@qca.qualcomm.com> Signed-off-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Luis R. Rodriguez authored
802.11 cards may have different country IE parsing behavioural preferences and vendors may want to support these. These preferences were managed by the REGULATORY_CUSTOM_REG and the REGULATORY_STRICT_REG flags and their combination. Instead of using this existing notation, split out the country IE behavioural preferences as a new flag. This will allow us to add more customizations easily and make the code more maintainable. Cc: Mihir Shete <smihir@qti.qualcomm.com> Cc: Henri Bahini <hbahini@qca.qualcomm.com> Cc: Tushnim Bhattacharyya <tushnimb@qca.qualcomm.com> Signed-off-by:
-
Luis R. Rodriguez authored
We'll expand this later, this will make it easier to classify and review what things are related to regulatory or not. Coccinelle only missed 4 hits, which I had to do manually, supplying the SmPL in case of merge conflicts. @@ struct wiphy *wiphy; @@ -wiphy->flags |= WIPHY_FLAG_CUSTOM_REGULATORY +wiphy->regulatory_flags |= REGULATORY_CUSTOM_REG @@ expression e; @@ -e->flags |= WIPHY_FLAG_CUSTOM_REGULATORY +e->regulatory_flags |= REGULATORY_CUSTOM_REG @@ struct wiphy *wiphy; @@ -wiphy->flags &= ~WIPHY_FLAG_CUSTOM_REGULATORY +wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG @@ struct wiphy *wiphy; @@ -wiphy->flags & WIPHY_FLAG_CUSTOM_REGULATORY +wiphy->regulatory_flags & REGULATORY_CUSTOM_REG @@ struct wiphy *wiphy; @@ -wiphy->flags |= WIPHY_FLAG_STRICT_REGULATORY +wiphy->regulatory_flags |= REGULATORY_STRICT_REG @@ expression e; @@ -e->flags |= WIPHY_FLAG_STRICT_REGULATORY +e->regulatory_flags |= REGULATORY_STRICT_REG @@ struct wiphy *wiphy; @@ -wiphy->flags &= ~WIPHY_FLAG_STRICT_REGULATORY +wiphy->regulatory_flags &= ~REGULATORY_STRICT_REG @@ struct wiphy *wiphy; @@ -wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY +wiphy->regulatory_flags & REGULATORY_STRICT_REG @@ struct wiphy *wiphy; @@ -wiphy->flags |= WIPHY_FLAG_DISABLE_BEACON_HINTS +wiphy->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS @@ expression e; @@ -e->flags |= WIPHY_FLAG_DISABLE_BEACON_HINTS +e->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS @@ struct wiphy *wiphy; @@ -wiphy->flags &= ~WIPHY_FLAG_DISABLE_BEACON_HINTS +wiphy->regulatory_flags &= ~REGULATORY_DISABLE_BEACON_HINTS @@ struct wiphy *wiphy; @@ -wiphy->flags & WIPHY_FLAG_DISABLE_BEACON_HINTS +wiphy->regulatory_flags & REGULATORY_DISABLE_BEACON_HINTS Generated-by: Coccinelle SmPL Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Peter Senna Tschudin <peter.senna@gmail.com> Cc: Mihir Shete <smihir@qti.qualcomm.com> Cc: Henri Bahini <hbahini@qca.qualcomm.com> Cc: Tushnim Bhattacharyya <tushnimb@qca.qualcomm.com> Signed-off-by:
-
Chun-Yeow Yeoh authored
use put_unaligned_le16 for precedence value in mesh channel switch support Signed-off-by:
Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by:
-
Karl Beldan authored
Signed-off-by:
Karl Beldan <karl.beldan@rivierawaves.com> Signed-off-by:
-
Luis R. Rodriguez authored
This reflects that case is now completely separated. Signed-off-by:
-
Luis R. Rodriguez authored
This splits up the driver regulatory update on its own, this helps simplify the reading the case. Signed-off-by:
-
Luis R. Rodriguez authored
This splits out the user regulatory update on its own, this helps simplify reading the case. Signed-off-by:
-
Luis R. Rodriguez authored
This splits up the core regulatory update to be set on its own helper. This should make it easier to read exactly what type of requests should be expected there. In this case its clear that NL80211_REGDOM_SET_BY_CORE is only used by the core for updating the world regulatory domain. This is consistant with the nl80211.h documentation. Signed-off-by:
-
Luis R. Rodriguez authored
last_request is RCU protected, since we're getting it on set_regdom() we might as well pass it to ensure the same request is being processed, otherwise there is a small race it could have changed. This makes processing of the request atomic. Signed-off-by:
-
Luis R. Rodriguez authored
Drivers that set the WIPHY_FLAG_CUSTOM_REGULATORY skip the core world regulatory domain updates, but do want their reg_notifier() called. Move the check for this closer to the source of the check that detected skipped was required and while at it add a helper for the notifier calling. This has no functional changes. This brings together the place where we call the reg_notifier() will be called. Signed-off-by:
-
Luis R. Rodriguez authored
It seems some out of tree drivers were using a regulatory_hint("00") to trigger off the wiphy regulatory notifier, for those cases just setting the WIPHY_FLAG_CUSTOM_REGULATORY would suffice to call the reg_notifier() for a world regulatory domain update. If drivers find other needs for calling the reg_notifier() a proper implemenation is preferred. Signed-off-by: -
Luis R. Rodriguez authored
All the regulatory request process routines use the same pattern. Signed-off-by:
-
Luis R. Rodriguez authored
This enforces proper RCU APIs accross the code. Signed-off-by:
-
Luis R. Rodriguez authored
This is common code, this reduces the chance of making a mistake of how we free it. Signed-off-by:
-
Luis R. Rodriguez authored
By dealing with non country IE conficts first we can shift the code that deals with the conflict to the left. This has no functional changes. Signed-off-by:
-
Luis R. Rodriguez authored
This is the last split up of the old unified __regultory_hint() processing set of functionality, it moves the country IE processing all on its own. This makes it easier to follow and read what exactly is going on for the case of processing country IEs. Signed-off-by:
-
Luis R. Rodriguez authored
This makes the code easier to read and follow. Signed-off-by:
-
Luis R. Rodriguez authored
This makes the code path easier to read and lets us split out some functionality that is only user specific, that makes it easier to read the other types of requests. Signed-off-by:
-
Luis R. Rodriguez authored
This makes the code path easier to read for the core case. Signed-off-by:
-
Luis R. Rodriguez authored
Currently nl80211 allows userspace to send the kernel a bogus regulatory domain with at most 32 rules set and it won't reject it until after its allocated memory. Let's be smart about it and take advantage that the last_request is now available under RTNL and check if the alpha2 matches an expected request and reject any bogus userspace requests prior to hitting the memory allocator. Signed-off-by:
-
Luis R. Rodriguez authored
If a custom regulatory domain is passed and if a rule for a channel indicates it should be disabled that channel should always remain disabled as per its documentation and design. Likewise if WIPHY_FLAG_STRICT_REGULATORY flag is set and a regulatory_hint() is issued if a channel is disabled that channel should remain disabled. Without this change only drivers that set the _orig flags appropriately on their own would ensure disallowed channels remaind disabled. This helps drivers save code by relying on the APIS provided to entrust channels that should not be enabled be respected by only having to use wiphy_apply_custom_regulatory() or regulatory_hint() with the WIPHY_FLAG_STRICT_REGULATORY set. If wiphy_apply_custom_regulatory() is used together with WIPHY_FLAG_STRICT_REGULATORY and a regulatory_hint() issued later, the incoming regulatory domain can override previously set _orig parameters from the initial custom regulatory setting. Signed-off-by:
-
Luis R. Rodriguez authored
If genregdb.awk assumes the file will end with an extra empty line or a comment line. This is could not be true so just address this. Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Luis R. Rodriguez authored
This has no functional change, this just lets us reuse helpers at a later time. Signed-off-by:
-
Max Stepanov authored
This adds generic cipher scheme support to mac80211, such schemes are fully under control by the driver. On hw registration drivers may specify additional HW ciphers with a scheme how these ciphers have to be handled by mac80211 TX/RR. A cipher scheme specifies a cipher suite value, a size of the security header to be added to or stripped from frames and how the PN is to be verified on RX. Signed-off-by:
Max Stepanov <Max.Stepanov@intel.com> Signed-off-by:
-
Janusz Dziedzic authored
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:
-
Janusz Dziedzic authored
To report channel width correctly we have to send correct channel parameters from mac80211 when calling cfg80211_cac_event(). This is required in case of using channel width higher than 20MHz and we have to set correct dfs channel state after CAC (NL80211_DFS_AVAILABLE). Signed-off-by:
-
Johannes Berg authored
There's no code calling ieee80211_key_replace() with both arguments NULL and it wouldn't make sense, but in the interest of maintainability add a warning for it. As a side effect, this also shuts up a smatch warning. Signed-off-by: -
Johannes Berg authored
As the flag is entirely implemented in cfg80211, it should have been a global feature flag (which I believe didn't exist at the time). However, there's no reason to allow drivers to unset the flag, so don't allow it and remove the validation of NL80211_SCAN_FLAG_FLUSH. Signed-off-by: -
Johannes Berg authored
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 authored
Coverity points out that checking assoc_data->ie is completely useless since it's an array in the struct and can't be NULL - remove the useless checks. Signed-off-by: -
Thomas Pedersen authored
802.11-2012 13.3.1 implicitly limits the mesh local link ID range to that of AID, since for mesh PS the local link ID must be indicated in the TIM IE, which only holds IEEE80211_MAX_AID bits. Also the code was allowing a local link ID of 0, but this is not correct since that TIM bit is used for indicating buffered mcast frames. Generate a random, unique, link ID from 1 - 2007, and drop a modulo conversion for the local link ID, but keep it for the peer link ID in case he chose something > MAX_AID. Signed-off-by:
Thomas Pedersen <thomas@cozybit.com> Signed-off-by:
-
Thomas Pedersen authored
Signed-off-by:
-
Thomas Pedersen authored
Signed-off-by:
-
Thomas Pedersen authored
If we store the peer link ID right after initializing a new neighbor, there is no need to do it later in the peering FSM. Signed-off-by:
-
Thomas Pedersen authored
Signed-off-by:
-
Thomas Pedersen authored
Signed-off-by:
-
Bob Copeland authored
Said function was removed some time ago. Signed-off-by:
Bob Copeland <bob@cozybit.com> Signed-off-by:
-
Bob Copeland authored
All other paths return an error code, do the same here. Signed-off-by:
-
Bob Copeland authored
The ignore_plink_timer flag is set when doing mod_timer() if the timer was not previously active. This is to avoid executing the timeout if del_timer() was subsequently called. However, del_timer() only happens if we are moving to ESTAB state or get a close frame while in HOLDING. We cannot leave HOLDING and re-enter ESTAB unless we receive a close frame (in which case ignore_plink_timer is already set) or if the timeout expires, so there actually isn't a case where this is needed on mod_timer(). Signed-off-by:
-
