2019-06-04 16:11:33 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2009-12-23 20:15:40 +08:00
|
|
|
/*
|
|
|
|
* Off-channel operation helpers
|
|
|
|
*
|
|
|
|
* Copyright 2003, Jouni Malinen <jkmaline@cc.hut.fi>
|
|
|
|
* Copyright 2004, Instant802 Networks, Inc.
|
|
|
|
* Copyright 2005, Devicescape Software, Inc.
|
|
|
|
* Copyright 2006-2007 Jiri Benc <jbenc@suse.cz>
|
|
|
|
* Copyright 2007, Michael Wu <flamingice@sourmilk.net>
|
|
|
|
* Copyright 2009 Johannes Berg <johannes@sipsolutions.net>
|
2019-07-24 02:00:01 +08:00
|
|
|
* Copyright (C) 2019 Intel Corporation
|
2009-12-23 20:15:40 +08:00
|
|
|
*/
|
2011-07-15 23:47:34 +08:00
|
|
|
#include <linux/export.h>
|
2009-12-23 20:15:40 +08:00
|
|
|
#include <net/mac80211.h>
|
|
|
|
#include "ieee80211_i.h"
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
#include "driver-ops.h"
|
2009-12-23 20:15:40 +08:00
|
|
|
|
|
|
|
/*
|
mac80211: Optimize scans on current operating channel.
This should decrease un-necessary flushes, on/off channel work,
and channel changes in cases where the only scanned channel is
the current operating channel.
* Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
and is-scanning flags instead.
* Add helper method to determine if we are currently configured
for the operating channel.
* Do no blindly go off/on channel in work.c Instead, only call
appropriate on/off code when we really need to change channels.
Always enable offchannel-ps mode when starting work,
and disable it when we are done.
* Consolidate ieee80211_offchannel_stop_station and
ieee80211_offchannel_stop_beaconing, call it
ieee80211_offchannel_stop_vifs instead.
* Accept non-beacon frames when scanning on operating channel.
* Scan state machine optimized to minimize on/off channel
transitions. Also, when going on-channel, go ahead and
re-enable beaconing. We're going to be there for 200ms,
so seems like some useful beaconing could happen.
Always enable offchannel-ps mode when starting software
scan, and disable it when we are done.
* Grab local->mtx earlier in __ieee80211_scan_completed_finish
so that we are protected when calling hw_config(), etc.
* Pass probe-responses up the stack if scanning on local
channel, so that mlme can take a look.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-02-05 03:54:17 +08:00
|
|
|
* Tell our hardware to disable PS.
|
|
|
|
* Optionally inform AP that we will go to sleep so that it will buffer
|
|
|
|
* the frames while we are doing off-channel work. This is optional
|
|
|
|
* because we *may* be doing work on-operating channel, and want our
|
|
|
|
* hardware unconditionally awake, but still let the AP send us normal frames.
|
2009-12-23 20:15:40 +08:00
|
|
|
*/
|
2012-06-18 21:33:52 +08:00
|
|
|
static void ieee80211_offchannel_ps_enable(struct ieee80211_sub_if_data *sdata)
|
2009-12-23 20:15:40 +08:00
|
|
|
{
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
2010-09-17 03:12:31 +08:00
|
|
|
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
|
2020-06-29 16:55:23 +08:00
|
|
|
bool offchannel_ps_enabled = false;
|
2009-12-23 20:15:40 +08:00
|
|
|
|
|
|
|
/* FIXME: what to do when local->pspolling is true? */
|
|
|
|
|
|
|
|
del_timer_sync(&local->dynamic_ps_timer);
|
2010-09-17 03:12:33 +08:00
|
|
|
del_timer_sync(&ifmgd->bcn_mon_timer);
|
2010-09-17 03:12:31 +08:00
|
|
|
del_timer_sync(&ifmgd->conn_mon_timer);
|
|
|
|
|
2009-12-23 20:15:40 +08:00
|
|
|
cancel_work_sync(&local->dynamic_ps_enable_work);
|
|
|
|
|
|
|
|
if (local->hw.conf.flags & IEEE80211_CONF_PS) {
|
2020-06-29 16:55:23 +08:00
|
|
|
offchannel_ps_enabled = true;
|
2009-12-23 20:15:40 +08:00
|
|
|
local->hw.conf.flags &= ~IEEE80211_CONF_PS;
|
|
|
|
ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_PS);
|
|
|
|
}
|
|
|
|
|
2020-06-29 16:55:23 +08:00
|
|
|
if (!offchannel_ps_enabled ||
|
2015-06-03 03:39:54 +08:00
|
|
|
!ieee80211_hw_check(&local->hw, PS_NULLFUNC_STACK))
|
2009-12-23 20:15:40 +08:00
|
|
|
/*
|
|
|
|
* If power save was enabled, no need to send a nullfunc
|
|
|
|
* frame because AP knows that we are sleeping. But if the
|
|
|
|
* hardware is creating the nullfunc frame for power save
|
|
|
|
* status (ie. IEEE80211_HW_PS_NULLFUNC_STACK is not
|
|
|
|
* enabled) and power save was enabled, the firmware just
|
|
|
|
* sent a null frame with power save disabled. So we need
|
|
|
|
* to send a new nullfunc frame to inform the AP that we
|
|
|
|
* are again sleeping.
|
|
|
|
*/
|
2015-09-24 22:14:55 +08:00
|
|
|
ieee80211_send_nullfunc(local, sdata, true);
|
2009-12-23 20:15:40 +08:00
|
|
|
}
|
|
|
|
|
2020-06-29 16:55:23 +08:00
|
|
|
/* inform AP that we are awake again */
|
2009-12-23 20:15:40 +08:00
|
|
|
static void ieee80211_offchannel_ps_disable(struct ieee80211_sub_if_data *sdata)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
|
|
|
|
if (!local->ps_sdata)
|
2015-09-24 22:14:55 +08:00
|
|
|
ieee80211_send_nullfunc(local, sdata, false);
|
2020-06-29 16:55:23 +08:00
|
|
|
else if (local->hw.conf.dynamic_ps_timeout > 0) {
|
2009-12-23 20:15:40 +08:00
|
|
|
/*
|
2020-06-29 16:55:23 +08:00
|
|
|
* the dynamic_ps_timer had been running before leaving the
|
|
|
|
* operating channel, restart the timer now and send a nullfunc
|
|
|
|
* frame to inform the AP that we are awake so that AP sends
|
|
|
|
* the buffered packets (if any).
|
2009-12-23 20:15:40 +08:00
|
|
|
*/
|
2015-09-24 22:14:55 +08:00
|
|
|
ieee80211_send_nullfunc(local, sdata, false);
|
2009-12-23 20:15:40 +08:00
|
|
|
mod_timer(&local->dynamic_ps_timer, jiffies +
|
|
|
|
msecs_to_jiffies(local->hw.conf.dynamic_ps_timeout));
|
|
|
|
}
|
2010-09-17 03:12:31 +08:00
|
|
|
|
2010-09-17 03:12:33 +08:00
|
|
|
ieee80211_sta_reset_beacon_monitor(sdata);
|
2010-09-17 03:12:31 +08:00
|
|
|
ieee80211_sta_reset_conn_monitor(sdata);
|
2009-12-23 20:15:40 +08:00
|
|
|
}
|
|
|
|
|
2012-12-20 21:41:18 +08:00
|
|
|
void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local)
|
2009-12-23 20:15:40 +08:00
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata;
|
|
|
|
|
2012-07-26 20:55:08 +08:00
|
|
|
if (WARN_ON(local->use_chanctx))
|
|
|
|
return;
|
|
|
|
|
mac80211: Optimize scans on current operating channel.
This should decrease un-necessary flushes, on/off channel work,
and channel changes in cases where the only scanned channel is
the current operating channel.
* Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
and is-scanning flags instead.
* Add helper method to determine if we are currently configured
for the operating channel.
* Do no blindly go off/on channel in work.c Instead, only call
appropriate on/off code when we really need to change channels.
Always enable offchannel-ps mode when starting work,
and disable it when we are done.
* Consolidate ieee80211_offchannel_stop_station and
ieee80211_offchannel_stop_beaconing, call it
ieee80211_offchannel_stop_vifs instead.
* Accept non-beacon frames when scanning on operating channel.
* Scan state machine optimized to minimize on/off channel
transitions. Also, when going on-channel, go ahead and
re-enable beaconing. We're going to be there for 200ms,
so seems like some useful beaconing could happen.
Always enable offchannel-ps mode when starting software
scan, and disable it when we are done.
* Grab local->mtx earlier in __ieee80211_scan_completed_finish
so that we are protected when calling hw_config(), etc.
* Pass probe-responses up the stack if scanning on local
channel, so that mlme can take a look.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-02-05 03:54:17 +08:00
|
|
|
/*
|
|
|
|
* notify the AP about us leaving the channel and stop all
|
|
|
|
* STA interfaces.
|
|
|
|
*/
|
2013-02-12 01:21:07 +08:00
|
|
|
|
2013-02-12 01:21:08 +08:00
|
|
|
/*
|
|
|
|
* Stop queues and transmit all frames queued by the driver
|
|
|
|
* before sending nullfunc to enable powersave at the AP.
|
|
|
|
*/
|
2013-02-13 19:25:28 +08:00
|
|
|
ieee80211_stop_queues_by_reason(&local->hw, IEEE80211_MAX_QUEUE_MAP,
|
2014-06-13 21:30:05 +08:00
|
|
|
IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL,
|
|
|
|
false);
|
2015-01-07 21:42:39 +08:00
|
|
|
ieee80211_flush_queues(local, NULL, false);
|
2013-02-12 01:21:07 +08:00
|
|
|
|
2009-12-23 20:15:40 +08:00
|
|
|
mutex_lock(&local->iflist_mtx);
|
|
|
|
list_for_each_entry(sdata, &local->interfaces, list) {
|
|
|
|
if (!ieee80211_sdata_running(sdata))
|
|
|
|
continue;
|
|
|
|
|
2016-09-20 22:31:14 +08:00
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_P2P_DEVICE ||
|
|
|
|
sdata->vif.type == NL80211_IFTYPE_NAN)
|
2012-06-19 02:07:15 +08:00
|
|
|
continue;
|
|
|
|
|
mac80211: Optimize scans on current operating channel.
This should decrease un-necessary flushes, on/off channel work,
and channel changes in cases where the only scanned channel is
the current operating channel.
* Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
and is-scanning flags instead.
* Add helper method to determine if we are currently configured
for the operating channel.
* Do no blindly go off/on channel in work.c Instead, only call
appropriate on/off code when we really need to change channels.
Always enable offchannel-ps mode when starting work,
and disable it when we are done.
* Consolidate ieee80211_offchannel_stop_station and
ieee80211_offchannel_stop_beaconing, call it
ieee80211_offchannel_stop_vifs instead.
* Accept non-beacon frames when scanning on operating channel.
* Scan state machine optimized to minimize on/off channel
transitions. Also, when going on-channel, go ahead and
re-enable beaconing. We're going to be there for 200ms,
so seems like some useful beaconing could happen.
Always enable offchannel-ps mode when starting software
scan, and disable it when we are done.
* Grab local->mtx earlier in __ieee80211_scan_completed_finish
so that we are protected when calling hw_config(), etc.
* Pass probe-responses up the stack if scanning on local
channel, so that mlme can take a look.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-02-05 03:54:17 +08:00
|
|
|
if (sdata->vif.type != NL80211_IFTYPE_MONITOR)
|
|
|
|
set_bit(SDATA_STATE_OFFCHANNEL, &sdata->state);
|
|
|
|
|
|
|
|
/* Check to see if we should disable beaconing. */
|
2012-12-14 21:06:28 +08:00
|
|
|
if (sdata->vif.bss_conf.enable_beacon) {
|
|
|
|
set_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED,
|
|
|
|
&sdata->state);
|
|
|
|
sdata->vif.bss_conf.enable_beacon = false;
|
2009-12-23 20:15:40 +08:00
|
|
|
ieee80211_bss_info_change_notify(
|
|
|
|
sdata, BSS_CHANGED_BEACON_ENABLED);
|
2012-12-14 21:06:28 +08:00
|
|
|
}
|
2009-12-23 20:15:40 +08:00
|
|
|
|
2013-02-12 01:21:07 +08:00
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_STATION &&
|
|
|
|
sdata->u.mgd.associated)
|
|
|
|
ieee80211_offchannel_ps_enable(sdata);
|
2009-12-23 20:15:40 +08:00
|
|
|
}
|
|
|
|
mutex_unlock(&local->iflist_mtx);
|
|
|
|
}
|
|
|
|
|
2012-12-20 21:41:18 +08:00
|
|
|
void ieee80211_offchannel_return(struct ieee80211_local *local)
|
2009-12-23 20:15:40 +08:00
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata;
|
|
|
|
|
2012-07-26 20:55:08 +08:00
|
|
|
if (WARN_ON(local->use_chanctx))
|
|
|
|
return;
|
|
|
|
|
2009-12-23 20:15:40 +08:00
|
|
|
mutex_lock(&local->iflist_mtx);
|
|
|
|
list_for_each_entry(sdata, &local->interfaces, list) {
|
2012-06-19 02:07:15 +08:00
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_P2P_DEVICE)
|
|
|
|
continue;
|
|
|
|
|
2011-12-23 07:48:06 +08:00
|
|
|
if (sdata->vif.type != NL80211_IFTYPE_MONITOR)
|
|
|
|
clear_bit(SDATA_STATE_OFFCHANNEL, &sdata->state);
|
|
|
|
|
2009-12-23 20:15:40 +08:00
|
|
|
if (!ieee80211_sdata_running(sdata))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Tell AP we're back */
|
2012-12-20 21:41:18 +08:00
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_STATION &&
|
|
|
|
sdata->u.mgd.associated)
|
|
|
|
ieee80211_offchannel_ps_disable(sdata);
|
2009-12-23 20:15:40 +08:00
|
|
|
|
2012-12-14 21:06:28 +08:00
|
|
|
if (test_and_clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED,
|
|
|
|
&sdata->state)) {
|
|
|
|
sdata->vif.bss_conf.enable_beacon = true;
|
2009-12-23 20:15:40 +08:00
|
|
|
ieee80211_bss_info_change_notify(
|
|
|
|
sdata, BSS_CHANGED_BEACON_ENABLED);
|
2012-12-14 21:06:28 +08:00
|
|
|
}
|
2009-12-23 20:15:40 +08:00
|
|
|
}
|
|
|
|
mutex_unlock(&local->iflist_mtx);
|
2013-02-12 01:21:07 +08:00
|
|
|
|
2013-02-13 19:25:28 +08:00
|
|
|
ieee80211_wake_queues_by_reason(&local->hw, IEEE80211_MAX_QUEUE_MAP,
|
2014-06-13 21:30:05 +08:00
|
|
|
IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL,
|
|
|
|
false);
|
2009-12-23 20:15:40 +08:00
|
|
|
}
|
2010-12-19 00:20:47 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
static void ieee80211_roc_notify_destroy(struct ieee80211_roc_work *roc)
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
{
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
/* was never transmitted */
|
|
|
|
if (roc->frame) {
|
|
|
|
cfg80211_mgmt_tx_status(&roc->sdata->wdev, roc->mgmt_tx_cookie,
|
|
|
|
roc->frame->data, roc->frame->len,
|
|
|
|
false, GFP_KERNEL);
|
|
|
|
ieee80211_free_txskb(&roc->sdata->local->hw, roc->frame);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!roc->mgmt_tx_cookie)
|
|
|
|
cfg80211_remain_on_channel_expired(&roc->sdata->wdev,
|
|
|
|
roc->cookie, roc->chan,
|
|
|
|
GFP_KERNEL);
|
2019-06-13 03:35:10 +08:00
|
|
|
else
|
|
|
|
cfg80211_tx_mgmt_expired(&roc->sdata->wdev,
|
|
|
|
roc->mgmt_tx_cookie,
|
|
|
|
roc->chan, GFP_KERNEL);
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
|
|
|
|
list_del(&roc->list);
|
|
|
|
kfree(roc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long ieee80211_end_finished_rocs(struct ieee80211_local *local,
|
|
|
|
unsigned long now)
|
|
|
|
{
|
|
|
|
struct ieee80211_roc_work *roc, *tmp;
|
|
|
|
long remaining_dur_min = LONG_MAX;
|
|
|
|
|
|
|
|
lockdep_assert_held(&local->mtx);
|
|
|
|
|
|
|
|
list_for_each_entry_safe(roc, tmp, &local->roc_list, list) {
|
|
|
|
long remaining;
|
|
|
|
|
|
|
|
if (!roc->started)
|
|
|
|
break;
|
|
|
|
|
|
|
|
remaining = roc->start_time +
|
|
|
|
msecs_to_jiffies(roc->duration) -
|
|
|
|
now;
|
|
|
|
|
2015-12-07 03:19:15 +08:00
|
|
|
/* In case of HW ROC, it is possible that the HW finished the
|
|
|
|
* ROC session before the actual requested time. In such a case
|
|
|
|
* end the ROC session (disregarding the remaining time).
|
|
|
|
*/
|
|
|
|
if (roc->abort || roc->hw_begun || remaining <= 0)
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
ieee80211_roc_notify_destroy(roc);
|
|
|
|
else
|
|
|
|
remaining_dur_min = min(remaining_dur_min, remaining);
|
|
|
|
}
|
|
|
|
|
|
|
|
return remaining_dur_min;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool ieee80211_recalc_sw_work(struct ieee80211_local *local,
|
|
|
|
unsigned long now)
|
|
|
|
{
|
|
|
|
long dur = ieee80211_end_finished_rocs(local, now);
|
|
|
|
|
|
|
|
if (dur == LONG_MAX)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
mod_delayed_work(local->workqueue, &local->roc_work, dur);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ieee80211_handle_roc_started(struct ieee80211_roc_work *roc,
|
|
|
|
unsigned long start_time)
|
|
|
|
{
|
|
|
|
if (WARN_ON(roc->notified))
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
return;
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
roc->start_time = start_time;
|
|
|
|
roc->started = true;
|
|
|
|
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
if (roc->mgmt_tx_cookie) {
|
|
|
|
if (!WARN_ON(!roc->frame)) {
|
2012-07-26 23:24:39 +08:00
|
|
|
ieee80211_tx_skb_tid_band(roc->sdata, roc->frame, 7,
|
2020-07-23 18:01:52 +08:00
|
|
|
roc->chan->band);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
roc->frame = NULL;
|
|
|
|
}
|
|
|
|
} else {
|
2012-10-26 22:13:06 +08:00
|
|
|
cfg80211_ready_on_channel(&roc->sdata->wdev, roc->cookie,
|
2012-11-09 01:31:02 +08:00
|
|
|
roc->chan, roc->req_duration,
|
|
|
|
GFP_KERNEL);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
roc->notified = true;
|
|
|
|
}
|
|
|
|
|
2010-12-19 00:20:47 +08:00
|
|
|
static void ieee80211_hw_roc_start(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local =
|
|
|
|
container_of(work, struct ieee80211_local, hw_roc_start);
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
struct ieee80211_roc_work *roc;
|
2010-12-19 00:20:47 +08:00
|
|
|
|
|
|
|
mutex_lock(&local->mtx);
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
list_for_each_entry(roc, &local->roc_list, list) {
|
|
|
|
if (!roc->started)
|
|
|
|
break;
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
|
2015-12-09 06:46:33 +08:00
|
|
|
roc->hw_begun = true;
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
ieee80211_handle_roc_started(roc, local->hw_roc_start_time);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
}
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
|
2010-12-19 00:20:47 +08:00
|
|
|
mutex_unlock(&local->mtx);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_ready_on_channel(struct ieee80211_hw *hw)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = hw_to_local(hw);
|
|
|
|
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
local->hw_roc_start_time = jiffies;
|
|
|
|
|
2010-12-19 00:20:47 +08:00
|
|
|
trace_api_ready_on_channel(local);
|
|
|
|
|
|
|
|
ieee80211_queue_work(hw, &local->hw_roc_start);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(ieee80211_ready_on_channel);
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
static void _ieee80211_start_next_roc(struct ieee80211_local *local)
|
2010-12-19 00:20:47 +08:00
|
|
|
{
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
struct ieee80211_roc_work *roc, *tmp;
|
|
|
|
enum ieee80211_roc_type type;
|
|
|
|
u32 min_dur, max_dur;
|
2010-12-19 00:20:47 +08:00
|
|
|
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
lockdep_assert_held(&local->mtx);
|
2010-12-19 00:20:47 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (WARN_ON(list_empty(&local->roc_list)))
|
2010-12-19 00:20:47 +08:00
|
|
|
return;
|
|
|
|
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
roc = list_first_entry(&local->roc_list, struct ieee80211_roc_work,
|
|
|
|
list);
|
2012-05-31 21:09:27 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (WARN_ON(roc->started))
|
2012-06-21 02:11:33 +08:00
|
|
|
return;
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
min_dur = roc->duration;
|
|
|
|
max_dur = roc->duration;
|
|
|
|
type = roc->type;
|
2012-05-31 21:09:27 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
list_for_each_entry(tmp, &local->roc_list, list) {
|
|
|
|
if (tmp == roc)
|
|
|
|
continue;
|
|
|
|
if (tmp->sdata != roc->sdata || tmp->chan != roc->chan)
|
|
|
|
break;
|
|
|
|
max_dur = max(tmp->duration, max_dur);
|
|
|
|
min_dur = min(tmp->duration, min_dur);
|
|
|
|
type = max(tmp->type, type);
|
|
|
|
}
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (local->ops->remain_on_channel) {
|
|
|
|
int ret = drv_remain_on_channel(local, roc->sdata, roc->chan,
|
|
|
|
max_dur, type);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
|
|
|
|
if (ret) {
|
|
|
|
wiphy_warn(local->hw.wiphy,
|
|
|
|
"failed to start next HW ROC (%d)\n", ret);
|
|
|
|
/*
|
|
|
|
* queue the work struct again to avoid recursion
|
|
|
|
* when multiple failures occur
|
|
|
|
*/
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
list_for_each_entry(tmp, &local->roc_list, list) {
|
|
|
|
if (tmp->sdata != roc->sdata ||
|
|
|
|
tmp->chan != roc->chan)
|
|
|
|
break;
|
|
|
|
tmp->started = true;
|
|
|
|
tmp->abort = true;
|
|
|
|
}
|
|
|
|
ieee80211_queue_work(&local->hw, &local->hw_roc_done);
|
|
|
|
return;
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
}
|
2014-05-14 21:34:41 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
/* we'll notify about the start once the HW calls back */
|
|
|
|
list_for_each_entry(tmp, &local->roc_list, list) {
|
|
|
|
if (tmp->sdata != roc->sdata || tmp->chan != roc->chan)
|
|
|
|
break;
|
|
|
|
tmp->started = true;
|
|
|
|
}
|
|
|
|
} else {
|
2014-05-14 21:34:41 +08:00
|
|
|
/* If actually operating on the desired channel (with at least
|
|
|
|
* 20 MHz channel width) don't stop all the operations but still
|
|
|
|
* treat it as though the ROC operation started properly, so
|
|
|
|
* other ROC operations won't interfere with this one.
|
|
|
|
*/
|
|
|
|
roc->on_channel = roc->chan == local->_oper_chandef.chan &&
|
|
|
|
local->_oper_chandef.width != NL80211_CHAN_WIDTH_5 &&
|
|
|
|
local->_oper_chandef.width != NL80211_CHAN_WIDTH_10;
|
2010-12-19 00:20:47 +08:00
|
|
|
|
2014-05-14 21:34:41 +08:00
|
|
|
/* start this ROC */
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
ieee80211_recalc_idle(local);
|
|
|
|
|
2014-05-14 21:34:41 +08:00
|
|
|
if (!roc->on_channel) {
|
|
|
|
ieee80211_offchannel_stop_vifs(local);
|
|
|
|
|
|
|
|
local->tmp_channel = roc->chan;
|
|
|
|
ieee80211_hw_config(local, 0);
|
|
|
|
}
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
ieee80211_queue_delayed_work(&local->hw, &local->roc_work,
|
|
|
|
msecs_to_jiffies(min_dur));
|
|
|
|
|
|
|
|
/* tell userspace or send frame(s) */
|
|
|
|
list_for_each_entry(tmp, &local->roc_list, list) {
|
|
|
|
if (tmp->sdata != roc->sdata || tmp->chan != roc->chan)
|
|
|
|
break;
|
|
|
|
|
|
|
|
tmp->on_channel = roc->on_channel;
|
|
|
|
ieee80211_handle_roc_started(tmp, jiffies);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_start_next_roc(struct ieee80211_local *local)
|
|
|
|
{
|
|
|
|
struct ieee80211_roc_work *roc;
|
|
|
|
|
|
|
|
lockdep_assert_held(&local->mtx);
|
|
|
|
|
|
|
|
if (list_empty(&local->roc_list)) {
|
|
|
|
ieee80211_run_deferred_scan(local);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-12-14 22:26:57 +08:00
|
|
|
/* defer roc if driver is not started (i.e. during reconfig) */
|
|
|
|
if (local->in_reconfig)
|
|
|
|
return;
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
roc = list_first_entry(&local->roc_list, struct ieee80211_roc_work,
|
|
|
|
list);
|
|
|
|
|
|
|
|
if (WARN_ON_ONCE(roc->started))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (local->ops->remain_on_channel) {
|
|
|
|
_ieee80211_start_next_roc(local);
|
|
|
|
} else {
|
|
|
|
/* delay it a bit */
|
|
|
|
ieee80211_queue_delayed_work(&local->hw, &local->roc_work,
|
|
|
|
round_jiffies_relative(HZ/2));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __ieee80211_roc_work(struct ieee80211_local *local)
|
|
|
|
{
|
|
|
|
struct ieee80211_roc_work *roc;
|
|
|
|
bool on_channel;
|
|
|
|
|
|
|
|
lockdep_assert_held(&local->mtx);
|
|
|
|
|
|
|
|
if (WARN_ON(local->ops->remain_on_channel))
|
|
|
|
return;
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
roc = list_first_entry_or_null(&local->roc_list,
|
|
|
|
struct ieee80211_roc_work, list);
|
|
|
|
if (!roc)
|
|
|
|
return;
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (!roc->started) {
|
|
|
|
WARN_ON(local->use_chanctx);
|
|
|
|
_ieee80211_start_next_roc(local);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
} else {
|
2014-05-14 21:34:41 +08:00
|
|
|
on_channel = roc->on_channel;
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (ieee80211_recalc_sw_work(local, jiffies))
|
|
|
|
return;
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
/* careful - roc pointer became invalid during recalc */
|
|
|
|
|
|
|
|
if (!on_channel) {
|
2015-01-07 21:42:39 +08:00
|
|
|
ieee80211_flush_queues(local, NULL, false);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
|
|
|
|
local->tmp_channel = NULL;
|
|
|
|
ieee80211_hw_config(local, 0);
|
|
|
|
|
2012-12-20 21:41:18 +08:00
|
|
|
ieee80211_offchannel_return(local);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ieee80211_recalc_idle(local);
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
ieee80211_start_next_roc(local);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
}
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
}
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
static void ieee80211_roc_work(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local =
|
|
|
|
container_of(work, struct ieee80211_local, roc_work.work);
|
|
|
|
|
|
|
|
mutex_lock(&local->mtx);
|
|
|
|
__ieee80211_roc_work(local);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
mutex_unlock(&local->mtx);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ieee80211_hw_roc_done(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local =
|
|
|
|
container_of(work, struct ieee80211_local, hw_roc_done);
|
|
|
|
|
|
|
|
mutex_lock(&local->mtx);
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
ieee80211_end_finished_rocs(local, jiffies);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
|
|
|
|
/* if there's another roc, start it now */
|
|
|
|
ieee80211_start_next_roc(local);
|
|
|
|
|
2010-12-19 00:20:47 +08:00
|
|
|
mutex_unlock(&local->mtx);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ieee80211_remain_on_channel_expired(struct ieee80211_hw *hw)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = hw_to_local(hw);
|
|
|
|
|
|
|
|
trace_api_remain_on_channel_expired(local);
|
|
|
|
|
|
|
|
ieee80211_queue_work(hw, &local->hw_roc_done);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(ieee80211_remain_on_channel_expired);
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
static bool
|
|
|
|
ieee80211_coalesce_hw_started_roc(struct ieee80211_local *local,
|
|
|
|
struct ieee80211_roc_work *new_roc,
|
|
|
|
struct ieee80211_roc_work *cur_roc)
|
2015-11-24 00:18:35 +08:00
|
|
|
{
|
|
|
|
unsigned long now = jiffies;
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
unsigned long remaining;
|
|
|
|
|
|
|
|
if (WARN_ON(!cur_roc->started))
|
|
|
|
return false;
|
2015-11-24 00:18:35 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
/* if it was scheduled in the hardware, but not started yet,
|
|
|
|
* we can only combine if the older one had a longer duration
|
|
|
|
*/
|
|
|
|
if (!cur_roc->hw_begun && new_roc->duration > cur_roc->duration)
|
2015-11-24 00:18:35 +08:00
|
|
|
return false;
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
remaining = cur_roc->start_time +
|
|
|
|
msecs_to_jiffies(cur_roc->duration) -
|
|
|
|
now;
|
|
|
|
|
2015-11-24 00:18:35 +08:00
|
|
|
/* if it doesn't fit entirely, schedule a new one */
|
|
|
|
if (new_roc->duration > jiffies_to_msecs(remaining))
|
|
|
|
return false;
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
/* add just after the current one so we combine their finish later */
|
|
|
|
list_add(&new_roc->list, &cur_roc->list);
|
|
|
|
|
|
|
|
/* if the existing one has already begun then let this one also
|
|
|
|
* begin, otherwise they'll both be marked properly by the work
|
|
|
|
* struct that runs once the driver notifies us of the beginning
|
|
|
|
*/
|
2015-12-09 06:46:33 +08:00
|
|
|
if (cur_roc->hw_begun) {
|
|
|
|
new_roc->hw_begun = true;
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
ieee80211_handle_roc_started(new_roc, now);
|
2015-12-09 06:46:33 +08:00
|
|
|
}
|
2015-11-24 00:18:35 +08:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ieee80211_start_roc_work(struct ieee80211_local *local,
|
|
|
|
struct ieee80211_sub_if_data *sdata,
|
|
|
|
struct ieee80211_channel *channel,
|
|
|
|
unsigned int duration, u64 *cookie,
|
|
|
|
struct sk_buff *txskb,
|
|
|
|
enum ieee80211_roc_type type)
|
|
|
|
{
|
|
|
|
struct ieee80211_roc_work *roc, *tmp;
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
bool queued = false, combine_started = true;
|
2015-11-24 00:18:35 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
lockdep_assert_held(&local->mtx);
|
|
|
|
|
2020-04-02 09:18:04 +08:00
|
|
|
if (channel->freq_offset)
|
|
|
|
/* this may work, but is untested */
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2015-11-24 00:18:35 +08:00
|
|
|
if (local->use_chanctx && !local->ops->remain_on_channel)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
roc = kzalloc(sizeof(*roc), GFP_KERNEL);
|
|
|
|
if (!roc)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the duration is zero, then the driver
|
|
|
|
* wouldn't actually do anything. Set it to
|
|
|
|
* 10 for now.
|
|
|
|
*
|
|
|
|
* TODO: cancel the off-channel operation
|
|
|
|
* when we get the SKB's TX status and
|
|
|
|
* the wait time was zero before.
|
|
|
|
*/
|
|
|
|
if (!duration)
|
|
|
|
duration = 10;
|
|
|
|
|
|
|
|
roc->chan = channel;
|
|
|
|
roc->duration = duration;
|
|
|
|
roc->req_duration = duration;
|
|
|
|
roc->frame = txskb;
|
|
|
|
roc->type = type;
|
|
|
|
roc->sdata = sdata;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* cookie is either the roc cookie (for normal roc)
|
|
|
|
* or the SKB (for mgmt TX)
|
|
|
|
*/
|
|
|
|
if (!txskb) {
|
|
|
|
roc->cookie = ieee80211_mgmt_tx_cookie(local);
|
|
|
|
*cookie = roc->cookie;
|
|
|
|
} else {
|
|
|
|
roc->mgmt_tx_cookie = *cookie;
|
|
|
|
}
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
/* if there's no need to queue, handle it immediately */
|
|
|
|
if (list_empty(&local->roc_list) &&
|
|
|
|
!local->scanning && !ieee80211_is_radar_required(local)) {
|
|
|
|
/* if not HW assist, just queue & schedule work */
|
|
|
|
if (!local->ops->remain_on_channel) {
|
|
|
|
list_add_tail(&roc->list, &local->roc_list);
|
|
|
|
ieee80211_queue_delayed_work(&local->hw,
|
|
|
|
&local->roc_work, 0);
|
|
|
|
} else {
|
|
|
|
/* otherwise actually kick it off here
|
|
|
|
* (for error handling)
|
|
|
|
*/
|
|
|
|
ret = drv_remain_on_channel(local, sdata, channel,
|
|
|
|
duration, type);
|
|
|
|
if (ret) {
|
|
|
|
kfree(roc);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
roc->started = true;
|
|
|
|
list_add_tail(&roc->list, &local->roc_list);
|
|
|
|
}
|
2015-11-24 00:18:35 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
return 0;
|
2015-11-24 00:18:35 +08:00
|
|
|
}
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
/* otherwise handle queueing */
|
2015-11-24 00:18:35 +08:00
|
|
|
|
|
|
|
list_for_each_entry(tmp, &local->roc_list, list) {
|
|
|
|
if (tmp->chan != channel || tmp->sdata != sdata)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
* Extend this ROC if possible: If it hasn't started, add
|
|
|
|
* just after the new one to combine.
|
2015-11-24 00:18:35 +08:00
|
|
|
*/
|
|
|
|
if (!tmp->started) {
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
list_add(&roc->list, &tmp->list);
|
2015-11-24 00:18:35 +08:00
|
|
|
queued = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (!combine_started)
|
|
|
|
continue;
|
2015-11-24 00:18:35 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (!local->ops->remain_on_channel) {
|
|
|
|
/* If there's no hardware remain-on-channel, and
|
|
|
|
* doing so won't push us over the maximum r-o-c
|
|
|
|
* we allow, then we can just add the new one to
|
|
|
|
* the list and mark it as having started now.
|
|
|
|
* If it would push over the limit, don't try to
|
|
|
|
* combine with other started ones (that haven't
|
|
|
|
* been running as long) but potentially sort it
|
|
|
|
* with others that had the same fate.
|
2015-11-24 00:18:35 +08:00
|
|
|
*/
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
unsigned long now = jiffies;
|
|
|
|
u32 elapsed = jiffies_to_msecs(now - tmp->start_time);
|
|
|
|
struct wiphy *wiphy = local->hw.wiphy;
|
|
|
|
u32 max_roc = wiphy->max_remain_on_channel_duration;
|
2015-11-24 00:18:35 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (elapsed + roc->duration > max_roc) {
|
|
|
|
combine_started = false;
|
|
|
|
continue;
|
|
|
|
}
|
2015-11-24 00:18:35 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
list_add(&roc->list, &tmp->list);
|
|
|
|
queued = true;
|
|
|
|
roc->on_channel = tmp->on_channel;
|
|
|
|
ieee80211_handle_roc_started(roc, now);
|
2015-12-08 20:16:41 +08:00
|
|
|
ieee80211_recalc_sw_work(local, now);
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
break;
|
2015-11-24 00:18:35 +08:00
|
|
|
}
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
|
|
|
|
queued = ieee80211_coalesce_hw_started_roc(local, roc, tmp);
|
|
|
|
if (queued)
|
|
|
|
break;
|
|
|
|
/* if it wasn't queued, perhaps it can be combined with
|
|
|
|
* another that also couldn't get combined previously,
|
|
|
|
* but no need to check for already started ones, since
|
|
|
|
* that can't work.
|
|
|
|
*/
|
|
|
|
combine_started = false;
|
2015-11-24 00:18:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!queued)
|
|
|
|
list_add_tail(&roc->list, &local->roc_list);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ieee80211_remain_on_channel(struct wiphy *wiphy, struct wireless_dev *wdev,
|
|
|
|
struct ieee80211_channel *chan,
|
|
|
|
unsigned int duration, u64 *cookie)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&local->mtx);
|
|
|
|
ret = ieee80211_start_roc_work(local, sdata, chan,
|
|
|
|
duration, cookie, NULL,
|
|
|
|
IEEE80211_ROC_TYPE_NORMAL);
|
|
|
|
mutex_unlock(&local->mtx);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ieee80211_cancel_roc(struct ieee80211_local *local,
|
|
|
|
u64 cookie, bool mgmt_tx)
|
|
|
|
{
|
|
|
|
struct ieee80211_roc_work *roc, *tmp, *found = NULL;
|
|
|
|
int ret;
|
|
|
|
|
2015-12-02 06:15:26 +08:00
|
|
|
if (!cookie)
|
|
|
|
return -ENOENT;
|
|
|
|
|
2017-08-18 20:33:57 +08:00
|
|
|
flush_work(&local->hw_roc_start);
|
|
|
|
|
2015-11-24 00:18:35 +08:00
|
|
|
mutex_lock(&local->mtx);
|
|
|
|
list_for_each_entry_safe(roc, tmp, &local->roc_list, list) {
|
|
|
|
if (!mgmt_tx && roc->cookie != cookie)
|
|
|
|
continue;
|
|
|
|
else if (mgmt_tx && roc->mgmt_tx_cookie != cookie)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
found = roc;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!found) {
|
|
|
|
mutex_unlock(&local->mtx);
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (!found->started) {
|
|
|
|
ieee80211_roc_notify_destroy(found);
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
2015-11-24 00:18:35 +08:00
|
|
|
|
|
|
|
if (local->ops->remain_on_channel) {
|
2019-07-24 02:00:01 +08:00
|
|
|
ret = drv_cancel_remain_on_channel(local, roc->sdata);
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (WARN_ON_ONCE(ret)) {
|
|
|
|
mutex_unlock(&local->mtx);
|
|
|
|
return ret;
|
2015-11-24 00:18:35 +08:00
|
|
|
}
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
/* TODO:
|
|
|
|
* if multiple items were combined here then we really shouldn't
|
|
|
|
* cancel them all - we should wait for as much time as needed
|
|
|
|
* for the longest remaining one, and only then cancel ...
|
|
|
|
*/
|
|
|
|
list_for_each_entry_safe(roc, tmp, &local->roc_list, list) {
|
|
|
|
if (!roc->started)
|
|
|
|
break;
|
|
|
|
if (roc == found)
|
|
|
|
found = NULL;
|
|
|
|
ieee80211_roc_notify_destroy(roc);
|
|
|
|
}
|
2015-11-24 00:18:35 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
/* that really must not happen - it was started */
|
|
|
|
WARN_ON(found);
|
2015-11-24 00:18:35 +08:00
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
ieee80211_start_next_roc(local);
|
2015-11-24 00:18:35 +08:00
|
|
|
} else {
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
/* go through work struct to return to the operating channel */
|
2015-11-24 00:18:35 +08:00
|
|
|
found->abort = true;
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
mod_delayed_work(local->workqueue, &local->roc_work, 0);
|
2015-11-24 00:18:35 +08:00
|
|
|
}
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
out_unlock:
|
|
|
|
mutex_unlock(&local->mtx);
|
|
|
|
|
2015-11-24 00:18:35 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ieee80211_cancel_remain_on_channel(struct wiphy *wiphy,
|
|
|
|
struct wireless_dev *wdev, u64 cookie)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
|
|
|
|
|
|
|
return ieee80211_cancel_roc(local, cookie, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
|
|
|
|
struct cfg80211_mgmt_tx_params *params, u64 *cookie)
|
|
|
|
{
|
|
|
|
struct ieee80211_sub_if_data *sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
2015-11-24 21:25:49 +08:00
|
|
|
struct sk_buff *skb;
|
2015-11-24 00:18:35 +08:00
|
|
|
struct sta_info *sta;
|
|
|
|
const struct ieee80211_mgmt *mgmt = (void *)params->buf;
|
|
|
|
bool need_offchan = false;
|
|
|
|
u32 flags;
|
|
|
|
int ret;
|
|
|
|
u8 *data;
|
|
|
|
|
|
|
|
if (params->dont_wait_for_ack)
|
|
|
|
flags = IEEE80211_TX_CTL_NO_ACK;
|
|
|
|
else
|
|
|
|
flags = IEEE80211_TX_INTFL_NL80211_FRAME_TX |
|
|
|
|
IEEE80211_TX_CTL_REQ_TX_STATUS;
|
|
|
|
|
|
|
|
if (params->no_cck)
|
|
|
|
flags |= IEEE80211_TX_CTL_NO_CCK_RATE;
|
|
|
|
|
|
|
|
switch (sdata->vif.type) {
|
|
|
|
case NL80211_IFTYPE_ADHOC:
|
|
|
|
if (!sdata->vif.bss_conf.ibss_joined)
|
|
|
|
need_offchan = true;
|
|
|
|
#ifdef CONFIG_MAC80211_MESH
|
2020-07-08 04:45:48 +08:00
|
|
|
fallthrough;
|
2015-11-24 00:18:35 +08:00
|
|
|
case NL80211_IFTYPE_MESH_POINT:
|
|
|
|
if (ieee80211_vif_is_mesh(&sdata->vif) &&
|
|
|
|
!sdata->u.mesh.mesh_id_len)
|
|
|
|
need_offchan = true;
|
|
|
|
#endif
|
2020-07-08 04:45:48 +08:00
|
|
|
fallthrough;
|
2015-11-24 00:18:35 +08:00
|
|
|
case NL80211_IFTYPE_AP:
|
|
|
|
case NL80211_IFTYPE_AP_VLAN:
|
|
|
|
case NL80211_IFTYPE_P2P_GO:
|
|
|
|
if (sdata->vif.type != NL80211_IFTYPE_ADHOC &&
|
|
|
|
!ieee80211_vif_is_mesh(&sdata->vif) &&
|
|
|
|
!rcu_access_pointer(sdata->bss->beacon))
|
|
|
|
need_offchan = true;
|
|
|
|
if (!ieee80211_is_action(mgmt->frame_control) ||
|
|
|
|
mgmt->u.action.category == WLAN_CATEGORY_PUBLIC ||
|
|
|
|
mgmt->u.action.category == WLAN_CATEGORY_SELF_PROTECTED ||
|
|
|
|
mgmt->u.action.category == WLAN_CATEGORY_SPECTRUM_MGMT)
|
|
|
|
break;
|
|
|
|
rcu_read_lock();
|
2016-10-03 19:14:15 +08:00
|
|
|
sta = sta_info_get_bss(sdata, mgmt->da);
|
2015-11-24 00:18:35 +08:00
|
|
|
rcu_read_unlock();
|
|
|
|
if (!sta)
|
|
|
|
return -ENOLINK;
|
|
|
|
break;
|
|
|
|
case NL80211_IFTYPE_STATION:
|
|
|
|
case NL80211_IFTYPE_P2P_CLIENT:
|
|
|
|
sdata_lock(sdata);
|
|
|
|
if (!sdata->u.mgd.associated ||
|
|
|
|
(params->offchan && params->wait &&
|
|
|
|
local->ops->remain_on_channel &&
|
|
|
|
memcmp(sdata->u.mgd.associated->bssid,
|
|
|
|
mgmt->bssid, ETH_ALEN)))
|
|
|
|
need_offchan = true;
|
|
|
|
sdata_unlock(sdata);
|
|
|
|
break;
|
|
|
|
case NL80211_IFTYPE_P2P_DEVICE:
|
|
|
|
need_offchan = true;
|
|
|
|
break;
|
2016-09-20 22:31:13 +08:00
|
|
|
case NL80211_IFTYPE_NAN:
|
2015-11-24 00:18:35 +08:00
|
|
|
default:
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* configurations requiring offchan cannot work if no channel has been
|
|
|
|
* specified
|
|
|
|
*/
|
|
|
|
if (need_offchan && !params->chan)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mutex_lock(&local->mtx);
|
|
|
|
|
|
|
|
/* Check if the operating channel is the requested channel */
|
|
|
|
if (!need_offchan) {
|
|
|
|
struct ieee80211_chanctx_conf *chanctx_conf;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
|
|
|
|
|
|
|
|
if (chanctx_conf) {
|
|
|
|
need_offchan = params->chan &&
|
|
|
|
(params->chan !=
|
|
|
|
chanctx_conf->def.chan);
|
|
|
|
} else if (!params->chan) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
rcu_read_unlock();
|
|
|
|
goto out_unlock;
|
|
|
|
} else {
|
|
|
|
need_offchan = true;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (need_offchan && !params->offchan) {
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
skb = dev_alloc_skb(local->hw.extra_tx_headroom + params->len);
|
|
|
|
if (!skb) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
skb_reserve(skb, local->hw.extra_tx_headroom);
|
|
|
|
|
networking: introduce and use skb_put_data()
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.
An spatch similar to the one for skb_put_zero() converts many
of the places using it:
@@
identifier p, p2;
expression len, skb, data;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_data(skb, data, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_data(skb, data, len);
)
(
p2 = (t2)p;
-memcpy(p2, data, len);
|
-memcpy(p, data, len);
)
@@
type t, t2;
identifier p, p2;
expression skb, data;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
)
(
p2 = (t2)p;
-memcpy(p2, data, sizeof(*p));
|
-memcpy(p, data, sizeof(*p));
)
@@
expression skb, len, data;
@@
-memcpy(skb_put(skb, len), data, len);
+skb_put_data(skb, data, len);
(again, manually post-processed to retain some comments)
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 20:29:20 +08:00
|
|
|
data = skb_put_data(skb, params->buf, params->len);
|
2015-11-24 00:18:35 +08:00
|
|
|
|
|
|
|
/* Update CSA counters */
|
|
|
|
if (sdata->vif.csa_active &&
|
|
|
|
(sdata->vif.type == NL80211_IFTYPE_AP ||
|
|
|
|
sdata->vif.type == NL80211_IFTYPE_MESH_POINT ||
|
|
|
|
sdata->vif.type == NL80211_IFTYPE_ADHOC) &&
|
|
|
|
params->n_csa_offsets) {
|
|
|
|
int i;
|
|
|
|
struct beacon_data *beacon = NULL;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
|
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_AP)
|
|
|
|
beacon = rcu_dereference(sdata->u.ap.beacon);
|
|
|
|
else if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
|
|
|
|
beacon = rcu_dereference(sdata->u.ibss.presp);
|
|
|
|
else if (ieee80211_vif_is_mesh(&sdata->vif))
|
|
|
|
beacon = rcu_dereference(sdata->u.mesh.beacon);
|
|
|
|
|
|
|
|
if (beacon)
|
|
|
|
for (i = 0; i < params->n_csa_offsets; i++)
|
|
|
|
data[params->csa_offsets[i]] =
|
2020-08-11 16:01:04 +08:00
|
|
|
beacon->cntdwn_current_counter;
|
2015-11-24 00:18:35 +08:00
|
|
|
|
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
|
|
|
|
|
|
|
IEEE80211_SKB_CB(skb)->flags = flags;
|
|
|
|
|
|
|
|
skb->dev = sdata->dev;
|
|
|
|
|
|
|
|
if (!params->dont_wait_for_ack) {
|
|
|
|
/* make a copy to preserve the frame contents
|
|
|
|
* in case of encryption.
|
|
|
|
*/
|
2015-11-24 21:25:49 +08:00
|
|
|
ret = ieee80211_attach_ack_skb(local, skb, cookie, GFP_KERNEL);
|
|
|
|
if (ret) {
|
2015-11-24 00:18:35 +08:00
|
|
|
kfree_skb(skb);
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* Assign a dummy non-zero cookie, it's not sent to
|
|
|
|
* userspace in this case but we rely on its value
|
|
|
|
* internally in the need_offchan case to distinguish
|
|
|
|
* mgmt-tx from remain-on-channel.
|
|
|
|
*/
|
|
|
|
*cookie = 0xffffffff;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!need_offchan) {
|
|
|
|
ieee80211_tx_skb(sdata, skb);
|
|
|
|
ret = 0;
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
IEEE80211_SKB_CB(skb)->flags |= IEEE80211_TX_CTL_TX_OFFCHAN |
|
|
|
|
IEEE80211_TX_INTFL_OFFCHAN_TX_OK;
|
|
|
|
if (ieee80211_hw_check(&local->hw, QUEUE_CONTROL))
|
|
|
|
IEEE80211_SKB_CB(skb)->hw_queue =
|
|
|
|
local->hw.offchannel_tx_hw_queue;
|
|
|
|
|
|
|
|
/* This will handle all kinds of coalescing and immediate TX */
|
|
|
|
ret = ieee80211_start_roc_work(local, sdata, params->chan,
|
|
|
|
params->wait, cookie, skb,
|
|
|
|
IEEE80211_ROC_TYPE_MGMT_TX);
|
|
|
|
if (ret)
|
|
|
|
ieee80211_free_txskb(&local->hw, skb);
|
|
|
|
out_unlock:
|
|
|
|
mutex_unlock(&local->mtx);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ieee80211_mgmt_tx_cancel_wait(struct wiphy *wiphy,
|
|
|
|
struct wireless_dev *wdev, u64 cookie)
|
|
|
|
{
|
|
|
|
struct ieee80211_local *local = wiphy_priv(wiphy);
|
|
|
|
|
|
|
|
return ieee80211_cancel_roc(local, cookie, true);
|
|
|
|
}
|
|
|
|
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
void ieee80211_roc_setup(struct ieee80211_local *local)
|
2010-12-19 00:20:47 +08:00
|
|
|
{
|
|
|
|
INIT_WORK(&local->hw_roc_start, ieee80211_hw_roc_start);
|
|
|
|
INIT_WORK(&local->hw_roc_done, ieee80211_hw_roc_done);
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
INIT_DELAYED_WORK(&local->roc_work, ieee80211_roc_work);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
INIT_LIST_HEAD(&local->roc_list);
|
|
|
|
}
|
|
|
|
|
2013-03-28 05:49:19 +08:00
|
|
|
void ieee80211_roc_purge(struct ieee80211_local *local,
|
|
|
|
struct ieee80211_sub_if_data *sdata)
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
{
|
|
|
|
struct ieee80211_roc_work *roc, *tmp;
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
bool work_to_do = false;
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
|
|
|
|
mutex_lock(&local->mtx);
|
|
|
|
list_for_each_entry_safe(roc, tmp, &local->roc_list, list) {
|
2013-03-28 05:49:19 +08:00
|
|
|
if (sdata && roc->sdata != sdata)
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
continue;
|
|
|
|
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (roc->started) {
|
|
|
|
if (local->ops->remain_on_channel) {
|
|
|
|
/* can race, so ignore return value */
|
2019-07-24 02:00:01 +08:00
|
|
|
drv_cancel_remain_on_channel(local, sdata);
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
ieee80211_roc_notify_destroy(roc);
|
|
|
|
} else {
|
|
|
|
roc->abort = true;
|
|
|
|
work_to_do = true;
|
|
|
|
}
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
} else {
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
ieee80211_roc_notify_destroy(roc);
|
mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.
This fixes a number of small issues with the ROC
implementation:
* offloaded remain-on-channel couldn't be queued,
now we can queue it as well, if needed
* in iwlwifi (the only user) offloaded ROC is
mutually exclusive with scanning, use the new
queue to handle that case -- I expect that it
will later depend on a HW flag
The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.
The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.
Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-05 20:28:42 +08:00
|
|
|
}
|
|
|
|
}
|
mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.
Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.
There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.
Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.
This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.
TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-11-24 06:53:51 +08:00
|
|
|
if (work_to_do)
|
|
|
|
__ieee80211_roc_work(local);
|
|
|
|
mutex_unlock(&local->mtx);
|
2010-12-19 00:20:47 +08:00
|
|
|
}
|