Merge ath-next from git://git./linux/kernel/git/kvalo/ath.git

ath.git patches for v5.17. Major changes:

ath11k

* qca6390/wcn6855: report signal and tx bitrate

* qca6390: rfkill support

* qca6390/wcn6855: regdb.bin support

ath5k

* switch to rate table based lookup

ath11k: Fix unexpected return buffer manager error for QCA6390

We are seeing below error on QCA6390:
...
[70211.671189] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22
[70212.696154] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22
[70213.092941] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22
...

The reason is that, with commit 734223d78428 ("ath11k: change return
buffer manager for QCA6390"), ath11k expects the return buffer manager
(RBM) field of descriptor configured as HAL_RX_BUF_RBM_SW1_BM when
parsing error frames from WBM2SW3_RELEASE ring. This is a wrong change
cause the RBM field is set as HAL_RX_BUF_RBM_SW3_BM.

The same issue also applies to REO2TCL ring though we have not got any
error reported.

Fix it by changing RBM from HAL_RX_BUF_RBM_SW1_BM to HAL_RX_BUF_RBM_SW3_BM
for these two rings.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1

Fixes: 734223d78428 ("ath11k: change return buffer manager for QCA6390")
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211222013536.582527-1-quic_bqiang@quicinc.com

ath11k: add support of firmware logging for WCN6855

Host enables WMI firmware logging feature via QMI message.
Host receives firmware logging messages on WMI_DIAG_EVENTID, then
sends logging messages to user space via event tracing infrastructure.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1

Signed-off-by: Cheng Wang <quic_chengwan@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211220121053.357087-1-quic_chengwan@quicinc.com

ath11k: Fix napi related hang

Similar to the same bug in ath10k, a napi disable w/out it being enabled
will hang forever.  I believe I saw this while trying rmmod after driver
had some failure on startup.  Fix it by keeping state on whether napi is
enabled or not.

And, remove un-used napi pointer in ath11k driver base struct.

Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20200903195254.29379-1-greearb@candelatech.com

ath10k: replace strlcpy with strscpy

The strlcpy should not be used because it doesn't limit the source
length. So that it will lead some potential bugs.

But the strscpy doesn't require reading memory from the src string
beyond the specified "count" bytes, and since the return value is
easier to error-check than strlcpy()'s. In addition, the implementation
is robust to the string changing out from underneath it, unlike the
current strlcpy() implementation.

Thus, replace strlcpy with strscpy.

Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211221070931.725720-1-wangborong@cdjrlc.com

rtw88: support SAR via kernel common API

Register cfg80211_sar_capa with type NL80211_SAR_TYPE_POWER and four
frequency ranges for configurations in unit of 0.25 dBm. And handle
callback set_sar_specs.

Originally, TX power has three main parameters, i.e. power base,
power by rate, and power limit. The formula can be simply considered
as TX power = power base + min(power by rate, power limit). With the
support of SAR which can be treated as another power limit, there is
one more parameter for TX power. And the formula will evolve into
TX power = power base + min(power by rate, power limit, power sar).

Besides, debugfs tx_pwr_tbl is also refined to show SAR information.
The following is an example for the difference.
Before supporting SAR,
-----------------------------------
...
path rate       pwr       base      (byr  lmt ) rem
   A  CCK_1M     66(0x42)   78  -12 (  12  -12)    0
   A  CCK_2M     66(0x42)   78  -12 (   8  -12)    0
...
-----------------------------------
After supporting SAR and making some configurations,
-----------------------------------
...
path rate       pwr       base      (byr  lmt  sar ) rem
   A  CCK_1M     62(0x3e)   78  -16 (  12  -12  -16)    0
   A  CCK_2M     62(0x3e)   78  -16 (   8  -12  -16)    0
...
-----------------------------------

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211220093656.65312-1-pkshih@realtek.com

rtw88: 8822c: add ieee80211_ops::hw_scan

Declare this function allows us to use customized scanning policy.
By doing so we can be more time efficient on each scan. In order to
make existing coex mechanism work as usual, firmware notifies driver
on each channel switch event, then decide antenna ownership based on
the current channel/band. Do note that this new mechanism affects
throughput more than the sw_scan we used to have, but the overall
average throughput is not affected since each scan take less time.
Since the firmware size is limited, we only support probe requests
with custom IEs length under 128 bytes for now, if any user space
tools requires more than that, we'll introduce related changes
afterwards. For backward compatibility, we fallback to sw_scan when
using older firmware that does not support this feature.

Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211221085010.39421-1-pkshih@realtek.com

Merge tag 'iwlwifi-next-for-kalle-2021-12-21-v2' of git://git./linux/kernel/git/iwlwifi/iwlwifi-next

wlwifi patches for v5.17 v2

* Support for Time-Aware-SAR (TAS) as read from the BIOS;
* Fix scan timeout issue when 6GHz is enabled;
* Work continues for new HW family Bz;
* Support for Optimized Connectivity Experience (OCE) scan;
* A bunch of FW debugging improvements and fixes;
* Fix one 32-bit compilation issue;
* Some RX changes for new HW family
* Some fixes for 6 GHz scan;
* Fix SAR table fixes with newer platforms;
* Fix early restart crash;
* Small fix in the debugging code;
* Add new Killer device IDs;
* Datapath updates for Bz family continues;
* A couple of important fixes in iwlmei;
* Some other small fixes, clean-ups and improvements.

iwlwifi: mei: wait before mapping the shared area

The shared area is a DMA memory allocated in the host and
mapped so that the host and the CSME firmware can
exchange data. It is mapped through a dedicated PCI device
that is driven by the mei bus driver.

The bus driver is in charge of allocating and mapping this
memory. It also needs to configure the CSME firmware with
a specific set of commands, so that the CSME firmware will
know that this memory is meant to be used by its internal
WLAN module.

For this, the CSME firmware first needs to completely
initialize its WLAN module and only then get the mapping
request.

The problem is that the mei bus enumeration completes
before the WLAN is completely ready. This means that
the WLAN module's initialization is racing with iwlmei's
allocation and mapping flow.

Testing showed a problem in resume flows where iwlmei
was too fast and the DMA mapping failed.

Add a delay to avoid this. This is still racy, but our
measurements showed that we have a good margin and we
should now be safe.

Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211220142940.8b6279e3d0be.I6fe128b0b86149a85535104822c8355b367887c8@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mei: clear the ownership when the driver goes down

When the driver is unregistered, CSME will take ownership on the
device. Reflect this in the iwlmei object so that we will remember
to re-ask for ownership when the driver will register again.

Not doing so will cause CSME not to give the host ownership and
we will see the following error message when trying to bring up
the interface:

iwlwifi 0000:a9:00.0: iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
iwlwifi 0000:a9:00.0: iwl_pcie_set_hw_ready hardware not ready
iwlwifi 0000:a9:00.0: iwl_pcie_set_hw_ready hardware not ready
iwlwifi 0000:a9:00.0: iwl_pcie_prepare_card_hw Couldn't prepare the card but SAP is connected
iwlwifi 0000:a9:00.0: Error while preparing HW: -16

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211220142940.c7bb5b7644df.I48498d9fd6e3959562205af67aa5f1a822eb762d@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: yoyo: fix issue with new DBGI_SRAM region read.

NIC has been grabbed for reading twice which is leading
to NIC hang. Code correction are done for reading data with
no grab function.

Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.55527214f8c9.I1748215ccb3fa20a3491a46a49b12e04eb560ac6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: fw: fix some scan kernel-doc

Some devices also use iwl_scan_config_v2 struct, so link it in
the documentation for SCAN_CFG_CMD. Fix a bunch of kernel-doc
as well.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.3331df94b106.If6c96b0d386e1c5988c8da6b69257e8f2e737f07@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: pcie: make sure prph_info is set when treating wakeup IRQ

In some rare cases when the HW is in a bad state, we may get this
interrupt when prph_info is not set yet.  Then we will try to
dereference it to check the sleep_notif element, which will cause an
oops.

Fix that by ignoring the interrupt if prph_info is not set yet.

Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.0537aa562313.I183bb336345b9b3da196ba9e596a6f189fbcbd09@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: remove card state notification code

This notification ID was actually used for something else we
never implemented, but luckily we only had some debug code
here. Just remove it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.a67b5b9db259.Ic55b306fcd2a3525b3993f4b7e00622dd95053ba@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: drop too short packets silently

There's little value in this warning, we get a warning here
if firmware passes us a short packet, particularly in monitor
mode.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.305d12cf51ac.I2e4e6874113b1e5d8ee467b8a2d90820cc6ddde9@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: fix AUX ROC removal

When IWL_UCODE_TLV_CAPA_SESSION_PROT_CMD is set, removing a time event
always tries to cancel session protection. However, AUX ROC does
not use session protection so it was never removed. As a result,
if the driver tries to allocate another AUX ROC event right after
cancelling the first one, it will fail with a warning.
In addition, the time event data passed to iwl_mvm_remove_aux_roc_te()
is incorrect. Fix it.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.915e1f69f062.Id837e917f1c2beaca7c1eb33333d622548918a76@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: return op_mode only in case the failure is from MEI

Currently we always return the op_mode with valid pointer in case
getting NVM failed, while it's only relevant for cases that CSME is the
owner of the nic.

Fix this by checking also who's the owner of the nic.

Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.b1e96021b616.Id0164855f2dd01ecdecf79b239d6ee5974882245@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: support Bz TX checksum offload

Support TX checksum offload for Bz devices, where we have full
checksum offload (NETIF_F_HW_CSUM) and the hardware doesn't
need to parse the IP headers or anything.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.c0f44c98b36d.I75a688f3ac80cbe824c459ece4bb67843b9fce76@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: add US/CA to TAS block list if OEM isn't allowed

If OEM isn't in the allowed list, TAS should be disabled in US/CA.
Currently, if the OEM isn't allowed - we're sending the TAS only
if we are not in US or CA.
But this country check is done before we even know the country
(usually the configuration is ZZ in that stage).
So do the following instead:
1. Check if the current OEM is in the allowed list
2. If not - add US and CA to tas_block_list_array
3. Send the TAS table to FW.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: correctly set schedule scan profiles

Set scan offload profiles auth algorithms with valid
algorithms only.

Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.525f2d468d22.I4d497d6a0a14ffb833f7edc7e980d26bbf8d7527@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: set protected flag only for NDP ranging

Don't use protected ranging negotiation for FTM ranging as responders
that support only FTM ranging don't expect the FTM request to be
protected.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Fixes: 517a5eb9fab2 ("iwlwifi: mvm: when associated with PMF, use protected NDP ranging negotiation")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.f50ed0e3c6b3.Ibff247ee9d4e6e0a1a2d08a3c8a4bbb37e6829dd@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: pcie: add killer devices to the driver

add killer subsystem devices from the 1675i and 1675s family
to the driver.

Signed-off-by: Yaara Baruch <yaara.baruch@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.2d5bec2d7b68.Icffb4e27390e6a5c76a0cbe7abf7472558f323d6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: perform 6GHz passive scan after suspend

The 6GHz passive scan is performed only once every 50 minutes.
However, in case of suspend/resume, the regulatory information
is reset, so 6GHz channels may become disabled.
Fix it by performing a 6GHz passive scan within 60 seconds after
suspend/resume even if the 50 minutes timeout did not expire yet.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Fixes: e8fe3b41c3a3 ("iwlwifi: mvm: Add support for 6GHz passive scan")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.6d5c043372cf.I251dd5618a3f0b8febbcca788eb861f1cd6039bc@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: correctly set channel flags

In case of forced passive scan on a UHB channel,
don't set the direct probe option for this channel.

Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.0ede76a9ca92.Ie64a4df79ea9c485ae3d2fc043319e8f79cefa8e@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: always store the PPAG table as the latest version.

In case of a conflict between BIOS version and FW
version of the PPAG table - the values arrive in the FW in the wrong
places. This happens because we're storing the table in different
structures depending on the BIOS version, not on the FW version,
and so the FW doesn't get what it expect to.
Always store the table in a v2 structure (which is a superset
of v1 and v0).

Also store the table in a structured way and in it's own structure,
rather then storing it in the ppag command structure, similarly to
the WRDS, EWRD and WGDS tables.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.793a509da7bd.Ia176746a28b816b5f788cce9a281139735909e2a@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: bump FW API to 69 for AX devices

Start supporting API version 69 for AX devices.

Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.7d8fe0dffaea.I2de65c1efd9ab464d4158a3d852f73efe63024f8@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: Fix calculation of frame length

The RADA might include in the Rx frame the MIC and CRC bytes.
These bytes should be removed for non monitor interfaces and
should not be passed to mac80211.

Fix the Rx processing to remove the extra bytes on non monitor
cases.

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.098be12c801e.I1d81733d8a75b84c3b20eb6e0d14ab3405ca6a86@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: test roc running status bits before removing the sta

In some cases the sta is being removed twice since we do not test the
roc aux running before removing it. Start looking at the bit before
removing the sta.

Signed-off-by: Nathan Errera <nathan.errera@intel.com>
Fixes: 2c2c3647cde4 ("iwlwifi: mvm: support ADD_STA_CMD_API_S ver 12")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d5376ac6bcb0.Ic5f8470ea60c072bde9d1503e5f528b65e301e20@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: don't pass actual WGDS revision number in table_revision

The FW API for PER_CHAIN_LIMIT_OFFSET_CMD is misleading.  The element
name is table_rev, but it shouldn't actually contain the table
revision number, but whether we should use the South Korea scheme or
not.

Fix the driver so that we only set this value to either 0 or 1.  It
will only be 1 (meaning South Korea) if the ACPI WGDS table revision
is 1.

Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Fixes: 664c011b763e ("iwlwifi: acpi: support reading and storing WGDS revision 2")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.abed3b8119c7.I1fdc2c14577523fcffdfe8fb5902c2d8efde7e09@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: yoyo: support TLV-based firmware reset

Support resetting the firmware via TLV-based debugging.  When applied,
this will cause the driver to reset the firmware when the debugging
is triggered.

Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d59b29653a1e.I7b3be4a1ad1a9d5d0e86259740e89ac113c9348b@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: change old-SN drop threshold

Increment the threshold to avoid dropping too eagerly.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.0e947ed458c4.Ia376cbea5f59df4b4474f0bd33ab033e84535cce@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: don't trust hardware queue number

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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.539aecb91247.I6e555a5185bad30d7d1a4659f9c0b99325425f18@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: handle RX checksum on Bz devices

On Bz devices, the hardware checksums including the SNAP header,
starting directly after the MAC header, so we don't need the
extra checks and can just pass the checksum to mac80211.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.8ef59da4e05e.Ide87c2dc8fa08eae55c013a625f4ece5184b1b63@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: use a define for checksum flags mask

For the upcoming Bz devices, we will set NETIF_F_HW_CSUM instead
of NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM. However, we still need
to be able to remove all the checksum bits, so add a mask for the
removal, and keep the old define for the feature advertisement.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.f05488ce8b83.I65bb83721498d8433e4ee2b09415eb74ab579445@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: remove module loading failure message

When CONFIG_DEBUG_TEST_DRIVER_REMOVE is set, iwlwifi crashes
when the opmode module cannot be loaded, due to completing
the completion before using drv->dev, which can then already
be freed.

Fix this by removing the (fairly useless) message. Moving the
completion later causes a deadlock instead, so that's not an
option.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/20211210091245.289008-2-luca@coelho.fi
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: isolate offload assist (checksum) calculation

Isolate the entire calculation of the offload_assist field used
for HW checksumming to the iwl_mvm_tx_csum function.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.796ae29c90d9.Icb2f07905bebd9ed4537ca4c453069211ea71799@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: add support for OCE scan

In case the fw supports OCE scan and one of the OCE feature flags
are set in the scan request, set the corresponding flag in the
firmware scan request.
Note that new firmware that indicates OCE support does not support
the probe deferral and suppression feature (which is optional).

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.3dd63c381839.Id79b39f650103bb9b851e31ed6a0178e81988587@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: fix leaks/bad data after failed firmware load

If firmware load fails after having loaded some parts of the
firmware, e.g. the IML image, then this would leak. For the
host command list we'd end up running into a WARN on the next
attempt to load another firmware image.

Fix this by calling iwl_dealloc_ucode() on failures, and make
that also clear the data so we start fresh on the next round.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.1f742f0eb58a.I1315f22f6aa632d94ae2069f85e1bca5e734dce0@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: fix debug TLV parsing

Debug TLV parsing was missing size checks, so if a valid but
too short TLV was encountered, it would attempt to read it.
If the firmware file was arranged to be a multiple of pages
long with this happening just before the end, it could crash
reading out-of-bounds of a vmalloc area.

Fix this by adding the relevant size check.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.84848da8067f.Ifb4f80c95d283ec62e495a7928069af711b5fee2@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: fix 32-bit build in FTM

On a 32-bit build, the division here needs to be done
using do_div(), otherwise the compiler will try to call
a function that doesn't exist, thus failing to build.

Fixes: b68bd2e3143a ("iwlwifi: mvm: Add FTM initiator RTT smoothing logic")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219111352.e56cbf614a4d.Ib98004ccd2c7a55fd883a8ea7eebd810f406dec6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: dump RCM error tables

There's another set of error tables on newer (Bz) hardware,
support finding and dumping those error tables if present.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.c727a975b434.Ie5ad3fd974b700f1b90867b2b52ef7607799e8fe@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: dump both TCM error tables if present

There can be two TCMs in a given device, dump both of the
error tables if present.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.887cba319301.Ifdc3f617f7e0e3e39c90e8c208e60f11b3bb9404@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: dump CSR scratch from outer function

We shouldn't dump this twice if we have two TCMs, and it really
doesn't belong to the TCM dump anyway, so move this out.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.b58a02f27512.Idbfbc430776a7abda0eb086215fb64f2c9307ac0@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: parse error tables from debug TLVs

With more things being added, we're no longer going to duplicate
the error tables from the debug TLVs nor send them at runtime.
Use the debug TLVs to find the locations of the error tables. As
we've never released firmware using IWL_UCODE_TLV_TCM_DEBUG_ADDRS
just remove that entirely.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.779d68490f68.I472c7d9cbaca46000a10ec18808ef54836b33a8a@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: Increase the scan timeout guard to 30 seconds

With the introduction of 6GHz channels the scan guard timeout should
be adjusted to account for the following extreme case:

- All 6GHz channels are scanned passively: 58 channels.
- The scan is fragmented with the following parameters: 3 fragments,
  95 TUs suspend time, 44 TUs maximal out of channel time.

The above would result with scan time of more than 24 seconds. Thus,
set the timeout to 30 seconds.

Cc: stable@vger.kernel.org
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.3c851b93aef5.I346fa2e1d79220a6770496e773c6f87a2ad9e6c4@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: recognize missing PNVM data and then log filename

We can detect that a FW SYSASSERT is due to missing PNVM data by
checking the assertion code.  When this happens, it's is useful for
the user if we print the filename where the driver is looking for the
data.

Add the PNVM missing assertion code to the dump list and print out the
name of the file we're looking for when this happens.

Reported-by: Sam Edwards <CFSworks@gmail.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.1d8725b7518a.I0c36617a7282bd445cda484d97ac4a83022706ee@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: rs: add support for TLC config command ver 4

The new version enables support for EHT mode configurations.

The name of IWL_TLC_HT_BW_NONE_160 change to IWL_TLC_MCS_PER_BW_80
to make the difference from 80 bandwidth (non 160), and the new bandwidth
320 which is also non 160.

Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.7d1a57f3df1b.Ibc01dde2b064329ad5f5bcefa83d1998d557cbdb@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: rfi: update rfi table

After some lab experimentation with different DDRs, need
to update the table. Also, arrange it by frequency and not
by DDR type since now the table contains a super-set of all
possible conflicts.

Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.6f2fca102739.I8b5e37a00c50b7b51f7d377216dde91e71faffba@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: add support for BNJ HW

Add support for BNJ HW with GF, GF4, HR1, FM and FM4 RF modules

Signed-off-by: Mike Golant <michael.golant@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.e94c1f921245.I8cba209b1366dc0636a04711fc6a85539ca878d0@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: Add list of OEMs allowed to use TAS

Add list of vendors that are allowed to use TAS and check it
against the value provided in the SMBIOS manufacturer field.
Initially add the following approved vendors: HP, Dell, Lenovo and Samsung.

Signed-off-by: Ayala Barazani <ayala.barazani@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.27fe6abf2e4c.I806e4b47dabddaa8ac27172e7cfa3d719c100e8f@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: support revision 1 of WTAS table

A new revision of WTAS was added in order to support
IEC optimisation. Add support for reading the new revision from ACPI and
passing it to the FW.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.ff455b9d66bd.Ic7c1460e89f6b22101f3c5a2ea438031c7f11771@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: Read the correct addresses when getting the crf id

The original implementation checked the HW family, and as a result
of that used different addresses for the prph registers.

The old HWs addresses start with 0xa****** and the newer
ones start with 0xd******.

For this there are iwl_read/write_umac_prph functions that just add the

diff in the address automatically (in this case 0x300000), so the code will
be common for all HWs

In the original implementation the address given already had the 0xd******
causing the address to become 0x10***** (after adding the offset)

Change the registers to start with 0xa*****.

Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.db2722547eb2.I03dce63698befc2fd9105111c3015b8d6e36868a@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: pcie: add jacket bit to device configuration parsing

Some devices have same HW ID's and the only way to differentiate them is
by checking the jacket bit.

Signed-off-by: Mike Golant <michael.golant@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.cffa843734d3.I01963e494c459efde5d909c1085cd561e0df9df9@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: fw: remove dead error log code

The struct iwl_error_event_table_v1 is unused, remove it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.eb33452fcdc6.I8133ef3aaa0234cb116189c87d22c3f10235105e@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: fix Bz NMI behaviour

Contrary to what was stated before, the hardware hasn't changed
the bits here yet. In any case, the new CSR is also directly
(lower 16 bits) connected to UREG_DOORBELL_TO_ISR6, so if it
still changes the changes would be there. Adjust the code and
comments accordingly.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes: 6c0795f1a524 ("iwlwifi: implement Bz NMI behaviour")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210090244.75b6207536e3.I7d170a48a9096e6b7269c3a9f447c326f929b171@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: do not use __unused as variable name

On various systems __unused is a define to __attribute__((__unused__))
and yields compile errors as a result. Use __spare instead to describe
that these bits are "unused".

Sponsored by:  The FreeBSD Foundation
Signed-off-by: Bjoern A. Zeeb <bz@FreeBSD.ORG>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: iwl-eeprom-parse: mostly dvm only

Most of iwl-eeprom-parse.c is only used for dvm but not for mvm.
Hide the parts under #if IS_ENABLED(CONFIG_IWLDVM) to reduce size
and code surface for mvm-only builds.

Sponsored by:  The FreeBSD Foundation
Signed-off-by: Bjoern A. Zeeb <bz@FreeBSD.ORG>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: clean up indenting in iwl_mvm_tlc_update_notif()

These lines need to be indented one more tab.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211110080922.GF5176@kili
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

iwlwifi: mvm: fix a stray tab

This line was indented too far and was a bit confusing.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211110080759.GE5176@kili
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

ath11k: add regdb.bin download for regdb offload

The regdomain is self-managed type for ath11k, the regdomain info is
reported from firmware, it is not from wireless regdb. Firmware fetch
the regdomain info from board data file before. Currently most of the
regdomain info has moved to another file regdb.bin from board data
file for some chips such as QCA6390 and WCN6855, so the regdomain info
left in board data file is not enough to support the feature which need
more regdomain info.

After download regdb.bin, firmware will fetch the regdomain info from
regdb.bin instead of board data file and report to ath11k. If it does
not have the file regdb.bin, it also can initialize wlan success and
firmware then fetch regdomain info from board data file.

Add download the regdb.bin before download board data for some specific
chip which support supports_regdb in hardware parameters.

download regdb.bin log:
[430082.334162] ath11k_pci 0000:05:00.0: chip_id 0x2 chip_family 0xb board_id 0x106 soc_id 0x400c0200
[430082.334169] ath11k_pci 0000:05:00.0: fw_version 0x110c8b4c fw_build_timestamp 2021-10-25 07:41 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HSP.1.1-02892-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
[430082.334414] ath11k_pci 0000:05:00.0: boot firmware request ath11k/WCN6855/hw2.0/regdb.bin size 24310

output of "iw reg get"
global
country US: DFS-FCC
        (2402 - 2472 @ 40), (N/A, 30), (N/A)
        (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
        (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
        (5735 - 5835 @ 80), (N/A, 30), (N/A)
        (57240 - 63720 @ 2160), (N/A, 40), (N/A)

phy#0 (self-managed)
country US: DFS-FCC
        (2402 - 2472 @ 40), (6, 30), (N/A)
        (5170 - 5250 @ 80), (N/A, 24), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
        (5490 - 5730 @ 160), (N/A, 24), (0 ms), DFS, AUTO-BW
        (5735 - 5895 @ 160), (N/A, 30), (N/A), AUTO-BW
        (5945 - 7125 @ 160), (N/A, 24), (N/A), NO-OUTDOOR, AUTO-BW

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1

Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211220062355.17021-1-quic_wgong@quicinc.com

rtlwifi: rtl8192cu: Fix WARNING when calling local_irq_restore() with interrupts enabled

Syzbot reports the following WARNING:

[200~raw_local_irq_restore() called with IRQs enabled
WARNING: CPU: 1 PID: 1206 at kernel/locking/irqflag-debug.c:10
   warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10

Hardware initialization for the rtl8188cu can run for as long as 350 ms,
and the routine may be called with interrupts disabled. To avoid locking
the machine for this long, the current routine saves the interrupt flags
and enables local interrupts. The problem is that it restores the flags
at the end without disabling local interrupts first.

This patch fixes commit a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long
disable of IRQs").

Reported-by: syzbot+cce1ee31614c171f5595@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Fixes: a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long disable of IRQs")
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211215171105.20623-1-Larry.Finger@lwfinger.net

rtl8xxxu: Improve the A-MPDU retransmission rate with RTS/CTS protection

The A-MPDU TX retransmission rate is always high (> 20%) even in a very
clean environment. However, the vendor driver retransimission rate is
< 10% in the same test bed. The difference is the vendor driver starts
the A-MPDU TXOP with initial RTS/CTS handshake which is observed in the
air capture and the TX descriptor. Since the driver does not know how
many frames will be aggregated and the estimated duration, forcing the
RTS/CTS protection for A-MPDU helps to lower the retransmission rate
from > 20% to ~12% in the same test setup with the vendor driver.

Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211215085819.729345-1-chris.chiu@canonical.com

rtw88: 8822c: update rx settings to prevent potential hw deadlock

These settings enables mac to detect and recover when rx fifo
circuit deadlock occurs. Previous version missed this, so we fix it.

Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211217012708.8623-1-pkshih@realtek.com

rtw88: don't check CRC of VHT-SIG-B in 802.11ac signal

Currently all realtek wifi chip is set to check CRC of VHT-SIG-B
in 802.11ac signal, but some AP don't calculate the CRC and packets
from these AP can't be received and lead to disconnection.
We disable the check defaultly to avoid this case.

Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211217012421.7859-1-pkshih@realtek.com

rtw88: Disable PCIe ASPM while doing NAPI poll on 8821CE

Many Intel based platforms face system random freeze after commit
9e2fd29864c5 ("rtw88: add napi support").

The commit itself shouldn't be the culprit. My guess is that the 8821CE
only leaves ASPM L1 for a short period when IRQ is raised. Since IRQ is
masked during NAPI polling, the PCIe link stays at L1 and makes RX DMA
extremely slow. Eventually the RX ring becomes messed up:
[ 1133.194697] rtw_8821ce 0000:02:00.0: pci bus timeout, check dma status

Since the 8821CE hardware may fail to leave ASPM L1, manually do it in
the driver to resolve the issue.

Fixes: 9e2fd29864c5 ("rtw88: add napi support")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215131
BugLink: https://bugs.launchpad.net/bugs/1927808
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Jian-Hong Pan <jhp@endlessos.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211215114635.333767-1-kai.heng.feng@canonical.com

wilc1000: fix double free error in probe()

Smatch complains that there is a double free in probe:

drivers/net/wireless/microchip/wilc1000/spi.c:186 wilc_bus_probe() error: double free of 'spi_priv'
drivers/net/wireless/microchip/wilc1000/sdio.c:163 wilc_sdio_probe() error: double free of 'sdio_priv'

The problem is that wilc_netdev_cleanup() function frees "wilc->bus_data".
That's confusing and a layering violation.  Leave the frees in probe(),
delete the free in wilc_netdev_cleanup(), and add some new frees to the
remove() functions.

Fixes: dc8b338f3bcd ("wilc1000: use goto labels on error path")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211217150311.GC16611@kili

iwlwifi: mvm: fix imbalanced locking in iwl_mvm_start_get_nvm()

If iwl_transt_start_hw() failed, we were returning without calling
wiphy_unlock() and rtnl_unlock(), causing a locking imbalance:

drivers/net/wireless/intel/iwlwifi/mvm/ops.c:686:12: warning: context imbalance in 'iwl_mvm_start_get_nvm' - wrong count at exit

Fix that by adding the unlock calls.

Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211219090128.42417-2-luca@coelho.fi

iwlwifi: mvm: add dbg_time_point to debugfs

We forgot to link this to debugfs, so the code is all dead.
Add it for real.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20211219110000.d0f314101410.I7357c01179c35621686265d4da4a64d2333a5f1a@changeid

iwlwifi: mvm: add missing min_size to kernel-doc

On struct iwl_rx_handlers we should document the min_size
member, do that.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20211219110000.0c42c428bc6b.I8bfa49d534acc5f513f2fb3dff2d6f22f6c45071@changeid

iwlwifi: mei: fix W=1 warnings

There are a few warnings due to kernel-doc not understanding
the constructs the way they're done here, fix them.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20211219110000.1ef2bb24771c.I6a59ad2d64f719d3e27398951c8f1b678b0b1092@changeid

Merge tag 'mt76-for-kvalo-2021-12-18' of https://github.com/nbd168/wireless

mt76 patches for 5.17

* decap offload fixes
* mt7915 fixes
* mt7921 fixes
* eeprom fixes
* powersave handling fixes
* SAR support
* code cleanups

ath11k: add support for hardware rfkill for QCA6390

When hardware rfkill is enabled in the firmware it will report the
capability via using WMI_SYS_CAP_INFO_RFKILL bit in the WMI_SERVICE_READY
event to the host. ath11k will check the capability, and if it is enabled then
ath11k will set the GPIO information to firmware using WMI_PDEV_SET_PARAM. When
the firmware detects hardware rfkill is enabled by the user, it will report it
via WMI_RFKILL_STATE_CHANGE_EVENTID. Once ath11k receives the event it will
send wmi command WMI_PDEV_SET_PARAM to the firmware and also notifies cfg80211.

This only enable rfkill feature for QCA6390, rfkill_pin is all initialized to 0
for other chips in ath11k_hw_params.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1

Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211217102334.14907-1-quic_wgong@quicinc.com

ath11k: report tx bitrate for iw wlan station dump

HTT_T2H_MSG_TYPE_PPDU_STATS_IND is a message which include the ppdu
info, currently it is not report from firmware for ath11k, then the
tx bitrate of "iw wlan0 station dump" always show an invalid value
"tx bitrate: 6.0 MBit/s".

To address the issue, this is to parse the info of tx complete report
from firmware and indicate the tx rate to mac80211.

After that, "iw wlan0 station dump" show the correct tx bit rate such
as:
tx bitrate: 78.0 MBit/s MCS 12
tx bitrate: 144.4 MBit/s VHT-MCS 7 short GI VHT-NSS 2
tx bitrate: 286.7 MBit/s HE-MCS 11 HE-NSS 2 HE-GI 0 HE-DCM 0
tx bitrate: 1921.5 MBit/s 160MHz HE-MCS 9 HE-NSS 2 HE-GI 0 HE-DCM 0

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1

Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211217093722.5739-1-quic_wgong@quicinc.com

ath9k: Fix out-of-bound memcpy in ath9k_hif_usb_rx_stream

Large pkt_len can lead to out-out-bound memcpy. Current
ath9k_hif_usb_rx_stream allows combining the content of two urb
inputs to one pkt. The first input can indicate the size of the
pkt. Any remaining size is saved in hif_dev->rx_remain_len.
While processing the next input, memcpy is used with rx_remain_len.

4-byte pkt_len can go up to 0xffff, while a single input is 0x4000
maximum in size (MAX_RX_BUF_SIZE). Thus, the patch adds a check for
pkt_len which must not exceed 2 * MAX_RX_BUG_SIZE.

BUG: KASAN: slab-out-of-bounds in ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
Read of size 46393 at addr ffff888018798000 by task kworker/0:1/23

CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 5.6.0 #63
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Workqueue: events request_firmware_work_func
Call Trace:
 <IRQ>
 dump_stack+0x76/0xa0
 print_address_description.constprop.0+0x16/0x200
 ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
 ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
 __kasan_report.cold+0x37/0x7c
 ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
 kasan_report+0xe/0x20
 check_memory_region+0x15a/0x1d0
 memcpy+0x20/0x50
 ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
 ? hif_usb_mgmt_cb+0x2d9/0x2d9 [ath9k_htc]
 ? _raw_spin_lock_irqsave+0x7b/0xd0
 ? _raw_spin_trylock_bh+0x120/0x120
 ? __usb_unanchor_urb+0x12f/0x210
 __usb_hcd_giveback_urb+0x1e4/0x380
 usb_giveback_urb_bh+0x241/0x4f0
 ? __hrtimer_run_queues+0x316/0x740
 ? __usb_hcd_giveback_urb+0x380/0x380
 tasklet_action_common.isra.0+0x135/0x330
 __do_softirq+0x18c/0x634
 irq_exit+0x114/0x140
 smp_apic_timer_interrupt+0xde/0x380
 apic_timer_interrupt+0xf/0x20

I found the bug using a custome USBFuzz port. It's a research work
to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only,
providing hand-crafted usb descriptors to QEMU.

After fixing the value of pkt_tag to ATH_USB_RX_STREAM_MODE_TAG in QEMU
emulation, I found the KASAN report. The bug is triggerable whenever
pkt_len is above two MAX_RX_BUG_SIZE. I used the same input that crashes
to test the driver works when applying the patch.

Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/YXsidrRuK6zBJicZ@10-18-43-117.dynapool.wireless.nyu.edu

ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()

syzbot is reporting lockdep warning at ath9k_wmi_event_tasklet() followed
by kernel panic at get_htc_epid_queue() from ath9k_htc_tx_get_packet() from
ath9k_htc_txstatus() [1], for ath9k_wmi_event_tasklet(WMI_TXSTATUS_EVENTID)
depends on spin_lock_init() from ath9k_init_priv() being already completed.

Since ath9k_wmi_event_tasklet() is set by ath9k_init_wmi() from
ath9k_htc_probe_device(), it is possible that ath9k_wmi_event_tasklet() is
called via tasklet interrupt before spin_lock_init() from ath9k_init_priv()
 from ath9k_init_device() from ath9k_htc_probe_device() is called.

Let's hold ath9k_wmi_event_tasklet(WMI_TXSTATUS_EVENTID) no-op until
ath9k_tx_init() completes.

Link: https://syzkaller.appspot.com/bug?extid=31d54c60c5b254d6f75b
Reported-by: syzbot <syzbot+31d54c60c5b254d6f75b@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: syzbot <syzbot+31d54c60c5b254d6f75b@syzkaller.appspotmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/77b76ac8-2bee-6444-d26c-8c30858b8daa@i-love.sakura.ne.jp

ath9k_htc: fix NULL pointer dereference at ath9k_htc_rxep()

syzbot is reporting lockdep warning followed by kernel panic at
ath9k_htc_rxep() [1], for ath9k_htc_rxep() depends on ath9k_rx_init()
being already completed.

Since ath9k_htc_rxep() is set by ath9k_htc_connect_svc(WMI_BEACON_SVC)
 from ath9k_init_htc_services(), it is possible that ath9k_htc_rxep() is
called via timer interrupt before ath9k_rx_init() from ath9k_init_device()
is called.

Since we can't call ath9k_init_device() before ath9k_init_htc_services(),
let's hold ath9k_htc_rxep() no-op until ath9k_rx_init() completes.

Link: https://syzkaller.appspot.com/bug?extid=4d2d56175b934b9a7bf9
Reported-by: syzbot <syzbot+4d2d56175b934b9a7bf9@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: syzbot <syzbot+4d2d56175b934b9a7bf9@syzkaller.appspotmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/2b88f416-b2cb-7a18-d688-951e6dc3fe92@i-love.sakura.ne.jp

ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()

When enable more debug config, it happen below warning. It is because
the caller does not add rcu_read_lock()/rcu_read_unlock() to wrap the
rcu_dereference().

Add rcu_read_lock()/rcu_read_unlock() to wrap rcu_dereference(), then
fixed it.

[ 180.716604] =============================
[ 180.716670] WARNING: suspicious RCU usage
[ 180.716734] 5.16.0-rc4-wt-ath+ #542 Not tainted
[ 180.716895] -----------------------------
[ 180.716957] drivers/net/wireless/ath/ath11k/mac.c:506 suspicious rcu_dereference_check() usage!
[ 180.717023]
               other info that might help us debug this:

[ 180.717087]
               rcu_scheduler_active = 2, debug_locks = 1
[ 180.717151] no locks held by swapper/0/0.
[ 180.717215]
               stack backtrace:
[ 180.717279] CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 5.16.0-rc4-wt-ath+ #542
[ 180.717346] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021
[ 180.717411] Call Trace:
[ 180.717475] <IRQ>
[ 180.717541] dump_stack_lvl+0x57/0x7d
[ 180.717610] ath11k_mac_get_arvif_by_vdev_id+0x1ab/0x2d0 [ath11k]
[ 180.717694] ? ath11k_mac_get_arvif+0x140/0x140 [ath11k]
[ 180.717798] ? ath11k_wmi_tlv_op_rx+0xc1b/0x2520 [ath11k]
[ 180.717888] ? kfree+0xe8/0x2c0
[ 180.717959] ath11k_wmi_tlv_op_rx+0xc27/0x2520 [ath11k]
[ 180.718038] ? ath11k_mgmt_rx_event+0xda0/0xda0 [ath11k]
[ 180.718113] ? __lock_acquire+0xb72/0x1870
[ 180.718182] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370
[ 180.718250] ? sched_clock_cpu+0x15/0x1b0
[ 180.718314] ? find_held_lock+0x33/0x110
[ 180.718381] ? __lock_release+0x4bd/0x9f0
[ 180.718447] ? lock_downgrade+0x130/0x130
[ 180.718517] ath11k_htc_rx_completion_handler+0x38f/0x5b0 [ath11k]
[ 180.718596] ? __local_bh_enable_ip+0xa0/0x110
[ 180.718662] ath11k_ce_recv_process_cb+0x5ac/0x920 [ath11k]
[ 180.718783] ? __lock_acquired+0x205/0x890
[ 180.718864] ? ath11k_ce_rx_post_pipe+0x970/0x970 [ath11k]
[ 180.718949] ? __wake_up_bit+0x100/0x100
[ 180.719020] ath11k_pci_ce_tasklet+0x5f/0xf0 [ath11k_pci]
[ 180.719085] ? tasklet_clear_sched+0x42/0xe0
[ 180.719148] tasklet_action_common.constprop.0+0x204/0x2f0
[ 180.719217] __do_softirq+0x276/0x86a
[ 180.719281] ? __common_interrupt+0x92/0x1d0
[ 180.719350] __irq_exit_rcu+0x11c/0x180
[ 180.719418] irq_exit_rcu+0x5/0x20
[ 180.719482] common_interrupt+0xa4/0xc0
[ 180.719547] </IRQ>
[ 180.719609] <TASK>
[ 180.719671] asm_common_interrupt+0x1e/0x40
[ 180.719772] RIP: 0010:cpuidle_enter_state+0x1f3/0x8d0
[ 180.719838] Code: 00 41 8b 77 04 bf ff ff ff ff e8 78 f1 ff ff 31 ff e8 81 fa 52 fe 80 7c 24 08 00 0f 85 9e 01 00 00 e8 11 13 78 fe fb 45 85 e4 <0f> 88 8c 02 00 00 49 63 ec 48 8d 44 6d 00 48 8d 44 85 00 48 8d 7c
[ 180.719909] RSP: 0018:ffffffffa4607dd0 EFLAGS: 00000202
[ 180.719982] RAX: 00000000002aea91 RBX: ffffffffa4a5fec0 RCX: 1ffffffff49ca501
[ 180.720047] RDX: 0000000000000000 RSI: ffffffffa3c6e4e0 RDI: ffffffffa3dcf2a0
[ 180.720110] RBP: 0000000000000002 R08: 0000000000000001 R09: ffffffffa4e54d17
[ 180.720173] R10: fffffbfff49ca9a2 R11: 0000000000000001 R12: 0000000000000002
[ 180.720236] R13: ffff8881169ccc04 R14: 0000002a13899598 R15: ffff8881169ccc00
[ 180.720321] cpuidle_enter+0x45/0xa0
[ 180.720413] cpuidle_idle_call+0x274/0x3f0
[ 180.720503] ? arch_cpu_idle_exit+0x30/0x30
[ 180.720869] ? tsc_verify_tsc_adjust+0x97/0x2e0
[ 180.720935] ? lockdep_hardirqs_off+0x90/0xd0
[ 180.721002] do_idle+0xe0/0x150
[ 180.721069] cpu_startup_entry+0x14/0x20
[ 180.721134] start_kernel+0x3a2/0x3c2
[ 180.721200] secondary_startup_64_no_verify+0xb0/0xbb
[ 180.721274] </TASK>

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-02892.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1

Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211217064132.30911-1-quic_wgong@quicinc.com

ath11k: add signal report to mac80211 for QCA6390 and WCN6855

IEEE80211_HW_USES_RSS is set in ath11k, then the device uses RSS and
thus requires parallel RX which implies using per-CPU station statistics
in sta_get_last_rx_stats() of mac80211. Currently signal is only set in
ath11k_mgmt_rx_event(), and not set for RX data packet, then it show
signal as 0 for iw command easily.

Change to get signal from firmware and report to mac80211.

For QCA6390 and WCN6855, the rssi value is already in dbm unit, so
don't need to convert it again.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1

Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211216070535.31732-1-quic_wgong@quicinc.com

ath11k: report rssi of each chain to mac80211 for QCA6390/WCN6855

Command "iw wls1 station dump" does not show each chain's rssi currently.

If the rssi of each chain from mon status which parsed in function
ath11k_hal_rx_parse_mon_status_tlv() is invalid, then ath11k send
wmi cmd WMI_REQUEST_STATS_CMDID with flag WMI_REQUEST_RSSI_PER_CHAIN_STAT
to firmware, and parse the rssi of chain in wmi WMI_UPDATE_STATS_EVENTID,
then report them to mac80211.

WMI_REQUEST_STATS_CMDID is only sent when CONFIG_ATH11K_DEBUGFS is set,
it is only called by ath11k_mac_op_sta_statistics(). It does not effect
performance and power consumption. Because after STATION connected to
AP, it is only called every 6 seconds by NetworkManager in below stack.

[  797.005587] CPU: 0 PID: 701 Comm: NetworkManager Tainted: G        W  OE     5.13.0-rc6-wt-ath+ #2
[  797.005596] Hardware name: LENOVO 418065C/418065C, BIOS 83ET63WW (1.33 ) 07/29/2011
[  797.005600] RIP: 0010:ath11k_mac_op_sta_statistics+0x2f/0x1b0 [ath11k]
[  797.005644] Code: 41 56 41 55 4c 8d aa 58 01 00 00 41 54 55 48 89 d5 53 48 8b 82 58 01 00 00 48 89 cb 4c 8b 70 20 49 8b 06 4c 8b a0 90 08 00 00 <0f> 0b 48 8b 82 b8 01 00 00 48 ba 00 00 00 00 01 00 00 00 48 89 81
[  797.005651] RSP: 0018:ffffb1fc80a4b890 EFLAGS: 00010282
[  797.005658] RAX: ffff8a5726200000 RBX: ffffb1fc80a4b958 RCX: ffffb1fc80a4b958
[  797.005664] RDX: ffff8a5726a609f0 RSI: ffff8a581247f598 RDI: ffff8a5702878800
[  797.005668] RBP: ffff8a5726a609f0 R08: 0000000000000000 R09: 0000000000000000
[  797.005672] R10: 0000000000000000 R11: 0000000000000007 R12: 02dd68024f75f480
[  797.005676] R13: ffff8a5726a60b48 R14: ffff8a5702879f40 R15: ffff8a5726a60000
[  797.005681] FS:  00007f632c52a380(0000) GS:ffff8a583a200000(0000) knlGS:0000000000000000
[  797.005687] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  797.005692] CR2: 00007fb025d69000 CR3: 00000001124f6005 CR4: 00000000000606f0
[  797.005698] Call Trace:
[  797.005710]  sta_set_sinfo+0xa7/0xb80 [mac80211]
[  797.005820]  ieee80211_get_station+0x50/0x70 [mac80211]
[  797.005925]  nl80211_get_station+0xd1/0x200 [cfg80211]
[  797.006045]  genl_family_rcv_msg_doit.isra.15+0x111/0x140
[  797.006059]  genl_rcv_msg+0xe6/0x1e0
[  797.006065]  ? nl80211_dump_station+0x220/0x220 [cfg80211]
[  797.006223]  ? nl80211_send_station.isra.72+0xf50/0xf50 [cfg80211]
[  797.006348]  ? genl_family_rcv_msg_doit.isra.15+0x140/0x140
[  797.006355]  netlink_rcv_skb+0xb9/0xf0
[  797.006363]  genl_rcv+0x24/0x40
[  797.006369]  netlink_unicast+0x18e/0x290
[  797.006375]  netlink_sendmsg+0x30f/0x450
[  797.006382]  sock_sendmsg+0x5b/0x60
[  797.006393]  ____sys_sendmsg+0x219/0x240
[  797.006403]  ? copy_msghdr_from_user+0x5c/0x90
[  797.006413]  ? ____sys_recvmsg+0xf5/0x190
[  797.006422]  ___sys_sendmsg+0x88/0xd0
[  797.006432]  ? copy_msghdr_from_user+0x5c/0x90
[  797.006443]  ? ___sys_recvmsg+0x9e/0xd0
[  797.006454]  ? __fget_files+0x58/0x90
[  797.006461]  ? __fget_light+0x2d/0x70
[  797.006466]  ? do_epoll_wait+0xce/0x720
[  797.006476]  ? __sys_sendmsg+0x63/0xa0
[  797.006485]  __sys_sendmsg+0x63/0xa0
[  797.006497]  do_syscall_64+0x3c/0xb0
[  797.006509]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  797.006519] RIP: 0033:0x7f632d99912d
[  797.006526] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 ca ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2f 44 89 c7 48 89 44 24 08 e8 fe ee ff ff 48
[  797.006533] RSP: 002b:00007ffd80808c00 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
[  797.006540] RAX: ffffffffffffffda RBX: 0000563dab99d840 RCX: 00007f632d99912d
[  797.006545] RDX: 0000000000000000 RSI: 00007ffd80808c50 RDI: 000000000000000b
[  797.006549] RBP: 00007ffd80808c50 R08: 0000000000000000 R09: 0000000000001000
[  797.006552] R10: 0000563dab96f010 R11: 0000000000000293 R12: 0000563dab99d840
[  797.006556] R13: 0000563dabbb28c0 R14: 00007f632dad4280 R15: 0000563dabab11c0
[  797.006563] ---[ end trace c9dcf08920c9945c ]---

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01230-QCAHSTSWPLZ_V2_TO_X86-1
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-02892.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1

Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211215090944.19729-1-quic_wgong@quicinc.com

ath5k: switch to rate table based lookup

Switching from legacy usage of ieee80211_get_tx_rates() lookup to direct
rate table lookup in struct ieee80211_sta->rates.

The current rate control API allows drivers to directly get rates from
ieee80211_sta->rates. ath5k is currently one of the legacy drivers that
perform translation/merge with the internal rate table via
ieee80211_get_tx_rates provided by rate control API.
For our upcoming changes to rate control API and the implementation of
transmit power control, this patch changes the behaviour. The call to
ieee80211_get_tx_rates and subsequent calls are also avoided. ath5k now
directly reads rates from sta->rates into its internal rate table. Cause
ath5k does not rely on the rate array in SKB->CB, this is not considered
anymore except for the first entry (used for probing).

Tested this on a PCEngines ALIX with CMP9-GP miniPCI wifi card (Atheros
AR5213A). Generated traffic between AP and multiple STAs before and
after applying the patch and simultaneously measured throughput and
captured rc_stats. Comparison resulted in same rate selection and no
performance loss between both runs.

Co-developed-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de>
Signed-off-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de>
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211215215042.637-1-jelonek.jonas@gmail.com

mt76: mt7921s: fix cmd timeout in throughput test

During heavy loading throughtput test, the RX buffer (128)
would be exhausted and some RX pkts dropped randomly. Increase
buffer size from 128 to 512 (a safer length) to avoid tput degrade
or cmd-timeout problem.

Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7921s: fix suspend error with enlarging mcu timeout value

Fix the false positive suspend error that may occur on mt7921s
with enlarging mcu timeout value.

The reason why we have to enlarge mcu timeout from HZ / 3 to HZ is
we should consider the additional overhead caused by running
concurrently with btmtksdio (a MT7921 bluetooth SDIO driver) that
would compete for the same SDIO bus in process context to complete
the suspend procedure.

Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7921s: make pm->suspended usage consistent

Update pm->suspended usage to be consistent with mt7921e driver.

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7921: fix possible resume failure

Fix the possible resume failure due to mt76_connac_mcu_set_hif_suspend
timeout.

That is because clearing the flag pm->suspended too early opened up a race
window, where mt7921_poll_tx/rx scheduled a ps_work to put the device in
doze mode, that is unexpected for the device is being resumed from the
suspend state and would make the remaining MCU comamnds in resume handler
failed to execute.

Fixes: ffa1bf97425b ("mt76: mt7921: introduce PM support")
Co-developed-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7921: clear pm->suspended in mt7921_mac_reset_work

clear pm->suspended in mt7921_mac_reset_work to allow pm runtime
can be enabled after wifi reset in any circumstance.

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: connac: rely on le16_add_cpu in mt76_connac_mcu_add_nested_tlv

Rely on le16_add_cpu() in mt76_connac_mcu_add_nested_tlv routine.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7921: remove dead definitions

to_wcid_lo and to_wcid_hi are no longer used in mt7921/mcu.c

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7915: add mu-mimo and ofdma debugfs knobs

Add mu-mimo and ofdma packet counters statistics.
The statistics are clear on read.

Reviewed-by: Money Wang <Money.Wang@mediatek.com>
Reviewed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: MeiChia Chiu <meichia.chiu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7915: introduce mt76_vif in mt7915_vif

Align mt7915_vif layout to mt7921_vif and mt7615_vif

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7921: reduce log severity levels for informative messages

"ASIC revision" and "Firmware init done" shouldn't be error messages.
Reduces the severity levels.

Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7915: rely on mt76_connac definitions

Remove duplicated mcu definitions in mt7915 mcu.h and reused connac
ones.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: connac: rely on MCU_CMD macro

Similar to mt7915 driver, rely on MCU_CMD macro and do not command
definitions directly

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: connac: introduce MCU_CE_CMD macro

Similar to MCU_EXT_CMD, introduce MCU_CE_CMD for CE commands

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: connac: introduce MCU_UNI_CMD macro

Similar to MCU_EXT_CMD, introduce MCU_UNI_CMD for unified commands

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: connac: remove MCU_FW_PREFIX bit

Get rid of MCU_FW_PREFIX bit since it is no longer used

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: connac: align MCU_EXT definitions with 7915 driver

Align MCU_EXT and MCU_FW definitions between mt76_connac and mt7915
driver. This is a preliminary patch to reuse mt76_connac in mt7915
driver.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: connac: introduce MCU_EXT macros

Introduce MCU_EXT_CMD and MCU_EXT_QUERY macros in mt76_connac module.
This is a preliminary patch to reuse mt76_connac module in mt7915
driver.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7921: fix network buffer leak by txs missing

TXS in mt7921 may be forwared to tx_done event. Should try to catch
TXS information in tx_done event as well.

Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7615: in debugfs queue stats, skip wmm index 3 on mt7663

The hardware only supports WMM index 0-2 and registers for index 3 return
bogus data.

Signed-off-by: Felix Fietkau <nbd@nbd.name>

mt76: mt7915: process txfree and txstatus without allocating skbs

Reduces pressure on the memory allocator

Signed-off-by: Felix Fietkau <nbd@nbd.name>