DFS requirement for ETSI domain (section 4.7.1.4 in
ETSI EN 301 893 V1.8.1) is the only one which explicitly
states that once DFS channel is marked as available afer
the CAC, this channel will remain in available state even
moving to a different operating channel. But the same is
not explicitly stated in FCC DFS requirement. Also, Pre-CAC
requriements are not explicitly mentioned in FCC requirement.
Current implementation in keeping DFS channel in available
state is same as described in ETSI domain.

For non-ETSI DFS domain, this patch gives a grace period of 2 seconds
since the completion of successful CAC before moving the channel's
DFS state to 'usable' from 'available' state. The same grace period
is checked against the channel's dfs_state_entered timestamp while
deciding if a DFS channel is available for operation. There is a new
radar event, NL80211_RADAR_PRE_CAC_EXPIRED, reported when DFS channel
is moved from available to usable state after the grace period. Also
make sure the DFS channel state is reset to usable once the beaconing
operation on that channel is brought down (like stop_ap, leave_ibss
and leave_mesh) in non-ETSI domain.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

It is needed for another cfg80211 helper that will be out of reg.c so
move it to common util.c file and make it non-static.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no harm in having drivers read the list, since they can
use RCU protection or RTNL locking; allow this to not require
each and every driver to also implement its own bookkeeping.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This enum is already perfectly aliased to enum nl80211_band, and
the only reason for it is that we get IEEE80211_NUM_BANDS out of
it. There's no really good reason to not declare the number of
bands in nl80211 though, so do that and remove the cfg80211 one.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of having this Kconfig option, which just *floods* the
kernel log,
 * remove the per-channel prints that are fairly useless anyway
 * convert the conditional printing to pr_debug()
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The rule definitions here aren't really valid, they would
be rejected if it came from userspace due to the bandwidth
specified being bigger than the rule's width.

This is fairly much inconsequential since the other rules
around them do enable the bandwidth, but express that better
using the NL80211_RRF_AUTO_BW flag.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

cfg80211 module prints a lot of messages like below. Actually printing
once is acceptable but sometimes it will print again and again, it looks
very annoying. It is better to change these detail messages to debugging
only.

cfg80211: World regulatory domain updated:
cfg80211:  DFS Master region: unset
cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)

The changes in this patch is to replace pr_info with pr_debug in function
print_rd_rules and print_regdomain_info
Signed-off-by: NDave Young <dyoung@redhat.com>
[change some pr_err() statements to at least keep the alpha2]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The first leak occurs when entering the default case
in the switch for the initiator in set_regdom.
The second leaks a platform_device struct if the
platform registration in regulatory_init succeeds but
the sub sequent regulatory hint fails due to no memory.
Signed-off-by: NOla Olsson <ola.olsson@sonymobile.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The same piece of code appears at two places. Make a function from it.
Signed-off-by: NMichal Sojka <sojkam1@fel.cvut.cz>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NMichal Sojka <sojkam1@fel.cvut.cz>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The return type should be enum reg_request_treatment for both
branches of the #ifdef.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The function is void and static, so just ifdef its contents
instead of duplicating the declaration.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Printing "N/A mBi" is strange - print just "N/A" instead.

Also add a missing opening parenthesis.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of having a lot of places that free ignored requests
and then return REG_REQ_OK, make reg_process_hint() process
REG_REQ_IGNORE by freeing the request, and let functions it
calls return that instead of freeing.

This also fixes a leak when a second (different) country IE
hint was ignored.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This function can only deal with treatment values OK and ALREADY_SET
so make the callees not return anything else and warn if they do.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The new name better reflects the functionality.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If there's a built-in regulatory database, there may be little point
in also calling out to CRDA and failing if the system is configured
that way. Allow removing CRDA support to save ~1K kernel size.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the functions reg_set_rd_driver() and reg_set_rd_country_ie()
return with an error, the calling function already restores data
by calling restore_regulatory_settings(), so there's no need to
also schedule a timeout (which would lead to other side effects
such as indicating CRDA failed, which clearly isn't true.) Remove
the scheduling.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of searching the built-in database only in the worker,
search it directly and return an error if the entry cannot be
found (or memory cannot be allocated.) This means that builtin
database queries no longer rely on the timeout.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The new name is more appropriate since in the case of a built-in
database it may not really rely on CRDA.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The function reg_call_crda() can't actually validly return
REG_REQ_IGNORE as it does now when calling CRDA fails since
that return value isn't handled properly. Fix that.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no way that the alpha2 pointer can be NULL, so
no point in checking that it isn't.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no "g" prefix, only "G" (1e9) that was clearly intended here.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

As pointed out by sparse, this symbol should be static, make it so.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

restore_regulatory_settings() should restore alpha2
as computed in restore_alpha2(), not raw user_alpha2 to
behave as described in the comment just above that code.

This fixes endless loop of calling CRDA for "00" and "97"
countries after resume from suspend on my laptop.

Looks like others had the same problem, too:
http://ath9k-devel.ath9k.narkive.com/knY5W6St/ath9k-and-crda-messages-in-logs
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/899335
https://forum.porteus.org/viewtopic.php?t=4975&p=36436
https://forums.opensuse.org/showthread.php/483356-Authentication-Regulatory-Domain-issues-ath5k-12-2Signed-off-by: NMaciej Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The original assumption of 20MHz wide channels hasn't been true since
the addition of support for 5 and 10 MHz channels.
Change the code to no longer disable all channels that don't fit into
the 20MHz grid, but instead set the appropriate flags to disable
operation on specific bandwidths.
Signed-off-by: NMatthias May <matthias.may@neratec.com>
[reword commit message]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Commit eeca9fce ('cfg80211: Schedule timeout for all CRDA calls')
left behind a superfluous check after it removed some earlier code.

In reg_process_hint, the test of "treatment == REG_REQ_IGNORE ||
treatment == REG_REQ_ALREADY_SET" is superfluous because the code in the
if-then branch is identical to the code after the if statement.

Coverity CID #1295939

I also removed the unnecessary assignment of treatment in this case,
and added a comment reminding any future patch authors to ensure that
treatment is properly assigned before it is used after the switch.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The RTNL is required to check for IR-relaxation conditions that allow
more channels to beacon. Export an RTNL locked version of reg_can_beacon
and use it where possible in AP/STA interface type flows, where
IR-relaxation may be applicable.

Fixes: 06f207fc ("cfg80211: change GO_CONCURRENT to IR_CONCURRENT for STA")
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

With a basic Linux userspace, the messages "Calling CRDA to update
world regulatory domain" appears 10 times after boot every second or
so, followed by a final "Exceeded CRDA call max attempts. Not calling
CRDA". For those of us not having the corresponding userspace parts,
having those messages repeatedly displayed at boot time is a bit
annoying, so this commit reduces their log level to pr_debug().
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The GO_CONCURRENT regulatory definition can be extended to station
interfaces requesting to IR as part of TDLS off-channel operations.
Rename the GO_CONCURRENT flag to IR_CONCURRENT and allow the added
use-case.

Change internal users of GO_CONCURRENT to use the new definition.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Patch eeca9fce (cfg80211: Schedule
timeout for all CRDA call) introduced a regression, where in case
that crda is not installed (or not configured properly etc.), the
regulatory core will needlessly continue to call it, polluting the
log with the following log:

"cfg80211: Calling CRDA to update world regulatory domain"

Fix this by limiting the number of continuous CRDA request failures.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

It is possible that there are several regulatory requests
pending, but the processing of the last one does not call
CRDA, and thus the other requests are not handled.

Fix this by rescheduling the work until all requests have
been processed.
Signed-off-by: NBen Rosenfeld <ben.rosenfeld@intel.com>
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Timeout was scheduled only in case CRDA was called due to user hints,
but was not scheduled for other cases. This can result in regulatory
hint processing getting stuck in case that there is no CRDA configured.

Change this by scheduling a timeout every time CRDA is called. In
addition, in restore_regulatory_settings() all pending requests are
restored (and not only the user ones).
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Acked-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Previously, the indoor setting configuration assumed that as
long as a station interface is connected, the indoor environment
setting does not change. However, this assumption is problematic
as:

- It is possible that a station interface is connected to a mobile
  AP, e.g., softAP or a P2P GO, where it is possible that both the
  station and the mobile AP move out of the indoor environment making
  the indoor setting invalid. In such a case, user space has no way to
  invalidate the setting.
- A station interface disconnection does not necessarily imply that
  the device is no longer operating in an indoor environment, e.g.,
  it is possible that the station interface is roaming but is still
  stays indoor.

To handle the above, extend the indoor configuration API to allow
user space to indicate a change of indoor settings, and allow it to
indicate weather it controls the indoor setting, such that:

1. If the user space process explicitly indicates that it is going
   to control the indoor setting, do not clear the indoor setting
   internally, unless the socket is released. The user space process
   should use the NL80211_ATTR_SOCKET_OWNER attribute in the command
   to state that it is going to control the indoor setting.
2. Reset the indoor setting when restoring the regulatory settings in
   case it is not owned by a user space process.

Based on the above, a user space tool that continuously monitors the
indoor settings, i.e., tracking power setting, location etc., can
indicate environment changes to the regulatory core.

It should be noted that currently user space is the only provided mechanism
used to hint to the regulatory core over the indoor/outdoor environment --
while the country IEs do have an environment setting this has been completely
ignored by the regulatory core by design for a while now since country IEs
typically can contain bogus data.
Acked-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NArikX Nemtsov <arik@wizery.com>
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Directly update the indoor setting without wrapping it as
a regulatory request, to simplify the processing.
Acked-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There are currently 8 rules in the world_regdom, but only the first 6
are applied due to an incorrect value for n_reg_rules.  This causes
channels 149-165 and 60GHz to be disabled.
Signed-off-by: NJason Abele <jason@aether.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When a system contains only self-managed regulatory devices all hints
from the regulatory core are ignored. Stop hint processing early in this
case. These systems usually don't have CRDA deployed, which results in
endless (irrelevent) logs of the form:
cfg80211: Calling CRDA to update world regulatory domain

Make sure there's at least one self-managed device before discarding a
hint, in order to prevent initial hints from disappearing on CRDA
managed systems.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A self-managed device will sometimes need to set its regdomain synchronously.
Notably it should be set before usermode has a chance to query it. Expose
a new API to accomplish this which requires the RTNL.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If a P2P GO is active, the cfg80211_reg_can_beacon function will take
the wdev lock, in its call to cfg80211_go_permissive_chan. But the wdev lock
is already taken by the parent channel-checking function, causing a
deadlock.
Split the checking code into two parts. The first part will check if the
wdev is active and saves the channel under the wdev lock. The second part
will check actual channel validity according to type.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The custom-reg handling function can currently only add flags to a given
channel. This results in stale flags being left applied. In some cases
a channel was disabled and even the orig_flags were changed to reflect
this.

Previously the API was designed for a single invocation before wiphy
registration, so this didn't matter. The previous approach doesn't scale
well to self-managed regulatory devices, particularly when a more
permissive regdom is applied after a restrictive one.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>