- 13 Feb, 2023 29 commits
-
-
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 <ku920601@realtek.com> Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230117114109.4298-4-pkshih@realtek.com
-
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:
-
Martin Blumenstingl authored
rtw_hw_queue_mapping() and ac_to_hwq[] hold values of type enum rtw_tx_queue_type. Change their types to reflect this to make it easier to understand this part of the code. While here, also change the array to be static const as it is not supposed to be modified at runtime. Signed-off-by:
-
Jonathan Neuschäfer authored
It should be "broadcast". Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
-
Doug Brown authored
Add compatibility with WPS by passing on WPS enrollee information in probe requests. Ignore other IEs supplied in the scan request. This also has the added benefit of restoring compatibility with newer wpa_supplicant versions that always add scan IEs. Previously, with max_scan_ie_len set to 0, scans would always fail. Suggested-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
Doug Brown <doug@schmorgal.com> Reviewed-by:
-
Doug Brown authored
Add a define for the TLV type that will be used to add WPS enrollee information to probe requests. Suggested-by:
-
Doug Brown authored
The existing code only converts the first IE to a TLV, but it returns a value that takes the length of all IEs into account. When there is more than one IE (which happens with modern wpa_supplicant versions for example), the returned length is too long and extra junk TLVs get sent to the firmware, resulting in an association failure. Fix this by finding the first RSN or WPA IE and only adding that. This has the extra benefit of working properly if the RSN/WPA IE isn't the first one in the IE buffer. While we're at it, clean up the code to use the available structs like the other lbs_add_* functions instead of directly manipulating the TLV buffer. Signed-off-by:
-
Doug Brown authored
Several of the structs are using the deprecated convention of items[1] for a dynamically sized trailing element. Convert these structs to the modern C99 style of items[]. Also fix a couple of camel case struct element names. Signed-off-by:
-
https://github.com/nbd168/wirelessKalle Valo authored
mt76 patches for 6.3 - fixes - mt7996 cleanups - switch to page pool allocator - mt7996 eht support - WED reset support
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2023-01-30' of http://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next iwlwifi updates towards v6.3, this patch-set contains: * EHT rate reporting * Sniffer support for EHT and a few fixes in the related code * A few general cleanups and small bugfixes * Bump FW API to 74 for AX devices * Fix a compilation error in mei (it still depends on BROKEN) * STEP equalizer support - transfer some Phy related parameters from the BIOS to the firmware
-
- 11 Feb, 2023 11 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-02-09 (i40e) Jan removes i40e_status from the driver; replacing them with standard kernel error codes. Kees Cook replaces 0-length array with flexible array. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: net/i40e: Replace 0-length array with flexible array i40e: use ERR_PTR error print in i40e messages i40e: use int for i40e_status i40e: Remove string printing for i40e_status i40e: Remove unused i40e status codes ==================== Link: https://lore.kernel.org/r/20230209172536.3595838-1-anthony.l.nguyen@intel.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Alexandra Winter says: ==================== s390/net: updates 2023-02-06 Just maintenance patches, no functional changes. If you disagree with patch 4, we can leave it out. We prefer scnprintf, but no strong opinion. ==================== Link: https://lore.kernel.org/r/20230209110424.1707501-1-wintera@linux.ibm.comSigned-off-by:
-
Thorsten Winkler authored
This LWN article explains the rationale for this change https: //lwn.net/Articles/69419/ Ie. snprintf() returns what *would* be the resulting length, while scnprintf() returns the actual length. Reported-by:
Jules Irenge <jbi.octave@gmail.com> Reviewed-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
Thorsten Winkler <twinkler@linux.ibm.com> Signed-off-by:
-
Thorsten Winkler authored
Following the advice of the Documentation/filesystems/sysfs.rst. All sysfs related show()-functions should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Reported-by:
Joe Perches <joe@perches.com> Reviewed-by:
-
Thorsten Winkler authored
Use INET6_ADDRSTRLEN constant with size of 48 which be used for char arrays storing ip addresses (for IPv4 and IPv6) Reviewed-by:
-
Alexandra Winter authored
Get rid of multiple smatch warnings, like: warn: inconsistent indenting Reviewed-by:
-
Jakub Kicinski authored
Yoshihiro Shimoda says: ==================== net: renesas: rswitch: Improve TX timestamp accuracy The patch [[123]/4] are minor refacoring for readability. The patch [4/4] is for improving TX timestamp accuracy. To improve the accuracy, it requires refactoring so that this is not a fixed patch. v2: https://lore.kernel.org/all/20230208235721.2336249-1-yoshihiro.shimoda.uh@renesas.com/ v1: https://lore.kernel.org/all/20230208073445.2317192-1-yoshihiro.shimoda.uh@renesas.com/ ==================== Link: https://lore.kernel.org/r/20230209081741.2536034-1-yoshihiro.shimoda.uh@renesas.comSigned-off-by:
-
Yoshihiro Shimoda authored
In the previous code, TX timestamp accuracy was bad because the irq handler got the timestamp from the timestamp register at that time. This hardware has "Timestamp capture" feature which can store each TX timestamp into the timestamp descriptors. To improve TX timestamp accuracy, implement timestamp descriptors' handling. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
Alexander Duyck <alexanderduyck@fb.com> Signed-off-by:
-
Yoshihiro Shimoda authored
In the previous code, the gptp flag was completely related to the !dir_tx in struct rswitch_gwca_queue because rswitch_gwca_queue_alloc() was called below: < In rswitch_txdmac_alloc() > err = rswitch_gwca_queue_alloc(ndev, priv, rdev->tx_queue, true, false, TX_RING_SIZE); So, dir_tx = true, and gptp = false. < In rswitch_rxdmac_alloc() > err = rswitch_gwca_queue_alloc(ndev, priv, rdev->rx_queue, false, true, RX_RING_SIZE); So, dir_tx = false, and gptp = true. In the future, a new queue handling for timestamp will be implemented and this gptp flag is confusable. So, remove the gptp flag. Signed-off-by:
-
Yoshihiro Shimoda authored
To improve readability, move linkfix related variables to struct rswitch_gwca. Also, rename function names "desc" with "linkfix". Signed-off-by:
-
Yoshihiro Shimoda authored
To add a new ring which is really related to timestamp (ts_ring) in the future, rename the following members to improve readability: ring --> tx_ring ts_ring --> rx_ring Signed-off-by:
-
