Add a strict start type so all new attributes starting from
NL80211_ATTR_HE_OBSS_PD are validated strictly.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add the data structure, policy and parsing code allowing userland to send
the OBSS PD information into the kernel.
Signed-off-by: NJohn Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20190730163701.18836-2-john@phrozen.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

This came up in fuzz testing, and really we don't consider
all-zeroes to be a valid MAC address in most places, so
also reject it here to avoid confusion later on.
Signed-off-by: NKarthikeyan Periyasamy <periyasa@codeaurora.org>
Link: https://lore.kernel.org/r/1563959770-21570-1-git-send-email-periyasa@codeaurora.org
[rewrite commit message]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Over time, we really need to get rid of all of our global locking.
One of the things needed is to use parallel_ops. This isn't really
the most important (RTNL is much more important) but OTOH we just
keep adding uses of genl_family_attrbuf() now. Use .parallel_ops to
disallow this.
Reviewed-By: NDenis Kenzior <denkenz@gmail.com>
Link: https://lore.kernel.org/r/20190729143109.18683-1-johannes@sipsolutions.netSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Give a proper boottime_ns value for netlink RX to avoid scan
issues here.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/r/20190729160605.1074-1-johannes@sipsolutions.netSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

The return from ieee80211_get_sband can potentially be a null pointer, so
it seems prudent to add a null check to avoid a null pointer dereference
on sband.

Addresses-Coverity: ("Dereference null return")
Fixes: 2ab45876 ("mac80211: add support for the ADDBA extension element")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20190730143205.14261-1-colin.king@canonical.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

HE allows peers to negotiate the aggregation fragmentation level to be used
during transmission. The level can be 1-3. The Ext element is added behind
the ADDBA request inside the action frame. The responder will then reply
with the same level or a lower one if the requested one is not supported.
This patch only handles the negotiation part as the ADDBA frames get passed
to the ATH11k firmware, which does the rest of the magic for us aswell as
generating the requests.
Signed-off-by: NShashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: NJohn Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20190729104512.27615-1-john@phrozen.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Upon a successful assoc a station shall store the content of the HE
operation element inside bss_conf so that the driver can setup the
hardware accordingly.
Signed-off-by: NShashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: NJohn Crispin <john@phrozen.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20190729102342.8659-2-john@phrozen.org
[use struct copy]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Johannes mentioned that the comment should not reference mac80211 as other
subsystems might call the helper.
Signed-off-by: NJohn Crispin <john@phrozen.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20190729102342.8659-1-john@phrozen.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Depending on the regulatory domain, leaving a DFS channel requires
a new CAC to be performed when returning back to that channel.
If needed, update dfs states after a driver channel switch.
Signed-off-by: NMichael Vassernis <michael.vassernis@tandemg.com>
Link: https://lore.kernel.org/r/20190729060024.5660-1-michael.vassernis@tandemg.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

When associated BSS completes channel switch procedure, its channel
record needs to be updated. The existing mac80211 solution was
extended to cfg80211 in commit 5dc8cdce ("mac80211/cfg80211:
update bss channel on channel switch").

However that solution still appears to be incomplete as it may lead
to duplicated scan entries for associated BSS after channel switch.
The root cause of the problem is as follows. Each BSS entry is
included into the following data structures:
- bss list rdev->bss_list
- bss search tree rdev->bss_tree
Updating BSS channel record without rebuilding bss_tree may break
tree search since cmp_bss considers all of the following: channel,
bssid, ssid. When BSS channel is updated, but its location in bss_tree
is not updated, then subsequent search operations may fail to locate
this BSS since they will be traversing bss_tree in wrong direction.
As a result, for scan performed after associated BSS channel switch,
cfg80211_bss_update may add the second entry for the same BSS to both
bss_list and bss_tree, rather then update the existing one.

To summarize, if BSS channel needs to be updated, then bss_tree should
be rebuilt in order to put updated BSS entry into a proper location.

This commit suggests the following straightforward solution:
- if new entry has been already created for BSS after channel switch,
  then use its IEs to update known BSS entry and then remove new
  entry completely
- use rb_erase/rb_insert_bss reinstall updated BSS in bss_tree
- for nontransmit BSS entry, the whole transmit BSS hierarchy
  is updated
Signed-off-by: NSergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Link: https://lore.kernel.org/r/20190726163922.27509-3-sergey.matyukevich.os@quantenna.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

This patch implements minor refactoring for cfg80211_bss_update function.
Code path for updating known BSS is extracted into dedicated
cfg80211_update_known_bss function.
Signed-off-by: NSergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Link: https://lore.kernel.org/r/20190726163922.27509-2-sergey.matyukevich.os@quantenna.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Include wiphy address setup in wiphy dumps and new wiphy events.  The
wiphy permanent address is exposed as ATTR_MAC.  If addr_mask is setup,
then it is included as ATTR_MAC_MASK attribute.  If multiple addresses
are available, then their are exposed in a nested ATTR_MAC_ADDRS array.

This information is already exposed via sysfs, but it makes sense to
include it in the wiphy dump as well.
Signed-off-by: NDenis Kenzior <denkenz@gmail.com>
Link: https://lore.kernel.org/r/20190722113312.14031-3-denkenz@gmail.com
[use just nla_nest_start(), this is new functionality]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Commit 1c38c7f2 ("nl80211: send event when CMD_FRAME duration
expires") added the possibility of NL80211_CMD_FRAME_WAIT_CANCEL
being sent whenever the off-channel wait time associated with a
CMD_FRAME completes.  Document this in the uapi/linux/nl80211.h file.
Signed-off-by: NDenis Kenzior <denkenz@gmail.com>
Link: https://lore.kernel.org/r/20190722113312.14031-1-denkenz@gmail.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Implement the basics required for supporting high efficiency with mesh:
include HE information elements in beacons, probe responses, and peering
action frames, and check for compatible HE configurations when peering.
Signed-off-by: NSven Eckelmann <seckelmann@datto.com>

Forwarded: https://patchwork.kernel.org/patch/11029299/
Link: https://lore.kernel.org/r/20190724163359.3507-2-sven@narfation.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Add IEEE80211_KEY_FLAG_GENERATE_MMIE flag to ieee80211_key_flags in order
to allow the driver to notify mac80211 to generate MMIE and that it
requires sequence number generation only.
This is a preliminary patch to add BIP_CMAC_128 hw support to mt7615
driver
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/dfe275f9aa0f1cc6b33085f9efd5d8447f68ad13.1563228405.git.lorenzo@kernel.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Add support to mac80211 for parsing SPR elements as per
P802.11ax_D4.0 section 9.4.2.241.
Signed-off-by: NShashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: NJohn Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20190618061915.7102-2-john@phrozen.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Add support to ieee80211_add_tx_radiotap_header() for handling rates
reported via ieee80211_tx_status. This allows us to also report HE rates.
Signed-off-by: NJohn Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20190714154419.11854-4-john@phrozen.org
[remove text about 60 GHz, mac80211 doesn't support it, fix endianness issue]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This will allow use to report HE rates on the radiotap interface.
Signed-off-by: NJohn Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20190714154419.11854-3-john@phrozen.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Right now struct ieee80211_tx_rate cannot hold HE rates. Lets use
struct ieee80211_tx_status instead. This will also make the code
future-proof for when we have EHT.
Signed-off-by: NJohn Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20190714154419.11854-2-john@phrozen.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

ADDBA_EXT IEs can be used to negotiate the BA fragmentation level.
Signed-off-by: NJohn Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20190713163642.18491-2-john@phrozen.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

If we just read jiffies over and over again, a non-transmitting
entry may have a newer timestamp than the transmitting one,
leading to possible confusion on expiry. Give them all the same
timestamp when creating them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NSergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Link: https://lore.kernel.org/r/20190703133823.10530-3-johannes@sipsolutions.netSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Don't parse the multi-BSSID structures if we couldn't even create
their transmitting BSS, this would confuse all of our tracking.

This also means that non_tx_data->tx_bss will never be NULL, so
we can clean up a little bit.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NSergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Link: https://lore.kernel.org/r/20190703133823.10530-2-johannes@sipsolutions.netSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

cfg80211_inform_single_bss_frame_data() doesn't need the
non_tx_data data argument since it's always NULL.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NSergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Link: https://lore.kernel.org/r/20190703133823.10530-1-johannes@sipsolutions.netSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190703070142.GA29993@kroah.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Extended Key ID allows A-MPDU sessions while rekeying as long as each
A-MPDU aggregates only MPDUs with one keyid together.

Drivers able to segregate MPDUs accordingly can tell mac80211 to not
stop A-MPDU sessions when rekeying by setting the new flag
IEEE80211_HW_AMPDU_KEYBORDER_SUPPORT.
Signed-off-by: NAlexander Wetzel <alexander@wetzel-home.de>
Link: https://lore.kernel.org/r/20190629195015.19680-3-alexander@wetzel-home.deSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

1) Drop IEEE80211_HW_EXT_KEY_ID_NATIVE and let drivers directly set
   the NL80211_EXT_FEATURE_EXT_KEY_ID flag.

2) Drop IEEE80211_HW_NO_AMPDU_KEYBORDER_SUPPORT and simply assume all
   drivers are unable to handle A-MPDU key borders.

The new Extended Key ID API now requires all mac80211 drivers to set
NL80211_EXT_FEATURE_EXT_KEY_ID when they implement set_key() and can
handle Extended Key ID. For drivers not providing set_key() mac80211
itself enables Extended Key ID support, using the internal SW crypto
services.
Signed-off-by: NAlexander Wetzel <alexander@wetzel-home.de>
Link: https://lore.kernel.org/r/20190629195015.19680-2-alexander@wetzel-home.deSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Prepare hwsim Extended Key ID support for a mac80211 API change.

The mac80211 flag IEEE80211_HW_EXT_KEY_ID_NATIVE is being replaced by
NL80211_EXT_FEATURE_EXT_KEY_ID which only must be set by drivers when
they support HW crypto.

This reverts commit cfe7007a ("mac80211_hwsim: Extended Key ID support").
Signed-off-by: NAlexander Wetzel <alexander@wetzel-home.de>
Link: https://lore.kernel.org/r/20190629195015.19680-1-alexander@wetzel-home.deSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Since ieee80211_tx_dequeue() must not be called with softirqs enabled
(i.e. from process context without proper disable of bottom halves),
we add a wrapper that disables bottom halves before calling
ieee80211_tx_dequeue()

The new function is named ieee80211_tx_dequeue_ni() just as all other
from-process-context versions found in mac80211.

The documentation of ieee80211_tx_dequeue() is also updated so it
mentions that the function should not be called from process context.
Signed-off-by: NErik Stromdahl <erik.stromdahl@gmail.com>
Link: https://lore.kernel.org/r/20190617200140.6189-1-erik.stromdahl@gmail.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of open coding the CCM aead mode in the driver, and invoking
the AES block cipher block by block, use a ccm(aes) aead transform
which already encapsulates this functionality. This is a cleaner use
of the crypto API, and permits optimized implementations to be used,
which are typically much faster and deal more efficiently with the
SIMD register file, which usually needs to be preserved/restored in
order to use special AES instructions.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Link: https://lore.kernel.org/r/20190617091901.7063-1-ard.biesheuvel@linaro.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

The remove_sta_debugfs callback in struct rate_control_ops is no longer
used by any driver, as there is no need for it (the debugfs directory is
already removed recursivly by the mac80211 core.)  Because no one needs
it, just remove it to keep anyone else from accidentally using it in the
future.

Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190612142658.12792-5-gregkh@linuxfoundation.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

The .remove_sta_debugfs callback was not doing anything in this driver,
so remove it as it is not needed.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190612142658.12792-4-gregkh@linuxfoundation.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

When calling debugfs functions, there is no need to ever check the
return value.  This driver was saving the debugfs file away to be
removed at a later time.  However, the 80211 core would delete the whole
directory that the debugfs files are created in, after it asks the
driver to do the deletion, so just rely on the 80211 core to do all of
the cleanup for us, making us not need to keep a pointer to the dentries
around at all.

This cleans up the structure of the driver data a bit and makes the code
a tiny bit smaller.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190612142658.12792-3-gregkh@linuxfoundation.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

This low level driver can find it useful to get the vif
when a remain on channel session is cancelled.

iwlwifi will need this soon.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://lore.kernel.org/r/20190723180001.5828-1-emmanuel.grumbach@intel.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

This function name should be 'mac80211_hwsim_he_capab()' (s wand w
switched) to be consistent with the rest of the file.
Fix and use it.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20190725191328.18010-1-christophe.jaillet@wanadoo.frSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

devm_platform_ioremap_resource() wraps platform_get_resource() and
devm_ioremap_resource() in a single helper, let's use that helper to
simplify the code.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Tuong Lien says:

====================
tipc: link changeover issues

This patch series is to resolve some issues found with the current link
changeover mechanism, it also includes an optimization for the link
synching.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In conjunction with changing the interfaces' MTU (e.g. especially in
the case of a bonding) where the TIPC links are brought up and down
in a short time, a couple of issues were detected with the current link
changeover mechanism:

1) When one link is up but immediately forced down again, the failover
procedure will be carried out in order to failover all the messages in
the link's transmq queue onto the other working link. The link and node
state is also set to FAILINGOVER as part of the process. The message
will be transmited in form of a FAILOVER_MSG, so its size is plus of 40
bytes (= the message header size). There is no problem if the original
message size is not larger than the link's MTU - 40, and indeed this is
the max size of a normal payload messages. However, in the situation
above, because the link has just been up, the messages in the link's
transmq are almost SYNCH_MSGs which had been generated by the link
synching procedure, then their size might reach the max value already!
When the FAILOVER_MSG is built on the top of such a SYNCH_MSG, its size
will exceed the link's MTU. As a result, the messages are dropped
silently and the failover procedure will never end up, the link will
not be able to exit the FAILINGOVER state, so cannot be re-established.

2) The same scenario above can happen more easily in case the MTU of
the links is set differently or when changing. In that case, as long as
a large message in the failure link's transmq queue was built and
fragmented with its link's MTU > the other link's one, the issue will
happen (there is no need of a link synching in advance).

3) The link synching procedure also faces with the same issue but since
the link synching is only started upon receipt of a SYNCH_MSG, dropping
the message will not result in a state deadlock, but it is not expected
as design.

The 1) & 3) issues are resolved by the last commit that only a dummy
SYNCH_MSG (i.e. without data) is generated at the link synching, so the
size of a FAILOVER_MSG if any then will never exceed the link's MTU.

For the 2) issue, the only solution is trying to fragment the messages
in the failure link's transmq queue according to the working link's MTU
so they can be failovered then. A new function is made to accomplish
this, it will still be a TUNNEL PROTOCOL/FAILOVER MSG but if the
original message size is too large, it will be fragmented & reassembled
at the receiving side.
Acked-by: NYing Xue <ying.xue@windriver.com>
Acked-by: NJon Maloy <jon.maloy@ericsson.com>
Signed-off-by: NTuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This commit along with the next one are to resolve the issues with the
link changeover mechanism. See that commit for details.

Basically, for the link synching, from now on, we will send only one
single ("dummy") SYNCH message to peer. The SYNCH message does not
contain any data, just a header conveying the synch point to the peer.

A new node capability flag ("TIPC_TUNNEL_ENHANCED") is introduced for
backward compatible!
Acked-by: NYing Xue <ying.xue@windriver.com>
Acked-by: NJon Maloy <jon.maloy@ericsson.com>
Suggested-by: NJon Maloy <jon.maloy@ericsson.com>
Signed-off-by: NTuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

devm_ioremap_resource already contains error message, so remove
the redundant dev_err message
Signed-off-by: NDing Xiang <dingxiang@cmss.chinamobile.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>