Most of the dwells are constant across different scan types.
Use defines instead of depending on scan type.
This is needed as preparation to having different scan type per
band.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Delete the scanned channel results.
No need in it we get it any way when logging.
The print only clogs up the ftrace print buffer.
Signed-off-by: NMordechai Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

There are several occasions where a scan of the same type is requested
concurrently, so logging every time this happens is just noisy and
unnecessary.  Remove the logging for these cases.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

API will be the same regardless of FW compilation.
CDB related values will be filled in only for CDB.
Cahneg code and names accordingly.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

For CDB devices we will want to configure scan parameters
per band.
Support the new scan API for now. Logic per band will be
added in the future.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Currently we have up to 3 phy contexts - defined by NUM_PHY_CTX.
However - some code paths validate the ID by using MAX_PHYS define
which is set to 4.
While there is no harm it is incorrect - since the maximum is 3.
Remove the define and use the correct one.
Cleanup the code a bit while at it.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

With unified images, we need to make sure the net-detect scan is
stopped after resuming, since we don't restart the FW.  Also, we need
to make sure we check if there are enough scan slots available to run
it, as we do with other scans.

Fixes: commit 23ae6128 ("iwlwifi: mvm: Do not switch to D3 image on suspend")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

FW versions older than -17 for 3160 and 7260 and older than -22 for
newer NICs are not supported anymore.  Don't load these versions
and remove code that handles them.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Implement support for RRM by adding an option to configure the scan
dwell time and reporting scan start time and BSS detection time, and
Advertise support for these features.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add the following to support beacon report radio measurement
with the measurement mode field set to passive or active:
1. Propagate the required scan duration to the device
2. Report the scan start time (in terms of TSF)
3. Report each BSS's detection time (also in terms of TSF)

TSF times refer to the BSS that the interface that requested the
scan is connected to.
Signed-off-by: NAssaf Krauss <assaf.krauss@intel.com>
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
[changed ath9k/10k, at76c59x-usb, iwlegacy, wl1251 and wlcore to match
the new API]
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some transports may sleep when writing to registers, which is done
when calling iwl_force_nmi().  So we can't call iwl_force_nmi() in a
timer context.  To solve that, convert the scan timeout timer to a
delayed work.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The 16 seconds timeout we were using turned out to be too short.
Recalculations by system show that the total time in both bands should
be < 18.5 seconds, even in the slowest cases (e.g. DCM P2P with
DTIM=2).  Rounding it up to 20 seconds for a bit more safety.

Fixes: 728e825f ("iwlwifi: mvm: add a scan timeout for regular scans")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This enum is already perfectly aliased to enum nl80211_band, and
the only reason for it is that we get IEEE80211_NUM_BANDS out of
it. There's no really good reason to not declare the number of
bands in nl80211 though, so do that and remove the cfg80211 one.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If something goes wrong with the firmware and we never get a scan
complete notification, we stay stuck forever.  In order to avoid this
situation, add a timeout and trigger an NMI if it expires before
receiving the notification., so we can clean things up.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Auxilary station ID in flag in scan config command wasn't set
although we set the station ID. Add the flag.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware doesn't send match found notifications when no matchsets
are passed.  This makes sense because if there are no matchsets,
nothing can be matched.  But the nl80211 API should report when there
are results available, even if no matchsets were passed.

To handle this, we can use the firmware's ITERATION_COMPLETE
reporting, which will send us notifications every time it completed a
scheduled scan iteration.  Then we can set a flag when we received
beacons and use that to report that results are available.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware can perform a scheduled scan with not matchsets passed,
but it can't send notification that results were found.  Since the
userspace then cannot know when we got new results and the firmware
wouldn't trigger a wake in case we are sleeping, it's better not to
allow scans without matchsets.

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

Cc: <stable@vger.kernel.org> [3.17+]
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Print a debug message in iwl_mvm_config_scan() if a scan configuration
data is decided not to be sent to FW.
Signed-off-by: NMax Stepanov <Max.Stepanov@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Currently when the driver is configured with wowlan parameters, and enters
D3 mode, the driver switches the FW image to D3, and when it exists
suspend, it reloads the D0 image.

If the firmware supports the consolidation of the D0 & D3 images there is
no need to load the D3 image on suspend, and no need to reload the D0
image on resume.

Do not switch images on suspend / resume, for firmwares that support
consolidated images.
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

FW adds 10 msec for every dwell time in low band, so we need
to set 10 msec less.
Don't use extended dwell time when fragmented scan is needed
because FW adds 3 msec per probe and it can easily exceed
max out of channel time.

Fixes: c3e230b1 ("iwlwifi: mvm: add extended dwell time")
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When doing active scan on crowded channels we are likely to miss probe
responses due to collisions. To overcome this issue we use an extended
dwell time on channels 1, 6 and 11; this dwell time is set to 100.

In case of fragmented scan extended dwell time is the maximum out of
channel time - 44 msec. Fragmented active scan will be addressed later.

Extended dwell time isn't used in sched scan or p2p find.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

ilw@linux.intel.com is not available anymore.
linuxwifi@intel.com should be used instead.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Change scan configuration (dwell time, suspend time etc.) according
to traffic conditions. This is useful for scans that are managed by
the FW (e.g. scheduled scan).
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In the iwl_mvm_check_running_scans() we were mistakenly ignoring the
value returned by iwl_mvm_scan_stop() for scheduled scans and falling
thorugh to the next case, which caused us to always return zero.
Signed-off-by: NNicholas Krause <xerofoify@gmail.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If the firmware sends LMAC scan notifications while a UMAC scan is
running, just WARN and ignore it, otherwise the scanning state gets
messed up.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Configure the FW to use fragmented scan when the traffic load is high
or low latency traffic is on. This is useful for scans that are
managed by the FW (e.g. scheduled scan).
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Part of reorganising wireless drivers directory and Kconfig.
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

In some cases, scan reference was taken, but wasn't
released even though scan command wasn't actually issued.

Change the current code to simply take the reference
only on success.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

As cfg80211 already enforces these limits, there's little point
in having them again here in our code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add support for two scan plans for scheduled scan. The first plan
will run for a limited number of iterations, then the second plan
will run infinitely.
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add the option to configure multiple 'scan plans' for scheduled scan.
Each 'scan plan' defines the number of scan cycles and the interval
between scans. The scan plans are executed in the order they were
configured. The last scan plan will always run infinitely and thus
defines only the interval between scans.
The maximum number of scan plans supported by the device and the
maximum number of iterations in a single scan plan are advertised
to userspace so it can configure the scan plans appropriately.

When scheduled scan results are received there is no way to know which
scan plan is being currently executed, so there is no way to know when
the next scan iteration will start. This is not a problem, however.
The scan start timestamp is only used for flushing old scan results,
and there is no difference between flushing all results received until
the end of the previous iteration or the start of the current one,
since no results will be received in between.
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

All the supported firmwares have this flag set.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>

split long debug messages that may result warning in tracing.

Fixes: 1a84e771 ("iwlwifi: mvm: add debug info to schedule scan complete message.")
Signed-off-by: NAyala Beker <ayala.beker@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add more information to schedule scan complete message.
Signed-off-by: NAyala Beker <ayala.beker@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Lmac sched scan supports partial scans, so we can set some channels to be
scanned on every scan iteration and others to be scanned only on some
iterations. Currently we set all channels to be scanned every iteration,
but still have some configuration of which iterations should be partial
and which should be full.

Remove all partial/full scan configuration to reduce confusions.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Remove timing values from iwl_mvm_scan_params and use defines and
arrays of values instead.

While at that fix few values and corner cases and align all OSs
to ChromeOS values.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add support for extended command id in notification system.
Extended command id header contains group id in addition to command id.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Existing UMAC commands already use the long header, but are sent
with group 0 and the long header inserted manually. Move them to
the group 1 to take advantage of the header building in the low-
level transport.

Existing firmware ignores the group_id field (it's reserved) and
the first firmware that really supports long command headers can
parse all commands in both group 0 (with short header) and group
1 (with long header.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the supported firmwares support this API.
This includes removing dwell per band, as band is no longer a factor
in calculating the dwell. Only basic dwell is used and FW will calculate
the actual dwell time.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>