- 11 10月, 2013 1 次提交
-
-
由 Luis R. Rodriguez 提交于
If we have a wiphy with an ISO3166-alpha2 regulatory domain programmed with the strict flag set we wait until the wiphy gets its wiphy->regd programmed before allowing regulatory domains hints other than country IE hints from processing on the wiphy. The existing check however discards the possibility of custom regulatory domains having also used the strict flag and these will not have the wiphy->regd set. Custom strict regulatory domains never set the wiphy->regd though as such currently all regulatory hints other than country IE hints are being ignored on these wiphys. All custom strict regulatory domains set the wiphy with the WIPHY_FLAG_CUSTOM_REGULATORY and use wiphy_apply_custom_regulatory(). Enhance the check for the strict ISO3166-alpha2 regulatory domain case by exempting the WIPHY_FLAG_CUSTOM_REGULATORY case. This will enable other regulatory hints to be processed now for these strict custom regulatory domains. Cc: smihir@qti.qualcomm.com Cc: tushnimb@qca.qualcomm.com Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 09 10月, 2013 1 次提交
-
-
由 Luis R. Rodriguez 提交于
It is incorrect to refer to this as 11d as 802.11d was just a proposed amendment, 802.11d was merged to the standard so use proper terminology. Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 01 10月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
If allowed in a country, these channels typically require DFS so mark them as such. Channel 144 is a bit special, it's coming into use now to allow more VHT 80 channels, but world roaming with passive scanning is acceptable anyway. It seems fairly unlikely that it'll be used as the control channel for a VHT AP, but it needs to be present to allow a full VHT connection to an AP that uses it as one of the secondary channels. Also enable VHT 160 on these channels, and also for channels 36-48 to be able to use VHT 160 there. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 25 7月, 2013 1 次提交
-
-
由 Arik Nemtsov 提交于
The current regdomain was not always set by the core. This causes cards with a custom regulatory domain to ignore user initiated changes if done before the card was registered. Signed-off-by: NArik Nemtsov <arik@wizery.com> Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 7月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
restore_regulatory_settings() requires the RTNL to be held, add the missing locking in reg_timeout_work(). Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 04 6月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
get_reg_request_treatment() returns 0 in one case but is defined to return an enum, use the proper value REG_REQ_OK. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 25 5月, 2013 3 次提交
-
-
由 Johannes Berg 提交于
The reg_mutex is similar to the ones I just removed in cfg80211 but even less useful since it protects global data, and we hold the RTNL in all places (except module unload) already. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Since it just does a quick check of the last regulatory request, the function doesn't have to hold the reg mutex but can use RCU instead. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Virtually all code paths in cfg80211 already (need to) hold the RTNL. As such, there's little point in having another four mutexes for various parts of the code, they just cause lock ordering issues (and much of the time, the RTNL and a few of the others need thus be held.) Simplify all this by getting rid of the extra four mutexes and just use the RTNL throughout. Only a few code changes were needed to do this and we can get rid of a work struct for bonus points. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 4月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
When a full scan 2.4 and 5 GHz scan is scheduled, but then the 2.4 GHz part of the scan disables a 5.2 GHz channel due to, e.g. receiving country or frequency information, that 5.2 GHz channel might already be in the list of channels to scan next. Then, when the driver checks if it should do a passive scan, that will return false and attempt an active scan. This is not only wrong but can also lead to the iwlwifi device firmware crashing since it checks regulatory as well. Fix this by not setting the channel flags to just disabled but rather OR'ing in the disabled flag. That way, even if the race happens, the channel will be scanned passively which is still (mostly) correct. Cc: stable@vger.kernel.org Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 06 3月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
For VHT, the wider bandwidths (up to 160 MHz) need to be allowed. Since world roaming only covers the case of connecting to an AP, it can be opened up there, we will rely on the AP to know the local regulations. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 15 2月, 2013 2 次提交
-
-
由 Johannes 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: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Simon 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: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> [remove WIPHY_FLAG_HAS_RADAR_DETECT again -- my mistake] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 12 2月, 2013 1 次提交
-
-
由 Larry Finger 提交于
When a driver requests a specific regulatory domain after cfg80211 already has one, a struct ieee80211_regdomain is leaked. Reported-by: NLarry Finger <Larry.Finger@lwfinger.net> Tested-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 11 1月, 2013 1 次提交
-
-
由 Felix Fietkau 提交于
commit 1a919318 "regulatory: code cleanup" changed is_ht40_allowed without considering that IEEE80211_CHAN_NO_HT40 is not just one flag, but two. This is causing HT40- to be blocked completely. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 09 1月, 2013 2 次提交
-
-
由 Johannes Berg 提交于
My commit 379b82f4 ("regulatory: pass new regdomain to reset function") broke the restore_regulatory_settings() function due to a logic change. Consider this change: - reset_regdomains(true); - cfg80211_regdomain = cfg80211_world_regdom; + reset_regdomains(true, cfg80211_world_regdom); This looks innocent enough, until you realise that the called function (reset_regdomains) also resets the cfg80211_world_regdom pointer, so that the old version of the code would use the new object it pointed to and the new version of the code uses the old object. This lead to a double-free of this object. Since reset_regdomains() sets it to &world_regdom, use that directly. Reported-by: NSujith Manoharan <sujith@msujith.org> Tested-by: NSujith Manoharan <sujith@msujith.org> Reported-by: NBob Copeland <me@bobcopeland.com> Reported-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The uevent callback doesn't protect its access to last_request, which now causes a warning since the conversion to get_last_request(). Fix this by allowing to use RCU protection for last_request. Reported-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 03 1月, 2013 23 次提交
-
-
由 Luis R. Rodriguez 提交于
We should not add new beacon hints even if the wiphy is not world roaming. Without this we were always adding a beacon hint if not world roaming for every non world roaming wiphy interface. Tested-by: NBen Greear <greearb@candelatech.com> Reported-by: NBen Greear <greearb@candelatech.com> Reported-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> [fix locking] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Luis R. Rodriguez 提交于
This will be used later by other code. This has no functional change. Tested-by: NBen Greear <greearb@candelatech.com> Reported-by: NBen Greear <greearb@candelatech.com> Reported-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Luis R. Rodriguez 提交于
Regulatory beacon hints are used to help with world roaming and as it is right now we learn from a beacon hint processed on one wiphy to all other wiphys. The processing of beacon hints however is scheduled and if we have a lot of interfaces we may hit the case that we'll queue a the same beacon hint many times until its processed. To avoid this do a lookup on the queued up beacon hints prior to adding a new beacon hint. If the beacon hint is removed from the pending reg beacon hint list then it would be processed and we'd ensure all wiphys would have learned from it, if its on the pending reg beacon list we'd now find it prior to it being processed. Tested-by: NBen Greear <greearb@candelatech.com> Reported-by: NBen Greear <greearb@candelatech.com> Reported-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Instead of returning an error and filling a pointer return the pointer and an ERR_PTR value in error cases. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
This will allow making freq_reg_info() lock-free. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
To simplify the locking and not require cfg80211_mutex (which nl80211 uses to access the global regdomain) and also to make it possible for drivers to access their wiphy->regd safely, use RCU to protect these pointers. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Instead of assigning after calling the function do it inside the function. This will later avoid a period of time where the pointer is NULL. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The channel bandwidth handling isn't really quite right, it assumes that a 40 MHz channel is really two 20 MHz channels, which isn't strictly true. This is the way the regulatory database handling is defined right now though so remove the logic to handle other channel widths. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's a bug with the world regulatory domain, it can be updated any time which is different from all other regdomains that can only be updated once after a request for them. Fix this by adding a check for "processed" to the reg_is_valid_request() function and clear that when doing a request. While looking at this I also found another locking bug, last_request is protected by the reg_mutex not the cfg80211_mutex so the code in nl80211 is racy. Remove that code as it only tries to prevent an allocation in an error case, which isn't necessary. Then the function can also become static and locking in nl80211 can have a smaller scope. Also change __set_regdom() to do the checks earlier and not different for world/other regdomains. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
wiphy_apply_custom_regulatory() doesn't have to hold the regulatory mutex as it only modifies the given wiphy with the given regulatory domain, it doesn't access any global regulatory data. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Many places that currently check that cfg80211_mutex is held don't actually use any data protected by it. The functions that need to hold the cfg80211_mutex are the ones using the cfg80211_regdomain variable, so add the lock assertion to those and clarify this in the comments. The reason for this is that nl80211 uses the regdom without being able to hold reg_mutex. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The function itself has dual-purpose: it can retrieve from a given regdomain or from the globally installed one. Change it to have a single purpose only: to look up from a given regdomain. Pass the correct regdomain in the freq_reg_info() function instead. This also changes the locking rules for it, no locking is required any more. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Even if it never happens and is hidden behind the debug config option, it's completely useless: the calltrace will only show module loading. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
toupper() only modifies lower-case letters, so the isalpha() check is redundant; remove it. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Use list_splice_tail_init() and also simplify the locking. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
This code is a bit too BUG_ON happy, remove all instances and while doing so make some code a bit smarter by passing the right pointer instead of indices into arrays. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
This is pretty much useless since get_wiphy_idx() always returns true since it's always called with a valid wiphy pointer. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Instead of treating special error codes specially, like -EALREADY, introduce a real enum for all the needed possibilities and use it. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
It would be a major problem if anything were to run concurrently while the module is being unloaded so remove the locking that doesn't help anything. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Clean up various things like indentation, extra parentheses, too many/few line breaks, etc. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no need to unlock before calling queue_regulatory_request(), so simplify the function. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no need to test whether a list is empty or not before iterating. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Use ERR_PTR/IS_ERR to return the result or errors, also do some code cleanups. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-