- 30 Aug, 2021 9 commits
-
-
Edwin Peer authored
The conversion follows this general pattern for most of the calls: 1. The input message is changed from a stack variable initialized using bnxt_hwrm_cmd_hdr_init() to a pointer allocated and intialized using hwrm_req_init(). 2. If we don't need to read the firmware response, the hwrm_send_message() call is replaced with hwrm_req_send(). 3. If we need to read the firmware response, the mutex lock is replaced by hwrm_req_hold() to hold the response. When the response is read, the mutex unlock is replaced by hwrm_req_drop(). If additional DMA buffers are needed for firmware response data, the hwrm_req_dma_slice() is used instead of calling dma_alloc_coherent(). Some minor refactoring is also done while doing these conversions. v2: Fix unintialized variable warnings in __bnxt_hwrm_get_tx_rings() and bnxt_approve_mac() Signed-off-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Edwin Peer authored
We currently use the hwrm_cmd_lock to serialize the update of the firmware's link status response data and the copying of link status data to the VF. This won't work when we update the firmware message APIs, so we use the link_lock mutex instead. All link_info data should be updated under the link_lock mutex. Also add link_lock to functions that touch link_info in __bnxt_open_nic() and bnxt_probe_phy(). The locking is probably not strictly necessary during probe, but it's more consistent. Signed-off-by:
-
Edwin Peer authored
Slices are a mechanism for suballocating DMA mapped regions from the request buffer. Such regions can be used for indirect command data instead of creating new mappings with dma_alloc_coherent(). The advantage of using a slice is that the lifetime of the slice is bound to the request and will be automatically unmapped when the request is consumed. A single external region is also supported. This allows for regions that will not fit inside the spare request buffer space such that the same API can be used consistently even for larger mappings. Signed-off-by:
-
Edwin Peer authored
hwrm_req_replace() provides an assignment like operation to replace a managed HWRM request object with data from a pre-built source. This is useful for handling request data provided by higher layer HWRM clients. Signed-off-by:
-
Edwin Peer authored
During firmware crash recovery, it is possible for firmware to respond to stale HWRM commands that have already timed out. Because response buffers may be reused, any out of sequence responses need to be ignored and only the matching seq_id should be accepted. Also, READ_ONCE should be used for the reads from the DMA buffer to ensure that the necessary loads are scheduled. Reviewed-by:
Scott Branden <scott.branden@broadcom.com> Signed-off-by:
-
Edwin Peer authored
This change constitutes a major step towards supporting multiple firmware commands in flight by maintaining a separate response buffer for the duration of each request. These firmware commands are also known as Hardware Resource Manager (HWRM) commands. Using separate response buffers requires an API change in order for callers to be able to free the buffer when done. It is impossible to keep the existing APIs unchanged. The existing usage for a simple HWRM message request such as the following: struct input req = {0}; bnxt_hwrm_cmd_hdr_init(bp, &req, REQ_TYPE, -1, -1); rc = hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT); if (rc) /* error */ changes to: struct input *req; rc = hwrm_req_init(bp, req, REQ_TYPE); if (rc) /* error */ rc = hwrm_req_send(bp, req); /* consumes req */ if (rc) /* error */ The key changes are: 1. The req is no longer allocated on the stack. 2. The caller must call hwrm_req_init() to allocate a req buffer and check for a valid buffer. 3. The req buffer is automatically released when hwrm_req_send() returns. 4. If the caller wants to check the firmware response, the caller must call hwrm_req_hold() to take ownership of the response buffer and release it afterwards using hwrm_req_drop(). The caller is no longer required to explicitly hold the hwrm_cmd_lock mutex to read the response. 5. Because the firmware commands and responses all have different sizes, some safeguards are added to the code. This patch maintains legacy API compatibiltiy, implementing the old API in terms of the new. The follow-on patches will convert all callers to use the new APIs. v2: Fix redefined writeq with parisc .config Fix "cast from pointer to integer of different size" warning in hwrm_calc_sentinel() Signed-off-by: -
Edwin Peer authored
Move all firmware messaging functions and definitions to new bnxt_hwrm.[ch]. The follow-on patches will make major modifications to these APIs. Signed-off-by:
-
Edwin Peer authored
Refactor the code so that __bnxt_hwrm_ver_get() does not call bnxt_hwrm_do_send_msg() directly. The new APIs will not expose this internal call. Add a new bnxt_hwrm_poll() to poll the HWRM_VER_GET firmware call silently. The other bnxt_hwrm_ver_get() function will send the HWRM_VER_GET message directly with error logs enabled. Signed-off-by:
-
Edwin Peer authored
The additional response buffer serves no useful purpose. There can be only one firmware command in flight due to the hwrm_cmd_lock mutex, which is taken for the entire duration of any command completion, KONG or otherwise. It is thus safe to share a single DMA buffer. Removing the code associated with the additional mapping will simplify matters in the next patch, which allocates response buffers from DMA pools on a per request basis. Signed-off-by:
-
- 29 Aug, 2021 30 commits
-
-
David S. Miller authored
Merge tag 'wireless-drivers-next-2021-08-29' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== pull-request: wireless-drivers-next-2021-08-29 here's a pull request to net-next tree, more info below. Please let me know if there are any problems. wireless-drivers-next patches for v5.15 Second, and most likely last, set of patches for v5.15. Lots of iwlwifi patches this time, but smaller changes to other drivers as well. Nothing special standing out. Major changes: rtw88 * add quirk to disable pci caps on HP Pavilion 14-ce0xxx brcmfmac * Add WPA3 Personal with FT to supported cipher suites wcn36xx * allow firmware name to be overridden by DT iwlwifi * support scanning hidden 6GHz networks * support for a new hardware family (Bz) * support for new firmware API versions mwifiex * add reset_d3cold quirk for Surface gen4+ devices ==================== Signed-off-by:
-
Jing Yangyang authored
./include/linux/ssb/ssb_driver_extif.h:200:8-9:WARNING: return of 0/1 in function 'ssb_extif_available' with return type bool Return statements in functions returning bool should use true/false instead of 1/0. Generated by: scripts/coccinelle/misc/boolreturn.cocci Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Jing Yangyang <jing.yangyang@zte.com.cn> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210824061341.59255-1-deng.changcheng@zte.com.cn
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below. It has been hand modified to use 'dma_set_mask_and_coherent()' instead of 'pci_set_dma_mask()/pci_set_consistent_dma_mask()' when applicable. This is less verbose. It has been compile tested. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Tsuchiya Yuto authored
To reset mwifiex on Surface gen4+ (Pro 4 or later gen) devices, it seems that putting the wifi device into D3cold is required according to errata.inf file on Windows installation (Windows/INF/errata.inf). This patch adds a function that performs power-cycle (put into D3cold then D0) and call the function at the end of reset_prepare(). Note: Need to also reset the parent device (bridge) of wifi on SB1; it might be because the bridge of wifi always reports it's in D3hot. When I tried to reset only the wifi device (not touching parent), it gave the following error and the reset failed: acpi device:4b: Cannot transition to power state D0 for parent in D3hot mwifiex_pcie 0000:03:00.0: can't change power state from D3cold to D0 (config space inaccessible) Signed-off-by:Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by:
Jonas Dreßler <verdre@v0yd.nl> Signed-off-by:
-
Jonas Dreßler authored
This commit adds the ability to apply device-specific quirks to the mwifiex driver. It uses DMI matching similar to the quirks brcmfmac uses with dmi.c. We'll add identifiers to match various MS Surface devices, which this is primarily meant for, later. This commit is a slightly modified version of a previous patch sent in by Tsuchiya Yuto. Co-developed-by:
-
Ahmad Fatoum authored
When resuming from suspend, brcmf_pcie_pm_leave_D3 will first attempt a hot resume and then fall back to removing the PCI device and then reprobing. If this probe fails, the kernel will oops, because brcmf_err, which is called to report the failure will dereference the stale bus pointer. Open code and use the default bus-less brcmf_err to avoid this. Fixes: 8602e624 ("brcmfmac: pass bus to the __brcmf_err() in pcie.c") Signed-off-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by:
-
Zenghui Yu authored
As it had never been used since the initial commit 8369ae33 ("bcma: add Broadcom specific AMBA bus driver"). Signed-off-by:
Zenghui Yu <yuzenghui@huawei.com> Signed-off-by:
-
Zenghui Yu authored
kmemleak reported that dev_name() of internally-handled cores were leaked on driver unbinding. Let's use device_initialize() to take refcounts for them and put_device() to properly free the related stuff. While looking at it, there's another potential issue for those which should be *registered* into driver core. If device_register() failed, we put device once and freed bcma_device structures. In bcma_unregister_cores(), they're treated as unregistered and we hit both UAF and double-free. That smells not good and has also been fixed now. Fixes: ab54bc84 ("bcma: fill core details for every device") Signed-off-by:
-
Kalle Valo authored
Merge commit 'e257d969' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next I think last commits in tag iwlwifi-next-for-kalle-2021-08-26 are not ready yet so I'm skipping those and pulling an earlier commit. I modified Luca's description below to not include the skipped commits. iwlwifi patches for v5.15 * Support scanning hidden 6GHz networks; * Some improvements in the FW error dumps; * Add some HE capability flags * A bunch of janitorial clean-ups; * Clean-ups in the TX code; * Small fix for SMPS; * Support for a new hardware family (Bz); * Small fix in the scan code; * A bunch of changes in the D3 code, including new FW API; * Finalize the refactoring of 6GHz scan; * Initial changes in the SAR profile code; * Fix reading one of our ACPI tables (WTAS); * Support some new ACPI table revisions; * Support new API of the WoWlan status FW notification; * Fixes in SAR ACPI tables handling; * Some debugging improvements; * Fix in ROC; * Support for new FW API versions; * Support new FW command versions; * Some other small fixes, clean-ups and improvements.
-
Li RongQing authored
smp_processor_id()/raw* will be called once each when not more queues in virtnet_xdp_get_sq() which is called in non-preemptible context, so it's safe to call the function smp_processor_id() once. Signed-off-by:
Li RongQing <lirongqing@baidu.com> Signed-off-by:
-
Christophe JAILLET authored
In [1], Christoph Hellwig has proposed to remove the wrappers in include/linux/pci-dma-compat.h. Some reasons why this API should be removed have been given by Julia Lawall in [2]. A coccinelle script has been used to perform the needed transformation Only relevant parts are given below. It has been hand modified to use 'dma_set_mask_and_coherent()' instead of 'pci_set_dma_mask()/pci_set_consistent_dma_mask()' when applicable. This is less verbose. Finally, the now useless 'dma_mask' variable has been removed. It has been compile tested. @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) [1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/ [2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/Signed-off-by:
-
Christophe JAILLET authored
In [1], Christoph Hellwig has proposed to remove the wrappers in include/linux/pci-dma-compat.h. Some reasons why this API should be removed have been given by Julia Lawall in [2]. A coccinelle script has been used to perform the needed transformation Only relevant parts are given below. It has been compile tested. @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) [1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/ [2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/Signed-off-by:
-
Christophe JAILLET authored
In [1], Christoph Hellwig has proposed to remove the wrappers in include/linux/pci-dma-compat.h. Some reasons why this API should be removed have been given by Julia Lawall in [2]. A coccinelle script has been used to perform the needed transformation Only relevant parts are given below. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) [1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/ [2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/Signed-off-by:
Geoff Levand <geoff@infradead.org> Signed-off-by:
-
Subbaraya Sundeep authored
NPC extraction profile marks layer types NPC_LT_LB_CTAG for CTAG and NPC_LT_LB_STAG_QINQ for STAG after parsing input packet. Those layer types can be used to install ntuple filters using vlan-etype option. Below are the commands and corresponding behavior with this patch in place. > alias nt "ethtool -U eth0 flow-type ether" > nt vlan 5 m 0xf000 action 0 Input packets with outer VLAN id as 5 i.e, stag packets with VLAN id 5 and ctag packets with VLAN id as 5 are hit. > nt vlan-etype 0x8100 action 0 All input ctag packets with any VLAN id are hit. > nt vlan-etype 0x88A8 action 0 All input stag packets with any VLAN id are hit. > nt vlan-etype 0x8100 vlan 5 m 0xf000 action 0 All input ctag packets with VLAN id 5 are hit. > nt vlan-etype 0x88A8 vlan 5 m 0xf000 action 0 All input stag packets with VLAN id 5 are hit. Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Signed-off-by:
-
Sunil Goutham authored
Fixed inconsistent license text across the RVU admin function driver. Signed-off-by:
-
Sunil Goutham authored
Fixed inconsistent license text across the netdev drivers. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-David S. Miller authored
queue Tony Nguyen says: ==================== 1GbE Intel Wired LAN Driver Updates 2021-08-27 ravindhan Gunasekaran says: This adds support for Credit-based shaper qdisc offload from Traffic Control system. It enables traffic prioritization and bandwidth reservation via the Credit-Based Shaper which is implemented in hardware by i225 controller. Patch 1/3 adds a default cycle-time for TSN mode to be configured. Patch 2/3 helps to separate TSN mode programming on the fly and during reset sequence. It also simplifies handling features flags for various TSN modes supported by i225 in the driver. Patch 3/3 adds support for IEEE802.1Qav(CBS) standard implemented in i225 HW. Two sets of CBS HW shapers are present in i225 and driver enables them in the two high priority queues. ==================== Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for v5.15. Major changes: wcn36xx * allow firmware name to be overridden by DT
-
David Mosberger-Tang authored
Move static "isinit" variable to wilc_spi structure to allow multiple WILC1000 devices per machine. Signed-off-by:
David Mosberger-Tang <davidm@egauge.net> Signed-off-by:
-
Paweł Drewniak authored
This allows the driver to connect to BSSIDs supporting SAE with 802.11r. Tested on Raspberry Pi 4 Model B (STA) and UniFi 6LR/OpenWRT 21.02.0-rc2. AP was set to 'sae-mixed' (WPA2/3 Personal). Signed-off-by:
Paweł Drewniak <czajernia@gmail.com> Signed-off-by:
-
Linus Walleij authored
The SSB header only uses the legacy <linux/gpio.h> header to get struct gpio_chip so inluce <linux/gpio/driver.h> which is the right include to deal with gpio_chip. Cc: Michael Buesch <m@bues.ch> Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Colin Ian King authored
Don't populate the array fsm_state on the stack but instead it static const. Makes the object code smaller by 154 bytes: Before: text data bss dec hex filename 9213 3904 0 13117 333d .../wireless/rsi/rsi_91x_debugfs.o After: text data bss dec hex filename 8995 3968 0 12963 32a3 .../wireless/rsi/rsi_91x_debugfs.o (gcc version 10.3.0) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Nathan Chancellor authored
Clang warns: drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:901:6: warning: variable 'place' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (chnl > 14) { ^~~~~~~~~ drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:909:9: note: uninitialized use occurs here return place; ^~~~~ drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:901:2: note: remove the 'if' if its condition is always true if (chnl > 14) { ^~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:899:10: note: initialize the variable 'place' to silence this warning u8 place; ^ = '\0' 1 warning generated. Commit 369956ae ("rtlwifi: rtl8192de: Remove redundant variable initializations") removed the initialization of place but it appears that this removal was in the wrong function. _rtl92c_phy_get_rightchnlplace() returns place's value at the end of the function so now if the if statement is false, place never gets initialized. Add that initialization back to address the warning. place's initialization is not necessary in rtl92d_get_rightchnlplace_for_iqk() as place is only used within the if statement so it can be removed, which is likely what was intended in the first place. Fixes: 369956ae ("rtlwifi: rtl8192de: Remove redundant variable initializations") Signed-off-by:Nathan Chancellor <nathan@kernel.org> Acked-by:
Ping-Ke Shih <pkshih@realtek.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Ugo Rémery authored
8821CE causes random freezes on HP Pavilion 14-ce0019nf. Add a quirk to disable pci ASPM capability. Signed-off-by:
Ugo Rémery <ugo.remery@gmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Dan Carpenter authored
This error path is unlikely because of it checked for NULL and returned -ENOMEM earlier in the function. But it should return an error code here as well if we ever do hit it because of a race condition or something. Fixes: bdcd8170 ("Add ath6kl cleaned up driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Miaoqing Pan authored
The problem is that gpio_free() can sleep and the cfg_soc() can be called with spinlocks held. One problematic call tree is: --> ath_reset_internal() takes &sc->sc_pcu_lock spin lock --> ath9k_hw_reset() --> ath9k_hw_gpio_request_in() --> ath9k_hw_gpio_request() --> ath9k_hw_gpio_cfg_soc() Remove gpio_free(), use error message instead, so we should make sure there is no GPIO conflict. Also remove ath9k_hw_gpio_free() from ath9k_hw_apply_gpio_override(), as gpio_mask will never be set for SOC chips. Signed-off-by:Miaoqing Pan <miaoqing@codeaurora.org> Signed-off-by:
-
Zekun Shen authored
Bad header can have large length field which can cause OOB. cptr is the last bytes for read, and the eeprom is parsed from high to low address. The OOB, triggered by the condition length > cptr could cause memory error with a read on negative index. There are some sanity check around length, but it is not compared with cptr (the remaining bytes). Here, the corrupted/bad EEPROM can cause panic. I was able to reproduce the crash, but I cannot find the log and the reproducer now. After I applied the patch, the bug is no longer reproducible. Signed-off-by:
Zekun Shen <bruceshenzk@gmail.com> Signed-off-by:
-
Loic Poulain authored
When receiving a beacon or probe response, we should update the boottime_ns field which is the timestamp the frame was received at. (cf mac80211.h) This fixes a scanning issue with Android since it relies on this timestamp to determine when the AP has been seen for the last time (via the nl80211 BSS_LAST_SEEN_BOOTTIME parameter). Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Reviewed-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by:
-
Bjorn Andersson authored
The WLAN NV firmware blob differs between platforms, and possibly devices, so add support in the wcn36xx driver for reading the path of this file from DT in order to allow these files to live in a generic file system (or linux-firmware). For some reason the parent (wcnss_ctrl) also needs to upload this blob, so rather than specifying the same information in both nodes wcn36xx reads the string from the parent's of_node. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by:
Aníbal Limón <anibal.limon@linaro.org> Signed-off-by:
-
Joseph Gates authored
If the operating channel is the first in the scan list, it was seen that a finish scan request would be sent before a start scan request was sent, causing the firmware to fail all future scans. Track the current channel being scanned to avoid requesting the scan finish before it starts. Cc: <stable@vger.kernel.org> Fixes: 5973a294 ("wcn36xx: Fix software-driven scan") Signed-off-by:
Joseph Gates <jgates@squareup.com> Signed-off-by:
-
- 28 Aug, 2021 1 commit
-
-
David S. Miller authored
Shannon Nelson says: ==================== ionic: queue mgmt updates The first pair of patches help smooth the driver's response when the firmware has gone through a recovery/reboot cycle. The next four patches take care of a couple things seen when changing the interface status. ==================== Signed-off-by:
-
