The firmware of 11AC devices need more information to support more offload
functions, such as IQK. And 11N devices such as 8723D does not support
offload these function in firmware, there is no need to send these additional
information to firmware when it comes to 11N devices.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200422034607.28747-3-yhchuang@realtek.com

The WLAN CPU of 8723D device is different from others, add legacy
firmware download function for it. A new variable wlan_cpu is used to
decide which firmware download function we should use.

Legacy firmware file contains 32 bytes header including version and
subversion. When downloading to wlan cpu, header is excluded.

Firmware is downloaded via beacon queue to reserved page that is a part of
TX buffer. Since 11N WLAN CPU uses different control registers, this patch
introduces related control registers.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200422034607.28747-2-yhchuang@realtek.com

This patch adding support for new cipher suite - AES-CMAC in wlcore driver.
This patch is required for support PMF/WPA3 connection to install IGTK key.
Signed-off-by: NRaz Bouganim <r-bouganim@ti.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1587472085-755-1-git-send-email-r-bouganim@ti.com

8822C devices have power trim, thermal and PA bias values
programmed in efuse. Driver should configure the RF components
according to the values.

If the power trim is not configured, then the devices might have
distortion on the output tx power.
Signed-off-by: NTzu-En Huang <tehuang@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420105207.31899-1-yhchuang@realtek.com

The logical efuse map is decoded from physical map by parsing the
header format of the physical map. And each different type of chips
has different logical efuse layout. So add the logical map's layout
for parsing the efuse contents.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420055054.14592-9-yhchuang@realtek.com

8723D devices need to grant efuse access before dumping physical efuse
map, other chips don't need it, so keep this ops as blank.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420055054.14592-8-yhchuang@realtek.com

Implement rtw_chip_ops::cfg_ldo25 to enable/disable LDO25 with proper
voltage.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420055054.14592-7-yhchuang@realtek.com

Add corresponding parameter tables for 8723D devices.
Since 8723D devices currently have only one RFE type, there is
only one entry in rtw8723d_rfe_defs.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420055054.14592-6-yhchuang@realtek.com

8723D use SIPI to indirectly read RF register instead of directly read,
so introduce a new struct rtw_rf_sipi_addr and new function
rtw_phy_read_rf_sipi(). Since other chips don't use the new function,
only 8723D needs to fill struct rtw_rf_sipi_addr in rtw_chip_info.

Because there are two kinds of functions for reading RF registers now,
change rtw_phy_read_rf() to chip->ops->read_rf() in
rtw_phy_write_rf_reg_sipi() so that we can switch tp proper RF read
functions depends on the type of the chip.

Though 8723D is an 1x1 chip, it has two RF PHY and we can switch to
one of them, and that should be configured properly. Hence, add a
fix_rf_phy_num to struct rtw_chip_info to allow driver to set one of
the PHY's registers for 8723D, even it is only 1x1. Another variable
rf_phy_num is introduced to keep the constraint number of RF path we
can access, and its value is:
	rf_phy_num = (fix_rf_phy_num ? fix_rf_phy_num : rf_path_num)
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NZong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420055054.14592-5-yhchuang@realtek.com

Add corresponding power sequence for 8723D devices
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420055054.14592-4-yhchuang@realtek.com

8723D doesn't support beamform because rtw88 only supports VHT beamform
but 8723d doesn't have VHT capability. Though 8723d doesn't support
beamform, BSS_CHANGED_MU_GROUPS is still marked as changed when doing
disassociation. So, add wrapper functions for all beamform ops to make
sure they aren't NULL before calling.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420055054.14592-3-yhchuang@realtek.com

RTL8723DE is an 11n 1x1 2.4G single band chip with the
following capabilities:

 - TX/RX BD size: 16/8
 - TX/RX desc size: 40/24
 - physical/logical/protected efuse size: 512/512/96
 - TX gain index factor: 1
 - max TX power index: 0x3F
 - band: 2G
 - HT: support
 - VHT: Not support
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420055054.14592-2-yhchuang@realtek.com

Fix the following coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c:617:14-20: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c:622:13-19: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c:627:14-20: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c:632:13-19: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c:937:5-13: WARNING:
Comparison to bool
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200420042658.18733-1-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c:79:1-34: WARNING:
Assignment of 0/1 to bool variable
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c:81:1-34: WARNING:
Assignment of 0/1 to bool variable
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200418070236.9620-6-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c:77:1-34: WARNING:
Assignment of 0/1 to bool variable
drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c:79:1-34: WARNING:
Assignment of 0/1 to bool variable
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200418070236.9620-5-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c:78:1-34: WARNING:
Assignment of 0/1 to bool variable
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c:80:1-34: WARNING:
Assignment of 0/1 to bool variable
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200418070236.9620-4-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c:81:1-34: WARNING:
Assignment of 0/1 to bool variable
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c:83:1-34: WARNING:
Assignment of 0/1 to bool variable
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200418070236.9620-3-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c:70:1-34: WARNING:
Assignment of 0/1 to bool variable
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c:72:1-34: WARNING:
Assignment of 0/1 to bool variable
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200418070236.9620-2-yanaijie@huawei.com

Signed-off-by: NNils ANDRÉ-CHANG <nils@nilsand.re>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200412171900.xzedxhzd56gox5kf@nixos

This function actually needs no return value. So remove the unneeded
variable 'ret' and make it void.

This also fixes the following coccicheck warning:

drivers/net/wireless/intel/ipw2x00/ipw2200.c:10648:5-8: Unneeded
variable: "ret". Return "0" on line 10684
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200414120251.35869-1-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c:309:5-13:
Unneeded variable: "ret_code". Return "0" on line 328
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200413082126.22572-1-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/intersil/orinoco/spectrum_cs.c:281:5-8: Unneeded
variable: "err". Return "0" on line 286
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200413082043.22468-1-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/marvell/libertas/cmdresp.c:225:5-8: Unneeded
variable: "ret". Return "0" on line 355
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200413082022.22380-1-yanaijie@huawei.com

Sparse reports a warning at brcms_down()

warning: context imbalance in brcms_down()
	- unexpected unlock
The root cause is the missing annotation at brcms_down()
Add the missing __must_hold(&wl->lock) annotation
Signed-off-by: NJules Irenge <jbi.octave@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200411001933.10072-6-jbi.octave@gmail.com

Sparse reports a warning at brcms_rfkill_set_hw_state()

warning: context imbalance in brcms_rfkill_set_hw_state()
	- unexpected unlock
The root cause is the missing annotation at brcms_rfkill_set_hw_state()
Add the missing __must_hold(&wl->lock) annotation
Signed-off-by: NJules Irenge <jbi.octave@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200411001933.10072-5-jbi.octave@gmail.com

Sparse reports warnings at prism2_bss_list_proc_start() and prism2_bss_list_proc_stop()

warning: context imbalance in prism2_wds_proc_stop() - unexpected unlock
warning: context imbalance in prism2_bss_list_proc_start() - wrong count at exit

The root cause is the missing annotations at prism2_bss_list_proc_start()

Add the missing __acquires(&local->lock) annotation
Add the missing __releases(&local->lock) annotation
Signed-off-by: NJules Irenge <jbi.octave@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200411001933.10072-4-jbi.octave@gmail.com

User space program such as iw can set antenna mask for the device.
So add set antenna support by configure the trx mode.

This is useful for some tests want to see the output of different
antenna configuration (e.g. path A v.s. path B).
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200410100950.3199-3-yhchuang@realtek.com

To support ieee80211_ops::set_antenna, the driver can decide if the
antenna mask is accepted, otherwise it can return an error code.
Because each chip could have different limitations, let the chip
check the mask and return.

Also the antenna mask for TRX from upper space is 32-bit long.
Change the antenna mask for rtw_chip_ops::set_antenna from u8 to u32.
Signed-off-by: NYan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200410100950.3199-2-yhchuang@realtek.com

Fix the following coccicheck warning:

drivers/net/wireless/marvell/libertas/mesh.c:833:5-8: Unneeded variable:
"ret". Return "0" on line 874
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: NLubomir Rintel <lkundrak@v3.sk>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200410090942.27239-1-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/st/cw1200/cw1200_spi.c:273:5-8: Unneeded variable:
"ret". Return "0" on line 279
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200410090910.27132-1-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/intel/ipw2x00/ipw2200.c:7048:5-8: Unneeded
variable: "ret". Return "0" on line 7055
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200410090850.27025-1-yanaijie@huawei.com

Fix the following coccicheck warning:

drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:3773:5-8:
Unneeded variable: "err". Return "0" on line 3781
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200410090817.26883-1-yanaijie@huawei.com

There is no need to re-implement 'netdev_alloc_skb_ip_align()' here.
Keep the code simple.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: NSergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200407193233.9439-1-christophe.jaillet@wanadoo.fr

This patch fixes commit 75388acd ("add mac80211-based driver for
legacy BCM43xx devices")

In https://bugzilla.kernel.org/show_bug.cgi?id=207093, a defect in
b43legacy is reported. Upon testing, thus problem exists on PPC and
X86 platforms, is present in the oldest kernel tested (3.2), and
has been present in the driver since it was first added to the kernel.

The problem is a corrupted channel status received from the device.
Both the internal card in a PowerBook G4 and the PCMCIA version
(Broadcom BCM4306 with PCI ID 14e4:4320) have the problem. Only Rev, 2
(revision 4 of the 802.11 core) of the chip has been tested. No other
devices using b43legacy are available for testing.

Various sources of the problem were considered. Buffer overrun and
other sources of corruption within the driver were rejected because
the faulty channel status is always the same, not a random value.
It was concluded that the faulty data is coming from the device, probably
due to a firmware bug. As that source is not available, the driver
must take appropriate action to recover.

At present, the driver reports the error, and them continues to process
the bad packet. This is believed that to be a mistake, and the correct
action is to drop the correpted packet.

Fixes: 75388acd ("add mac80211-based driver for legacy BCM43xx devices")
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Reported-and-tested by: F. Erhard <erhard_f@mailbox.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200407190043.1686-1-Larry.Finger@lwfinger.net

On some systems we can constanly see rtw88 complains:
[39584.721375] rtw_pci 0000:03:00.0: failed to send h2c command

Increase interval of each check to wait the status bit really changed.

Use read_poll_timeout() macro which fits anything we need here.
Suggested-by: NKalle Valo <kvalo@codeaurora.org>
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200407073331.397-1-kai.heng.feng@canonical.com

This patch adds the AirVasT USB wireless devices 124a:4026
to the list of supported devices. It's using the ISL3886
usb firmware. Without this modification, the wiki adapter
is not recognized.

Cc: <stable@vger.kernel.org>
Signed-off-by: NGiuseppe Marco Randazzo <gmrandazzo@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com> [formatted, reworded]
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200405220659.45621-1-chunkeey@gmail.com

Pointer 'address' is being assigned and updated in a few places
by it is never read. Hence the assignments are redundant and can
be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200405133906.381358-1-colin.king@canonical.com

There is a typo in debug message. Fix it.
s/throld/threshold
Signed-off-by: NQiujun Huang <hqjagain@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1585837078-6149-1-git-send-email-hqjagain@gmail.com

There is a spelling mistake in a trace message. Fix it.
Signed-off-by: NQiujun Huang <hqjagain@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1585815557-20212-1-git-send-email-hqjagain@gmail.com

sup_wpa feature is getting after setting feature_disable flag.
If firmware is supported sup_wpa feature,  it's always enabled
regardless of feature_disable flag.

Fixes: b8a64f0e ("brcmfmac: support 4-way handshake offloading for WPA/WPA2-PSK")
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200330052528.10503-1-jh80.chung@samsung.com