Program the RMAC CHFREQ registers to properly indicate the band that the
frames are received on.
Add some sanity checks to the programmed values, because the firmware
programs these registers differently
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Move chainmask to struct mt7615_phy and instead of needlessly making the
format similar to values for older chips, make it refer to the actual chain
bits used for the rx/tx path.
This is important for multiple wiphy support, where for a secondary phy,
antenna_mask will start at 0, and chainmask will start at the chain offset
(bit 2)
Signed-off-by: Felix Fietkau <nbd@nbd.name>

There are two DFS detectors on the chip. When using 160 MHz channel bandwidth
(not supported in dual-wiphy mode), both are used. Otherwise, one detector is
used per wiphy.
Rework the code to start/stop them separately per phy and to indicate the
radar event on the right phy based on the detector index
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Writing 0/1 is shorter and just as clear
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Initialize low-power beacon mode setting
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Use per-phy radio stats and tuning registers
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Allows them to be used by a separately registered wiphy later
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Prevent the overwriting of max_tx_fragments if it has already been set
in chip-specific init routine.
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>

It is only used by the driver
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Will be used to determine the phy from within the driver
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Unlike the core phy, this will have extra allocated memory for a driver
private struct.
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Will be used for per-phy driver private data
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Allow tracking clients of both wiphys separately
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Adds multiple wiphy support to mt76_get_txpower
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Nothing in the core uses it
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Nothing in the core uses it
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Allows keeping per-wiphy state separate
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Allows tracking tx scheduling separately per phy
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Add support for an extra wiphy in mt76_set_channel and mt76_get_survey
This is preparation for supporting multiple wiphys per device to support the
concurrent dual-band feature of MT7615D
Signed-off-by: Felix Fietkau <nbd@nbd.name>

This is preparation for supporting multiple wiphys per device to support the
concurrent dual-band feature of MT7615D
Signed-off-by: Felix Fietkau <nbd@nbd.name>

This is preparation for supporting multiple wiphys per device to support the
concurrent dual-band feature of MT7615D
Signed-off-by: Felix Fietkau <nbd@nbd.name>

This is preparation for supporting multiple wiphys per device to support the
concurrent dual-band feature of MT7615D
Signed-off-by: Felix Fietkau <nbd@nbd.name>

This is preparation for supporting multiple wiphys per device to support the
concurrent dual-band feature of MT7615D
Signed-off-by: Felix Fietkau <nbd@nbd.name>

This is preparation for supporting multiple wiphys per device to support the
concurrent dual-band feature of MT7615D

On the first wiphy, hw->priv will point to struct mt76_dev, which contains a
struct mt76_phy at the start. For the secondary wiphy, hw->priv will point
to a mt76_phy encapsulated in a driver specific struct

To simplify access to struct mt76_phy members from drivers, the driver specific
device struct is changed to add a union of struct mt76_dev and struct mt76_phy
as the first element
Signed-off-by: Felix Fietkau <nbd@nbd.name>

Reduces duplication and prepares for further rework
Signed-off-by: Felix Fietkau <nbd@nbd.name>

In associating and configuring beamformee, bfee->role is not
correctly set before rtw_chip_ops::config_bfee().
Fix it by setting it correctly.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Reduce the data size 2kb or 3kb by making tables const.
Add const to pointer declarations to make compilation work too.

(x86-64 defconfig)
$ size drivers/net/wireless/realtek/rtw88/rtw8822?.o*
   text	   data	    bss	    dec	    hex	filename
  25054	    672	      8	  25734	   6486	drivers/net/wireless/realtek/rtw88/rtw8822b.o.new
  23870	   1872	      8	  25750	   6496	drivers/net/wireless/realtek/rtw88/rtw8822b.o.old
  53646	    828	      0	  54474	   d4ca	drivers/net/wireless/realtek/rtw88/rtw8822c.o.new
  52846	   1652	      0	  54498	   d4e2	drivers/net/wireless/realtek/rtw88/rtw8822c.o.old

(x86-64 allyesconfig)
$ size drivers/net/wireless/realtek/rtw88/rtw8822?.o*
   text	   data	    bss	    dec	    hex	filename
  45811	   6280	    128	  52219	   cbfb	drivers/net/wireless/realtek/rtw88/rtw8822b.o.new
  44211	   7880	    128	  52219	   cbfb	drivers/net/wireless/realtek/rtw88/rtw8822b.o.old
 100195	   8128	      0	 108323	  1a723	drivers/net/wireless/realtek/rtw88/rtw8822c.o.new
  98947	   9376	      0	 108323	  1a723	drivers/net/wireless/realtek/rtw88/rtw8822c.o.old
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Some tests shows that using AMSDU to aggregate TCP ACKs to specific
APs will degrade the throughput on 2.4G band in 20MHz bandwidth
(< 10 Mbps, should be ~100 Mbps for 2x2). Also found that there's
barely no negative impact if we disable TX AMSDU on 2.4G to connect
to other APs. So it seems like we can just tell mac80211 to not to
aggregate MSDUs when transmitting on 2.4G band.

Note that we still can TX AMSDU on 5G band and benefit from it by
having 50 ~ 70 Mbps throughput improvement.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

According to some experiments, the original RF register protection
setting of 8822c cannot perfectly make sure that there is no hardware
PI write (direct) during direct write. Modify the setting so that the
hardware block of PI would be turned off via rtw8822c_rstb_3wire()
during the direct write, to avoid RF register racing.

Note that 8822b uses SIPI write (indirect), so 8822b does not
have such problem.
Signed-off-by: Chien-Hsun Liao <ben.liao@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

The hardware value of secondary channel offset isn't very intuitive. This
commit adds enumeration, so we can easier to check the logic with the
suffix of enumeration name, likes _UPPER or _LOWER.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

sk_buff structs need to be freed with kfree_skb(), not kfree().

Fixes: b6c12908 ("rtw88: Add wowlan net-detect support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Appearently the hw pointer can be NULL while the module is loaded and
in that case rsi_shutdown() crashes due to the unconditional dereference.
Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Fix switching xtal mode leads to BT USB error issue.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Though hardware isn't implement CCMP-256, GCMP and GCMP-256, it's possible
to fallback to use software de-/en-cryption implemented by mac80211.

Without adding these chipers, kernel log will show something if we connect
to a WPA3 enterprise AP, likes
  wlan0: failed to set key (1, ff:ff:ff:ff:ff:ff) to hardware (-524)
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Driver could possibly be dead-locked while canceling works with
*_sync() with mutex lock held. Those cancel_delayed_work_sync()
functions will wait until the work is done, but if we hold the
lock, they will never acquire the lock.

To prevent this, simply release the lock and acquire again after
the works have been canceled. And to avoid the works being queued
again, check if the device is at RTW_FLAG_RUNNING state, otherwise
just return and do nothing.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

When driver is coming up, mac80211 will set changed as ~0 (0xffffffff),
and driver could enter IDLE state (power off) before switching channel or
other config event. So move rtw_enter_ips() to the last, to make sure the
driver completed the config events before going to IDLE state.

So, moves leave/enter IPS config to be first/last one according to flag
IEEE80211_CONF_IDLE. If there're more configureations we want to add in
the future, they must locate between leave/enter IPS.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Since RTL8822CE has enabled reference clock auto calibration,
there is no need to add any clock delay for covering the timing
gap of the reference clock.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Both are missing but could be used sometimes.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

vif is not used, remove it
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

With commit 216b4400 ("brcmfmac: Fix use after free in
brcmf_sdio_readframes()") applied, we see locking timeouts in
brcmf_sdio_watchdog_thread().

brcmfmac: brcmf_escan_timeout: timer expired
INFO: task brcmf_wdog/mmc1:621 blocked for more than 120 seconds.
Not tainted 4.19.94-07984-g24ff99a0f713 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
brcmf_wdog/mmc1 D    0   621      2 0x00000000 last_sleep: 2440793077.  last_runnable: 2440766827
[<c0aa1e60>] (__schedule) from [<c0aa2100>] (schedule+0x98/0xc4)
[<c0aa2100>] (schedule) from [<c0853830>] (__mmc_claim_host+0x154/0x274)
[<c0853830>] (__mmc_claim_host) from [<bf10c5b8>] (brcmf_sdio_watchdog_thread+0x1b0/0x1f8 [brcmfmac])
[<bf10c5b8>] (brcmf_sdio_watchdog_thread [brcmfmac]) from [<c02570b8>] (kthread+0x178/0x180)

In addition to restarting or exiting the loop, it is also necessary to
abort the command and to release the host.

Fixes: 216b4400 ("brcmfmac: Fix use after free in brcmf_sdio_readframes()")
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: franky.lin@broadcom.com
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>