- 07 Mar, 2023 29 commits
-
-
Mukesh Sisodiya authored
Add missing RF name extraction for MsP device from hardware rf-id. Signed-off-by:
Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230305124406.ae831f21ec55.Iad71cc30f9930f7ebe079d210ebe6c968a159273@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Mordechay Goodstein authored
Although no data is presented in the skb, but upper layers need it for calculating where radio tap header are done, so we mark it. Signed-off-by:
Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by:
-
Mordechay Goodstein authored
Nothing change with LSIG in EHT so just extend the switch case to include EHT standard. Signed-off-by:
-
Jacob Keller authored
The cfg80211_scan_request structure is followed by a flexible array member as well as several other arrays that are then stored into pointers in the structure. These are allocated currently using a simple sequence of multiplications. Replace the calculations with struct_size(), size_add(), and array_size() helper macros. These macros saturate the calculation at SIZE_MAX rather than overflowing. Note that we can't use flex_array_size() instead of array_size() because the fields are not arrays, but simple pointers. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20230228162827.3876606-3-jacob.e.keller@intel.comSigned-off-by:
-
Veerendranath Jakkam authored
Add support to use a random local address in authentication and deauthentication frames sent to unassociated peer when the driver supports. The driver needs to configure receive behavior to accept frames with random transmit address specified in TX path authentication frames during the time of the frame exchange is pending and such frames need to be acknowledged similarly to frames sent to the local permanent address when this random address functionality is used. This capability allows use of randomized transmit address for PASN authentication frames to improve privacy of WLAN clients. Signed-off-by:
Veerendranath Jakkam <quic_vjakkam@quicinc.com> Link: https://lore.kernel.org/r/20230112012415.167556-2-quic_vjakkam@quicinc.comSigned-off-by:
-
Ryder Lee authored
This is utilized to pass LDPC configurations from user space (i.e. hostapd) to driver. Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Link: https://lore.kernel.org/r/1de696aaa34efd77a926eb657b8c0fda05aaa177.1676628065.git.ryder.lee@mediatek.comSigned-off-by:
-
Ryder Lee authored
Similar to VHT/HE. This is utilized to pass MU-MIMO configurations from user space (i.e. hostapd) to driver. Signed-off-by:
-
Ryder Lee authored
This allows low level drivers to refresh the tx agg session timer, based on querying stats from the firmware usually. Especially for some mt76 devices support .net_fill_forward_path would bypass mac80211, which leads to tx BA session timeout clients that set a timeout in their AddBA response to our request, even if our request is without a timeout. Signed-off-by:
-
Mordechay Goodstein authored
The new TLV format enables adding TLVs after the fixed fields in radiotap, as part of the radiotap header. Support this and move vendor data to the TLV format, allowing a reuse of the RX_FLAG_RADIOTAP_VENDOR_DATA as the new RX_FLAG_RADIOTAP_TLV_AT_END flag. Signed-off-by:
-
Mordechay Goodstein authored
This is based on https://www.radiotap.org/fields/EHT.html and https://www.radiotap.org/fields/U-SIG.html new EHT TLV definition for 11be standard. Signed-off-by:
-
Johannes Berg authored
The return type here should be u64 for the flags, even if it doesn't matter right now because it doesn't return any flags that don't fit into u32. Signed-off-by:
-
Johannes Berg authored
Given the code in cfg80211, EHT capa cannot be non-NULL when HE capa is NULL, but it's easier to reason about it if both are checked and the compiler will likely integrate the check with the previous one for HE capa anyway. Signed-off-by:
-
Johannes Berg authored
We already exited the function if sta ended up NULL, so just remove the extra check. Signed-off-by:
-
Ilan Peer authored
mac80211_hwsim always uses the probe request coming from mac80211, which has support for minimal probe request content. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Benjamin Berg authored
This adds the infrastructure to have netdev specific per-link data both for mac80211 and the driver in debugfs. For the driver, a new callback is added which is only used if MLO is supported. Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Signed-off-by:
-
Benjamin Berg authored
The spatial multiplexing power save feature does not apply to AP mode. Remove it from debugfs in this case. Signed-off-by:
-
Benjamin Berg authored
While often not needed, this considerably simplifies going from a link specific bss_config to the vif. This helps with e.g. creating link specific debugfs entries inside drivers. Signed-off-by:
-
Johannes Berg authored
We should perhaps support this API for MLO, but it's not clear that it makes sense, in any case then we'd have to update it to probe the correct BSS. For now, if it happens, warn only once so that we don't get flooded with messages if the driver misbehaves and calls this. Signed-off-by:
-
Johannes Berg authored
For control port RX, report the link ID for MLO. Signed-off-by:
-
Avraham Stern authored
Support the set_hw_timestamp callback for enabling and disabling HW timestamping if the low level driver supports it. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
Avraham Stern authored
Add a command to enable and disable HW timestamping of TM and FTM frames. HW timestamping can be enabled for a specific mac address or for all addresses. The low level driver will indicate how many peers HW timestamping can be enabled concurrently, and this information will be passed to userspace. Signed-off-by:
-
Mordechay Goodstein authored
In the past ftype was used for deciding about 6G DUP beacon, but the logic was removed and ftype is not needed anymore. Signed-off-by:
-
Mordechay Goodstein authored
The check that beacon primary channel is in the range of 80 MHz (abs < 80) is invalid for 320 MHz since duplicate beacon transmit means that the AP transmits it on all the 20 MHz sub-channels: 9.4.2.249 HE Operation element - ... AP transmits Beacon frames in non-HT duplicate PPDU with a TXVECTOR parameter CH_BANDWIDTH value that is up to the BSS bandwidth. So in case of 320 MHz the DUP beacon can be in upper 160 for primary channel in the lower 160 giving possibly an absolute range of over 80 MHz. Also this check is redundant alltogether, if AP has a wrong primary channel in the beacon it's a faulty AP, and we would fail in next steps to connect. While at it, fix the frequency comparison to no longer compare between KHz and MHz, which was introduced by commit 7f599aec ("cfg80211: Use the HE operation IE to determine a 6GHz BSS channel"). Signed-off-by:
-
Mordechay Goodstein authored
Currently in case DUP bit is not set we don't return the primary channel for 6 GHz Band, but the spec says that the DUP bit has no effect on this field: 9.4.2.249 HE Operation element: The Duplicate Beacon subfield is set to 1 if the AP transmits Beacon frames in non-HT duplicate PPDU with a TXVECTOR parameter CH_BANDWIDTH value that is up to the BSS bandwidth and is set to 0 otherwise. So remove the condition for returning primary channel based on DUP. Since the caller code already marks the signal as invalid in case the indicated frequency is not the tuned frequency, there's no need to additionally handle this case here since that's already true for duplicated beacons on the non-primary channel(s). Signed-off-by:
-
Johannes Berg authored
In case of beacon protection, check if the key was offloaded to the hardware and in that case set control.hw_key so that the encryption function will see it and only do the needed steps that aren't done in hardware. Signed-off-by:
-
Johannes Berg authored
This will likely never happen, but for completeness check the key taint flag before using a key for beacon protection. Signed-off-by:
-
Mordechay Goodstein authored
Since we remove radiotap from skb data, clear all RX_FLAG_X related info that indicate info on the skb data. Also we need to do it only once so remove the clear from cooked_monitor. Signed-off-by:
-
Johannes Berg authored
Instead of the comment about holding RTNL, which is now wrong, add a proper lockdep assertion for the wiphy mutex. Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver") Signed-off-by:
-
Ilan Peer authored
Add a detailed description of NL80211_SCAN_FLAG_COLOCATED_6GHZ flag. Signed-off-by:
-
- 06 Mar, 2023 5 commits
-
-
Jiapeng Chong authored
Variables bcntime_cfg, bcn_cw and bcn_ifs are not effectively used, so delete them. drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:1555:6: warning: variable 'bcntime_cfg' set but not used. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4240Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Acked-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230302023911.59278-1-jiapeng.chong@linux.alibaba.com
-
Martin Blumenstingl authored
rtw_mac_power_switch() calls rtw_pwr_seq_parser() which can return -EINVAL, -EBUSY or 0. Propagate the original error code instead of unconditionally returning -EINVAL in case of an error. Fixes: e3037485 ("rtw88: new Realtek 802.11ac driver") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
-
Martin Blumenstingl authored
rtw_pwr_seq_parser() calls rtw_sub_pwr_seq_parser() which can either return -EBUSY, -EINVAL or 0. Propagate the original error code instead of unconditionally returning -EBUSY in case of an error. Fixes: e3037485 ("rtw88: new Realtek 802.11ac driver") Signed-off-by:
-
Konrad Dybcio authored
Some phones from around 2016, as well as other random devices have this chip called 43956 or 4359C0 or 43596A0, which is more or less just a rev bump (v9) of the already-supported 4359. Add a corresponding firmware definition to allow for choosing the correct blob. Suggested-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
-
Chih-Kang Chang authored
When SER L1 triggered, driver need to stop Rx and clear RTW89_FLAG_RUNNING flag. If track_work check RTW89_FLAG_RUNNING simultaneously, it will check failed and never queue track_work again, and LPS won't enter either. Therefore, we cancel delayed work when enter SER L1, and queue delayed work when leave SER L1. Signed-off-by:
Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by:
-
- 27 Feb, 2023 6 commits
-
-
Hector Martin authored
BCM4378B3 is a new silicon revision of BCM4378 present on the Apple M2 13" MacBook Pro "kyushu". Its PCI revision number is 5. Signed-off-by:
Hector Martin <marcan@marcan.st> Reviewed-by:
Julian Calaby <julian.calaby@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Hector Martin authored
The calibration blob for a chip is normally stored in SROM and loaded internally by the firmware. However, Apple ARM64 platforms instead store it as part of platform configuration data, and provide it via the Apple Device Tree. We forward this into the Linux DT in the bootloader. Add support for taking this blob from the DT and loading it into the dongle. The loading mechanism is the same as used for the CLM and TxCap blobs. Reviewed-by:
-
Hector Martin authored
These blobs are named .txcap_blob, and exist alongside the existing .clm_blob files. Use the existing firmware machinery to provide them to the core. Reviewed-by:
-
Hector Martin authored
The TxCap blobs are additional data blobs used on Apple devices, and are uploaded analogously to CLM blobs. Add core support for doing this. Acked-by:
-
Hector Martin authored
This chip is present on Apple M1 Pro/Max (t600x) platforms: * maldives (apple,j314s): MacBook Pro (14-inch, M1 Pro, 2021) * maldives (apple,j314c): MacBook Pro (14-inch, M1 Max, 2021) * madagascar (apple,j316s): MacBook Pro (16-inch, M1 Pro, 2021) * madagascar (apple,j316c): MacBook Pro (16-inch, M1 Max, 2021) Reviewed-by:
-
Hector Martin authored
Apparently the hex passphrase mechanism does not work on newer chips/firmware (e.g. BCM4387). It seems there was a simple way of passing it in binary all along, so use that and avoid the hexification. OpenBSD has been doing it like this from the beginning, so this should work on all chips. Also clear the structure before setting the PMK. This was leaking uninitialized stack contents to the device. Reviewed-by:
-
