Merge tag 'mac80211-next-for-john-2014-08-29' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
Johannes Berg <johannes@sipsolutions.net> says:
"Not that much content this time. Some RCU cleanups, crypto
performance improvements, and various patches all over,
rather than listing them one might as well look into the
git log instead."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Conflicts:
drivers/net/wireless/ath/wil6210/wmi.c
Michal Kazior [Mon, 28 Jul 2014 13:16:59 +0000 (15:16 +0200)]
mac80211: fix chantype recalc warning
When a device driver is unloaded local->interfaces
list is cleared. If there was more than 1
interface running and connected (bound to a
chanctx) then chantype recalc was called and it
ended up with compat being NULL causing a call
trace warning.
Warn if compat becomes NULL as a result of
incompatible bss_conf.chandef of interfaces bound
to a given channel context only.
carl9170: tx: Replace rcu_assign_pointer() with RCU_INIT_POINTER()
According to RCU_INIT_POINTER()'s block comment 3.a, it can be used if
"3. The referenced data structure has already been exposed to readers either
at compile time or via rcu_assign_pointer() -and-
a. You have not made -any- reader-visible changes to this structure since
then".
This case fulfills the conditions above because between the rcu_dereference()
call (cvif = rcu_dereference(ar->beacon_iter);) and the rcu_assign_pointer()
call there is no update of the "cvif" variable.
Therefore, this patch makes the replacement.
The following Coccinelle semantic patch was used:
@@
identifier v;
@@
v = rcu_dereference(...);
... when != rcu_dereference(...);
when != v = ...;
when != (<+...v...+>)++;
when != \(memcpy\|memset\)(...);
(
- rcu_assign_pointer
+ RCU_INIT_POINTER
(..., v);
|
if(...) {
... when != v = ...;
- rcu_assign_pointer
+ RCU_INIT_POINTER
(..., v);
... when any
}
)
Because there are cases where between a “rcu_dereference()” call and a
“rcu_assign_pointer()” call might be updates of the value that interests us,
the Coccinelle semantic patch ignores them and replaces with
"RCU_INIT_POINTER()" only when the update is not happening.
Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith Manoharan [Sun, 24 Aug 2014 15:46:13 +0000 (21:16 +0530)]
ath9k: Fix channel context creation
If a new context is being added in addition to the current one,
then send the ASSIGN event to abort a running scan since
the addition of a context is usually followed by VIF
assignment and further operations.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith Manoharan [Sat, 23 Aug 2014 13:42:14 +0000 (19:12 +0530)]
ath9k: Remove redundant ifdef
This was introduced in an earlier patch to handle
a compilation warning, but since the channel context
code has been mostly isolated, this is not required now.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith Manoharan [Sat, 23 Aug 2014 07:59:23 +0000 (13:29 +0530)]
ath9k: Fix 'offchannel' in ath_softc
Finally move the 'offchannel' instance in ath_softc
inside a CONFIG_ATH9K_CHANNEL_CONTEXT cage. The offchannel
usage in ath9k_calculate_iter_data() is closed off with
an ifdef for now, since the state/opmode calculation is
common for both the channel context mode and the normal mode.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith Manoharan [Sat, 23 Aug 2014 07:59:22 +0000 (13:29 +0530)]
ath9k: Fix function argument type
ath9k_vif_iter() was earlier used as an iterator
routine when calling a mac80211 utility. This is no
longer the case and hence we can mention the argument
type explicitly.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith Manoharan [Sat, 23 Aug 2014 07:59:16 +0000 (13:29 +0530)]
ath9k: Fix channel context events
Check if channel context usage is enabled before
calling ath_chanctx_event() from various parts of the
driver. Also, make sure that ath_chanctx_event() is
compiled only when CONFIG_ATH9K_CHANNEL_CONTEXT is
enabled.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
The carl9170_op_ampdu_action() function is used only by the mac80211
framework.
Since the mac80211 already takes care of checks and properly serializing
calls to the driver's function there is no need for the driver to do the same
thing.
Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith Manoharan [Fri, 22 Aug 2014 15:09:31 +0000 (20:39 +0530)]
ath9k: Isolate ath9k_use_chanctx module parameter
This patch ensures that the module parameter "use_chanctx" is
visible only when CONFIG_ATH9K_CHANNEL_CONTEXT is selected.
Also register the channel context callbacks with mac80211 only
when it is explicitly enabled and compile them out of the driver
when CONFIG_ATH9K_CHANNEL_CONTEXT is not selected.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith Manoharan [Fri, 22 Aug 2014 15:09:28 +0000 (20:39 +0530)]
ath9k: Add a config option for channel context
Channel contexts are supported only for P2P right now,
so make sure that the 'normal' path remains unaffected
by using a config option. This will also reduce the size
of the driver.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bob Copeland [Fri, 22 Aug 2014 13:18:01 +0000 (09:18 -0400)]
ath5k: ensure led name is null terminated
Add the missing null termination after strncpy().
This isn't actually a buffer overflow in this case since we use
snprintf() appropriately to fill the buffer passed by the caller,
but in the interest of not turning this into a bug down the road,
go ahead and force termination here.
Found by Coverity.
Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rasmus Villemoes [Mon, 25 Aug 2014 07:59:29 +0000 (09:59 +0200)]
ray_cs: Add include guards
The files ray_cs.h and rayctl.h both contain two thirds of what
appears to be an include guard using the macro name RAYLINK_H (both
lack the #define). Since RAYLINK_H is not defined anywhere, the
#ifndefs are confusing no-ops. Add proper include guards using
different macro names.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Amitkumar Karwar [Tue, 19 Aug 2014 12:24:26 +0000 (08:24 -0400)]
mwifiex: use firmware API revision from GET_HW_SPEC response
Newer firmware returns API revision in GET_HW_SPEC command
response. We will make use of it instead of parsing this
information from FW release number.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Amitkumar Karwar [Tue, 19 Aug 2014 12:24:24 +0000 (08:24 -0400)]
mwifiex: fix left_len calculation issue
While updating 'left_len' in each iteration, we should subtract
last TLV length not the accumulated length of TLVs parsed till
now.
This bug in parsing logic is exposed by newer firmware which adds
two TLVs in GET_HW_SPEC command response. Earlier firmwares used to
add only one TLV.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Csaba Kiraly [Sun, 17 Aug 2014 23:53:34 +0000 (01:53 +0200)]
ath9k_htc: advertise support for TDLS
Based on a quick test with AR9271, TDLS seems to be working fine.
Tests were done with 2 Atheros AR9271 based devices with firmware
1.3 (sha1 8d49f928aa40ac53c729189bff1333cd373a7fb5), associated
with a WAP54G access point. TDLS worked fine both in WPA2 mode and
without encryption. Stations maintained ping flood traffic between
each other and towards the AP without significant losses.
mac80211: Replace rcu_dereference() with rcu_access_pointer()
The "rcu_dereference()" calls are used directly in conditions.
Since their return values are never dereferenced it is recommended to
use "rcu_access_pointer()" instead of "rcu_dereference()".
Therefore, this patch makes the replacements.
The following Coccinelle semantic patch was used:
@@
@@
mac80211: scan: Replace rcu_assign_pointer() with RCU_INIT_POINTER()
The use of "rcu_assign_pointer()" is NULLing out the pointer.
According to RCU_INIT_POINTER()'s block comment:
"1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.
The following Coccinelle semantic patch was used:
@@
@@
Johannes Berg [Tue, 12 Aug 2014 19:01:28 +0000 (21:01 +0200)]
cfg80211: allow passing frame type to cfg80211_inform_bss()
When using the cfg80211_inform_bss[_width]() functions drivers
cannot currently indicate whether the data was received in a
beacon or probe response. Fix that by passing a new enum that
indicates such (or unknown).
For good measure, use it in ath6kl.
Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath6kl] Acked-by: Arend van Spriel <arend@broadcom.com> [brcmfmac] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 12 Aug 2014 18:34:30 +0000 (20:34 +0200)]
cfg80211: clarify BSS probe response vs. beacon data
There are a few possible cases of where BSS data came from:
1) only a beacon has been received
2) only a probe response has been received
3) the driver didn't report what it received (this happens when
using cfg80211_inform_bss[_width]())
4) both probe response and beacon data has been received
Unfortunately, in the userspace API, a few things weren't there:
a) there was no way to differentiate cases 1) and 4) above
without comparing the data of the IEs
b) the TSF was always from the last frame, instead of being
exposed for beacon/probe response separately like IEs
Fix this by
i) exporting a new flag attribute that indicates whether or
not probe response data has been received - this addresses (a)
ii) exporting a BEACON_TSF attribute that holds the beacon's TSF
if a beacon has been received
iii) not exporting the beacon attributes in case (3) above as that
would just lead userspace into thinking the data actually came
from a beacon when that isn't clear
To implement this, track inside the IEs struct whether or not it
(definitely) came from a beacon.
Reported-by: William Seto Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Header-less cloned skbs with sufficient headroom need not be cloned
unless the tailroom is going to be modified.
Fix ieee80211_skb_resize so it would only resize cloned skbs if either
the header isn't released or the tailroom is going to be modified.
Some drivers might have assumed that skbs are never cloned, so add a HW
flag that explicitly permits cloned TX skbs. Drivers which do not modify
TX skbs should set this flag to avoid copying skbs.
mac80211: Fix accounting of the tailroom-needed counter
When hw acceleration is enabled, the GENERATE_IV or PUT_IV_SPACE flags
will only require headroom space. Consequently, the tailroom-needed
counter can safely be decremented.
ieee80211: Support parsing TPC report element in action frames
TPC report element is contained in spectrum management's tpc report
action frames and in radio measurement's link measurement report
action frames. Add a function which checks whether an action frame
contains this element. This may be needed by the drivers in order
to set the correct tx power value in these frames.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: remove @gfp parameter from cfg80211_rx_mgmt()
In the cfg80211_rx_mgmt(), parameter @gfp was used for the memory allocation.
But, memory get allocated under spin_lock_bh(), this implies atomic context.
So, one can't use GFP_KERNEL, only variants with no __GFP_WAIT. Actually, in all
occurrences GFP_ATOMIC is used (wil6210 use GFP_KERNEL by mistake),
and it should be this way or warning triggered in the memory allocation code.
Remove @gfp parameter as no actual choice exist, and use hard coded
GFP_ATOMIC for memory allocation.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Himangi Saraogi <himangi774@gmail.com> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Himangi Saraogi [Wed, 13 Aug 2014 17:10:24 +0000 (22:40 +0530)]
atmel_cs: Remove typedef local_info_t
The Linux kernel coding style guidelines suggest not using typedefs
for structure types. This patch gets rid of the typedef for
local_info_t. Also, the name of the struct is changed to drop the _t,
to make the name look less typedef-like.
The following Coccinelle semantic patch detects the case:
@tn@
identifier i;
type td;
@@
-typedef
struct i { ... }
-td
;
@@
type tn.td;
identifier tn.i;
@@
-td
+ struct i
Signed-off-by: Himangi Saraogi <himangi774@gmail.com> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently it can send regulatory domain change notification before any
NEW_WIPHY notification. Moreover, if rfill_register() fails, calling
wiphy_unregister() will send a DEL_WIPHY though no NEW_WIPHY had been
sent previously.
Thus reordering so it properly notifies NEW_WIPHY before any other.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Himangi Saraogi [Thu, 7 Aug 2014 11:02:45 +0000 (16:32 +0530)]
wireless: wlcore: Use devm_kzalloc
This patch introduces the use of devm_kzalloc and does away with the
kfrees in the probe and remove functions. Also, a couple of labels and
the initial assignment of the ret variable in the probe function are
removed.
Signed-off-by: Himangi Saraogi <himangi774@gmail.com> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Define tables for similar file entries, i.e.
- table for debugfs_create_file
- table for static parameters
- table for parameters that are members of "wil" structure
- table for blobs
- table for interrupt controllers
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
wil6210: wait longer for hardware reset completion
Typical time for hardware reset, as measured, is about 200..250 msec.
Adjust sleeping to use more relaxed msleep, increase sleep interval
and increase total sleep time to be about 1sec
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
When resetting target in wil_target_reset(), error may occur.
Indicate error via error code. In case of error, don't attempt to further
interact with card, specifically don't attempt firmware download or
interrupts enabling.
Move wil_rx_fini() to be always executed to prevent memory leak.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Himangi Saraogi [Sat, 2 Aug 2014 14:52:46 +0000 (20:22 +0530)]
cw1200: Introduce the use of devm_kzalloc
This patch introduces the use of devm_kzalloc and does away with the
kfrees in the probe and remove functions.
Signed-off-by: Himangi Saraogi <himangi774@gmail.com> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: John W. Linville <linville@tuxdriver.com>
b43: implement PPR (Power Per Rate) management/API
Broadcom hardware supports auto-adjustment of TX power depending on the
currently used rate. So far all calculations were handled without any
helpers (API) using big arrays and magic offsets.
It seems Broadcom recently decided to clean this up by developing PPR.
Their wlc_ppr.h can be found in open parts of the SDK.
As we plan to implement support for rate-based TX power it makes sense
to also implement our version of PPR as well.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rafał Miłecki [Thu, 7 Aug 2014 05:45:37 +0000 (07:45 +0200)]
b43: flush some writes on Broadcom MIPS SoCs
Access to PHY and radio registers is indirect on Broadcom hardware and
it seems that addressing on some MIPS SoCs may require flushing. So far
this problem was noticed on 0x4716 SoC only (marketing names: BCM4717,
BCM4718).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Most of the PHYs use the same way of accessing registers, so move that
code to the shared place. An exception is G-PHY which sometimes access
A-PHY regs and requires special handling.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Michal Kazior [Fri, 22 Aug 2014 12:33:18 +0000 (14:33 +0200)]
ath10k: flush hif buffers before recovery
Transport buffers weren't flushed and processed
before queueing hw recovery request to mac80211.
This could in theory result in an unwanted htt/wmi
rx events being processed while mac80211 recovers
the device and possibly interfere or even crash
the system.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>