- 07 Mar, 2023 17 commits
-
-
Johannes Berg authored
We already exited the function if sta ended up NULL, so just remove the extra check. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230301115906.4cbac9cfd03a.I21ec81c96d246afdabc2b0807d3856e6b1182cb7@changeidSigned-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 <mordechay.goodstein@intel.com> 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 14 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:
-
Hector Martin authored
Add support for the new PMKID_V3 API, which allows performing PMKID mutations individually, instead of requiring the driver to keep track of the full list. This new API is required by at least BCM4387. Note that PMKID_V2 is not implemented yet. Reviewed-by:
-
Hector Martin authored
The "wlc_ver" iovar returns information on the WLC and EPI versions. This can be used to determine whether the PMKID_V2 and _V3 features are supported. Reviewed-by:
-
Hector Martin authored
This new API version is required for at least the BCM4387 firmware. Add support for it, with a fallback to the v1 API. Acked-by:
-
Hector Martin authored
BCM4387 has trailing odd-sized blocks as part of TCM which have their size described as a multiple of 1024 instead of 8192. Handle this so we can compute the TCM size properly. Reviewed-by:
-
Hector Martin authored
At least on BCM4387, the D11 cores are held in reset on cold startup and firmware expects to release reset itself. Just assert reset here and let firmware deassert it. Premature deassertion results in the firmware failing to initialize properly some of the time, with strange AXI bus errors. Also, BCM4387 has 3 cores, up from 2. The logic for handling that is in brcmf_chip_ai_resetcore(), but since we aren't using that any more, just handle it here. Reviewed-by:
-
John Keeping authored
Using the BCM4339 firmware from linux-firmware (version "BCM4339/2 wl0: Sep 5 2019 11:05:52 version 6.37.39.113 (r722271 CY)" from cypress/cyfmac4339-sdio.bin) the RSSI respose is only 4 bytes, which results in an error being logged. It seems that older devices send only the RSSI field and neither SNR nor noise is included. Handle this by accepting a 4 byte message and reading only the RSSI from it. Fixes: 7dd56ea4 ("brcmfmac: add support for CQM RSSI notifications") Signed-off-by:
John Keeping <john@metanate.com> Signed-off-by:
-
Hector Martin authored
Newer Apple firmwares on chipsets without a hardware RNG require the host to provide a buffer of 256 random bytes to the device on initialization. This buffer is present immediately before NVRAM, suffixed by a footer containing a magic number and the buffer length. This won't affect chips/firmwares that do not use this feature, so do it unconditionally for all Apple platforms (those with an Apple OTP). Reviewed-by:
-
Hector Martin authored
On DT platforms, the module-instance and antenna-sku-info properties are passed in the DT. On ACPI platforms, module-instance is passed via the analogous Apple device property mechanism, while the antenna SKU info is instead obtained via an ACPI method that grabs it from non-volatile storage. Add support for this, to allow proper firmware selection on Apple platforms. Signed-off-by:
-
- 22 Feb, 2023 4 commits
-
-
Zong-Zhe Yang authored
The newer chips use the newer firmware branches, e.g. v027, v029. And, those firmware branches are supposed to support packet drop when they are just branched out. The initial firmware branch used by each chip is as below. * 8852A: v009 * 8852C: v027 * 8852B: v027 So, only 8852A may use firmware which doesn't support packet drop at runtime. To save trivial positive listing in firmware feature table, we change to reverse judgment. Besides, rtw89_mac_ptk_drop_by_band_and_wait() missed to check firmware feature before calling rtw89_fw_h2c_pkt_drop(). We also fix it. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
This enables hw_scan for 8852b after firmware version 0.29.29.0. Signed-off-by:
-
Po-Hao Huang authored
To obtain correct packet frequency for hw_scan, 52b needs to decode the channel index obtained from hardware. Change the driver related set channel part as well to make driver/firmware compatible. Signed-off-by:
Po-Hao Huang <phhuang@realtek.com> Signed-off-by:
-
Po-Hao Huang authored
Since the range of channel table is identical among ICs. Make channel encode/decode function common and not IC dependent. So all ICs with matching firmware that needs this kind of coding can use it directly. This patch doesn't change logic at all. Signed-off-by:
-
