- 13 Feb, 2023 40 commits
-
-
Ping-Ke Shih authored
New firmware type NORMAL_CE is introduced to support P2P-PS and hardware scan, but no LPS-PG mode. After this patch, old firmware with NORMAL type can still work well. The use of this new type is the same as before, so we add new type to avoid taking wrong firmware. Then, driver log can also give clear information about this change: rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 5 rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 3 Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230123065401.14174-7-pkshih@realtek.com
-
Ping-Ke Shih authored
Due to firmware size limit of 8852b, LPS-PG mode isn't supported after 0.29.26.0, and then we have more space to support other features, such as P2P-PS, hardware scan and so on. Signed-off-by:
-
Ping-Ke Shih authored
For different firmware type, it could use different IDMEM mode, so reset it to default to avoid encountering error during we bisect firmware version, like rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 5 rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 3 rtw89_8852be 0000:03:00.0: fw security fail rtw89_8852be 0000:03:00.0: download firmware fail rtw89_8852be 0000:03:00.0: [ERR]fwdl 0x1E0 = 0x62 rtw89_8852be 0000:03:00.0: [ERR]fwdl 0x83F2 = 0x8 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931154 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931154 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931150 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931154 Signed-off-by:
-
Ping-Ke Shih authored
Driver can prepare pkt_list for firmware that only uses them to send out the packets in specific situations. To understand the usage of current status, and to check if there is leakage problem, dump bitmap and the indices used by certain function. An example looks like: map: ... pkt_ofld: 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... [SCAN 0]: 3 [SCAN 1]: 4 [SCAN 3]: 5 VIF [0] xx:xx:xx:xx:xx:xx ... pkt_ofld[GENERAL]: 0 1 2 Signed-off-by: -
Chin-Yen Lee authored
For upcoming firmware, driver needs to do packet offload to firmware to ensure LPS protocol work properly, so we update current connection and disconnect flow to maintain packet offload flow, and integrate with current WoWLAN flow which also needs packet offload. Signed-off-by:
Chin-Yen Lee <timlee@realtek.com> Signed-off-by:
-
Chin-Yen Lee authored
When driver fails to send H2C to firmware for pkt-offload, we should not update the pkt_list of driver, and need to release allocated pkt index to avoid wrong mapping between driver and firmware. Signed-off-by:
-
Kuan-Chung Chen authored
Buffer STA on TDLS links are not currently supported. Therefore, it is not allowed to enter the PS mode after TDLS link is established. Signed-off-by:
Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
To debug channel concurrency more centrally, we add a new debug flag, RTW89_DBG_CHAN, for channel related things, especially channel concurrency. Then, we change MCC (multi-channel concurrency) C2H (chip to host packets) debug flag to it. Besides, refine debug logs to show TSF in u64 directly. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
A 8-byte offset is missed during parsing C2Hs (chip to host packets) of MCC (multi-channel concurrent) series. So, we fix it. Fixes: ef9dff4c ("wifi: rtw89: mac: process MCC related C2H") Signed-off-by:
-
Zong-Zhe Yang authored
RXI300 is a HW design to maintain stuffs across BUS, e.g. AXI, AHB, APB. It will feedback an error when host does an invalid BUS operation. For example, * BUS master request without power/clock on. * host reads/writes/accesses an invalid address. They might lead to problems such as BUS timeout, platform hang, etc. So, once if RXI300 feedback an error, it notifies that driver need a L2 SER (system error recovery) to reset things. Previously, driver did not parse the error scenario for RXI300. We add it and assign a corresponding error code which will make SER flow do L2 reset. Signed-off-by:
-
Zong-Zhe Yang authored
Only 8852C chip has valid pages on RTW89_DBG_SEL_MAC_30. To other chips, this section is an address hole. It will lead to crash if trying to access this section on chips except for 8852C. So, we avoid that. Signed-off-by:
-
Zong-Zhe Yang authored
Add mac function rtw89_mac_port_get_tsf() to get TSF by port. It will be used when MCC (multi-channel concurrency) calculates timing things. Signed-off-by:
-
Zong-Zhe Yang authored
Originally, rtw89_mac_port_tsf_sync() contains randomization logic internally. However, not all situation, we need the randomization. So, split out the generic part from it. And, make the full logic of original one contained in rtw89_mac_port_tsf_sync_rand(). It will still be used by its original caller as before. Then, the generic one will be used in MCC (multi-channel concurrency) management flow. MCC will implement its logic to decide the offset for TSF sync. Signed-off-by:
-
Zong-Zhe Yang authored
Strictly speaking, the unit of the offset should be TU instead of ms. So, correct it and the macro for calculation. Then, to make the macro generic, the factor n is moved outside. Signed-off-by:
-
Ching-Te Ku authored
Should update the driver with the supported firmware version of the below item. Bluetooth firmware BT_Coex_Ver: 0x07 Wi-Fi firmware version: RTL8852C->v0.27.56.10, RTL8852A->v0.24.36 Signed-off-by:
Ching-Te Ku <ku920601@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
The origin code will enable TDMA WL:BT = 50:50 to prevent Wi-Fi throughput suddenly drop to 0 in the moment while A2DP pause. And this protection just a short moment, and will turn to Bluetooth idle case when A2DP turn into sniff mode. But the raspberryPI simulated A2DP device will not turn into sniff mode. So the protection will bring the throughput drop. Signed-off-by:
-
Ching-Te Ku authored
When Wi-Fi enter and leave LPS, coexistence driver need to know is there A2DP exist or not. And when Wi-Fi sleep in deep power save state will not able to receive mailbox sent from Bluetooth. So update the A2DP exist information from reading register. Signed-off-by:
-
Ching-Te Ku authored
When Wi-Fi is RX, set Bluetooth background scan to low-priority and not to break Wi-Fi packet. Bluetooth can RX depend on hardware ability even RX request has been rejected. This way can improve Wi-Fi RX throughput performance. Signed-off-by:
-
Ching-Te Ku authored
Adjust the log format and correct variable reference to make the log more readable. Signed-off-by:
-
Ching-Te Ku authored
Force firmware to update TDMA parameter when enter/exit power saving. The TDMA instant feature will make firmware force update TDMA parameter immediately when the TDMA parameter H2C to firmware. Without this feature, it will have a low fail rate trigger Bluetooth audio sound glitch when Wi-Fi is under power saving. Or Wi-Fi fail to turn in to power save state. Signed-off-by:
-
Ching-Te Ku authored
Reset the counter no matter Wi-Fi is notified turning into power save or not. With rest the counter coexistence will recognize Bluetooth is hanged easily. Signed-off-by:
-
Ching-Te Ku authored
This patch update the external control (Wi-Fi firmware control) type of TDMA related parameters, almost all of these case were related to Wi-Fi multi-role situations & AP mode. Signed-off-by:
-
Arend van Spriel authored
The function cfg80211_set_channel() is an static function in brcmfmac but the name is misleading. Hence rename it with 'brcmf' prefix. Also changing the parameters to avoid additional conversions. Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Dan Carpenter authored
This code re-uses "i" to be the iterator for both the inside and outside loops. It means the outside loop will exit earlier than intended. Fixes: d219b7eb ("mwifiex: handle BT coex event to adjust Rx BA window size") Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Gustavo A. R. Silva authored
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct mwifiex_ie_types_rates_param_set. These are the only binary differences I see after the change: mwifiex.o _@@ -50154,7 +50154,7 @@ 23514: R_X86_64_32S kmalloc_caches+0x50 23518: call 2351d <mwifiex_scan_networks+0x11d> 23519: R_X86_64_PLT32 __tsan_read8-0x4 - 2351d: mov $0x225,%edx + 2351d: mov $0x224,%edx 23522: mov $0xdc0,%esi 23527: mov 0x0(%rip),%rdi # 2352e <mwifiex_scan_networks+0x12e> 2352a: R_X86_64_PC32 kmalloc_caches+0x4c scan.o _@@ -5582,7 +5582,7 @@ 4394: R_X86_64_32S kmalloc_caches+0x50 4398: call 439d <mwifiex_scan_networks+0x11d> 4399: R_X86_64_PLT32 __tsan_read8-0x4 - 439d: mov $0x225,%edx + 439d: mov $0x224,%edx 43a2: mov $0xdc0,%esi 43a7: mov 0x0(%rip),%rdi # 43ae <mwifiex_scan_networks+0x12e> 43aa: R_X86_64_PC32 kmalloc_caches+0x4c and the reason for that is the following line: drivers/net/wireless/marvell/mwifiex/scan.c: 1517 scan_cfg_out = kzalloc(sizeof(union mwifiex_scan_cmd_config_tlv), 1518 GFP_KERNEL); sizeof(union mwifiex_scan_cmd_config_tlv) is now one-byte smaller due to the flex-array transformation: 46 union mwifiex_scan_cmd_config_tlv { 47 /* Scan configuration (variable length) */ 48 struct mwifiex_scan_cmd_config config; 49 /* Max allocated block */ 50 u8 config_alloc_buf[MAX_SCAN_CFG_ALLOC]; 51 }; Notice that MAX_SCAN_CFG_ALLOC is defined in terms of sizeof(struct mwifiex_ie_types_rates_param_set), see: 26 /* Memory needed to store supported rate */ 27 #define RATE_TLV_MAX_SIZE (sizeof(struct mwifiex_ie_types_rates_param_set) \ 28 + HOSTCMD_SUPPORTED_RATES) 37 /* Maximum memory needed for a mwifiex_scan_cmd_config with all TLVs at max */ 38 #define MAX_SCAN_CFG_ALLOC (sizeof(struct mwifiex_scan_cmd_config) \ 39 + sizeof(struct mwifiex_ie_types_num_probes) \ 40 + sizeof(struct mwifiex_ie_types_htcap) \ 41 + CHAN_TLV_MAX_SIZE \ 42 + RATE_TLV_MAX_SIZE \ 43 + WILDCARD_SSID_TLV_MAX_SIZE) This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/252 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Gustavo A. R. Silva authored
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element arrays with flexible-array members in multiple structures. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. This results in no differences in binary output. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/256 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by:
-
Gustavo A. R. Silva authored
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct brcmf_tlv. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. This results in no differences in binary output. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/253 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by:
-
Lukas Wunner authored
Support the firmware hotfix version in GET_HW_SPEC responses to avoid an irritating "Unknown api_id: 5" message on probe. Based on this commit in NXP's GPLv2-licensed out-of-tree driver: https://github.com/nxp-imx/mwifiex/commit/27fd8ecca504Signed-off-by:
Lukas Wunner <lukas@wunner.de> Cc: Sherry Sun <sherry.sun@nxp.com> Signed-off-by:
-
Lukas Wunner authored
The Marvell SD8978 (aka NXP IW416) uses identical registers as SD8987, so reuse the existing mwifiex_reg_sd8987 definition. Note that mwifiex_reg_sd8977 and mwifiex_reg_sd8997 are likewise identical, save for the fw_dump_ctrl register: They define it as 0xf0 whereas mwifiex_reg_sd8987 defines it as 0xf9. I've verified that 0xf9 is the correct value on SD8978. NXP's out-of-tree driver uses 0xf9 for all of them, so there's a chance that 0xf0 is not correct in the mwifiex_reg_sd8977 and mwifiex_reg_sd8997 definitions. I cannot test that for lack of hardware, hence am leaving it as is. NXP has only released a firmware which runs Bluetooth over UART. Perhaps Bluetooth over SDIO is unsupported by this chipset. Consequently, only an "sdiouart" firmware image is referenced, not an alternative "sdsd" image. Signed-off-by:
-
Lukas Wunner authored
Commit e3fffc1f ("devicetree: document new marvell-8xxx and pwrseq-sd8787 options") documented a compatible string for SD8787 in the devicetree bindings, but neglected to add it to the mwifiex driver. Fixes: e3fffc1f ("devicetree: document new marvell-8xxx and pwrseq-sd8787 options") Signed-off-by:
-
Hector Martin authored
This chip exists in two revisions (B2=r3 and B3=r4) on different platforms, and was added without regard to doing proper firmware selection or differentiating between them. Fix this to have proper per-revision firmwares and support Apple NVRAM selection. Revision B2 is present on at least these Apple T2 Macs: kauai: MacBook Pro 15" (Touch/2018-2019) maui: MacBook Pro 13" (Touch/2018-2019) lanai: Mac mini (Late 2018) ekans: iMac Pro 27" (5K, Late 2017) And these non-T2 Macs: nihau: iMac 27" (5K, 2019) Revision B3 is present on at least these Apple T2 Macs: bali: MacBook Pro 16" (2019) trinidad: MacBook Pro 13" (2020, 4 TB3) borneo: MacBook Pro 16" (2019, 5600M) kahana: Mac Pro (2019) kahana: Mac Pro (2019, Rack) hanauma: iMac 27" (5K, 2020) kure: iMac 27" (5K, 2020, 5700/XT) Also fix the firmware interface for 4364, from BCA to WCC. Fixes: 24f0bd13 ("brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2") Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Hector Martin <marcan@marcan.st> Signed-off-by:
-
Hector Martin authored
This chip is present on at least these Apple T2 Macs: * tahiti: MacBook Pro 13" (2020, 2 TB3) * formosa: MacBook Pro 13" (Touch/2019) * fiji: MacBook Air 13" (Scissor, 2020) Reviewed-by:
-
Hector Martin authored
This chip is present on at least these Apple T2 Macs: * hawaii: MacBook Air 13" (Late 2018) * hawaii: MacBook Air 13" (True Tone, 2019) Users report seeing PCI revision ID 12 for this chip, which Arend reports should be revision C2, but Apple has the firmware tagged as revision C1. Assume the right cutoff point for firmware versions is revision ID 11 then, and leave older revisions using the non-versioned firmware filename (Apple only uses C1 firmware builds). Reviewed-by:
-
Hector Martin authored
The commit that introduced support for this chip incorrectly claimed it is a Cypress-specific part, while in actuality it is just a variant of BCM4355 silicon (as evidenced by the chip ID). The relationship between Cypress products and Broadcom products isn't entirely clear but given what little information is available and prior art in the driver, it seems the convention should be that originally Broadcom parts should retain the Broadcom name. Thus, rename the relevant constants and firmware file. Also rename the specific 89459 PCIe ID to BCM43596, which seems to be the original subvariant name for this PCI ID (as defined in the out-of-tree bcmdhd driver). Since Cypress added this part and will presumably be providing its supported firmware, we keep the CYW designation for this device. We also drop the RAW device ID in this commit. We don't do this for the other chips since apparently some devices with them exist in the wild, but there is already a 4355 entry with the Broadcom subvendor and WCC firmware vendor, so adding a generic fallback to Cypress seems redundant (no reason why a device would have the raw device ID *and* an explicitly programmed subvendor). Fixes: dce45ded ("brcmfmac: Support 89459 pcie") Reviewed-by:
-
Krzysztof Kozlowski authored
Minor cleanups: - Drop redundant blank lines, - Correct indentaion in examples, - Correct node names in examples to drop underscore and use generic name. No functional impact except adjusting to preferred coding style. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Jiasheng Jiang authored
Add the check for the return value of the create_singlethread_workqueue() in order to avoid NULL pointer dereference. Fixes: b481de9c ("[IWLWIFI]: add iwlwifi wireless drivers") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Acked-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
-
Jiasheng Jiang authored
Add the check for the return value of the create_singlethread_workqueue in order to avoid NULL pointer dereference. Fixes: b481de9c ("[IWLWIFI]: add iwlwifi wireless drivers") Signed-off-by:
-
Martin Blumenstingl authored
Replace the magic numbers for the intf_mask with their existing RTW_PWR_INTF_PCI_MSK and RTW_PWR_INTF_USB_MSK macros to make the code easier to understand. Acked-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Martin Blumenstingl authored
This code is not specific to the PCIe bus type but can be re-used by USB and SDIO bus types. Move it to tx.{c,h} to avoid code-duplication in the future. While here, add checking of the ac argument in rtw_tx_ac_to_hwq() so we're not accessing entries beyond the end of the array. Signed-off-by: -
Martin Blumenstingl authored
This makes it easier to understand which values are allowed for the "queue" variable when using the enum instead of an u8. Acked-by:
-
