2019-06-04 11:11:33 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2007-05-05 22:45:53 +04:00
|
|
|
/*
|
|
|
|
* Copyright 2002-2005, Instant802 Networks, Inc.
|
|
|
|
* Copyright 2006-2007 Jiri Benc <jbenc@suse.cz>
|
2014-09-03 16:24:57 +04:00
|
|
|
* Copyright 2013-2014 Intel Mobile Communications GmbH
|
2017-04-26 15:51:20 +03:00
|
|
|
* Copyright (C) 2015 - 2017 Intel Deutschland GmbH
|
2021-05-11 21:02:47 +03:00
|
|
|
* Copyright (C) 2018-2021 Intel Corporation
|
2007-05-05 22:45:53 +04:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
2012-03-01 18:22:09 +04:00
|
|
|
#include <linux/etherdevice.h>
|
2007-05-05 22:45:53 +04:00
|
|
|
#include <linux/netdevice.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/skbuff.h>
|
|
|
|
#include <linux/if_arp.h>
|
2007-12-17 17:07:43 +03:00
|
|
|
#include <linux/timer.h>
|
2008-02-25 18:27:46 +03:00
|
|
|
#include <linux/rtnetlink.h>
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2017-04-06 12:38:26 +03:00
|
|
|
#include <net/codel.h>
|
2007-05-05 22:45:53 +04:00
|
|
|
#include <net/mac80211.h>
|
|
|
|
#include "ieee80211_i.h"
|
2009-04-23 20:52:52 +04:00
|
|
|
#include "driver-ops.h"
|
2008-04-08 23:14:40 +04:00
|
|
|
#include "rate.h"
|
2007-05-05 22:45:53 +04:00
|
|
|
#include "sta_info.h"
|
2007-05-05 22:46:38 +04:00
|
|
|
#include "debugfs_sta.h"
|
2008-02-23 17:17:11 +03:00
|
|
|
#include "mesh.h"
|
2011-09-29 18:04:34 +04:00
|
|
|
#include "wme.h"
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2008-02-25 18:27:46 +03:00
|
|
|
/**
|
|
|
|
* DOC: STA information lifetime rules
|
|
|
|
*
|
|
|
|
* STA info structures (&struct sta_info) are managed in a hash table
|
|
|
|
* for faster lookup and a list for iteration. They are managed using
|
|
|
|
* RCU, i.e. access to the list and hash table is protected by RCU.
|
|
|
|
*
|
2010-02-03 15:59:58 +03:00
|
|
|
* Upon allocating a STA info structure with sta_info_alloc(), the caller
|
|
|
|
* owns that structure. It must then insert it into the hash table using
|
|
|
|
* either sta_info_insert() or sta_info_insert_rcu(); only in the latter
|
|
|
|
* case (which acquires an rcu read section but must not be called from
|
|
|
|
* within one) will the pointer still be valid after the call. Note that
|
|
|
|
* the caller may not do much with the STA info before inserting it, in
|
|
|
|
* particular, it may not start any mesh peer link management or add
|
|
|
|
* encryption keys.
|
2008-04-01 17:21:00 +04:00
|
|
|
*
|
|
|
|
* When the insertion fails (sta_info_insert()) returns non-zero), the
|
|
|
|
* structure will have been freed by sta_info_insert()!
|
2008-02-25 18:27:46 +03:00
|
|
|
*
|
2010-02-03 15:59:58 +03:00
|
|
|
* Station entries are added by mac80211 when you establish a link with a
|
2009-06-03 02:38:14 +04:00
|
|
|
* peer. This means different things for the different type of interfaces
|
|
|
|
* we support. For a regular station this mean we add the AP sta when we
|
2011-03-31 05:57:33 +04:00
|
|
|
* receive an association response from the AP. For IBSS this occurs when
|
2010-02-03 15:59:58 +03:00
|
|
|
* get to know about a peer on the same IBSS. For WDS we add the sta for
|
2011-03-31 05:57:33 +04:00
|
|
|
* the peer immediately upon device open. When using AP mode we add stations
|
2010-02-03 15:59:58 +03:00
|
|
|
* for each respective station upon request from userspace through nl80211.
|
2009-06-03 02:38:14 +04:00
|
|
|
*
|
2010-02-03 15:59:58 +03:00
|
|
|
* In order to remove a STA info structure, various sta_info_destroy_*()
|
|
|
|
* calls are available.
|
2008-02-25 18:27:46 +03:00
|
|
|
*
|
2010-02-03 15:59:58 +03:00
|
|
|
* There is no concept of ownership on a STA entry, each structure is
|
|
|
|
* owned by the global hash table/list until it is removed. All users of
|
|
|
|
* the structure need to be RCU protected so that the structure won't be
|
|
|
|
* freed before they are done using it.
|
2008-02-25 18:27:46 +03:00
|
|
|
*/
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2022-06-01 00:20:08 +03:00
|
|
|
struct sta_link_alloc {
|
|
|
|
struct link_sta_info info;
|
|
|
|
struct ieee80211_link_sta sta;
|
2022-06-15 10:20:45 +03:00
|
|
|
struct rcu_head rcu_head;
|
2022-06-01 00:20:08 +03:00
|
|
|
};
|
|
|
|
|
2015-02-13 23:55:15 +03:00
|
|
|
static const struct rhashtable_params sta_rht_params = {
|
|
|
|
.nelem_hint = 3, /* start small */
|
2015-04-24 12:10:10 +03:00
|
|
|
.automatic_shrinking = true,
|
2015-02-13 23:55:15 +03:00
|
|
|
.head_offset = offsetof(struct sta_info, hash_node),
|
2015-06-16 17:22:12 +03:00
|
|
|
.key_offset = offsetof(struct sta_info, addr),
|
2015-02-13 23:55:15 +03:00
|
|
|
.key_len = ETH_ALEN,
|
2015-04-23 18:26:06 +03:00
|
|
|
.max_size = CONFIG_MAC80211_STA_HASH_MAX_SIZE,
|
2015-02-13 23:55:15 +03:00
|
|
|
};
|
|
|
|
|
2022-06-14 14:07:42 +03:00
|
|
|
static const struct rhashtable_params link_sta_rht_params = {
|
|
|
|
.nelem_hint = 3, /* start small */
|
|
|
|
.automatic_shrinking = true,
|
|
|
|
.head_offset = offsetof(struct link_sta_info, link_hash_node),
|
|
|
|
.key_offset = offsetof(struct link_sta_info, addr),
|
|
|
|
.key_len = ETH_ALEN,
|
|
|
|
.max_size = CONFIG_MAC80211_STA_HASH_MAX_SIZE,
|
|
|
|
};
|
|
|
|
|
2011-12-15 14:24:20 +04:00
|
|
|
/* Caller must hold local->sta_mtx */
|
2007-07-27 17:43:23 +04:00
|
|
|
static int sta_info_hash_del(struct ieee80211_local *local,
|
|
|
|
struct sta_info *sta)
|
2007-05-05 22:45:53 +04:00
|
|
|
{
|
2016-09-19 14:00:10 +03:00
|
|
|
return rhltable_remove(&local->sta_hash, &sta->hash_node,
|
|
|
|
sta_rht_params);
|
2007-05-05 22:45:53 +04:00
|
|
|
}
|
|
|
|
|
2022-07-15 00:40:47 +03:00
|
|
|
static int link_sta_info_hash_add(struct ieee80211_local *local,
|
|
|
|
struct link_sta_info *link_sta)
|
|
|
|
{
|
2022-07-19 13:08:29 +03:00
|
|
|
lockdep_assert_held(&local->sta_mtx);
|
2022-07-15 00:40:47 +03:00
|
|
|
return rhltable_insert(&local->link_sta_hash,
|
|
|
|
&link_sta->link_hash_node,
|
|
|
|
link_sta_rht_params);
|
|
|
|
}
|
|
|
|
|
2022-06-14 14:07:42 +03:00
|
|
|
static int link_sta_info_hash_del(struct ieee80211_local *local,
|
|
|
|
struct link_sta_info *link_sta)
|
|
|
|
{
|
2022-07-19 13:08:29 +03:00
|
|
|
lockdep_assert_held(&local->sta_mtx);
|
2022-06-14 14:07:42 +03:00
|
|
|
return rhltable_remove(&local->link_sta_hash,
|
|
|
|
&link_sta->link_hash_node,
|
|
|
|
link_sta_rht_params);
|
|
|
|
}
|
|
|
|
|
2014-02-17 23:49:03 +04:00
|
|
|
static void __cleanup_single_sta(struct sta_info *sta)
|
2012-09-09 15:43:51 +04:00
|
|
|
{
|
|
|
|
int ac, i;
|
|
|
|
struct tid_ampdu_tx *tid_tx;
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
2012-10-10 23:39:50 +04:00
|
|
|
struct ps_data *ps;
|
2012-09-09 15:43:51 +04:00
|
|
|
|
2014-02-20 14:19:58 +04:00
|
|
|
if (test_sta_flag(sta, WLAN_STA_PS_STA) ||
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
test_sta_flag(sta, WLAN_STA_PS_DRIVER) ||
|
|
|
|
test_sta_flag(sta, WLAN_STA_PS_DELIVER)) {
|
2012-10-10 23:39:50 +04:00
|
|
|
if (sta->sdata->vif.type == NL80211_IFTYPE_AP ||
|
|
|
|
sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
|
|
|
|
ps = &sdata->bss->ps;
|
2013-01-30 21:14:08 +04:00
|
|
|
else if (ieee80211_vif_is_mesh(&sdata->vif))
|
|
|
|
ps = &sdata->u.mesh.ps;
|
2012-10-10 23:39:50 +04:00
|
|
|
else
|
|
|
|
return;
|
2012-09-09 15:43:51 +04:00
|
|
|
|
|
|
|
clear_sta_flag(sta, WLAN_STA_PS_STA);
|
2014-02-20 14:19:58 +04:00
|
|
|
clear_sta_flag(sta, WLAN_STA_PS_DRIVER);
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
clear_sta_flag(sta, WLAN_STA_PS_DELIVER);
|
2012-09-09 15:43:51 +04:00
|
|
|
|
2012-10-10 23:39:50 +04:00
|
|
|
atomic_dec(&ps->num_sta_ps);
|
2012-09-09 15:43:51 +04:00
|
|
|
}
|
|
|
|
|
2022-10-09 19:30:40 +03:00
|
|
|
for (i = 0; i < ARRAY_SIZE(sta->sta.txq); i++) {
|
|
|
|
struct txq_info *txqi;
|
2018-08-31 11:31:08 +03:00
|
|
|
|
2022-10-09 19:30:40 +03:00
|
|
|
if (!sta->sta.txq[i])
|
|
|
|
continue;
|
2018-08-31 11:31:08 +03:00
|
|
|
|
2022-10-09 19:30:40 +03:00
|
|
|
txqi = to_txq_info(sta->sta.txq[i]);
|
2015-03-27 23:30:37 +03:00
|
|
|
|
2022-10-09 19:30:40 +03:00
|
|
|
ieee80211_txq_purge(local, txqi);
|
2015-03-27 23:30:37 +03:00
|
|
|
}
|
|
|
|
|
2012-09-09 15:43:51 +04:00
|
|
|
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
|
|
|
|
local->total_ps_buffered -= skb_queue_len(&sta->ps_tx_buf[ac]);
|
2012-11-10 06:44:14 +04:00
|
|
|
ieee80211_purge_tx_queue(&local->hw, &sta->ps_tx_buf[ac]);
|
|
|
|
ieee80211_purge_tx_queue(&local->hw, &sta->tx_filtered[ac]);
|
2012-09-09 15:43:51 +04:00
|
|
|
}
|
|
|
|
|
2013-02-06 22:17:21 +04:00
|
|
|
if (ieee80211_vif_is_mesh(&sdata->vif))
|
|
|
|
mesh_sta_cleanup(sta);
|
2012-09-09 15:43:51 +04:00
|
|
|
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
cancel_work_sync(&sta->drv_deliver_wk);
|
2012-09-09 15:43:51 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Destroy aggregation state here. It would be nice to wait for the
|
|
|
|
* driver to finish aggregation stop and then clean up, but for now
|
|
|
|
* drivers have to handle aggregation stop being requested, followed
|
|
|
|
* directly by station destruction.
|
|
|
|
*/
|
2012-11-15 02:22:21 +04:00
|
|
|
for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
|
2013-06-13 00:47:56 +04:00
|
|
|
kfree(sta->ampdu_mlme.tid_start_tx[i]);
|
2012-09-09 15:43:51 +04:00
|
|
|
tid_tx = rcu_dereference_raw(sta->ampdu_mlme.tid_tx[i]);
|
|
|
|
if (!tid_tx)
|
|
|
|
continue;
|
2012-11-10 06:44:14 +04:00
|
|
|
ieee80211_purge_tx_queue(&local->hw, &tid_tx->pending);
|
2012-09-09 15:43:51 +04:00
|
|
|
kfree(tid_tx);
|
|
|
|
}
|
2014-02-17 23:49:03 +04:00
|
|
|
}
|
2012-09-09 15:43:51 +04:00
|
|
|
|
2014-02-17 23:49:03 +04:00
|
|
|
static void cleanup_single_sta(struct sta_info *sta)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
|
|
|
|
__cleanup_single_sta(sta);
|
2012-09-09 15:43:51 +04:00
|
|
|
sta_info_free(local, sta);
|
|
|
|
}
|
|
|
|
|
2016-09-19 14:00:10 +03:00
|
|
|
struct rhlist_head *sta_info_hash_lookup(struct ieee80211_local *local,
|
|
|
|
const u8 *addr)
|
|
|
|
{
|
|
|
|
return rhltable_lookup(&local->sta_hash, addr, sta_rht_params);
|
|
|
|
}
|
|
|
|
|
2008-02-25 18:27:46 +03:00
|
|
|
/* protected by RCU */
|
2009-11-25 19:46:18 +03:00
|
|
|
struct sta_info *sta_info_get(struct ieee80211_sub_if_data *sdata,
|
|
|
|
const u8 *addr)
|
2007-05-05 22:45:53 +04:00
|
|
|
{
|
2009-11-25 19:46:18 +03:00
|
|
|
struct ieee80211_local *local = sdata->local;
|
2016-09-19 14:00:10 +03:00
|
|
|
struct rhlist_head *tmp;
|
2015-04-23 15:02:30 +03:00
|
|
|
struct sta_info *sta;
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2015-04-23 15:02:30 +03:00
|
|
|
rcu_read_lock();
|
2016-09-19 14:00:10 +03:00
|
|
|
for_each_sta_info(local, addr, sta, tmp) {
|
2015-04-23 15:02:30 +03:00
|
|
|
if (sta->sdata == sdata) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
/* this is safe as the caller must already hold
|
|
|
|
* another rcu read section or the mutex
|
|
|
|
*/
|
|
|
|
return sta;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
return NULL;
|
2008-02-21 16:09:30 +03:00
|
|
|
}
|
|
|
|
|
2010-01-08 20:10:58 +03:00
|
|
|
/*
|
|
|
|
* Get sta info either from the specified interface
|
|
|
|
* or from one of its vlans
|
|
|
|
*/
|
|
|
|
struct sta_info *sta_info_get_bss(struct ieee80211_sub_if_data *sdata,
|
|
|
|
const u8 *addr)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
2016-09-19 14:00:10 +03:00
|
|
|
struct rhlist_head *tmp;
|
2010-01-08 20:10:58 +03:00
|
|
|
struct sta_info *sta;
|
|
|
|
|
2015-02-13 23:55:15 +03:00
|
|
|
rcu_read_lock();
|
2016-09-19 14:00:10 +03:00
|
|
|
for_each_sta_info(local, addr, sta, tmp) {
|
2015-02-13 23:55:15 +03:00
|
|
|
if (sta->sdata == sdata ||
|
|
|
|
(sta->sdata->bss && sta->sdata->bss == sdata->bss)) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
/* this is safe as the caller must already hold
|
|
|
|
* another rcu read section or the mutex
|
|
|
|
*/
|
|
|
|
return sta;
|
|
|
|
}
|
2010-01-08 20:10:58 +03:00
|
|
|
}
|
2015-02-13 23:55:15 +03:00
|
|
|
rcu_read_unlock();
|
|
|
|
return NULL;
|
2010-01-08 20:10:58 +03:00
|
|
|
}
|
|
|
|
|
2022-06-14 14:07:42 +03:00
|
|
|
struct rhlist_head *link_sta_info_hash_lookup(struct ieee80211_local *local,
|
|
|
|
const u8 *addr)
|
|
|
|
{
|
|
|
|
return rhltable_lookup(&local->link_sta_hash, addr,
|
|
|
|
link_sta_rht_params);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct link_sta_info *
|
|
|
|
link_sta_info_get_bss(struct ieee80211_sub_if_data *sdata, const u8 *addr)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
struct rhlist_head *tmp;
|
|
|
|
struct link_sta_info *link_sta;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
for_each_link_sta_info(local, addr, link_sta, tmp) {
|
|
|
|
struct sta_info *sta = link_sta->sta;
|
|
|
|
|
|
|
|
if (sta->sdata == sdata ||
|
|
|
|
(sta->sdata->bss && sta->sdata->bss == sdata->bss)) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
/* this is safe as the caller must already hold
|
|
|
|
* another rcu read section or the mutex
|
|
|
|
*/
|
|
|
|
return link_sta;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2022-09-02 17:12:43 +03:00
|
|
|
struct ieee80211_sta *
|
|
|
|
ieee80211_find_sta_by_link_addrs(struct ieee80211_hw *hw,
|
|
|
|
const u8 *addr,
|
|
|
|
const u8 *localaddr,
|
|
|
|
unsigned int *link_id)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = hw_to_local(hw);
|
|
|
|
struct link_sta_info *link_sta;
|
|
|
|
struct rhlist_head *tmp;
|
|
|
|
|
|
|
|
for_each_link_sta_info(local, addr, link_sta, tmp) {
|
|
|
|
struct sta_info *sta = link_sta->sta;
|
|
|
|
struct ieee80211_link_data *link;
|
|
|
|
u8 _link_id = link_sta->link_id;
|
|
|
|
|
|
|
|
if (!localaddr) {
|
|
|
|
if (link_id)
|
|
|
|
*link_id = _link_id;
|
|
|
|
return &sta->sta;
|
|
|
|
}
|
|
|
|
|
|
|
|
link = rcu_dereference(sta->sdata->link[_link_id]);
|
|
|
|
if (!link)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (memcmp(link->conf->addr, localaddr, ETH_ALEN))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (link_id)
|
|
|
|
*link_id = _link_id;
|
|
|
|
return &sta->sta;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(ieee80211_find_sta_by_link_addrs);
|
|
|
|
|
2019-11-12 16:08:35 +03:00
|
|
|
struct sta_info *sta_info_get_by_addrs(struct ieee80211_local *local,
|
|
|
|
const u8 *sta_addr, const u8 *vif_addr)
|
|
|
|
{
|
|
|
|
struct rhlist_head *tmp;
|
|
|
|
struct sta_info *sta;
|
|
|
|
|
|
|
|
for_each_sta_info(local, sta_addr, sta, tmp) {
|
|
|
|
if (ether_addr_equal(vif_addr, sta->sdata->vif.addr))
|
|
|
|
return sta;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2009-11-16 14:00:37 +03:00
|
|
|
struct sta_info *sta_info_get_by_idx(struct ieee80211_sub_if_data *sdata,
|
|
|
|
int idx)
|
2008-02-23 17:17:11 +03:00
|
|
|
{
|
2009-11-16 14:00:37 +03:00
|
|
|
struct ieee80211_local *local = sdata->local;
|
2008-02-23 17:17:11 +03:00
|
|
|
struct sta_info *sta;
|
|
|
|
int i = 0;
|
|
|
|
|
2020-04-09 11:29:06 +03:00
|
|
|
list_for_each_entry_rcu(sta, &local->sta_list, list,
|
|
|
|
lockdep_is_held(&local->sta_mtx)) {
|
2009-11-16 14:00:37 +03:00
|
|
|
if (sdata != sta->sdata)
|
2008-03-01 04:51:25 +03:00
|
|
|
continue;
|
2008-02-23 17:17:11 +03:00
|
|
|
if (i < idx) {
|
|
|
|
++i;
|
|
|
|
continue;
|
|
|
|
}
|
2008-03-01 04:51:25 +03:00
|
|
|
return sta;
|
2008-02-23 17:17:11 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2022-06-01 00:20:08 +03:00
|
|
|
static void sta_info_free_link(struct link_sta_info *link_sta)
|
2022-05-30 22:31:37 +03:00
|
|
|
{
|
2022-06-01 00:20:08 +03:00
|
|
|
free_percpu(link_sta->pcpu_rx_stats);
|
|
|
|
}
|
2022-05-30 22:31:37 +03:00
|
|
|
|
2022-06-14 14:07:42 +03:00
|
|
|
static void sta_remove_link(struct sta_info *sta, unsigned int link_id,
|
|
|
|
bool unhash)
|
2022-06-01 00:20:08 +03:00
|
|
|
{
|
|
|
|
struct sta_link_alloc *alloc = NULL;
|
2022-06-15 10:20:45 +03:00
|
|
|
struct link_sta_info *link_sta;
|
2022-05-30 22:31:37 +03:00
|
|
|
|
2022-06-15 10:20:45 +03:00
|
|
|
link_sta = rcu_dereference_protected(sta->link[link_id],
|
|
|
|
lockdep_is_held(&sta->local->sta_mtx));
|
|
|
|
|
|
|
|
if (WARN_ON(!link_sta))
|
2022-06-01 00:20:08 +03:00
|
|
|
return;
|
|
|
|
|
2022-06-14 14:07:42 +03:00
|
|
|
if (unhash)
|
|
|
|
link_sta_info_hash_del(sta->local, link_sta);
|
|
|
|
|
2022-09-06 15:26:52 +03:00
|
|
|
if (test_sta_flag(sta, WLAN_STA_INSERTED))
|
|
|
|
ieee80211_link_sta_debugfs_remove(link_sta);
|
|
|
|
|
2022-06-15 10:20:45 +03:00
|
|
|
if (link_sta != &sta->deflink)
|
|
|
|
alloc = container_of(link_sta, typeof(*alloc), info);
|
2022-06-01 00:20:08 +03:00
|
|
|
|
|
|
|
sta->sta.valid_links &= ~BIT(link_id);
|
2022-06-15 10:20:45 +03:00
|
|
|
RCU_INIT_POINTER(sta->link[link_id], NULL);
|
|
|
|
RCU_INIT_POINTER(sta->sta.link[link_id], NULL);
|
2022-06-01 00:20:08 +03:00
|
|
|
if (alloc) {
|
|
|
|
sta_info_free_link(&alloc->info);
|
2022-06-15 10:20:45 +03:00
|
|
|
kfree_rcu(alloc, rcu_head);
|
2022-05-30 22:31:37 +03:00
|
|
|
}
|
2022-09-02 17:12:54 +03:00
|
|
|
|
|
|
|
ieee80211_sta_recalc_aggregates(&sta->sta);
|
2022-05-30 22:31:37 +03:00
|
|
|
}
|
|
|
|
|
2008-04-01 17:21:00 +04:00
|
|
|
/**
|
2011-12-14 15:35:30 +04:00
|
|
|
* sta_info_free - free STA
|
2008-04-01 17:21:00 +04:00
|
|
|
*
|
2008-07-04 00:52:18 +04:00
|
|
|
* @local: pointer to the global information
|
2008-04-01 17:21:00 +04:00
|
|
|
* @sta: STA info to free
|
|
|
|
*
|
|
|
|
* This function must undo everything done by sta_info_alloc()
|
2011-12-14 15:35:30 +04:00
|
|
|
* that may happen before sta_info_insert(). It may only be
|
|
|
|
* called when sta_info_insert() has not been attempted (and
|
|
|
|
* if that fails, the station is freed anyway.)
|
2008-04-01 17:21:00 +04:00
|
|
|
*/
|
2011-12-14 15:35:30 +04:00
|
|
|
void sta_info_free(struct ieee80211_local *local, struct sta_info *sta)
|
2008-04-01 17:21:00 +04:00
|
|
|
{
|
2022-06-01 00:20:08 +03:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(sta->link); i++) {
|
|
|
|
if (!(sta->sta.valid_links & BIT(i)))
|
|
|
|
continue;
|
|
|
|
|
2022-07-18 23:54:27 +03:00
|
|
|
sta_remove_link(sta, i, false);
|
2022-06-01 00:20:08 +03:00
|
|
|
}
|
|
|
|
|
2020-10-09 15:17:11 +03:00
|
|
|
/*
|
|
|
|
* If we had used sta_info_pre_move_state() then we might not
|
|
|
|
* have gone through the state transitions down again, so do
|
|
|
|
* it here now (and warn if it's inserted).
|
|
|
|
*
|
|
|
|
* This will clear state such as fast TX/RX that may have been
|
|
|
|
* allocated during state transitions.
|
|
|
|
*/
|
|
|
|
while (sta->sta_state > IEEE80211_STA_NONE) {
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
WARN_ON_ONCE(test_sta_flag(sta, WLAN_STA_INSERTED));
|
|
|
|
|
|
|
|
ret = sta_info_move_state(sta, sta->sta_state - 1);
|
|
|
|
if (WARN_ONCE(ret, "sta_info_move_state() returned %d\n", ret))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2012-01-17 13:33:29 +04:00
|
|
|
if (sta->rate_ctrl)
|
2009-11-17 20:18:36 +03:00
|
|
|
rate_control_free_sta(sta);
|
2008-04-01 17:21:00 +04:00
|
|
|
|
2012-06-22 13:29:50 +04:00
|
|
|
sta_dbg(sta->sdata, "Destroyed STA %pM\n", sta->sta.addr);
|
2008-04-01 17:21:00 +04:00
|
|
|
|
2022-10-09 19:30:40 +03:00
|
|
|
kfree(to_txq_info(sta->sta.txq[0]));
|
2014-05-28 00:33:57 +04:00
|
|
|
kfree(rcu_dereference_raw(sta->sta.rates));
|
2015-06-17 11:31:00 +03:00
|
|
|
#ifdef CONFIG_MAC80211_MESH
|
|
|
|
kfree(sta->mesh);
|
|
|
|
#endif
|
2022-05-30 22:31:37 +03:00
|
|
|
|
2022-06-01 00:20:08 +03:00
|
|
|
sta_info_free_link(&sta->deflink);
|
2008-04-01 17:21:00 +04:00
|
|
|
kfree(sta);
|
|
|
|
}
|
|
|
|
|
2011-12-15 14:24:20 +04:00
|
|
|
/* Caller must hold local->sta_mtx */
|
2016-03-31 18:22:45 +03:00
|
|
|
static int sta_info_hash_add(struct ieee80211_local *local,
|
|
|
|
struct sta_info *sta)
|
2007-05-05 22:45:53 +04:00
|
|
|
{
|
2016-09-19 14:00:10 +03:00
|
|
|
return rhltable_insert(&local->sta_hash, &sta->hash_node,
|
|
|
|
sta_rht_params);
|
2007-05-05 22:45:53 +04:00
|
|
|
}
|
|
|
|
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
static void sta_deliver_ps_frames(struct work_struct *wk)
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
{
|
|
|
|
struct sta_info *sta;
|
|
|
|
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
sta = container_of(wk, struct sta_info, drv_deliver_wk);
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
|
|
|
if (sta->dead)
|
|
|
|
return;
|
|
|
|
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
local_bh_disable();
|
|
|
|
if (!test_sta_flag(sta, WLAN_STA_PS_STA))
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
ieee80211_sta_ps_deliver_wakeup(sta);
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
else if (test_and_clear_sta_flag(sta, WLAN_STA_PSPOLL))
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
ieee80211_sta_ps_deliver_poll_response(sta);
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
else if (test_and_clear_sta_flag(sta, WLAN_STA_UAPSD))
|
2011-09-29 18:04:33 +04:00
|
|
|
ieee80211_sta_ps_deliver_uapsd(sta);
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
local_bh_enable();
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
}
|
|
|
|
|
2009-11-17 20:18:36 +03:00
|
|
|
static int sta_prepare_rate_control(struct ieee80211_local *local,
|
|
|
|
struct sta_info *sta, gfp_t gfp)
|
|
|
|
{
|
2015-06-02 22:39:54 +03:00
|
|
|
if (ieee80211_hw_check(&local->hw, HAS_RATE_CONTROL))
|
2009-11-17 20:18:36 +03:00
|
|
|
return 0;
|
|
|
|
|
2012-01-17 13:33:29 +04:00
|
|
|
sta->rate_ctrl = local->rate_ctrl;
|
2009-11-17 20:18:36 +03:00
|
|
|
sta->rate_ctrl_priv = rate_control_alloc_sta(sta->rate_ctrl,
|
2015-03-05 18:10:08 +03:00
|
|
|
sta, gfp);
|
2012-01-17 13:33:29 +04:00
|
|
|
if (!sta->rate_ctrl_priv)
|
2009-11-17 20:18:36 +03:00
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-06-01 00:20:08 +03:00
|
|
|
static int sta_info_alloc_link(struct ieee80211_local *local,
|
|
|
|
struct link_sta_info *link_info,
|
|
|
|
gfp_t gfp)
|
2022-05-30 22:31:37 +03:00
|
|
|
{
|
|
|
|
struct ieee80211_hw *hw = &local->hw;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (ieee80211_hw_check(hw, USES_RSS)) {
|
|
|
|
link_info->pcpu_rx_stats =
|
|
|
|
alloc_percpu_gfp(struct ieee80211_sta_rx_stats, gfp);
|
|
|
|
if (!link_info->pcpu_rx_stats)
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
link_info->rx_stats.last_rx = jiffies;
|
|
|
|
u64_stats_init(&link_info->rx_stats.syncp);
|
|
|
|
|
|
|
|
ewma_signal_init(&link_info->rx_stats_avg.signal);
|
|
|
|
ewma_avg_signal_init(&link_info->status_stats.avg_ack_signal);
|
|
|
|
for (i = 0; i < ARRAY_SIZE(link_info->rx_stats_avg.chain_signal); i++)
|
|
|
|
ewma_signal_init(&link_info->rx_stats_avg.chain_signal[i]);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-06-01 00:20:08 +03:00
|
|
|
static void sta_info_add_link(struct sta_info *sta,
|
|
|
|
unsigned int link_id,
|
|
|
|
struct link_sta_info *link_info,
|
|
|
|
struct ieee80211_link_sta *link_sta)
|
|
|
|
{
|
|
|
|
link_info->sta = sta;
|
|
|
|
link_info->link_id = link_id;
|
2022-06-15 10:20:45 +03:00
|
|
|
link_info->pub = link_sta;
|
2022-09-06 20:02:04 +03:00
|
|
|
link_info->pub->sta = &sta->sta;
|
2022-08-19 14:12:38 +03:00
|
|
|
link_sta->link_id = link_id;
|
2022-06-15 10:20:45 +03:00
|
|
|
rcu_assign_pointer(sta->link[link_id], link_info);
|
|
|
|
rcu_assign_pointer(sta->sta.link[link_id], link_sta);
|
2022-09-02 17:12:41 +03:00
|
|
|
|
|
|
|
link_sta->smps_mode = IEEE80211_SMPS_OFF;
|
2022-09-02 17:12:54 +03:00
|
|
|
link_sta->agg.max_rc_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_BA;
|
2022-06-01 00:20:08 +03:00
|
|
|
}
|
|
|
|
|
2022-07-15 00:40:47 +03:00
|
|
|
static struct sta_info *
|
|
|
|
__sta_info_alloc(struct ieee80211_sub_if_data *sdata,
|
|
|
|
const u8 *addr, int link_id, const u8 *link_addr,
|
|
|
|
gfp_t gfp)
|
2007-05-05 22:45:53 +04:00
|
|
|
{
|
2008-02-25 18:27:46 +03:00
|
|
|
struct ieee80211_local *local = sdata->local;
|
2015-03-27 23:30:37 +03:00
|
|
|
struct ieee80211_hw *hw = &local->hw;
|
2007-05-05 22:45:53 +04:00
|
|
|
struct sta_info *sta;
|
2022-10-09 19:30:40 +03:00
|
|
|
void *txq_data;
|
|
|
|
int size;
|
2007-12-25 18:00:34 +03:00
|
|
|
int i;
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2015-03-27 23:30:37 +03:00
|
|
|
sta = kzalloc(sizeof(*sta) + hw->sta_data_size, gfp);
|
2007-05-05 22:45:53 +04:00
|
|
|
if (!sta)
|
2008-02-25 18:27:47 +03:00
|
|
|
return NULL;
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2022-05-30 22:31:37 +03:00
|
|
|
sta->local = local;
|
|
|
|
sta->sdata = sdata;
|
|
|
|
|
2022-06-01 00:20:08 +03:00
|
|
|
if (sta_info_alloc_link(local, &sta->deflink, gfp))
|
2022-08-23 16:22:23 +03:00
|
|
|
goto free;
|
2016-03-31 20:02:11 +03:00
|
|
|
|
2022-06-01 00:20:08 +03:00
|
|
|
if (link_id >= 0) {
|
|
|
|
sta_info_add_link(sta, link_id, &sta->deflink,
|
|
|
|
&sta->sta.deflink);
|
|
|
|
sta->sta.valid_links = BIT(link_id);
|
|
|
|
} else {
|
|
|
|
sta_info_add_link(sta, 0, &sta->deflink, &sta->sta.deflink);
|
|
|
|
}
|
|
|
|
|
2022-09-02 17:12:54 +03:00
|
|
|
sta->sta.cur = &sta->sta.deflink.agg;
|
|
|
|
|
2008-05-03 03:02:02 +04:00
|
|
|
spin_lock_init(&sta->lock);
|
mac80211: fix AP powersave TX vs. wakeup race
There is a race between the TX path and the STA wakeup: while
a station is sleeping, mac80211 buffers frames until it wakes
up, then the frames are transmitted. However, the RX and TX
path are concurrent, so the packet indicating wakeup can be
processed while a packet is being transmitted.
This can lead to a situation where the buffered frames list
is emptied on the one side, while a frame is being added on
the other side, as the station is still seen as sleeping in
the TX path.
As a result, the newly added frame will not be send anytime
soon. It might be sent much later (and out of order) when the
station goes to sleep and wakes up the next time.
Additionally, it can lead to the crash below.
Fix all this by synchronising both paths with a new lock.
Both path are not fastpath since they handle PS situations.
In a later patch we'll remove the extra skb queue locks to
reduce locking overhead.
BUG: unable to handle kernel
NULL pointer dereference at 000000b0
IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
*pde = 00000000
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
Stack:
e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
Call Trace:
[<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
[<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
[<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
[<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
[<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
[<c149ef70>] dev_hard_start_xmit+0x450/0x950
[<c14b9aa9>] sch_direct_xmit+0xa9/0x250
[<c14b9c9b>] __qdisc_run+0x4b/0x150
[<c149f732>] dev_queue_xmit+0x2c2/0xca0
Cc: stable@vger.kernel.org
Reported-by: Yaara Rozenblum <yaara.rozenblum@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
[reword commit log, use a separate lock]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-02-20 11:22:11 +04:00
|
|
|
spin_lock_init(&sta->ps_lock);
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
INIT_WORK(&sta->drv_deliver_wk, sta_deliver_ps_frames);
|
2010-06-10 12:21:43 +04:00
|
|
|
INIT_WORK(&sta->ampdu_mlme.work, ieee80211_ba_session_work);
|
2010-06-10 12:21:46 +04:00
|
|
|
mutex_init(&sta->ampdu_mlme.mtx);
|
2013-03-02 10:02:52 +04:00
|
|
|
#ifdef CONFIG_MAC80211_MESH
|
2015-06-17 11:31:00 +03:00
|
|
|
if (ieee80211_vif_is_mesh(&sdata->vif)) {
|
|
|
|
sta->mesh = kzalloc(sizeof(*sta->mesh), gfp);
|
|
|
|
if (!sta->mesh)
|
|
|
|
goto free;
|
2017-10-05 20:39:10 +03:00
|
|
|
sta->mesh->plink_sta = sta;
|
2015-06-17 11:31:00 +03:00
|
|
|
spin_lock_init(&sta->mesh->plink_lock);
|
2022-02-03 18:30:34 +03:00
|
|
|
if (!sdata->u.mesh.user_mpm)
|
2017-10-05 20:39:10 +03:00
|
|
|
timer_setup(&sta->mesh->plink_timer, mesh_plink_timer,
|
|
|
|
0);
|
2015-06-17 11:31:00 +03:00
|
|
|
sta->mesh->nonpeer_pm = NL80211_MESH_POWER_ACTIVE;
|
|
|
|
}
|
2013-03-02 10:02:52 +04:00
|
|
|
#endif
|
2008-05-03 03:02:02 +04:00
|
|
|
|
2015-06-16 17:22:12 +03:00
|
|
|
memcpy(sta->addr, addr, ETH_ALEN);
|
2008-09-11 02:02:02 +04:00
|
|
|
memcpy(sta->sta.addr, addr, ETH_ALEN);
|
2022-07-15 00:40:47 +03:00
|
|
|
memcpy(sta->deflink.addr, link_addr, ETH_ALEN);
|
|
|
|
memcpy(sta->sta.deflink.addr, link_addr, ETH_ALEN);
|
2016-08-22 17:14:04 +03:00
|
|
|
sta->sta.max_rx_aggregation_subframes =
|
|
|
|
local->hw.max_rx_aggregation_subframes;
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
/* TODO link specific alloc and assignments for MLO Link STA */
|
|
|
|
|
2019-03-19 23:34:08 +03:00
|
|
|
/* Extended Key ID needs to install keys for keyid 0 and 1 Rx-only.
|
|
|
|
* The Tx path starts to use a key as soon as the key slot ptk_idx
|
|
|
|
* references to is not NULL. To not use the initial Rx-only key
|
|
|
|
* prematurely for Tx initialize ptk_idx to an impossible PTK keyid
|
|
|
|
* which always will refer to a NULL key.
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON(ARRAY_SIZE(sta->ptk) <= INVALID_PTK_KEYIDX);
|
|
|
|
sta->ptk_idx = INVALID_PTK_KEYIDX;
|
|
|
|
|
2016-03-31 20:02:09 +03:00
|
|
|
|
2021-05-11 21:02:47 +03:00
|
|
|
ieee80211_init_frag_cache(&sta->frags);
|
|
|
|
|
2012-01-20 16:55:20 +04:00
|
|
|
sta->sta_state = IEEE80211_STA_NONE;
|
|
|
|
|
2014-11-19 14:47:38 +03:00
|
|
|
/* Mark TID as unreserved */
|
|
|
|
sta->reserved_tid = IEEE80211_TID_UNRESERVED;
|
|
|
|
|
2015-09-30 14:26:36 +03:00
|
|
|
sta->last_connected = ktime_get_seconds();
|
2010-12-02 13:12:43 +03:00
|
|
|
|
2022-10-09 19:30:40 +03:00
|
|
|
size = sizeof(struct txq_info) +
|
|
|
|
ALIGN(hw->txq_data_size, sizeof(void *));
|
2015-03-27 23:30:37 +03:00
|
|
|
|
2022-10-09 19:30:40 +03:00
|
|
|
txq_data = kcalloc(ARRAY_SIZE(sta->sta.txq), size, gfp);
|
|
|
|
if (!txq_data)
|
|
|
|
goto free;
|
2015-03-27 23:30:37 +03:00
|
|
|
|
2022-10-09 19:30:40 +03:00
|
|
|
for (i = 0; i < ARRAY_SIZE(sta->sta.txq); i++) {
|
|
|
|
struct txq_info *txq = txq_data + i * size;
|
2015-03-27 23:30:37 +03:00
|
|
|
|
2022-10-09 19:30:40 +03:00
|
|
|
/* might not do anything for the (bufferable) MMPDU TXQ */
|
|
|
|
ieee80211_txq_init(sdata, sta, txq, i);
|
2015-02-25 12:03:25 +03:00
|
|
|
}
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2015-03-27 23:30:37 +03:00
|
|
|
if (sta_prepare_rate_control(local, sta, gfp))
|
|
|
|
goto free_txq;
|
|
|
|
|
2022-06-26 00:24:05 +03:00
|
|
|
sta->airtime_weight = IEEE80211_DEFAULT_AIRTIME_WEIGHT;
|
2018-12-19 04:02:08 +03:00
|
|
|
|
2011-09-29 18:04:29 +04:00
|
|
|
for (i = 0; i < IEEE80211_NUM_ACS; i++) {
|
|
|
|
skb_queue_head_init(&sta->ps_tx_buf[i]);
|
|
|
|
skb_queue_head_init(&sta->tx_filtered[i]);
|
2022-06-26 00:24:05 +03:00
|
|
|
sta->airtime[i].deficit = sta->airtime_weight;
|
|
|
|
atomic_set(&sta->airtime[i].aql_tx_pending, 0);
|
|
|
|
sta->airtime[i].aql_limit_low = local->aql_txq_limit_low[i];
|
|
|
|
sta->airtime[i].aql_limit_high = local->aql_txq_limit_high[i];
|
2011-09-29 18:04:29 +04:00
|
|
|
}
|
2008-02-25 18:27:47 +03:00
|
|
|
|
2012-11-15 02:22:21 +04:00
|
|
|
for (i = 0; i < IEEE80211_NUM_TIDS; i++)
|
2010-05-25 01:33:03 +04:00
|
|
|
sta->last_seq_ctrl[i] = cpu_to_le16(USHRT_MAX);
|
2009-05-14 17:12:08 +04:00
|
|
|
|
mac80211: use STA info in rate_control_send_low()
Even if we have a station, we currently call rate_control_send_low()
with the NULL station unless further rate control (driver, minstrel)
has been initialized.
Change this so we can use more information about the station to use
a better rate. For example, when we associate with an AP, we will
now use the lowest rate it advertised as supported (that we can)
rather than the lowest mandatory rate. This aligns our behaviour
with most other 802.11 implementations.
To make this possible, we need to also ensure that we have non-zero
rates at all times, so in case we really have *nothing* pre-fill
the supp_rates bitmap with the very lowest mandatory bitmap (11b
and 11a on 2.4 and 5 GHz respectively).
Additionally, hostapd appears to be giving us an empty supported
rates bitmap (it can and should do better, since the STA must have
supported for at least the basic rates in the BSS), so ignore any
such bitmaps that would actually zero out the supp_rates, and in
that case just keep the pre-filled mandatory rates.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-05-29 15:25:35 +03:00
|
|
|
for (i = 0; i < NUM_NL80211_BANDS; i++) {
|
|
|
|
u32 mandatory = 0;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
if (!hw->wiphy->bands[i])
|
|
|
|
continue;
|
|
|
|
|
|
|
|
switch (i) {
|
|
|
|
case NL80211_BAND_2GHZ:
|
2021-10-18 13:00:54 +03:00
|
|
|
case NL80211_BAND_LC:
|
mac80211: use STA info in rate_control_send_low()
Even if we have a station, we currently call rate_control_send_low()
with the NULL station unless further rate control (driver, minstrel)
has been initialized.
Change this so we can use more information about the station to use
a better rate. For example, when we associate with an AP, we will
now use the lowest rate it advertised as supported (that we can)
rather than the lowest mandatory rate. This aligns our behaviour
with most other 802.11 implementations.
To make this possible, we need to also ensure that we have non-zero
rates at all times, so in case we really have *nothing* pre-fill
the supp_rates bitmap with the very lowest mandatory bitmap (11b
and 11a on 2.4 and 5 GHz respectively).
Additionally, hostapd appears to be giving us an empty supported
rates bitmap (it can and should do better, since the STA must have
supported for at least the basic rates in the BSS), so ignore any
such bitmaps that would actually zero out the supp_rates, and in
that case just keep the pre-filled mandatory rates.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-05-29 15:25:35 +03:00
|
|
|
/*
|
|
|
|
* We use both here, even if we cannot really know for
|
|
|
|
* sure the station will support both, but the only use
|
|
|
|
* for this is when we don't know anything yet and send
|
|
|
|
* management frames, and then we'll pick the lowest
|
|
|
|
* possible rate anyway.
|
|
|
|
* If we don't include _G here, we cannot find a rate
|
|
|
|
* in P2P, and thus trigger the WARN_ONCE() in rate.c
|
|
|
|
*/
|
|
|
|
mandatory = IEEE80211_RATE_MANDATORY_B |
|
|
|
|
IEEE80211_RATE_MANDATORY_G;
|
|
|
|
break;
|
|
|
|
case NL80211_BAND_5GHZ:
|
|
|
|
mandatory = IEEE80211_RATE_MANDATORY_A;
|
|
|
|
break;
|
|
|
|
case NL80211_BAND_60GHZ:
|
|
|
|
WARN_ON(1);
|
|
|
|
mandatory = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (r = 0; r < hw->wiphy->bands[i]->n_bitrates; r++) {
|
|
|
|
struct ieee80211_rate *rate;
|
|
|
|
|
|
|
|
rate = &hw->wiphy->bands[i]->bitrates[r];
|
|
|
|
|
|
|
|
if (!(rate->flags & mandatory))
|
|
|
|
continue;
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
sta->sta.deflink.supp_rates[i] |= BIT(r);
|
mac80211: use STA info in rate_control_send_low()
Even if we have a station, we currently call rate_control_send_low()
with the NULL station unless further rate control (driver, minstrel)
has been initialized.
Change this so we can use more information about the station to use
a better rate. For example, when we associate with an AP, we will
now use the lowest rate it advertised as supported (that we can)
rather than the lowest mandatory rate. This aligns our behaviour
with most other 802.11 implementations.
To make this possible, we need to also ensure that we have non-zero
rates at all times, so in case we really have *nothing* pre-fill
the supp_rates bitmap with the very lowest mandatory bitmap (11b
and 11a on 2.4 and 5 GHz respectively).
Additionally, hostapd appears to be giving us an empty supported
rates bitmap (it can and should do better, since the STA must have
supported for at least the basic rates in the BSS), so ignore any
such bitmaps that would actually zero out the supp_rates, and in
that case just keep the pre-filled mandatory rates.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-05-29 15:25:35 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-06 12:38:26 +03:00
|
|
|
sta->cparams.ce_threshold = CODEL_DISABLED_THRESHOLD;
|
|
|
|
sta->cparams.target = MS2TIME(20);
|
|
|
|
sta->cparams.interval = MS2TIME(100);
|
|
|
|
sta->cparams.ecn = true;
|
fq_codel: generalise ce_threshold marking for subset of traffic
Commit e72aeb9ee0e3 ("fq_codel: implement L4S style ce_threshold_ect1
marking") expanded the ce_threshold feature of FQ-CoDel so it can
be applied to a subset of the traffic, using the ECT(1) bit of the ECN
field as the classifier. However, hard-coding ECT(1) as the only
classifier for this feature seems limiting, so let's expand it to be more
general.
To this end, change the parameter from a ce_threshold_ect1 boolean, to a
one-byte selector/mask pair (ce_threshold_{selector,mask}) which is applied
to the whole diffserv/ECN field in the IP header. This makes it possible to
classify packets by any value in either the ECN field or the diffserv
field. In particular, setting a selector of INET_ECN_ECT_1 and a mask of
INET_ECN_MASK corresponds to the functionality before this patch, and a
mask of ~INET_ECN_MASK allows using the selector as a straight-forward
match against a diffserv code point:
# apply ce_threshold to ECT(1) traffic
tc qdisc replace dev eth0 root fq_codel ce_threshold 1ms ce_threshold_selector 0x1/0x3
# apply ce_threshold to ECN-capable traffic marked as diffserv AF22
tc qdisc replace dev eth0 root fq_codel ce_threshold 1ms ce_threshold_selector 0x50/0xfc
Regardless of the selector chosen, the normal rules for ECN-marking of
packets still apply, i.e., the flow must still declare itself ECN-capable
by setting one of the bits in the ECN field to get marked at all.
v2:
- Add tc usage examples to patch description
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20211019174709.69081-1-toke@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-19 20:47:09 +03:00
|
|
|
sta->cparams.ce_threshold_selector = 0;
|
|
|
|
sta->cparams.ce_threshold_mask = 0;
|
2017-04-06 12:38:26 +03:00
|
|
|
|
2012-06-22 13:29:50 +04:00
|
|
|
sta_dbg(sdata, "Allocated STA %pM\n", sta->sta.addr);
|
2014-01-06 18:56:59 +04:00
|
|
|
|
2015-02-25 12:03:25 +03:00
|
|
|
return sta;
|
2015-03-27 23:30:37 +03:00
|
|
|
|
|
|
|
free_txq:
|
2022-10-09 19:30:40 +03:00
|
|
|
kfree(to_txq_info(sta->sta.txq[0]));
|
2015-03-27 23:30:37 +03:00
|
|
|
free:
|
2022-06-01 00:20:08 +03:00
|
|
|
sta_info_free_link(&sta->deflink);
|
2015-06-17 11:31:00 +03:00
|
|
|
#ifdef CONFIG_MAC80211_MESH
|
|
|
|
kfree(sta->mesh);
|
|
|
|
#endif
|
2015-03-27 23:30:37 +03:00
|
|
|
kfree(sta);
|
|
|
|
return NULL;
|
2008-02-25 18:27:47 +03:00
|
|
|
}
|
|
|
|
|
2022-07-15 00:40:47 +03:00
|
|
|
struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
|
|
|
|
const u8 *addr, gfp_t gfp)
|
|
|
|
{
|
|
|
|
return __sta_info_alloc(sdata, addr, -1, addr, gfp);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct sta_info *sta_info_alloc_with_link(struct ieee80211_sub_if_data *sdata,
|
|
|
|
const u8 *mld_addr,
|
|
|
|
unsigned int link_id,
|
|
|
|
const u8 *link_addr,
|
|
|
|
gfp_t gfp)
|
|
|
|
{
|
|
|
|
return __sta_info_alloc(sdata, mld_addr, link_id, link_addr, gfp);
|
|
|
|
}
|
|
|
|
|
2011-08-17 16:18:14 +04:00
|
|
|
static int sta_info_insert_check(struct sta_info *sta)
|
2010-02-03 15:59:58 +03:00
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
|
|
|
|
2008-02-27 11:56:40 +03:00
|
|
|
/*
|
|
|
|
* Can't be a WARN_ON because it can be triggered through a race:
|
|
|
|
* something inserts a STA (on one CPU) without holding the RTNL
|
|
|
|
* and another CPU turns off the net device.
|
|
|
|
*/
|
2011-08-17 16:18:14 +04:00
|
|
|
if (unlikely(!ieee80211_sdata_running(sdata)))
|
|
|
|
return -ENETDOWN;
|
2008-02-27 11:56:40 +03:00
|
|
|
|
mac80211: Convert compare_ether_addr to ether_addr_equal
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script:
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a, b)
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- compare_ether_addr(a, b)
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) == 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) != 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !!ether_addr_equal(a, b)
+ ether_addr_equal(a, b)
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-08 22:56:52 +04:00
|
|
|
if (WARN_ON(ether_addr_equal(sta->sta.addr, sdata->vif.addr) ||
|
2021-06-26 16:03:34 +03:00
|
|
|
!is_valid_ether_addr(sta->sta.addr)))
|
2011-08-17 16:18:14 +04:00
|
|
|
return -EINVAL;
|
|
|
|
|
2016-09-19 14:00:10 +03:00
|
|
|
/* The RCU read lock is required by rhashtable due to
|
|
|
|
* asynchronous resize/rehash. We also require the mutex
|
|
|
|
* for correctness.
|
2015-10-22 18:35:19 +03:00
|
|
|
*/
|
|
|
|
rcu_read_lock();
|
|
|
|
lockdep_assert_held(&sdata->local->sta_mtx);
|
|
|
|
if (ieee80211_hw_check(&sdata->local->hw, NEEDS_UNIQUE_STA_ADDR) &&
|
|
|
|
ieee80211_find_sta_by_ifaddr(&sdata->local->hw, sta->addr, NULL)) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
return -ENOTUNIQ;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2011-08-17 16:18:14 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-01-20 16:55:21 +04:00
|
|
|
static int sta_info_insert_drv_state(struct ieee80211_local *local,
|
|
|
|
struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct sta_info *sta)
|
|
|
|
{
|
|
|
|
enum ieee80211_sta_state state;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
for (state = IEEE80211_STA_NOTEXIST; state < sta->sta_state; state++) {
|
|
|
|
err = drv_sta_state(local, sdata, sta, state, state + 1);
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!err) {
|
2012-01-20 16:55:22 +04:00
|
|
|
/*
|
|
|
|
* Drivers using legacy sta_add/sta_remove callbacks only
|
|
|
|
* get uploaded set to true after sta_add is called.
|
|
|
|
*/
|
|
|
|
if (!local->ops->sta_add)
|
|
|
|
sta->uploaded = true;
|
2012-01-20 16:55:21 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_ADHOC) {
|
2012-06-22 13:29:50 +04:00
|
|
|
sdata_info(sdata,
|
|
|
|
"failed to move IBSS STA %pM to state %d (%d) - keeping it anyway\n",
|
|
|
|
sta->sta.addr, state + 1, err);
|
2012-01-20 16:55:21 +04:00
|
|
|
err = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* unwind on error */
|
|
|
|
for (; state > IEEE80211_STA_NOTEXIST; state--)
|
|
|
|
WARN_ON(drv_sta_state(local, sdata, sta, state, state - 1));
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2017-08-05 11:44:36 +03:00
|
|
|
static void
|
|
|
|
ieee80211_recalc_p2p_go_ps_allowed(struct ieee80211_sub_if_data *sdata)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
bool allow_p2p_go_ps = sdata->vif.p2p;
|
|
|
|
struct sta_info *sta;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(sta, &local->sta_list, list) {
|
|
|
|
if (sdata != sta->sdata ||
|
|
|
|
!test_sta_flag(sta, WLAN_STA_ASSOC))
|
|
|
|
continue;
|
|
|
|
if (!sta->sta.support_p2p_ps) {
|
|
|
|
allow_p2p_go_ps = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
if (allow_p2p_go_ps != sdata->vif.bss_conf.allow_p2p_go_ps) {
|
|
|
|
sdata->vif.bss_conf.allow_p2p_go_ps = allow_p2p_go_ps;
|
2022-06-17 23:36:37 +03:00
|
|
|
ieee80211_link_info_change_notify(sdata, &sdata->deflink,
|
|
|
|
BSS_CHANGED_P2P_PS);
|
2017-08-05 11:44:36 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-17 16:18:14 +04:00
|
|
|
/*
|
|
|
|
* should be called with sta_mtx locked
|
|
|
|
* this function replaces the mutex lock
|
|
|
|
* with a RCU lock
|
|
|
|
*/
|
2011-12-15 14:24:20 +04:00
|
|
|
static int sta_info_insert_finish(struct sta_info *sta) __acquires(RCU)
|
2011-08-17 16:18:14 +04:00
|
|
|
{
|
|
|
|
struct ieee80211_local *local = sta->local;
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
2016-12-14 19:28:59 +03:00
|
|
|
struct station_info *sinfo = NULL;
|
2011-08-17 16:18:14 +04:00
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
lockdep_assert_held(&local->sta_mtx);
|
2010-02-03 15:59:58 +03:00
|
|
|
|
2012-01-20 16:55:24 +04:00
|
|
|
/* check if STA exists already */
|
|
|
|
if (sta_info_get_bss(sdata, sta->sta.addr)) {
|
|
|
|
err = -EEXIST;
|
2021-10-02 17:53:29 +03:00
|
|
|
goto out_cleanup;
|
2011-12-15 14:24:20 +04:00
|
|
|
}
|
2007-12-19 03:31:26 +03:00
|
|
|
|
2016-12-14 19:28:59 +03:00
|
|
|
sinfo = kzalloc(sizeof(struct station_info), GFP_KERNEL);
|
|
|
|
if (!sinfo) {
|
|
|
|
err = -ENOMEM;
|
2021-10-02 17:53:29 +03:00
|
|
|
goto out_cleanup;
|
2016-12-14 19:28:59 +03:00
|
|
|
}
|
|
|
|
|
2012-01-20 16:55:24 +04:00
|
|
|
local->num_sta++;
|
|
|
|
local->sta_generation++;
|
|
|
|
smp_mb();
|
2011-12-15 14:24:20 +04:00
|
|
|
|
2014-02-17 23:49:03 +04:00
|
|
|
/* simplify things and don't accept BA sessions yet */
|
|
|
|
set_sta_flag(sta, WLAN_STA_BLOCK_BA);
|
|
|
|
|
2012-01-20 16:55:24 +04:00
|
|
|
/* make the station visible */
|
2016-03-31 18:22:45 +03:00
|
|
|
err = sta_info_hash_add(local, sta);
|
|
|
|
if (err)
|
|
|
|
goto out_drop_sta;
|
2012-01-12 12:31:10 +04:00
|
|
|
|
2022-07-15 00:40:47 +03:00
|
|
|
if (sta->sta.valid_links) {
|
|
|
|
err = link_sta_info_hash_add(local, &sta->deflink);
|
|
|
|
if (err) {
|
|
|
|
sta_info_hash_del(local, sta);
|
|
|
|
goto out_drop_sta;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-10-22 13:32:16 +04:00
|
|
|
list_add_tail_rcu(&sta->list, &local->sta_list);
|
2011-12-15 14:24:20 +04:00
|
|
|
|
2021-11-29 16:32:42 +03:00
|
|
|
/* update channel context before notifying the driver about state
|
|
|
|
* change, this enables driver using the updated channel context right away.
|
|
|
|
*/
|
|
|
|
if (sta->sta_state >= IEEE80211_STA_ASSOC) {
|
2022-06-22 16:15:56 +03:00
|
|
|
ieee80211_recalc_min_chandef(sta->sdata, -1);
|
2021-11-29 16:32:42 +03:00
|
|
|
if (!sta->sta.support_p2p_ps)
|
|
|
|
ieee80211_recalc_p2p_go_ps_allowed(sta->sdata);
|
|
|
|
}
|
|
|
|
|
2014-02-17 23:49:03 +04:00
|
|
|
/* notify driver */
|
|
|
|
err = sta_info_insert_drv_state(local, sdata, sta);
|
|
|
|
if (err)
|
|
|
|
goto out_remove;
|
|
|
|
|
2012-01-20 16:55:24 +04:00
|
|
|
set_sta_flag(sta, WLAN_STA_INSERTED);
|
2017-08-05 11:44:36 +03:00
|
|
|
|
2014-02-17 23:49:03 +04:00
|
|
|
/* accept BA sessions now */
|
|
|
|
clear_sta_flag(sta, WLAN_STA_BLOCK_BA);
|
2011-12-15 14:24:20 +04:00
|
|
|
|
2012-01-20 16:55:24 +04:00
|
|
|
ieee80211_sta_debugfs_add(sta);
|
|
|
|
rate_control_add_sta_debugfs(sta);
|
2022-09-06 15:26:52 +03:00
|
|
|
if (sta->sta.valid_links) {
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(sta->link); i++) {
|
|
|
|
struct link_sta_info *link_sta;
|
|
|
|
|
|
|
|
link_sta = rcu_dereference_protected(sta->link[i],
|
|
|
|
lockdep_is_held(&local->sta_mtx));
|
|
|
|
|
|
|
|
if (!link_sta)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ieee80211_link_sta_debugfs_add(link_sta);
|
|
|
|
if (sdata->vif.active_links & BIT(i))
|
|
|
|
ieee80211_link_sta_debugfs_drv_add(link_sta);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
ieee80211_link_sta_debugfs_add(&sta->deflink);
|
|
|
|
ieee80211_link_sta_debugfs_drv_add(&sta->deflink);
|
|
|
|
}
|
2011-12-15 14:24:20 +04:00
|
|
|
|
2016-01-27 01:05:31 +03:00
|
|
|
sinfo->generation = local->sta_generation;
|
|
|
|
cfg80211_new_sta(sdata->dev, sta->sta.addr, sinfo, GFP_KERNEL);
|
|
|
|
kfree(sinfo);
|
2008-02-25 18:27:46 +03:00
|
|
|
|
2012-06-22 13:29:50 +04:00
|
|
|
sta_dbg(sdata, "Inserted STA %pM\n", sta->sta.addr);
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
/* move reference to rcu-protected */
|
|
|
|
rcu_read_lock();
|
|
|
|
mutex_unlock(&local->sta_mtx);
|
2007-05-05 22:46:38 +04:00
|
|
|
|
2008-02-25 18:27:47 +03:00
|
|
|
if (ieee80211_vif_is_mesh(&sdata->vif))
|
|
|
|
mesh_accept_plinks_update(sdata);
|
|
|
|
|
2011-08-17 16:18:14 +04:00
|
|
|
return 0;
|
2014-02-17 23:49:03 +04:00
|
|
|
out_remove:
|
2022-07-18 23:54:27 +03:00
|
|
|
if (sta->sta.valid_links)
|
|
|
|
link_sta_info_hash_del(local, &sta->deflink);
|
2014-02-17 23:49:03 +04:00
|
|
|
sta_info_hash_del(local, sta);
|
|
|
|
list_del_rcu(&sta->list);
|
2016-03-31 18:22:45 +03:00
|
|
|
out_drop_sta:
|
2014-02-17 23:49:03 +04:00
|
|
|
local->num_sta--;
|
|
|
|
synchronize_net();
|
2021-10-02 17:53:29 +03:00
|
|
|
out_cleanup:
|
2020-11-12 13:22:04 +03:00
|
|
|
cleanup_single_sta(sta);
|
2011-12-15 14:24:20 +04:00
|
|
|
mutex_unlock(&local->sta_mtx);
|
2016-02-02 10:51:14 +03:00
|
|
|
kfree(sinfo);
|
2011-12-15 14:24:20 +04:00
|
|
|
rcu_read_lock();
|
|
|
|
return err;
|
2011-08-17 16:18:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
int sta_info_insert_rcu(struct sta_info *sta) __acquires(RCU)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = sta->local;
|
2014-04-21 08:53:00 +04:00
|
|
|
int err;
|
2011-08-17 16:18:14 +04:00
|
|
|
|
2011-12-15 14:24:20 +04:00
|
|
|
might_sleep();
|
|
|
|
|
2015-10-22 18:35:19 +03:00
|
|
|
mutex_lock(&local->sta_mtx);
|
|
|
|
|
2011-08-17 16:18:14 +04:00
|
|
|
err = sta_info_insert_check(sta);
|
|
|
|
if (err) {
|
2020-11-12 13:22:04 +03:00
|
|
|
sta_info_free(local, sta);
|
2015-10-22 18:35:19 +03:00
|
|
|
mutex_unlock(&local->sta_mtx);
|
2011-08-17 16:18:14 +04:00
|
|
|
rcu_read_lock();
|
2020-11-12 13:22:04 +03:00
|
|
|
return err;
|
2011-08-17 16:18:14 +04:00
|
|
|
}
|
|
|
|
|
2020-11-12 13:22:04 +03:00
|
|
|
return sta_info_insert_finish(sta);
|
2007-05-05 22:45:53 +04:00
|
|
|
}
|
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
int sta_info_insert(struct sta_info *sta)
|
|
|
|
{
|
|
|
|
int err = sta_info_insert_rcu(sta);
|
|
|
|
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2012-10-10 23:39:50 +04:00
|
|
|
static inline void __bss_tim_set(u8 *tim, u16 id)
|
2008-02-20 13:21:35 +03:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* This format has been mandated by the IEEE specifications,
|
|
|
|
* so this line may not be changed to use the __set_bit() format.
|
|
|
|
*/
|
2012-10-10 23:39:50 +04:00
|
|
|
tim[id / 8] |= (1 << (id % 8));
|
2008-02-20 13:21:35 +03:00
|
|
|
}
|
|
|
|
|
2012-10-10 23:39:50 +04:00
|
|
|
static inline void __bss_tim_clear(u8 *tim, u16 id)
|
2008-02-20 13:21:35 +03:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* This format has been mandated by the IEEE specifications,
|
|
|
|
* so this line may not be changed to use the __clear_bit() format.
|
|
|
|
*/
|
2012-10-10 23:39:50 +04:00
|
|
|
tim[id / 8] &= ~(1 << (id % 8));
|
2008-02-20 13:21:35 +03:00
|
|
|
}
|
|
|
|
|
2013-03-05 17:27:20 +04:00
|
|
|
static inline bool __bss_tim_get(u8 *tim, u16 id)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* This format has been mandated by the IEEE specifications,
|
|
|
|
* so this line may not be changed to use the test_bit() format.
|
|
|
|
*/
|
|
|
|
return tim[id / 8] & (1 << (id % 8));
|
|
|
|
}
|
|
|
|
|
2011-09-29 18:04:29 +04:00
|
|
|
static unsigned long ieee80211_tids_for_ac(int ac)
|
2008-02-20 13:21:35 +03:00
|
|
|
{
|
2011-09-29 18:04:29 +04:00
|
|
|
/* If we ever support TIDs > 7, this obviously needs to be adjusted */
|
|
|
|
switch (ac) {
|
|
|
|
case IEEE80211_AC_VO:
|
|
|
|
return BIT(6) | BIT(7);
|
|
|
|
case IEEE80211_AC_VI:
|
|
|
|
return BIT(4) | BIT(5);
|
|
|
|
case IEEE80211_AC_BE:
|
|
|
|
return BIT(0) | BIT(3);
|
|
|
|
case IEEE80211_AC_BK:
|
|
|
|
return BIT(1) | BIT(2);
|
|
|
|
default:
|
|
|
|
WARN_ON(1);
|
|
|
|
return 0;
|
2008-02-25 18:27:46 +03:00
|
|
|
}
|
2008-02-20 13:21:35 +03:00
|
|
|
}
|
|
|
|
|
2015-01-09 13:40:39 +03:00
|
|
|
static void __sta_info_recalc_tim(struct sta_info *sta, bool ignore_pending)
|
2008-02-20 13:21:35 +03:00
|
|
|
{
|
2011-09-29 18:04:27 +04:00
|
|
|
struct ieee80211_local *local = sta->local;
|
2012-10-10 23:39:50 +04:00
|
|
|
struct ps_data *ps;
|
2011-09-29 18:04:29 +04:00
|
|
|
bool indicate_tim = false;
|
|
|
|
u8 ignore_for_tim = sta->sta.uapsd_queues;
|
|
|
|
int ac;
|
2015-07-14 15:31:58 +03:00
|
|
|
u16 id = sta->sta.aid;
|
2012-10-10 23:39:50 +04:00
|
|
|
|
|
|
|
if (sta->sdata->vif.type == NL80211_IFTYPE_AP ||
|
|
|
|
sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
|
|
|
|
if (WARN_ON_ONCE(!sta->sdata->bss))
|
|
|
|
return;
|
2008-02-20 13:21:35 +03:00
|
|
|
|
2012-10-10 23:39:50 +04:00
|
|
|
ps = &sta->sdata->bss->ps;
|
2013-01-30 21:14:08 +04:00
|
|
|
#ifdef CONFIG_MAC80211_MESH
|
|
|
|
} else if (ieee80211_vif_is_mesh(&sta->sdata->vif)) {
|
|
|
|
ps = &sta->sdata->u.mesh.ps;
|
|
|
|
#endif
|
2012-10-10 23:39:50 +04:00
|
|
|
} else {
|
2011-09-29 18:04:27 +04:00
|
|
|
return;
|
2012-10-10 23:39:50 +04:00
|
|
|
}
|
mac80211: make master netdev handling sane
Currently, almost every interface type has a 'bss' pointer
pointing to BSS information. This BSS information, however,
is for a _local_ BSS, not for the BSS we joined, so having
it on a STA mode interface makes little sense, but now they
have it pointing to the master device, which is an AP mode
virtual interface. However, except for some bitrate control
data, this pointer is only used in AP/VLAN modes (for power
saving stations.)
Overall, it is not necessary to even have the master netdev
be a valid virtual interface, and it doesn't have to be on
the list of interfaces either.
This patch changes the master netdev to be special, it now
- no longer is on the list of virtual interfaces, which
lets me remove a lot of tests for that
- no longer has sub_if_data attached, since that isn't used
Additionally, this patch changes some vlan/ap mode handling
that is related to these 'bss' pointers described above (but
in the VLAN case they actually make sense because there they
point to the AP they belong to); it also adds some debugging
code to IEEE80211_DEV_TO_SUB_IF to validate it is not called
on the master netdev any more.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-07-09 16:40:34 +04:00
|
|
|
|
2011-09-29 18:04:27 +04:00
|
|
|
/* No need to do anything if the driver does all */
|
2017-02-20 16:24:36 +03:00
|
|
|
if (ieee80211_hw_check(&local->hw, AP_LINK_PS) && !local->ops->set_tim)
|
2011-09-29 18:04:27 +04:00
|
|
|
return;
|
2008-02-20 13:21:35 +03:00
|
|
|
|
2011-09-29 18:04:27 +04:00
|
|
|
if (sta->dead)
|
|
|
|
goto done;
|
mac80211: make master netdev handling sane
Currently, almost every interface type has a 'bss' pointer
pointing to BSS information. This BSS information, however,
is for a _local_ BSS, not for the BSS we joined, so having
it on a STA mode interface makes little sense, but now they
have it pointing to the master device, which is an AP mode
virtual interface. However, except for some bitrate control
data, this pointer is only used in AP/VLAN modes (for power
saving stations.)
Overall, it is not necessary to even have the master netdev
be a valid virtual interface, and it doesn't have to be on
the list of interfaces either.
This patch changes the master netdev to be special, it now
- no longer is on the list of virtual interfaces, which
lets me remove a lot of tests for that
- no longer has sub_if_data attached, since that isn't used
Additionally, this patch changes some vlan/ap mode handling
that is related to these 'bss' pointers described above (but
in the VLAN case they actually make sense because there they
point to the AP they belong to); it also adds some debugging
code to IEEE80211_DEV_TO_SUB_IF to validate it is not called
on the master netdev any more.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-07-09 16:40:34 +04:00
|
|
|
|
2011-09-29 18:04:29 +04:00
|
|
|
/*
|
|
|
|
* If all ACs are delivery-enabled then we should build
|
|
|
|
* the TIM bit for all ACs anyway; if only some are then
|
|
|
|
* we ignore those and build the TIM bit using only the
|
|
|
|
* non-enabled ones.
|
|
|
|
*/
|
|
|
|
if (ignore_for_tim == BIT(IEEE80211_NUM_ACS) - 1)
|
|
|
|
ignore_for_tim = 0;
|
|
|
|
|
2015-01-09 13:40:39 +03:00
|
|
|
if (ignore_pending)
|
|
|
|
ignore_for_tim = BIT(IEEE80211_NUM_ACS) - 1;
|
|
|
|
|
2011-09-29 18:04:29 +04:00
|
|
|
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
|
|
|
|
unsigned long tids;
|
mac80211: make master netdev handling sane
Currently, almost every interface type has a 'bss' pointer
pointing to BSS information. This BSS information, however,
is for a _local_ BSS, not for the BSS we joined, so having
it on a STA mode interface makes little sense, but now they
have it pointing to the master device, which is an AP mode
virtual interface. However, except for some bitrate control
data, this pointer is only used in AP/VLAN modes (for power
saving stations.)
Overall, it is not necessary to even have the master netdev
be a valid virtual interface, and it doesn't have to be on
the list of interfaces either.
This patch changes the master netdev to be special, it now
- no longer is on the list of virtual interfaces, which
lets me remove a lot of tests for that
- no longer has sub_if_data attached, since that isn't used
Additionally, this patch changes some vlan/ap mode handling
that is related to these 'bss' pointers described above (but
in the VLAN case they actually make sense because there they
point to the AP they belong to); it also adds some debugging
code to IEEE80211_DEV_TO_SUB_IF to validate it is not called
on the master netdev any more.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-07-09 16:40:34 +04:00
|
|
|
|
2016-10-18 23:12:12 +03:00
|
|
|
if (ignore_for_tim & ieee80211_ac_to_qos_mask[ac])
|
2011-09-29 18:04:29 +04:00
|
|
|
continue;
|
|
|
|
|
|
|
|
indicate_tim |= !skb_queue_empty(&sta->tx_filtered[ac]) ||
|
|
|
|
!skb_queue_empty(&sta->ps_tx_buf[ac]);
|
|
|
|
if (indicate_tim)
|
|
|
|
break;
|
mac80211: make master netdev handling sane
Currently, almost every interface type has a 'bss' pointer
pointing to BSS information. This BSS information, however,
is for a _local_ BSS, not for the BSS we joined, so having
it on a STA mode interface makes little sense, but now they
have it pointing to the master device, which is an AP mode
virtual interface. However, except for some bitrate control
data, this pointer is only used in AP/VLAN modes (for power
saving stations.)
Overall, it is not necessary to even have the master netdev
be a valid virtual interface, and it doesn't have to be on
the list of interfaces either.
This patch changes the master netdev to be special, it now
- no longer is on the list of virtual interfaces, which
lets me remove a lot of tests for that
- no longer has sub_if_data attached, since that isn't used
Additionally, this patch changes some vlan/ap mode handling
that is related to these 'bss' pointers described above (but
in the VLAN case they actually make sense because there they
point to the AP they belong to); it also adds some debugging
code to IEEE80211_DEV_TO_SUB_IF to validate it is not called
on the master netdev any more.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-07-09 16:40:34 +04:00
|
|
|
|
2011-09-29 18:04:29 +04:00
|
|
|
tids = ieee80211_tids_for_ac(ac);
|
|
|
|
|
|
|
|
indicate_tim |=
|
|
|
|
sta->driver_buffered_tids & tids;
|
2015-03-27 23:30:37 +03:00
|
|
|
indicate_tim |=
|
|
|
|
sta->txq_buffered_tids & tids;
|
2008-02-25 18:27:46 +03:00
|
|
|
}
|
2008-02-20 13:21:35 +03:00
|
|
|
|
2011-09-29 18:04:27 +04:00
|
|
|
done:
|
2013-02-13 20:39:53 +04:00
|
|
|
spin_lock_bh(&local->tim_lock);
|
2008-02-20 13:21:35 +03:00
|
|
|
|
2013-03-05 17:27:20 +04:00
|
|
|
if (indicate_tim == __bss_tim_get(ps->tim, id))
|
|
|
|
goto out_unlock;
|
|
|
|
|
2011-09-29 18:04:29 +04:00
|
|
|
if (indicate_tim)
|
2012-10-10 23:39:50 +04:00
|
|
|
__bss_tim_set(ps->tim, id);
|
2011-09-29 18:04:27 +04:00
|
|
|
else
|
2012-10-10 23:39:50 +04:00
|
|
|
__bss_tim_clear(ps->tim, id);
|
2008-02-20 13:21:35 +03:00
|
|
|
|
2015-01-09 13:40:39 +03:00
|
|
|
if (local->ops->set_tim && !WARN_ON(sta->dead)) {
|
2011-09-29 18:04:27 +04:00
|
|
|
local->tim_in_locked_section = true;
|
2011-09-29 18:04:29 +04:00
|
|
|
drv_set_tim(local, &sta->sta, indicate_tim);
|
2011-09-29 18:04:27 +04:00
|
|
|
local->tim_in_locked_section = false;
|
|
|
|
}
|
mac80211: make master netdev handling sane
Currently, almost every interface type has a 'bss' pointer
pointing to BSS information. This BSS information, however,
is for a _local_ BSS, not for the BSS we joined, so having
it on a STA mode interface makes little sense, but now they
have it pointing to the master device, which is an AP mode
virtual interface. However, except for some bitrate control
data, this pointer is only used in AP/VLAN modes (for power
saving stations.)
Overall, it is not necessary to even have the master netdev
be a valid virtual interface, and it doesn't have to be on
the list of interfaces either.
This patch changes the master netdev to be special, it now
- no longer is on the list of virtual interfaces, which
lets me remove a lot of tests for that
- no longer has sub_if_data attached, since that isn't used
Additionally, this patch changes some vlan/ap mode handling
that is related to these 'bss' pointers described above (but
in the VLAN case they actually make sense because there they
point to the AP they belong to); it also adds some debugging
code to IEEE80211_DEV_TO_SUB_IF to validate it is not called
on the master netdev any more.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-07-09 16:40:34 +04:00
|
|
|
|
2013-03-05 17:27:20 +04:00
|
|
|
out_unlock:
|
2013-02-13 20:39:53 +04:00
|
|
|
spin_unlock_bh(&local->tim_lock);
|
2008-02-20 13:21:35 +03:00
|
|
|
}
|
|
|
|
|
2015-01-09 13:40:39 +03:00
|
|
|
void sta_info_recalc_tim(struct sta_info *sta)
|
|
|
|
{
|
|
|
|
__sta_info_recalc_tim(sta, false);
|
|
|
|
}
|
|
|
|
|
2011-09-06 16:13:06 +04:00
|
|
|
static bool sta_info_buffer_expired(struct sta_info *sta, struct sk_buff *skb)
|
2007-05-05 22:45:53 +04:00
|
|
|
{
|
2008-05-15 14:55:29 +04:00
|
|
|
struct ieee80211_tx_info *info;
|
2007-05-05 22:45:53 +04:00
|
|
|
int timeout;
|
|
|
|
|
|
|
|
if (!skb)
|
2011-09-06 16:13:06 +04:00
|
|
|
return false;
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2008-05-15 14:55:29 +04:00
|
|
|
info = IEEE80211_SKB_CB(skb);
|
2007-05-05 22:45:53 +04:00
|
|
|
|
|
|
|
/* Timeout: (2 * listen_interval * beacon_int * 1024 / 1000000) sec */
|
2009-04-23 18:10:04 +04:00
|
|
|
timeout = (sta->listen_interval *
|
|
|
|
sta->sdata->vif.bss_conf.beacon_int *
|
|
|
|
32 / 15625) * HZ;
|
2007-05-05 22:45:53 +04:00
|
|
|
if (timeout < STA_TX_BUFFER_EXPIRE)
|
|
|
|
timeout = STA_TX_BUFFER_EXPIRE;
|
2008-05-15 14:55:29 +04:00
|
|
|
return time_after(jiffies, info->control.jiffies + timeout);
|
2007-05-05 22:45:53 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-09-29 18:04:29 +04:00
|
|
|
static bool sta_info_cleanup_expire_buffered_ac(struct ieee80211_local *local,
|
|
|
|
struct sta_info *sta, int ac)
|
2007-05-05 22:45:53 +04:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
struct sk_buff *skb;
|
|
|
|
|
2011-09-29 18:04:28 +04:00
|
|
|
/*
|
|
|
|
* First check for frames that should expire on the filtered
|
|
|
|
* queue. Frames here were rejected by the driver and are on
|
|
|
|
* a separate queue to avoid reordering with normal PS-buffered
|
|
|
|
* frames. They also aren't accounted for right now in the
|
|
|
|
* total_ps_buffered counter.
|
|
|
|
*/
|
|
|
|
for (;;) {
|
2011-09-29 18:04:29 +04:00
|
|
|
spin_lock_irqsave(&sta->tx_filtered[ac].lock, flags);
|
|
|
|
skb = skb_peek(&sta->tx_filtered[ac]);
|
2011-09-29 18:04:28 +04:00
|
|
|
if (sta_info_buffer_expired(sta, skb))
|
2011-09-29 18:04:29 +04:00
|
|
|
skb = __skb_dequeue(&sta->tx_filtered[ac]);
|
2011-09-29 18:04:28 +04:00
|
|
|
else
|
|
|
|
skb = NULL;
|
2011-09-29 18:04:29 +04:00
|
|
|
spin_unlock_irqrestore(&sta->tx_filtered[ac].lock, flags);
|
2011-09-29 18:04:28 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Frames are queued in order, so if this one
|
|
|
|
* hasn't expired yet we can stop testing. If
|
|
|
|
* we actually reached the end of the queue we
|
|
|
|
* also need to stop, of course.
|
|
|
|
*/
|
|
|
|
if (!skb)
|
|
|
|
break;
|
2012-10-11 00:40:23 +04:00
|
|
|
ieee80211_free_txskb(&local->hw, skb);
|
2011-09-29 18:04:28 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now also check the normal PS-buffered queue, this will
|
|
|
|
* only find something if the filtered queue was emptied
|
|
|
|
* since the filtered frames are all before the normal PS
|
|
|
|
* buffered frames.
|
|
|
|
*/
|
2007-05-05 22:45:53 +04:00
|
|
|
for (;;) {
|
2011-09-29 18:04:29 +04:00
|
|
|
spin_lock_irqsave(&sta->ps_tx_buf[ac].lock, flags);
|
|
|
|
skb = skb_peek(&sta->ps_tx_buf[ac]);
|
2009-04-23 18:10:04 +04:00
|
|
|
if (sta_info_buffer_expired(sta, skb))
|
2011-09-29 18:04:29 +04:00
|
|
|
skb = __skb_dequeue(&sta->ps_tx_buf[ac]);
|
2008-02-20 04:07:21 +03:00
|
|
|
else
|
2007-05-05 22:45:53 +04:00
|
|
|
skb = NULL;
|
2011-09-29 18:04:29 +04:00
|
|
|
spin_unlock_irqrestore(&sta->ps_tx_buf[ac].lock, flags);
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2011-09-29 18:04:28 +04:00
|
|
|
/*
|
|
|
|
* frames are queued in order, so if this one
|
|
|
|
* hasn't expired yet (or we reached the end of
|
|
|
|
* the queue) we can stop testing
|
|
|
|
*/
|
2008-02-20 04:07:21 +03:00
|
|
|
if (!skb)
|
2007-05-05 22:45:53 +04:00
|
|
|
break;
|
2008-02-20 04:07:21 +03:00
|
|
|
|
|
|
|
local->total_ps_buffered--;
|
2012-06-22 13:29:50 +04:00
|
|
|
ps_dbg(sta->sdata, "Buffered frame expired (STA %pM)\n",
|
|
|
|
sta->sta.addr);
|
2012-10-11 00:40:23 +04:00
|
|
|
ieee80211_free_txskb(&local->hw, skb);
|
2007-05-05 22:45:53 +04:00
|
|
|
}
|
2010-04-19 11:12:52 +04:00
|
|
|
|
2011-09-29 18:04:28 +04:00
|
|
|
/*
|
|
|
|
* Finally, recalculate the TIM bit for this station -- it might
|
|
|
|
* now be clear because the station was too slow to retrieve its
|
|
|
|
* frames.
|
|
|
|
*/
|
|
|
|
sta_info_recalc_tim(sta);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return whether there are any frames still buffered, this is
|
|
|
|
* used to check whether the cleanup timer still needs to run,
|
|
|
|
* if there are no frames we don't need to rearm the timer.
|
|
|
|
*/
|
2011-09-29 18:04:29 +04:00
|
|
|
return !(skb_queue_empty(&sta->ps_tx_buf[ac]) &&
|
|
|
|
skb_queue_empty(&sta->tx_filtered[ac]));
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool sta_info_cleanup_expire_buffered(struct ieee80211_local *local,
|
|
|
|
struct sta_info *sta)
|
|
|
|
{
|
|
|
|
bool have_buffered = false;
|
|
|
|
int ac;
|
|
|
|
|
2013-01-30 21:14:08 +04:00
|
|
|
/* This is only necessary for stations on BSS/MBSS interfaces */
|
|
|
|
if (!sta->sdata->bss &&
|
|
|
|
!ieee80211_vif_is_mesh(&sta->sdata->vif))
|
2011-09-29 18:04:29 +04:00
|
|
|
return false;
|
|
|
|
|
|
|
|
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
|
|
|
|
have_buffered |=
|
|
|
|
sta_info_cleanup_expire_buffered_ac(local, sta, ac);
|
|
|
|
|
|
|
|
return have_buffered;
|
2007-05-05 22:45:53 +04:00
|
|
|
}
|
|
|
|
|
2013-12-05 02:12:31 +04:00
|
|
|
static int __must_check __sta_info_destroy_part1(struct sta_info *sta)
|
2007-05-05 22:45:53 +04:00
|
|
|
{
|
2010-02-03 15:59:58 +03:00
|
|
|
struct ieee80211_local *local;
|
|
|
|
struct ieee80211_sub_if_data *sdata;
|
2022-07-18 23:54:27 +03:00
|
|
|
int ret, i;
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
might_sleep();
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
if (!sta)
|
|
|
|
return -ENOENT;
|
2009-05-17 13:40:42 +04:00
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
local = sta->local;
|
|
|
|
sdata = sta->sdata;
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2012-01-12 12:31:10 +04:00
|
|
|
lockdep_assert_held(&local->sta_mtx);
|
|
|
|
|
2010-04-06 13:18:47 +04:00
|
|
|
/*
|
|
|
|
* Before removing the station from the driver and
|
|
|
|
* rate control, it might still start new aggregation
|
|
|
|
* sessions -- block that to make sure the tear-down
|
|
|
|
* will be sufficient.
|
|
|
|
*/
|
2011-09-29 18:04:36 +04:00
|
|
|
set_sta_flag(sta, WLAN_STA_BLOCK_BA);
|
2012-07-18 15:31:31 +04:00
|
|
|
ieee80211_sta_tear_down_BA_sessions(sta, AGG_STOP_DESTROY_STA);
|
2010-04-06 13:18:47 +04:00
|
|
|
|
2016-03-03 00:46:14 +03:00
|
|
|
/*
|
|
|
|
* Before removing the station from the driver there might be pending
|
|
|
|
* rx frames on RSS queues sent prior to the disassociation - wait for
|
|
|
|
* all such frames to be processed.
|
|
|
|
*/
|
|
|
|
drv_sync_rx_queues(local, sta);
|
|
|
|
|
2022-07-18 23:54:27 +03:00
|
|
|
for (i = 0; i < ARRAY_SIZE(sta->link); i++) {
|
|
|
|
struct link_sta_info *link_sta;
|
|
|
|
|
|
|
|
if (!(sta->sta.valid_links & BIT(i)))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
link_sta = rcu_dereference_protected(sta->link[i],
|
|
|
|
lockdep_is_held(&local->sta_mtx));
|
|
|
|
|
|
|
|
link_sta_info_hash_del(local, link_sta);
|
|
|
|
}
|
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
ret = sta_info_hash_del(local, sta);
|
2013-12-04 23:25:27 +04:00
|
|
|
if (WARN_ON(ret))
|
2010-02-03 15:59:58 +03:00
|
|
|
return ret;
|
|
|
|
|
2014-11-09 19:50:19 +03:00
|
|
|
/*
|
|
|
|
* for TDLS peers, make sure to return to the base channel before
|
|
|
|
* removal.
|
|
|
|
*/
|
|
|
|
if (test_sta_flag(sta, WLAN_STA_TDLS_OFF_CHANNEL)) {
|
|
|
|
drv_tdls_cancel_channel_switch(local, sdata, &sta->sta);
|
|
|
|
clear_sta_flag(sta, WLAN_STA_TDLS_OFF_CHANNEL);
|
|
|
|
}
|
|
|
|
|
2012-06-04 00:32:32 +04:00
|
|
|
list_del_rcu(&sta->list);
|
2015-11-17 11:24:37 +03:00
|
|
|
sta->removed = true;
|
2011-12-15 14:24:20 +04:00
|
|
|
|
2013-12-05 01:39:17 +04:00
|
|
|
drv_sta_pre_rcu_remove(local, sta->sdata, sta);
|
|
|
|
|
2013-12-04 23:11:06 +04:00
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
|
|
|
|
rcu_access_pointer(sdata->u.vlan.sta) == sta)
|
|
|
|
RCU_INIT_POINTER(sdata->u.vlan.sta, NULL);
|
|
|
|
|
2013-12-05 02:12:31 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __sta_info_destroy_part2(struct sta_info *sta)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = sta->local;
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
2016-01-27 01:05:31 +03:00
|
|
|
struct station_info *sinfo;
|
2013-12-05 02:12:31 +04:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NOTE: This assumes at least synchronize_net() was done
|
|
|
|
* after _part1 and before _part2!
|
|
|
|
*/
|
|
|
|
|
|
|
|
might_sleep();
|
|
|
|
lockdep_assert_held(&local->sta_mtx);
|
|
|
|
|
2020-08-03 12:02:10 +03:00
|
|
|
if (sta->sta_state == IEEE80211_STA_AUTHORIZED) {
|
2020-03-26 17:51:35 +03:00
|
|
|
ret = sta_info_move_state(sta, IEEE80211_STA_ASSOC);
|
|
|
|
WARN_ON_ONCE(ret);
|
|
|
|
}
|
|
|
|
|
2013-12-05 02:05:45 +04:00
|
|
|
/* now keys can no longer be reached */
|
2013-03-07 02:09:11 +04:00
|
|
|
ieee80211_free_sta_keys(local, sta);
|
2010-02-03 15:59:58 +03:00
|
|
|
|
2015-01-09 13:40:39 +03:00
|
|
|
/* disable TIM bit - last chance to tell driver */
|
|
|
|
__sta_info_recalc_tim(sta, true);
|
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
sta->dead = true;
|
|
|
|
|
|
|
|
local->num_sta--;
|
|
|
|
local->sta_generation++;
|
|
|
|
|
2012-01-12 12:31:10 +04:00
|
|
|
while (sta->sta_state > IEEE80211_STA_NONE) {
|
2012-01-20 16:55:21 +04:00
|
|
|
ret = sta_info_move_state(sta, sta->sta_state - 1);
|
|
|
|
if (ret) {
|
2012-01-12 12:31:10 +04:00
|
|
|
WARN_ON_ONCE(1);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2011-12-14 15:35:30 +04:00
|
|
|
|
2012-01-20 16:55:21 +04:00
|
|
|
if (sta->uploaded) {
|
|
|
|
ret = drv_sta_state(local, sdata, sta, IEEE80211_STA_NONE,
|
|
|
|
IEEE80211_STA_NOTEXIST);
|
|
|
|
WARN_ON_ONCE(ret != 0);
|
|
|
|
}
|
2010-02-03 15:59:58 +03:00
|
|
|
|
2012-06-22 13:29:50 +04:00
|
|
|
sta_dbg(sdata, "Removed STA %pM\n", sta->sta.addr);
|
|
|
|
|
2016-01-27 01:05:31 +03:00
|
|
|
sinfo = kzalloc(sizeof(*sinfo), GFP_KERNEL);
|
|
|
|
if (sinfo)
|
2018-05-18 12:40:44 +03:00
|
|
|
sta_set_sinfo(sta, sinfo, true);
|
2016-01-27 01:05:31 +03:00
|
|
|
cfg80211_del_sta_sinfo(sdata->dev, sta->sta.addr, sinfo, GFP_KERNEL);
|
|
|
|
kfree(sinfo);
|
2011-03-23 16:29:52 +03:00
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
ieee80211_sta_debugfs_remove(sta);
|
|
|
|
|
2021-05-11 21:02:47 +03:00
|
|
|
ieee80211_destroy_frag_cache(&sta->frags);
|
|
|
|
|
2013-12-05 01:46:11 +04:00
|
|
|
cleanup_single_sta(sta);
|
2013-12-05 02:12:31 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
int __must_check __sta_info_destroy(struct sta_info *sta)
|
|
|
|
{
|
|
|
|
int err = __sta_info_destroy_part1(sta);
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
synchronize_net();
|
|
|
|
|
|
|
|
__sta_info_destroy_part2(sta);
|
2010-02-03 15:59:58 +03:00
|
|
|
|
|
|
|
return 0;
|
2008-04-07 23:53:49 +04:00
|
|
|
}
|
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
int sta_info_destroy_addr(struct ieee80211_sub_if_data *sdata, const u8 *addr)
|
2008-04-07 23:53:49 +04:00
|
|
|
{
|
2010-02-03 15:59:58 +03:00
|
|
|
struct sta_info *sta;
|
|
|
|
int ret;
|
2008-04-07 23:53:49 +04:00
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
mutex_lock(&sdata->local->sta_mtx);
|
2012-01-20 16:55:24 +04:00
|
|
|
sta = sta_info_get(sdata, addr);
|
2010-02-03 15:59:58 +03:00
|
|
|
ret = __sta_info_destroy(sta);
|
|
|
|
mutex_unlock(&sdata->local->sta_mtx);
|
2008-04-07 23:53:49 +04:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
int sta_info_destroy_addr_bss(struct ieee80211_sub_if_data *sdata,
|
|
|
|
const u8 *addr)
|
2007-05-05 22:46:38 +04:00
|
|
|
{
|
2010-02-03 15:59:58 +03:00
|
|
|
struct sta_info *sta;
|
|
|
|
int ret;
|
2007-05-05 22:46:38 +04:00
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
mutex_lock(&sdata->local->sta_mtx);
|
2012-01-20 16:55:24 +04:00
|
|
|
sta = sta_info_get_bss(sdata, addr);
|
2010-02-03 15:59:58 +03:00
|
|
|
ret = __sta_info_destroy(sta);
|
|
|
|
mutex_unlock(&sdata->local->sta_mtx);
|
2008-02-25 18:27:46 +03:00
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
return ret;
|
|
|
|
}
|
2007-05-05 22:46:38 +04:00
|
|
|
|
2017-10-17 02:35:49 +03:00
|
|
|
static void sta_info_cleanup(struct timer_list *t)
|
2010-02-03 15:59:58 +03:00
|
|
|
{
|
2017-10-17 02:35:49 +03:00
|
|
|
struct ieee80211_local *local = from_timer(local, t, sta_cleanup);
|
2010-02-03 15:59:58 +03:00
|
|
|
struct sta_info *sta;
|
2010-04-19 11:12:52 +04:00
|
|
|
bool timer_needed = false;
|
2010-02-03 15:59:58 +03:00
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(sta, &local->sta_list, list)
|
2010-04-19 11:12:52 +04:00
|
|
|
if (sta_info_cleanup_expire_buffered(local, sta))
|
|
|
|
timer_needed = true;
|
2010-02-03 15:59:58 +03:00
|
|
|
rcu_read_unlock();
|
2007-05-05 22:46:38 +04:00
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
if (local->quiescing)
|
|
|
|
return;
|
2008-02-25 18:27:46 +03:00
|
|
|
|
2010-04-19 11:12:52 +04:00
|
|
|
if (!timer_needed)
|
|
|
|
return;
|
|
|
|
|
2011-04-01 15:52:48 +04:00
|
|
|
mod_timer(&local->sta_cleanup,
|
|
|
|
round_jiffies(jiffies + STA_INFO_CLEANUP_INTERVAL));
|
2007-05-05 22:46:38 +04:00
|
|
|
}
|
|
|
|
|
2015-02-13 23:55:15 +03:00
|
|
|
int sta_info_init(struct ieee80211_local *local)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2016-09-19 14:00:10 +03:00
|
|
|
err = rhltable_init(&local->sta_hash, &sta_rht_params);
|
2015-02-13 23:55:15 +03:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2022-06-14 14:07:42 +03:00
|
|
|
err = rhltable_init(&local->link_sta_hash, &link_sta_rht_params);
|
|
|
|
if (err) {
|
|
|
|
rhltable_destroy(&local->sta_hash);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2011-12-15 14:24:20 +04:00
|
|
|
spin_lock_init(&local->tim_lock);
|
2010-02-03 15:59:58 +03:00
|
|
|
mutex_init(&local->sta_mtx);
|
2007-05-05 22:45:53 +04:00
|
|
|
INIT_LIST_HEAD(&local->sta_list);
|
|
|
|
|
2017-10-17 02:35:49 +03:00
|
|
|
timer_setup(&local->sta_cleanup, sta_info_cleanup, 0);
|
2015-02-13 23:55:15 +03:00
|
|
|
return 0;
|
2007-05-05 22:45:53 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void sta_info_stop(struct ieee80211_local *local)
|
|
|
|
{
|
2012-12-14 02:08:52 +04:00
|
|
|
del_timer_sync(&local->sta_cleanup);
|
2016-09-19 14:00:10 +03:00
|
|
|
rhltable_destroy(&local->sta_hash);
|
2022-06-14 14:07:42 +03:00
|
|
|
rhltable_destroy(&local->link_sta_hash);
|
2007-05-05 22:45:53 +04:00
|
|
|
}
|
|
|
|
|
2012-12-14 02:49:02 +04:00
|
|
|
|
2013-12-05 02:18:37 +04:00
|
|
|
int __sta_info_flush(struct ieee80211_sub_if_data *sdata, bool vlans)
|
2007-05-05 22:45:53 +04:00
|
|
|
{
|
2012-12-14 02:07:46 +04:00
|
|
|
struct ieee80211_local *local = sdata->local;
|
2007-05-05 22:45:53 +04:00
|
|
|
struct sta_info *sta, *tmp;
|
2013-12-05 02:12:31 +04:00
|
|
|
LIST_HEAD(free_list);
|
2008-02-25 18:27:49 +03:00
|
|
|
int ret = 0;
|
2007-05-05 22:45:53 +04:00
|
|
|
|
2008-02-25 18:27:46 +03:00
|
|
|
might_sleep();
|
2007-07-27 17:43:23 +04:00
|
|
|
|
2013-12-05 02:18:37 +04:00
|
|
|
WARN_ON(vlans && sdata->vif.type != NL80211_IFTYPE_AP);
|
|
|
|
WARN_ON(vlans && !sdata->bss);
|
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
mutex_lock(&local->sta_mtx);
|
2008-02-25 18:27:46 +03:00
|
|
|
list_for_each_entry_safe(sta, tmp, &local->sta_list, list) {
|
2013-12-05 02:18:37 +04:00
|
|
|
if (sdata == sta->sdata ||
|
|
|
|
(vlans && sdata->bss == sta->sdata->bss)) {
|
2013-12-05 02:12:31 +04:00
|
|
|
if (!WARN_ON(__sta_info_destroy_part1(sta)))
|
|
|
|
list_add(&sta->free_list, &free_list);
|
2012-02-26 00:40:46 +04:00
|
|
|
ret++;
|
|
|
|
}
|
2007-07-27 17:43:23 +04:00
|
|
|
}
|
2013-12-05 02:12:31 +04:00
|
|
|
|
|
|
|
if (!list_empty(&free_list)) {
|
|
|
|
synchronize_net();
|
|
|
|
list_for_each_entry_safe(sta, tmp, &free_list, free_list)
|
|
|
|
__sta_info_destroy_part2(sta);
|
|
|
|
}
|
2010-02-03 15:59:58 +03:00
|
|
|
mutex_unlock(&local->sta_mtx);
|
2008-02-25 18:27:49 +03:00
|
|
|
|
2012-12-14 02:49:02 +04:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2008-09-11 02:01:46 +04:00
|
|
|
void ieee80211_sta_expire(struct ieee80211_sub_if_data *sdata,
|
|
|
|
unsigned long exp_time)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
struct sta_info *sta, *tmp;
|
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
mutex_lock(&local->sta_mtx);
|
2011-12-26 09:13:29 +04:00
|
|
|
|
|
|
|
list_for_each_entry_safe(sta, tmp, &local->sta_list, list) {
|
2016-03-31 20:02:07 +03:00
|
|
|
unsigned long last_active = ieee80211_sta_last_active(sta);
|
|
|
|
|
2011-12-20 19:16:52 +04:00
|
|
|
if (sdata != sta->sdata)
|
|
|
|
continue;
|
|
|
|
|
2016-03-31 20:02:07 +03:00
|
|
|
if (time_is_before_jiffies(last_active + exp_time)) {
|
2012-10-08 20:03:47 +04:00
|
|
|
sta_dbg(sta->sdata, "expiring inactive STA %pM\n",
|
|
|
|
sta->sta.addr);
|
2013-01-30 21:14:08 +04:00
|
|
|
|
|
|
|
if (ieee80211_vif_is_mesh(&sdata->vif) &&
|
|
|
|
test_sta_flag(sta, WLAN_STA_PS_STA))
|
|
|
|
atomic_dec(&sdata->u.mesh.ps.num_sta_ps);
|
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
WARN_ON(__sta_info_destroy(sta));
|
2008-09-11 02:01:46 +04:00
|
|
|
}
|
2011-12-26 09:13:29 +04:00
|
|
|
}
|
|
|
|
|
2010-02-03 15:59:58 +03:00
|
|
|
mutex_unlock(&local->sta_mtx);
|
2008-09-11 02:01:46 +04:00
|
|
|
}
|
2008-09-11 02:02:02 +04:00
|
|
|
|
2010-09-23 20:44:36 +04:00
|
|
|
struct ieee80211_sta *ieee80211_find_sta_by_ifaddr(struct ieee80211_hw *hw,
|
2015-02-13 23:55:15 +03:00
|
|
|
const u8 *addr,
|
|
|
|
const u8 *localaddr)
|
2008-09-11 02:02:02 +04:00
|
|
|
{
|
2015-02-13 23:55:15 +03:00
|
|
|
struct ieee80211_local *local = hw_to_local(hw);
|
2016-09-19 14:00:10 +03:00
|
|
|
struct rhlist_head *tmp;
|
2015-02-13 23:55:15 +03:00
|
|
|
struct sta_info *sta;
|
2008-09-11 02:02:02 +04:00
|
|
|
|
2010-09-23 20:44:36 +04:00
|
|
|
/*
|
|
|
|
* Just return a random station if localaddr is NULL
|
|
|
|
* ... first in list.
|
|
|
|
*/
|
2016-09-19 14:00:10 +03:00
|
|
|
for_each_sta_info(local, addr, sta, tmp) {
|
2010-09-23 20:44:36 +04:00
|
|
|
if (localaddr &&
|
mac80211: Convert compare_ether_addr to ether_addr_equal
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script:
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a, b)
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- compare_ether_addr(a, b)
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) == 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) != 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !!ether_addr_equal(a, b)
+ ether_addr_equal(a, b)
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-08 22:56:52 +04:00
|
|
|
!ether_addr_equal(sta->sdata->vif.addr, localaddr))
|
2010-09-23 20:44:36 +04:00
|
|
|
continue;
|
2010-04-30 15:48:36 +04:00
|
|
|
if (!sta->uploaded)
|
|
|
|
return NULL;
|
2009-11-25 19:46:18 +03:00
|
|
|
return &sta->sta;
|
2010-04-30 15:48:36 +04:00
|
|
|
}
|
|
|
|
|
2009-11-25 19:46:18 +03:00
|
|
|
return NULL;
|
2008-09-11 02:02:02 +04:00
|
|
|
}
|
2010-09-23 20:44:36 +04:00
|
|
|
EXPORT_SYMBOL_GPL(ieee80211_find_sta_by_ifaddr);
|
2009-11-04 16:42:28 +03:00
|
|
|
|
|
|
|
struct ieee80211_sta *ieee80211_find_sta(struct ieee80211_vif *vif,
|
|
|
|
const u8 *addr)
|
|
|
|
{
|
2010-04-30 15:48:36 +04:00
|
|
|
struct sta_info *sta;
|
2009-11-04 16:42:28 +03:00
|
|
|
|
|
|
|
if (!vif)
|
|
|
|
return NULL;
|
|
|
|
|
2010-04-30 15:48:36 +04:00
|
|
|
sta = sta_info_get_bss(vif_to_sdata(vif), addr);
|
|
|
|
if (!sta)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (!sta->uploaded)
|
|
|
|
return NULL;
|
2009-11-04 16:42:28 +03:00
|
|
|
|
2010-04-30 15:48:36 +04:00
|
|
|
return &sta->sta;
|
2009-11-04 16:42:28 +03:00
|
|
|
}
|
2008-09-11 02:02:02 +04:00
|
|
|
EXPORT_SYMBOL(ieee80211_find_sta);
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
2014-02-20 14:19:58 +04:00
|
|
|
/* powersave support code */
|
|
|
|
void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta)
|
2010-11-16 22:50:28 +03:00
|
|
|
{
|
2012-01-30 18:18:00 +04:00
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
2014-02-20 14:19:58 +04:00
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
struct sk_buff_head pending;
|
2015-03-27 23:30:37 +03:00
|
|
|
int filtered = 0, buffered = 0, ac, i;
|
2014-02-20 14:19:58 +04:00
|
|
|
unsigned long flags;
|
2012-10-10 23:39:50 +04:00
|
|
|
struct ps_data *ps;
|
|
|
|
|
2014-07-25 18:20:23 +04:00
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
|
|
|
|
sdata = container_of(sdata->bss, struct ieee80211_sub_if_data,
|
|
|
|
u.ap);
|
|
|
|
|
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_AP)
|
2012-10-10 23:39:50 +04:00
|
|
|
ps = &sdata->bss->ps;
|
2013-01-30 21:14:08 +04:00
|
|
|
else if (ieee80211_vif_is_mesh(&sdata->vif))
|
|
|
|
ps = &sdata->u.mesh.ps;
|
2012-10-10 23:39:50 +04:00
|
|
|
else
|
|
|
|
return;
|
2010-11-16 22:50:28 +03:00
|
|
|
|
2011-09-29 18:04:36 +04:00
|
|
|
clear_sta_flag(sta, WLAN_STA_SP);
|
2011-09-29 18:04:33 +04:00
|
|
|
|
2012-11-15 02:22:21 +04:00
|
|
|
BUILD_BUG_ON(BITS_TO_LONGS(IEEE80211_NUM_TIDS) > 1);
|
2011-09-29 18:04:29 +04:00
|
|
|
sta->driver_buffered_tids = 0;
|
2015-03-27 23:30:37 +03:00
|
|
|
sta->txq_buffered_tids = 0;
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
2015-06-02 22:39:54 +03:00
|
|
|
if (!ieee80211_hw_check(&local->hw, AP_LINK_PS))
|
2011-01-31 23:29:13 +03:00
|
|
|
drv_sta_notify(local, sdata, STA_NOTIFY_AWAKE, &sta->sta);
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
for (i = 0; i < ARRAY_SIZE(sta->sta.txq); i++) {
|
|
|
|
if (!sta->sta.txq[i] || !txq_has_queue(sta->sta.txq[i]))
|
|
|
|
continue;
|
2015-03-27 23:30:37 +03:00
|
|
|
|
2018-12-19 04:02:06 +03:00
|
|
|
schedule_and_wake_txq(local, to_txq_info(sta->sta.txq[i]));
|
2015-03-27 23:30:37 +03:00
|
|
|
}
|
|
|
|
|
2011-09-29 18:04:29 +04:00
|
|
|
skb_queue_head_init(&pending);
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
mac80211: fix AP powersave TX vs. wakeup race
There is a race between the TX path and the STA wakeup: while
a station is sleeping, mac80211 buffers frames until it wakes
up, then the frames are transmitted. However, the RX and TX
path are concurrent, so the packet indicating wakeup can be
processed while a packet is being transmitted.
This can lead to a situation where the buffered frames list
is emptied on the one side, while a frame is being added on
the other side, as the station is still seen as sleeping in
the TX path.
As a result, the newly added frame will not be send anytime
soon. It might be sent much later (and out of order) when the
station goes to sleep and wakes up the next time.
Additionally, it can lead to the crash below.
Fix all this by synchronising both paths with a new lock.
Both path are not fastpath since they handle PS situations.
In a later patch we'll remove the extra skb queue locks to
reduce locking overhead.
BUG: unable to handle kernel
NULL pointer dereference at 000000b0
IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
*pde = 00000000
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
Stack:
e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
Call Trace:
[<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
[<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
[<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
[<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
[<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
[<c149ef70>] dev_hard_start_xmit+0x450/0x950
[<c14b9aa9>] sch_direct_xmit+0xa9/0x250
[<c14b9c9b>] __qdisc_run+0x4b/0x150
[<c149f732>] dev_queue_xmit+0x2c2/0xca0
Cc: stable@vger.kernel.org
Reported-by: Yaara Rozenblum <yaara.rozenblum@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
[reword commit log, use a separate lock]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-02-20 11:22:11 +04:00
|
|
|
/* sync with ieee80211_tx_h_unicast_ps_buf */
|
|
|
|
spin_lock(&sta->ps_lock);
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
/* Send all buffered frames to the station */
|
2011-09-29 18:04:29 +04:00
|
|
|
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
|
|
|
|
int count = skb_queue_len(&pending), tmp;
|
|
|
|
|
2012-11-05 12:27:52 +04:00
|
|
|
spin_lock_irqsave(&sta->tx_filtered[ac].lock, flags);
|
2011-09-29 18:04:29 +04:00
|
|
|
skb_queue_splice_tail_init(&sta->tx_filtered[ac], &pending);
|
2012-11-05 12:27:52 +04:00
|
|
|
spin_unlock_irqrestore(&sta->tx_filtered[ac].lock, flags);
|
2011-09-29 18:04:29 +04:00
|
|
|
tmp = skb_queue_len(&pending);
|
|
|
|
filtered += tmp - count;
|
|
|
|
count = tmp;
|
|
|
|
|
2012-11-05 12:27:52 +04:00
|
|
|
spin_lock_irqsave(&sta->ps_tx_buf[ac].lock, flags);
|
2011-09-29 18:04:29 +04:00
|
|
|
skb_queue_splice_tail_init(&sta->ps_tx_buf[ac], &pending);
|
2012-11-05 12:27:52 +04:00
|
|
|
spin_unlock_irqrestore(&sta->ps_tx_buf[ac].lock, flags);
|
2011-09-29 18:04:29 +04:00
|
|
|
tmp = skb_queue_len(&pending);
|
|
|
|
buffered += tmp - count;
|
|
|
|
}
|
|
|
|
|
2014-02-20 14:19:58 +04:00
|
|
|
ieee80211_add_pending_skbs(local, &pending);
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
|
|
|
|
/* now we're no longer in the deliver code */
|
|
|
|
clear_sta_flag(sta, WLAN_STA_PS_DELIVER);
|
|
|
|
|
|
|
|
/* The station might have polled and then woken up before we responded,
|
|
|
|
* so clear these flags now to avoid them sticking around.
|
|
|
|
*/
|
|
|
|
clear_sta_flag(sta, WLAN_STA_PSPOLL);
|
|
|
|
clear_sta_flag(sta, WLAN_STA_UAPSD);
|
mac80211: fix AP powersave TX vs. wakeup race
There is a race between the TX path and the STA wakeup: while
a station is sleeping, mac80211 buffers frames until it wakes
up, then the frames are transmitted. However, the RX and TX
path are concurrent, so the packet indicating wakeup can be
processed while a packet is being transmitted.
This can lead to a situation where the buffered frames list
is emptied on the one side, while a frame is being added on
the other side, as the station is still seen as sleeping in
the TX path.
As a result, the newly added frame will not be send anytime
soon. It might be sent much later (and out of order) when the
station goes to sleep and wakes up the next time.
Additionally, it can lead to the crash below.
Fix all this by synchronising both paths with a new lock.
Both path are not fastpath since they handle PS situations.
In a later patch we'll remove the extra skb queue locks to
reduce locking overhead.
BUG: unable to handle kernel
NULL pointer dereference at 000000b0
IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
*pde = 00000000
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
Stack:
e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
Call Trace:
[<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
[<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
[<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
[<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
[<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
[<c149ef70>] dev_hard_start_xmit+0x450/0x950
[<c14b9aa9>] sch_direct_xmit+0xa9/0x250
[<c14b9c9b>] __qdisc_run+0x4b/0x150
[<c149f732>] dev_queue_xmit+0x2c2/0xca0
Cc: stable@vger.kernel.org
Reported-by: Yaara Rozenblum <yaara.rozenblum@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
[reword commit log, use a separate lock]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-02-20 11:22:11 +04:00
|
|
|
spin_unlock(&sta->ps_lock);
|
2011-09-29 18:04:29 +04:00
|
|
|
|
2014-02-20 14:19:58 +04:00
|
|
|
atomic_dec(&ps->num_sta_ps);
|
|
|
|
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
local->total_ps_buffered -= buffered;
|
|
|
|
|
2011-09-29 18:04:27 +04:00
|
|
|
sta_info_recalc_tim(sta);
|
|
|
|
|
2012-06-22 13:29:50 +04:00
|
|
|
ps_dbg(sdata,
|
2017-02-20 16:24:39 +03:00
|
|
|
"STA %pM aid %d sending %d filtered/%d PS frames since STA woke up\n",
|
2012-06-22 13:29:50 +04:00
|
|
|
sta->sta.addr, sta->sta.aid, filtered, buffered);
|
2015-03-21 17:25:43 +03:00
|
|
|
|
|
|
|
ieee80211_check_fast_xmit(sta);
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
}
|
|
|
|
|
2015-11-17 11:24:36 +03:00
|
|
|
static void ieee80211_send_null_response(struct sta_info *sta, int tid,
|
2014-01-09 03:00:38 +04:00
|
|
|
enum ieee80211_frame_release_type reason,
|
2015-11-17 11:24:36 +03:00
|
|
|
bool call_driver, bool more_data)
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
{
|
2015-11-17 11:24:36 +03:00
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
struct ieee80211_local *local = sdata->local;
|
2011-09-29 18:04:34 +04:00
|
|
|
struct ieee80211_qos_hdr *nullfunc;
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
struct sk_buff *skb;
|
2011-09-29 18:04:34 +04:00
|
|
|
int size = sizeof(*nullfunc);
|
|
|
|
__le16 fc;
|
2014-07-22 16:50:47 +04:00
|
|
|
bool qos = sta->sta.wme;
|
2011-09-29 18:04:34 +04:00
|
|
|
struct ieee80211_tx_info *info;
|
2012-07-26 19:24:39 +04:00
|
|
|
struct ieee80211_chanctx_conf *chanctx_conf;
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
2011-09-29 18:04:34 +04:00
|
|
|
if (qos) {
|
|
|
|
fc = cpu_to_le16(IEEE80211_FTYPE_DATA |
|
|
|
|
IEEE80211_STYPE_QOS_NULLFUNC |
|
|
|
|
IEEE80211_FCTL_FROMDS);
|
|
|
|
} else {
|
|
|
|
size -= 2;
|
|
|
|
fc = cpu_to_le16(IEEE80211_FTYPE_DATA |
|
|
|
|
IEEE80211_STYPE_NULLFUNC |
|
|
|
|
IEEE80211_FCTL_FROMDS);
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
}
|
|
|
|
|
2011-09-29 18:04:34 +04:00
|
|
|
skb = dev_alloc_skb(local->hw.extra_tx_headroom + size);
|
|
|
|
if (!skb)
|
|
|
|
return;
|
|
|
|
|
|
|
|
skb_reserve(skb, local->hw.extra_tx_headroom);
|
|
|
|
|
networking: make skb_put & friends return void pointers
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions (skb_put, __skb_put and pskb_put) return void *
and remove all the casts across the tree, adding a (u8 *) cast only
where the unsigned char pointer was used directly, all done with the
following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_put, __skb_put };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_put, __skb_put };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
which actually doesn't cover pskb_put since there are only three
users overall.
A handful of stragglers were converted manually, notably a macro in
drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many
instances in net/bluetooth/hci_sock.c. In the former file, I also
had to fix one whitespace problem spatch introduced.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 15:29:21 +03:00
|
|
|
nullfunc = skb_put(skb, size);
|
2011-09-29 18:04:34 +04:00
|
|
|
nullfunc->frame_control = fc;
|
|
|
|
nullfunc->duration_id = 0;
|
|
|
|
memcpy(nullfunc->addr1, sta->sta.addr, ETH_ALEN);
|
|
|
|
memcpy(nullfunc->addr2, sdata->vif.addr, ETH_ALEN);
|
|
|
|
memcpy(nullfunc->addr3, sdata->vif.addr, ETH_ALEN);
|
2014-03-04 16:46:53 +04:00
|
|
|
nullfunc->seq_ctrl = 0;
|
2011-09-29 18:04:34 +04:00
|
|
|
|
2011-10-13 15:19:19 +04:00
|
|
|
skb->priority = tid;
|
|
|
|
skb_set_queue_mapping(skb, ieee802_1d_to_ac[tid]);
|
2011-09-29 18:04:34 +04:00
|
|
|
if (qos) {
|
|
|
|
nullfunc->qos_ctrl = cpu_to_le16(tid);
|
|
|
|
|
2015-11-17 11:24:36 +03:00
|
|
|
if (reason == IEEE80211_FRAME_RELEASE_UAPSD) {
|
2011-09-29 18:04:34 +04:00
|
|
|
nullfunc->qos_ctrl |=
|
|
|
|
cpu_to_le16(IEEE80211_QOS_CTL_EOSP);
|
2015-11-17 11:24:36 +03:00
|
|
|
if (more_data)
|
|
|
|
nullfunc->frame_control |=
|
|
|
|
cpu_to_le16(IEEE80211_FCTL_MOREDATA);
|
|
|
|
}
|
2011-09-29 18:04:34 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
info = IEEE80211_SKB_CB(skb);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Tell TX path to send this frame even though the
|
|
|
|
* STA may still remain is PS mode after this frame
|
2011-09-29 18:04:35 +04:00
|
|
|
* exchange. Also set EOSP to indicate this packet
|
|
|
|
* ends the poll/service period.
|
2011-09-29 18:04:34 +04:00
|
|
|
*/
|
2012-02-27 15:18:30 +04:00
|
|
|
info->flags |= IEEE80211_TX_CTL_NO_PS_BUFFER |
|
2011-09-29 18:04:35 +04:00
|
|
|
IEEE80211_TX_STATUS_EOSP |
|
|
|
|
IEEE80211_TX_CTL_REQ_TX_STATUS;
|
2011-09-29 18:04:34 +04:00
|
|
|
|
2014-12-10 18:56:10 +03:00
|
|
|
info->control.flags |= IEEE80211_TX_CTRL_PS_RESPONSE;
|
|
|
|
|
2014-01-09 03:00:38 +04:00
|
|
|
if (call_driver)
|
|
|
|
drv_allow_buffered_frames(local, sta, BIT(tid), 1,
|
|
|
|
reason, false);
|
2011-09-29 18:04:38 +04:00
|
|
|
|
2013-02-13 18:39:57 +04:00
|
|
|
skb->dev = sdata->dev;
|
|
|
|
|
2012-07-26 19:24:39 +04:00
|
|
|
rcu_read_lock();
|
wifi: mac80211: move some future per-link data to bss_conf
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 14:26:44 +03:00
|
|
|
chanctx_conf = rcu_dereference(sdata->vif.bss_conf.chanctx_conf);
|
2012-07-26 19:24:39 +04:00
|
|
|
if (WARN_ON(!chanctx_conf)) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
kfree_skb(skb);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-11-09 19:50:09 +03:00
|
|
|
info->band = chanctx_conf->def.chan->band;
|
2020-07-23 13:01:52 +03:00
|
|
|
ieee80211_xmit(sdata, sta, skb);
|
2012-07-26 19:24:39 +04:00
|
|
|
rcu_read_unlock();
|
2011-09-29 18:04:34 +04:00
|
|
|
}
|
|
|
|
|
2014-01-09 14:05:31 +04:00
|
|
|
static int find_highest_prio_tid(unsigned long tids)
|
|
|
|
{
|
|
|
|
/* lower 3 TIDs aren't ordered perfectly */
|
|
|
|
if (tids & 0xF8)
|
|
|
|
return fls(tids) - 1;
|
|
|
|
/* TID 0 is BE just like TID 3 */
|
|
|
|
if (tids & BIT(0))
|
|
|
|
return 0;
|
|
|
|
return fls(tids) - 1;
|
|
|
|
}
|
|
|
|
|
2015-11-17 11:24:36 +03:00
|
|
|
/* Indicates if the MORE_DATA bit should be set in the last
|
|
|
|
* frame obtained by ieee80211_sta_ps_get_frames.
|
|
|
|
* Note that driver_release_tids is relevant only if
|
|
|
|
* reason = IEEE80211_FRAME_RELEASE_PSPOLL
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
ieee80211_sta_ps_more_data(struct sta_info *sta, u8 ignored_acs,
|
|
|
|
enum ieee80211_frame_release_type reason,
|
|
|
|
unsigned long driver_release_tids)
|
|
|
|
{
|
|
|
|
int ac;
|
|
|
|
|
|
|
|
/* If the driver has data on more than one TID then
|
|
|
|
* certainly there's more data if we release just a
|
|
|
|
* single frame now (from a single TID). This will
|
|
|
|
* only happen for PS-Poll.
|
|
|
|
*/
|
|
|
|
if (reason == IEEE80211_FRAME_RELEASE_PSPOLL &&
|
|
|
|
hweight16(driver_release_tids) > 1)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
|
2016-10-18 23:12:12 +03:00
|
|
|
if (ignored_acs & ieee80211_ac_to_qos_mask[ac])
|
2015-11-17 11:24:36 +03:00
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!skb_queue_empty(&sta->tx_filtered[ac]) ||
|
|
|
|
!skb_queue_empty(&sta->ps_tx_buf[ac]))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2011-09-29 18:04:33 +04:00
|
|
|
static void
|
2015-11-17 11:24:36 +03:00
|
|
|
ieee80211_sta_ps_get_frames(struct sta_info *sta, int n_frames, u8 ignored_acs,
|
|
|
|
enum ieee80211_frame_release_type reason,
|
|
|
|
struct sk_buff_head *frames,
|
|
|
|
unsigned long *driver_release_tids)
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
2011-09-29 18:04:29 +04:00
|
|
|
int ac;
|
|
|
|
|
mac80211: release multiple ACs in uAPSD, fix more-data bug
When a response for PS-Poll or a uAPSD trigger frame is sent, the
more-data bit should be set according to 802.11-2012 11.2.1.5 h),
meaning that it should indicate more data on the relevant ACs
(delivery-enabled or nondelivery-enabled for uAPSD or PS-Poll.)
In, for example, the following scenario:
* 1 frame on VO queue (either in driver or in mac80211)
* at least 1 frame on VI queue (in the driver)
* both VO/VI are delivery-enabled
* uAPSD trigger frame received
The more-data flag to the driver would not be set, even though
it should be.
While fixing this, I noticed that we should really release frames
from multiple ACs where there's data buffered in the driver for
the corresponding TIDs.
To address all this, restructure the code a bit to consider all
ACs if we only release driver frames or only buffered frames.
This also addresses the more-data bug described above as now the
TIDs will all be marked as released, so the driver will have to
check the number of frames.
While at it, clarify some code and comments and remove the found
variable, replacing it with the appropriate sw/hw release check.
Reported-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-08 20:45:07 +04:00
|
|
|
/* Get response frame(s) and more data bit for the last one. */
|
2011-09-29 18:04:29 +04:00
|
|
|
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
|
2011-09-29 18:04:32 +04:00
|
|
|
unsigned long tids;
|
|
|
|
|
2016-10-18 23:12:12 +03:00
|
|
|
if (ignored_acs & ieee80211_ac_to_qos_mask[ac])
|
2011-09-29 18:04:29 +04:00
|
|
|
continue;
|
|
|
|
|
2011-09-29 18:04:32 +04:00
|
|
|
tids = ieee80211_tids_for_ac(ac);
|
|
|
|
|
mac80211: release multiple ACs in uAPSD, fix more-data bug
When a response for PS-Poll or a uAPSD trigger frame is sent, the
more-data bit should be set according to 802.11-2012 11.2.1.5 h),
meaning that it should indicate more data on the relevant ACs
(delivery-enabled or nondelivery-enabled for uAPSD or PS-Poll.)
In, for example, the following scenario:
* 1 frame on VO queue (either in driver or in mac80211)
* at least 1 frame on VI queue (in the driver)
* both VO/VI are delivery-enabled
* uAPSD trigger frame received
The more-data flag to the driver would not be set, even though
it should be.
While fixing this, I noticed that we should really release frames
from multiple ACs where there's data buffered in the driver for
the corresponding TIDs.
To address all this, restructure the code a bit to consider all
ACs if we only release driver frames or only buffered frames.
This also addresses the more-data bug described above as now the
TIDs will all be marked as released, so the driver will have to
check the number of frames.
While at it, clarify some code and comments and remove the found
variable, replacing it with the appropriate sw/hw release check.
Reported-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-08 20:45:07 +04:00
|
|
|
/* if we already have frames from software, then we can't also
|
|
|
|
* release from hardware queues
|
|
|
|
*/
|
2015-11-17 11:24:36 +03:00
|
|
|
if (skb_queue_empty(frames)) {
|
|
|
|
*driver_release_tids |=
|
|
|
|
sta->driver_buffered_tids & tids;
|
|
|
|
*driver_release_tids |= sta->txq_buffered_tids & tids;
|
2015-03-27 23:30:37 +03:00
|
|
|
}
|
2011-09-29 18:04:29 +04:00
|
|
|
|
2015-11-17 11:24:36 +03:00
|
|
|
if (!*driver_release_tids) {
|
mac80211: release multiple ACs in uAPSD, fix more-data bug
When a response for PS-Poll or a uAPSD trigger frame is sent, the
more-data bit should be set according to 802.11-2012 11.2.1.5 h),
meaning that it should indicate more data on the relevant ACs
(delivery-enabled or nondelivery-enabled for uAPSD or PS-Poll.)
In, for example, the following scenario:
* 1 frame on VO queue (either in driver or in mac80211)
* at least 1 frame on VI queue (in the driver)
* both VO/VI are delivery-enabled
* uAPSD trigger frame received
The more-data flag to the driver would not be set, even though
it should be.
While fixing this, I noticed that we should really release frames
from multiple ACs where there's data buffered in the driver for
the corresponding TIDs.
To address all this, restructure the code a bit to consider all
ACs if we only release driver frames or only buffered frames.
This also addresses the more-data bug described above as now the
TIDs will all be marked as released, so the driver will have to
check the number of frames.
While at it, clarify some code and comments and remove the found
variable, replacing it with the appropriate sw/hw release check.
Reported-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-08 20:45:07 +04:00
|
|
|
struct sk_buff *skb;
|
|
|
|
|
|
|
|
while (n_frames > 0) {
|
|
|
|
skb = skb_dequeue(&sta->tx_filtered[ac]);
|
|
|
|
if (!skb) {
|
|
|
|
skb = skb_dequeue(
|
|
|
|
&sta->ps_tx_buf[ac]);
|
|
|
|
if (skb)
|
|
|
|
local->total_ps_buffered--;
|
|
|
|
}
|
|
|
|
if (!skb)
|
|
|
|
break;
|
|
|
|
n_frames--;
|
2015-11-17 11:24:36 +03:00
|
|
|
__skb_queue_tail(frames, skb);
|
mac80211: release multiple ACs in uAPSD, fix more-data bug
When a response for PS-Poll or a uAPSD trigger frame is sent, the
more-data bit should be set according to 802.11-2012 11.2.1.5 h),
meaning that it should indicate more data on the relevant ACs
(delivery-enabled or nondelivery-enabled for uAPSD or PS-Poll.)
In, for example, the following scenario:
* 1 frame on VO queue (either in driver or in mac80211)
* at least 1 frame on VI queue (in the driver)
* both VO/VI are delivery-enabled
* uAPSD trigger frame received
The more-data flag to the driver would not be set, even though
it should be.
While fixing this, I noticed that we should really release frames
from multiple ACs where there's data buffered in the driver for
the corresponding TIDs.
To address all this, restructure the code a bit to consider all
ACs if we only release driver frames or only buffered frames.
This also addresses the more-data bug described above as now the
TIDs will all be marked as released, so the driver will have to
check the number of frames.
While at it, clarify some code and comments and remove the found
variable, replacing it with the appropriate sw/hw release check.
Reported-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-08 20:45:07 +04:00
|
|
|
}
|
2011-09-29 18:04:32 +04:00
|
|
|
}
|
2011-09-29 18:04:29 +04:00
|
|
|
|
2015-11-17 11:24:36 +03:00
|
|
|
/* If we have more frames buffered on this AC, then abort the
|
|
|
|
* loop since we can't send more data from other ACs before
|
|
|
|
* the buffered frames from this.
|
mac80211: release multiple ACs in uAPSD, fix more-data bug
When a response for PS-Poll or a uAPSD trigger frame is sent, the
more-data bit should be set according to 802.11-2012 11.2.1.5 h),
meaning that it should indicate more data on the relevant ACs
(delivery-enabled or nondelivery-enabled for uAPSD or PS-Poll.)
In, for example, the following scenario:
* 1 frame on VO queue (either in driver or in mac80211)
* at least 1 frame on VI queue (in the driver)
* both VO/VI are delivery-enabled
* uAPSD trigger frame received
The more-data flag to the driver would not be set, even though
it should be.
While fixing this, I noticed that we should really release frames
from multiple ACs where there's data buffered in the driver for
the corresponding TIDs.
To address all this, restructure the code a bit to consider all
ACs if we only release driver frames or only buffered frames.
This also addresses the more-data bug described above as now the
TIDs will all be marked as released, so the driver will have to
check the number of frames.
While at it, clarify some code and comments and remove the found
variable, replacing it with the appropriate sw/hw release check.
Reported-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-08 20:45:07 +04:00
|
|
|
*/
|
2011-09-29 18:04:29 +04:00
|
|
|
if (!skb_queue_empty(&sta->tx_filtered[ac]) ||
|
2015-11-17 11:24:36 +03:00
|
|
|
!skb_queue_empty(&sta->ps_tx_buf[ac]))
|
2011-09-29 18:04:29 +04:00
|
|
|
break;
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
}
|
2015-11-17 11:24:36 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
ieee80211_sta_ps_deliver_response(struct sta_info *sta,
|
|
|
|
int n_frames, u8 ignored_acs,
|
|
|
|
enum ieee80211_frame_release_type reason)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
unsigned long driver_release_tids = 0;
|
|
|
|
struct sk_buff_head frames;
|
|
|
|
bool more_data;
|
|
|
|
|
|
|
|
/* Service or PS-Poll period starts */
|
|
|
|
set_sta_flag(sta, WLAN_STA_SP);
|
|
|
|
|
|
|
|
__skb_queue_head_init(&frames);
|
|
|
|
|
|
|
|
ieee80211_sta_ps_get_frames(sta, n_frames, ignored_acs, reason,
|
|
|
|
&frames, &driver_release_tids);
|
|
|
|
|
|
|
|
more_data = ieee80211_sta_ps_more_data(sta, ignored_acs, reason, driver_release_tids);
|
|
|
|
|
2015-12-20 14:50:00 +03:00
|
|
|
if (driver_release_tids && reason == IEEE80211_FRAME_RELEASE_PSPOLL)
|
2015-11-17 11:24:36 +03:00
|
|
|
driver_release_tids =
|
|
|
|
BIT(find_highest_prio_tid(driver_release_tids));
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
mac80211: release multiple ACs in uAPSD, fix more-data bug
When a response for PS-Poll or a uAPSD trigger frame is sent, the
more-data bit should be set according to 802.11-2012 11.2.1.5 h),
meaning that it should indicate more data on the relevant ACs
(delivery-enabled or nondelivery-enabled for uAPSD or PS-Poll.)
In, for example, the following scenario:
* 1 frame on VO queue (either in driver or in mac80211)
* at least 1 frame on VI queue (in the driver)
* both VO/VI are delivery-enabled
* uAPSD trigger frame received
The more-data flag to the driver would not be set, even though
it should be.
While fixing this, I noticed that we should really release frames
from multiple ACs where there's data buffered in the driver for
the corresponding TIDs.
To address all this, restructure the code a bit to consider all
ACs if we only release driver frames or only buffered frames.
This also addresses the more-data bug described above as now the
TIDs will all be marked as released, so the driver will have to
check the number of frames.
While at it, clarify some code and comments and remove the found
variable, replacing it with the appropriate sw/hw release check.
Reported-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-08 20:45:07 +04:00
|
|
|
if (skb_queue_empty(&frames) && !driver_release_tids) {
|
2016-10-18 23:12:12 +03:00
|
|
|
int tid, ac;
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
|
|
|
/*
|
2011-09-29 18:04:34 +04:00
|
|
|
* For PS-Poll, this can only happen due to a race condition
|
|
|
|
* when we set the TIM bit and the station notices it, but
|
|
|
|
* before it can poll for the frame we expire it.
|
|
|
|
*
|
|
|
|
* For uAPSD, this is said in the standard (11.2.1.5 h):
|
|
|
|
* At each unscheduled SP for a non-AP STA, the AP shall
|
|
|
|
* attempt to transmit at least one MSDU or MMPDU, but no
|
|
|
|
* more than the value specified in the Max SP Length field
|
|
|
|
* in the QoS Capability element from delivery-enabled ACs,
|
|
|
|
* that are destined for the non-AP STA.
|
|
|
|
*
|
|
|
|
* Since we have no other MSDU/MMPDU, transmit a QoS null frame.
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
*/
|
|
|
|
|
2011-09-29 18:04:34 +04:00
|
|
|
/* This will evaluate to 1, 3, 5 or 7. */
|
2016-10-18 23:12:12 +03:00
|
|
|
for (ac = IEEE80211_AC_VO; ac < IEEE80211_NUM_ACS; ac++)
|
2016-10-25 10:32:16 +03:00
|
|
|
if (!(ignored_acs & ieee80211_ac_to_qos_mask[ac]))
|
|
|
|
break;
|
2016-10-18 23:12:12 +03:00
|
|
|
tid = 7 - 2 * ac;
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
2015-11-17 11:24:36 +03:00
|
|
|
ieee80211_send_null_response(sta, tid, reason, true, false);
|
mac80211: release multiple ACs in uAPSD, fix more-data bug
When a response for PS-Poll or a uAPSD trigger frame is sent, the
more-data bit should be set according to 802.11-2012 11.2.1.5 h),
meaning that it should indicate more data on the relevant ACs
(delivery-enabled or nondelivery-enabled for uAPSD or PS-Poll.)
In, for example, the following scenario:
* 1 frame on VO queue (either in driver or in mac80211)
* at least 1 frame on VI queue (in the driver)
* both VO/VI are delivery-enabled
* uAPSD trigger frame received
The more-data flag to the driver would not be set, even though
it should be.
While fixing this, I noticed that we should really release frames
from multiple ACs where there's data buffered in the driver for
the corresponding TIDs.
To address all this, restructure the code a bit to consider all
ACs if we only release driver frames or only buffered frames.
This also addresses the more-data bug described above as now the
TIDs will all be marked as released, so the driver will have to
check the number of frames.
While at it, clarify some code and comments and remove the found
variable, replacing it with the appropriate sw/hw release check.
Reported-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-08 20:45:07 +04:00
|
|
|
} else if (!driver_release_tids) {
|
2011-09-29 18:04:33 +04:00
|
|
|
struct sk_buff_head pending;
|
|
|
|
struct sk_buff *skb;
|
2011-09-29 18:04:38 +04:00
|
|
|
int num = 0;
|
|
|
|
u16 tids = 0;
|
2014-01-09 03:00:38 +04:00
|
|
|
bool need_null = false;
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
2011-09-29 18:04:33 +04:00
|
|
|
skb_queue_head_init(&pending);
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
2011-09-29 18:04:33 +04:00
|
|
|
while ((skb = __skb_dequeue(&frames))) {
|
|
|
|
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
|
|
|
|
struct ieee80211_hdr *hdr = (void *) skb->data;
|
2011-09-29 18:04:38 +04:00
|
|
|
u8 *qoshdr = NULL;
|
|
|
|
|
|
|
|
num++;
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
2011-09-29 18:04:33 +04:00
|
|
|
/*
|
|
|
|
* Tell TX path to send this frame even though the
|
|
|
|
* STA may still remain is PS mode after this frame
|
|
|
|
* exchange.
|
|
|
|
*/
|
2014-12-10 18:56:10 +03:00
|
|
|
info->flags |= IEEE80211_TX_CTL_NO_PS_BUFFER;
|
|
|
|
info->control.flags |= IEEE80211_TX_CTRL_PS_RESPONSE;
|
2011-09-29 18:04:33 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Use MoreData flag to indicate whether there are
|
|
|
|
* more buffered frames for this STA
|
|
|
|
*/
|
2011-11-07 11:47:47 +04:00
|
|
|
if (more_data || !skb_queue_empty(&frames))
|
2011-09-29 18:04:33 +04:00
|
|
|
hdr->frame_control |=
|
|
|
|
cpu_to_le16(IEEE80211_FCTL_MOREDATA);
|
2011-11-07 11:47:47 +04:00
|
|
|
else
|
|
|
|
hdr->frame_control &=
|
|
|
|
cpu_to_le16(~IEEE80211_FCTL_MOREDATA);
|
2011-09-29 18:04:33 +04:00
|
|
|
|
2011-09-29 18:04:38 +04:00
|
|
|
if (ieee80211_is_data_qos(hdr->frame_control) ||
|
|
|
|
ieee80211_is_qos_nullfunc(hdr->frame_control))
|
|
|
|
qoshdr = ieee80211_get_qos_ctl(hdr);
|
|
|
|
|
2014-01-09 03:00:38 +04:00
|
|
|
tids |= BIT(skb->priority);
|
2012-03-16 18:30:26 +04:00
|
|
|
|
2014-01-09 03:00:38 +04:00
|
|
|
__skb_queue_tail(&pending, skb);
|
|
|
|
|
|
|
|
/* end service period after last frame or add one */
|
|
|
|
if (!skb_queue_empty(&frames))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (reason != IEEE80211_FRAME_RELEASE_UAPSD) {
|
|
|
|
/* for PS-Poll, there's only one frame */
|
2012-03-16 18:30:26 +04:00
|
|
|
info->flags |= IEEE80211_TX_STATUS_EOSP |
|
|
|
|
IEEE80211_TX_CTL_REQ_TX_STATUS;
|
2014-01-09 03:00:38 +04:00
|
|
|
break;
|
2012-03-16 18:30:26 +04:00
|
|
|
}
|
2011-09-29 18:04:35 +04:00
|
|
|
|
2014-01-09 03:00:38 +04:00
|
|
|
/* For uAPSD, things are a bit more complicated. If the
|
|
|
|
* last frame has a QoS header (i.e. is a QoS-data or
|
|
|
|
* QoS-nulldata frame) then just set the EOSP bit there
|
|
|
|
* and be done.
|
|
|
|
* If the frame doesn't have a QoS header (which means
|
|
|
|
* it should be a bufferable MMPDU) then we can't set
|
|
|
|
* the EOSP bit in the QoS header; add a QoS-nulldata
|
|
|
|
* frame to the list to send it after the MMPDU.
|
|
|
|
*
|
|
|
|
* Note that this code is only in the mac80211-release
|
|
|
|
* code path, we assume that the driver will not buffer
|
|
|
|
* anything but QoS-data frames, or if it does, will
|
|
|
|
* create the QoS-nulldata frame by itself if needed.
|
|
|
|
*
|
|
|
|
* Cf. 802.11-2012 10.2.1.10 (c).
|
|
|
|
*/
|
|
|
|
if (qoshdr) {
|
|
|
|
*qoshdr |= IEEE80211_QOS_CTL_EOSP;
|
2011-09-29 18:04:38 +04:00
|
|
|
|
2014-01-09 03:00:38 +04:00
|
|
|
info->flags |= IEEE80211_TX_STATUS_EOSP |
|
|
|
|
IEEE80211_TX_CTL_REQ_TX_STATUS;
|
|
|
|
} else {
|
|
|
|
/* The standard isn't completely clear on this
|
|
|
|
* as it says the more-data bit should be set
|
|
|
|
* if there are more BUs. The QoS-Null frame
|
|
|
|
* we're about to send isn't buffered yet, we
|
|
|
|
* only create it below, but let's pretend it
|
|
|
|
* was buffered just in case some clients only
|
|
|
|
* expect more-data=0 when eosp=1.
|
|
|
|
*/
|
|
|
|
hdr->frame_control |=
|
|
|
|
cpu_to_le16(IEEE80211_FCTL_MOREDATA);
|
|
|
|
need_null = true;
|
|
|
|
num++;
|
|
|
|
}
|
|
|
|
break;
|
2011-09-29 18:04:33 +04:00
|
|
|
}
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
2011-09-29 18:04:38 +04:00
|
|
|
drv_allow_buffered_frames(local, sta, tids, num,
|
|
|
|
reason, more_data);
|
|
|
|
|
2011-09-29 18:04:33 +04:00
|
|
|
ieee80211_add_pending_skbs(local, &pending);
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
|
2014-01-09 03:00:38 +04:00
|
|
|
if (need_null)
|
|
|
|
ieee80211_send_null_response(
|
2015-11-17 11:24:36 +03:00
|
|
|
sta, find_highest_prio_tid(tids),
|
|
|
|
reason, false, false);
|
2014-01-09 03:00:38 +04:00
|
|
|
|
2011-09-29 18:04:27 +04:00
|
|
|
sta_info_recalc_tim(sta);
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
} else {
|
2015-03-27 23:30:37 +03:00
|
|
|
int tid;
|
|
|
|
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
/*
|
2011-09-29 18:04:32 +04:00
|
|
|
* We need to release a frame that is buffered somewhere in the
|
|
|
|
* driver ... it'll have to handle that.
|
mac80211: release multiple ACs in uAPSD, fix more-data bug
When a response for PS-Poll or a uAPSD trigger frame is sent, the
more-data bit should be set according to 802.11-2012 11.2.1.5 h),
meaning that it should indicate more data on the relevant ACs
(delivery-enabled or nondelivery-enabled for uAPSD or PS-Poll.)
In, for example, the following scenario:
* 1 frame on VO queue (either in driver or in mac80211)
* at least 1 frame on VI queue (in the driver)
* both VO/VI are delivery-enabled
* uAPSD trigger frame received
The more-data flag to the driver would not be set, even though
it should be.
While fixing this, I noticed that we should really release frames
from multiple ACs where there's data buffered in the driver for
the corresponding TIDs.
To address all this, restructure the code a bit to consider all
ACs if we only release driver frames or only buffered frames.
This also addresses the more-data bug described above as now the
TIDs will all be marked as released, so the driver will have to
check the number of frames.
While at it, clarify some code and comments and remove the found
variable, replacing it with the appropriate sw/hw release check.
Reported-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-08 20:45:07 +04:00
|
|
|
* Note that the driver also has to check the number of frames
|
|
|
|
* on the TIDs we're releasing from - if there are more than
|
|
|
|
* n_frames it has to set the more-data bit (if we didn't ask
|
|
|
|
* it to set it anyway due to other buffered frames); if there
|
|
|
|
* are fewer than n_frames it has to make sure to adjust that
|
|
|
|
* to allow the service period to end properly.
|
2011-09-29 18:04:32 +04:00
|
|
|
*/
|
|
|
|
drv_release_buffered_frames(local, sta, driver_release_tids,
|
2011-09-29 18:04:33 +04:00
|
|
|
n_frames, reason, more_data);
|
2011-09-29 18:04:32 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note that we don't recalculate the TIM bit here as it would
|
|
|
|
* most likely have no effect at all unless the driver told us
|
mac80211: release multiple ACs in uAPSD, fix more-data bug
When a response for PS-Poll or a uAPSD trigger frame is sent, the
more-data bit should be set according to 802.11-2012 11.2.1.5 h),
meaning that it should indicate more data on the relevant ACs
(delivery-enabled or nondelivery-enabled for uAPSD or PS-Poll.)
In, for example, the following scenario:
* 1 frame on VO queue (either in driver or in mac80211)
* at least 1 frame on VI queue (in the driver)
* both VO/VI are delivery-enabled
* uAPSD trigger frame received
The more-data flag to the driver would not be set, even though
it should be.
While fixing this, I noticed that we should really release frames
from multiple ACs where there's data buffered in the driver for
the corresponding TIDs.
To address all this, restructure the code a bit to consider all
ACs if we only release driver frames or only buffered frames.
This also addresses the more-data bug described above as now the
TIDs will all be marked as released, so the driver will have to
check the number of frames.
While at it, clarify some code and comments and remove the found
variable, replacing it with the appropriate sw/hw release check.
Reported-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-08 20:45:07 +04:00
|
|
|
* that the TID(s) became empty before returning here from the
|
2011-09-29 18:04:32 +04:00
|
|
|
* release function.
|
mac80211: release multiple ACs in uAPSD, fix more-data bug
When a response for PS-Poll or a uAPSD trigger frame is sent, the
more-data bit should be set according to 802.11-2012 11.2.1.5 h),
meaning that it should indicate more data on the relevant ACs
(delivery-enabled or nondelivery-enabled for uAPSD or PS-Poll.)
In, for example, the following scenario:
* 1 frame on VO queue (either in driver or in mac80211)
* at least 1 frame on VI queue (in the driver)
* both VO/VI are delivery-enabled
* uAPSD trigger frame received
The more-data flag to the driver would not be set, even though
it should be.
While fixing this, I noticed that we should really release frames
from multiple ACs where there's data buffered in the driver for
the corresponding TIDs.
To address all this, restructure the code a bit to consider all
ACs if we only release driver frames or only buffered frames.
This also addresses the more-data bug described above as now the
TIDs will all be marked as released, so the driver will have to
check the number of frames.
While at it, clarify some code and comments and remove the found
variable, replacing it with the appropriate sw/hw release check.
Reported-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-01-08 20:45:07 +04:00
|
|
|
* Either way, however, when the driver tells us that the TID(s)
|
2015-03-27 23:30:37 +03:00
|
|
|
* became empty or we find that a txq became empty, we'll do the
|
|
|
|
* TIM recalculation.
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
*/
|
2015-03-27 23:30:37 +03:00
|
|
|
|
|
|
|
for (tid = 0; tid < ARRAY_SIZE(sta->sta.txq); tid++) {
|
2018-08-31 11:31:08 +03:00
|
|
|
if (!sta->sta.txq[tid] ||
|
|
|
|
!(driver_release_tids & BIT(tid)) ||
|
2016-10-04 10:22:19 +03:00
|
|
|
txq_has_queue(sta->sta.txq[tid]))
|
2015-03-27 23:30:37 +03:00
|
|
|
continue;
|
|
|
|
|
|
|
|
sta_info_recalc_tim(sta);
|
|
|
|
break;
|
|
|
|
}
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-09-29 18:04:33 +04:00
|
|
|
void ieee80211_sta_ps_deliver_poll_response(struct sta_info *sta)
|
|
|
|
{
|
|
|
|
u8 ignore_for_response = sta->sta.uapsd_queues;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If all ACs are delivery-enabled then we should reply
|
|
|
|
* from any of them, if only some are enabled we reply
|
|
|
|
* only from the non-enabled ones.
|
|
|
|
*/
|
|
|
|
if (ignore_for_response == BIT(IEEE80211_NUM_ACS) - 1)
|
|
|
|
ignore_for_response = 0;
|
|
|
|
|
|
|
|
ieee80211_sta_ps_deliver_response(sta, 1, ignore_for_response,
|
|
|
|
IEEE80211_FRAME_RELEASE_PSPOLL);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_sta_ps_deliver_uapsd(struct sta_info *sta)
|
|
|
|
{
|
|
|
|
int n_frames = sta->sta.max_sp;
|
|
|
|
u8 delivery_enabled = sta->sta.uapsd_queues;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we ever grow support for TSPEC this might happen if
|
|
|
|
* the TSPEC update from hostapd comes in between a trigger
|
|
|
|
* frame setting WLAN_STA_UAPSD in the RX path and this
|
|
|
|
* actually getting called.
|
|
|
|
*/
|
|
|
|
if (!delivery_enabled)
|
|
|
|
return;
|
|
|
|
|
|
|
|
switch (sta->sta.max_sp) {
|
|
|
|
case 1:
|
|
|
|
n_frames = 2;
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
n_frames = 4;
|
|
|
|
break;
|
|
|
|
case 3:
|
|
|
|
n_frames = 6;
|
|
|
|
break;
|
|
|
|
case 0:
|
|
|
|
/* XXX: what is a good value? */
|
2014-11-04 12:33:04 +03:00
|
|
|
n_frames = 128;
|
2011-09-29 18:04:33 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
ieee80211_sta_ps_deliver_response(sta, n_frames, ~delivery_enabled,
|
|
|
|
IEEE80211_FRAME_RELEASE_UAPSD);
|
|
|
|
}
|
|
|
|
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
void ieee80211_sta_block_awake(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_sta *pubsta, bool block)
|
|
|
|
{
|
|
|
|
struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
|
|
|
|
|
2010-04-07 18:48:40 +04:00
|
|
|
trace_api_sta_block_awake(sta->local, pubsta, block);
|
|
|
|
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
if (block) {
|
2011-09-29 18:04:36 +04:00
|
|
|
set_sta_flag(sta, WLAN_STA_PS_DRIVER);
|
2015-03-21 17:25:43 +03:00
|
|
|
ieee80211_clear_fast_xmit(sta);
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!test_sta_flag(sta, WLAN_STA_PS_DRIVER))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!test_sta_flag(sta, WLAN_STA_PS_STA)) {
|
|
|
|
set_sta_flag(sta, WLAN_STA_PS_DELIVER);
|
|
|
|
clear_sta_flag(sta, WLAN_STA_PS_DRIVER);
|
|
|
|
ieee80211_queue_work(hw, &sta->drv_deliver_wk);
|
|
|
|
} else if (test_sta_flag(sta, WLAN_STA_PSPOLL) ||
|
|
|
|
test_sta_flag(sta, WLAN_STA_UAPSD)) {
|
|
|
|
/* must be asleep in this case */
|
|
|
|
clear_sta_flag(sta, WLAN_STA_PS_DRIVER);
|
|
|
|
ieee80211_queue_work(hw, &sta->drv_deliver_wk);
|
|
|
|
} else {
|
|
|
|
clear_sta_flag(sta, WLAN_STA_PS_DRIVER);
|
2015-03-21 17:25:43 +03:00
|
|
|
ieee80211_check_fast_xmit(sta);
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 18:32:27 +04:00
|
|
|
}
|
mac80211: async station powersave handling
Some devices require that all frames to a station
are flushed when that station goes into powersave
mode before being able to send frames to that
station again when it wakes up or polls -- all in
order to avoid reordering and too many or too few
frames being sent to the station when it polls.
Normally, this is the case unless the station
goes to sleep and wakes up very quickly again.
But in that case, frames for it may be pending
on the hardware queues, and thus races could
happen in the case of multiple hardware queues
used for QoS/WMM. Normally this isn't a problem,
but with the iwlwifi mechanism we need to make
sure the race doesn't happen.
This makes mac80211 able to cope with the race
with driver help by a new WLAN_STA_PS_DRIVER
per-station flag that can be controlled by the
driver and tells mac80211 whether it can transmit
frames or not. This flag must be set according to
very specific rules outlined in the documentation
for the function that controls it.
When we buffer new frames for the station, we
normally set the TIM bit right away, but while
the driver has blocked transmission to that sta
we need to avoid that as well since we cannot
respond to the station if it wakes up due to the
TIM bit. Once the driver unblocks, we can set
the TIM bit.
Similarly, when the station just wakes up, we
need to wait until all other frames are flushed
before we can transmit frames to that station,
so the same applies here, we need to wait for
the driver to give the OK.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-06 13:35:50 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ieee80211_sta_block_awake);
|
2011-04-17 19:45:00 +04:00
|
|
|
|
2013-02-16 00:38:08 +04:00
|
|
|
void ieee80211_sta_eosp(struct ieee80211_sta *pubsta)
|
2011-09-29 18:04:39 +04:00
|
|
|
{
|
|
|
|
struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
|
|
|
|
struct ieee80211_local *local = sta->local;
|
|
|
|
|
|
|
|
trace_api_eosp(local, pubsta);
|
|
|
|
|
2013-02-16 00:38:08 +04:00
|
|
|
clear_sta_flag(sta, WLAN_STA_SP);
|
2011-09-29 18:04:39 +04:00
|
|
|
}
|
2013-02-16 00:38:08 +04:00
|
|
|
EXPORT_SYMBOL(ieee80211_sta_eosp);
|
2011-09-29 18:04:39 +04:00
|
|
|
|
2015-11-17 11:24:36 +03:00
|
|
|
void ieee80211_send_eosp_nullfunc(struct ieee80211_sta *pubsta, int tid)
|
|
|
|
{
|
|
|
|
struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
|
|
|
|
enum ieee80211_frame_release_type reason;
|
|
|
|
bool more_data;
|
|
|
|
|
|
|
|
trace_api_send_eosp_nullfunc(sta->local, pubsta, tid);
|
|
|
|
|
|
|
|
reason = IEEE80211_FRAME_RELEASE_UAPSD;
|
|
|
|
more_data = ieee80211_sta_ps_more_data(sta, ~sta->sta.uapsd_queues,
|
|
|
|
reason, 0);
|
|
|
|
|
|
|
|
ieee80211_send_null_response(sta, tid, reason, false, more_data);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ieee80211_send_eosp_nullfunc);
|
|
|
|
|
2011-09-29 18:04:26 +04:00
|
|
|
void ieee80211_sta_set_buffered(struct ieee80211_sta *pubsta,
|
|
|
|
u8 tid, bool buffered)
|
2011-04-17 19:45:00 +04:00
|
|
|
{
|
|
|
|
struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
|
|
|
|
|
2012-11-15 02:22:21 +04:00
|
|
|
if (WARN_ON(tid >= IEEE80211_NUM_TIDS))
|
2011-09-29 18:04:26 +04:00
|
|
|
return;
|
|
|
|
|
2013-12-19 13:47:48 +04:00
|
|
|
trace_api_sta_set_buffered(sta->local, pubsta, tid, buffered);
|
|
|
|
|
2011-09-29 18:04:29 +04:00
|
|
|
if (buffered)
|
|
|
|
set_bit(tid, &sta->driver_buffered_tids);
|
|
|
|
else
|
|
|
|
clear_bit(tid, &sta->driver_buffered_tids);
|
|
|
|
|
2011-09-29 18:04:27 +04:00
|
|
|
sta_info_recalc_tim(sta);
|
2011-04-17 19:45:00 +04:00
|
|
|
}
|
2011-09-29 18:04:26 +04:00
|
|
|
EXPORT_SYMBOL(ieee80211_sta_set_buffered);
|
2011-12-14 15:35:30 +04:00
|
|
|
|
2022-06-26 00:24:05 +03:00
|
|
|
void ieee80211_sta_register_airtime(struct ieee80211_sta *pubsta, u8 tid,
|
|
|
|
u32 tx_airtime, u32 rx_airtime)
|
2018-12-19 04:02:08 +03:00
|
|
|
{
|
2022-06-26 00:24:05 +03:00
|
|
|
struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
|
|
|
|
struct ieee80211_local *local = sta->sdata->local;
|
|
|
|
u8 ac = ieee80211_ac_from_tid(tid);
|
2018-12-19 04:02:08 +03:00
|
|
|
u32 airtime = 0;
|
2022-06-26 00:24:11 +03:00
|
|
|
u32 diff;
|
2018-12-19 04:02:08 +03:00
|
|
|
|
2022-06-26 00:24:05 +03:00
|
|
|
if (sta->local->airtime_flags & AIRTIME_USE_TX)
|
2018-12-19 04:02:08 +03:00
|
|
|
airtime += tx_airtime;
|
2022-06-26 00:24:05 +03:00
|
|
|
if (sta->local->airtime_flags & AIRTIME_USE_RX)
|
2018-12-19 04:02:08 +03:00
|
|
|
airtime += rx_airtime;
|
|
|
|
|
2022-06-26 00:24:05 +03:00
|
|
|
spin_lock_bh(&local->active_txq_lock[ac]);
|
|
|
|
sta->airtime[ac].tx_airtime += tx_airtime;
|
|
|
|
sta->airtime[ac].rx_airtime += rx_airtime;
|
2022-06-26 00:24:11 +03:00
|
|
|
|
|
|
|
diff = (u32)jiffies - sta->airtime[ac].last_active;
|
|
|
|
if (diff <= AIRTIME_ACTIVE_DURATION)
|
|
|
|
sta->airtime[ac].deficit -= airtime;
|
|
|
|
|
2022-06-26 00:24:05 +03:00
|
|
|
spin_unlock_bh(&local->active_txq_lock[ac]);
|
2018-12-19 04:02:08 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ieee80211_sta_register_airtime);
|
|
|
|
|
2022-10-05 14:52:26 +03:00
|
|
|
void __ieee80211_sta_recalc_aggregates(struct sta_info *sta, u16 active_links)
|
2022-09-02 17:12:54 +03:00
|
|
|
{
|
|
|
|
bool first = true;
|
2022-10-05 14:52:26 +03:00
|
|
|
int link_id;
|
2022-09-02 17:12:54 +03:00
|
|
|
|
2022-10-05 14:52:26 +03:00
|
|
|
if (!sta->sta.valid_links || !sta->sta.mlo) {
|
|
|
|
sta->sta.cur = &sta->sta.deflink.agg;
|
2022-09-02 17:12:54 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2022-10-05 14:52:26 +03:00
|
|
|
for (link_id = 0; link_id < ARRAY_SIZE((sta)->link); link_id++) {
|
|
|
|
struct ieee80211_link_sta *link_sta;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!(active_links & BIT(link_id)))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
link_sta = rcu_dereference(sta->sta.link[link_id]);
|
|
|
|
if (!link_sta)
|
|
|
|
continue;
|
|
|
|
|
2022-09-02 17:12:54 +03:00
|
|
|
if (first) {
|
2022-10-05 14:52:26 +03:00
|
|
|
sta->cur = sta->sta.deflink.agg;
|
2022-09-02 17:12:54 +03:00
|
|
|
first = false;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
sta->cur.max_amsdu_len =
|
|
|
|
min(sta->cur.max_amsdu_len,
|
|
|
|
link_sta->agg.max_amsdu_len);
|
|
|
|
sta->cur.max_rc_amsdu_len =
|
|
|
|
min(sta->cur.max_rc_amsdu_len,
|
|
|
|
link_sta->agg.max_rc_amsdu_len);
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(sta->cur.max_tid_amsdu_len); i++)
|
|
|
|
sta->cur.max_tid_amsdu_len[i] =
|
|
|
|
min(sta->cur.max_tid_amsdu_len[i],
|
|
|
|
link_sta->agg.max_tid_amsdu_len[i]);
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2022-10-05 14:52:26 +03:00
|
|
|
sta->sta.cur = &sta->cur;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_sta_recalc_aggregates(struct ieee80211_sta *pubsta)
|
|
|
|
{
|
|
|
|
struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
|
|
|
|
|
|
|
|
__ieee80211_sta_recalc_aggregates(sta, sta->sdata->vif.active_links);
|
2022-09-02 17:12:54 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ieee80211_sta_recalc_aggregates);
|
|
|
|
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-19 09:06:09 +03:00
|
|
|
void ieee80211_sta_update_pending_airtime(struct ieee80211_local *local,
|
|
|
|
struct sta_info *sta, u8 ac,
|
|
|
|
u16 tx_airtime, bool tx_completed)
|
|
|
|
{
|
|
|
|
int tx_pending;
|
|
|
|
|
2019-12-12 14:14:37 +03:00
|
|
|
if (!wiphy_ext_feature_isset(local->hw.wiphy, NL80211_EXT_FEATURE_AQL))
|
|
|
|
return;
|
|
|
|
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-19 09:06:09 +03:00
|
|
|
if (!tx_completed) {
|
|
|
|
if (sta)
|
|
|
|
atomic_add(tx_airtime,
|
|
|
|
&sta->airtime[ac].aql_tx_pending);
|
|
|
|
|
|
|
|
atomic_add(tx_airtime, &local->aql_total_pending_airtime);
|
2022-06-26 00:24:09 +03:00
|
|
|
atomic_add(tx_airtime, &local->aql_ac_pending_airtime[ac]);
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-19 09:06:09 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (sta) {
|
|
|
|
tx_pending = atomic_sub_return(tx_airtime,
|
|
|
|
&sta->airtime[ac].aql_tx_pending);
|
2020-07-25 11:45:33 +03:00
|
|
|
if (tx_pending < 0)
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-19 09:06:09 +03:00
|
|
|
atomic_cmpxchg(&sta->airtime[ac].aql_tx_pending,
|
|
|
|
tx_pending, 0);
|
|
|
|
}
|
|
|
|
|
2022-06-26 00:24:09 +03:00
|
|
|
atomic_sub(tx_airtime, &local->aql_total_pending_airtime);
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-19 09:06:09 +03:00
|
|
|
tx_pending = atomic_sub_return(tx_airtime,
|
2022-06-26 00:24:09 +03:00
|
|
|
&local->aql_ac_pending_airtime[ac]);
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-19 09:06:09 +03:00
|
|
|
if (WARN_ONCE(tx_pending < 0,
|
|
|
|
"Device %s AC %d pending airtime underflow: %u, %u",
|
|
|
|
wiphy_name(local->hw.wiphy), ac, tx_pending,
|
2022-06-26 00:24:09 +03:00
|
|
|
tx_airtime)) {
|
|
|
|
atomic_cmpxchg(&local->aql_ac_pending_airtime[ac],
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-19 09:06:09 +03:00
|
|
|
tx_pending, 0);
|
2022-06-26 00:24:09 +03:00
|
|
|
atomic_sub(tx_pending, &local->aql_total_pending_airtime);
|
|
|
|
}
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-19 09:06:09 +03:00
|
|
|
}
|
|
|
|
|
2012-01-12 12:31:10 +04:00
|
|
|
int sta_info_move_state(struct sta_info *sta,
|
|
|
|
enum ieee80211_sta_state new_state)
|
2011-12-14 15:35:30 +04:00
|
|
|
{
|
2011-12-15 14:17:37 +04:00
|
|
|
might_sleep();
|
2011-12-14 15:35:30 +04:00
|
|
|
|
|
|
|
if (sta->sta_state == new_state)
|
|
|
|
return 0;
|
|
|
|
|
2012-01-20 16:55:21 +04:00
|
|
|
/* check allowed transitions first */
|
|
|
|
|
|
|
|
switch (new_state) {
|
|
|
|
case IEEE80211_STA_NONE:
|
|
|
|
if (sta->sta_state != IEEE80211_STA_AUTH)
|
|
|
|
return -EINVAL;
|
|
|
|
break;
|
|
|
|
case IEEE80211_STA_AUTH:
|
|
|
|
if (sta->sta_state != IEEE80211_STA_NONE &&
|
|
|
|
sta->sta_state != IEEE80211_STA_ASSOC)
|
|
|
|
return -EINVAL;
|
|
|
|
break;
|
|
|
|
case IEEE80211_STA_ASSOC:
|
|
|
|
if (sta->sta_state != IEEE80211_STA_AUTH &&
|
|
|
|
sta->sta_state != IEEE80211_STA_AUTHORIZED)
|
|
|
|
return -EINVAL;
|
|
|
|
break;
|
|
|
|
case IEEE80211_STA_AUTHORIZED:
|
|
|
|
if (sta->sta_state != IEEE80211_STA_ASSOC)
|
|
|
|
return -EINVAL;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
WARN(1, "invalid state %d", new_state);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-06-22 13:29:50 +04:00
|
|
|
sta_dbg(sta->sdata, "moving STA %pM to state %d\n",
|
|
|
|
sta->sta.addr, new_state);
|
2012-01-20 16:55:21 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* notify the driver before the actual changes so it can
|
|
|
|
* fail the transition
|
|
|
|
*/
|
|
|
|
if (test_sta_flag(sta, WLAN_STA_INSERTED)) {
|
|
|
|
int err = drv_sta_state(sta->local, sta->sdata, sta,
|
|
|
|
sta->sta_state, new_state);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* reflect the change in all state variables */
|
|
|
|
|
2011-12-14 15:35:30 +04:00
|
|
|
switch (new_state) {
|
|
|
|
case IEEE80211_STA_NONE:
|
|
|
|
if (sta->sta_state == IEEE80211_STA_AUTH)
|
|
|
|
clear_bit(WLAN_STA_AUTH, &sta->_flags);
|
|
|
|
break;
|
|
|
|
case IEEE80211_STA_AUTH:
|
2015-12-13 14:41:43 +03:00
|
|
|
if (sta->sta_state == IEEE80211_STA_NONE) {
|
2011-12-14 15:35:30 +04:00
|
|
|
set_bit(WLAN_STA_AUTH, &sta->_flags);
|
2015-12-13 14:41:43 +03:00
|
|
|
} else if (sta->sta_state == IEEE80211_STA_ASSOC) {
|
2011-12-14 15:35:30 +04:00
|
|
|
clear_bit(WLAN_STA_ASSOC, &sta->_flags);
|
2022-06-22 16:15:56 +03:00
|
|
|
ieee80211_recalc_min_chandef(sta->sdata, -1);
|
2016-03-17 16:41:39 +03:00
|
|
|
if (!sta->sta.support_p2p_ps)
|
|
|
|
ieee80211_recalc_p2p_go_ps_allowed(sta->sdata);
|
2015-12-13 14:41:43 +03:00
|
|
|
}
|
2011-12-14 15:35:30 +04:00
|
|
|
break;
|
|
|
|
case IEEE80211_STA_ASSOC:
|
2011-12-14 15:20:31 +04:00
|
|
|
if (sta->sta_state == IEEE80211_STA_AUTH) {
|
2011-12-14 15:35:30 +04:00
|
|
|
set_bit(WLAN_STA_ASSOC, &sta->_flags);
|
2019-08-09 21:00:01 +03:00
|
|
|
sta->assoc_at = ktime_get_boottime_ns();
|
2022-06-22 16:15:56 +03:00
|
|
|
ieee80211_recalc_min_chandef(sta->sdata, -1);
|
2016-03-17 16:41:39 +03:00
|
|
|
if (!sta->sta.support_p2p_ps)
|
|
|
|
ieee80211_recalc_p2p_go_ps_allowed(sta->sdata);
|
2011-12-14 15:20:31 +04:00
|
|
|
} else if (sta->sta_state == IEEE80211_STA_AUTHORIZED) {
|
2016-10-10 20:12:21 +03:00
|
|
|
ieee80211_vif_dec_num_mcast(sta->sdata);
|
2011-12-14 15:35:30 +04:00
|
|
|
clear_bit(WLAN_STA_AUTHORIZED, &sta->_flags);
|
2015-03-21 17:25:43 +03:00
|
|
|
ieee80211_clear_fast_xmit(sta);
|
2016-03-31 20:02:10 +03:00
|
|
|
ieee80211_clear_fast_rx(sta);
|
2012-01-20 16:55:21 +04:00
|
|
|
}
|
2011-12-14 15:35:30 +04:00
|
|
|
break;
|
|
|
|
case IEEE80211_STA_AUTHORIZED:
|
2011-12-14 15:20:31 +04:00
|
|
|
if (sta->sta_state == IEEE80211_STA_ASSOC) {
|
2016-10-10 20:12:21 +03:00
|
|
|
ieee80211_vif_inc_num_mcast(sta->sdata);
|
2011-12-14 15:35:30 +04:00
|
|
|
set_bit(WLAN_STA_AUTHORIZED, &sta->_flags);
|
2015-03-21 17:25:43 +03:00
|
|
|
ieee80211_check_fast_xmit(sta);
|
2016-03-31 20:02:10 +03:00
|
|
|
ieee80211_check_fast_rx(sta);
|
2012-01-20 16:55:21 +04:00
|
|
|
}
|
mac80211: Do not send Layer 2 Update frame before authorization
The Layer 2 Update frame is used to update bridges when a station roams
to another AP even if that STA does not transmit any frames after the
reassociation. This behavior was described in IEEE Std 802.11F-2003 as
something that would happen based on MLME-ASSOCIATE.indication, i.e.,
before completing 4-way handshake. However, this IEEE trial-use
recommended practice document was published before RSN (IEEE Std
802.11i-2004) and as such, did not consider RSN use cases. Furthermore,
IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been
maintained amd should not be used anymore.
Sending out the Layer 2 Update frame immediately after association is
fine for open networks (and also when using SAE, FT protocol, or FILS
authentication when the station is actually authenticated by the time
association completes). However, it is not appropriate for cases where
RSN is used with PSK or EAP authentication since the station is actually
fully authenticated only once the 4-way handshake completes after
authentication and attackers might be able to use the unauthenticated
triggering of Layer 2 Update frame transmission to disrupt bridge
behavior.
Fix this by postponing transmission of the Layer 2 Update frame from
station entry addition to the point when the station entry is marked
authorized. Similarly, send out the VLAN binding update only if the STA
entry has already been authorized.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-11 16:03:05 +03:00
|
|
|
if (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
|
|
|
|
sta->sdata->vif.type == NL80211_IFTYPE_AP)
|
|
|
|
cfg80211_send_layer2_update(sta->sdata->dev,
|
|
|
|
sta->sta.addr);
|
2011-12-14 15:35:30 +04:00
|
|
|
break;
|
|
|
|
default:
|
2012-01-20 16:55:21 +04:00
|
|
|
break;
|
2011-12-14 15:35:30 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
sta->sta_state = new_state;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2013-10-01 17:45:43 +04:00
|
|
|
|
2016-03-31 20:02:11 +03:00
|
|
|
static struct ieee80211_sta_rx_stats *
|
|
|
|
sta_get_last_rx_stats(struct sta_info *sta)
|
|
|
|
{
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
struct ieee80211_sta_rx_stats *stats = &sta->deflink.rx_stats;
|
2016-03-31 20:02:11 +03:00
|
|
|
int cpu;
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
if (!sta->deflink.pcpu_rx_stats)
|
2016-03-31 20:02:11 +03:00
|
|
|
return stats;
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
struct ieee80211_sta_rx_stats *cpustats;
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
cpustats = per_cpu_ptr(sta->deflink.pcpu_rx_stats, cpu);
|
2016-03-31 20:02:11 +03:00
|
|
|
|
|
|
|
if (time_after(cpustats->last_rx, stats->last_rx))
|
|
|
|
stats = cpustats;
|
|
|
|
}
|
|
|
|
|
|
|
|
return stats;
|
|
|
|
}
|
|
|
|
|
2018-06-09 09:14:44 +03:00
|
|
|
static void sta_stats_decode_rate(struct ieee80211_local *local, u32 rate,
|
2016-03-31 20:02:08 +03:00
|
|
|
struct rate_info *rinfo)
|
2015-10-14 19:31:30 +03:00
|
|
|
{
|
2017-04-26 15:51:20 +03:00
|
|
|
rinfo->bw = STA_STATS_GET(BW, rate);
|
2016-03-31 20:02:08 +03:00
|
|
|
|
2017-04-26 15:51:20 +03:00
|
|
|
switch (STA_STATS_GET(TYPE, rate)) {
|
2017-02-15 17:02:09 +03:00
|
|
|
case STA_STATS_RATE_TYPE_VHT:
|
2016-03-31 20:02:08 +03:00
|
|
|
rinfo->flags = RATE_INFO_FLAGS_VHT_MCS;
|
2017-04-26 15:51:20 +03:00
|
|
|
rinfo->mcs = STA_STATS_GET(VHT_MCS, rate);
|
|
|
|
rinfo->nss = STA_STATS_GET(VHT_NSS, rate);
|
|
|
|
if (STA_STATS_GET(SGI, rate))
|
|
|
|
rinfo->flags |= RATE_INFO_FLAGS_SHORT_GI;
|
2017-02-15 17:02:09 +03:00
|
|
|
break;
|
|
|
|
case STA_STATS_RATE_TYPE_HT:
|
2016-03-31 20:02:08 +03:00
|
|
|
rinfo->flags = RATE_INFO_FLAGS_MCS;
|
2017-04-26 15:51:20 +03:00
|
|
|
rinfo->mcs = STA_STATS_GET(HT_MCS, rate);
|
|
|
|
if (STA_STATS_GET(SGI, rate))
|
|
|
|
rinfo->flags |= RATE_INFO_FLAGS_SHORT_GI;
|
2017-02-15 17:02:09 +03:00
|
|
|
break;
|
|
|
|
case STA_STATS_RATE_TYPE_LEGACY: {
|
2015-10-14 19:31:30 +03:00
|
|
|
struct ieee80211_supported_band *sband;
|
|
|
|
u16 brate;
|
2016-03-31 20:02:08 +03:00
|
|
|
unsigned int shift;
|
2017-04-26 15:51:20 +03:00
|
|
|
int band = STA_STATS_GET(LEGACY_BAND, rate);
|
|
|
|
int rate_idx = STA_STATS_GET(LEGACY_IDX, rate);
|
2016-03-31 20:02:08 +03:00
|
|
|
|
2017-04-26 15:51:20 +03:00
|
|
|
sband = local->hw.wiphy->bands[band];
|
2020-10-05 19:45:21 +03:00
|
|
|
|
|
|
|
if (WARN_ON_ONCE(!sband->bitrates))
|
|
|
|
break;
|
|
|
|
|
2017-04-26 15:51:20 +03:00
|
|
|
brate = sband->bitrates[rate_idx].bitrate;
|
2016-03-31 20:02:08 +03:00
|
|
|
if (rinfo->bw == RATE_INFO_BW_5)
|
|
|
|
shift = 2;
|
|
|
|
else if (rinfo->bw == RATE_INFO_BW_10)
|
|
|
|
shift = 1;
|
|
|
|
else
|
|
|
|
shift = 0;
|
2015-10-14 19:31:30 +03:00
|
|
|
rinfo->legacy = DIV_ROUND_UP(brate, 1 << shift);
|
2017-02-15 17:02:09 +03:00
|
|
|
break;
|
|
|
|
}
|
2018-06-09 09:14:44 +03:00
|
|
|
case STA_STATS_RATE_TYPE_HE:
|
|
|
|
rinfo->flags = RATE_INFO_FLAGS_HE_MCS;
|
|
|
|
rinfo->mcs = STA_STATS_GET(HE_MCS, rate);
|
|
|
|
rinfo->nss = STA_STATS_GET(HE_NSS, rate);
|
|
|
|
rinfo->he_gi = STA_STATS_GET(HE_GI, rate);
|
|
|
|
rinfo->he_ru_alloc = STA_STATS_GET(HE_RU, rate);
|
|
|
|
rinfo->he_dcm = STA_STATS_GET(HE_DCM, rate);
|
|
|
|
break;
|
2015-10-14 19:31:30 +03:00
|
|
|
}
|
2016-03-31 20:02:08 +03:00
|
|
|
}
|
|
|
|
|
2016-12-14 22:30:38 +03:00
|
|
|
static int sta_set_rate_info_rx(struct sta_info *sta, struct rate_info *rinfo)
|
2016-03-31 20:02:08 +03:00
|
|
|
{
|
locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.
However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:
----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()
// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24 00:07:29 +03:00
|
|
|
u16 rate = READ_ONCE(sta_get_last_rx_stats(sta)->last_rate);
|
2015-10-14 19:31:30 +03:00
|
|
|
|
2016-03-31 20:02:08 +03:00
|
|
|
if (rate == STA_STATS_RATE_INVALID)
|
2016-12-14 22:30:38 +03:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
sta_stats_decode_rate(sta->local, rate, rinfo);
|
|
|
|
return 0;
|
2015-10-14 19:31:30 +03:00
|
|
|
}
|
|
|
|
|
2020-03-18 13:15:55 +03:00
|
|
|
static inline u64 sta_get_tidstats_msdu(struct ieee80211_sta_rx_stats *rxstats,
|
|
|
|
int tid)
|
|
|
|
{
|
|
|
|
unsigned int start;
|
|
|
|
u64 value;
|
|
|
|
|
|
|
|
do {
|
2022-10-26 16:22:15 +03:00
|
|
|
start = u64_stats_fetch_begin(&rxstats->syncp);
|
2020-03-18 13:15:55 +03:00
|
|
|
value = rxstats->msdu[tid];
|
2022-10-26 16:22:15 +03:00
|
|
|
} while (u64_stats_fetch_retry(&rxstats->syncp, start));
|
2020-03-18 13:15:55 +03:00
|
|
|
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
2016-03-31 20:02:09 +03:00
|
|
|
static void sta_set_tidstats(struct sta_info *sta,
|
|
|
|
struct cfg80211_tid_stats *tidstats,
|
|
|
|
int tid)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = sta->local;
|
2020-03-18 13:15:55 +03:00
|
|
|
int cpu;
|
2016-03-31 20:02:09 +03:00
|
|
|
|
|
|
|
if (!(tidstats->filled & BIT(NL80211_TID_STATS_RX_MSDU))) {
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
tidstats->rx_msdu += sta_get_tidstats_msdu(&sta->deflink.rx_stats,
|
|
|
|
tid);
|
2016-03-31 20:02:09 +03:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
if (sta->deflink.pcpu_rx_stats) {
|
2020-03-18 13:15:55 +03:00
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
struct ieee80211_sta_rx_stats *cpurxs;
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
cpurxs = per_cpu_ptr(sta->deflink.pcpu_rx_stats,
|
|
|
|
cpu);
|
2020-03-18 13:15:55 +03:00
|
|
|
tidstats->rx_msdu +=
|
|
|
|
sta_get_tidstats_msdu(cpurxs, tid);
|
|
|
|
}
|
|
|
|
}
|
2016-03-31 20:02:09 +03:00
|
|
|
|
|
|
|
tidstats->filled |= BIT(NL80211_TID_STATS_RX_MSDU);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(tidstats->filled & BIT(NL80211_TID_STATS_TX_MSDU))) {
|
|
|
|
tidstats->filled |= BIT(NL80211_TID_STATS_TX_MSDU);
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
tidstats->tx_msdu = sta->deflink.tx_stats.msdu[tid];
|
2016-03-31 20:02:09 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!(tidstats->filled & BIT(NL80211_TID_STATS_TX_MSDU_RETRIES)) &&
|
|
|
|
ieee80211_hw_check(&local->hw, REPORTS_TX_ACK_STATUS)) {
|
|
|
|
tidstats->filled |= BIT(NL80211_TID_STATS_TX_MSDU_RETRIES);
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
tidstats->tx_msdu_retries = sta->deflink.status_stats.msdu_retries[tid];
|
2016-03-31 20:02:09 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!(tidstats->filled & BIT(NL80211_TID_STATS_TX_MSDU_FAILED)) &&
|
|
|
|
ieee80211_hw_check(&local->hw, REPORTS_TX_ACK_STATUS)) {
|
|
|
|
tidstats->filled |= BIT(NL80211_TID_STATS_TX_MSDU_FAILED);
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
tidstats->tx_msdu_failed = sta->deflink.status_stats.msdu_failed[tid];
|
2016-03-31 20:02:09 +03:00
|
|
|
}
|
2018-05-08 14:03:50 +03:00
|
|
|
|
2022-10-09 19:30:40 +03:00
|
|
|
if (tid < IEEE80211_NUM_TIDS) {
|
2018-05-08 14:03:50 +03:00
|
|
|
spin_lock_bh(&local->fq.lock);
|
|
|
|
rcu_read_lock();
|
|
|
|
|
|
|
|
tidstats->filled |= BIT(NL80211_TID_STATS_TXQ_STATS);
|
|
|
|
ieee80211_fill_txq_stats(&tidstats->txq_stats,
|
|
|
|
to_txq_info(sta->sta.txq[tid]));
|
|
|
|
|
|
|
|
rcu_read_unlock();
|
|
|
|
spin_unlock_bh(&local->fq.lock);
|
|
|
|
}
|
2016-03-31 20:02:09 +03:00
|
|
|
}
|
|
|
|
|
2016-03-31 20:02:11 +03:00
|
|
|
static inline u64 sta_get_stats_bytes(struct ieee80211_sta_rx_stats *rxstats)
|
|
|
|
{
|
|
|
|
unsigned int start;
|
|
|
|
u64 value;
|
|
|
|
|
|
|
|
do {
|
2022-10-26 16:22:15 +03:00
|
|
|
start = u64_stats_fetch_begin(&rxstats->syncp);
|
2016-03-31 20:02:11 +03:00
|
|
|
value = rxstats->bytes;
|
2022-10-26 16:22:15 +03:00
|
|
|
} while (u64_stats_fetch_retry(&rxstats->syncp, start));
|
2016-03-31 20:02:11 +03:00
|
|
|
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
2018-05-18 12:40:44 +03:00
|
|
|
void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo,
|
|
|
|
bool tidstats)
|
2014-06-04 19:31:56 +04:00
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
u32 thr = 0;
|
2016-03-31 20:02:11 +03:00
|
|
|
int i, ac, cpu;
|
|
|
|
struct ieee80211_sta_rx_stats *last_rxstats;
|
|
|
|
|
|
|
|
last_rxstats = sta_get_last_rx_stats(sta);
|
2014-06-04 19:31:56 +04:00
|
|
|
|
|
|
|
sinfo->generation = sdata->local->sta_generation;
|
|
|
|
|
2015-01-21 23:09:02 +03:00
|
|
|
/* do before driver, so beacon filtering drivers have a
|
|
|
|
* chance to e.g. just add the number of filtered beacons
|
|
|
|
* (or just modify the value entirely, of course)
|
|
|
|
*/
|
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_STATION)
|
2022-05-16 16:00:15 +03:00
|
|
|
sinfo->rx_beacon = sdata->deflink.u.mgd.count_beacon_signal;
|
2015-01-21 23:09:02 +03:00
|
|
|
|
2014-11-17 13:35:23 +03:00
|
|
|
drv_sta_statistics(local, sdata, &sta->sta, sinfo);
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_INACTIVE_TIME) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_STA_FLAGS) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_BSS_PARAM) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_CONNECTED_TIME) |
|
2019-08-09 21:00:01 +03:00
|
|
|
BIT_ULL(NL80211_STA_INFO_ASSOC_AT_BOOTTIME) |
|
2018-06-17 13:06:25 +03:00
|
|
|
BIT_ULL(NL80211_STA_INFO_RX_DROP_MISC);
|
2015-10-16 18:18:11 +03:00
|
|
|
|
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_STATION) {
|
2022-05-16 16:00:15 +03:00
|
|
|
sinfo->beacon_loss_count =
|
|
|
|
sdata->deflink.u.mgd.beacon_loss_count;
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_BEACON_LOSS);
|
2015-10-16 18:18:11 +03:00
|
|
|
}
|
2014-06-04 19:31:56 +04:00
|
|
|
|
2015-09-30 14:26:36 +03:00
|
|
|
sinfo->connected_time = ktime_get_seconds() - sta->last_connected;
|
2019-08-09 21:00:01 +03:00
|
|
|
sinfo->assoc_at = sta->assoc_at;
|
2015-10-16 18:54:47 +03:00
|
|
|
sinfo->inactive_time =
|
2016-03-31 20:02:07 +03:00
|
|
|
jiffies_to_msecs(jiffies - ieee80211_sta_last_active(sta));
|
2014-11-17 13:35:23 +03:00
|
|
|
|
2018-06-17 13:06:25 +03:00
|
|
|
if (!(sinfo->filled & (BIT_ULL(NL80211_STA_INFO_TX_BYTES64) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_TX_BYTES)))) {
|
2014-11-17 13:35:23 +03:00
|
|
|
sinfo->tx_bytes = 0;
|
|
|
|
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
sinfo->tx_bytes += sta->deflink.tx_stats.bytes[ac];
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_BYTES64);
|
2014-11-17 13:35:23 +03:00
|
|
|
}
|
|
|
|
|
2018-06-17 13:06:25 +03:00
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_TX_PACKETS))) {
|
2014-11-17 13:35:23 +03:00
|
|
|
sinfo->tx_packets = 0;
|
|
|
|
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
sinfo->tx_packets += sta->deflink.tx_stats.packets[ac];
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_PACKETS);
|
2014-11-17 13:35:23 +03:00
|
|
|
}
|
|
|
|
|
2018-06-17 13:06:25 +03:00
|
|
|
if (!(sinfo->filled & (BIT_ULL(NL80211_STA_INFO_RX_BYTES64) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_RX_BYTES)))) {
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
sinfo->rx_bytes += sta_get_stats_bytes(&sta->deflink.rx_stats);
|
2016-03-31 20:02:11 +03:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
if (sta->deflink.pcpu_rx_stats) {
|
2016-03-31 20:02:11 +03:00
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
struct ieee80211_sta_rx_stats *cpurxs;
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
cpurxs = per_cpu_ptr(sta->deflink.pcpu_rx_stats,
|
|
|
|
cpu);
|
2016-03-31 20:02:11 +03:00
|
|
|
sinfo->rx_bytes += sta_get_stats_bytes(cpurxs);
|
|
|
|
}
|
|
|
|
}
|
2016-03-31 20:02:09 +03:00
|
|
|
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_RX_BYTES64);
|
2014-11-17 13:35:23 +03:00
|
|
|
}
|
|
|
|
|
2018-06-17 13:06:25 +03:00
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_RX_PACKETS))) {
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
sinfo->rx_packets = sta->deflink.rx_stats.packets;
|
|
|
|
if (sta->deflink.pcpu_rx_stats) {
|
2016-03-31 20:02:11 +03:00
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
struct ieee80211_sta_rx_stats *cpurxs;
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
cpurxs = per_cpu_ptr(sta->deflink.pcpu_rx_stats,
|
|
|
|
cpu);
|
2016-03-31 20:02:11 +03:00
|
|
|
sinfo->rx_packets += cpurxs->packets;
|
|
|
|
}
|
|
|
|
}
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_RX_PACKETS);
|
2014-11-17 13:35:23 +03:00
|
|
|
}
|
|
|
|
|
2018-06-17 13:06:25 +03:00
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_TX_RETRIES))) {
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
sinfo->tx_retries = sta->deflink.status_stats.retry_count;
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_RETRIES);
|
2014-11-17 13:35:23 +03:00
|
|
|
}
|
|
|
|
|
2018-06-17 13:06:25 +03:00
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_TX_FAILED))) {
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
sinfo->tx_failed = sta->deflink.status_stats.retry_failed;
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_FAILED);
|
2014-06-04 19:31:56 +04:00
|
|
|
}
|
2014-11-17 13:35:23 +03:00
|
|
|
|
2018-12-19 04:02:08 +03:00
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_RX_DURATION))) {
|
|
|
|
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
|
|
|
|
sinfo->rx_duration += sta->airtime[ac].rx_airtime;
|
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_RX_DURATION);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_TX_DURATION))) {
|
|
|
|
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
|
|
|
|
sinfo->tx_duration += sta->airtime[ac].tx_airtime;
|
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_DURATION);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_AIRTIME_WEIGHT))) {
|
2022-06-26 00:24:05 +03:00
|
|
|
sinfo->airtime_weight = sta->airtime_weight;
|
2018-12-19 04:02:08 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_AIRTIME_WEIGHT);
|
|
|
|
}
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
sinfo->rx_dropped_misc = sta->deflink.rx_stats.dropped;
|
|
|
|
if (sta->deflink.pcpu_rx_stats) {
|
2016-03-31 20:02:11 +03:00
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
struct ieee80211_sta_rx_stats *cpurxs;
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
cpurxs = per_cpu_ptr(sta->deflink.pcpu_rx_stats, cpu);
|
2017-06-01 22:26:03 +03:00
|
|
|
sinfo->rx_dropped_misc += cpurxs->dropped;
|
2016-03-31 20:02:11 +03:00
|
|
|
}
|
|
|
|
}
|
2014-06-04 19:31:56 +04:00
|
|
|
|
2015-01-21 23:09:02 +03:00
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_STATION &&
|
|
|
|
!(sdata->vif.driver_flags & IEEE80211_VIF_BEACON_FILTER)) {
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_BEACON_RX) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_BEACON_SIGNAL_AVG);
|
2015-01-21 23:09:02 +03:00
|
|
|
sinfo->rx_beacon_signal_avg = ieee80211_ave_rssi(&sdata->vif);
|
|
|
|
}
|
|
|
|
|
2015-06-02 22:39:54 +03:00
|
|
|
if (ieee80211_hw_check(&sta->local->hw, SIGNAL_DBM) ||
|
|
|
|
ieee80211_hw_check(&sta->local->hw, SIGNAL_UNSPEC)) {
|
2018-06-17 13:06:25 +03:00
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_SIGNAL))) {
|
2016-03-31 20:02:11 +03:00
|
|
|
sinfo->signal = (s8)last_rxstats->last_signal;
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_SIGNAL);
|
2014-11-17 13:35:23 +03:00
|
|
|
}
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
if (!sta->deflink.pcpu_rx_stats &&
|
2018-06-17 13:06:25 +03:00
|
|
|
!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_SIGNAL_AVG))) {
|
2015-07-13 13:26:46 +03:00
|
|
|
sinfo->signal_avg =
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
-ewma_signal_read(&sta->deflink.rx_stats_avg.signal);
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_SIGNAL_AVG);
|
2014-11-17 13:35:23 +03:00
|
|
|
}
|
2014-06-04 19:31:56 +04:00
|
|
|
}
|
2014-11-17 13:35:23 +03:00
|
|
|
|
2016-03-31 20:02:11 +03:00
|
|
|
/* for the average - if pcpu_rx_stats isn't set - rxstats must point to
|
|
|
|
* the sta->rx_stats struct, so the check here is fine with and without
|
|
|
|
* pcpu statistics
|
|
|
|
*/
|
|
|
|
if (last_rxstats->chains &&
|
2018-06-17 13:06:25 +03:00
|
|
|
!(sinfo->filled & (BIT_ULL(NL80211_STA_INFO_CHAIN_SIGNAL) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_CHAIN_SIGNAL_AVG)))) {
|
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_CHAIN_SIGNAL);
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
if (!sta->deflink.pcpu_rx_stats)
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_CHAIN_SIGNAL_AVG);
|
2016-03-31 20:02:11 +03:00
|
|
|
|
|
|
|
sinfo->chains = last_rxstats->chains;
|
2014-06-04 19:31:56 +04:00
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(sinfo->chain_signal); i++) {
|
2015-10-16 18:54:47 +03:00
|
|
|
sinfo->chain_signal[i] =
|
2016-03-31 20:02:11 +03:00
|
|
|
last_rxstats->chain_signal_last[i];
|
2014-06-04 19:31:56 +04:00
|
|
|
sinfo->chain_signal_avg[i] =
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
-ewma_signal_read(&sta->deflink.rx_stats_avg.chain_signal[i]);
|
2014-06-04 19:31:56 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-07-07 16:11:54 +03:00
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_TX_BITRATE)) &&
|
|
|
|
!sta->sta.valid_links) {
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
sta_set_rate_info_tx(sta, &sta->deflink.tx_stats.last_rate,
|
2015-10-16 18:54:47 +03:00
|
|
|
&sinfo->txrate);
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_BITRATE);
|
2014-11-17 13:35:23 +03:00
|
|
|
}
|
|
|
|
|
2022-07-07 16:11:54 +03:00
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_RX_BITRATE)) &&
|
|
|
|
!sta->sta.valid_links) {
|
2016-12-14 22:30:38 +03:00
|
|
|
if (sta_set_rate_info_rx(sta, &sinfo->rxrate) == 0)
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_RX_BITRATE);
|
2014-11-17 13:35:23 +03:00
|
|
|
}
|
2014-06-04 19:31:56 +04:00
|
|
|
|
2018-05-18 12:40:44 +03:00
|
|
|
if (tidstats && !cfg80211_sinfo_alloc_tid_stats(sinfo, GFP_KERNEL)) {
|
2018-11-09 13:13:15 +03:00
|
|
|
for (i = 0; i < IEEE80211_NUM_TIDS + 1; i++)
|
|
|
|
sta_set_tidstats(sta, &sinfo->pertid[i], i);
|
2014-11-21 16:26:31 +03:00
|
|
|
}
|
|
|
|
|
2014-06-04 19:31:56 +04:00
|
|
|
if (ieee80211_vif_is_mesh(&sdata->vif)) {
|
|
|
|
#ifdef CONFIG_MAC80211_MESH
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_LLID) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_PLID) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_PLINK_STATE) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_LOCAL_PM) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_PEER_PM) |
|
2018-10-25 22:48:53 +03:00
|
|
|
BIT_ULL(NL80211_STA_INFO_NONPEER_PM) |
|
2020-06-11 17:02:38 +03:00
|
|
|
BIT_ULL(NL80211_STA_INFO_CONNECTED_TO_GATE) |
|
|
|
|
BIT_ULL(NL80211_STA_INFO_CONNECTED_TO_AS);
|
2014-06-04 19:31:56 +04:00
|
|
|
|
2015-06-17 11:31:00 +03:00
|
|
|
sinfo->llid = sta->mesh->llid;
|
|
|
|
sinfo->plid = sta->mesh->plid;
|
|
|
|
sinfo->plink_state = sta->mesh->plink_state;
|
2014-06-04 19:31:56 +04:00
|
|
|
if (test_sta_flag(sta, WLAN_STA_TOFFSET_KNOWN)) {
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_T_OFFSET);
|
2015-06-17 11:31:00 +03:00
|
|
|
sinfo->t_offset = sta->mesh->t_offset;
|
2014-06-04 19:31:56 +04:00
|
|
|
}
|
2015-06-17 11:31:00 +03:00
|
|
|
sinfo->local_pm = sta->mesh->local_pm;
|
|
|
|
sinfo->peer_pm = sta->mesh->peer_pm;
|
|
|
|
sinfo->nonpeer_pm = sta->mesh->nonpeer_pm;
|
2018-10-25 22:48:53 +03:00
|
|
|
sinfo->connected_to_gate = sta->mesh->connected_to_gate;
|
2020-06-11 17:02:38 +03:00
|
|
|
sinfo->connected_to_as = sta->mesh->connected_to_as;
|
2014-06-04 19:31:56 +04:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
sinfo->bss_param.flags = 0;
|
|
|
|
if (sdata->vif.bss_conf.use_cts_prot)
|
|
|
|
sinfo->bss_param.flags |= BSS_PARAM_FLAGS_CTS_PROT;
|
|
|
|
if (sdata->vif.bss_conf.use_short_preamble)
|
|
|
|
sinfo->bss_param.flags |= BSS_PARAM_FLAGS_SHORT_PREAMBLE;
|
|
|
|
if (sdata->vif.bss_conf.use_short_slot)
|
|
|
|
sinfo->bss_param.flags |= BSS_PARAM_FLAGS_SHORT_SLOT_TIME;
|
2014-09-03 16:25:04 +04:00
|
|
|
sinfo->bss_param.dtim_period = sdata->vif.bss_conf.dtim_period;
|
2014-06-04 19:31:56 +04:00
|
|
|
sinfo->bss_param.beacon_interval = sdata->vif.bss_conf.beacon_int;
|
|
|
|
|
|
|
|
sinfo->sta_flags.set = 0;
|
|
|
|
sinfo->sta_flags.mask = BIT(NL80211_STA_FLAG_AUTHORIZED) |
|
|
|
|
BIT(NL80211_STA_FLAG_SHORT_PREAMBLE) |
|
|
|
|
BIT(NL80211_STA_FLAG_WME) |
|
|
|
|
BIT(NL80211_STA_FLAG_MFP) |
|
|
|
|
BIT(NL80211_STA_FLAG_AUTHENTICATED) |
|
|
|
|
BIT(NL80211_STA_FLAG_ASSOCIATED) |
|
|
|
|
BIT(NL80211_STA_FLAG_TDLS_PEER);
|
|
|
|
if (test_sta_flag(sta, WLAN_STA_AUTHORIZED))
|
|
|
|
sinfo->sta_flags.set |= BIT(NL80211_STA_FLAG_AUTHORIZED);
|
|
|
|
if (test_sta_flag(sta, WLAN_STA_SHORT_PREAMBLE))
|
|
|
|
sinfo->sta_flags.set |= BIT(NL80211_STA_FLAG_SHORT_PREAMBLE);
|
2014-07-22 16:50:47 +04:00
|
|
|
if (sta->sta.wme)
|
2014-06-04 19:31:56 +04:00
|
|
|
sinfo->sta_flags.set |= BIT(NL80211_STA_FLAG_WME);
|
|
|
|
if (test_sta_flag(sta, WLAN_STA_MFP))
|
|
|
|
sinfo->sta_flags.set |= BIT(NL80211_STA_FLAG_MFP);
|
|
|
|
if (test_sta_flag(sta, WLAN_STA_AUTH))
|
|
|
|
sinfo->sta_flags.set |= BIT(NL80211_STA_FLAG_AUTHENTICATED);
|
|
|
|
if (test_sta_flag(sta, WLAN_STA_ASSOC))
|
|
|
|
sinfo->sta_flags.set |= BIT(NL80211_STA_FLAG_ASSOCIATED);
|
|
|
|
if (test_sta_flag(sta, WLAN_STA_TDLS_PEER))
|
|
|
|
sinfo->sta_flags.set |= BIT(NL80211_STA_FLAG_TDLS_PEER);
|
|
|
|
|
2016-07-11 17:15:24 +03:00
|
|
|
thr = sta_get_expected_throughput(sta);
|
|
|
|
|
|
|
|
if (thr != 0) {
|
2018-06-17 13:06:25 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
|
2016-07-11 17:15:24 +03:00
|
|
|
sinfo->expected_throughput = thr;
|
|
|
|
}
|
2018-02-13 08:34:46 +03:00
|
|
|
|
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL)) &&
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
sta->deflink.status_stats.ack_signal_filled) {
|
|
|
|
sinfo->ack_signal = sta->deflink.status_stats.last_ack_signal;
|
2018-02-13 08:34:46 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL);
|
|
|
|
}
|
2018-04-16 17:48:41 +03:00
|
|
|
|
2018-07-19 16:26:27 +03:00
|
|
|
if (!(sinfo->filled & BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL_AVG)) &&
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
sta->deflink.status_stats.ack_signal_filled) {
|
2018-04-16 17:48:41 +03:00
|
|
|
sinfo->avg_ack_signal =
|
|
|
|
-(s8)ewma_avg_signal_read(
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
&sta->deflink.status_stats.avg_ack_signal);
|
2018-04-16 17:48:41 +03:00
|
|
|
sinfo->filled |=
|
2018-07-19 16:26:27 +03:00
|
|
|
BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL_AVG);
|
2018-04-16 17:48:41 +03:00
|
|
|
}
|
2019-02-07 23:16:05 +03:00
|
|
|
|
|
|
|
if (ieee80211_vif_is_mesh(&sdata->vif)) {
|
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_AIRTIME_LINK_METRIC);
|
|
|
|
sinfo->airtime_link_metric =
|
|
|
|
airtime_link_metric_get(local, sta);
|
|
|
|
}
|
2016-07-11 17:15:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
u32 sta_get_expected_throughput(struct sta_info *sta)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
struct rate_control_ref *ref = NULL;
|
|
|
|
u32 thr = 0;
|
|
|
|
|
|
|
|
if (test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
|
|
|
|
ref = local->rate_ctrl;
|
|
|
|
|
2014-06-04 19:31:56 +04:00
|
|
|
/* check if the driver has a SW RC implementation */
|
|
|
|
if (ref && ref->ops->get_expected_throughput)
|
|
|
|
thr = ref->ops->get_expected_throughput(sta->rate_ctrl_priv);
|
|
|
|
else
|
2016-08-11 13:38:16 +03:00
|
|
|
thr = drv_get_expected_throughput(local, sta);
|
2014-06-04 19:31:56 +04:00
|
|
|
|
2016-07-11 17:15:24 +03:00
|
|
|
return thr;
|
2014-06-04 19:31:56 +04:00
|
|
|
}
|
2016-03-31 20:02:07 +03:00
|
|
|
|
|
|
|
unsigned long ieee80211_sta_last_active(struct sta_info *sta)
|
|
|
|
{
|
2016-03-31 20:02:11 +03:00
|
|
|
struct ieee80211_sta_rx_stats *stats = sta_get_last_rx_stats(sta);
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
if (!sta->deflink.status_stats.last_ack ||
|
|
|
|
time_after(stats->last_rx, sta->deflink.status_stats.last_ack))
|
2016-03-31 20:02:11 +03:00
|
|
|
return stats->last_rx;
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 18:41:23 +03:00
|
|
|
return sta->deflink.status_stats.last_ack;
|
2016-03-31 20:02:07 +03:00
|
|
|
}
|
2017-04-06 12:38:26 +03:00
|
|
|
|
|
|
|
static void sta_update_codel_params(struct sta_info *sta, u32 thr)
|
|
|
|
{
|
|
|
|
if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
|
|
|
|
sta->cparams.target = MS2TIME(50);
|
|
|
|
sta->cparams.interval = MS2TIME(300);
|
|
|
|
sta->cparams.ecn = false;
|
|
|
|
} else {
|
|
|
|
sta->cparams.target = MS2TIME(20);
|
|
|
|
sta->cparams.interval = MS2TIME(100);
|
|
|
|
sta->cparams.ecn = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_sta_set_expected_throughput(struct ieee80211_sta *pubsta,
|
|
|
|
u32 thr)
|
|
|
|
{
|
|
|
|
struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
|
|
|
|
|
|
|
|
sta_update_codel_params(sta, thr);
|
|
|
|
}
|
2022-06-01 00:20:08 +03:00
|
|
|
|
|
|
|
int ieee80211_sta_allocate_link(struct sta_info *sta, unsigned int link_id)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
|
|
|
struct sta_link_alloc *alloc;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
lockdep_assert_held(&sdata->local->sta_mtx);
|
|
|
|
|
|
|
|
/* must represent an MLD from the start */
|
|
|
|
if (WARN_ON(!sta->sta.valid_links))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (WARN_ON(sta->sta.valid_links & BIT(link_id) ||
|
|
|
|
sta->link[link_id]))
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
alloc = kzalloc(sizeof(*alloc), GFP_KERNEL);
|
|
|
|
if (!alloc)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
ret = sta_info_alloc_link(sdata->local, &alloc->info, GFP_KERNEL);
|
|
|
|
if (ret) {
|
|
|
|
kfree(alloc);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
sta_info_add_link(sta, link_id, &alloc->info, &alloc->sta);
|
|
|
|
|
2022-09-06 15:26:52 +03:00
|
|
|
ieee80211_link_sta_debugfs_add(&alloc->info);
|
|
|
|
|
2022-06-01 00:20:08 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-06-14 17:27:03 +03:00
|
|
|
void ieee80211_sta_free_link(struct sta_info *sta, unsigned int link_id)
|
|
|
|
{
|
|
|
|
lockdep_assert_held(&sta->sdata->local->sta_mtx);
|
|
|
|
|
|
|
|
sta_remove_link(sta, link_id, false);
|
|
|
|
}
|
|
|
|
|
2022-06-01 00:20:08 +03:00
|
|
|
int ieee80211_sta_activate_link(struct sta_info *sta, unsigned int link_id)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
2022-06-15 10:20:45 +03:00
|
|
|
struct link_sta_info *link_sta;
|
2022-06-01 00:20:08 +03:00
|
|
|
u16 old_links = sta->sta.valid_links;
|
|
|
|
u16 new_links = old_links | BIT(link_id);
|
|
|
|
int ret;
|
|
|
|
|
2022-06-15 10:20:45 +03:00
|
|
|
link_sta = rcu_dereference_protected(sta->link[link_id],
|
|
|
|
lockdep_is_held(&sdata->local->sta_mtx));
|
2022-06-01 00:20:08 +03:00
|
|
|
|
2022-06-15 10:20:45 +03:00
|
|
|
if (WARN_ON(old_links == new_links || !link_sta))
|
2022-06-01 00:20:08 +03:00
|
|
|
return -EINVAL;
|
|
|
|
|
2022-07-19 13:08:29 +03:00
|
|
|
rcu_read_lock();
|
|
|
|
if (link_sta_info_hash_lookup(sdata->local, link_sta->addr)) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
return -EALREADY;
|
|
|
|
}
|
|
|
|
/* we only modify under the mutex so this is fine */
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2022-06-01 00:20:08 +03:00
|
|
|
sta->sta.valid_links = new_links;
|
|
|
|
|
2022-08-12 13:31:26 +03:00
|
|
|
if (!test_sta_flag(sta, WLAN_STA_INSERTED))
|
2022-06-14 14:07:42 +03:00
|
|
|
goto hash;
|
2022-06-01 00:20:08 +03:00
|
|
|
|
2022-09-02 17:12:54 +03:00
|
|
|
/* Ensure the values are updated for the driver,
|
|
|
|
* redone by sta_remove_link on failure.
|
|
|
|
*/
|
|
|
|
ieee80211_sta_recalc_aggregates(&sta->sta);
|
|
|
|
|
2022-06-01 00:20:08 +03:00
|
|
|
ret = drv_change_sta_links(sdata->local, sdata, &sta->sta,
|
|
|
|
old_links, new_links);
|
|
|
|
if (ret) {
|
|
|
|
sta->sta.valid_links = old_links;
|
2022-06-14 14:07:42 +03:00
|
|
|
sta_remove_link(sta, link_id, false);
|
2022-07-19 13:08:29 +03:00
|
|
|
return ret;
|
2022-06-01 00:20:08 +03:00
|
|
|
}
|
|
|
|
|
2022-06-14 14:07:42 +03:00
|
|
|
hash:
|
2022-07-19 13:08:29 +03:00
|
|
|
ret = link_sta_info_hash_add(sdata->local, link_sta);
|
|
|
|
WARN_ON(ret);
|
|
|
|
return 0;
|
2022-06-01 00:20:08 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_sta_remove_link(struct sta_info *sta, unsigned int link_id)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = sta->sdata;
|
2022-07-24 11:07:32 +03:00
|
|
|
u16 old_links = sta->sta.valid_links;
|
2022-06-01 00:20:08 +03:00
|
|
|
|
|
|
|
lockdep_assert_held(&sdata->local->sta_mtx);
|
|
|
|
|
|
|
|
sta->sta.valid_links &= ~BIT(link_id);
|
|
|
|
|
|
|
|
if (test_sta_flag(sta, WLAN_STA_INSERTED))
|
|
|
|
drv_change_sta_links(sdata->local, sdata, &sta->sta,
|
2022-07-24 11:07:32 +03:00
|
|
|
old_links, sta->sta.valid_links);
|
2022-06-01 00:20:08 +03:00
|
|
|
|
2022-06-14 14:07:42 +03:00
|
|
|
sta_remove_link(sta, link_id, true);
|
2022-06-01 00:20:08 +03:00
|
|
|
}
|
2022-07-13 19:08:03 +03:00
|
|
|
|
|
|
|
void ieee80211_sta_set_max_amsdu_subframes(struct sta_info *sta,
|
|
|
|
const u8 *ext_capab,
|
|
|
|
unsigned int ext_capab_len)
|
|
|
|
{
|
|
|
|
u8 val;
|
|
|
|
|
|
|
|
sta->sta.max_amsdu_subframes = 0;
|
|
|
|
|
|
|
|
if (ext_capab_len < 8)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* The sender might not have sent the last bit, consider it to be 0 */
|
|
|
|
val = u8_get_bits(ext_capab[7], WLAN_EXT_CAPA8_MAX_MSDU_IN_AMSDU_LSB);
|
|
|
|
|
|
|
|
/* we did get all the bits, take the MSB as well */
|
|
|
|
if (ext_capab_len >= 9)
|
|
|
|
val |= u8_get_bits(ext_capab[8],
|
|
|
|
WLAN_EXT_CAPA9_MAX_MSDU_IN_AMSDU_MSB) << 1;
|
|
|
|
|
|
|
|
if (val)
|
|
|
|
sta->sta.max_amsdu_subframes = 4 << val;
|
|
|
|
}
|
2022-09-02 17:12:52 +03:00
|
|
|
|
|
|
|
#ifdef CONFIG_LOCKDEP
|
|
|
|
bool lockdep_sta_mutex_held(struct ieee80211_sta *pubsta)
|
|
|
|
{
|
|
|
|
struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
|
|
|
|
|
|
|
|
return lockdep_is_held(&sta->local->sta_mtx);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(lockdep_sta_mutex_held);
|
|
|
|
#endif
|