In 22000 devices, aka gen2, the TFS is 256 bytes.
In order to save memory, use shorter TX queue for aux and
mgmt queues, since there isn't much traffic on them.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

As preparation for dynamic queue sizing, add a parameter
of the TX queue size to the dynamic queue allocation op
mode API.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Support the new APIs and activate AMSDU based on the
offloaded TLC decisions.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The code that sets the correct out-of-channel priority depending on
the scan type was accidentally removed during a rebase.  Add it back.

Fixes: c1a75153 ("iwlwifi: mvm: add adaptive dwell support")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Introduce and use iwl_mvm_cdb_scan_api(), which checks the family.
Most of this will go away once the 22000 firmware supports adaptive
dwell, after which the V6 scan API won't be used, but the V3 scan
*config* API will still need to be distinguished.

In any case, this gets rid of the completely bogus has_new_tx_api()
checks.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Detect low latency and traffic load per band.  Add support for
deciding on scan type and timings per band.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Try to detect that the AP is not using aggregation even when there's
enough traffic to make it worthwhile; if this is the case and U-APSD
is enabled then assume the AP is broken (like so many) and doesn't
enable aggregation when U-APSD is used. In this case, disconnect from
the AP and blacklist U-APSD for a potential new connection to it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The primary channel is the channel that will be untouched by BT. The
secondary channel might be touched by BT.  Hence, we want the primary
to be the most active channel.  To do so, use the TCM infrastructure.

Since the BT keeps sending notifications, we can rely on them to
trigger the check. Every 10 seconds, we will check what is the most
active context and chose the right primary.

We need to wait 10 seconds before we modify the settings because
frequent changes in these settings can confuse BT.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The code for changing the scan priority is already implemented, but
isn't yet in use.  Now that TCM data is available, we can base the
scan priority decision on the traffic load.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Traffic condition monitor gathers data about the traffic load and
other conditions and can be used to make decisions regarding latency,
throughput etc.  This patch introduces the code and data structures to
collect this data for future use.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

fix iwlwifi_dev_ucode_error tracepoint to pass pointer to a table
instead of all 17 arguments by value.
dvm/main.c and mvm/utils.c have 'struct iwl_error_event_table'
defined with very similar yet subtly different fields and offsets.
tracepoint is still common and using definition of 'struct iwl_error_event_table'
from dvm/commands.h while copying fields.
Long term this tracepoint probably should be split into two.
Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>

Currently we have a boolean variable for each cause.

This costs space, and requires to check each separately
when determining low latency.

Since we have another cause incoming, convert it to an enum.

While at it, move the retrieval of the prev value and the
assignment of the new value to be inside iwl_mvm_update_low_latency
and save the need for each caller to do it separately.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Remove fragmented_dwell_time and add num_of_fragments to support
the new API version.
Signed-off-by: NAyala Beker <ayala.beker@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The FW does not allocate quota air time for the binding of a station
MAC before iwlmvm indicates that it is associated. Currently iwlmvm
indicates that the MAC is associated only after hearing a beacon from
the AP. In case a deauthentication frame is sent before the MAC is
associated, the frame might not be sent as the corresponding binding
is not scheduled.

To handle such cases, set IEEE80211_HW_DEAUTH_NEED_MGD_TX_PREP in the
HW flags, requesting mac80211 to call the mgd_prepare_tx() callback
before transmitting a deauthentication frame if associated but no
beacon was heard from the AP.

In addition, do not warn in iwl_mvm_mac_mgd_prepare_tx() when already
associated as now the callback can be called also when associated.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add support for Optimized Connectivity Experience (OCE).  Get
capabilities from the fw, expose them with nl80211, and enable them in
UMAC scan if the relevant nl80211 flags are set by the userspace.
Signed-off-by: NRoee Zamir <roee.zamir@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Update the scan command API with support for adaptive dwell.  Adaptive
dwell is a type of scan that dynamically changes the time it remains
on each channel listening for beacons or probe responses.
Signed-off-by: NRoee Zamir <roee.zamir@intel.com>
Signed-off-by: NBeni Lev <beni.lev@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Sometimes iwl_mvm_disable_txq() may be called with mac80211_queue ==
IEEE80211_INVAL_HW_QUEUE, and this would cause us to use BIT(0xFF)
which is way too large for the u16 we used to store it in
hw_queue_to_mac820211.  If this happens the following UBSAN warning
will be generated:

[  167.185167] UBSAN: Undefined behaviour in drivers/net/wireless/intel/iwlwifi/mvm/utils.c:838:5
[  167.185171] shift exponent 255 is too large for 64-bit type 'long unsigned int'

Fix that by checking that it is not IEEE80211_INVAL_HW_QUEUE and,
while at it, add a warning if the queue number is larger than
IEEE80211_MAX_QUEUES.

Fixes: 34e10860 ("iwlwifi: mvm: remove references to queue_info in new TX path")
Reported-by: NPaul Menzel <pmenzel+linux-wireless@molgen.mpg.de>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This makes future bail-outs from transmitting an AMSDU more
readable.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

RCU isn't properly locked.

Fixes: 46d372af ("iwlwifi: mvm: rs: new rate scale API - add FW notifications")
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Hardware bug was fixed in later generation.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Prefer the direct use of octal for permissions.

Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace
and some typing.

Miscellanea:

o Whitespace neatening around these conversions.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

When immediate quiet bit is set in CSA, the entire channel is blocked
by the firmware. It is expected that all the MACs will evacuate the
channel and the phy will be eventually either moved or removed.

Currently, the phy context is just unreferenced and thus, the quiet
bit is kept set and it will be impossible to TX on this phy, if we
will need to reuse it in the future.  This can be seen when doing a
channel switch with mode=1 (quiet) twice from channel X to Y and then
back to channel X.

Fix that, by moving the phy context to a default channel when not
referenced anymore.
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When starting aggregation, the code checks the status of the queue
allocated to the aggregation tid, which might not yet be allocated
and thus the queue index may be invalid.
Fix this by reserving a new queue in case the queue id is invalid.

While at it, clean up some unreachable code (a condition that is
already handled earlier) and remove all the non-DQA comments since
non-DQA mode is no longer supported.

Fixes: cf961e16 ("iwlwifi: mvm: support dqa-mode agg on non-shared queue")
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

If the driver failed to resume from D3, it is possible that it has
no valid aux station. In such case, fw restart will end up in sending
station related commands with an invalid station id, which will
result in an assert.

Fix this by allocating a new station id for the aux station if it
does not have a valid id even in the case of fw restart.
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When a queue is reserved for aggregation, the queue id is assigned
to the tid_data. This is fine since iwl_mvm_sta_tx_agg_oper()
takes care of allocating the queue before actual tx starts.
When the reservation is cancelled (e.g. when the AP declined the
aggregation request) the tid_data is not cleared. As a result,
following tx for this tid was trying to use an unallocated queue.

Fix this by setting the txq_id for the tid to invalid when unreserving
the queue.
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

After switching to a new channel, driver schedules session protection
time event in order to hear the beacon on the new channel.
The duration of the protection is two beacon intervals.
However, since we start to switch slightly before beacon with count 1, in
case we don't hear (or AP doesn't transmit) the very first beacon on the
new channel the protection ends without hearing any beacon at all.
At this stage the switch is not complete, the queues are closed and the
interface doesn't have quota yet or TBTT events. As the result, we are
stuck forever waiting for iwl_mvm_post_channel_switch() to be called.

Fix this by increasing the protection time to be 3 beacon intervals and
in addition drop the connection if the time event ends before we got any
beacon.
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Some devices use a shared clock which is very sensitive to variations
and cause trouble in some situations.  We need to set a bit in the phy
configuration to indicate that to the FW.  To make this generic, add a
extra_phy_config_flags element to the device configuration and OR it
into the phy_cfg before sending it to the firmware.  And also create a
set of configurations for devices that use shared clocks and need this
extra bit to be set.

Fixes: c62446d2 ("iwlwifi: add new 9460 series PCI IDs")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The earlier patch called the station add functions but didn't
assign their return value to the ret variable, so that the
checks for it were meaningless. Fix that.

Found by smatch:

.../mac80211.c:2560 iwl_mvm_start_ap_ibss() warn: we tested 'ret' before and it was 'false'
.../mac80211.c:2563 iwl_mvm_start_ap_ibss() warn: we tested 'ret' before and it was 'false'

Fixes: 3a89411cd31c ("iwlwifi: mvm: fix assert 0x2B00 on older FWs")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Currently when an IGTK is set for an AP, it is set as a regular key.
Since the cipher is set to CMAC, the STA_KEY_FLG_EXT flag is added to
the host command, which causes assert 0x253D on NICs that do not support
this.

Fixes: 85aeb58c ("iwlwifi: mvm: Enable security on new TX API")
Signed-off-by: NBeni Lev <beni.lev@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The tid being used for the queue (cab_queue) for the MCAST
station has been changed recently to be 0 (for BE).
The flush path still flushed only the special tid (15)
which means that the firmware wasn't flushing the right
queue and we could get a firmware crash upon remove
station if we had an MCAST packet on the ring.

The current code that flushes queues for a station only
differentiates between internal stations (stations that
aren't instantiated in mac80211, like the MCAST station)
and the non-internal ones.
Internal stations can be either: BCAST (beacons), MCAST
(for cab_queue), GENERAL_PURPOSE (p2p dev, and sniffer
injection). The internal stations can use different tids.

To make the code simpler, just flush all the tids always
and add the special internal tid (15) for internal
stations. The firmware will know how to handle this even
if we hadn't any queue mapped that that tid.

Fixes: e340c1a6ef4b ("iwlwifi: mvm: Correctly set the tid for mcast queue")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In the scheduler config command, the meaning of tid == 0xf was intended
to indicate the configuration is for management frames. However,
tid == 0xf was also used for the multicast queue that was meant only
for multicast data frames, which resulted with the FW not encrypting
multicast data frames.

As multicast frames do not have a QoS header, fix this by setting
tid == 0, to indicate that this is a data queue and not management
one.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Multicast frames for NL80211_IFTYPE_AP and NL80211_IFTYPE_ADHOC were
directed to the broadcast station, however, as the broadcast station
did not have keys configured, these frames were sent unencrypted.

Fix this by using the multicast station which is the station for which
encryption keys are configured.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When the GTK is installed, we install it to HW with the
station ID of the AP.

Mac80211 will try to remove it only after the AP sta is
removed, which will result in a failure to remove key
since we do not have any station for it.

This is a valid situation, but a previous commit removed
the early return and added a return with error value, which
resulted in an error message that is confusing to users.

Remove the error return value.

Fixes: 85aeb58c ("iwlwifi: mvm: Enable security on new TX API")
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Trying to collect firmware debug data while firmware
is not loaded causes various errors (e.g. failing NIC access).
This causes even a bigger issue if at that time the
HW radio is off.
In that case, when later turning the radio on, the Driver
fails to read the HW (registers contain garbage values).
(It may be that the CSR_GP_CNTRL_REG_FLAG_RFKILL_WAKE_L1A_EN
bit is cleared on faulty NIC access - since the same behavior
was seen in HW RFKILL toggling before setting that bit.)
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We should add the multicast station before adding the
broadcast station.

However, in older FW, the firmware will start beaconing
when we add the multicast station, and since the broadcast
station is not added at this point so the transmission
of the beacon will fail on assert 0x2b00.

This is fixed in later firmware, so make the order
of addition depend on the TLV.

Fixes: 26d6c16b ("iwlwifi: mvm: add multicast station")
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

It was assumed that apply_time==0 implies immediate scheduling, which is
wrong. Instead, the fw expects the START_IMMEDIATELY flag to be set.
Otherwise, this resulted in 0x3063 assert.
Fix that.
While at it rename the T2_V2_START_IMMEDIATELY to
TE_V2_START_IMMEDIATELY.

Fixes: f5d8f50f ("iwlwifi: mvm: Fix channel switch in case of count <= 1")
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We don't have enough room in the TX command for a CCMP 256
key, and need to use key from table.

Fixes: 3264bf032bd9 ("[BUGFIX] iwlwifi: mvm: Fix CCMP IV setting")
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

While entering to D3 mode there is a gap between the time the
driver handles the D3_CONFIG_CMD response to the time the host is going
to sleep.
In between there might be cases which MARKER_CMD can tailgate.
Also during resume flow the MARKER_CMD might get sent while D0I3_CMD
is being handled in the FW.
Cancel MARKER_CMD timer and set it again properly during suspend
resume flows to prevent this command from being sent accidentlly.
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In AP mode, when a new station associates, rs is initialized immediately
upon association completion, before the phy context is updated with the
association parameters, so the sta bandwidth might be wider than the phy
context allows.
To avoid this issue, always initialize rs with 20mhz bandwidth rate, and
after authorization, when the phy context is already up-to-date, re-init
rs with the correct bw.
Signed-off-by: NNaftali Goldstein <naftali.goldstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Canceling the periodic timestamp work should be
done in the opposite flow to where it was started.
This also prevents from sending the MARKER command
during the mac_stop flow - causing a false queue hang
(FW is no longer there to send a response).

Fixes: 93b167c1 ("iwlwifi: runtime: sync FW and host clocks for logs")
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>