- 29 Apr, 2024 11 commits
-
-
Jiapeng Chong authored
The assignment of the else and if branches is the same in the "case: MLO_2_PLUS_0_1RF" branch of the function rtw89_phy_get_kpath, so we remove it and add comments here to make the code easier to understand. ./drivers/net/wireless/realtek/rtw89/phy.c:6406:2-4: WARNING: possible condition with no effect (if == else). Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=8812Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240422072922.50940-1-jiapeng.chong@linux.alibaba.com
-
Ching-Te Ku authored
If there is any changes with Wi-Fi/Bluetooth, the mechanism will trigger run_coex to update information and coexistence mechanism. Enable/Disable reports here can make sure the action take effect in time. Signed-off-by:
Ching-Te Ku <ku920601@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
BTG(A hardware block, which Wi-Fi 2.4Ghz & Bluetooth shared a part of hardware). Because some information are saved in role info. So the logic also need to get value from the version 8 role info. Signed-off-by:
-
Ching-Te Ku authored
This function is to let Bluetooth know Wi-Fi is using which channel, and ask Bluetooth do not hop into the nearby channel. Wi-Fi channel is saved at role info, this patch make the logic also get the channel value from version 8 role info. Signed-off-by:
-
Ching-Te Ku authored
It will assign wrong value to version 7 slot parameter setting, because the structure member order has changed. Add a for-loop to assign variables manually. Signed-off-by:
-
Ching-Te Ku authored
The report is reported from Bluetooth, it shows the current Bluetooth driver & firmware version code. Wi-Fi & Bluetooth need to use compatible version. The version 7 report adjust the structure variables order. Signed-off-by:
-
Ching-Te Ku authored
The report is reported from Bluetooth, it described the usable Bluetooth channel map. Bluetooth should not hopped into Wi-Fi using channel. Version 8 report adjust the structure variables order. Signed-off-by:
-
Ching-Te Ku authored
This report is reported from Bluetooth, it described Bluetooth scan parameters. Version 7 adjust the structure variables order. Signed-off-by:
-
Ching-Te Ku authored
The mechanism will use Wi-Fi null packet to stop the packets from access point to avoid the interference to Bluetooth when switch to Bluetooth slot. The report can check whether the null packet is working as expected or not. Signed-off-by:
-
Ping-Ke Shih authored
RFE type 5 of 8852B is a type of hardware module, which can use different external components, so update register settings accordingly. Signed-off-by:
-
Kuan-Chung Chen authored
The CTS cannot be received by the peer due to center frequency deviation. This issue can be solved by correct settings to transmit proper CTS. Signed-off-by:
Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by:
-
- 23 Apr, 2024 12 commits
-
-
Ching-Te Ku authored
The report index has changed, correct the index for the corresponding firmware version. Signed-off-by:
-
Ching-Te Ku authored
This report summary monitor the firmware related counters, firmware version. It will help to analysis the communication between driver and firmware. Signed-off-by:
-
Ching-Te Ku authored
The feature can help to know how the firmware mechanism working. There are several trigger point set in firmware. If driver send the H2C command to firmware to enable the trigger, firmware will toggle GPIO to perform the firmware mechanism. Signed-off-by:
-
Ching-Te Ku authored
To avoid driver I/O, firmware will periodic monitor the register settings and update to driver. The v7 report adjust the structure variables order, so driver does changes accordingly. Signed-off-by:
-
Ching-Te Ku authored
When the PTA breaks Wi-Fi traffic request caused Bluetooth traffic, it means Bluetooth polluted the Wi-Fi traffic. When Wi-Fi is TX, the mechanism can ignore the polluted Wi-Fi packet retry counter, it is help to the stability of Wi-Fi TX rate. The chip RTL8922A has not only one MAC, so need to include the all MAC as reference. Signed-off-by:
-
Ching-Te Ku authored
PTA(packet traffic arbitration) is a coexistence hardware feature. Wi-Fi & Bluetooth owns their PTA, the function is to show whose PTA control the traffic now. RTL8922A PTA control is controlled by hardware logic, there is no register to monitor the setting. Signed-off-by:
-
Ching-Te Ku authored
The map is the H2C index for driver forward the driver status to firmware. The status is for firmware to make mechanism decision, if driver provided the wrong index to firmware, it will make parse the status incorrectly. Signed-off-by:
-
Ching-Te Ku authored
To support v7 version firmware cycle report, which adjusts the structure variables order, apply the related structure and functions. The cycle report can show how the firmware mechanism runs. Signed-off-by:
-
Ching-Te Ku authored
The Wi-Fi/Bluetooth slot are toggled by firmware timer when Wi-Fi doing firmware scan, and Wi-Fi slot don't allow Bluetooth do traffic when Wi-Fi slot. It will trigger Bluetooth audio lag in a random rate, because Bluetooth can not have enough time slot to keep enough data to play audio. This patch make Bluetooth can do traffic during Wi-Fi slot, this can help Bluetooth to collect audio data in time. Signed-off-by:
-
Bitterblue Smith authored
Software control (on/off) and hardware control (automatic blinking) tested with EDUP EP-N8568. Signed-off-by:
Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by:
-
Bitterblue Smith authored
Also, don't set bit 7 of LEDCFG2 for RTL8192CU. If bit 7 is set the LED never turns on. In this family only RTL8188CUS needs bit 7 of LEDCFG2 set. Software control (on/off) and hardware control (automatic blinking) tested with Netcore NW362 (RTL8192CU). Signed-off-by:
-
Bitterblue Smith authored
Until now RTL8192CU family was using the MAC init table from RTL8723AU, but these tables are not identical in the two vendor drivers. Import the correct table for RTL8192CU. Also move the existing MAC init table to rtl8xxxu_8723a.c, which is the only remaining user. Tested with the Netcore NW362 (RTL8192CU). Signed-off-by:
-
- 22 Apr, 2024 5 commits
-
-
Martin Kaistra authored
In order to connect to networks which require 802.11w, add the MFP_CAPABLE flag and let mac80211 do the actual crypto in software. When a robust management frame is received, rx_dec->swdec is not set, even though the HW did not decrypt it. Extend the check and don't set RX_FLAG_DECRYPTED for these frames in order to use SW decryption. Use the security flag in the RX descriptor for this purpose, like it is done in the rtw88 driver. Cc: stable@vger.kernel.org Signed-off-by:
Martin Kaistra <martin.kaistra@linutronix.de> Signed-off-by:
-
Martin Kaistra authored
This reverts commit 77f5924f. There is a more elegant solution to check for not decrypted frames, which is to check the security flag in the RX descriptor. Revert commit 77f5924f ("wifi: rtl8xxxu: enable MFP support") in favor of this to be able to send it to stable. Signed-off-by:
-
Ping-Ke Shih authored
Driver throws messages when scanning with a lot of traffic, because packets in TX buffer can not be transmitted in time. Since this is a common occurrence, change them to debug message with special debug mask that developers can turn on this mask by default for further analysis. Cc: Lewis Robbins <lewis.robbins2@gmail.com> Tested-by:
Lewis Robbins <lewis.robbins2@gmail.com> Signed-off-by:
-
Zong-Zhe Yang authored
When hal_reset on MAC_1/PHY_1, we should pass tx_en1 instead of tx_en0. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
We will support MLO on 802.11be chip, e.g. RTL8922A, in the future. At that time being, we will set WIPHY_FLAG_SUPPORTS_MLO according to chip info and FW features at runtime. But, with WIPHY_FLAG_SUPPORTS_MLO flag, cfg80211 will disable WEXT. In case inconsistent user experience, if 802.11be chip, we disable WEXT uniformly from now on. Signed-off-by:
-
- 19 Apr, 2024 1 commit
-
-
Bitterblue Smith authored
Don't subtract 1 from the power index. This was added in commit 2fc0b8e5 ("rtl8xxxu: Add TX power base values for gen1 parts") for unknown reasons. The vendor drivers don't do this. Also correct the calculations of values written to REG_OFDM0_X{C,D}_TX_IQ_IMBALANCE. According to the vendor driver, these are used for TX power training. With these changes rtl8xxxu sets the TX power of RTL8192CU the same as the vendor driver. None of this appears to have any effect on my RTL8192CU device. Cc: stable@vger.kernel.org Signed-off-by:
-
- 18 Apr, 2024 9 commits
-
-
Zong-Zhe Yang authored
According to BIOS configuration of Realtek ACPI DSM function 7, RTW89_ACPI_DSM_FUNC_6GHZ_SP_SUP, we handle the regd policy of 6 GHz SP. If BIOS indicates to override driver settings, we only allow the countries, which are enabled by BIOS, to use 6 GHz SP power. Other countries will be applied to select default power when recalculating 6 GHz regulatory power selection. Signed-off-by:
-
Zong-Zhe Yang authored
Realtek ACPI DSM func 7, RTW89_ACPI_DSM_FUNC_6GHZ_SP_SUP, accepts a format via ACPI buffer as below. | index | description | -------------------------------------------- | [0-3] | signature | | [4] | revision | | [5] | override driver settings, or not | | [6] | configuration if override | | [7] | reserved | where field of [6] is a bitmap by country, and for now, only define BIT(0) is for US. Through this function with overriding, BIOS can indicate to allow/block 6 GHz SP power by country. Signed-off-by:
-
Zong-Zhe Yang authored
Originally, we have an ACPI function to determine whether to enable UNII-4. Since IC (Industry Canada) has allowed UNII-4, the ACPI result is extended to be two bits as below. * BIT(0): determine if rtw89_regd::FCC enable UNII-4 * BIT(1): determine if rtw89_regd::IC enable UNII-4 Besides, to take old platforms into account, we enable UNII-4 on IC if and only if BIOS configuration enable it. Signed-off-by:
-
Zong-Zhe Yang authored
We allow 6 GHz on target regd if and only if 1. it is a specific country, i.e. not any world-wide cases 2. its 6 GHz is not blocked So, for world-wide cases, their 6 GHz will be blocked now. Signed-off-by:
-
Zong-Zhe Yang authored
Deconfigure fields for 6GHz SP. Don't use these set of values until getting certification of 6GHz SP regulation. Without configuring these fields, driver takes world-wide values when 6GHz SP cases. Signed-off-by:
-
Zong-Zhe Yang authored
Deconfigure fields for 6GHz SP. Don't use these set of values until getting certification of 6GHz SP regulation. Without configuring these fields, driver takes world-wide values when 6GHz SP cases. Signed-off-by:
-
Zong-Zhe Yang authored
We have some policy via BIOS to block uses of 6 GHz. In this case, 6 GHz sband will be NULL even if it is WiFi 7 chip. So, add NULL handling here to avoid crash. Signed-off-by:
-
Zong-Zhe Yang authored
TX power in MAC domain is signed 7 bits. (unit: based on txpwr_factor_mac) The valid range should be [-64, 63]. While the original wrong bounds might not really be encountered, still make them correct. Signed-off-by:
-
Ping-Ke Shih authored
The DMA channel of firmware command doesn't use TX WD (WiFi descriptor), so don't need to consider number of TX WD as factor of TX resource. Otherwise, during pause state (a transient state to switch to/from low power mode) firmware commands could be dropped and driver throws warnings suddenly: rtw89_8852ce 0000:04:00.0: no tx fwcmd resource rtw89_8852ce 0000:04:00.0: failed to send h2c The case we met is that driver sends RSSI strength of firmware command at RX path that could be running concurrently with switching low power mode. The missing of this firmware command doesn't affect user experiences, because the RSSI strength will be updated again after a while. The DMA descriptors of normal packets has three layers like: +-------+ | TX BD | (*n elements) +-------+ | | +-------+ +-> | TX WD | (*m elements) +-------+ | | +--------+ +-> | SKB | +--------+ And, firmware command queue (TXCH 12) is a special queue that has only two layers: +-------+ | TX BD | (*n elements) +-------+ | | +------------------+ +-> | firmware command | +------------------+ Fixes: 4a29213c ("wifi: rtw89: pci: correct TX resource checking in low power mode") Cc: stable@vger.kernel.org Signed-off-by:
-
- 08 Apr, 2024 2 commits
-
-
Michael-CY Lee authored
Extend the flag IEEE80211_KEY_FLAG_GENERATE_MMIE to BIP-CMAC-256, BIP-GMAC-128 and BIP-GMAC-256 for the same reason and in the same way that the flag was added originally in commit a0b4496a ("mac80211: add IEEE80211_KEY_FLAG_GENERATE_MMIE to ieee80211_key_flags"). Signed-off-by:
Michael-CY Lee <michael-cy.lee@mediatek.com> Link: https://msgid.link/20240326003036.15215-1-michael-cy.lee@mediatek.comSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Jeff Johnson authored
kernel-doc is reporting some warnings, so fix them: % scripts/kernel-doc -Wall -Werror -none include/net/mac80211.h include/net/mac80211.h:2056: warning: No description found for return value of 'wdev_to_ieee80211_vif' include/net/mac80211.h:2066: warning: No description found for return value of 'ieee80211_vif_to_wdev' include/net/mac80211.h:5603: warning: No description found for return value of 'ieee80211_beacon_cntdwn_is_complete' include/net/mac80211.h:5968: warning: No description found for return value of 'ieee80211_gtk_rekey_add' include/net/mac80211.h:6350: warning: No description found for return value of 'ieee80211_find_sta_by_link_addrs' include/net/mac80211.h:6478: warning: No description found for return value of 'ieee80211_txq_airtime_check' include/net/mac80211.h:6981: warning: No description found for return value of 'rate_control_set_rates' include/net/mac80211.h:7142: warning: No description found for return value of 'ieee80211_tx_prepare_skb' include/net/mac80211.h:7156: warning: No description found for return value of 'ieee80211_parse_tx_radiotap' include/net/mac80211.h:7277: warning: No description found for return value of 'ieee80211_tx_dequeue' include/net/mac80211.h:7292: warning: No description found for return value of 'ieee80211_tx_dequeue_ni' include/net/mac80211.h:7324: warning: No description found for return value of 'ieee80211_next_txq' include/net/mac80211.h:7405: warning: No description found for return value of 'ieee80211_txq_may_transmit' include/net/mac80211.h:7466: warning: No description found for return value of 'ieee80211_calc_rx_airtime' include/net/mac80211.h:7480: warning: No description found for return value of 'ieee80211_calc_tx_airtime' include/net/mac80211.h:7528: warning: No description found for return value of 'ieee80211_is_tx_data' include/net/mac80211.h:7562: warning: No description found for return value of 'ieee80211_set_active_links' 17 warnings as Errors Signed-off-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Tested-by:
-
