iwlwifi features a debug mechanism that allows to dump
binary data which is helpful to debug the firmware.
Until now, this data was made available for the userspace
through debugfs. For this exact purpose, devcoredump was
created. Move to the new infrastructure.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

These chips support STBC in both Tx and Rx.
Given that we've added STBC Tx support enable it.
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Precedence of & and >> is not the same and is not left to right.
shift has higher precedence and should be done after the mask.

Add parentheses around the mask.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

We used to need to include some headers in order to read the registers
and do all the calculations by ourselves, but this is not done anymore
(i.e. we let the firmware do this for us), so we don't need to include
those headers anymore.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

For WMM-AC we may have to be changing QoS parameters while the
queues are being flushed. This is not relevant in the "drop"
case, but matters when we wait for the device to finish the
transmissions.

To allow this, do the actual waiting without holding the mutex.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The warning gives no information about the frame, and presents
the flags so that one might think they're the frame. Clarify
and add more information.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This makes it easier to tune the values during the testing.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

It is unused and won't be available in some future invocations of the
function.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The MVM_FW_BCAST_FILTER_PASS_ALL option defined in iwl-dbg-cfg.ini
configuration file allows to enable/disable FW broadcast filtering.

If MVM_FW_BCAST_FILTER_PASS_ALL is not defined in iwl-dbg-cfg.ini or
its value is 0, the mvm broadcast filtering is enabled.

Setting MVM_FW_BCAST_FILTER_PASS_ALL=1 in iwl-dbg-cfg.ini blocks sending
of BCAST_FILTER_CMD to FW.
Signed-off-by: NMax Stepanov <Max.Stepanov@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This is were it really needs to be.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In the new format the "CSS section" has the same TLV type
as the "mem section". So we need to run the secured flow
for all the 8000 products.
Signed-off-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When the ARC is reset when we exit from Sx in case we had
WoWLAN running, we can't access the prph before we reset
the NIC.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Otherwise we have no way to know that the buffer hasn't been
allocated.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

A few slave bus devices show better performance when we
reduce the size of the Tx A-MPDU.
Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Getting the BSS station vif is something that may be needed by other
parts of the code.  So, instead of having an iterator specifically for
d3, change it into a generic one in utils.c.  Additionally, add a
iwl_mvm_get_bss_vif() function to make it easier to retrieving it.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Before we get all the chain (ie. mac80211, cfg80211, nl80211 and
userspace) changed to support net-detect, we can use this debugfs
entry for easy testing and as a proof of concept.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The net-detect feature will require a scan offload to be started in
the same way it is done now for scheduled scan.  Spin a new function
off of the sched_scan_start op code for reuse.  Additionally,
restructure the function a bit for more readability.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Instead of checking if we are associated when suspending with wowlan
enabled in the interface iterator, allow it to return an unassociated
vif and move the check to the main suspend function.  This will be
needed by netdetect, since it should also work when we are not
associated but the vif is active.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Take the WoWLAN handling code out of the main suspend function,
dividing it into three parts: get_config (which is used before the
firmware is switched), switch_to_d3 (which handles the rebooting of
the hardware with the D3 firmware) and config (which configures the D3
firmware for WoWLAN operation).  This is necessary to prepare for the
net-detect implementation, which will use only the switch_to_d3 part
of this flow.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

We use ieee80211_iter_keys() which requires the rtnl to be held.  If
we don't lock the rtnl, like we do when we suspend during a d3 test,
we get the following splat:

 RTNL: assertion failed at net/mac80211/key.c (566)
 CPU: 1 PID: 26529 Comm: cat Tainted: G        W  O 3.10.29-dev #1
 Hardware name: Dell Inc. Latitude E6430/0CPWYR, BIOS A09 12/13/2012
  e7b15008 e7b15008 e68adc1c c168aa62 e68adc54 f91f20b6 f923700c f9236fd8
  00000236 00000000 ece23874 00000000 f94941e0 00000000 e43b8e48 e7b15008
  00000000 e8b69e78 e68adcc0 f9493ab9 e68adc68 00000000 e43b8e48 e7b15008
 Call Trace:
  [<c168aa62>] dump_stack+0x16/0x18
  [<f91f20b6>] ieee80211_iter_keys+0x166/0x170 [mac80211]
  [<f94941e0>] ? iwl_mvm_query_wakeup_reasons+0x5f0/0x5f0 [iwlmvm]
  [<f9493ab9>] iwl_mvm_setup_connection_keep.isra.5+0x99/0x1d0 [iwlmvm]
  [<f9165e28>] ? cfg80211_report_wowlan_wakeup+0x308/0x510 [cfg80211]
  [<f9493fe5>] iwl_mvm_query_wakeup_reasons+0x3f5/0x5f0 [iwlmvm]
  [<c116125a>] ? init_object+0x3a/0x70
  [<f8a5b8ee>] ? iwl_trans_pcie_d3_resume+0x1be/0x3a0 [iwlwifi]
  [<f94956da>] __iwl_mvm_resume+0x14a/0x180 [iwlmvm]
  [<f9495736>] iwl_mvm_d3_test_release+0x26/0xc0 [iwlmvm]
  [<c117a64d>] __fput+0xad/0x210
  [<c117a7bd>] ____fput+0xd/0x10
  [<c10601a1>] task_work_run+0x81/0xb0
  [<c1040fa5>] do_exit+0x255/0xac0
  [<c104e511>] ? dequeue_signal+0x31/0x1a0
  [<c1041888>] do_group_exit+0x38/0xa0
  [<c10a6cfb>] ? trace_hardirqs_on+0xb/0x10
  [<c1051c31>] get_signal_to_deliver+0x1e1/0x8e0
  [<c104bd52>] ? try_to_del_timer_sync+0x42/0x60
  [<c104bd70>] ? try_to_del_timer_sync+0x60/0x60
  [<c168dc82>] ? schedule_timeout+0x102/0x2a0
  [<c10011ba>] do_signal+0x3a/0x8e0
  [<c104b190>] ? __internal_add_timer+0xb0/0xb0
  [<c168de7a>] ? schedule_timeout_interruptible+0x1a/0x20
  [<c104ce39>] ? msleep_interruptible+0x39/0x40
  [<f94939a9>] ? iwl_mvm_d3_test_read+0x49/0x70 [iwlmvm]
  [<c11797fc>] ? vfs_read+0x8c/0x160
  [<c11243af>] ? SyS_fadvise64_64+0x15f/0x2b0
  [<f9493960>] ? iwl_mvm_wowlan_program_keys+0x4a0/0x4a0 [iwlmvm]
  [<c1179a57>] ? SyS_read+0x57/0xa0
  [<c1001acf>] do_notify_resume+0x6f/0xa0
  [<c1692500>] work_notifysig+0x29/0x31

Fix this by hold the rtnl lock when calling __iwl_mvm_resume() in the
d3 test wake up path.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

mac80211 will never call rate_control_tx_status with a NULL
pointer for sta. Remove the superfluous check. This check
misled smatch.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The current TLC isn't optimized for low latency and some devices
have issues with MIMO. This kind of combo creates latency issues.
Allow to temporarily disable MIMO for tests in order to solve
the latency issues without the added complexity of MIMO.
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

iwl_poll_bit may return a strictly positive value when the
poll doesn't match on the first try.
This was caught when WoWLAN started failing upon resume
even if the poll_bit actually succeeded.

Also change a wrong print. If we reach the end of
iwl_pcie_prepare_card_hw, it means that we couldn't
get the devices.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This reverts commit aa11bbf3.
This commit was causing connection issues and is not needed
if IWL_MVM_RS_RSSI_BASED_INIT_RATE is set to false by default.

Regardless of the issues mentioned above, this patch added the
following WARNING:

WARNING: CPU: 0 PID: 3946 at drivers/net/wireless/iwlwifi/mvm/tx.c:190 iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]()
Got an HT rate for a non data frame 0x8
CPU: 0 PID: 3946 Comm: wpa_supplicant Tainted: G           O   3.17.0+ #6
Hardware name: LENOVO 20ANCTO1WW/20ANCTO1WW, BIOS GLET71WW (2.25 ) 07/02/2014
 0000000000000009 ffffffff814fa911 ffff8804288db8f8 ffffffff81064f52
 0000000000001808 ffff8804288db948 ffff88040add8660 ffff8804291b5600
 0000000000000000 ffffffff81064fb7 ffffffffa07b73d0 0000000000000020
Call Trace:
 [<ffffffff814fa911>] ? dump_stack+0x41/0x51
 [<ffffffff81064f52>] ? warn_slowpath_common+0x72/0x90
 [<ffffffff81064fb7>] ? warn_slowpath_fmt+0x47/0x50
 [<ffffffffa07a39ea>] ? iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]
 [<ffffffffa07a3cf8>] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm]
 [<ffffffffa079cb9b>] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm]
 [<ffffffffa0746ce9>] ? __ieee80211_tx+0x2b9/0x3c0 [mac80211]
 [<ffffffffa07492f3>] ? ieee80211_tx+0xb3/0x100 [mac80211]
 [<ffffffffa0749c49>] ? ieee80211_subif_start_xmit+0x459/0xca0 [mac80211]
 [<ffffffff814116e7>] ? dev_hard_start_xmit+0x337/0x5f0
 [<ffffffff81430d46>] ? sch_direct_xmit+0x96/0x1f0
 [<ffffffff81411ba3>] ? __dev_queue_xmit+0x203/0x4f0
 [<ffffffff8142f670>] ? ether_setup+0x70/0x70
 [<ffffffff814e96a1>] ? packet_sendmsg+0xf81/0x1110
 [<ffffffff8140625c>] ? skb_free_datagram+0xc/0x40
 [<ffffffff813f7538>] ? sock_sendmsg+0x88/0xc0
 [<ffffffff813f7274>] ? move_addr_to_kernel.part.20+0x14/0x60
 [<ffffffff811c47c2>] ? __inode_wait_for_writeback+0x62/0xb0
 [<ffffffff813f7a91>] ? SYSC_sendto+0xf1/0x180
 [<ffffffff813f88f9>] ? __sys_recvmsg+0x39/0x70
 [<ffffffff8150066d>] ? system_call_fastpath+0x1a/0x1f
---[ end trace cc19a150d311fc63 ]---

which was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=85691

CC: <stable@vger.kernel.org> [3.13+]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When mac80211 wants to ensure that a frame is sent, it calls
the flush() callback. Until now, iwldvm implemented this by
waiting that all the frames are sent (ACKed or timeout).
In case of weak signal, this can take a significant amount
of time, delaying the next connection (in case of roaming).
Many users have reported that the flush would take too long
leading to the following error messages to be printed:

iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2
iwlwifi 0000:03:00.0: Current SW read_ptr 161 write_ptr 201
iwl data: 00000000: 00 00 00 00 00 00 00 00 fe ff 01 00 00 00 00 00
[snip]
iwlwifi 0000:03:00.0: FH TRBs(0) = 0x00000000
[snip]
iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [9,9]
[snip]

Instead of waiting for these packets, simply drop them. This
significantly improves the responsiveness of the network.
Note that all the queues are flushed, but the VO one. This
is not typically used by the applications and it likely
contains management frames that are useful for connection
or roaming.

This bug is tracked here:
https://bugzilla.kernel.org/show_bug.cgi?id=56581

But it is duplicated in distributions' trackers.
A simple search in Ubuntu's database led to these bugs:

https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1270808
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305406
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356236
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1360597
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361809

Cc: <stable@vger.kernel.org>
Depends-on: 77be2c54 ("mac80211: add vif to flush call")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Don't add the time event to the list. We added it several
times the same time event, which leads to an infinite loop
when walking the list.

Since we (currently) don't support more than one ROC for STA
vif at a time, enforce this and don't add the time event
to any list.

We were also missing the locking of the mutex which led to
a lockdep splat - fix that.
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The tx power should be limited from many reasons.
currently, setting the tx power is available by the mvm only for
station interface. Adding the tx power condition to
bss_info_changed_ap_ibss make it available also for AP.
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The probe requests sent during scan must get BT prio 3.
Fix that.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Cc: <stable@vger.kernel.org> [3.16+]
Fixes: 2adc8949 ("iwlwifi: mvm: BT Coex - fix boost register / LUT values")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

I changed the string but forgot to update the fix also to
MODULE_FIRMWARE().
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The LTR is the handshake between the device and the root
complex about the latency allowed when the bus exits power
save. This configuration was missing and this led to high
latency in the link power up. The end user could experience
high latency in the network because of this.

Cc: <stable@vger.kernel.org> [3.10+]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Indenting errors yielded the following static checker warnings:

drivers/net/wireless/rtlwifi/rtl8192ee/hw.c:533 rtl92ee_set_hw_reg() warn: add curly braces? (if)
drivers/net/wireless/rtlwifi/rtl8192ee/hw.c:539 rtl92ee_set_hw_reg() warn: add curly braces? (if)

An unreleased version of the static checker also reported:

drivers/net/wireless/rtlwifi/rtl8723be/trx.c:550 rtl8723be_rx_query_desc() warn: 'hdr' can't be NULL.
drivers/net/wireless/rtlwifi/rtl8188ee/trx.c:621 rtl88ee_rx_query_desc() warn: 'hdr' can't be NULL.
drivers/net/wireless/rtlwifi/rtl8192ee/trx.c:567 rtl92ee_rx_query_desc() warn: 'hdr' can't be NULL.
drivers/net/wireless/rtlwifi/rtl8821ae/trx.c:758 rtl8821ae_rx_query_desc() warn: 'hdr' can't be NULL.
drivers/net/wireless/rtlwifi/rtl8723ae/trx.c:494 rtl8723e_rx_query_desc() warn: 'hdr' can't be NULL.
drivers/net/wireless/rtlwifi/rtl8192se/trx.c:315 rtl92se_rx_query_desc() warn: 'hdr' can't be NULL.
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c:392 rtl92ce_rx_query_desc() warn: 'hdr' can't be NULL.

All of these are fixed.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The driver needs btcoexist, but Kconfig fails to select it. This omission
could cause build errors for some configurations.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When we are attempting to switch to a new
channel context, the TX queues are flushed, but
the mac80211 queues are not stopped and traffic
can still come down to the driver.

This patch fixes it by stopping the queues
assigned to the current context/vif before
trying to flush.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When a full chip reset is done, all the queues
across all VIFs are stopped, but if MCC is enabled,
only the queues of the current context is awakened,
when we complete the reset.

This results in unfairness for the inactive context.
Since frames are queued internally in the driver if
there is a context mismatch, we can awaken all the
queues when coming out of a reset.

The VIF-specific queues are still used in flow control,
to ensure fairness when traffic is high.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This can be used when the queues of a context
needs to be stopped.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Change the ath9k_chanctx_wake_queues() API so
that we can pass the channel context that needs its
queues to be stopped.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When draining of the TX queues fails, a
full HW reset is done. ath_reset() makes sure
that the queues in mac80211 are restarted,
so there is no need to wake them up again.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k_has_tx_pending() can be used to
check if there are pending frames instead
of having duplicate code.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Checking for the queue depth outside of
the TX queue lock is incorrect and in this
case, is not required since it is done inside
ath9k_has_pending_frames().
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>