- 21 Dec, 2023 30 commits
-
-
Andrei Otcheretianski authored
AX210 devices allow concurrent P2P operation on DFS channels. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by:
Gregory Greenman <gregory.greenman@intel.com> Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20231219215605.dc39b33bf507.I04dfda24d73091fb75701279d10ac400314de488@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The firmware changed their mind, don't set the chains to zero, instead set them to 1 as we normally would for connections to APs that don't use MIMO. Fixes: 2a7ce54c ("iwlwifi: mvm: honour firmware SMPS requests") Signed-off-by:
Luciano Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Miri Korenblit authored
During ieee80211_set_active_links() we do (among the others): 1. Call drv_change_vif_links() with both old_active and new_active 2. Unassign the chanctx for the removed link(s) (if any) 3. Assign chanctx to the added link(s) (if any) 4. Call drv_change_vif_links() with the new_active links bitmap The problem here is that during step #1 the driver doesn't know whether we will activate multiple links simultaneously or are just doing a link switch, so it can't check there if multiple links are supported/enabled. (Some of the drivers might enable/disable this option dynamically) And during step #3, in which the driver already knows that, returning an error code (for example when multiple links are not supported or disabled), will cause a warning, and we will still complete the transition to the new_active links. (It is hard to undo things in that stage, since we released channels etc.) Therefore add a driver callback to check if the desired new_active links will be supported by the driver or not. This callback will be called in the beginning of ieee80211_set_active_links() so we won't do anything before we are sure it is supported. Signed-off-by:
-
Ayala Beker authored
Handle a case of time overflow, where the switch time might be smaller than the partial TSF in the beacon. Additionally, apply advertised TTLM earlier in order to be ready on time on the newly activated links. Fixes: 702e8047 ("wifi: mac80211: support handling of advertised TID-to-link mapping") Signed-off-by:
Ayala Beker <ayala.beker@intel.com> Reviewed-by:
-
Benjamin Berg authored
cfg80211_update_known_bss will always consume the passed IEs. As such, cfg80211_update_assoc_bss_entry also needs to always set the pointers to NULL so that no double free can occur. Note that hitting this would probably require being connected to a hidden BSS which is then doing a channel switch while also switching to be not hidden anymore at the same time. Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Reviewed-by:
-
Benjamin Berg authored
cfg80211_bss_update is expected to consume the IEs that are passed into it in the temporary internal BSS. This did not happen in some error cases (which are also WARN_ON paths), so change the code to use a common label and use that everywhere. Signed-off-by:
-
Benjamin Berg authored
This is a more of a cosmetic fix. The branch will only be taken if proberesp_ies is set, which implies that beacon_ies is not set unless we are connected to an AP that just did a channel switch. And, in that case we should have found the BSS in the internal storage to begin with. Signed-off-by:
-
Johannes Berg authored
When reporting the radiotap timestamp, the mactime field is usually unused, we take the data from the device_timestamp. However, there can be cases where the radiotap timestamp is better reported as a 64-bit value, so since the mactime is free, add a flag to support using the mactime as a 64-bit radiotap timestamp. Signed-off-by:
-
Johannes Berg authored
We only have a single flag free, and before using that for another mactime flag, instead refactor the mactime flags to use a 2-bit field. Signed-off-by:
-
Mukesh Sisodiya authored
UHB AP send supported power type(LPI, SP, VLP) in beacon and probe response IE and STA should connect to these AP only if their regulatory support the AP power type. Beacon/Probe response are reported to userspace with reason "STA regulatory not supporting to connect to AP based on transmitted power type" and it should not connect to AP. Signed-off-by:
Mukesh Sisodiya <mukesh.sisodiya@intel.com> Reviewed-by:
-
Andrei Otcheretianski authored
Add custom regulatory that marks DFS channels as DFS_CONCURRENT. Signed-off-by:
-
Andrei Otcheretianski authored
Some devices may support concurrent DFS operation which relies on the BSS channel width for its relaxations. Notify cfg80211 about BW change so it can schedule regulatory checks. Signed-off-by:
-
Andrei Otcheretianski authored
Due to different relaxation policies it may be needed to re-check channels after a BSS station interface is disconnected or performed a channel switch. Signed-off-by:
-
Andrei Otcheretianski authored
FCC-594280 D01 Section B.3 allows peer-to-peer and ad hoc devices to operate on DFS channels while they operate under the control of a concurrent DFS master. For example, it is possible to have a P2P GO on a DFS channel as long as BSS connection is active on the same channel. Allow such operation by adding additional regulatory flags to indicate DFS concurrent channels and capable devices. Add the required relaxations in DFS regulatory checks. Signed-off-by:
-
Jouni Malinen authored
It is possible for the TX status report for the (Re)Association Request frame to be delayed long enough for the AP's (Re)Association Response frame to be received and processed before it. If that were to happen for a case where the AP rejects the association with indication to come back later, the association timeout and retry state should not be modified anymore with the TX status information that would be processed after this. Updating the association timeout in such a reverse order of events could result in shortening the timeouts for the association comeback mechanism and that could result in the association failing. Track whether we have already processed association rejection with comeback time and if so, skip the timeout and retry update on any following TX status report. Signed-off-by:
Jouni Malinen <quic_jouni@quicinc.com> Link: https://msgid.link/20231219174814.2581575-1-j@w1.fiSigned-off-by:
-
Jonathan Corbet authored
include/net/mac80111.h contains a number of either excess or incorrect kerneldoc entries for structure members, leading to these warnings: ./include/net/mac80211.h:491: warning: Excess struct member 'rssi' description in 'ieee80211_event' ./include/net/mac80211.h:491: warning: Excess struct member 'mlme' description in 'ieee80211_event' ./include/net/mac80211.h:491: warning: Excess struct member 'ba' description in 'ieee80211_event' ./include/net/mac80211.h:777: warning: Excess struct member 'ack_enabled' description in 'ieee80211_bss_conf' ./include/net/mac80211.h:1222: warning: Excess struct member 'ampdu_ack_len' description in 'ieee80211_tx_info' ./include/net/mac80211.h:1222: warning: Excess struct member 'ampdu_len' description in 'ieee80211_tx_info' ./include/net/mac80211.h:1222: warning: Excess struct member 'ack_signal' description in 'ieee80211_tx_info' ./include/net/mac80211.h:2920: warning: Excess struct member 'radiotap_he' description in 'ieee80211_hw' Fix or remove the entries as needed. This change removes 208 warnings from a "make htmldocs" build. Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://msgid.link/87zfy4bhxo.fsf@meer.lwn.netSigned-off-by:
-
Miri Korenblit authored
We are missing the flag that indicates that capability of 40 MHz bandwidth support in HE on the LB. Add it. Signed-off-by:
-
Jonathan Corbet authored
include/net/cfg80211.h includes a number of kerneldoc entries for struct members that do not exist, leading to these warnings: ./include/net/cfg80211.h:3192: warning: Excess struct member 'band_pref' description in 'cfg80211_bss_selection' ./include/net/cfg80211.h:3192: warning: Excess struct member 'adjust' description in 'cfg80211_bss_selection' ./include/net/cfg80211.h:6181: warning: Excess struct member 'bssid' description in 'wireless_dev' ./include/net/cfg80211.h:6181: warning: Excess struct member 'beacon_interval' description in 'wireless_dev' ./include/net/cfg80211.h:7299: warning: Excess struct member 'bss' description in 'cfg80211_rx_assoc_resp_data' Remove and/or repair each entry to address the warnings and ensure a proper docs build for the affected structures. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://msgid.link/87plz1g2sc.fsf@meer.lwn.netSigned-off-by:
-
David Lin authored
Variable firmware_stat is possible to be used without initialization. Signed-off-by:
David Lin <yu-hao.lin@nxp.com> Fixes: 1c5d463c ("wifi: mwifiex: add extra delay for firmware ready") Cc: stable@vger.kernel.org Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202312192236.ZflaWYCw-lkp@intel.com/Acked-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231221015511.1032128-1-yu-hao.lin@nxp.com
-
Su Hui authored
Using calculate_bit_shift() to replace rtl8723_phy_calculate_bit_shift(). And fix an undefined bitwise shift behavior problem. Signed-off-by:
Su Hui <suhui@nfschina.com> Signed-off-by:
-
Su Hui authored
Using calculate_bit_shift() to replace rtl8723_phy_calculate_bit_shift(). And fix the undefined bitwise shift behavior problem. Fixes: 0a168b48 ("rtlwifi: rtl8723ae: rtl8723-common: Create new driver for common code") Signed-off-by:
-
Su Hui authored
Using calculate_bit_shift() to replace _rtl92s_phy_calculate_bit_shift(). And fix the undefined bitwise shift behavior problem. Fixes: d1585316 ("rtlwifi: rtl8192se: Merge phy routines") Signed-off-by:
-
Su Hui authored
Using calculate_bit_shift() to replace _rtl92ee_phy_calculate_bit_shift(). And fix the undefined bitwise shift behavior problem. Fixes: b1a3bfc9 ("rtlwifi: rtl8192ee: Move driver from staging to the regular tree") Signed-off-by:
-
Su Hui authored
Using calculate_bit_shift() to replace _rtl92d_phy_calculate_bit_shift(). And fix the undefined bitwise shift behavior problem. Fixes: 7274a8c2 ("rtlwifi: rtl8192de: Merge phy routines") Signed-off-by:
-
Su Hui authored
Using calculate_bit_shift() to replace _rtl92c_phy_calculate_bit_shift(). And fix the undefined bitwise shift behavior problem. Fixes: 0c817338 ("rtl8192ce: Add new driver") Signed-off-by:
-
Su Hui authored
Using calculate_bit_shift() to replace _rtl92c_phy_calculate_bit_shift(). And fix an undefined bitwise shift behavior problem. Fixes: f0a39ae7 ("rtlwifi: rtl8192cu: Add routine phy") Signed-off-by:
-
Su Hui authored
Using calculate_bit_shift() to replace _rtl92c_phy_calculate_bit_shift(). And fix the undefined bitwise shift behavior problem. Fixes: 4295cd25 ("rtlwifi: Move common parts of rtl8192ce/phy.c") Signed-off-by:
-
Su Hui authored
Using calculate_bit_shift() to replace _rtl88e_phy_calculate_bit_shift(). And fix the undefined bitwise shift behavior problem. Fixes: f0eb856e ("rtlwifi: rtl8188ee: Add new driver") Signed-off-by:
-
Su Hui authored
using calculate_bit_shift() to replace _rtl8821ae_phy_calculate_bit_shift(). Signed-off-by:
-
Su Hui authored
There are many same functions like _rtl88e_phy_calculate_bit_shift(), _rtl92c_phy_calculate_bit_shift() and so on. And these functions can cause undefined bitwise shift behavior. Add calculate_bit_shift() to replace them and fix undefined behavior in subsequent patches. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
- 20 Dec, 2023 10 commits
-
-
Ching-Te Ku authored
Because some platform Bluetooth will have many background scan when idle. And the frequently Bluetooth scan will break Wi-Fi traffic many times at a short duration, it will make Wi-Fi throughput become lower. This patch will shorter Bluetooth slot and adjust priority settings, make Wi-Fi can have a more completed duration to do traffic. Signed-off-by:
Ching-Te Ku <ku920601@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
More readable on the coexistence log. Signed-off-by:
-
Ching-Te Ku authored
Coexistence will set the RF parameter according to Wi-Fi link mode, Wi-Fi/Bluetooth signal level, traffic direction, antenna type, and is there Bluetooth connection exist or not. Bluetooth will notify the current LNA level by scoreboard. If the setting not as expected, coexistence will try to assign the correct level. Signed-off-by:
-
Ching-Te Ku authored
In order to control RF LNA setting, need Bluetooth RSSI level information. RSSI level separate Bluetooth RSSI to several level, so the mechanism can assign a corresponding setting. Signed-off-by:
-
Ching-Te Ku authored
To avoid Bluetooth reconnecting/pairing fail during Wi-Fi is link/scan, especially the Bluetooth connect event after the platform restart/boot up. Signed-off-by:
-
Ching-Te Ku authored
Including Wi-Fi RF mode to judge is Wi-Fi RF still on or off, if Wi-Fi is RF off should set scoreboard to let Bluetooth know Wi-Fi has gone. Every time the Wi-Fi radio state changed firmware should force execute refresh the TDMA coexistence mechanism to prevent incorrect mechanism runs at mismatch state. The coexistence antenna/TDMA settings should consider what the Wi-Fi mode it is now, this can help to solve some LPS transient state issue like A2DP slightly glitch. Signed-off-by:
-
Ching-Te Ku authored
This can help to debug the grant signal and antenna path control issue during Wi-Fi power saving mode. Signed-off-by:
-
Ching-Te Ku authored
BTG is a RF system type, it means Wi-Fi 2.4GHz and Bluetooth share RF gain and antenna. The RF gain must control by Wi-Fi or Bluetooth in single side. For example, if Bluetooth RX a very strong signal, then Bluetooth will adjust to a lower gain. And Wi-Fi will also use the same gain to do RX, then maybe the gain will not enough. This BTG control mechanism can do some refine to this situation. Signed-off-by:
-
Ching-Te Ku authored
Pre-AGC(Auto gain control) is a hardware mechanism, it will auto adjust the RX gain for every packet, it can help to keep Wi-Fi signal on a well RX quality. The coexistence will give advice to control the API and monitor the settings by firmware report. Also add function to check register, these registers were monitoring by Wi-Fi firmware and report to coexistence driver periodically. This can help to track whether these settings were taking effect or not. Signed-off-by:
-
Ching-Te Ku authored
This information will use as judgment about how to set RF/HW parameters. Signed-off-by:
-
