- 18 Sep, 2023 16 commits
-
-
Ping-Ke Shih authored
Using mac_gen pointer to reuse the code with WiFi 7 chips, and define MAC ports registers for WiFi 7 chips. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230911082049.33541-7-pkshih@realtek.com
-
Ping-Ke Shih authored
MAC port is a design to support virtual interface on single MAC hardware. For next generation chips, register addresses are changed but definitions are the same, so move registers together to be easier to reuse codes. Signed-off-by:
-
Ping-Ke Shih authored
For existing chips, size of TX WD info is 6 words, but upcoming WiFi 7 chips become 8 words, so add a chip_info to reuse the code. Signed-off-by:
-
Ping-Ke Shih authored
The format v2 of TX descriptor contains 8-word body and 8-word info, and fields include packet size, MAC_ID, security key ID and etc. By design, it can possibly only fill body to reduce overhead, but this driver keeps thing simple, so always fill body and info currently. Signed-off-by:
-
Ping-Ke Shih authored
This kind of TX descriptor is used to download firmware or send firmware command. Because we want to reduce descriptor overhead and this only needs two fields 'size' and 'type', hardware designers choose short form of RX descriptor for it. Signed-off-by:
-
Ping-Ke Shih authored
RX descriptor is used to provide meta data of received data. The WiFi 7 chips use different RX descriptor format, so add this parser along with hardware design. Signed-off-by:
-
Zong-Zhe Yang authored
In MCC STA+GO mode, we calculate NoA information and fill it into the beacon of P2P GO. Since NoA uses only 32 bits to describe time things, we need to deal with renewal when TSF[63:32] is carried. We trigger FW to notify that. Then, we can update NoA information for new time period once we get notification from FW. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
When receiving request of adjusting BT slot from coex. mechanism, we need to fetch the new BT slot and use the new one to calculate MCC (multi-channel concurrency) pattern. Then, we update the new MCC pattern to FW. Signed-off-by:
-
Zong-Zhe Yang authored
MCC fills duration limit of a role according to NoA description. If P2P PS changes during MCC, we don't process P2P PS via normal flow. Instead, we re-fill duration limit of the role for new NoA description, and then we do MCC update. Signed-off-by:
-
Zong-Zhe Yang authored
In MCC STA+GC mode, the offset between TBTTs of remote AP and remote GO might change. If the change is larger than tolerance, we should update MCC after re-calculating parameters for new things. So, we track that in rtw89_track_work() now. And, we add MCC update flow to tell FW either to change durations of roles or to replace entire pattern according to how MCC plans BT slot. Signed-off-by:
-
Zong-Zhe Yang authored
Each MCC (multi-channel concurrency) role maintains a bitmap of mac IDs. The bitmap is supposed to contain the two points below. * mac ID of itself * mac ID(s) of STA(s) connecting to it Under STA+GC mode, the bitmaps of both roles should not change. However, under STA+GO mode, the bitmap of GO may change due to P2P clients which connect/disconnect to/from it. FW controls (TDMA-based) MCC things via mac IDs in bitmap of each role. For example, mac IDs are required by FW when it wants to pause role1's TX in role0 slot. So, to sync between driver and FW, we update the new mac ID bitmap of GO to FW once it's changed. Signed-off-by:
-
Zong-Zhe Yang authored
DPK is one kind of RF calibration. When MCC (multi-channel concurrency) start/stop, DPK needs to do extra things to be off/on. We add a chanctx callback type, RTW89_CHANCTX_CALLBACK_RFK, and register it for RTL8852C to deal with DPK according to MCC states. Signed-off-by:
-
Zong-Zhe Yang authored
After MCC (multi-channel concurrency) is started, FW will control channel changes and use the corresponding backup of RF calibration result. And, driver RF calibration (RF-K) won't be able to keep up with the speed at which the channels are changing. So, even if we keep tracking it in driver, the RF-K result might not be good either. To save these unnecessary things, we disable driver RF-K tracking during MCC. Signed-off-by:
-
Zong-Zhe Yang authored
RF calibration will notify FW to backup the calibration result after it is done on a channel. For MCC (multi-channel concurrency) flow, when we at RTW89_ENTITY_MODE_MCC_PREPARE mode, RF calibration should execute on second channel of MCC, i.e. RTW89_SUB_ENTITY_1, and then, notify FW to backup the result for the second one. Originally, the RF calibration flow only fit single channel case. We are planning to support MCC on RTL8852C, so we refine its RF calibration flow to fit MCC case. Signed-off-by:
-
Jeff Johnson authored
While converting struct ieee80211_tim_ie::virtual_map to be a flexible array it was observed that the TIM IE processing in cw1200_rx_cb() could potentially process a malformed IE in a manner that could result in a buffer over-read. Add logic to verify that the TIM IE length is large enough to hold a valid TIM payload before processing it. Signed-off-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by:
-
Wen Gong authored
6 GHz regulatory domains introduces Power Spectral Density (PSD). The PSD value of the regulatory rule should be taken into effect for the ieee80211_channels falling into that particular regulatory rule. Save the values in the channel which has PSD value and add nl80211 attributes accordingly to handle it. Co-developed-by:
Aditya Kumar Singh <quic_adisi@quicinc.com> Signed-off-by:
Wen Gong <quic_wgong@quicinc.com> Link: https://lore.kernel.org/r/20230914082026.3709-1-quic_wgong@quicinc.com [use hole in chan flags, reword docs] Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 14 Sep, 2023 1 commit
-
-
Johannes Berg authored
Now that I fixed the function name, we see the parameters are wrong as well. Fix that too. Change-Id: I1a4cfea446875998a5a242ca36acc8244991a199 Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 13 Sep, 2023 23 commits
-
-
Ping-Ke Shih authored
We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for "unset power level". UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211] In this case, simply return an error instead, to indicate that no data is available. Cc: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Stephen Douthit authored
If the driver doesn't fill NL80211_STA_INFO_TX_BITRATE in sta_set_sinfo() then as a fallback sta->deflink.tx_stats.last_rate is used. Unfortunately there's no guarantee that this has actually been set before it's used. Originally found when 'iw <dev> link' would always return a tx rate of 6Mbps regardless of actual link speed for the QCA9337 running firmware WLAN.TF.2.1-00021-QCARMSWP-1 in my netbook. Use the sanity check logic from ieee80211_fill_rx_status() and refactor that to use the new inline function. Signed-off-by:
Stephen Douthit <stephen.douthit@gmail.com> Link: https://lore.kernel.org/r/20230213204024.3377-1-stephen.douthit@gmail.com [change to bool ..._rate_valid() instead of int ..._rate_invalid()] Signed-off-by:
-
Emmanuel Grumbach authored
Getting a BAR can be an explanation if we're chasing packet loss. Add a print with the relevant debug level in that code path. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.913e989a1751.I6bff9020e339d91b61b5ad6aede27bcf8c7e6819@changeidSigned-off-by:
-
Johannes Berg authored
This can be moved to constants, while at it also rename it to have a better name with MVM_ prefix. Signed-off-by:
-
Miri Korenblit authored
Transition to d3 is much faster if there is no power save during the transition. Therefore a new flag was added to the device power cmd to indicate the power save isn't allowed until the transition is completed. Set this flag in _iwl_mvm_suspend, when the transition begins. Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by:
-
Johannes Berg authored
Some new fields were added to the context info structure, define them for future use. Signed-off-by:
-
Emmanuel Grumbach authored
If the firmware crashes in the de-activation / re-activation of the link during CSA, we will not have a valid phy_ctxt pointer in mvmvif. This is a legit case, but when mac80211 removes the station to cleanup our state during the re-configuration, we need to make sure we clear ap_sta otherwise we won't re-add the station after the firmware has been restarted. Later on, we'd activate the link, try to send a TLC command crash again on ASSERT 3508. Fix this by properly cleaning up our state. Signed-off-by:
-
Miri Korenblit authored
Currently we are setting the rate in the tx cmd for mgmt frames (e.g. during connection establishment). This was problematic when sending mgmt frames in eSR mode, as we don't know what link this frame will be sent on (This is decided by the FW), so we don't know what is the lowest rate. Fix this by not setting the rate in tx cmd and rely on FW to choose the right one. Set rate only for injected frames with fixed rate, or when no sta is given. Also set for important frames (EAPOL etc.) the High Priority flag. Fixes: 055b22e7 ("iwlwifi: mvm: Set Tx rate and flags when there is not station") Signed-off-by:
-
Shaul Triebitz authored
If the channel bandwidth is greater or equal than 80MHz, enable FILS DF transmittion, even if the control channel is non-PSC. That's because that in 80MHz there must be a sub 20MHz PSC channel, and since the FILS DF is duplicated on all sub 20MHz channels, within the 80MHz (hence it will be sent on a PSC channel). Also, if FILS DF Tx is enabled, always configure the firmware with the actual channel bandwidth, even before there is a connected client (rather than the minimum bandwidth e.g. 20MHz), since FILS DF transmission on a PSC channel take presedent over power consumption. Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
-
Johannes Berg authored
If the device initialized with ME active, this would indeed work, since the NVM information would be obtained from ME. However, in the much more likely case that ME isn't active and the firmware takes actions requiring the sync, this was not working correctly when the firmware is only run at init to obtain NVM data, since mac80211 isn't even initialized. Fix this by moving the 'pldr_sync' handling to a different place. Signed-off-by:
-
Emmanuel Grumbach authored
When we drop frames we want to have something printed in the logger. This won't be printed by default of course. Signed-off-by:
-
Gregory Greenman authored
Disable firmware debug asserts, which are used for internal firmware testing purposes only. Signed-off-by:
-
Miri Korenblit authored
This condition will never be true. Signed-off-by:
-
Johannes Berg authored
Enable the TOP (HW part) fatal error interrupt and add a print when it happens. Currently FW always adds also the SW error interrupt, but for >= Bz we'll need to do PLDR in case this is asserted, so leave a TODO item already. Signed-off-by:
-
Johannes Berg authored
If the hardware is not responding, as indicated by (currently) five consecutive HW errors during reading, then just give up and fail, rather than attempting forever and forever for this to not return any useful data anyway. Even though we no longer completely deadlock the machine if it takes a long time, we still make it pretty much unusable since we'll eventually hold the RTNL while waiting for this process to finish. Signed-off-by:
-
Johannes Berg authored
If the bus has no parent due to the topology, the device rescan (after some kind of reset was detected) wouldn't work. On the other hand, some platforms appear to require scanning the parent, though it's not clear why. However if there's no parent, then we skip the rescan, which isn't a good idea. Change the code to go to the parent only if that exists, and rescan the bus itself where it doesn't. Signed-off-by:
-
Aditya Kumar Singh authored
cfg80211 has cfg80211_chandef_dfs_usable() function to know whether at least one channel in the chandef is in usable state or not. Also, cfg80211_chandef_dfs_cac_time() function is there which tells the CAC time required for the given chandef. Make these two functions visible to drivers by exporting their symbol to global list of kernel symbols. Lower level drivers can make use of these two functions to be aware if CAC is required on the given chandef and for how long. For example drivers which maintains the CAC state internally can make use of these. Signed-off-by:
-
Abhishek Kumar authored
Currently the channel property updates are not propagated to driver. This causes issues in the discovery of hidden SSIDs and fails to connect to them. This change defines a new wiphy flag which when enabled by vendor driver, the reg_call_notifier callback will be trigger on beacon hints. This ensures that the channel property changes are visible to the vendor driver. The vendor changes the channels for active scans. This fixes the discovery issue of hidden SSID. Signed-off-by:
Abhishek Kumar <kuabhs@chromium.org> Link: https://lore.kernel.org/r/20230629035254.1.I059fe585f9f9e896c2d51028ef804d197c8c009e@changeidSigned-off-by:
-
Raj Kumar Bhagat authored
Currently regulatory update by driver is not allowed when the wiphy->regd is already set and drivers_request->intersect is false. During wiphy registration, some drivers (ath10k does this currently) first register the world regulatory to cfg80211 using wiphy_apply_custom_regulatory(). The driver then obtain the current operating country and tries to update the correct regulatory to cfg80211 using regulatory_hint(). But at this point, wiphy->regd is already set to world regulatory. Also, since this is the first request from driver after the world regulatory is set this will result in drivers_request->intersect set to false. In this condition the driver request regulatory is not allowed to update to cfg80211 in reg_set_rd_driver(). This restricts the device operation to the world regulatory. This driver request to update the regulatory with current operating country is valid and should be updated to cfg80211. Hence allow regulatory update by driver even if the wiphy->regd is already set and driver_request->intersect is false. Signed-off-by:
Raj Kumar Bhagat <quic_rajkbhag@quicinc.com> Reviewed-by:
-
Aloka Dixit authored
Process FILS discovery and unsolicited broadcast probe response transmission configurations in ieee80211_change_beacon(). Signed-off-by:
Aloka Dixit <quic_alokad@quicinc.com> Reviewed-by:
-
Aloka Dixit authored
FILS discovery and unsolicited broadcast probe response templates need to be updated along with beacon templates in some cases such as the channel switch operation. Add the missing implementation. Signed-off-by:
-
Aloka Dixit authored
Modify the prototype for change_beacon() in struct cfg80211_op to accept cfg80211_ap_settings instead of cfg80211_beacon_data so that it can process data in addition to beacons. Modify the prototypes of ieee80211_change_beacon() and driver specific functions accordingly. Signed-off-by:
-
Aloka Dixit authored
FILS discovery configuration gets updated only if the maximum interval is set to a non-zero value, hence there is no way to reset this value to 0 once set. Replace the check for interval with a new flag which is set only if the configuration should be updated. Add similar changes for the unsolicited broadcast probe response handling. Signed-off-by:
-
