In case of AP mode, the beacon interval is already reset to
zero inside cfg80211_stop_ap(), and in the other modes it
isn't relevant. Remove the assignment to remove a potential
race since the assignment isn't properly locked.
Reported-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Due to the previous commit, when a scan finishes, it is in theory
possible to hit the following sequence:
 1. interface starts being removed
 2. scan is cancelled by driver and cfg80211 is notified
 3. scan done work is scheduled
 4. interface is removed completely, rdev->scan_req is freed,
    event sent to userspace but scan done work remains pending
 5. new scan is requested on another virtual interface
 6. scan done work runs, freeing the still-running scan

To fix this situation, hang on to the scan done message and block
new scans while that is the case, and only send the message from
the work function, regardless of whether the scan_req is already
freed from interface removal. This makes step 5 above impossible
and changes step 6 to be
 5. scan done work runs, sending the scan done message

As this can't work for wext, so we send the message immediately,
but this shouldn't be an issue since we still return -EBUSY.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When an interface/wdev is removed, any ongoing scan should be
cancelled by the driver. This will make it call cfg80211, which
only queues a work struct. If interface/wdev removal is quick
enough, this can leave the scan request pending and processed
only after the interface is gone, causing a use-after-free.

Fix this by making sure the scan request is not pending after
the interface is destroyed. We can't flush or cancel the work
item due to locking concerns, but when it'll run it shouldn't
find anything to do. This leaves a potential issue, if a new
scan gets requested before the work runs, it prematurely stops
the running scan, potentially causing another crash. I'll fix
that in the next patch.

This was particularly observed with P2P_DEVICE wdevs, likely
because freeing them is quicker than freeing netdevs.
Reported-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Fixes: 4a58e7c3 ("cfg80211: don't "leak" uncompleted scans")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Unfortunately I forgot this during the merge window, but the
patch seems small enough to go in as a fix. The userspace API
bug that was the reason for disabling it has long been fixed.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

___cfg80211_scan_done() can be called in some cases
(e.g. on NETDEV_DOWN) before the low level driver
notified scan completion (which is indicated by
passing leak=true).

Clearing rdev->scan_req in this case is buggy, as
scan_done_wk might have already being queued/running
(and can't be flushed as it takes rtnl()).

If a new scan will be requested at this stage, the
scan_done_wk will try freeing it (instead of the
previous scan), and this will later result in
a use after free.

Simply remove the "leak" option, and replace it with
a standard WARN_ON.

An example backtrace after such crash:
Unable to handle kernel paging request at virtual address fffffee5
pgd = c0004000
[fffffee5] *pgd=9fdf6821, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] SMP ARM
PC is at cfg80211_scan_done+0x28/0xc4 [cfg80211]
LR is at __ieee80211_scan_completed+0xe4/0x2dc [mac80211]
[<bf0077b0>] (cfg80211_scan_done+0x28/0xc4 [cfg80211])
[<bf0973d4>] (__ieee80211_scan_completed+0xe4/0x2dc [mac80211])
[<bf0982cc>] (ieee80211_scan_work+0x94/0x4f0 [mac80211])
[<c005fd10>] (process_one_work+0x1b0/0x4a8)
[<c0060404>] (worker_thread+0x138/0x37c)
[<c0066d70>] (kthread+0xa4/0xb0)
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

cfg80211_leave stops sched scan when any station vif
is leaving. Add an explicit check and call it only
when the relevant vif (the one we scan on) is leaving.
Signed-off-by: NBarak Bercovitz <barak@wizery.com>
[Eliad - changed the commit message a bit]
Signed-off-by: NEliad Peller <eliad@wizery.com>
[Johannes - add ASSERT_RTNL since that protects the pointer]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The channel switch announcement code has some major locking problems
which can cause a deadlock in worst case. A series of fixes has been
proposed, but these are non-trivial and need to be tested first.
Therefore disable CSA completely for 3.13.
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
[fix up whitespace damage, overly long lines]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>

Due to nl80211 API breakage, 5/10 MHz support is broken for
all drivers. Fixing it requires adding new API, but that
can't be done as a bugfix commit since that would require
either updating all APIs in the trees needing the bugfix or
cause different kernels to have incompatible API.

Therefore, just disable 5/10 MHz support for all drivers.

Cc: stable@vger.kernel.org [3.12]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since P2P device doesn't have a netdev associated to it,
we cannot prevent the user to start it when in RFKILL.
So refuse to even add it when in RFKILL.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

My locking rework/race fixes caused a regression in the
registration, causing uevent notifications for wireless
devices before the device is really fully registered and
available in nl80211.

Fix this by moving the device_add() under rtnl and move
the rfkill to afterwards (it can't be under rtnl.)
Reported-and-tested-by: NMaxime Bizon <mbizon@freebox.fr>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When a P2P GO interface goes down, cfg80211 doesn't properly
tear it down, leading to warnings later. Add the GO interface
type to the enumeration to tear it down like AP interfaces.
Otherwise, we leave it pending and mac80211's state can get
very confused, leading to warnings later.

Cc: stable@vger.kernel.org
Reported-by: NIlan Peer <ilan.peer@intel.com>
Tested-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In most cases, host that receives IPv4 and IPv6 multicast/broadcast
packets does not do anything with these packets. Therefore the
reception of these unwanted packets causes unnecessary processing
and power consumption.

Packet coalesce feature helps to reduce number of received
interrupts to host by buffering these packets in firmware/hardware
for some predefined time. Received interrupt will be generated when
one of the following events occur.
a) Expiration of hardware timer whose expiration time is set to
maximum coalescing delay of matching coalesce rule.
b) Coalescing buffer in hardware reaches it's limit.
c) Packet doesn't match any of the configured coalesce rules.

This patch adds set/get configuration support for packet coalesce.
User needs to configure following parameters for creating a coalesce
rule.
a) Maximum coalescing delay
b) List of packet patterns which needs to be matched
c) Condition for coalescence. pattern 'match' or 'no match'
Multiple such rules can be created.

This feature needs to be advertised during driver initialization.
Drivers are supposed to do required firmware/hardware settings based
on user configuration.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
[fix kernel-doc, change free function, fix copy/paste error]
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

If it *is* still set when the netdev is being deleted,
then we are about to leak a pointer.  Warn and clean up
in that case.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The change to use atomic_inc_return() for assigning the wiphy
index made the first wiphy index 1 instead of 0. This is fine,
but we all habitually type "phy0" when we're testing, so make
it go back to 0 instead of 1 by subtracting 1 from the index.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

My big locking cleanups caused a problem by registering the
rfkill instance with the RTNL held, while the callback also
acquires the RTNL. This potentially causes a deadlock since
the two locks used (rfkill mutex and RTNL) can be acquired
in two different orders. Fix this by (un)registering rfkill
without holding the RTNL. This needs to be done after the
device struct is registered, but that can also be done w/o
holding the RTNL.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The current internal SME implementation in cfg80211 is
very mixed up with the MLME handling, which has been
causing issues for a long time. There are three things
that the implementation has to provide:
 * a basic SME implementation for nl80211's connect()
   call (for drivers implementing auth/assoc, which is
   really just mac80211) and wireless extensions
 * MLME events for the userspace SME
 * SME events (connected, disconnected etc.) for all
   different SME implementation possibilities (driver,
   cfg80211 and userspace)

To achieve these goals it isn't necessary to track the
software SME's connection status outside of it's state
(which is the part that caused many issues.) Instead,
track it only in the SME data (wdev->conn) and in the
general case only track whether the wdev is connected
or not (via wdev->current_bss.)

Also separate the internal implementation to not have
callbacks from the SME events, but rather call it from
the API functions that the driver (or rather mac80211)
calls. This separates the code better.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no need to take up the space for devices that don't
support WoWLAN, and most drivers can even make the support
data static const (except where it's modified at runtime.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

So far, only net_device * could be passed along with netdevice notifier
event. This patch provides a possibility to pass custom structure
able to provide info that event listener needs to know.
Signed-off-by: NJiri Pirko <jiri@resnulli.us>

v2->v3: fix typo on simeth
	shortened dev_getter
	shortened notifier_info struct name
v1->v2: fix notifier_call parameter in call_netdevice_notifier()
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Make the current WoWLAN configuration available to drivers
at runtime. This isn't really useful for the normal WoWLAN
behaviour and accessing it can also be racy, but drivers
may use it for testing the WoWLAN device behaviour while
the host stays up & running to observe the device.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

By making all the API functions require wdev locking we
can clean up the API a bit, getting rid of the locking
version of each function. This also decreases the size
of cfg80211 by a small amount.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If the driver for some reason successfully finishes
scanning while in p2p_stop_device(), cfg80211 will
still set it to aborted. Simplify this code using the
new 'notified' value and only mark it aborted in case
the driver didn't notify cfg80211 at all (in which
case we also leak the request to not crash, this is
a driver bug.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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>

There's no need to lock, we can just use an atomic_t.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The function is only used and needed by the wext code
for scanning, so move it there.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

To support auto-loading of wireless modules from netlink users, add module
alias for nl80211 family.

This also adds NL80211_GENL_NAME constant to define the "nl80211" netlink
family name as part of uapi.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the interface goes down, there's no need to call
cfg80211_mlme_down() after __cfg80211_disconnect() as
the latter will call the former (if appropriate.)

Also, in __cfg80211_disconnect(), if the cfg80211 SME
isn't used, __cfg80211_disconnected() may still need
to be called (depending on the current state) so that
the SME state gets cleared.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If rfkill_register() fails in wiphy_register() the struct device
is unregistered but everything else isn't (regulatory, debugfs)
and we even leave the wiphy instance on all internal lists even
though it will likely be freed soon, which is clearly a problem.
Fix this by cleaning up properly.

Cc: stable@vger.kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If a P2P device wdev is removed while it has a scan, then the
scan completion might crash later as it is already freed by
that time. To avoid the crash always check the scan completion
when the P2P device is being removed for some reason. If the
driver already canceled it, don't want and free it, otherwise
warn and leak it to avoid later crashes.

In order to do this, locking needs to be changed away from the
rdev mutex (which can't always be guaranteed). For now, use
the sched_scan_mtx instead, I'll rename it to just scan_mtx in
a later patch.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If possible that after suspend, cfg80211 will receive request to
disconnect what require action on interface that was removed during
suspend.

Problem can manifest itself by various warnings similar to below one:

WARNING: at net/mac80211/driver-ops.h:12 ieee80211_bss_info_change_notify+0x2f9/0x300 [mac80211]()
wlan0:  Failed check-sdata-in-driver check, flags: 0x4
Call Trace:
 [<c043e0b3>] warn_slowpath_fmt+0x33/0x40
 [<f83707c9>] ieee80211_bss_info_change_notify+0x2f9/0x300 [mac80211]
 [<f83a660a>] ieee80211_recalc_ps_vif+0x2a/0x30 [mac80211]
 [<f83a6706>] ieee80211_set_disassoc+0xf6/0x500 [mac80211]
 [<f83a9441>] ieee80211_mgd_deauth+0x1f1/0x280 [mac80211]
 [<f8381b36>] ieee80211_deauth+0x16/0x20 [mac80211]
 [<f8261e70>] cfg80211_mlme_down+0x70/0xc0 [cfg80211]
 [<f8264de1>] __cfg80211_disconnect+0x1b1/0x1d0 [cfg80211]

To fix the problem disconnect from any associated network before
suspend. User space is responsible to establish connection again
after resume. This basically need to be done by user space anyway,
because associated stations can go away during suspend (for example
NetworkManager disconnects on suspend and connect on resume by default).

Patch also handle situation when driver refuse to suspend with wowlan
configured and try to suspend again without it.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is another case of data increasing the size of the
wiphy information significantly with a new feature, for
now remove this as well.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When drivers or regulatory have limitations on
40, 80 or 160 MHz channels, advertise these to
userspace via nl80211. Also add a new feature
flag to let userspace know this is supported.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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>

This prepares for using the spinlock instead of krefs
which is needed in the next patch to track the refs
of combined BSSes correctly.

Acked-by: Bing Zhao <bzhao@marvell.com> [mwifiex]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add API to enable drivers to implement MAC address based
access control in AP/P2P GO mode. Capable drivers advertise
this capability by setting the maximum number of MAC
addresses in such a list in wiphy->max_acl_mac_addrs.

An initial ACL may be given to the NL80211_CMD_START_AP
command and/or changed later with NL80211_CMD_SET_MAC_ACL.

Black- and whitelists are supported, but not simultaneously.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
[rewrite commit log, many cleanups]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

To ease further DFS development regarding interface combinations, use
the interface combinations structure to test for radar capabilities.
Drivers can specify which channel widths they support, and in which
modes. Right now only a single AP interface is allowed, but as the
DFS code evolves other combinations can be enabled.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since:

commit 2c60db03
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Sep 16 09:17:26 2012 +0000

    net: provide a default dev->ethtool_ops

wireless core does not correctly assign ethtool_ops.

After alloc_netdev*() call, some cfg80211 drivers provide they own
ethtool_ops, but some do not. For them, wireless core provide generic
cfg80211_ethtool_ops, which is assigned in NETDEV_REGISTER notify call:

        if (!dev->ethtool_ops)
                dev->ethtool_ops = &cfg80211_ethtool_ops;

But after Eric's commit, dev->ethtool_ops is no longer NULL (on cfg80211
drivers without custom ethtool_ops), but points to &default_ethtool_ops.

In order to fix the problem, provide function which will overwrite
default_ethtool_ops and use it by wireless core.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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>