Move the TX PN assignment (for CCMP only) to the driver. This prepares
the driver for future DSO (driver segmentation offload) where it will
split an SKB into multiple MPDUs by itself.

For TDLS, split out the CCMP TX command handling so that it won't get
a PN assigned, the firmware assigns the PN in that case.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In iwl_mvm_tx_skb_non_sta(), in case of managed interface,
use the AP station for multicast frames instead of the auxiliary
station as otherwise the frames can be sent to an absent P2P GO as
the FW does not block transmissions for the auxiliary station
since it is not associated with the station MAC context.

Note that this is not possible for unicast frames, as a TDLS
discovery response is sent without a station entry, and in this
case the P2P GO NoA should not block transmission to the peer.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In the mvm driver, neither the old command nor the return value
are used, so remove them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When BT is active, we want to avoid the shared antenna for
management frame to make sure we don't disturb BT. There
was a bug in that code because it chose the antenna
BIT(ANT_A) where ANT_A is already a bitmap (0x1). This
means that the antenna chosen in the end was ANT_B.
While this is not optimal on devices with 2 antennas (it'd
disturb BT), it is critical on single antenna devices like
3160 which couldn't connect at all when BT was active.

This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=97181

CC: <stable@vger.kernel.org> [3.17+]
Fixes: 34c8b24f ("iwlwifi: mvm: BT Coex - avoid the shared antenna for management frames")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Currently, loading the firmware fails when it has higher API or CAPA
bits than the driver supports. That's an issue with integration.

At the same time, actually using api[0] and capa[0] will become
confusing when we also have api[1] and capa[1], and it's almost
certain that we'll mix up the bits and use the bits for api[1] with
api[0] by accident.

Avoid all this by translating the API/CAPA bits to the regular kernel
test_bit() format, and also providing wrapper functions. Also use the
__bitwise__ facility of sparse to check that we're testing the right
one.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

BlockAck sessions can have events that are interesting to
debug. When we send or receive a BAR, it is may indicate
that something bad is happening. Even more so when mac80211
tells us that a frame timed out in the reodering buffer.
Add a few triggers for BlockAck session debugging.
Allow per-TID debugging.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware frequently manages to trigger this, and there's
no known driver workaround, so stop warning.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

There are transport that must buffer frames in the driver.
This means that we have frames that are not in the op_mode
and not visible to the firwmare. This causes issues when we
flush the queues: the op_mode flushes a queue, and the
firmware flushes all the frames that are *currently* on the
rings, but if the transport buffers frames, it can submit
these while we are flushing. This leads to a situation
where we still have frames on the queues after we flushed
them.
Preventing those buffered frame from getting into the
firmware is possible, but then, we have to run the Tx
response path on frames that didn't reach the firmware
which is not desirable.
The way I solve this here is to let these frames go to the
firmware, but make sure the firmware will not transmit them
(by setting the station as draining). The op_mode then needs
to wait until the transport itself is empty to be sure that
the queue is really empty.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Currently rs uses the info in mac80211 tx status which is
a translation of the actual rate coming up from the FW in
the tx response. This is matched up against the LQ table first
rate to make sure this tx frame used the current LQ table.
Instead of using the translated mac80211 info it's easier and
cleaner to just pass the actual tx response rate in the driver
private data and use that for matching.
This becomes even more important once the FW begins to
decide on its own whether to use STBC/BFER/SISO.
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

A new host command can be used to configure the scheduler
instead of accessing the scheduler's registers from the
driver. This is easier and less error prone since accessing
the hardware at certain moments can lead to races with the
firmware.
Prefer to use the host command whenever it is available.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If Tx failed because the STA was in powersave there's no point
in sending a BAR so avoid indicating AMPDU_NO_BACK to mac80211.
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

These are coming from the FW and are used to access arrays.
Bad values can cause an out of bounds access so discard
such ba_notifs and warn.

CC: <stable@vger.kernel.org> [3.10+]
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

BAR tx cmd tid was set to non qos (8). This is wrong as BAR
should be sent with the tid of the BA session.
This led to a corruption in the firmware. The visible
effect of this from the driver side is the BA notification
that comes back after the BAR. It was botched and led to the
WARNING below.

------------[ cut here ]------------
WARNING: CPU: 2 PID: 17707 at /home/tester/workspace_hostap/iwlwifi/drivers/net/wireless/iwlwifi/mvm/tx.c:976 iwl_mvm_rx_ba_notif+0x4ba/0x4d0 [iwlmvm]()
Q 4500, tid 8, flow 65535
Modules linked in: iwlmvm(O) mac80211(O) iwlwifi(O) cfg80211(O) compat(O) netconsole configfs ctr ccm arc4 autofs4 microcode bnep rfcomm snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel joydev snd_hda_codec uvcvideo videobuf2_core snd_hwdep videodev snd_pcm videobuf2_vmalloc videobuf2_memops i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device drm_kms_helper dell_wmi dell_laptop drm btusb bluetooth snd psmouse i2c_algo_bit sparse_keymap wmi soundcore 6lowpan_iphc dcdbas serio_raw video lpc_ich ppdev mac_hid parport_pc nfsd nfs_acl auth_rpcgss nfs fscache binfmt_misc lockd sunrpc lp parport msdos sdhci_pci sdhci mmc_core ahci libahci e1000e ptp pps_core [last unloaded: compat]
CPU: 2 PID: 17707 Comm: irq/46-iwlwifi Tainted: G        W  O 3.14.17-patched #4
Hardware name: Dell Inc. Latitude E6430/0CPWYR, BIOS A09 12/13/2012
 00000000 00000000 ebd49d6c c1616221 f985dbdc ebd49d9c c1044e44 f9861df4
 ebd49dc8 0000452b f985dbdc 000003d0 f98395da f98395da ebd49f10 eaf3d8a4
 0000ffff ebd49db4 c1044f03 00000009 ebd49dac f9861df4 ebd49dc8 ebd49e64
Call Trace:
 [<c1616221>] dump_stack+0x41/0x52
 [<c1044e44>] warn_slowpath_common+0x84/0xa0
 [<f98395da>] ? iwl_mvm_rx_ba_notif+0x4ba/0x4d0 [iwlmvm]
 [<f98395da>] ? iwl_mvm_rx_ba_notif+0x4ba/0x4d0 [iwlmvm]
 [<c1044f03>] warn_slowpath_fmt+0x33/0x40
 [<f98395da>] iwl_mvm_rx_ba_notif+0x4ba/0x4d0 [iwlmvm]
 [<c10e3952>] ? ring_buffer_unlock_commit+0xa2/0xd0
 [<c10e9767>] ? trace_buffer_unlock_commit+0x37/0x50
 [<f98568a3>] ? iwl_tm_mvm_send_rx+0x53/0x90 [iwlmvm]
 [<f98327a8>] iwl_mvm_rx_dispatch+0x108/0x130 [iwlmvm]
 [<f9eac7e7>] iwl_pcie_irq_handler+0xf17/0x15b0 [iwlwifi]
 [<c10994c1>] irq_thread_fn+0x21/0x50
 [<c109926c>] irq_thread+0xec/0x110
 [<c10994a0>] ? irq_thread_dtor+0xb0/0xb0
 [<c10993f0>] ? irq_finalize_oneshot.part.34+0xc0/0xc0
 [<c1099180>] ? wake_threads_waitq+0x40/0x40
 [<c1062fdb>] kthread+0x9b/0xb0
 [<c1627137>] ret_from_kernel_thread+0x1b/0x28
 [<c1062f40>] ? flush_kthread_worker+0x90/0x90
---[ end trace 5e0f67374816db17 ]---
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When tid_tspec was set to IWL_TID_NON_QOS (8) this led to an
out of bounds access to the tid_to_mac80211_ac array whose size
is 7. Fix this.
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The antenna configuration has to be read also from OTP
Currently read only from FW image
Guideline: An antenna exists only if appears both in FW image & NVM
Signed-off-by: NMoshe Harel <moshe.harel@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When adding a TDLS station, allocate 4 new queues for it. Configure them
to FW and enable them. On station removal, drain the queues if needed
and disable them when empty.

Make sure to flush all packets in the private queues of TDLS stations in
the mac80211 flush() callback.
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>

After the corresponding mac80211 patch, we can now report the airtime
used for each transmitted packet and mac80211 will be able to implement
WMM-AC with that information.

To support WMM-AC in the driver then, report the airtime and advertise
support.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Mostly functions related to building Tx-commands for sending to FW.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@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 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>

Currently BA notifications which don't reclaim any frames
would not cause the RS to be called as no skbs are passed
to mac80211. This is not optimal as RS can benefit from the
statistics of sent vs. acked of such a BA. This can improve the
reaction time of the RS algorithm. Also, an upcoming change in
the firmware would cause BA timeout to be reported as a BA notif
with 0 acked so this change is required for that as well.
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The scheduler is a HW sub-block that directs the work of the Flow
Handler by issuing requests for frame transfers, specifying source
and destination. Its primary function is to allocate flows into the
TX FIFOs based upon a pre-determined mapping.

The driver has some responsibilities to the scheduler, namely
initialising and maintaining the hardware registers. This is
currently done by directly accessing them, which can cause races
with the firmware also accessing the registers.

To address this problem, change the driver to no longer directly
access the registers but go through the firmware for this if the
firmware has support for DQA and thus the new command.
Signed-off-by: NAvri Altman <avri.altman@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Introduce new tx command flag (TX_CMD_FLG_WRITE_TX_POWER) which requests the
fw to update the tx power value at some constant offset.
Set this flag when transmitting either TPC report or Link measurement report
action frames.
In addition, introduce new tlv which indicates whether the fw supports power
insertion (IWL_UCODE_TLV_CAPA_TXPOWER_INSERTION_SUPPORT) and publish the
corresponding nl80211 feature.
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The sharing model will differ in new hardware. Define the
non shared antenna based on the device so that different
devices can have different names for the non shared antenna.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Using the LQ table which is initially set according to
the rssi could lead to EAPOLs being sent in high legacy
rates like 54mbps.
It's better to avoid sending EAPOLs in high rates as it reduces
the chances of a successful 4-Way handshake.
Avoid this and treat them like other mgmt frames which would
initially get sent at the basic rate.

Cc: <stable@vger.kernel.org> [3.13+]
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Our legal structure changed at some point (see wikipedia), but
we forgot to immediately switch over to the new copyright
notice.

For files that we have modified in the time since the change,
add the proper copyright notice now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In a later patch, the hardware configuration will be moved to
firmware. Prepare for this by allowing hardware configuration
in the transport to be skipped by not passing a configuration
on enable and passing configure_scd=false on disable.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Enabling the Aux queue and mapping it to FIFO 5.
Defining the Aux queue for the Aux station.
Signed-off-by: NAriej Marjieh <ariej.marjieh@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The comment was not accurate, we are talking about the frames
*for* the station and not from the station.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

An AP/GO may perform the channel switch slightly before its stations.
This scenario may result in packet loss, since the transmission may start
before the client is actually on a new channel. In order to prevent
potential packet loss disable tx to all the stations when the channel
switch flow starts. Clear the disable_tx bit when a station is seen on a
target channel, or after IWL_MVM_CS_UNBLOCK_TX_TIMEOUT beacons on a new
channel. In addition call ieee80211_sta_block_awake in order to inform
mac80211 that the frames for this station should be buffered.
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

These flags are not used by the firmware anyway.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If BT is active, we need to refrain from using the shared
antenna. This logic is done in the firmware when we use the
link quality tables. But for management frames, the rate is
written in the Tx command by the driver.
Hence the driver needs to make sure not use the shared
antenna when BT is active for any frames that don't use
the rate scale table such as management frames or multicast.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

CMD_SYNC is really 0 which is confusing:

if (cmd.flags & CMD_SYNC) is always false.
Fix this by simply removing its definition.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Use the new NAPI infrastructure added to mac80211 to get
GRO. We don't really implement NAPI since we don't have
a real poll function and we never schedule a NAPI poll.
Instead of this, we collect all the packets we got from a
single interrupt and then call napi_gro_flush().

This allows us to benefit from GRO. In half duplex medium
like WiFi, its main advantage is that it reduces the number
of TCP Acks, hence improving the TCP Rx performance.

Since we call the Rx path with a spinlock held, remove
the might_sleep mention from the op_mode's API.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NIdo Yariv <ido@wizery.com>
[Squash different patches and rewrite the commit message]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The fw recently added an option to set tx power reduction
per station (in the lq_cmd command), and get the tx power
reduction used (in the tx_resp struct).

Use them and propogate this value up to mac80211's tx
response (in order to use it later in the rate-scaling
algorithm).
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Currently RTS protection was done whenever trasnmitting an AMPDU.
This limits throughput in cases where there's no need for protection.
Disable this too inclusive protection for now.
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

We can now define the priority against BT per AC. This is
possible with a newer firmware that allows to define the
priority with 2 bits.
Note that this change is compatible with older firmware
since older firmware will simply ignore the new bit (11),
and we still set the old bit (12) in the same cases as
before.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This code is really related to BT Coex - move it to the coex
file.
Also - prepare for a FW API change that will happen soon:
Bits 11 and 12 will be allocated for BT priority. Today, we
only have bit 12.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Only the first packet is currently handled correctly, but then
all others are assumed to have failed which is problematic. Fix
this, marking them all successful instead (since if they're not
then the firmware will have transmitted them as single frames.)

This fixes the lost packet reporting.

Also do a tiny variable scoping cleanup.

Cc: <stable@vger.kernel.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
[Add the dvm part]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

These inlines are pretty pointless now as they just return a
fixed struct value, remove them - the code even gets shorter.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>