02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
28 Apr, 2017
1 commit
-
Have proper request id filled in the SCHED_SCAN_RESULTS and
SCHED_SCAN_STOPPED notifications toward user-space by having the
driver provide it through the api.Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
Signed-off-by: Johannes Berg
27 Feb, 2017
1 commit
-
The issue was found when entering suspend and resume.
It triggers a warning in:
mac80211/key.c: ieee80211_enable_keys()
...
WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt ||
sdata->crypto_tx_tailroom_pending_dec);
...It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully
in a delayed_work during suspend. Add a flush_delayed_work to fix it.Cc: stable@vger.kernel.org
Signed-off-by: Matt Chen
Signed-off-by: Johannes Berg
13 Sep, 2016
1 commit
-
__ieee80211_suspend() checks early on if there's anything
to do by checking open_count, so there's no need to check
again later in the function. Remove the useless check.Signed-off-by: Johannes Berg
03 Nov, 2015
1 commit
-
Scheduled scan has to be reconfigured only if wowlan wasn't
configured, since otherwise it should continue to run (with
the 'any' trigger) or be aborted.The current code will end up asking the driver to start a new
scheduled scan without stopping the previous one, and leaking
some memory (from the previous request.)Fix this by doing the abort/restart under the proper conditions.
Signed-off-by: Eliad Peller
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
29 Sep, 2015
1 commit
-
In case of "any" wowlan trigger, there is no reason to tear down
aggregations, as we want the device to continue working normally.Similarly, there's no reason to tear down aggregations on resume,
as they should have been torn down on suspend if needed.
However, since the reconfiguration flow is shared with HW restart,
tear down aggregations on reconfiguration when we are not resuming.To keep things working after non-wowlan suspend, keep clearing the
WLAN_STA_BLOCK_BA flag.Signed-off-by: Eliad Peller
Signed-off-by: Luca Coelho
Signed-off-by: Johannes Berg
17 Jul, 2015
1 commit
-
If for any reason we're in the middle of PS-polling or awake after
TX due to dynamic powersave while going to suspend, go back to save
power. This might cause a response frame to get lost, but since we
can't really wait for it while going to suspend that's still better
than not enabling powersave which would cause higher power usage
during (and possibly even after) suspend.Note that this really only affects the very few drivers that use
the powersave implementation in mac80211.Signed-off-by: Chaitanya T K
[rewrite misleading commit log]
Signed-off-by: Johannes Berg
10 Jun, 2015
1 commit
-
As we're running out of hardware capability flags pretty quickly,
convert them to use the regular test_bit() style unsigned long
bitmaps.This introduces a number of helper functions/macros to set and to
test the bits, along with new debugfs code.The occurrences of an explicit __clear_bit() are intentional, the
drivers were never supposed to change their supported bits on the
fly. We should investigate changing this to be a per-frame flag.Signed-off-by: Johannes Berg
04 Mar, 2015
3 commits
-
If the driver rejects WoWLAN, restart the queues before returning
to cfg80211. cfg80211 will return to mac80211, but not before it
disconnects all interfaces. If we don't start the queues, any of
the packets needed for disconnecting won't be transmitted, which
is strange. Fix that.Signed-off-by: Johannes Berg
-
We check local->open_count at the top of the __ieee80211_suspend(), so
there's no need to check for it again. open_count is protected by the
rtnl, so there's no chance for it to have change between the two
calls.Signed-off-by: Luciano Coelho
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg -
Drivers can't really be expected to suspend properly while auth
or assoc is in progress since then they don't have any state
they could keep with WoWLAN, nor can they actually finish the
authentication or association. In fact, keeping this can cause
subtle issues with drivers like iwlwifi that refuse WoWLAN if
not associated, but have trouble figuring out what's going on
in the middle of association.In any case, regardless of possible driver issues in this area,
it doesn't make sense for mac80211 to try to WoWLAN-suspend in
the middle of such operations, so stop them before.Signed-off-by: Johannes Berg
28 Jan, 2015
1 commit
-
Conflicts:
arch/arm/boot/dts/imx6sx-sdb.dts
net/sched/cls_bpf.cTwo simple sets of overlapping changes.
Signed-off-by: David S. Miller
23 Jan, 2015
1 commit
-
In normal cases (i.e. when we are fully associated), cfg80211 takes
care of removing all the stations before calling suspend in mac80211.But in the corner case when we suspend during authentication or
association, mac80211 needs to roll back the station states. But we
shouldn't roll back the station states in the suspend function,
because this is taken care of in other parts of the code, except for
WDS interfaces. For AP types of interfaces, cfg80211 takes care of
disconnecting all stations before calling the driver's suspend code.
For station interfaces, this is done in the quiesce code.For WDS interfaces we still need to do it here, so move the code into
a new switch case for WDS.Cc: stable@kernel.org [3.15+]
Signed-off-by: Luciano Coelho
Signed-off-by: Johannes Berg
14 Jan, 2015
1 commit
-
When roaming / suspending, it makes no sense to wait until
the transmit queues of the device are empty. In extreme
condition they can be starved (VO saturating the air), but
even in regular cases, it is pointless to delay the roaming
because the low level driver is trying to send packets to
an AP which is far away. We'd rather drop these packets and
let TCP retransmit if needed. This will allow to speed up
the roaming.For suspend, the explanation is even more trivial.
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
23 Jun, 2014
1 commit
-
Sometimes different vifs may be stopping the queues for the same
reason (e.g. when several interfaces are performing a channel switch).
Instead of using a bitmask for the reasons, use an integer that holds
a refcount instead. In order to keep it backwards compatible,
introduce a boolean in some functions that tell us whether the queue
stopping should be refcounted or not. For now, use not refcounted for
all calls to keep it functionally the same as before.Signed-off-by: Luciano Coelho
Signed-off-by: Johannes Berg
20 Mar, 2014
1 commit
-
Since Stanislaw's patch removing the quiescing code, mac80211 had
a race regarding suspend vs. authentication: as cfg80211 doesn't
track authentication attempts, it can't abort them. Therefore the
attempts may be kept running while suspending, which can lead to
all kinds of issues, in at least some cases causing an error in
iwlmvm firmware.Fix this by aborting the authentication attempt when suspending.
Cc: stable@vger.kernel.org
Fixes: 12e7f517029d ("mac80211: cleanup generic suspend/resume procedures")
Signed-off-by: Johannes Berg
16 Dec, 2013
1 commit
-
If we can assume that stations are never referenced by the
driver after sta_state returns (and this is true since the
previous iwlmvm patch and for all other drivers) then we
don't need to delay station destruction, and don't need to
play tricks with rcu_barrier() etc.This should speed up some scenarios like hostapd shutdown.
Signed-off-by: Johannes Berg
23 Jul, 2013
1 commit
-
My commit:
commit 12e7f517029dad819c45eca9ca01fdb9ba57616b
Author: Stanislaw Gruszka
Date: Thu Feb 28 10:55:26 2013 +0100mac80211: cleanup generic suspend/resume procedures
removed check for deleting MONITOR and AP_VLAN when suspend. That can
cause a crash (i.e. in iwlagn_mac_remove_interface()) since we remove
interface in the driver that we did not add before.Reference:
http://marc.info/?l=linux-kernel&m=137391815113860&w=2Bisected-by: Ortwin Glück
Reported-and-tested-by: Ortwin Glück
Cc: stable@vger.kernel.org # 3.10
Signed-off-by: Stanislaw Gruszka
Signed-off-by: Johannes Berg
22 Apr, 2013
1 commit
-
The RCU docs used to state that rcu_barrier() included a wait
for an RCU grace period; however the comments for rcu_barrier()
as of commit f0a0e6f... "rcu: Clarify memory-ordering properties
of grace-period primitives" contradict this.So add back synchronize_{rcu,net}() to where they once were,
but keep the rcu_barrier()s for the call_rcu() callbacks.Cc: stable
Signed-off-by: Bob Copeland
Reviewed-by: Paul E. McKenney
Signed-off-by: Johannes Berg
17 Apr, 2013
1 commit
-
Since Stanislaw's patches, when suspending while connected,
cfg80211 will disconnect. This causes the AP station to be
removed, which uses call_rcu() to clean up. Due to needing
process context, this queues a work struct on the mac80211
workqueue. This will warn and fail when already suspended,
which can happen if the rcu call doesn't happen quickly.To fix this, replace the synchronize_net() which is really
just synchronize_rcu_expedited() with rcu_barrier(), which
unlike synchronize_rcu() waits until RCU callback have run
and thus avoids this issue.In theory, this can even happen without Stanislaw's change
to disconnect on suspend since userspace might disconnect
just before suspending, though then it's unlikely that the
call_rcu() will be delayed long enough.Cc: stable@vger.kernel.org [3.7+]
Signed-off-by: Johannes Berg
08 Apr, 2013
2 commits
-
It has to be removed from the driver, but completely
destroying it helps handle unplug of a device during
suspend since then the channel context handling etc.
doesn't have to happen later when it's removed.Signed-off-by: Johannes Berg
-
They can't really be executed while suspended and could
trigger work warnings, so abort all ROC items. When the
system resumes the notifications about this will be
delivered to userspace which can then act accordingly
(though it will assume they were canceled/finished.)Signed-off-by: Johannes Berg
19 Mar, 2013
2 commits
-
Sometimes queues are flushed in the middle of
operation, which can lead to driver issues.
Stop queues temporarily, while flushing, to
avoid transmitting new packets while they are
being flushed.Signed-off-by: Johannes Berg
-
There are a number of situations in which mac80211 only
really needs to flush queues for one virtual interface,
and in fact during this frames might be transmitted on
other virtual interfaces. Calculate and pass a queue
bitmap to the driver so it knows which queues to flush.Signed-off-by: Johannes Berg
06 Mar, 2013
2 commits
-
Since now we disconnect before suspend, various code which save
connection state can now be removed from suspend and resume
procedure. Cleanup on resume side is smaller as ieee80211_reconfig()
is also used for H/W restart.Signed-off-by: Stanislaw Gruszka
Signed-off-by: Johannes Berg -
If possible that after suspend, cfg80211 will receive request to
disconnect what require action on interface that was removed during
suspend.Problem can manifest itself by various warnings similar to below one:
WARNING: at net/mac80211/driver-ops.h:12 ieee80211_bss_info_change_notify+0x2f9/0x300 [mac80211]()
wlan0: Failed check-sdata-in-driver check, flags: 0x4
Call Trace:
[] warn_slowpath_fmt+0x33/0x40
[] ieee80211_bss_info_change_notify+0x2f9/0x300 [mac80211]
[] ieee80211_recalc_ps_vif+0x2a/0x30 [mac80211]
[] ieee80211_set_disassoc+0xf6/0x500 [mac80211]
[] ieee80211_mgd_deauth+0x1f1/0x280 [mac80211]
[] ieee80211_deauth+0x16/0x20 [mac80211]
[] cfg80211_mlme_down+0x70/0xc0 [cfg80211]
[] __cfg80211_disconnect+0x1b1/0x1d0 [cfg80211]To fix the problem disconnect from any associated network before
suspend. User space is responsible to establish connection again
after resume. This basically need to be done by user space anyway,
because associated stations can go away during suspend (for example
NetworkManager disconnects on suspend and connect on resume by default).Patch also handle situation when driver refuse to suspend with wowlan
configured and try to suspend again without it.Signed-off-by: Stanislaw Gruszka
Signed-off-by: Johannes Berg
15 Feb, 2013
1 commit
-
Add command to trigger radar detection in the driver/FW.
Once radar detection is started it should continuously
monitor for radars as long as the channel active.
If radar is detected usermode notified with 'radar
detected' event.Scanning and remain on channel functionality must be disabled
while doing radar detection/scanning, and vice versa.Based on original patch by Victor Goldenshtein
Signed-off-by: Simon Wunderlich
Signed-off-by: Johannes Berg
31 Jan, 2013
1 commit
-
When waking up from WoWLAN, it is useful to know
what triggered the wakeup. Support reporting the
wakeup reason(s) in cfg80211 (and a pass-through
in mac80211) to allow userspace to know.Signed-off-by: Johannes Berg
03 Jan, 2013
5 commits
-
The initiator/tx doesn't really identify why an
aggregation session is stopped, give a reason
for stopping that more clearly identifies what's
going on. This will help tell the driver clearly
what is expected of it.Signed-off-by: Johannes Berg
-
Instead of checking every time bss_info_changed is called,
assign the pointer once depending on the interface type
and then leave it untouched until the interface type is
changed. This makes the ieee80211_bss_info_change_notify()
now a simple wrapper to call the driver only.Signed-off-by: Johannes Berg
-
The special case in the function isn't really needed,
instead make the suspend code a bit better and also
easier to understand and move the warning into the
driver op wrapper inline.Signed-off-by: Johannes Berg
-
When suspending, bss_info_changed() is called to
disable beacons, but managed mode interfaces are
simply removed (bss_info_changed() is called with
"no change" only). This can lead to problems.To fix this and copy the BSS configuration, clear
it during suspend and restore it on resume.Signed-off-by: Johannes Berg
-
It's a bit odd that there's a return value that only
depends on the iftype, move that logic out of the
function into the only caller that needs it.Also, since the quiescing could stop timers that
trigger the sdata work, move the sdata work cancel
into the function and after the actual quiesce.Finally, there's no need to call it on interfaces
that are down, so don't.Change-Id: I1632d46d21ba3558ea713d035184f1939905f2f1
Signed-off-by: Johannes Berg
20 Nov, 2012
1 commit
-
Sujith reported warnings with suspend/resume due to
channel contexts. When I looked into it, I realised
that the code was completely broken as it unassigned
the channel contexts when suspending, which actually
means they are destroyed.Eliad Peller then pointed out that we also need to
remove the channel contexts from the driver. When I
looked into this, I also noticed that the code isn't
handling the virtual monitor interface correctly (if
it exists.)Fix this by calling just the driver methods (if they
are implemented) instead of using the channel context
management code. Also add reconfiguration for the
virtual monitor interface.Reported-by: Sujith Manoharan
Signed-off-by: Johannes Berg
26 Oct, 2012
1 commit
-
Depending on the driver, a lot of setup may be
necessary to start operating as an AP, some of
which may fail. Add an explicit AP start driver
method to make such failures easier to handle,
and add an AP stop driver method for symmetry.Signed-off-by: Johannes Berg
17 Oct, 2012
1 commit
-
Instead of operating on a single channel only,
use the new channel context infrastructure in
all mac80211 code.This enables drivers that want to use the new
channel context infrastructure to use multiple
channels, while nothing should change for all
the other drivers that don't support it.Right now this disables both TX power settings
and spatial multiplexing powersave. Both need
to be re-enabled on a channel context basis.Additionally, when channel contexts are used
drop the connection when channel switch is
received rather than trying to handle it. This
will have to be improved later.[With fixes from Eliad and Emmanuel incorporated]
Signed-off-by: Eliad Peller
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
20 Jun, 2012
1 commit
-
In case the driver suspend callback fails, mac80211 is left
with stopped queues which prevents any further traffic as well
as all STAs are left marked with WLAN_STA_BLOCK_BA which will
cause any further ADDBA requests to be declined. Fix it by
undoing both before returning from __iee80211_suspend.Reported-by: Vitaly Wool
Signed-off-by: Eyal Shapira
Signed-off-by: Johannes Berg
07 Jun, 2012
1 commit
-
drv_resume can get called without a prior call to drv_suspend.
Consider the following steps:1. Suspend is started but driver's drv_suspend returns error.
2. Suspend is aborted. local->wowlan flag is left set.
3. Interface is removed.
4. Suspend again. This time open_count is 0 so drv_suspend is
not called and local->wowlan not cleared.
5. On resume ieee80211_reconfig will call drv_resume since
local->wowlan is set.Signed-off-by: Pontus Fuchs
Signed-off-by: John W. Linville
12 Apr, 2012
1 commit
-
The queue mapping redesign that I'm planning to do
will break pure injection unless we handle monitor
interfaces explicitly. One possible option would
be to have the driver tell mac80211 about monitor
mode queues etc., but that would duplicate the API
since we already need to have queue assignments
handled per virtual interface.So in order to solve this, have a virtual monitor
interface that is added whenever all active vifs
are monitors. We could also use the state of one
of the monitor interfaces, but managing that would
be complicated, so allocate separate state.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville
28 Feb, 2012
1 commit
-
Use interface data from sta instead of invalid pointer
to list head in calls to drv_sta_state.Signed-off-by: Jakub Kicinski
Reviewed-by: Johannes Berg
Signed-off-by: John W. Linville
