Fix a possible race enabling/disabling runtime-pm between
mt7921_pm_set() and mt7921_poll_rx() since mt7921_pm_wake_work()
always schedules rx-napi callback and it will trigger
mt7921_pm_power_save_work routine putting chip to in low-power state
during mt7921_pm_set processing.
Suggested-by: NDeren Wu <deren.wu@mediatek.com>
Tested-by: NDeren Wu <deren.wu@mediatek.com>
Fixes: 1d8efc74 ("mt76: mt7921: introduce Runtime PM support")
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/0f3e075a2033dc05f09dab4059e5be8cbdccc239.1640094847.git.lorenzo@kernel.org

Add documentation for the ENABLE and RESET GPIOs that may be needed by
wilc1000-spi.
Signed-off-by: NDavid Mosberger-Tang <davidm@egauge.net>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211221212531.4011609-3-davidm@egauge.net

For the SDIO driver, the RESET/ENABLE pins of WILC1000 are controlled
through the SDIO power sequence driver.  This commit adds analogous
support for the SPI driver.  Specifically, during initialization, the
chip will be ENABLEd and taken out of RESET and during
deinitialization, the chip will be placed back into RESET and disabled
(both to reduce power consumption and to ensure the WiFi radio is
off).

Both RESET and ENABLE GPIOs are optional.  However, if the ENABLE GPIO
is specified, then the RESET GPIO should normally also be specified as
otherwise there is no way to ensure proper timing of the ENABLE/RESET
sequence.
Signed-off-by: NDavid Mosberger-Tang <davidm@egauge.net>
Reviewed-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211221212531.4011609-2-davidm@egauge.net

Move "chipid" variable into the per-driver structure so the code
doesn't break if more than one wilc1000 module is present.
Signed-off-by: NDavid Mosberger-Tang <davidm@egauge.net>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211221210538.4011227-1-davidm@egauge.net

Since there are other protections in the set channel flow, fortunately old
wrong setting won't affect the performance.
Signed-off-by: NChung-Hsuan Hung <hsuan8331@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211221024800.23814-1-pkshih@realtek.com

In original flow, driver needs to ensure chip leave deep ps mode
before transmitting any packet, and don't enter deep ps mode beofre
PCIE DMA is finished. Now with the support of 8822ce's hardware
setting and firmware after v9.9.11, these limits are removed.
Signed-off-by: NChin-Yen Lee <timlee@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211221020230.20764-1-pkshih@realtek.com

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

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 734223d7 ("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: 734223d7 ("ath11k: change return buffer manager for QCA6390")
Signed-off-by: NBaochen Qiang <quic_bqiang@quicinc.com>
Signed-off-by: NKalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211222013536.582527-1-quic_bqiang@quicinc.com

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: NCheng Wang <quic_chengwan@quicinc.com>
Signed-off-by: NKalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211220121053.357087-1-quic_chengwan@quicinc.com

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: NBen Greear <greearb@candelatech.com>
Signed-off-by: NKalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20200903195254.29379-1-greearb@candelatech.com

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: NJason Wang <wangborong@cdjrlc.com>
Signed-off-by: NKalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211221070931.725720-1-wangborong@cdjrlc.com

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: NZong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211220093656.65312-1-pkshih@realtek.com

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: NPo-Hao Huang <phhuang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle 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.kernel.org/pub/scm/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.

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: 2da4366f ("iwlwifi: mei: add the driver to allow cooperation with CSME")
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.20211220142940.8b6279e3d0be.I6fe128b0b86149a85535104822c8355b367887c8@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211220142940.c7bb5b7644df.I48498d9fd6e3959562205af67aa5f1a822eb762d@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NMukesh Sisodiya <mukesh.sisodiya@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.55527214f8c9.I1748215ccb3fa20a3491a46a49b12e04eb560ac6@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.3331df94b106.If6c96b0d386e1c5988c8da6b69257e8f2e737f07@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.0537aa562313.I183bb336345b9b3da196ba9e596a6f189fbcbd09@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.a67b5b9db259.Ic55b306fcd2a3525b3993f4b7e00622dd95053ba@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.305d12cf51ac.I2e4e6874113b1e5d8ee467b8a2d90820cc6ddde9@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.915e1f69f062.Id837e917f1c2beaca7c1eb33333d622548918a76@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.b1e96021b616.Id0164855f2dd01ecdecf79b239d6ee5974882245@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.c0f44c98b36d.I75a688f3ac80cbe824c459ece4bb67843b9fce76@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NMiri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Set scan offload profiles auth algorithms with valid
algorithms only.
Signed-off-by: NAyala Beker <ayala.beker@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.525f2d468d22.I4d497d6a0a14ffb833f7edc7e980d26bbf8d7527@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NAvraham Stern <avraham.stern@intel.com>
Fixes: 517a5eb9 ("iwlwifi: mvm: when associated with PMF, use protected NDP ranging negotiation")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.f50ed0e3c6b3.Ibff247ee9d4e6e0a1a2d08a3c8a4bbb37e6829dd@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

add killer subsystem devices from the 1675i and 1675s family
to the driver.
Signed-off-by: NYaara Baruch <yaara.baruch@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.2d5bec2d7b68.Icffb4e27390e6a5c76a0cbe7abf7472558f323d6@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NAvraham Stern <avraham.stern@intel.com>
Fixes: e8fe3b41 ("iwlwifi: mvm: Add support for 6GHz passive scan")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.6d5c043372cf.I251dd5618a3f0b8febbcca788eb861f1cd6039bc@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

In case of forced passive scan on a UHB channel,
don't set the direct probe option for this channel.
Signed-off-by: NAyala Beker <ayala.beker@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.0ede76a9ca92.Ie64a4df79ea9c485ae3d2fc043319e8f79cefa8e@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NMiri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.793a509da7bd.Ia176746a28b816b5f788cce9a281139735909e2a@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Start supporting API version 69 for AX devices.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.7d8fe0dffaea.I2de65c1efd9ab464d4158a3d852f73efe63024f8@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.098be12c801e.I1d81733d8a75b84c3b20eb6e0d14ab3405ca6a86@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NNathan Errera <nathan.errera@intel.com>
Fixes: 2c2c3647 ("iwlwifi: mvm: support ADD_STA_CMD_API_S ver 12")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d5376ac6bcb0.Ic5f8470ea60c072bde9d1503e5f528b65e301e20@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NLuca Coelho <luciano.coelho@intel.com>
Fixes: 664c011b ("iwlwifi: acpi: support reading and storing WGDS revision 2")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.abed3b8119c7.I1fdc2c14577523fcffdfe8fb5902c2d8efde7e09@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NMukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d59b29653a1e.I7b3be4a1ad1a9d5d0e86259740e89ac113c9348b@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Increment the threshold to avoid dropping too eagerly.
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.0e947ed458c4.Ia376cbea5f59df4b4474f0bd33ab033e84535cce@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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>

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: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.8ef59da4e05e.Ide87c2dc8fa08eae55c013a625f4ece5184b1b63@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.f05488ce8b83.I65bb83721498d8433e4ee2b09415eb74ab579445@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>