We don't really have much reason to mistrust the hardware
queue number, but if it gets mixed up we still don't want
to access some data out of bounds, so drop such frames.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.539aecb91247.I6e555a5185bad30d7d1a4659f9c0b99325425f18@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Normally, when we hit an assert, we print out all the
assert data. However, in certain tests, when we trigger
it from debugfs intentionally, that can be useless and
confusing.

Allow writing the string "nolog\n" to the fw_nmi and
fw_restart files suppressing the assert dump as well
as - in the case of fw_restart - the

  iwlwifi 0000:00:00.0: FW error in SYNC CMD REPLY_ERROR

message.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174546.75e29a2ab68d.Id3064feda2ce7a77c116c6d6e71ce5ff447c6e86@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Support reading the SAR Geographic Offset Mapping (SGOM) table from UEFI
to allow OEMs to override the values according to geographical regions.
Signed-off-by: NAyala Barazani <ayala.barazani@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174546.e6dfd8b5dd40.Ibc9a8fe2bfde345f49df5d57ec56663da6a53dc4@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we use 2K RBs, we cannot receive all valid 802.11 frames,
including e.g. long beacons, since up to 2304 bytes are valid
(plus metadata and also encryption overhead etc.). Increase
the RB size to be always 4K to avoid that.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174545.675781ab0da5.I5c653f4c7dd726f8ad40077e4a109b85e7c0cdb1@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

The firmware is exposing a new system features control command,
define the necessary data structures etc. Rename "soc.h" to
"system.h" since the SoC command is also in the system group
and adding another file for just one more struct seemed like a
waste of files.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174545.94a120687887.I79acffcf0793ea9e4ddec24b06420961bfb4fe94@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Some command strings in the system group weren't added
for debug, add them now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204130722.5bbda292908e.I53cefd74547a745fd29261a795c94611e7ee8d1d@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

There's an RLC configuration command in the firmware that's
going to replace the chain information in the PHY context.
Add support for this command, while leaving the PHY context
fields unset when we know the RLC command will be used.

Also add support to send only the RLC configuration command
if only the # of chains used on the PHY context changes.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204083238.55faa3782bb0.I3f9d0071e680cab513c59b093d0827af99d41c51@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

We have a MAC component (which is inside the SoC) and it has several
different HW steps.  3 bits used to be enough but now we need 4-bits
to represent all the different steps.

Properly support 4-bits in the MAC step value by refactoring all the
current handling of the MAC step/dash.

Already from family 8000 and up the dash (bits 0-1) no longer exists
and the step (until 8000 bits 2-3) consists of the dash bits as well.

To do this remove the CSR_HW_REV_STEP and the CSR_HW_REV_DASH
macros, replace them with CSR_HW_REV_STEP_DASH and add hw_rev_step
into the trans struct.

In addition remove the CSR_HW_IF_CONFIG_REG_MSK_MAC_STEP and
CSR_HW_IF_CONFIG_REG_MSK_MAC_DASH macros and create a new macro
combining the 2 (this way we don't need shifting or anything else.)
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: NMike Golant <michael.golant@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211207160459.2e81a14d1f80.Ia5287e37fb3439d805336837361f6491f958e465@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Read the rfkill state upon boot, mac start and mac stop.
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112062814.7502-6-emmanuel.grumbach@intel.com

iwlmei needs to know about the follwing events:

* Association
* De-association
* Country Code change
* SW Rfkill change
* SAR table changes

iwlmei can take the device away from us, so report the new
rfkill type when this happens.
Advertise the required data from the CSME firmware to the
usersapce: mostly, the AP that the CSME firmware is currently
associated to in case there is an active link protection
session.
Generate the HOST_ASSOC / HOST_DISSASSOC messages.

Don't support WPA1 (non-RSNA) for now.
Don't support shared wep either.
We can then determine the AUTH parameter by checking the AKM.
Feed the cipher from the key installation.

SW Rfkill will be implemented later when cfg80211 will
allow us to read the SW Rfkill state.
Co-Developed-by: NAyala Beker <ayala.beker@intel.com>
Signed-off-by: NAyala Beker <ayala.beker@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

v7: Ayala added her signed-off
    remove pointless function declaration
    fix a bug due to merge conflict in the HOST_ASSOC message
v8: leave a print if we have a SAP connection on a device we do
    not support (yet)
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112062814.7502-4-emmanuel.grumbach@intel.com

Fix warnings produced by:
- lockdep_assert_wiphy() in function reg_process_self_managed_hint(),
- wiphy_dereference() in function iwl_mvm_init_fw_regd().
Both function are expected to be called in critical section.

The warnings were discovered when running v5.15 kernel
with debug options enabled:

1)
Hardware name: Google Delbin/Delbin
RIP: 0010:reg_process_self_managed_hint+0x254/0x347 [cfg80211]
...
Call Trace:
regulatory_set_wiphy_regd_sync+0x3d/0xb0
iwl_mvm_init_mcc+0x49d/0x5a2
iwl_op_mode_mvm_start+0x1b58/0x2507
? iwl_mvm_reprobe_wk+0x94/0x94
_iwl_op_mode_start+0x146/0x1a3
iwl_opmode_register+0xda/0x13d
init_module+0x28/0x1000

2)
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:263 suspicious rcu_dereference_protected() usage!
...
Hardware name: Google Delbin/Delbin, BIOS Google_Delbin
Call Trace:
dump_stack_lvl+0xb1/0xe6
iwl_mvm_init_fw_regd+0x2e7/0x379
iwl_mvm_init_mcc+0x2c6/0x5a2
iwl_op_mode_mvm_start+0x1b58/0x2507
? iwl_mvm_reprobe_wk+0x94/0x94
_iwl_op_mode_start+0x146/0x1a3
iwl_opmode_register+0xda/0x13d
init_module+0x28/0x100

Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver")
Signed-off-by: NŁukasz Bartosik <lb@semihalf.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211110215744.5487-1-lukasz.bartosik@semihalf.com

In some very rare cases the init flow may fail.  In many cases, this is
recoverable, so we can retry.  Implement a loop to retry two more times
after the first attempt failed.

This can happen in two different situations, namely during probe and
during mac80211 start.  For the first case, a simple loop is enough.
For the second case, we need to add a flag to prevent mac80211 from
trying to restart it as well, leaving full control with the driver.

Cc: <stable@vger.kernel.org>
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20211110150132.57514296ecab.I52a0411774b700bdc7dedb124d8b59bf99456eb2@changeid

There is no relation between the name and the purpose of the
notification. This notification is sent from FW when the channel switch
starts.
Signed-off-by: NNathan Errera <nathan.errera@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211024181719.24b71b0cb741.I97deb70e18f259de51395a1e7c7e58c7b006c317@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

When this code was implemented, there was no official FW API
description yet, so a placeholder name was used (GEO_TX_POWER_LIMIT).
But then the command became actually called
PER_CHAIN_LIMIT_OFFSET_CMD.  Rename the command (and change related
comments) to PER_CHAIN_LIMIT_OFFSET_CMD to avoid confusion.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211024181719.672fa727ef75.I6572df5d1e3441a0214993a59985da9a9431f3e5@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

As part of the new rate_n_flags, FW added a new version for
LOCATION_RANGE_RSP_NTFY, and it's internal structure -
LOCATION_RANGE_RSP_AP_ETRY_NTFY. Add support for this.
Signed-off-by: NMiri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211017123741.c5c6c863631e.I4b493f4eeabbfa1dc965ae012b72fc57de7d5f4f@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Use the previously added infrastructure to scrub key material
in firmware dumps:
 * in the TX FIFO data, just search for each key that we
   know about and override such data
 * scrub various commands that we sent to the firmware if
   they're present
 * in firmware memory, where advertised by firmware TLVs
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211017123741.d1514964e6a7.I18f8c2ce8082952af7cfe5f8fe75fe51851b8853@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

In firmware dumps, currently all kinds of key material may be
included, e.g. in host commands (if firmware crashes during the
processing of a key-related command) or in the TX FIFO(s) if
we have been using in-TX-command key material.

Additionally, some firmware versions will advertise sections
of their internal data to not dump, due to them containing some
sensitive data.

Add some infrastructure to allow scrubbing this data out, as
dependent on the opmode's idea of what will need to be done.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211017123741.360cc8fe55b1.Ie3bd3ece38043969f7e116e61a6ec1197a58d78b@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Consensus seems to be emerging that corporations or groups
shouldn't be listed as module authors, and we will not
maintain this email address any longer. Just remove it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211017113927.32109514aad0.I91a7d745f4ab50ee8ef918ece00dda8251541595@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Due to a rebase damage, we lost the rtnl_lock() when the patch was
sent out.  This causes an RTNL imbalance and failed assertions, due to
missing RTNL protection, for instance:

  RTNL: assertion failed at net/wireless/reg.c (4025)
  WARNING: CPU: 60 PID: 1720 at net/wireless/reg.c:4025 regulatory_set_wiphy_regd_sync+0x7f/0x90 [cfg80211]
  Call Trace:
   iwl_mvm_init_mcc+0x170/0x190 [iwlmvm]
   iwl_op_mode_mvm_start+0x824/0xa60 [iwlmvm]
   iwl_opmode_register+0xd0/0x130 [iwlwifi]
   init_module+0x23/0x1000 [iwlmvm]

Fix this by adding the missing rtnl_lock() back to the code.

Fixes: eb09ae93 ("iwlwifi: mvm: load regdomain at INIT stage")
Link: https://lore.kernel.org/lkml/CAHk-=wjB_zBwZ+WR9LOpvgjvaQn=cqryoKigod8QnZs=iYGEhA@mail.gmail.com/Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The new version sends station id in the notification. It's still not
used, but need to adjust the code since the offset of the data was
changed.
Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210826224715.87bc9e45c40b.I770493dc4a293ed8bdf059518e94dccf5dd1b3a7@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

We used to load the regdomain only in the load stage,
this caused the 'iw phy phy0 reg get' command to fail if we
booted a machine with wifi off.
Therefor we should load it in INIT stage already.
Signed-off-by: NMiri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210805141826.a6077801d7d5.I7d8d5c895bc467efbf81ea055dde366ea01cced1@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

We used to read the PPAG, WRDS, EWRD, WGDS tables from ACPI
in the load stage only. This prevented vendor commands from
being executed before bringing the interface up. Move reading those tables
to INIT stage.
Signed-off-by: NMiri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210805141826.ce3b60f0b426.I3643bf00e714aae930880cc7d6cf390b142eaccb@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

With recent changes in the firmware SRAM debug during D3 is
enabled by default and need not be enabled by driver.
cleaning the code to align the same.
Signed-off-by: NMukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210802215208.8535203d0ef7.Ib1695ce5de921b0472d0b1052e729e071573b863@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

When TVQM is enabled (iwl_mvm_has_new_tx_api() is true), then
queue numbers are just sequentially assigned 0, 1, 2, ...
Prior to TVQM, in DQA, there were some statically allocated
queue numbers:
 * IWL_MVM_DQA_AUX_QUEUE == 1,
 * both IWL_MVM_DQA_INJECT_MONITOR_QUEUE and
   IWL_MVM_DQA_P2P_DEVICE_QUEUE == 2, and
 * IWL_MVM_DQA_AP_PROBE_RESP_QUEUE == 9.

Now, these values are assigned to the members mvm->aux_queue,
mvm->snif_queue, mvm->probe_queue and mvm->p2p_dev_queue by
default. Normally, this doesn't really matter, and if TVQM is
in fact available we override them to the real values after
allocating a queue for use there.

However, this allocation doesn't always happen. For example,
for mvm->p2p_dev_queue (== 2) it only happens when the P2P
Device interface is started, if any. If it's not started, the
value in mvm->p2p_dev_queue remains 2. This wouldn't really
matter all that much if it weren't for iwl_mvm_is_static_queue()
which checks a queue number against one of those four static
numbers.

Now, if no P2P Device or monitor interface is added then queue
2 may be dynamically allocated, yet alias mvm->p2p_dev_queue or
mvm->snif_queue, and thus iwl_mvm_is_static_queue() erroneously
returns true for it. If it then gets full, all interface queues
are stopped, instead of just backpressuring against the one TXQ
that's really the only affected one.

This clearly can lead to issues, as everything is stopped even
if just a single TXQ filled its corresponding HW queue, if it
happens to have an appropriate number (2 or 9, AUX is always
reassigned.) Due to a mac80211 bug, this also led to a situation
in which the queues remained stopped across a deauthentication
and then attempts to connect to a new AP started failing, but
that's fixed separately.

Fix all of this by simply initializing the queue numbers to
the invalid value until they're used, if TVQM is enabled, and
also setting them back to that value when the queues are later
freed again.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210802172232.2e47e623f9e2.I9b0830dafbb68ef35b7b8f0f46160abec02ac7d0@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

The firmware SMPS request should only be honoured if the
connection is currently with HE and on 160 MHz, so check
that and then potentially reapply any request if the BW
changes.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210802172232.0cdcac5660da.I9ee7956fd4f48399855d1f97728bc58b36caf112@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

In some cases it may be necessary to synchronously create
a firmware error report, add the necessary infrastructure
for this.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210802170640.481b6642f0fc.I7c9c958408a285e3d19aceed2a5a3341cfc08382@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

If the firmware crashes while we're already shutting down
the system, there isn't much we can do since the shutdown
process is continuing and we wanted to do that. Don't do
a FW restart, with the implied debug collection, in this
case.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210802170640.43a7351ae6bd.I164d48ce4379accf76ea0637983fd946d52dc6f5@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

The firmware can now request SMPS (due to thermal conditions), add
some code to honour such requests and bubble them up through the
stack, subject to our other SMPS constraints, e.g. from Bluetooth.

Then, if the firmware requests SMPS, then we know that it supports
a small extension to the PHY configuration API where a chain mask
of 0 means "use 1 but pick which one yourself", so in this case we
use that extension.

During firmware restart, we stay in the previous state, and the FW
will send us a notification at startup (only) if the temperature is
below the lower or above the high threshold, to sync the state.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210617100544.85656b7684b9.I7a661a0758d070a750d3a91874d1a0f5fab9febc@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

We don't use this command anymore and it is going to be removed from
the FW.  Remove all related definitions.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210612142637.549b282ae9a4.Iced05882d73b869e19f50e6a6e7bf9ce6cd7899b@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

We don't need the NVM until fairly late in the flow and
since this flow will be split soon, get the NVM later to
unite it with the parts that really need it.
Gather all what needs the NVM into a function.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210210171218.bab0e65c4909.I789f3eb577b216ad1688269e036ce9fa4880f532@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

This will soon be a bit more complicated. Take it out
to a function.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210210171218.431f31a86ea0.I9db96647eb9c7142051e26cd5be3f52c5ffc5534@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

No need to pass the dbgfs_dir just to assign it to mvm.
Assign to mvm and then call iwl_mvm_dbgfs_register.

This is a preparation towards the addition of a delayed
op_mode_start flow.
This will allow to split the op_mode_start flow.
Registration to debugfs must happen after we register to
mac80211 and the registration to mac80211 will soon be
delayed in certain cases. In order not to have to remember
the debugfs_dir in a separate variable, just set it into
the mvm structure so that it can be usable later.

Declare mvm->debugfs_dir in the iwl_mvm structure even when
IWLWIFI_DEBUGFS isn't enabled to simplify the source code.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210210171218.a92ee491863d.I047923aa3598fbf4fb6fce2cdff75a4969fedd76@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

All the actions that were taken after the registration can
be taken before the registration to mac80211.
This will help to defer part of the op_mode_mvm_start
function to a later stage in case the device is not
available.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210210171218.c03cc5db67c1.Ia928ca34d25a73d959a345ffbe4f1217c3f17394@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

The first use is collecting debug data when transport stops the device.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210210142629.d282d0a9ee7b.I9a0ad29f80daba8956a6aa077ba865e19b2150be@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

If there are frequent CCA delays due to the extension channel
as detected by the firmware, and we're on 2.4 GHz, then handle
this by disconnecting (with a reconnect hint).

When we disconnect, we'll also update our capabilities to use
only 20 MHz on the next connection (if it's on 2.4 GHz) as to
avoid the use of the extension channel that has too much noise.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.4de9c363b0b5.I709b7e6f73a7537c53f22d7418927691259de8a8@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

For testing features where the firmware may send some
notifications it can often be a lot easier to do that
from a test script. Remove most injection limitations
from debugfs to be able to do this.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.9aff3c6b4607.I03b0ae7df094734451445ffcb7f9f0274969f1c0@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

We shouldn't trust the firmware with the sizes (or contents)
of notifications, accessing too much data could cause page
faults if the data doesn't fit into the allocated space. This
applies more on older NICs where multiple notifications can
be in a single RX buffer.

Add a general framework for checking a minimum size of any
notification in the RX handlers and use it for most. Some RX
handlers were already checking and I've moved the checks,
some more complex checks I left and made them _NO_SIZE for
the RX handlers.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.3e155d5e5f90.I2121fa4ac7cd7eb98970d84b793796646afa3eed@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

If we get into a problem severe enough to attempt a reprobe,
we schedule a worker to do that. However, if the problem gets
more severe and the device is actually destroyed before this
worker has a chance to run, we use a free device. Bump up the
reference count of the device until the worker runs to avoid
this situation.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20210122144849.871f0892e4b2.I94819e11afd68d875f3e242b98bef724b8236f1e@changeid

Having sta_id not set for aux_sta and snif_sta can potentially lead to a
hard to debug issue in case remove station is called without an add. In
this case sta_id 0, an unrelated regular station, will be removed.

In fact, we do have a FW assert that occures rarely and from the debug
data analysis it looks like sta_id 0 is removed by mistake, though it's
hard to pinpoint the exact flow. The WARN_ON in this patch should help
to find it.
Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20210122144849.5dc6dd9b22d5.I2add1b5ad24d0d0a221de79d439c09f88fcaf15d@changeid

The RX handlers for probe response data and channel switch weren't
hooked up properly, fix that.

Fixes: 86e177d8 ("iwlwifi: mvm: add NOA and CSA to a probe response")
Fixes: d3a108a4 ("iwlwifi: mvm: Support CSA countdown offloading")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.2d07dcee0d35.I07a61b5d734478db57d9434ff303e4c90bf6c32b@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>