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>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
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;
|
2009-12-23 20:15:40 +08:00
|
|
|
|
|
|
|
local->offchannel_ps_enabled = false;
|
|
|
|
|
|
|
|
/* 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) {
|
|
|
|
local->offchannel_ps_enabled = true;
|
|
|
|
local->hw.conf.flags &= ~IEEE80211_CONF_PS;
|
|
|
|
ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_PS);
|
|
|
|
}
|
|
|
|
|
2012-06-18 21:33:52 +08:00
|
|
|
if (!local->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
|
|
|
}
|
|
|
|
|
|
|
|
/* inform AP that we are awake again, unless power save is enabled */
|
|
|
|
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);
|
2009-12-23 20:15:40 +08:00
|
|
|
else if (local->offchannel_ps_enabled) {
|
|
|
|
/*
|
|
|
|
* In !IEEE80211_HW_PS_NULLFUNC_STACK case the hardware
|
|
|
|
* will send a nullfunc frame with the powersave bit set
|
|
|
|
* even though the AP already knows that we are sleeping.
|
|
|
|
* This could be avoided by sending a null frame with power
|
|
|
|
* save bit disabled before enabling the power save, but
|
|
|
|
* this doesn't gain anything.
|
|
|
|
*
|
|
|
|
* When IEEE80211_HW_PS_NULLFUNC_STACK is enabled, no need
|
|
|
|
* to send a nullfunc frame because AP already knows that
|
|
|
|
* we are sleeping, let's just enable power save mode in
|
|
|
|
* hardware.
|
|
|
|
*/
|
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
|
|
|
/* TODO: Only set hardware if CONF_PS changed?
|
|
|
|
* TODO: Should we set offchannel_ps_enabled to false?
|
|
|
|
*/
|
2009-12-23 20:15:40 +08:00
|
|
|
local->hw.conf.flags |= IEEE80211_CONF_PS;
|
|
|
|
ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_PS);
|
|
|
|
} else if (local->hw.conf.dynamic_ps_timeout > 0) {
|
|
|
|
/*
|
|
|
|
* If IEEE80211_CONF_PS was not set and 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.
|
|
|
|
*/
|
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;
|
|
|
|
|
2012-06-19 02:07:15 +08:00
|
|
|
if (sdata->vif.type == NL80211_IFTYPE_P2P_DEVICE)
|
|
|
|
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: 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_handle_roc_started(struct ieee80211_roc_work *roc)
|
|
|
|
{
|
|
|
|
if (roc->notified)
|
|
|
|
return;
|
|
|
|
|
|
|
|
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,
|
|
|
|
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: 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, *dep, *tmp;
|
2010-12-19 00:20:47 +08:00
|
|
|
|
|
|
|
mutex_lock(&local->mtx);
|
|
|
|
|
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 (list_empty(&local->roc_list))
|
|
|
|
goto out_unlock;
|
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
|
|
|
roc = list_first_entry(&local->roc_list, struct ieee80211_roc_work,
|
|
|
|
list);
|
|
|
|
|
|
|
|
if (!roc->started)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
roc->hw_begun = true;
|
|
|
|
roc->hw_start_time = local->hw_roc_start_time;
|
2010-12-19 00:20:48 +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
|
|
|
ieee80211_handle_roc_started(roc);
|
|
|
|
list_for_each_entry_safe(dep, tmp, &roc->dependents, list) {
|
|
|
|
ieee80211_handle_roc_started(dep);
|
|
|
|
|
|
|
|
if (dep->duration > roc->duration) {
|
|
|
|
u32 dur = dep->duration;
|
|
|
|
dep->duration = dur - roc->duration;
|
|
|
|
roc->duration = dur;
|
2012-09-06 13:20:53 +08:00
|
|
|
list_move(&dep->list, &roc->list);
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
out_unlock:
|
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: 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_start_next_roc(struct ieee80211_local *local)
|
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
|
|
|
struct ieee80211_roc_work *roc;
|
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: 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 (list_empty(&local->roc_list)) {
|
|
|
|
ieee80211_run_deferred_scan(local);
|
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
|
|
|
|
2012-06-21 02:11:33 +08:00
|
|
|
if (WARN_ON_ONCE(roc->started))
|
|
|
|
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
|
|
|
if (local->ops->remain_on_channel) {
|
|
|
|
int ret, duration = roc->duration;
|
2012-05-31 21:09:27 +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
|
|
|
/* XXX: duplicated, see ieee80211_start_roc_work() */
|
|
|
|
if (!duration)
|
|
|
|
duration = 10;
|
2012-05-31 21:09:27 +08:00
|
|
|
|
2012-11-19 23:05:09 +08:00
|
|
|
ret = drv_remain_on_channel(local, roc->sdata, roc->chan,
|
2013-02-12 15:34:13 +08:00
|
|
|
duration, roc->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
|
|
|
|
|
|
|
roc->started = true;
|
|
|
|
|
|
|
|
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
|
|
|
|
*/
|
|
|
|
ieee80211_remain_on_channel_expired(&local->hw);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* delay it a bit */
|
|
|
|
ieee80211_queue_delayed_work(&local->hw, &roc->work,
|
|
|
|
round_jiffies_relative(HZ/2));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-25 18:51:14 +08:00
|
|
|
void ieee80211_roc_notify_destroy(struct ieee80211_roc_work *roc, bool free)
|
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 *dep, *tmp;
|
|
|
|
|
2013-03-25 18:51:14 +08:00
|
|
|
if (WARN_ON(roc->to_be_freed))
|
|
|
|
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
|
|
|
/* was never transmitted */
|
|
|
|
if (roc->frame) {
|
2012-06-15 21:30:18 +08:00
|
|
|
cfg80211_mgmt_tx_status(&roc->sdata->wdev,
|
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
|
|
|
(unsigned long)roc->frame,
|
|
|
|
roc->frame->data, roc->frame->len,
|
|
|
|
false, GFP_KERNEL);
|
|
|
|
kfree_skb(roc->frame);
|
2012-05-31 21:09:27 +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
|
|
|
if (!roc->mgmt_tx_cookie)
|
2012-06-15 21:30:18 +08:00
|
|
|
cfg80211_remain_on_channel_expired(&roc->sdata->wdev,
|
2012-10-26 22:13:06 +08:00
|
|
|
roc->cookie, roc->chan,
|
2012-11-09 01:31:02 +08:00
|
|
|
GFP_KERNEL);
|
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
|
|
|
list_for_each_entry_safe(dep, tmp, &roc->dependents, list)
|
2013-03-25 18:51:14 +08:00
|
|
|
ieee80211_roc_notify_destroy(dep, 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
|
|
|
|
2013-03-25 18:51:14 +08:00
|
|
|
if (free)
|
|
|
|
kfree(roc);
|
|
|
|
else
|
|
|
|
roc->to_be_freed = 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_sw_roc_work(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct ieee80211_roc_work *roc =
|
|
|
|
container_of(work, struct ieee80211_roc_work, work.work);
|
|
|
|
struct ieee80211_sub_if_data *sdata = roc->sdata;
|
|
|
|
struct ieee80211_local *local = sdata->local;
|
2014-05-14 21:34:41 +08:00
|
|
|
bool started, on_channel;
|
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);
|
|
|
|
|
2013-03-25 18:51:14 +08:00
|
|
|
if (roc->to_be_freed)
|
|
|
|
goto out_unlock;
|
|
|
|
|
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->abort)
|
|
|
|
goto finish;
|
|
|
|
|
|
|
|
if (WARN_ON(list_empty(&local->roc_list)))
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
if (WARN_ON(roc != list_first_entry(&local->roc_list,
|
|
|
|
struct ieee80211_roc_work,
|
|
|
|
list)))
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
if (!roc->started) {
|
|
|
|
struct ieee80211_roc_work *dep;
|
|
|
|
|
2014-05-14 21:34:41 +08:00
|
|
|
WARN_ON(local->use_chanctx);
|
|
|
|
|
|
|
|
/* 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
|
|
|
|
|
|
|
/* tell userspace or send frame */
|
|
|
|
ieee80211_handle_roc_started(roc);
|
|
|
|
list_for_each_entry(dep, &roc->dependents, list)
|
|
|
|
ieee80211_handle_roc_started(dep);
|
|
|
|
|
|
|
|
/* if it was pure TX, just finish right away */
|
|
|
|
if (!roc->duration)
|
|
|
|
goto finish;
|
|
|
|
|
|
|
|
roc->started = true;
|
|
|
|
ieee80211_queue_delayed_work(&local->hw, &roc->work,
|
|
|
|
msecs_to_jiffies(roc->duration));
|
|
|
|
} else {
|
|
|
|
/* finish this ROC */
|
|
|
|
finish:
|
|
|
|
list_del(&roc->list);
|
2012-07-13 22:14:45 +08:00
|
|
|
started = roc->started;
|
2014-05-14 21:34:41 +08:00
|
|
|
on_channel = roc->on_channel;
|
2013-03-25 18:51:14 +08:00
|
|
|
ieee80211_roc_notify_destroy(roc, !roc->abort);
|
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
|
|
|
if (started && !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);
|
|
|
|
|
2012-07-13 22:14:45 +08:00
|
|
|
if (started)
|
2012-06-21 02:11:33 +08:00
|
|
|
ieee80211_start_next_roc(local);
|
2013-09-30 17:36:05 +08:00
|
|
|
else if (list_empty(&local->roc_list))
|
|
|
|
ieee80211_run_deferred_scan(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
|
|
|
}
|
|
|
|
|
|
|
|
out_unlock:
|
|
|
|
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);
|
|
|
|
struct ieee80211_roc_work *roc;
|
|
|
|
|
|
|
|
mutex_lock(&local->mtx);
|
|
|
|
|
|
|
|
if (list_empty(&local->roc_list))
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
roc = list_first_entry(&local->roc_list, struct ieee80211_roc_work,
|
|
|
|
list);
|
|
|
|
|
|
|
|
if (!roc->started)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
list_del(&roc->list);
|
|
|
|
|
2013-03-25 18:51:14 +08:00
|
|
|
ieee80211_roc_notify_destroy(roc, 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 there's another roc, start it now */
|
|
|
|
ieee80211_start_next_roc(local);
|
|
|
|
|
|
|
|
out_unlock:
|
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: 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: 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;
|
|
|
|
LIST_HEAD(tmp_list);
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
if (roc->started && local->ops->remain_on_channel) {
|
|
|
|
/* can race, so ignore return value */
|
|
|
|
drv_cancel_remain_on_channel(local);
|
|
|
|
}
|
|
|
|
|
|
|
|
list_move_tail(&roc->list, &tmp_list);
|
|
|
|
roc->abort = true;
|
|
|
|
}
|
|
|
|
mutex_unlock(&local->mtx);
|
|
|
|
|
|
|
|
list_for_each_entry_safe(roc, tmp, &tmp_list, list) {
|
|
|
|
if (local->ops->remain_on_channel) {
|
|
|
|
list_del(&roc->list);
|
2013-03-25 18:51:14 +08:00
|
|
|
ieee80211_roc_notify_destroy(roc, 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 {
|
|
|
|
ieee80211_queue_delayed_work(&local->hw, &roc->work, 0);
|
|
|
|
|
|
|
|
/* work will clean up etc */
|
|
|
|
flush_delayed_work(&roc->work);
|
2013-03-25 18:51:14 +08:00
|
|
|
WARN_ON(!roc->to_be_freed);
|
|
|
|
kfree(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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
WARN_ON_ONCE(!list_empty(&tmp_list));
|
2010-12-19 00:20:47 +08:00
|
|
|
}
|