The thermal throttling parameters were constant and hardcoded, not allowing
changes for different NIC families.
Change this so that the values are part of the NIC family configuration and
are not constant (so they can be changed dynamically in the future).
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When a firmware restart is done, don't try to reprogram the keys to new
slots but rather just keep the old key index, while skipping keys that
weren't programmed before.

Not only does this restore the state more faithfully, but it will also
allow using the HW key index for internal purposes as an array index.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The generic scan command functions are now irrelevant, since both
sched and regular scans are in the same code.  So rename this
functions to dwell and isolate all the dwell-related setting to them.
Keeping the dwell code separate makes it easier to compare the LMAC
and UMAC versions.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Having an LMAC counterpart for the existing UMAC flags function makes
things more consistent and easy to compare and spot the differences.
The flags are the same, but are in different bits, so unfortunately we
can't use a single function for both APIs.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Clean the code a little by moving all the flags into the right
function.  Additionally, rename the function, since "common" is now
irrelevant.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When we use an external buffer, it is allocated from the
t DRAM and can be as big as 64MB. This buffer is huge and
might not be needed for the specific issue being chased.
Especially if lots of dumps are going to be created.
Allow to limit the size of the buffer in the configuration.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

qos_seq points (to a struct) inside the command response data.

Make sure to free the response only after qos_seq is not
needed anymore.

type=bugfix
bug=not-tracked
fixes=I78c07110b59dcd389207bd2b168b0a2760839fe0

Change-Id: I619ce2c17e064dc98c7be9abc1e23175fdc8fb9a
Reported-by: NHeng Luo <heng.luo@intel.com>
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Reviewed-on: https://gerrit.rds.intel.com/r/55381Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Tested-by: IWL Jenkins
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

With just a few differences left in the UMAC scan functions now, we
can merge them into one, taking care of the small difference according
to the total number of iterations required.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In theory, LMAC scans can handle a 32-bit delay, but since waiting for
over 18 hours to start the scan is a bit silly and to keep it aligned
with UMAC scans (which only support 16-bit delays), trim it down to
16-bits.

This makes the LMAC vs. UMAC and the UMAC reg scan vs. UMAC sched scan
code more similar.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The last remaining difference between the regular scan and scheduled
scan flows for LMAC is the FW capabilities check for EBS scans.

Merge these checks into a new function and then combine the LMAC scan
functions into a single one.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

As another step towards combining the scan and sched scan functions,
add parameters that tell the scan function how many iterations we want
(i.e. 1 for normal scan, more for scheduled scan) and that set the
full scan multiplier (only meaningful for LMAC).
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The probe request to be added to both LMAC and UMAC scan commands are
identical, so move the generation out of the LMAC/UMAC-specific code.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

To make things clearer, rename the iwl_mvm_scan_calc_params() function
to iwl_mvm_calc_dwell() and make it calculate and fill in only
dwell-related parameters.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Now that both scheduled scan and regular scan SSID populating
functions do the same thing, they can be combined into a single
function.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware inverts the order of the SSIDs sent out in probe requests
(for some reason).  For regular scans, we've been passing the SSIDs in
the opposite order so they go out in the order we want.  With
scheduled scans, we were not doing that, so they were sent out in
reverse order of priority.  Fix that by using the reverse order when
populating the SSIDs array for scheduled scans as well.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The only difference in the ssid_bitmap between LMAC and UMAC scans is
that in LMAC bits 1 to 20 are used, while in UMAC bits 0 to 19 are
used (*sigh*).  So we can combine the bitmap creation into a single
function and simply shift left if LMAC is used.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Many parameters are common for all scans.  Instead of parsing the
cfg80211 scan and sched scan requests differently in each flow, move
the parsing outside of the API/scan-type specific functions.  In this
way, we only need to differentiate between scan types once.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Similarly to the regular scan patch, a lot of the UMAC and LMAC sched
scan code is also almost identical.  Grab the low hanging fruits by
combining the obvious parts.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

A lot of the UMAC and LMAC scan code is almost identical.  Grab the
low hanging fruits by combining the obvious parts.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The lists of the devices supported by either MVM or DVM
firmwares was incomplete. Point to
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#firmware
instead of maintaining the lists.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Usually during HW recovery the state of all active interfaces is cleaned
up during drv_start(). There's a special case where a HW restart is
requested when an interface is going down. In this case the iface-iterator
won't see this interface and we won't clean it. This has bad consequences
once the interface is legitimately brought up again.
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>

Instead of repeating the same code in 4 different places, combine the
comparisons into a new function.  Additionally, this change fixes UMAC
scans where the RRM IEs were not taken into consideration when
calculating the IE length.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

We have a function (iwl_mvm_scan_size()) that can calculate the scan
size for both UMAC and LMAC scans.  Use that function instead of
calculating manually for LMAC scan and sched scan.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

We don't support -9.ucode so, all the released firmwares
support scheduled scan properly.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Remove unused struct iwl_scan_offload_req and enum
iwl_scan_offload_flags which are not used anymore.  Rename
iwl_scan_offload_schedule to iwl_scan_schedule_lmac to make it clear
that this is for LMAC only.  And fix a small typo.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Previously there was a check that compared window->average_tpt
to some value, and if it was different - it set it to that
value. However, this value was already calculated and set in
_rs_collect_tx_data(), so the entire check is unneeded.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This adds support for configuring and retrieving the FW
monitor in MARBH mode.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Net-detect scans were using the same type as sched scan, which was
causing the driver to return -EBUSY and prevent the system from
suspending if there was an ongoing scheduled scan.  To avoid this, add
a new type for net-detect and don't stop anything when it is
requested, so that the existing scheduled scan will be resumed when
the system wakes up.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Move all the scan code that was in mac80211.c to scan.c where it
belongs, leaving only the parts that are specific to mac80211 ops.

Change some function definitions slightly to improve consistency.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All scans are using the unified APIs now, so using "unified" in the
symbols is useless and just make them much longer and the main
difference between scans now is LMAC vs. UMAC.  Remove "unified" from
all relevant symbols.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Instead of hardcoding the differences between UMAC scans and LMAC
scans (which in this case is the number of simultaneous scans that can
run), introduce a max_scans variable and stop scans of the other type
(i.e. stop sched scan if regular scan is being attempted and
vice-versa) if the number of running scans reached the maximum.

Add a function that checks if the maximum number of scans was reached
and stops the appropriate scan to make room for the new scan.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If a new scan cannot be run for some reason, we shouldn't cancel other
ongoing scans.  Move the checks to before the code that cancels other
scans.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Now that we have separate flags for stopping scans, we don't need to
wait for the scan stopped work to complete before starting the new
scan.  Previously we needed it because we had no way of distinguishing
the scan that was being stopped from the scan that was currently
running.  With the new flags there won't be any confusions and we are
able to handle the stop for the correct type of scan.

Thus we can remove the iwl_mvm_cancel_scan_wait_notif() function.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

LMAC scans cannot handle more than one scan at a time, but UMAC scans
can.  To avoid confusion we should combine the states of these two
types of scans.  To do so, we need to support mutliple scans at the
same time for UMAC.

This commit changes the scan_status element from a single value to a
bitmask of running scan types for LMAC.  Later, we will modify UMAC
scans to use the same state bitmask.

Additionally, add stopping scan flags for scheduled and regular scans.
This makes it easier to differentiate and handle stop requests
triggered by the driver and spontaneous stops generated by the
firmware.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In some cases, max_out_time value is smaller than 200 and having the
NL80211_SCAN_FLAG_LOW_PRIORITY flag was actually causing the
max_out_time to be increased.  To avoid that, set max_out_time to 200
only if it's greater than 200.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NAlexander Bondar <alexander.bondar@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add scan parameters information to make it easier to debug scan dwell
times and fragmentation.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NAlexander Bondar <alexander.bondar@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

last_txrate_idx isn't used anymore and can be dropped as this info
exists already somewhere else.
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>

Same code appear a few lines later while the position has
no effect on the actual flow.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When user space requests mac80211 to transmit a frame off
channel, mac80211 notifies the driver, and the driver requests
a time event from the ucode, and then transmits the frame.
When the driver requests a time event, it can specify what is the allowed
max delay for starting the time event.

When the max delay is too big, this can cause a timeout in the user space,
that is waiting for the frame to be transmitted.

Currently the max delay is extremely long.

Reduce the max delay for the AUX ROC time event that is sent to the ucode.
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>