- 17 Jun, 2024 6 commits
-
-
Ping-Ke Shih authored
Modern platforms can install more than 4GB memory, so DMA address can larger than 32 bits. If a platform doesn't enable IOMMU, kernel needs extra works of swiotlb to help DMA that packets reside on memory over 4GB. The DMA addressing capability of Realtek WiFi chips is 36 bits, so set LSB 4 bits of high 32-bit address to register and TX/RX descriptor, which below figure shows 3-level pointers in TX direction, and RX direction is similar but 2-level pointers only. +--------+ | | register to head of TX BD +---|----+ | +---------+ +-----> | TX BD | (in memory) +----|----+ | +---------+ +------> | TX WD | (in memory) +----|----+ | +--------+ +------> | skb | +--------+ Signed-off-by:Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240611021901.26394-1-pkshih@realtek.com
-
Ping-Ke Shih authored
Version C of 8922AE hardware will use the same firmware of version B, so extend rule of firmware recognition to allow less but closest firmware version. Originally only accept firmware with matched version. Tested on version A/B/C of 8922AE. Signed-off-by:
-
Ping-Ke Shih authored
Many common settings can share to 8851B, 8852B and 8852BT, so add an inline function rtw89_is_rtl885xb() to be concise. Meanwhile review and align settings for existing chips. Signed-off-by:
-
Ping-Ke Shih authored
The channel configuration of 8852BT is very similar but a little different to 8852B, so use chip ID as condition to add extra handles including external loss compensation, ADC configurations, spur settings and so on. Don't affect existing 8852BE. Signed-off-by:
-
Ping-Ke Shih authored
New upcoming chip is RTL8852BE-VT (or RTL8852BTE; 8852BT PCIE interface), which is a variant of 8852B, and many codes excepting to RF calibration can be shared, so move common code to an new kernel module named rtw89_8852b_common.ko. No logic change. Signed-off-by:
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by:
-
- 12 Jun, 2024 34 commits
-
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240603091541.8367-7-wsa+renesas@sang-engineering.com
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_interruptible_timeout() causing patterns like: timeout = wait_for_completion_interruptible_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Fix to the proper variable type 'long' while here. Signed-off-by:
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by:
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_event_timeout() causing patterns like: timeout = wait_event_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Fix to the proper variable type 'long' while here. Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Erick Archer authored
This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. As the "cmd_buf" variable is a pointer to "struct at76_command" and this structure ends in a flexible array: struct at76_command { [...] u8 data[]; } __packed; the preferred way in the kernel is to use the struct_size() helper to do the arithmetic instead of the calculation "size + count" in the kmalloc() function. Also, declare a new variable (total_size) since the return value of the struct_size() helper is used several times. At the same time, prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). In this case, it is important to note that the attribute used is "__counted_by_le" since the counter type is "__le16". This way, the code is more readable and safer. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Signed-off-by:Erick Archer <erick.archer@outlook.com> Signed-off-by:
-
Erick Archer authored
It is preferred to use sizeof(*pointer) instead of sizeof(type) due to the type of the variable can change and one needs not change the former (unlike the latter). This patch has no effect on runtime behavior. At the same time remove some redundant NULL initializations. Signed-off-by:
-
Shaul Triebitz authored
This is the first step towards removing the P2P Device MAC. Use ROC (which uses the AUX MAC) for P2P Device discoveribility and action frames. Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240605140556.8c90e457abbd.I8e340759ecb299e05b1809f3d8060429c6cbbd01@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If non-BSS and remain-on-channel (ROC) blocking were to occur simultaneously, they'd step on each other's toes, unblocking when not yet supported. Disentangle these bits, and ROC doesn't need to use the non_bss_link() function then. Fixes: a1efeb82 ("wifi: iwlwifi: mvm: Block EMLSR when a p2p/softAP vif is active") Signed-off-by:
-
Miri Korenblit authored
Stop supporting all FWs older than the max API version. These FW versions were supported since v6.5. Signed-off-by:
-
Miri Korenblit authored
When EMLSR gets unblocked, the current code checks if the last exit was due to an EXIT reason (as opposed to a BLOCKING one), and if so, it does nothing, as in this case a MLO scan was scheduled to run in 30 seconds. But the code doesn't consider the time that passed from the last exit, so if immediately after the exit a blocker occurred (e.g. non-BSS interface), and lasts for more than 30 seconds, then the MLO scan and the following link selection will decide not to enter EMLSR, and when the unblocking event finally happens, the reason is still set to the EXIT one, so it will do nothing, and we will not have the chance to re-enable EMLSR. Fix this by checking also the time that has passed since the last exit, only if it is less than 30 seconds, we can count on the scheduled MLO scan. Note that clearing the reason itself can't be done since it is needed for the EMLSR prevention mechanism. Fixes: 2f33561e ("wifi: iwlwifi: mvm: trigger link selection after exiting EMLSR") Signed-off-by:
-
Yedidya Benshimol authored
This was needed when we had multiple types of transports. Now we only have pcie, so there is no need for this ops. Cleanup the code such as the different trans APIs will call the pcie function directly, instead of calling the callback, and remove struct iwl_trans_ops. Signed-off-by:
Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by:
-
Johannes Berg authored
The TX queue code was mostly moved out to support an internal transport that we were never going to publish, but we're no longer using that. Since we're also going to be dissolving the virtual transport layer entirely, integrate the TX queue code into the PCIe layer. This also has a small kernel of already removing the virtual transport function layer, since iwl_trans_send_cmd() calls iwl_trans_pcie_send_hcmd() directly now, even if that still calls the transport send_cmd method for now, we'll clean it up later. Also, not everything is renamed yet. Signed-off-by:
-
Johannes Berg authored
This needs to include dbg-tlv.h since it uses the value of IWL_FW_INI_ALLOCATION_NUM from that file. Signed-off-by:
-
Johannes Berg authored
This really isn't correct to be in the opmode, do the clamping (and power-of-2 fixup that may be necessary due to this, or even otherwise) in the queue code. Also move down the retrying of the allocation, it should be after all the size fixups, but also it just makes sense, and avoids retrying same-size allocations in the case of the BZ-family A-step workaround. Signed-off-by:
-
Johannes Berg authored
When entering D3 we want to configure skip over DTIM, but it can't use the deflink configuration, that will not even exist. Adjust the code to handle multiple links by taking the min skip, even if we should only have a single active link at this point. Signed-off-by:
-
Miri Korenblit authored
Stop supporting older FWs. Signed-off-by:
-
Miri Korenblit authored
These entries are not used, remove them. Signed-off-by:
-
Emmanuel Grumbach authored
If a user uses iw to connect to a network and we don't have any information about the existing networks, cfg80211 will trigger a scan internally even if the user didn't ask for a scan. This scan is implemented by cfg80211_conn_scan(). This function called rdev_scan() directly without honoring the WIPHY_FLAG_SPLIT_SCAN_6GHZ flag. Use cfg80211_scan instead, this will split the scan if the low level driver asked to. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by:
-
Johannes Berg authored
There's no need to have the always-zero ret variable in the function scope, move it into the inner scope only. Signed-off-by:
-
Johannes Berg authored
When e.g. wpa_supplicant sets only the MLD "sta" authorized state, the code actually applies that change, but then returns an error to userspace anyway because there were no changes to the link station, and no link ID was given. However, it's not incorrect to not have a link ID when wanting to change only the MLD peer ("sta") state, so the code shouldn't require it. To fix this, separate the "new_link" argument out into a new three-state enum, because if modify is called on a link STA only, it should return an error if no link is given or if it doesn't exist. For modify on the MLD "sta", not having a link ID is OK, but if there is one it should be validated. This seems to not have mattered much as wpa_supplicant just prints a message and continues, and the authorized state was already set before this error return. However, in the later code powersave recalculation etc. will be skipped, so that it may result in never allowing powersave on MLO connections. Signed-off-by: -
Avraham Stern authored
Setting a channel with 320 MHz channel width over hwsim results in an array-index-out-of-bounds error. Fix it by adding 320 MHz to hwsim supported channel widths. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
Avraham Stern authored
In NDP ranging, the number of NDP exchanges is not negotiated and thus is not limited by the protocol. Remove the limit on FTMs per burst for trigger based and non trigger based ranging. Signed-off-by:
-
Benjamin Berg authored
On 6 GHz (and also 5 GHz to some degree), only a specific set of center frequencies should be used depending on the channel bandwidth. Verify this is the case on 6 GHz. For 5 GHz, we are more accepting as there are APs that got it wrong historically. Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
Add a regulatory flag to allow VLP AP operation even on channels otherwise marked NO_IR, which may be possible in some regulatory domains/countries. Note that this requires checking also when the beacon is changed, since that may change the regulatory power type. Reviewed-by:
-
Johannes Berg authored
There are two functions exported now, with different settings, refactor to just export a single function that take a struct with different settings. This will make it easier to add more parameters. Reviewed-by:
-
Johannes Berg authored
Add cfg80211_get_6ghz_power_type() to parse the 6 GHz power type from a given set of elements, which is now only inside cfg80211_6ghz_power_type_valid(). Reviewed-by:
-
Johannes Berg authored
To later introduce an override for VLP APs being allowed despite NO-IR flags, which is somewhat similar in construction to being allowed to monitor on disabled channels, refactor the code that checks channel flags to have not a 'monitor' argument but a set of 'permitting' flags that permit the operation without checking for 'prohibited' flags. Reviewed-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Johannes Berg authored
This really shouldn't have been in ieee80211.h, since it doesn't directly represent the spec. Move it to cfg80211 rather than mac80211 since upcoming changes will use it there. Reviewed-by:
-
Johannes Berg authored
This has never been used, and it's really not directly representing the spec, so shouldn't have been here in the first place. Remove it. Reviewed-by:
-
Johannes Berg authored
Use BIT(x) instead of 1<<x, in part because it's mostly missing spaces anyway, in part because it reads nicer. Reviewed-by:
-
Johannes Berg authored
It may be possible to monitor on disabled channels per the can-monitor flag, but evidently I forgot to expose that out to userspace. Fix that. Fixes: a110a3b7 ("wifi: cfg80211: optionally support monitor on disabled channels") Reviewed-by:
-
Baochen Qiang authored
Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. Fixes: c4cbaf79 ("cfg80211: Add support for HE") Signed-off-by:
Baochen Qiang <quic_bqiang@quicinc.com> Link: https://msgid.link/20240606020653.33205-3-quic_bqiang@quicinc.comSigned-off-by:
-
Baochen Qiang authored
rates_996 is mistakenly written as rates_969, fix it. Fixes: c4cbaf79 ("cfg80211: Add support for HE") Signed-off-by:
-
Breno Leitao authored
Commit 3e2f544d ("net: get stats64 if device if driver is configured") moved the callback to dev_get_tstats64() to net core, so, unless the driver is doing some custom stats collection, it does not need to set .ndo_get_stats64. Since this driver is now relying in NETDEV_PCPU_STAT_TSTATS, then, it doesn't need to set the dev_get_tstats64() generic .ndo_get_stats64 function pointer. In this driver specifically, .ndo_get_stats64 basically points to dev_fetch_sw_netstats(). Now it will point to dev_get_tstats64(), which calls netdev_stats_to_stats64() and dev_fetch_sw_netstats(). netdev_stats_to_stats64() seems irrelevant for this driver. Signed-off-by:
Breno Leitao <leitao@debian.org> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://msgid.link/20240607102045.235071-2-leitao@debian.orgSigned-off-by:
-
