Having the EWMA parameters stored in the runtime struct imposes
memory requirements for the constant values that could just be
inlined in the code. This particularly makes sense if there are
a lot of such structs, for example in mac80211 in the station
table where each station has a number of these in an array, and
there can be many stations.

Provide a macro DECLARE_EWMA() that declares the necessary struct
and inline functions to access it with the parameters hard-coded;
using this also means the user no longer needs to 'select AVERAGE'
as it's entirely self-contained.

In the mac80211 case, on x86-64, this actually slightly *reduces*
code size, while also saving 80 bytes of runtime memory per sta.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

During hwsim_init_netlink(), we should call genl_unregister_family()
if failed on netlink_register_notifier() since the genetlink is
already registered.
Signed-off-by: Su Kang Yin <cantona@cantona.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Define rc_rateidx_vht_mcs_mask array and rate_idx_match_vht_mcs_mask()
method in order to apply mcs mask for vht rates
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Define rate_control_apply_mask_ratetbl() in order to apply ratemask in
rate_control_set_rates() for station rate table
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Remove ieee80211_tx_rate dependency in rate_idx_match_legacy_mask(),
rate_idx_match_mcs_mask() and rate_idx_match_mask() in order to use the
previous logic to define a ratemask in rate_control_set_rates() for
station rate table. Moreover move rate mask definition logic in
rate_control_cap_mask()
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Remove unnecessary ieee80211_tx_info pointer from rate_control_apply_mask
signature. rate_control_apply_mask() will be used to define a ratemask in
rate_control_set_rates() for station rate table
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Perform the BSS_CHANGED_BSSID action when joining an OCB network.
This is required to set the broadcast BSSID in some network drivers.
Signed-off-by: Bertold Van den Bergh <bertold.vandenbergh@esat.kuleuven.be>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Currently OCB mode accepts frames with bssid==broadcast and type!=beacon.
Some non-data frames are sent matching this, for example probe responses.
This results in unnecessary creation of STA entries.
Signed-off-by: Bertold Van den Bergh <bertold.vandenbergh@esat.kuleuven.be>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

To make mac80211 accept the multicast rate requested by the user the
rate control should be told that it is operating in BSS mode.
Without this, the default rate is selected in rate_control_send_low
(!pubsta and !txrc->bss)
Signed-off-by: Bertold Van den Bergh <bertold.vandenbergh@esat.kuleuven.be>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Allow setting multicast rate on OCB interfaces.
Current behaviour results in EOPNOTSUPP when attempting this.
Signed-off-by: Bertold Van den Bergh <bertold.vandenbergh@esat.kuleuven.be>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

If driver failed to setup wiphy params (e.g. rts
threshold, fragmentation treshold) userspace
wasn't properly notified about this. This could
lead to user confusion who would think the command
succeeded even if that wasn't the case.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes 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: Matthias May <matthias.may@neratec.com>
[reword commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The outside if statement checks that IEEE80211_TX_INTFL_MLME_CONN_TX is
set so this condition is always true.  Checking twice upsets the static
checkers.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The iwlwifi driver was the only driver that used this, but as
it turns out it never needed it, so we can remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

According to firmware engineers, the firmware has never required
these fields and the values have always been calculated, they were
just leftovers from a previous implementation.

Therefore remove the unnecessary calculation.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer
functionality only, can still be compiled if GPIOLIB is not enabled.

Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where
appropriate.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

With this .config: http://busybox.net/~vda/kernel_config,
after deinlining these functions have sizes and callsite counts
as follows:

rate_control_rate_init: 554 bytes, 8 calls
rate_control_rate_update: 1596 bytes, 5 calls

Total size reduction: about 11 kbytes.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
CC: John Linville <linville@tuxdriver.com>
CC: Michal Kazior <michal.kazior@tieto.com>
CC: Johannes Berg <johannes.berg@intel.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

With this .config: http://busybox.net/~vda/kernel_config,
after deinlining the function size is 3132 bytes and there are
7 callsites.

Total size reduction: about 20 kbytes.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
CC: John Linville <linville@tuxdriver.com>
CC: Michal Kazior <michal.kazior@tieto.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Instead of using peer link id for AID, generate a new
AID when creating mesh STAs in the kernel peering manager.
This enables smaller TIM elements and more closely follows
the standard, and it also enables mesh to work on drivers
that require a valid AID when the STA is inserted (ath10k
firmware has this requirement, for example).

In the case of userspace-managed stations, we use the AID
from NL80211_CMD_NEW_STATION.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

According to 802.11-2012 13.3.1, a mesh STA should assign an AID
upon receipt of a mesh peering open frame rather than using the link
id of the peer.  Using the peer link id has two potential issues:
it may not be unique among the peers, and by its nature it is random,
so the TIM may not compress well.

In preparation for allocating it properly, use sta->sta.aid, but keep
the existing behavior of using the plid in the aid we send.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Move mesh_plink_frame_tx() above the first caller to remove
the forward declaration.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Currently, mac80211 calls drv_resume() on wowlan resume,
but drops any incoming frame until local->suspended is
cleared later on.

This requires the low-level driver to support a new state,
in which it is expected to fully work (as it was resumed)
but not passing rx frames yet (as they will be dropped).

iwlwifi (and probably other drivers as well) has issues
supporting such mode.

Since in the wowlan case we already short-circuit
ieee80211_reconfig, there's nothing that prevents us from
clearing local->suspend before calling drv_resume(),
and letting the low-level driver work normally.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

If a TDLS station is not allowed to beacon on a channel, don't accept
a channel switch request to this channel.
Move channel building code up to avoid lockdep violations - reg_can_beacon
needs to take the wdev lock.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Move TDLS channel-switch Rx handling into an RTNL locked work. This is
required to add proper regulatory checking to incoming channel-switch
requests.
Queue incoming requests in a dedicated skb queue and handle the request
in a device-specific work to avoid deadlocking on interface removal.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This is necessary to merge the new TDLS and mesh patches,
as they depend on some fixes.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Add support for declaring MU-MIMO beamformee capability for
relevant hardware.
When sending association request, the capability is included if both
hardware and the AP support it, and no other virtual interface
is using it.
This is in order to avoid multiple interfaces using MU-MIMO in parallel
which might lead to contradictions in the group-id mechanism.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

If an SKB will be segmented by the driver, count it for multiple
MSDUs that are being transmitted rather than just a single.
Signed-off-by: Johannes 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: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This callback is currently not allowed to sleep, which makes it more
difficult to implement proper driver methods in mac80211 than it has
to be. Instead of doing asynchronous work here in mac80211, make it
possible for the callback to sleep by doing some asynchronous work
in cfg80211. This also enables improvements to other drivers, like
ath6kl, that would like to sleep in this callback.

While at it, also fix the code to call the driver on the implicit
unregistration when an interface is removed, and do that also when
a P2P-Device wdev is destroyed (otherwise we leak the structs.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Most of the fields in this struct use too wide types, change
that to shrink the struct from 64 to 48 bytes (on 64-bit.)

This results in a total saving of 64 bytes for each interface.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This value is only used in mesh, so move it into the new mesh
sub-struct of the station info.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Some drivers may need to store data per key, for example for PN
validation. Allow this by adding a pointer to the struct that
the driver can assign.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There's no reason not to support this, allow it to test
those code paths.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

In case of Dynamic SMPS enable RTS/CTS for all rates.
Signed-off-by: Chaitanya T K <chaitanya.mgit@gmail.com>
[change comment]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This patch does the following:
- Remove unnecessary flags field used by PERR element
- Use the per target flags defined in <linux/ieee80211.h>
- Process the target only subfield based on case E2 of
  IEEE802.11-2012 13.10.9.3
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The IEEE802.11-2012 specification is vague regarding SMPS operation during
TDLS. It does not define a clear way to transition between SMPS states.

To avoid interop issues, set SMPS to off when TDLS peers are connected.
Accomplish this by extending the definition of the AUTOMATIC state. If the
driver forces a state other than OFF, disconnect all TDLS peers.

While at it, avoid changing the SMPS state of the peer STA. We have no
way to control it, so try and behave correctly towards it.

Move the TDLS peer-teardown function to where the rest of the TDLS code
resides.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

We already set a station to be associated when peering completes, both
in user space and in the kernel.  Thus we should always have an
associated sta before sending data frames to that station.

Failure to check assoc state can cause crashes in the lower-level driver
due to transmitting unicast data frames before driver sta structures
(e.g. ampdu state in ath9k) are initialized.  This occurred when
forwarding in the presence of fixed mesh paths: frames were transmitted
to stations with whom we hadn't yet completed peering.

Cc: stable@vger.kernel.org
Reported-by: Alexis Green <agreen@cococorp.com>
Tested-by: Jesse Jones <jjones@cococorp.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When processing a PREQ or PREP it's critical to use the incoming SN. If
that is improperly done routing loops and other types of badness can
happen. But the code was always processing path messages for deactivated
paths. This path fixes that so that if we have a valid SN then we use it
to verify that it is a message we can accept. For reference the relevant
section of the standard is 13.10.8.4 which doesn't address the deactivated
path case at all.

I also included a special case for when our peer reboots or restarts
networking. This is an important case because without it there can be a
very long delay before we accept path messages from that peer. It's also a
simple case and intimately associated with processing messages for
deactivated paths so I used one patch instead of two.
Signed-off-by: Alexis Green <agreen@cococorp.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The 2012 spec mentions that path SNs can be invalid when created (see
section 13.10.8.4 table 13-9) but AFAICT never talks about invalidating
SNs. Which makes sense: if we have figured out the path to a target at a
certain SN then we want to remember that fact. Failing to do so can lead
to routing loops because if we don't have a valid SN then we have no way
of knowing whether an incoming path message leads to or away from the
target.

However currently when discovery fails we zero out mpath->flags which
clears MESH_PATH_SN_VALID. This patch fixes that so that only the
discovery relevant flags are cleared.
Signed-off-by: Alexis Green <agreen@cococorp.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When the nexthop is unable to resolve its own nexthop it will send back a
PERR with a zero target_sn. According to section 13.10.11.4.3 step b in the
2012 standard that perr should be forwarded and the associated mpath->sn
should be incremented. Neither one of those was happening which is rather
bad because the originator was not told that packets are black holing.
Signed-off-by: Alexis Green <agreen@cococorp.com>
CC: Jesse Jones <jjones@cococorp.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>