The order of arguments for iwl_cmd_id() is confusing, and the
version is always 0 and thus a useless argument. Prefer the
WIDE_ID() macro (which needs to be a macro due to use in switch
cases etc.) over the iwl_cmd_id() function.

Obviously done with spatch:

  @@
  expression G, C;
  @@
  -iwl_cmd_id(C, G, 0)
  +WIDE_ID(G, C)
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.20220128153014.cc4f9d1a2e9b.Ieb023cd773ea22e819d1ef1c37ae857ecc1a839d@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Read a new bit defined in ACPI WTAS that allows OEMs to specify whether
TAS is allowed in UHB (6-7GHz) in the USA.  This can be used by OEMs
that got certified to use this feature.
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.20220128153014.1d2ae1e6bcdb.I177929ed01ed7bf4614ea0f6db2af9e52de13316@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Since FW is now in charge of timing the channel switch, there is no need
to send the add/modify/remove time event command to fw with every (e)CSA
element.
However, the driver needs to cancel the channel switch if the CS start
notification arrives and it does not know about an ongoing channel switch.
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.20220128153013.ac3af0ff22c7.Ie87c62047b71b93b12aa80b5dc5391b4798dbe97@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

The recent fix for NULL sta in iwl_mvm_get_tx_rate() still has a call
of iwl_mvm_sta_from_mac80211() that may be called with NULL sta.
Although this practically only points to the address and the actual
access doesn't happen due to the conditional evaluation at a later
point, it looks a bit flaky.

This patch drops the temporary variable above and evaluates
iwm_mvm_sta_from_mac80211() directly for avoiding confusions.

Fixes: d599f714 ("iwlwifi: mvm: don't crash on invalid rate w/o STA")
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20220121114024.10454-1-tiwai@suse.deSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add EHT capabilities to bands.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Link: https://lore.kernel.org/r/20220214173004.1b710f8e04ce.I11d6911dafc01deb8ceb7828e363e8554701790a@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Add initial support for EHT and 320 MHz bandwidth in mac80211.

As a new IEEE80211_STA_RX_BW_320 is added to
enum ieee80211_sta_rx_bandwidth, update the drivers to avoid
compilation warnings.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Link: https://lore.kernel.org/r/20220214173004.0f144cc0bba6.Iad18111264da87eed5fd7b017f0cc6e58c604e07@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Add 320 MHz support in the channel def and center frequency validation
with compatible check.
Signed-off-by: NJia Ding <quic_jiad@quicinc.com>
Co-authored-by: NKarthikeyan Periyasamy <quic_periyasa@quicinc.com>
Signed-off-by: NKarthikeyan Periyasamy <quic_periyasa@quicinc.com>
Co-authored-by: NMuna Sinada <quic_msinada@quicinc.com>
Signed-off-by: NMuna Sinada <quic_msinada@quicinc.com>
Co-authored-by: NVeerendranath Jakkam <quic_vjakkam@quicinc.com>
Signed-off-by: NVeerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/1640163883-12696-5-git-send-email-quic_vjakkam@quicinc.com
Link: https://lore.kernel.org/r/20220214163009.175289-1-johannes@sipsolutions.netSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

We add the fields for parsing extended ADDBA request/respond,
and new max 1K aggregation for limit ADDBA request/respond.

Adjust drivers to use the proper macro, IEEE80211_MAX_AMPDU_BUF ->
IEEE80211_MAX_AMPDU_BUF_HE.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Link: https://lore.kernel.org/r/20220214173004.b8b447ce95b7.I0ee2554c94e89abc7a752b0f7cc7fd79c273efea@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Add a custom regulatory domain for testing 6 GHz, including
320 MHz bandwidth. This can be used before the regulatory
databases are all updated etc.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Link: https://lore.kernel.org/r/20220214173004.e3d6faf1f35f.I9507395b64496d96a2276ba8c1e1323e54407aa7@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

The argument to hwsim_init_s1g_channels() shadows a global,
change that to be clearer.

Link: https://lore.kernel.org/r/20220214173004.66bac90d64a8.I3e878e42bf2feecbb0a6ca38a68c236c23a8c9e6@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Add checks to hwsim to validate that neither TX nor any
station's configured bandwidth can exceed the channel
(context) configuration previously requested.

Link: https://lore.kernel.org/r/20220214173004.9fd154d2c3c2.Ia0cd152357a373149bab017d479ab7d5ded289c0@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Set the base RSSI of a TX frame. The final RSSI of the frame will be
the base RSSI + the radio's TX power
Signed-off-by: NBeni Lev <beni.lev@intel.com>
Link: https://lore.kernel.org/r/20220210201649.dddebbb55a7f.I6c0607694587b577070339078829fcc20dfcfe2c@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Apply 160M bandwidth to RA (rate adaptive) mechanism, so it can transmit
packets with this bandwidth. On the other hand, convert 160M bandwidth
from RX desc to rx_info_bw.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220211075953.40421-7-pkshih@realtek.com

The new chip can support 160M, so add a chip attribute to indicate the
chip support it.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220211075953.40421-6-pkshih@realtek.com

Construct rate mask of 6G band, and rate adaptive mechanism can work well
on this band.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220211075953.40421-5-pkshih@realtek.com

Split 6G band into 8 sub-bands where indexes are from 0 to 7,
i.e. RTW89_CH_6G_BAND_IDX[0-7]. Then, decide subband by both
band and channel instead of just channel because conflicts
between 5G channels and 6G channels.

Moreover, add default case to the existing use of switch (subband).
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/20220211075953.40421-4-pkshih@realtek.com

Since these macro in rfk helpers are common now, a common naming
should be better. So, apply RTW89_ as prefix to them, and modify
the use correspondly. No logic is changed at all.
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/20220211075953.40421-3-pkshih@realtek.com

These rfk helpers are also useful for the chip which is under planning.
So, move them to common code to avoid duplicate stuff in the future.
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/20220211075953.40421-2-pkshih@realtek.com

BCM43454/6 is a variant of BCM4345 which is exactly identical to
BCM4345/6, except the chip id is 0xa9be. This patch adds support
for BCM43454/6 by handing it in the same way as BCM4345.

Note: when loading some specific version of BCM4345 firmware, the
chip id may become 0x4345. This is an expected behavior, and it will
restore to 0xa9be after power cycle.
Signed-off-by: NJiaqing Zhao <jiaqing.zhao@intel.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/CO1PR11MB47859B51BCA88613D1582EB88E2E9@CO1PR11MB4785.namprd11.prod.outlook.com

The variable len is being assigned bit is never used. The variable
and the strlen call are redundant and can be removed.
Signed-off-by: NColin Ian King <colin.i.king@gmail.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220207133329.336664-1-colin.i.king@gmail.com

There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].

This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().

This issue was found with the help of Coccinelle and audited and fixed,
manually.

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays

Link: https://github.com/KSPP/linux/issues/79Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220204232228.GA442895@embeddedor

B_AX_PLT_EN is to enable polluted mechanism. If it is enabled and
gnt_bt = 1 while wlan TX, B_AX_BT_PLT_PKT_CNT counter will increase,
but TX counter to BB will not. Without this bit BTCoex mechanism might
have some problems.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220208082751.43553-1-pkshih@realtek.com

Some APs like CMW270 only support one phyrate and the function
rtw89_phy_ra_mask_rssi could disable that rate. To fix such problem, we
restore the rate mask if we find that the rate_mask is empty.
Also, apply missed legacy rates from sta->supp_rates[].
Signed-off-by: NChien-Hsun Liao <ben.liao@realtek.com>
Signed-off-by: NKuan-Chung Chen <damon.chen@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/20220208082427.42433-3-pkshih@realtek.com

Some APs like CMW270 only support one phyrate and the function
rtw_update_rate_mask could disable that rate. To fix such problem, we
restore the rate mask if we find that the rate_mask is empty.
Signed-off-by: NChien-Hsun Liao <ben.liao@realtek.com>
Signed-off-by: NKuan-Chung Chen <damon.chen@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/20220208082427.42433-2-pkshih@realtek.com

Things are ready for AP mode, so declare this driver can support it.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220207063900.43643-8-pkshih@realtek.com

In order to trace the relation of IDs, we add this debugfs entry to make
them clear.

The output looks like:
  map:
          mac_id:    07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
          addr_cam:  07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
          bssid_cam: 01 00 00 00 00 00 00 00
          sec_cam:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  VIF [0] 94:08:53:8e:ef:21
          bssid_cam_idx=0
          addr_cam_idx=0
          -> bssid_cam_idx=0
          sec_cam_bitmap=00 00 00 00 00 00 00 00
  STA [1] 58:00:e3:bb:9c:4f
          addr_cam_idx=1
          -> bssid_cam_idx=0
          sec_cam_bitmap=00 00 00 00 00 00 00 00
  STA [2] 94:08:53:8e:ef:75
          addr_cam_idx=2
          -> bssid_cam_idx=0
          sec_cam_bitmap=00 00 00 00 00 00 00 00
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220207063900.43643-7-pkshih@realtek.com

Configure firmware and hardware to run AP mode. The start_ap() setup
bssid, mac port, mac_id entry, and does RFK. The stop_ap() reset the
state.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220207063900.43643-6-pkshih@realtek.com

In AP mode, when a STA associate to us, we need to create an entry in
firmware and hardware, and then they can transmit data properly.

The entry index called mac_id which is assigned when sta_add, and we ask
firmware to create an entry for an associated station. Also, the address
CAM should be filled so hardware can know which packet is ours, and lookup
the mac_id for further use.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220207063900.43643-5-pkshih@realtek.com

vif_type mapping indicates hardware operating mode corresponding to vif
type. In STA mode, hardware mode should be INFRA or NO_LINK mode
dynamically according to association status. Since AP mode don't need to
change this by association status intuitively, just do the mapping in
STA mode.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220207063900.43643-4-pkshih@realtek.com

In AP mode, each connected station needs an entry of address CAM. The
address CAM of vif is still needed to assit in AP itself.

For station mode, it still uses vif's address CAM.

Add a help macro rtw89_get_addr_cam_of() to get addr_cam from vif or sta
for all use cases.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220207063900.43643-3-pkshih@realtek.com

Fill mac_id and self_role depends on the operation mode.

In AP mode, echo connected station has an unique mac_id, and each vif also
has one mac_id to represent itself.

The self_role is assigned to vif if the operation mode is decided, and
RTW89_SELF_ROLE_AP_CLIENT is assigned to the connected STA in AP mode,
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220207063900.43643-2-pkshih@realtek.com

This code needs to use skb_queue_walk_safe() instead of skb_queue_walk()
because it frees the list iterator.

Fixes: d95984b5 ("rtw88: fix memory overrun and memory leak during hw_scan")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220203082532.GA25151@kili

The size of the status_driver_data field was not adjusted when
the is_valid_ack_signal field was added.
Since the size of struct ieee80211_tx_info is limited, replace
the is_valid_ack_signal field with a flags field, and adjust the
struct size accordingly.
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.20220202104617.0ff363d4fa56.I45792c0187034a6d0e1c99a7db741996ef7caba3@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

There's currently only one driver that reports CHECKSUM_COMPLETE,
that is iwlwifi. The current hardware there calculates checksum
after the SNAP header, but only RFC 1042 (and some other cases,
but replicating the exact hardware logic for corner cases in the
driver seemed awkward.)

Newer generations of hardware will checksum _including_ the SNAP,
which makes things easier.

To handle that, simply always assume the checksum _includes_ the
SNAP header, which this patch does, requiring to first add it
for older iwlwifi hardware, and then remove it again later on
conversion.

Alternatively, we could have:

 1) Always assumed the checksum starts _after_ the SNAP header;
    the problem with this is that we'd have to replace the exact
    "what is the SNAP" check in iwlwifi that cfg80211 has.

 2) Made it configurable with some flag, but that seemed like too
    much complexity.
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.20220202104617.230736e19e0e.I3e6745873585ad943c152fab9e23b5221f17a95f@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Check ndesc of q_rx to avoid potential hole in iteration.
This is an intermediate patch to add mt7986 support.
Signed-off-by: NSujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: NBo Jiao <Bo.Jiao@mediatek.com>
Reviewed-by: NRyder Lee <ryder.lee@mediatek.com>
Signed-off-by: NFelix Fietkau <nbd@nbd.name>

Even if it is only a false-positive since skip_buf0/skip_buf1 are only
used in mt76_dma_tx_cleanup_idx routine, initialize skip_unmap in
mt76_dma_rx_fill in order to fix the following UBSAN report:

[   13.924906] UBSAN: invalid-load in linux-5.15.0/drivers/net/wireless/mediatek/mt76/dma.c:162:13
[   13.924909] load of value 225 is not a valid value for type '_Bool'
[   13.924912] CPU: 9 PID: 672 Comm: systemd-udevd Not tainted 5.15.0-18-generic #18-Ubuntu
[   13.924914] Hardware name: LENOVO 21A0000CMX/21A0000CMX, BIOS R1MET43W (1.13 ) 11/05/2021
[   13.924915] Call Trace:
[   13.924917]  <TASK>
[   13.924920]  show_stack+0x52/0x58
[   13.924925]  dump_stack_lvl+0x4a/0x5f
[   13.924931]  dump_stack+0x10/0x12
[   13.924932]  ubsan_epilogue+0x9/0x45
[   13.924934]  __ubsan_handle_load_invalid_value.cold+0x44/0x49
[   13.924935]  ? __iommu_dma_map+0x84/0xf0
[   13.924939]  mt76_dma_add_buf.constprop.0.cold+0x23/0x85 [mt76]
[   13.924949]  mt76_dma_rx_fill.isra.0+0x102/0x1f0 [mt76]
[   13.924954]  mt76_dma_init+0xc9/0x150 [mt76]
[   13.924959]  ? mt7921_dma_enable+0x110/0x110 [mt7921e]
[   13.924966]  mt7921_dma_init+0x1e3/0x260 [mt7921e]
[   13.924970]  mt7921_register_device+0x29d/0x510 [mt7921e]
[   13.924975]  mt7921_pci_probe.part.0+0x17f/0x1b0 [mt7921e]
[   13.924980]  mt7921_pci_probe+0x43/0x60 [mt7921e]
[   13.924984]  local_pci_probe+0x4b/0x90
[   13.924987]  pci_device_probe+0x115/0x1f0
[   13.924989]  really_probe+0x21e/0x420
[   13.924992]  __driver_probe_device+0x115/0x190
[   13.924994]  driver_probe_device+0x23/0xc0
[   13.924996]  __driver_attach+0xbd/0x1d0
[   13.924998]  ? __device_attach_driver+0x110/0x110
[   13.924999]  bus_for_each_dev+0x7e/0xc0
[   13.925001]  driver_attach+0x1e/0x20
[   13.925003]  bus_add_driver+0x135/0x200
[   13.925005]  driver_register+0x95/0xf0
[   13.925008]  ? 0xffffffffc0766000
[   13.925010]  __pci_register_driver+0x68/0x70
[   13.925011]  mt7921_pci_driver_init+0x23/0x1000 [mt7921e]
[   13.925015]  do_one_initcall+0x48/0x1d0
[   13.925019]  ? kmem_cache_alloc_trace+0x19e/0x2e0
[   13.925022]  do_init_module+0x62/0x280
[   13.925025]  load_module+0xac9/0xbb0
[   13.925027]  __do_sys_finit_module+0xbf/0x120
[   13.925029]  __x64_sys_finit_module+0x18/0x20
[   13.925030]  do_syscall_64+0x5c/0xc0
[   13.925033]  ? do_syscall_64+0x69/0xc0
[   13.925034]  ? sysvec_reschedule_ipi+0x78/0xe0
[   13.925036]  ? asm_sysvec_reschedule_ipi+0xa/0x20
[   13.925039]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   13.925040] RIP: 0033:0x7fbf2b90f94d
[   13.925045] RSP: 002b:00007ffe2ec7e5d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[   13.925047] RAX: ffffffffffffffda RBX: 000056106b0634e0 RCX: 00007fbf2b90f94d
[   13.925048] RDX: 0000000000000000 RSI: 00007fbf2baa3441 RDI: 0000000000000013
[   13.925049] RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000002
[   13.925050] R10: 0000000000000013 R11: 0000000000000246 R12: 00007fbf2baa3441
[   13.925051] R13: 000056106b062620 R14: 000056106b0610c0 R15: 000056106b0640d0
[   13.925053]  </TASK>
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NFelix Fietkau <nbd@nbd.name>

Do not always copy ethernet header in mt{7615,7915,7921}_reverse_frag0_hdr_trans
and use a pointer instead.
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NFelix Fietkau <nbd@nbd.name>

Fixes corner cases in enabling/disabling detector
Signed-off-by: NFelix Fietkau <nbd@nbd.name>

Copy the updated logic from mt7915 to to fix issues in handling DFS radar
detector states
Signed-off-by: NFelix Fietkau <nbd@nbd.name>

Client mode on DFS channels was broken, because the old code was activating
the DFS detector on radar channels while leaving it in CAC state.
This was caused by making the decision based on the channel radar flag,
instead of hw->conf.radar_enabled.
In order to properly deal with the various corner cases, rip out the state
handling code and replace it with something that's much easier to reason
about.
Tested-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NFelix Fietkau <nbd@nbd.name>