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>

During firmware restart, the quota command isn't calculated multiple
times, but after the firmware restart it has to be sent, so force it.
Otherwise the firmware crashes.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

I forgot to rename the CPTCFG_ prefix...

Fixes: 484b3d13 ("iwlwifi: mvm: add debugfs entry with the number of net-detect scans")
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Our device needs two different firmwares: the INIT firmware
and the operational (OPER) firmware. The first one is run
when the driver loads and it returns calibrations results
as well as the NVM. The second one implements the WiFi
protocol.

If the wlan interface is not brought up, the device is put
to low power state: no firmware will be running. When the
interface is brought up, we would run the OPER firmware
only and reuse the results of the run of the INIT firmware
when the driver was loaded. This is changing with this
patch.
We now run the INIT firmware every time mac80211 calls
start(). The penalty for that is minimal since the INIT
firwmare run fast. I now also avoid to power down the device
between the INIT and OPER firmware on certains buses.

The motivation for this change is that there are components
on the device (MFUART) that are triggered by the INIT
firmware and need the device to be powered up in order to
keep running. Powering the device down between the INIT and
OPER firmware would stop these components and prevent them
from running again since they are triggered by the INIT
firmware only.
The new flow allows this and also allows to trigger these
components again when the interface is brought up after
it has been brought down.
Signed-off-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In the case of a DMA mapping error on the last iteration of
the loop of the allocation of memory of the FW monitor we
indeed free the pages, but don't NULL out the page variable
thus allowing for the possibility of setting the FW monitor
variables with invalid data to use.

Fixes: c2d20201 ("iwlwifi: pcie: add firmware monitor capabilities")
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If for some reason statistics notification received from the firmware
reports 0 in average beacon RSSI value, then skip it and avoid signal
based decisions.
Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Scan iteration complete notification handling uses the wrong FW API
version (version 2 instead of version 3).
Fix that by removing version 2 API which is no longer used, and using
only the updated version.
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Reviewed-by: NDavid Spinadel <david.spinadel@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When the delay paramatere is provided, we need to stop
the collection only after the delay has elapsed.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware doesn't relate the scan to a vif. The scan is
run by a separate entity called auxiliary MAC (aka AUX MAC).
This AUX MAC needs to get Tx power limitations that are
not applied on a specific vif, but on the device as a whole.

This can be implemented by using the minimum of all the
values set by the user for all the MACs. But then we need
to ignore the limitations that come from the AP or
regulatory for a specific vif: a specific vif might have
regulatory limitations because of the channel is works on.
This limit is irrelevant for the AUX MAC.
Use the new API from mac80211: the user_power_level in
bss_conf to achieve this.

Firmware -13.ucode has already moved to this API.

Change-Id: Ifba83660f378e91b93bd46d29fe8ba35a7c168a4
Signed-off-by: NAvri Altman <avri.altman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

With the recent driver changes, bump the version.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>

VFs were being improperly added to the switch's multicast group. The
error stems from the fact that incorrect arguments were passed to the
"update_mc_addr" function. It would seem to be a copy paste error since
the parameters are similar to the "update_uc_addr" function.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NNgai-Mint Kwan <ngai-mint.kwan@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When we call update_max_size it does not drop all oversized messages.
This is due to the difficulty in performing this operation, since it is
a FIFO which makes updating anything other than head or tail very
difficult. To fix this, modify validate_msg_size to ensure that we error
out later when trying to transmit the message that could be oversized.
This will generally be a rare condition, as it requires the FIFO to
include a message larger than the max_size negotiated during mailbox
connect. Note that max_size is always smaller than rx.size so it should
be safe to use here.

Also, update the update_max_size function header comment to clearly
indicate that it does not drop all oversized messages, but only those at
the head of the FIFO.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When we forcefully shutdown the mailbox, we then go about resetting max
size to 0, and clearing all messages in the FIFO. Instead, we should
just reset the head pointer so that the FIFO becomes empty, rather than
changing the max size to 0. This helps prevent increment in tx_dropped
counter during mailbox negotiation, which is confusing to viewers of
Linux ethtool statistics output.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

The use of dropped doesn't really mean dropped mailbox messages, but
rather specifically messages which were too large to fit in the remote
Rx FIFO. Rename the stat to more clearly indicate what it means.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When the PF receives a request to update a multicast address for the VF,
it checks the enabled multicast mode first. Fix a bug where the VF tried
to set a multicast address before requesting the required xcast mode.
This ensures the multicast addresses are honored as long as the xcast
mode was allowed.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Since the service task handles varying work that doesn't all require the
interface to be up, launch the service timer immediately. This ensures
that we continually check the mailbox, as well as handle other tasks
while the device is down.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

The header comment included a miscopy of a C-code line, and also
mis-used Rx FIFO when it clearly meant Tx FIFO
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Add a header comment explaining why we have the somewhat crazy mailbox
flow. This flow is necessary as it prevents the PF<->SM mailbox from
being flooded by the VF messages, which normally trigger a message to
the PF. This helps prevent the case where we see a PF mailbox timeout.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Since we already schedule the service task, we can just wait for this
task to handle the mailbox events from the VF. This reduces some complex
code flow, and makes it so we have a single path for handling the VF
messages. There is a possibility that we have a slight delay in handling
VF messages, but it should be minimal.

The result of tx_complete and !rx_ready is insufficient to determine
whether we need to process the mailbox. There is a possible race
condition whereby the VF fills up the mbmem for us, but we have already
recently processed the mailboxes in the interrupt. During this time,
the interrupt is disabled. Thus, our Rx FIFO is empty, but the mbmem now
has data in it. Since we continually check whether Rx FIFO is empty, we
then never call process. This results in the possibility to prevent PF
from handling the VF mailbox messages.

Instead, just call process every time, despite the fact that we may or
may not have anything to process for the VF. There should be minimal
overhead for doing this, and it resolves an issue where the VF never
comes up due to never getting response for its SET_LPORT_STATE message.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Since we run the watchdog periodically, which might take a while and
potentially monopolize the system default workqueue, create our own
separate work queue. This also helps reduce and stabilize latency
between scheduling the work in our interrupt and actually performing
the work. Still use a timer for the regular scheduled interval but
queue the work onto its own work queue.

It seemed overkill to create a single workqueue per interface, so we
just spawn a single work queue for all interfaces upon driver load. For
this reason, use a multi-threaded workqueue with one thread per
processor, rather than single threaded queue.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When returning virtualization queues from the VF back to the PF, do not
retain the VF rate limiter.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NTodd Russell <todd.a.russell@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Named it tx_hang_count to differentiate it from tx_hwtstamp_timeout.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

We were incrementing the tx_timeout_count for both the Tx hang
and then for all reset flows.  Instead, we should only increment
tx_timeout_count in the Tx hang path, so that our Tx hang counter
does not increment when it was not caused by a Tx hang.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Since we already print this message when a reset is requested via the
RESET_REQUESTED flag, we do not need to print it before setting the
flag.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

This patch resolves an issue with ethtool stats displaying useless
values on the VF, because some stats simply have no meaning to the VF.
Resolve this by splitting these out into PF_STATS and only showing them
if we aren't the VF.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Even though it shouldn't strictly matter, don't count queue stats higher
than the max_queues value stored for this mac. This ensures that we
don't attempt to check queues which don't belong to use in VFs. This
shouldn't be a visible change, as the VFs should see zero for queues
which don't belong to them.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Currently, we show statistics for all 128 queues, even though we don't
necessarily have that many queues available especially in the VF case.
Instead, use the hw->mac.max_queues value, which tells us how many
queues we actually have, rather than the space for the rings we
allocated. In this way, we prevent dumping statistics that are useless
on the VF.
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>