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>

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>

The commit:

commit 5e760230
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Nov 4 11:18:17 2011 +0100

    cfg80211: allow registering to beacons

allowed only a single process to register for beacon events
per wiphy.  This breaks cases where a user may want two or
more VIFs on a wiphy and run a seperate hostapd process on
each vif.

This patch allows multiple beacon listeners, fixing the
regression.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

These were missed due to the tracing work having
started on a kernel that didn't have P2P Device
yet, implement them now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

No driver initializes chan->max_antenna_gain to something sensible, and
the only place where it is being used right now is inside ath9k. This
leads to ath9k potentially using less tx power than it can use, which can
decrease performance/range in some rare cases.

Rather than going through every single driver, this patch initializes
chan->orig_mag in wiphy_register(), ignoring whatever value the driver
left in there. If a driver for some reason wishes to limit it independent
from regulatory rulesets, it can do so internally.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This will allow adding central tracing like in mac80211.
Signed-off-by: NHila Gonen <hila.gonen@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add an NL80211_SCAN_FLAG_FLUSH flag that causes old bss cache
entries to be flushed on scan completion. This is useful for
collecting guaranteed fresh scan/survey result (e.g. on resume).

For normal scan, flushing only happens on successful completion
of a scan; i.e. it does not happen if the scan is aborted.
For scheduled scan, previous scan results are flushed everytime
when we get new scan results.

This feature is enabled by default. Drivers can disable it by
unsetting the NL80211_FEATURE_SCAN_FLUSH flag.
Signed-off-by: NSam Leffler <sleffler@chromium.org>
Tested-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
[invert polarity of feature flag to account for old kernels]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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

libertas currently calls cfg80211_disconnected() when it is being
brought down. This causes an event to be allocated, but since the
wdev is already removed from the rdev by the time that the event
processing work executes, the event is never processed or freed.
http://article.gmane.org/gmane.linux.kernel.wireless.general/95666

Fix this leak, and other possible situations, by processing the event
queue when a device is being unregistered. Thanks to Johannes Berg for
the suggestion.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Cc: stable@vger.kernel.org
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now that we have wiphy_regulatory_register() we can
tuck away the core's regulatory_update() call there
and make it static.
Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This makes it clearer what we're doing. This now makes a bit
more sense given that regardless of the wiphy if the cell
base station hint feature is supported we will be modifying the
way the regulatory core behaves.
Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>