On !CONFIG_SMP builds spin_is_locked always returns 0. Assert the
locking using assert_spin_locked, which is written to behave correctly
in all cases.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

report the average beacon rssi which is calculated
by firmware for roaming statistics instead of the
last rx packet rssi. this results a more accurate
rssi reporting
Signed-off-by: NNadim Zubidat <nadimz@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Accumulate the total number of sent packets per-link to find out how far
the encryption sequence number has progressed. Use this number as the
initial security sequence number after recovery.

This consolidates security sequence handling for both chip families, as
we no longer have to rely on 12xx specific Tx completion.

A fortunate side effect of this is correct management of seq numbers for
AP roles and multi-role scenarios.

When a link is removed we save the last seq number on a persistent part
of the wlvif. This helps the data survive through recoveries/suspends,
which also entail changes in the hlid of the link.

This functionality is STA only currently.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The HLID of a STA can change, particularly during recovery. Don't cache
the HLID before it was potentially allocated.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

commit 144614f3eebd7d only allowed a single active link when
turning on the optimization, ignoring the fact that an AP has two
additional global links.
Use 3 links as an indication for a single active link. Use the
FW PSM bits to verify the extra active link belongs to the AP role.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Maximum number of supported RX BA sessions depends on chip type.
wl18xx supports 5 RX BA sessions while wl12xx supports 3.
Signed-off-by: NIgal Chernobelsky <igalc@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

It is requiered to enter sleep mode with smaller delay in forced PS mode.
This fixes issue of testing force PS mode during VoIP traffic where packets
are sent every 20ms. Chip never enters ps mode with default 30 ms delay
in such test.
Signed-off-by: NIgal Chernobelsky <igalc@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Even in failed case of pm_runtime_get_sync, the usage_count
is incremented. In order to keep the usage_count with correct
value and runtime power management to behave correctly, call
pm_runtime_put(_sync) in such case.

Signed-off-by Liu Chuansheng <chuansheng.liu@intel.com>
Signed-off-by: NLi Fei <fei.li@intel.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

When memory allocation using, kmalloc() fails, report appropriate error value.
Signed-off-by: NKumar Amit Mehta <gmate.amit@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes an instance of DMA buffer on stack(being passed to
usb_control_msg) for the wireless USB version of the Agere Orinoco card driver.
It also fixes the missing audit for the return value of firmware download
routine. Found using smatch.
Signed-off-by: NKumar Amit Mehta <gmate.amit@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rtlwifi allocates both setup_packet and data buffer of control message urb,
using shared kmalloc in _usbctrl_vendorreq_async_write. Structure used for
allocating is:
	struct {
		u8 data[254];
		struct usb_ctrlrequest dr;
	};

Because 'struct usb_ctrlrequest' is __packed, setup packet is unaligned and
DMA mapping of both 'data' and 'dr' confuses ARM/sunxi, leading to memory
corruptions and freezes.

Patch changes setup packet to be allocated separately.

[v2]:
 - Use WARN_ON_ONCE instead of WARN_ON

Cc: <stable@vger.kernel.org>
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For STA mode, collect VHT realated IEs from the Beacons or Probe
Responses and append similar VHT related IEs to association
requests.

For AP mode, get VHT related capability information and share it
with cfg80211 at the time of wiphy register. This information is
further used by cfg80211 and hostapd to start an AP with 802.11AC
support.

Currently only 8897 supports 802.11AC.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NFrank Huang <frankh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

They all can make one line.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While unloading driver, we free all pending TX packets by flushing
TX ring. There is unhandled case for PCIE8897 while checking for
ring empty condition.

This patch adds the handling by calling mwifiex_pcie_txbd_empty().
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I removed a bit too much info last time.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Theoretically, the card may not enter CTKILL:
In case the timer that iwl_prepare_ct_kill_task is setting,
will expire before tt->state revert to its previous state.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The time event data structures are required also for P2P Device
interface.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The FW can differentiate between scans, according to the interface
type on which the scan was issues. Supply the interfaces type
information to the FW.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Occasionally, we would run into this warning:

  iwlwifi 0000:02:00.0: U iwl_mvm_protect_session extend 0x2601: only 200 ms left
  iwlwifi 0000:02:00.0: U iwl_mvm_remove_time_event Removing TE 0x2601
  iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0925, 60 bytes at 37[5]:9
  iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0926, 60 bytes at 38[6]:9
  iwlwifi 0000:02:00.0: U iwl_mvm_time_event_response TIME_EVENT_CMD response - UID = 0x2601
  iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: U iwl_mvm_rx_time_event_notif Time event notification - UID = 0x2701 action 1
  wlan0: associate with 00:0a:b8:55:a8:30 (try 2/3)
  ------------[ cut here ]------------
  WARNING: at drivers/net/wireless/iwlwifi/mvm/time-event.c:269 iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]()
  Modules linked in: [...]
  Call Trace:
   [<c1046e42>] warn_slowpath_common+0x72/0xa0
   [<c1046e92>] warn_slowpath_null+0x22/0x30
   [<f8cad913>] iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]
   [<f8cadead>] iwl_mvm_protect_session+0xcd/0x1c0 [iwlmvm]
   [<f8ca2087>] iwl_mvm_mac_mgd_prepare_tx+0x67/0xa0 [iwlmvm]
   [<f882a130>] ieee80211_sta_work+0x8f0/0x1070 [mac80211]

The reason is a problem with asynchronous vs. synchronous
commands, what happens here is the following:
 * TE 0x2601 is removed, the TIME_EVENT_CMD for that is async
 * a new TE (will be 0x2701) is created, the TIME_EVENT_CMD
   for that is sync and also uses a notification wait for the
   response (to avoid another race condition)
 * the response for the TE 0x2601 removal comes from the
   firmware, and is handled by the notification wait handler
   that's really waiting for the second response, but can't
   tell the difference, we therefore see the message
   "TIME_EVENT_CMD response - UID = 0x2601" instead of
   "TIME_EVENT_CMD response - UID = 0x2701".

Fix this issue by making the TE removal synchronous as well,
this means that we wait for the response to that command
first, before there's any chance of sending a new one.

Also, to detect such issues more easily in the future, add
a warning to the notification handler that detects them.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is helpful for debugging the time event warning,
but also in general to see what's going on.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

All station commands must include a valid MAC ID,
the ID 0 is randomly valid in some cases, but we
must set the ID properly. Do that by passing the
right station and using its mac_id_n_color.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For the firmware to know when DTIM beacons arrive
we have to program the DTIM time in TSF and system
time in the MAC context. Since mac80211 now tracks
the different times (on demand), this becomes easy.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The iwlwifi-next tree removed IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC
while the mac80211-next tree removed
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Larry noticed (and bisected) that commit df881293
"cfg80211: Pass TDLS peer's QoS/HT/VHT information during set_station"
broke secure connections. This is is the case only for drivers that
don't support TDLS, where any kind of change, even just the change of
authorized flag that is required for normal operation, was rejected
now. To fix this, remove the checks. I have some patches that will add
proper verification for all the different cases later.

Cc: Jouni Malinen <j@w1.fi>
Bisected-by: NLarry Finger <Larry.Finger@lwfinger.net>
Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If mesh plink debugging is enabled, this gets annoying in
a crowded environment, fast.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Convert mesh peering events into strings and make the
debug output a little easier to read. Also stop printing
the llid and plid since these don't change across peering
states and are random numbers anyway so they just amount
to noise.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

ieee80211_ht_cap_ie_to_sta_ht_cap() will clean up the
ht_supported flag and station bandwidth field for us
if the peer beacon doesn't have an HT capability element
(is operating as non-HT).

Also, we don't really need a special station ch_width
member to track the station operating mode any more so use
sta.bandwidth instead.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If an interface is set down while authenticating or
associating, there's a station entry that will be
removed by the flushing in do_stop() and that will
cause a warning. It's otherwise harmless, but avoid
the warning by calling ieee80211_mgd_stop() first.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Update the 802.11 book to list the correct
data structures.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Several tracepoints are using STA_PR_FMT where STA_PR_ARG should be
used, resulting in messages like "phy0 sta:ARG TYPE NOT FIELD BUT 1".
Change these to STA_PR_ARG.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since mesh powersaving was added, pending bcast/mcast frames may go out the
CAB queue now.  Unfortunately, the queue was only set up for AP mode, so we
would try to tx on the IEEE80211_INVAL_HW_QUEUE.  Allow cab_queue for mesh
interfaces as well.

Fixes the following warning (or crash without MAC80211_VERBOSE_DEBUG):

WARNING: at net/mac80211/tx.c:1223 __ieee80211_tx+0x162/0x35f [mac80211]()
Modules linked in: mac80211_hwsim mac80211 cfg80211 [...]
Pid: 3085, comm: avahi-daemon Tainted: G        W    3.8.0-rc1+ #377
Call Trace:
 [<ffffffff81045c20>] warn_slowpath_common+0x83/0x9c
 [<ffffffff81045c53>] warn_slowpath_null+0x1a/0x1c
 [<ffffffffa083aef0>] __ieee80211_tx+0x162/0x35f [mac80211]
 [<ffffffffa083cb1d>] ieee80211_tx+0xd3/0xf9 [mac80211]
 [<ffffffffa083cc0f>] ieee80211_xmit+0xcc/0xd5 [mac80211]
 [<ffffffffa083db59>] ieee80211_subif_start_xmit+0xc53/0xcd8 [mac80211]
 [<ffffffff81319acd>] dev_hard_start_xmit+0x259/0x3ce
 [<ffffffff81333d6b>] sch_direct_xmit+0x74/0x17d
 [<ffffffff8131a0b1>] dev_queue_xmit+0x230/0x414
 [<ffffffff8134877a>] ip_finish_output2+0x348/0x3aa
 [<ffffffff81349029>] ip_finish_output+0x6c/0x71
 [<ffffffff81349046>] NF_HOOK_COND.constprop.44+0x18/0x58
 [<ffffffff8134a03a>] ip_mc_output+0x134/0x13c
 [<ffffffff8134835a>] dst_output+0x18/0x1c
 [<ffffffff81349a24>] ip_local_out+0x20/0x24
 [<ffffffff8134a8cf>] ip_send_skb+0x16/0x3c
 [<ffffffff8136bfba>] udp_send_skb+0x254/0x2b9
 [<ffffffff8136c85e>] udp_sendmsg+0x5a8/0x7d4
Signed-off-by: NBob Copeland <bob@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's various code with strange indentation,
questionable loop and locking constructs, etc.

The bigger change is moving the "sdata" argument
to the first argument of all functions, like all
other mac80211 functions that have one.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Otherwise memory corruption occurs when using channel contexts (ATM when
param 'channel' > 1).
Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Even when connecting to an AP that doesn't support VHT,
and even when the local device doesn't support it either,
the downgrade message gets printed. Suppress the message
if HT and/or VHT is disabled.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Adding the flag to mac80211 already without testing was
clearly a mistake, one that we now pay for by having to
reserve bit 13 forever. The problem is cfg80211 doesn't
allow capability/rate changes for station entries that
were added unassociated, so the station entries cannot
be set up properly when marked associated.

Change the NL80211_FEATURE_FULL_AP_CLIENT_STATE value
to make it clear to userspace implementations that all
current kernels don't actually support it, even though
the previous bit is set, and of course also remove the
flag from mac80211 until we test and fix the issues.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>