- 06 Jun, 2023 2 commits
-
-
Yedidya Benshimol authored
This new version of missed beacon notification uses link_id instead of mac_id. Also add an option to use link id for retrieving vif. Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230524203151.17fe1cc632f1.Id1fabb532e2174712fe17d4ad86a2c8c64ae84da@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Golan Ben Ami authored
FW version is now frozen for 22500 devices. Don't allow newer versions in the driver. Signed-off-by: Golan Ben Ami <golan.ben.ami@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230524203151.8a25ebf9134c.I3f1454498322ce28cb687d28c091c7ee092cefca@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 01 Jun, 2023 2 commits
-
-
Juhee Kang authored
pktq_empty was added in commit 5b435de0 ("net: wireless: add brcm80211 drivers") but it is currently not being utilized in some areas. This commit replaces the open code with the pktq_empty() function. Signed-off-by: Juhee Kang <claudiajkang@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230527114954.3281-2-claudiajkang@gmail.com
-
Juhee Kang authored
Although rtl_get_hdr was added in commit 3dad618b ("rtlwifi: Change wifi.h for rtl8192se and rtl8192de"), it is currently not being utilized in some areas. This commit replaces the open code with the rtl_get_hdr() function. Signed-off-by: Juhee Kang <claudiajkang@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230527114954.3281-1-claudiajkang@gmail.com
-
- 27 May, 2023 3 commits
-
-
Sascha Hauer authored
When receiving more rx packets than the kernel can handle the driver drops the packets and issues an error message. This is bad for two reasons. The logs are flooded with myriads of messages, but then time consumed for printing messages in that critical code path brings down the device. After some time of excessive rx load the driver responds with: rtw_8822cu 1-1:1.2: failed to get tx report from firmware rtw_8822cu 1-1:1.2: firmware failed to report density after scan rtw_8822cu 1-1:1.2: firmware failed to report density after scan The device stops working until being replugged. Fix this by lowering the priority to debug level and also by ratelimiting it. Fixes: a82dfd33 ("wifi: rtw88: Add common USB chip support") Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230524103934.1019096-1-s.hauer@pengutronix.de
-
Dongliang Mu authored
The ray_config uses ray_release as its unified error handling function. However, it does not know if local->sram/rmem/amem succeeds or not. Fix this by adding sanity check on local->sram/rmem/amem in the ray_relase. Signed-off-by: Dongliang Mu <dzm91@hust.edu.cn> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230316133236.556198-3-dzm91@hust.edu.cn
-
Dongliang Mu authored
In ray_detach, it and its child function ray_release both call del_timer(_sync) on the same timer. Fix this by removing the del_timer_sync in the ray_detach, and revising the del_timer to del_timer_sync. Signed-off-by: Dongliang Mu <dzm91@hust.edu.cn> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230316133236.556198-2-dzm91@hust.edu.cn
-
- 25 May, 2023 27 commits
-
-
Christophe JAILLET authored
Should ray_config() fail, some resources need to be released as already done in the remove function. While at it, remove a useless and erroneous comment. The probe is ray_probe(), not ray_attach(). Fixes: 15b99ac1 ("[PATCH] pcmcia: add return value to _config() functions") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/8c544d18084f8b37dd108e844f7e79e85ff708ff.1684570373.git.christophe.jaillet@wanadoo.fr
-
Christophe JAILLET authored
Should wl3501_config() fail, some resources need to be released as already done in the remove function. Fixes: 15b99ac1 ("[PATCH] pcmcia: add return value to _config() functions") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/7cc9c9316489b7d69b36aeb0edd3123538500b41.1684569865.git.christophe.jaillet@wanadoo.fr
-
Christophe JAILLET authored
Should atmel_config() fail, some resources need to be released as already done in the remove function. While at it, remove a useless and erroneous comment. The probe is atmel_probe(), not atmel_attach(). Fixes: 15b99ac1 ("[PATCH] pcmcia: add return value to _config() functions") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/1e65f174607a83348034197fa7d603bab10ba4a9.1684569156.git.christophe.jaillet@wanadoo.fr
-
Christophe JAILLET authored
Should orinoco_cs_config() fail, some resources need to be released as already done in the remove function. While at it, remove a useless and erroneous comment. The probe is orinoco_cs_probe(), not orinoco_cs_attach(). Fixes: 15b99ac1 ("[PATCH] pcmcia: add return value to _config() functions") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/e24735ce4d82901d5f7ea08419eea53bfdde3d65.1684568286.git.christophe.jaillet@wanadoo.fr
-
Christophe JAILLET authored
Should spectrum_cs_config() fail, some resources need to be released as already done in the remove function. While at it, remove a useless and erroneous comment. The probe is spectrum_cs_probe(), not spectrum_cs_attach(). Fixes: 15b99ac1 ("[PATCH] pcmcia: add return value to _config() functions") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/c0bc0c21c58ca477fc5521607615bafbf2aef8eb.1684567733.git.christophe.jaillet@wanadoo.fr
-
Arnd Bergmann authored
struct rtw89_btc_btf_tlv contains a one-byte member that is intended as a flexible array: In function 'fortify_memcpy_chk', inlined from '_append_tdma' at drivers/net/wireless/realtek/rtw89/coex.c:1579:3: include/linux/fortify-string.h:583:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 583 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Make this actually use a flexible array to let the compiler understand. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230523113241.2772811-1-arnd@kernel.org
-
Colin Ian King authored
There is a spelling mistake in a literal string. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522085924.913649-1-colin.i.king@gmail.com
-
Ping-Ke Shih authored
The register-based H2C/C2H are used to exchange commands and events with firmware. The exchange data is limited, but it is relatively simple, because it can work before HCI initialization. To make these code clean, use struct to access them. This patch doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522122513.13559-6-pkshih@realtek.com
-
Ping-Ke Shih authored
RX descriptor is to provide basic and important information related to packets, such as packet size, security, MAC ID and so on. Change to use struct to access these fields, and not change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522122513.13559-5-pkshih@realtek.com
-
Ping-Ke Shih authored
PHY status IEs generated by BB hardware is to provide more detail information related to received packets, such as RSSI and bandwidth. To avoid type casting, change buf type from u8* to void* as well. This patch doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522122513.13559-4-pkshih@realtek.com
-
Ping-Ke Shih authored
If received packet type is PPDU status, RX info provides information attached by MAC hardware, and mention how long BB information attached. This conversion patch doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522122513.13559-3-pkshih@realtek.com
-
Ping-Ke Shih authored
The next generation chips use different RX descriptor format, so add a chip_ops to hook suitable handlers. Also, the length of RX descriptor is different, so add a variable to store the length according to chip and descriptor content dynamically. Then, the code can be more general. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522122513.13559-2-pkshih@realtek.com
-
Ping-Ke Shih authored
Since 8851BE is ready, so add 8851BE to Makefile and Kconfig. Currently, it can support STA, AP and monitor modes with good performance. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230519031500.21087-8-pkshih@realtek.com
-
Chin-Yen Lee authored
8851B has the same issue: management frames get stuck when WiFi chip enters low PS mode, so we also add notify wake function to trigger WiFi chip wake before forwarding management frames. 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/20230519031500.21087-7-pkshih@realtek.com
-
Ping-Ke Shih authored
The register ranges of upcoming chips are different from current, and even existing chips have different ranges, so support longer length to dump registers. Then, user space can decide the ranges according to chip. Since arbitrary length (e.g. 7) would be a little complicated, so simply make length a multiple of 16. The output looks like 18620000h : 8580801f 82828282 82828282 080800fd Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230519031500.21087-6-pkshih@realtek.com
-
Ping-Ke Shih authored
RF configurations include RF calibrations and getting thermal value. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230519031500.21087-5-pkshih@realtek.com
-
Ping-Ke Shih authored
These configurations include path control, TX grant, TX scheduler, register-based H2C/C2H and so on. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230519031500.21087-4-pkshih@realtek.com
-
Ping-Ke Shih authored
These capabilities include helpers of BT coexistence, RX PPDU status parser, DIG (dynamic initial gain) and CFO (center frequency offset) settings. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230519031500.21087-3-pkshih@realtek.com
-
Ping-Ke Shih authored
Get TX power value from tables according to selected country and channel, and set proper power to registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230519031500.21087-2-pkshih@realtek.com
-
Zong-Zhe Yang authored
H2C of packet offload needs to wait FW ACK by C2H. But, it's possible that packet offload happens during SER (system error recovery), e.g. SER L2 which restarts HW. More, packet offload flow isn't deferrable. So, the H2C wait may get `ret == 1` (unreachable). However, the logic FW deals with packet offload is simple enough, just clone content. It means that as long as the H2C is issued successfully, the thing will succeed sooner or later. Therefore, after we add a debug log when receiving ACK to packet offload, it would be acceptable that during SER, packet offload don't really wait for ACK. And, if debugging, we can still check its debug logs. Besides, we can expect that if we see SER before receiving ACK to packet offload, those debug logs of the ACK have a time difference. 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/20230516082441.11154-4-pkshih@realtek.com
-
Zong-Zhe Yang authored
Some specific H2C (host to chip command) needs waiting until FW ACK by C2H (chip to host event). However, during SER (system error recovery), most interrupts are disabled, so we can't receive C2H immediately. It causes this kind of H2C TX waits will always time out during SER. To save time spent by SER, we don't do these redundant waits. And, to make a difference from -ETIMEDOUT in other cases, we make the function return 1 for SER case. When some H2C callers really catch `ret == 1` at runtime, they can determine whether it's reasonable or not, and consider how to resolve their flow if needed. 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/20230516082441.11154-3-pkshih@realtek.com
-
Zong-Zhe Yang authored
The total_sta_assoc and the tdls_peer are used for statistics accodring to stations' information. L2 (Level 2) SER (system error recovery) will call ieee80211_restart_hw() which re-invokes sta_state ops. And then, the total_sta_assoc and tdls_peer will be re-increased. In case wrong statistics results, we reset them in SER L2 handling. 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/20230516082441.11154-2-pkshih@realtek.com
-
Martin Blumenstingl authored
Wire up RTL8723DS chipset support using the rtw88 SDIO HCI code as well as the existing RTL8723D chipset code. Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522202425.1827005-5-martin.blumenstingl@googlemail.com
-
Martin Blumenstingl authored
RTL8723DS comes in two variant and each of them has their own SDIO ID: - 0xd723 can connect two antennas. The WiFi part is still 1x1 so the second antenna can be dedicated to Bluetooth - 0xd724 can only connect one antenna so it's shared between WiFi and Bluetooth Add a new entry for the single antenna RTL8723DS (0xd724) which can be found on the MangoPi MQ-Quad. Also rename the existing RTL8723DS entry (0xd723) so it's name reflects that it's the variant with support for two antennas. Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522202425.1827005-4-martin.blumenstingl@googlemail.com
-
Martin Blumenstingl authored
The efuse of the SDIO RTL8723DS chip has only one known member: the mac address is at offset 0x11a. Add a struct rtw8723ds_efuse describing this and use it for copying the mac address when the SDIO bus is used. Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522202425.1827005-3-martin.blumenstingl@googlemail.com
-
Martin Blumenstingl authored
rtw_sdio_rx_isr() is responsible for receiving data from the wifi chip and is called from the SDIO interrupt handler when the interrupt status register (HISR) has the RX_REQUEST bit set. After the first batch of data has been processed by the driver the wifi chip may have more data ready to be read, which is managed by a loop in rtw_sdio_rx_isr(). It turns out that there are cases where the RX buffer length (from the REG_SDIO_RX0_REQ_LEN register) does not match the data we receive. The following two cases were observed with a RTL8723DS card: - RX length is smaller than the total packet length including overhead and actual data bytes (whose length is part of the buffer we read from the wifi chip and is stored in rtw_rx_pkt_stat.pkt_len). This can result in errors like: skbuff: skb_over_panic: text:ffff8000011924ac len:3341 put:3341 (one case observed was: RX buffer length = 1536 bytes but rtw_rx_pkt_stat.pkt_len = 1546 bytes, this is not valid as it means we need to read beyond the end of the buffer) - RX length looks valid but rtw_rx_pkt_stat.pkt_len is zero Check if the RX_REQUEST is set in the HISR register for each iteration inside rtw_sdio_rx_isr(). This mimics what the RTL8723DS vendor driver does and makes the driver only read more data if the RX_REQUEST bit is set (which seems to be a way for the card's hardware or firmware to tell the host that data is ready to be processed). For RTW_WCPU_11AC chips this check is not needed. The RTL8822BS vendor driver for example states that this check is unnecessary (but still uses it) and the RTL8822CS drops this check entirely. Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522202425.1827005-2-martin.blumenstingl@googlemail.com
-
Niklas Schnelle authored
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Arnd Bergmann <arnd@kernel.org> Acked-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522105049.1467313-44-schnelle@linux.ibm.com
-
- 17 May, 2023 6 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for v6.5. Major changes: ath11k * Multiple Basic Service Set Identifier (MBSSID) and Enhanced MBSSID Advertisement (EMA) support in AP mode
-
Maharaja Kennadyrajan authored
Due to the firmware behavior with HT fixed rate setting, HT fixed rate MCS with NSS > 1 are treated as NSS = 1 HT rates in the firmware and enables the HT fixed rate of NSS = 1. This leads to HT fixed rate is always configured for NSS = 1 even though the user sets NSS = 2 or > 1 HT fixed MCS in the set bitrate command. Currently HT fixed MCS is sent via WMI peer assoc command. Fix this issue, by sending the HT fixed rate MCS in WMI peer fixed param instead of sending in peer assoc command. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Signed-off-by: Maharaja Kennadyrajan <quic_mkenna@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230504092033.3542456-3-quic_mkenna@quicinc.com
-
Maharaja Kennadyrajan authored
wifi: ath11k: Relocate the func ath11k_mac_bitrate_mask_num_ht_rates() and change hweight16 to hweight8 Relocate the function ath11k_mac_bitrate_mask_num_ht_rates() definition to call this function from other functions which helps to avoid the compilation error (function not defined). ht_mcs[] is 1 byte array and it is enough to use hweight8() instead of hweight16(). Hence, fixed the same. Tested on: Compile tested only. Signed-off-by: Maharaja Kennadyrajan <quic_mkenna@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230504092033.3542456-2-quic_mkenna@quicinc.com
-
Aishwarya R authored
When vdev start/stop happens, response from firmware is received with delay and hence there is a timeout before VDEV can be up/down. Also, with maximum peers connected and when vdev stop occurs, firmware will take time to clean up all the peers and vap queues. In such cases as well, vdev start/stop response is sent by firmware with delay. Increase the vdev setup timeout as recommended by firmware team. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0-02903-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aishwarya R <quic_aisr@quicinc.com> Signed-off-by: Ramya Gnanasekar <quic_rgnanase@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230428091041.20033-1-quic_rgnanase@quicinc.com
-
Ping-Ke Shih authored
TSSI is transmitter signal strength indication, which is a close-loop hardware circuit to feedback actual transmitting power as a reference for next transmission. When we setup channel to connect an AP, it does full calibration. When switching bands or channels, it needs to reset hardware status to prevent use wrong feedback of previous transmission. To do TX power compensation reflecting current temperature, it loads tables of compensation values into registers according to channel and band group. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230513054425.9689-4-pkshih@realtek.com
-
Ping-Ke Shih authored
DPK is short for digital pre-distortion calibration. It can adjusts digital waveform according to PA linear characteristics dynamically to enhance TX EVM. Do this calibration when we are going to run on AP channel. To prevent power offset out of boundary, it monitors thermal and set proper boundary to register. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230513054425.9689-3-pkshih@realtek.com
-