summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
2020-01-26Revert "ath10k: fix DMA related firmware crashes on multiple devices"Zhi Chen
This reverts commit 76d164f582150fd0259ec0fcbc485470bcd8033e. PCIe hung issue was observed on multiple platforms. The issue was reproduced when DUT was configured as AP and associated with 50+ STAs. For QCA9984/QCA9888, the DMA_BURST_SIZE register controls the AXI burst size of the RD/WR access to the HOST MEM. 0 - No split , RAW read/write transfer size from MAC is put out on bus as burst length 1 - Split at 256 byte boundary 2,3 - Reserved With PCIe protocol analyzer, we can see DMA Read crossing 4KB boundary when issue happened. It broke PCIe spec and caused PCIe stuck. So revert the default value from 0 to 1. Tested: IPQ8064 + QCA9984 with firmware 10.4-3.10-00047 QCS404 + QCA9984 with firmware 10.4-3.9.0.2--00044 Synaptics AS370 + QCA9888 with firmware 10.4-3.9.0.2--00040 Signed-off-by: Zhi Chen <zhichen@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26ath10k: drop RX skb with invalid length for sdioWen Gong
When simulate random transfer fail for sdio write and read, it crash sometimes. Test steps: 1. Add config and update kernel: CONFIG_FAIL_MMC_REQUEST=y CONFIG_FAULT_INJECTION=y CONFIG_FAULT_INJECTION_DEBUG_FS=y 2. run simulate fail: cd /sys/kernel/debug/mmc1/fail_mmc_request echo 10 > probability echo 10 > times # repeat until hitting issues 3. it crash, the act len of ath10k_htc_hdr is higher than allocate len, it cause panic: [ 99.723482] skbuff: skb_over_panic: text:00000000caa0f780 len:57013 put:57013 head:000000004116f24a data:0000000019ecb4dc tail:0xdef5 end:0x640 dev:<NULL> [ 99.737697] ------------[ cut here ]------------ [ 99.742327] kernel BUG at /mnt/host/source/src/third_party/kernel/v4.19/net/core/skbuff.c:104! [ 99.750937] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 99.831154] Process kworker/0:2 (pid: 151, stack limit = 0x00000000728010bf) [ 99.838200] CPU: 0 PID: 151 Comm: kworker/0:2 Tainted: G W 4.19.85 #48 [ 99.846022] Hardware name: MediaTek krane sku0 board (DT) [ 99.851429] Workqueue: events sdio_irq_work [ 99.855614] pstate: 60000005 (nZCv daif -PAN -UAO) [ 99.860402] pc : skb_panic+0x64/0x68 [ 99.863974] lr : skb_panic+0x64/0x68 [ 99.867542] sp : ffffff8008833a90 [ 99.870850] x29: ffffff8008833ac0 x28: ffffffe52e337370 [ 99.876159] x27: ffffffe52e328a90 x26: 000000000000e0d0 [ 99.881469] x25: ffffffe52e336b60 x24: 000000000000deb5 [ 99.886779] x23: ffffffe52e340680 x22: ffffffe4efd47e00 [ 99.892088] x21: 000000000000deb5 x20: ffffffa516d85b4c [ 99.897397] x19: ffffffa526928037 x18: 0000000000000000 [ 99.902706] x17: 000000000000003c x16: ffffffa5265b6c80 [ 99.908015] x15: 0000000000000006 x14: 3a76656420303436 [ 99.913325] x13: 0000000000029bf0 x12: 0000000000000000 [ 99.918634] x11: 0000000000000000 x10: 0000000000000000 [ 99.923943] x9 : a3b907e4b2783000 x8 : a3b907e4b2783000 [ 99.929253] x7 : 0000000000000000 x6 : ffffffa526f66d76 [ 99.934563] x5 : 0000000000000000 x4 : 0000000000000000 [ 99.939872] x3 : 000000000002a5ab x2 : ffffffe53feed918 [ 99.945182] x1 : ffffffe53fee4a08 x0 : 000000000000008e [ 99.950491] Call trace: [ 99.952937] skb_panic+0x64/0x68 [ 99.956165] skb_put+0x7c/0x84 [ 99.959224] ath10k_sdio_irq_handler+0x740/0xbb8 [ath10k_sdio] [ 99.965055] process_sdio_pending_irqs+0x58/0x1a4 [ 99.969758] sdio_run_irqs+0x34/0x60 [ 99.973329] sdio_irq_work+0x1c/0x28 [ 99.974930] cros-ec-spi spi2.0: SPI transfer timed out [ 99.976904] process_one_work+0x210/0x410 [ 99.976911] worker_thread+0x234/0x3dc [ 99.976923] kthread+0x120/0x130 [ 99.982090] cros-ec-spi spi2.0: spi transfer failed: -110 [ 99.986054] ret_from_fork+0x10/0x18 [ 99.986063] Code: aa1403e2 2a1503e4 a90023e9 97e37d1a (d4210000) [ 99.986068] ---[ end trace cb6d948c5a0fd6c7 ]--- [ 100.017250] Kernel panic - not syncing: Fatal exception [ 100.018879] cros-ec-spi spi2.0: Command xfer error (err:-110) [ 100.023659] SMP: stopping secondary CPUs [ 100.023703] Kernel Offset: 0x251dc00000 from 0xffffff8008000000 [ 100.023707] CPU features: 0x0,2188200c [ 100.023709] Memory Limit: none The simulate fail of sdio is not a real sdio transter fail, it only set an error status in mmc_should_fail_request after the transfer end, actually the transfer is success, then sdio_io_rw_ext_helper will return error status and stop transfer the left data. For example, the really RX len is 286 bytes, then it will split to 2 blocks in sdio_io_rw_ext_helper, one is 256 bytes, left is 30 bytes, if the first 256 bytes get an error status by mmc_should_fail_request,then the left 30 bytes will not read in this RX operation. Then when the next RX arrive, the left 30 bytes will be considered as the header of the read, the top 8 bytes will be considered as ath10k_htc_hdr, but actually the 8 bytes is not the ath10k_htc_hdr, so the act_len from this ath10k_htc_hdr is not correct, if it is a big value, such as 57013, it will trigger skb_panic. Drop the skb with invalid length will be reasonable. This patch only effect sdio chips. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26ath10k: use true,false for bool variablezhengbin
Fixes coccicheck warning: drivers/net/wireless/ath/ath10k/htt_rx.c:2143:2-31: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26ath10k: Add optional qdss clkBjorn Andersson
The WiFi firmware found on sm8150 requires that the QDSS clock is ticking in order to operate, so add an optional clock to the binding to allow this to be specified in the sm8150 dts and add the clock to the list of clocks in the driver. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26ath10k: pci: Fix comment on ath10k_pci_dump_memory_sramBryan O'Donoghue
The description of ath10k_pci_dump_memory_sram() is inaccurate, an error can never be returned, it is always the length. Update the comment to reflect. Fixes: 219cc084c6706 ("ath10k: add memory dump support QCA9984") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26ath10k: pci: Only dump ATH10K_MEM_REGION_TYPE_IOREG when safeBryan O'Donoghue
ath10k_pci_dump_memory_reg() will try to access memory of type ATH10K_MEM_REGION_TYPE_IOREG however, if a hardware restart is in progress this can crash a system. Individual ioread32() time has been observed to jump from 15-20 ticks to > 80k ticks followed by a secure-watchdog bite and a system reset. Work around this corner case by only issuing the read transaction when the driver state is ATH10K_STATE_ON. Tested-on: QCA9988 PCI 10.4-3.9.0.2-00044 Fixes: 219cc084c6706 ("ath10k: add memory dump support QCA9984") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26wil6210: use true,false for bool variablezhengbin
Fixes coccicheck warning: drivers/net/wireless/ath/wil6210/main.c:765:1-14: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/ath/wil6210/txrx.c:1143:1-19: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/ath/wil6210/wmi.c:1516:4-23: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/ath/wil6210/wmi.c:1523:4-23: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/ath/wil6210/wmi.c:1538:4-30: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/ath/wil6210/wmi.c:1545:4-30: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26ath9k: use true,false for bool variablezhengbin
Fixes coccicheck warning: drivers/net/wireless/ath/ath9k/ar9003_aic.c:409:2-12: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26Merge tag 'iwlwifi-next-for-kalle-2020-01-11' of ↵Kalle Valo
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next First set of patches intended for v5.6 * Support new versions of the FTM FW APIs; * Fix an old bug in D3 (WoWLAN); * A couple of fixes/improvements in the receive-buffers code; * Fix in the debugging where we were skipping one TXQ; * Support new version of the beacon template FW API; * Print some extra information when the driver is loaded; * Some debugging infrastructure (aka. yoyo) updates; * Support for a new HW version; * Second phase of device configuration work started; * Some clean-ups;
2020-01-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
Minor conflict in mlx5 because changes happened to code that has moved meanwhile. Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-25Merge branch 'for-mingo' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu Pull RCU updates from Paul E. McKenney: - Expedited grace-period updates - kfree_rcu() updates - RCU list updates - Preemptible RCU updates - Torture-test updates - Miscellaneous fixes - Documentation updates Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-01-23Merge tag 'wireless-drivers-2020-01-23' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for v5.5 Second set of fixes for v5.5. There are quite a few patches, especially on iwlwifi, due to me being on a long break. Libertas also has a security fix and mt76 a build fix. iwlwifi * don't send the PPAG command when PPAG is disabled, since it can cause problems * a few fixes for a HW bug * a fix for RS offload; * a fix for 3168 devices where the NVM tables where the wrong tables were being read * fix a couple of potential memory leaks in TXQ code * disable L0S states in all hardware since our hardware doesn't officially support them anymore (and older versions of the hardware had instability in these states) * remove lar_disable parameter since it has been causing issues for some people who erroneously disable it * force the debug monitor HW to stop also when debug is disabled, since it sometimes stays on and prevents low system power states * don't send IWL_MVM_RXQ_NSSN_SYNC notification due to DMA problems libertas * fix two buffer overflows mt76 * build fix related to CONFIG_MT76_LEDS * fix off by one in bitrates handling ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-23airo: Add missing CAP_NET_ADMIN check in AIROOLDIOCTL/SIOCDEVPRIVATEMichael Ellerman
The driver for Cisco Aironet 4500 and 4800 series cards (airo.c), implements AIROOLDIOCTL/SIOCDEVPRIVATE in airo_ioctl(). The ioctl handler copies an aironet_ioctl struct from userspace, which includes a command. Some of the commands are handled in readrids(), where the user controlled command is converted into a driver-internal value called "ridcode". There are two command values, AIROGWEPKTMP and AIROGWEPKNV, which correspond to ridcode values of RID_WEP_TEMP and RID_WEP_PERM respectively. These commands both have checks that the user has CAP_NET_ADMIN, with the comment that "Only super-user can read WEP keys", otherwise they return -EPERM. However there is another command value, AIRORRID, that lets the user specify the ridcode value directly, with no other checks. This means the user can bypass the CAP_NET_ADMIN check on AIROGWEPKTMP and AIROGWEPKNV. Fix it by moving the CAP_NET_ADMIN check out of the command handling and instead do it later based on the ridcode. That way regardless of whether the ridcode is set via AIROGWEPKTMP or AIROGWEPKNV, or passed in using AIRORID, we always do the CAP_NET_ADMIN check. Found by Ilja by code inspection, not tested as I don't have the required hardware. Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-23airo: Fix possible info leak in AIROOLDIOCTL/SIOCDEVPRIVATEMichael Ellerman
The driver for Cisco Aironet 4500 and 4800 series cards (airo.c), implements AIROOLDIOCTL/SIOCDEVPRIVATE in airo_ioctl(). The ioctl handler copies an aironet_ioctl struct from userspace, which includes a command and a length. Some of the commands are handled in readrids(), which kmalloc()'s a buffer of RIDSIZE (2048) bytes. That buffer is then passed to PC4500_readrid(), which has two cases. The else case does some setup and then reads up to RIDSIZE bytes from the hardware into the kmalloc()'ed buffer. Here len == RIDSIZE, pBuf is the kmalloc()'ed buffer: // read the rid length field bap_read(ai, pBuf, 2, BAP1); // length for remaining part of rid len = min(len, (int)le16_to_cpu(*(__le16*)pBuf)) - 2; ... // read remainder of the rid rc = bap_read(ai, ((__le16*)pBuf)+1, len, BAP1); PC4500_readrid() then returns to readrids() which does: len = comp->len; if (copy_to_user(comp->data, iobuf, min(len, (int)RIDSIZE))) { Where comp->len is the user controlled length field. So if the "rid length field" returned by the hardware is < 2048, and the user requests 2048 bytes in comp->len, we will leak the previous contents of the kmalloc()'ed buffer to userspace. Fix it by kzalloc()'ing the buffer. Found by Ilja by code inspection, not tested as I don't have the required hardware. Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-22net: Fix packet reordering caused by GRO and listified RX cooperationMaxim Mikityanskiy
Commit 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs") introduces batching of GRO_NORMAL packets in napi_frags_finish, and commit 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()") adds the same to napi_skb_finish. However, dev_gro_receive (that is called just before napi_{frags,skb}_finish) can also pass skbs to the networking stack: e.g., when the GRO session is flushed, napi_gro_complete is called, which passes pp directly to netif_receive_skb_internal, skipping napi->rx_list. It means that the packet stored in pp will be handled by the stack earlier than the packets that arrived before, but are still waiting in napi->rx_list. It leads to TCP reorderings that can be observed in the TCPOFOQueue counter in netstat. This commit fixes the reordering issue by making napi_gro_complete also use napi->rx_list, so that all packets going through GRO will keep their order. In order to keep napi_gro_flush working properly, gro_normal_list calls are moved after the flush to clear napi->rx_list. iwlwifi calls napi_gro_flush directly and does the same thing that is done by gro_normal_list, so the same change is applied there: napi_gro_flush is moved to be before the flush of napi->rx_list. A few other drivers also use napi_gro_flush (brocade/bna/bnad.c, cortina/gemini.c, hisilicon/hns3/hns3_enet.c). The first two also use napi_complete_done afterwards, which performs the gro_normal_list flush, so they are fine. The latter calls napi_gro_receive right after napi_gro_flush, so it can end up with non-empty napi->rx_list anyway. Fixes: 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs") Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Cc: Alexander Lobakin <alobakin@dlink.ru> Cc: Edward Cree <ecree@solarflare.com> Acked-by: Alexander Lobakin <alobakin@dlink.ru> Acked-by: Saeed Mahameed <saeedm@mellanox.com> Acked-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-22iwlwifi: mvm: don't send the IWL_MVM_RXQ_NSSN_SYNC notif to Rx queuesEmmanuel Grumbach
The purpose of this was to keep all the queues updated with the Rx sequence numbers because unlikely yet possible situations where queues can't understand if a specific packet needs to be dropped or not. Unfortunately, it was reported that this caused issues in our DMA engine. We don't fully understand how this is related, but this is being currently debugged. For now, just don't send this notification to the Rx queues. This de-facto reverts my commit 3c514bf831ac12356b695ff054bef641b9e99593: iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues This issue was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=204873 https://bugzilla.kernel.org/show_bug.cgi?id=205001 and others maybe. Fixes: 3c514bf831ac ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues") CC: <stable@vger.kernel.org> # 5.3+ Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-08net: iwlwifi: use skb_list_walk_safe helper for gso segmentsJason A. Donenfeld
This is a straight-forward conversion case for the new function, and while we're at it, we can remove a null write to skb->next by replacing it with skb_mark_not_on_list. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-06wil6210: get rid of begin() and complete() ethtool_opsMichal Kubecek
The wil6210 driver locks a mutex in begin() ethtool_ops callback and unlocks it in complete() so that all ethtool requests are serialized. This is not going to work correctly with netlink interface; e.g. when ioctl triggers a netlink notification, netlink code would call begin() again while the mutex taken by ioctl code is still held by the same task. Let's get rid of the begin() and complete() callbacks and move the mutex locking into the remaining ethtool_ops handlers except get_drvinfo which only copies strings that are not changing so that there is no need for serialization. Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-06remove ioremap_nocache and devm_ioremap_nocacheChristoph Hellwig
ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Arnd Bergmann <arnd@arndb.de>
2020-01-04iwlwifi: add device name to device_infoLuca Coelho
We have a lot of mostly duplicated data structures that are repeated only because the device name string is different. To avoid this, move the string from the cfg to the trans structure and add it independently from the rest of the configuration to the PCI mapping tables. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-04iwlwifi: implement a new device configuration tableLuca Coelho
Add a new device table that contains information that can be checked at runtime in order to decide which configuration to use. This allows us to map the full cfg independently from the tran-specific configuration. This is the first step in creating the new table. Subsequent patches will add the possibility of checking different values at runtime in order to make the decision. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-04iwlwifi: assume the driver_data is a trans_cfg, but allow full cfgLuca Coelho
With the new concept of separating the trans-specific (trans_cfg) data from the rest of the cfg, we will start mapping only the trans_cfg part to the PCI device ID/subsystem device ID. So we can assume that the data passed to the probe function contains the trans_cfg, but since the full cfg still contains the trans_cfg at the beginning, we can allow a full cfg to be passed as well. This makes it easier to convert the existing tables one by one. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-04iwlwifi: prph: remove some unused register definitionsJohannes Berg
There are some unused register definitions, remove them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-04iwlwifi: mvm: print out extended secboot status before dumpJohannes Berg
Print out the secure boot status, extended by the PCs of LMACs and the UMAC. This needs to be before dumping, as dumping will corrupt the PC (if the NMI is handled), so move that down. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-04iwlwifi: incorporate firmware filename into versionJohannes Berg
We have many different firmware images with the same version, and it's sometimes cumbersome to figure out which image was really used, especially as the marketing strings that we do print out can be the same for (slightly) different hardware using different firmware images. Incorporate the firmware filename into the fw_version so it's printed out all the time. Unfortunately, this will make the string be longer than the 32 characters for ethtool, but we almost never really use ethtool, so strip the "iwlwifi-" prefix (if not overridden), and the remaining data that may then be stripped at the end is not usually useful anyway. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-04iwlwifi: yoyo: check for the domain on all TLV types during initLuca Coelho
Now that we don't have dynamically changing domains anymore, we can simply skip all the TLVs with domains that are not enabled. To do so, remove the checks from the functions that handle the TLVs when a timepoint is reached to the top allocation function. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-04iwlwifi: add new iwlax411 struct for type SoSnjOren Givon
Add new struct for SoSnj and add uhb support for ax411 structs. Signed-off-by: Oren Givon <oren.givon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-04iwlwifi: yoyo: remove the iwl_dbg_tlv_gen_active_trigs() functionLuca Coelho
We only call this function from a single place and it's very very small and self-contained anyway, so remove the function and move the code into the caller. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-04iwlwifi: yoyo: remove unnecessary active triggers status flagLuca Coelho
Now that we can't change the domain at runtime anymore, we don't have to protect the active trigger status. Remove it. Additionally, we don't need to flush the dumps at this point anymore, since this only runs during initialization and there shouldn't be any dumps running. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-04iwlwifi: yoyo: don't allow changing the domain via debugfsLuca Coelho
We don't want to allow changing the domain via debugfs so that we can apply the domain to all TLV types more easily (doing some at runtime is difficult due to buffer allocations etc.). Change the fw_dbg_domain debugfs file to be read-only and remove the write function. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-01-04iwlwifi: mvm: Update BEACON_TEMPLATE_CMD firmware APIAndrei Otcheretianski
The new API version adds support for FILS discovery frames. It adds a new flag and a field for short SSID configuration. The new API is backward compatible, so we can just switch to it. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-30Revert "iwlwifi: mvm: fix scan config command size"Mehmet Akif Tasova
Since v5.4-rc1 was released, iwlwifi started throwing errors when scan commands were sent to the firmware with certain devices (depending on the OTP burned in the device, which contains the list of available channels). For instance: iwlwifi 0000:00:14.3: FW error in SYNC CMD SCAN_CFG_CMD This bug was reported in the ArchLinux bug tracker: https://bugs.archlinux.org/task/64703 And also in a specific case in bugzilla, when the lar_disabled option was set: https://bugzilla.kernel.org/show_bug.cgi?id=205193 Revert the commit that introduced this error, by using the number of channels from the OTP instead of the number of channels that is specified in the FW TLV that tells us how many channels it supports. This reverts commit 06eb547c4ae4382e70d556ba213d13c95ca1801b. Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Mehmet Akif Tasova <makiftasova@gmail.com> [ Luca: reworded the commit message a bit. ] Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-25Merge branch 'core/kprobes' into perf/core, to pick up a completed branchIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-24iwlwifi: fw: make pos static in iwl_sar_get_ewrd_table() loopLuca Coelho
In the for loop where we are supposed to go through the entire table, we are using a non-static local to keep the pos index. This makes each iteration start with 3, so we always access the first item on the table. Fix this by moving the variable outside of the loo so it doesn't lose its value at every iteration. Reported-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: ba3224db7803 ("iwlwifi: mvm: fix an out-of-bound access") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-24iwlwifi: remove lar_disable module parameterLuca Coelho
This is an old parameter that was used supposed to be used only when LAR was still under development. It should not be used anymore, but, since it's available, end-users have been mangling with it unnecessarily. In some cases it can cause problems because when LAR is supported the driver and the firmware do not expect it to be disabled. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-24iwlwifi: dbg: force stop the debug monitor HWShahar S Matityahu
The driver is required to stop the debug monitor HW recording regardless of the debug configuration since the driver is responsible to halt the FW DBGC. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-24iwlwifi: pcie: always disable L0S statesLuca Coelho
L0S states have been found to be unstable with our devices and in newer hardware they are not supported at all, so we must always set the L0S_DISABLED bit. Previously we were only disabling L0S states if L1 was supported, because the assumption was that transitions from L0S to L1 state was the problematic case. But now we should never use L0S, so do it regardless of whether L1 is supported or not. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-24iwlwifi: pcie: rename L0S_ENABLED bit to L0S_DISABLEDLuca Coelho
This bit has been misnamed since the initial implementation of the driver. The correct semantics is that setting this bit disables L0S states, and we already clearly use it as such in the code. Rename it to avoid confusion. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-24iwlwifi: mvm: fix potential SKB leak on TXQ TXJohannes Berg
When we transmit after TXQ dequeue, we aren't paying attention to the return value of the transmit functions, leading to a potential SKB leak. Refactor the code a bit (and rename ..._tx to ..._tx_sta) to check for this happening. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-24iwlwifi: mvm: fix SKB leak on invalid queueJohannes Berg
It used to be the case that if we got here, we wouldn't warn but instead allocate the queue (DQA). With using the mac80211 TXQs model this changed, and we really have nothing to do with the frame here anymore, hence the warning now. However, clearly we missed in coding & review that this is now a pure error path and leaks the SKB if we return 0 instead of an indication that the SKB needs to be freed. Fix this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-23iwlwifi: remove CSR registers abstractionLuca Coelho
We needed this abstraction for some CSR registers for IWL_DEVICE_22560, but that has been removed, so we don't need the abstraction anymore. Remove it. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-23iwlwifi: remove some outdated iwl22000 configurationsLuca Coelho
A few configuration structures were either not referenced anymore or assigned to devices IDs that were not in use anymore. Remove them. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-23iwlwifi: pcie: validate queue ID before array deref/bit opsJohannes Berg
Validate that the queue ID is in range before trying to use it as an index or for test_bit() - the previous bug showed that this has in fact happened, and it was lucky that we caught it there, had the bit been set then we'd have actually used the value despite being far out of range. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-23iwlwifi: pcie: use partial pages if applicableJohannes Berg
If we have only 2k RBs like on the latest (AX210) hardware, then even on x86 where PAGE_SIZE is 4k we currently waste half of the memory. If this is the case, return partial pages from the allocator and track the offset in each RBD (to be able to find the data in them and remap them later.) This might also address other platforms with larger PAGE_SIZE by putting more RBs into a single large page. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-23iwlwifi: pcie: map only used part of RX buffersJohannes Berg
We don't need to map *everything* of the RX buffers, we won't use that much, map only the part we're going to use. This save some IOMMU space (if applicable and it can deal with that) and also prepares a bit for mapping partial pages for 2K buffers later. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-23iwlwifi: allocate more receive buffers for HE devicesJohannes Berg
For HE-capable devices, we need to allocate more receive buffers as there could be 256 frames aggregated into a single A-MPDU, and then they might contain A-MSDUs as well. Until 22000 family, the devices are able to put multiple frames into a single RB and the default RB size is 4k, but starting from AX210 family this is no longer true. On the other hand, those newer devices only use 2k receive buffers (by default). Modify the code and configuration to allocate an appropriate number of RBs depending on the device capabilities: * 4096 for AX210 HE devices, which use 2k buffers by default, * 2048 for 22000 family devices which use 4k buffers by default, * 512 for existing 9000 family devices, which doesn't really change anything since that's the default before this patch, * 512 also for AX210/22000 family devices that don't do HE. Theoretically, for devices lower than AX210, we wouldn't have to allocate that many RBs if the RB size was manually increased, but to support that the code got more complex, and it didn't really seem necessary as that's a use case for monitor mode only, where hopefully the wasted memory isn't really much of a concern. Note that AX210 devices actually support bigger than 12-bit VID, which is required here as we want to allocate 4096 buffers plus some for quick recycling, so adjust the code for that as well. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-23iwlwifi: mvm: add support for responder config command version 7Avraham Stern
The new API requires the driver to config the supported frame format (legacy, HT, VHT etc.). Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-23iwlwifi: mvm: add support for location range request version 8Avraham Stern
The new API requires the driver to set the frame format (legacy, HT, VHT etc.) to be used for the measurement. The new API also supports 11az and secured measurement, but these are not supported by the driver for now. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-23iwlwifi: pcie: extend hardware workaround to context-infoJohannes Berg
After more investigation on the hardware side, it appears that the hardware bug regarding 2^32 boundary reaching/crossing also affects other uses of the DMA engine, in particular the ones triggered by the context-info (image loader) mechanism. It also turns out that the bug only affects devices with gen2 TX hardware engine, so we don't need to change context info for gen3. The TX path workarounds are simpler to still keep for both though. Add the workaround to that code as well; this is a lot simpler as we have just a single way to allocate DMA memory there. I made the algorithm recursive (with a small limit) since it's actually (almost) impossible to hit this today - dma_alloc_coherent is currently documented to always return 32-bit addressable memory regardless of the DMA mask for it, and so we could only get REALLY unlucky to get the very last page in that area. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2019-12-23iwlwifi: Don't ignore the cap field upon mcc updateHaim Dreyfuss
When receiving a new MCC driver get all the data about the new country code and its regulatory information. Mistakenly, we ignored the cap field, which includes global regulatory information which should be applies to every channel. Fix it. Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
generated by cgit (git 2.34.1) at 2025-09-07 03:06:01 +0000