- 07 Mar, 2023 8 commits
-
-
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:
Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230301115906.98d4761b809b.I255f5ecd77cb24fcf2f1641bb5833ea2d121296e@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
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:
Ilan Peer <ilan.peer@intel.com> 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 13 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:
-
Zong-Zhe Yang authored
RTL8852B firmware supports CRASH_TRIGGER feature from v0.29.29.0. After this is configured, debugfs fw_crash can support type 1 on RTL8852B to trigger firmware crash and verify L2 recovery through simulation. Signed-off-by:
-
Chin-Yen Lee authored
8852B has the same issue: management frames get stuck when wifi chip enters low ps mode, so we alse add notify wake function to trigger wifi chip wake before forwarding management frames. Signed-off-by:
Chin-Yen Lee <timlee@realtek.com> Signed-off-by:
-
Martin Blumenstingl authored
The efuse of the SDIO RTL8822CS chip has only one known member: the mac address is at offset 0x16a. Add a struct rtw8822cs_efuse describing this and use it for copying the mac address when the SDIO bus is used. Signed-off-by:
-
Martin Blumenstingl authored
The efuse of the SDIO RTL8822BS chip has only one known member: the mac address is at offset 0x11a. Add a struct rtw8822bs_efuse describing this and use it for copying the mac address when the SDIO bus is used. Signed-off-by:
-
Martin Blumenstingl authored
The efuse of the SDIO RTL8821CS chip has only one known member: the mac address is at offset 0x11a. Add a struct rtw8821cs_efuse describing this and use it for copying the mac address when the SDIO bus is used. Signed-off-by:
-
Martin Blumenstingl authored
txdma_queue_mapping() and priority_queue_cfg() can use the first entry of each chip's rqpn_table and page_table. Add this mapping so data transmission is possible on SDIO based chipsets. Signed-off-by:
-
Martin Blumenstingl authored
rtw_pwr_seq_parser() needs to know about the HCI bus interface mask for the SDIO bus so it can parse the chip state change sequences. Signed-off-by:
-
Bitterblue Smith authored
Fix a new smatch warning: drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:1580 rtl8xxxu_print_chipinfo() warn: always true condition '(priv->chip_cut <= 15) => (0-15 <= 15)' Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202302140753.71IgU77A-lkp@intel.com/ Fixes: 7b0ac469 ("wifi: rtl8xxxu: Recognise all possible chip cuts") Signed-off-by:
Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by:
-
Po-Hao Huang authored
Since 6 GHz band has around 60 channels and more strict rules for active probing. Reduced neighbor report can be used to reduce the channels we scan and get specific target BSS info to probe for. Declare flag WIPHY_FLAG_SPLIT_SCAN_6GHZ so the scan request could be divided into two portions: legacy bands and 6 GHz bands. So RNR information from legacy bands could later be used when 6 GHz scan. When the scan flag NL80211_SCAN_FLAG_COLOCATED_6GHZ is set, cfg80211 will pass down a reduced channel set which contains PSCs and non-PSC with RNR info received in the 2 GHz/5 GHz band. This reduces the scan duration by allowing us to only scan for channels in which APs are currently operating. Signed-off-by:
-
