summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2021-12-07iwlwifi: mvm: update rate scale in moving back to assoc stateMordechay Goodstein
In assoc state we only use narrow bandwidth, due to phy/radio not configured to max bandwidth. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204130722.139d74d2b063.I4cfbb594c110ea9b250e2306c30601f847db2c1a@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: avoid clearing a just saved session protection idShaul Triebitz
When scheduling a session protection the id is saved but then it may be cleared when calling iwl_mvm_te_clear_data (if a previous session protection is currently active). Fix it by saving the id after calling iwl_mvm_te_clear_data. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204130722.b0743a588d14.I098fef6677d0dab3ef1b6183ed206a10bab01eb2@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: add support for statistics update version 15Mordechay Goodstein
The main changes are remove the respond from STATISTICS_CMD and sending it with STATISTICS_NOTIFICATION, and updating for all mac id's and phy id's in one notification. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204130722.832c7b599202.If192dce8f51ec13005999c3ff96fe09a73cd8f91@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: Add support for a new version of scan request commandIlan Peer
The scan request command is identical in binary format to the previous scan request command and the only change is now a previously reserved octet is used to indicate new flags introduced in the command. Align the code to support the new version and the previous one. Later patches would add the specific handling for the new flags. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204130722.392a4af559bc.Ib8f1e3b527453531c10bfd7f4b116d3e257c7f1f@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: Fix wrong documentation for scan request commandIlan Peer
Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204130722.26c8bd826c83.Iefc78689607561573d8afbc7c5d3797abfbe875e@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: add missing entries for Gf4 with So and SoFLuca Coelho
We need to support platforms with So and SoF together with Gf4 radio modules. The difference is that these devices support CDB, so add the entries accordingly. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204130722.e7fa5b87fbdb.Ib47ff1dc082366b570649dfd8a2b24f0d6c52b5b@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: remove session protection upon station removalEmmanuel Grumbach
When the station is removed we need to remove the session protection that may be still running. Note that we need also to remove the session protection upon unassoc in case the station is kept in the AUTH state. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204130722.483977310ca2.If7eba02594f20dabd22d758e1c917fbca54b2ddd@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: remove unused iwlax210_2ax_cfg_so_hr_a0 structureLuca Coelho
We don't use this structure anymore, except for a check that will never match, so we can remove this structure entirely. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.c41548abd174.I6bb4f6058fd85e1dd92cd056b6eaca1cb4aa74a3@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: add support for PHY context command v4Johannes Berg
A new version of this command deprecates the rxchain_info field but is otherwise the same, so treat it the same way. We already leave the rxchain_info zeroed since the RLC command is supported. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.aca5bd78518e.I2f1b4b38899717851ea9f5b6dd23cde27e10387a@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: fw: api: add link to PHY context command struct v1Johannes Berg
There are two possible versions of this command in use today, add a link to v1 as well in the documentation. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.d7c4ed8e85e0.I524a84e03068ecf7c3125ad028f0ca465d41c0f3@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: support RLC configuration commandJohannes Berg
There's an RLC configuration command in the firmware that's going to replace the chain information in the PHY context. Add support for this command, while leaving the PHY context fields unset when we know the RLC command will be used. Also add support to send only the RLC configuration command if only the # of chains used on the PHY context changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.55faa3782bb0.I3f9d0071e680cab513c59b093d0827af99d41c51@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: d3: support v12 wowlan statusJohannes Berg
Newer firmware versions are going to come with a new version of the wowlan status API, which gives us replay counters for both GTKs that might still be in use, as well as unifying the layout of the counters to just be 64-bit quantities. Extend our code to handle this case and be able to install replay counters for both keys, if they're sent up from the firmware. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.73637acafe0b.I33e27712a12fff2816edc0a8abda1759259e20d7@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: parse firmware alive message version 6Johannes Berg
There's a new version with some addition, we'll need to do something with the additional data later, but for now just parse it so we don't fail with the newer firmware. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.f856cb190a4e.I77e3ff5a92b1bcc3e81c1344b046dade0a8b6a24@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: pcie: support Bz suspend/resume triggerHaim Dreyfuss
Instead of using two bits in the doorbell interrupt, the new Bz devices have a new CSR_IPC_SLEEP_CONTROL register to let drivers indicate the desired transition before triggering the doorbell interrupt. Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.63f3d150689a.Iaeb6f9b007e81b1a5a02144b0281935e4613cb78@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: d3: move GTK rekeys conditionJohannes Berg
Move the GTK rekeying condition into iwl_mvm_set_key_rx_seq() so we can modify it in the next patch. In the next firmware API revision we'll properly get data for both active GTKs and will have to install it accordingly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.f309942ddd15.Iaa95c602f3a681dd464e10ce2de047aa86fac19c@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: add support for Bz-Z HWMike Golant
Add support for Bz Z step HW with GF RF. Signed-off-by: Mike Golant <michael.golant@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.fc8626515758.Ibfeffc8bb071f9773ea189992ebef056f51be1be@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: support 4-bits in MAC step valueMike Golant
We have a MAC component (which is inside the SoC) and it has several different HW steps. 3 bits used to be enough but now we need 4-bits to represent all the different steps. Properly support 4-bits in the MAC step value by refactoring all the current handling of the MAC step/dash. Already from family 8000 and up the dash (bits 0-1) no longer exists and the step (until 8000 bits 2-3) consists of the dash bits as well. To do this remove the CSR_HW_REV_STEP and the CSR_HW_REV_DASH macros, replace them with CSR_HW_REV_STEP_DASH and add hw_rev_step into the trans struct. In addition remove the CSR_HW_IF_CONFIG_REG_MSK_MAC_STEP and CSR_HW_IF_CONFIG_REG_MSK_MAC_DASH macros and create a new macro combining the 2 (this way we don't need shifting or anything else.) Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com> Signed-off-by: Mike Golant <michael.golant@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211207160459.2e81a14d1f80.Ia5287e37fb3439d805336837361f6491f958e465@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: synchronize with FW after multicast commandsJohannes Berg
If userspace installs a lot of multicast groups very quickly, then we may run out of command queue space as we send the updates in an asynchronous fashion (due to locking concerns), and the CPU can create them faster than the firmware can process them. This is true even when mac80211 has a work struct that gets scheduled. Fix this by synchronizing with the firmware after sending all those commands - outside of the iteration we can send a synchronous echo command that just has the effect of the CPU waiting for the prior asynchronous commands to finish. This also will cause fewer of the commands to be sent to the firmware overall, because the work will only run once when rescheduled multiple times while it's running. Link: https://bugzilla.kernel.org/show_bug.cgi?id=213649 Suggested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reported-by: Maximilian Ernestus <maximilian@ernestus.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.51aea5b79ea4.I88a44798efda16e9fe480fb3e94224931d311b29@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: fix delBA vs. NSSN queue sync raceJohannes Berg
If we happen to decide an NSSN queue sync (IWL_MVM_RXQ_NSSN_SYNC) for some remaining packets that are still on the queue, but just after we've decided to do a delBA (which causes its own queues sync with IWL_MVM_RXQ_NOTIF_DEL_BA) we can end up with a sequence of events like this: CPU 1 CPU 2 remove BA session with baid N send IWL_MVM_RXQ_NOTIF_DEL_BA send IWL_MVM_RXQ_NSSN_SYNC get IWL_MVM_RXQ_NOTIF_DEL_BA get IWL_MVM_RXQ_NOTIF_DEL_BA get IWL_MVM_RXQ_NSSN_SYNC complete IWL_MVM_RXQ_NOTIF_DEL_BA remove N from baid_map[] get IWL_MVM_RXQ_NSSN_SYNC WARN_ON(!baid_map[N]) Thus, there's a race that leads in hitting the WARN_ON, but more importantly, it's a race that potentially even results in a new aggregation session getting assigned to baid N. To fix this, remove the WARN_ON() in the NSSN_SYNC case, we can't completely protect against hitting this case, so we shouldn't be warning. However, guard ourselves against BAID reuse by doing yet another round of queue synchronization after the entry is removed from the baid_map, so that it cannot be reused with any in-flight IWL_MVM_RXQ_NSSN_SYNC messages. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083237.44abbbc50f40.I5492600dfe513356555abe2d7df0e2835846e3d8@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07RDMA/irdma: Don't arm the CQ more than two times if no CE for this CQTatyana Nikolova
Completion events (CEs) are lost if the application is allowed to arm the CQ more than two times when no new CE for this CQ has been generated by the HW. Check if arming has been done for the CQ and if not, arm the CQ for any event otherwise promote to arm the CQ for any event only when the last arm event was solicited. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Link: https://lore.kernel.org/r/20211201231509.1930-2-shiraz.saleem@intel.com Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-12-07RDMA/irdma: Report correct WC errorsShiraz Saleem
Return IBV_WC_REM_OP_ERR for responder QP errors instead of IBV_WC_REM_ACCESS_ERR. Return IBV_WC_LOC_QP_OP_ERR for errors detected on the SQ with bad opcodes Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions") Link: https://lore.kernel.org/r/20211201231509.1930-1-shiraz.saleem@intel.com Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-12-07RDMA/irdma: Fix a potential memory allocation issue in ↵Christophe JAILLET
'irdma_prm_add_pble_mem()' 'pchunk->bitmapbuf' is a bitmap. Its size (in number of bits) is stored in 'pchunk->sizeofbitmap'. When it is allocated, the size (in bytes) is computed by: size_in_bits >> 3 There are 2 issues (numbers bellow assume that longs are 64 bits): - there is no guarantee here that 'pchunk->bitmapmem.size' is modulo BITS_PER_LONG but bitmaps are stored as longs (sizeofbitmap=8 bits will only allocate 1 byte, instead of 8 (1 long)) - the number of bytes is computed with a shift, not a round up, so we may allocate less memory than needed (sizeofbitmap=65 bits will only allocate 8 bytes (i.e. 1 long), when 2 longs are needed = 16 bytes) Fix both issues by using 'bitmap_zalloc()' and remove the useless 'bitmapmem' from 'struct irdma_chunk'. While at it, remove some useless NULL test before calling kfree/bitmap_free. Fixes: 915cc7ac0f8e ("RDMA/irdma: Add miscellaneous utility definitions") Link: https://lore.kernel.org/r/5e670b640508e14b1869c3e8e4fb970d78cbe997.1638692171.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-12-07RDMA/irdma: Fix a user-after-free in add_pble_prmShiraz Saleem
When irdma_hmc_sd_one fails, 'chunk' is freed while its still on the PBLE info list. Add the chunk entry to the PBLE info list only after successful setting of the SD in irdma_hmc_sd_one. Fixes: e8c4dbc2fcac ("RDMA/irdma: Add PBLE resource manager") Link: https://lore.kernel.org/r/20211207152135.2192-1-shiraz.saleem@intel.com Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-12-07IB/hfi1: Fix leak of rcvhdrtail_dummy_kvaddrMike Marciniszyn
This buffer is currently allocated in hfi1_init(): if (reinit) ret = init_after_reset(dd); else ret = loadtime_init(dd); if (ret) goto done; /* allocate dummy tail memory for all receive contexts */ dd->rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&dd->pcidev->dev, sizeof(u64), &dd->rcvhdrtail_dummy_dma, GFP_KERNEL); if (!dd->rcvhdrtail_dummy_kvaddr) { dd_dev_err(dd, "cannot allocate dummy tail memory\n"); ret = -ENOMEM; goto done; } The reinit triggered path will overwrite the old allocation and leak it. Fix by moving the allocation to hfi1_alloc_devdata() and the deallocation to hfi1_free_devdata(). Link: https://lore.kernel.org/r/20211129192008.101968.91302.stgit@awfm-01.cornelisnetworks.com Cc: stable@vger.kernel.org Fixes: 46b010d3eeb8 ("staging/rdma/hfi1: Workaround to prevent corruption during packet delivery") Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-12-07IB/hfi1: Fix early init panicMike Marciniszyn
The following trace can be observed with an init failure such as firmware load failures: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP PTI CPU: 0 PID: 537 Comm: kworker/0:3 Tainted: G OE --------- - - 4.18.0-240.el8.x86_64 #1 Workqueue: events work_for_cpu_fn RIP: 0010:0x0 Code: Bad RIP value. RSP: 0000:ffffae5f878a3c98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff95e48e025c00 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff95e48e025c00 RBP: ffff95e4bf3660a4 R08: 0000000000000000 R09: ffffffff86d5e100 R10: ffff95e49e1de600 R11: 0000000000000001 R12: ffff95e4bf366180 R13: ffff95e48e025c00 R14: ffff95e4bf366028 R15: ffff95e4bf366000 FS: 0000000000000000(0000) GS:ffff95e4df200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000f86a0a003 CR4: 00000000001606f0 Call Trace: receive_context_interrupt+0x1f/0x40 [hfi1] __free_irq+0x201/0x300 free_irq+0x2e/0x60 pci_free_irq+0x18/0x30 msix_free_irq.part.2+0x46/0x80 [hfi1] msix_clean_up_interrupts+0x2b/0x70 [hfi1] hfi1_init_dd+0x640/0x1a90 [hfi1] do_init_one.isra.19+0x34d/0x680 [hfi1] local_pci_probe+0x41/0x90 work_for_cpu_fn+0x16/0x20 process_one_work+0x1a7/0x360 worker_thread+0x1cf/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 The free_irq() results in a callback to the registered interrupt handler, and rcd->do_interrupt is NULL because the receive context data structures are not fully initialized. Fix by ensuring that the do_interrupt is always assigned and adding a guards in the slow path handler to detect and handle a partially initialized receive context and noop the receive. Link: https://lore.kernel.org/r/20211129192003.101968.33612.stgit@awfm-01.cornelisnetworks.com Cc: stable@vger.kernel.org Fixes: b0ba3c18d6bf ("IB/hfi1: Move normal functions from hfi1_devdata to const array") Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-12-07IB/hfi1: Insure use of smp_processor_id() is preempt disabledMike Marciniszyn
The following BUG has just surfaced with our 5.16 testing: BUG: using smp_processor_id() in preemptible [00000000] code: mpicheck/1581081 caller is sdma_select_user_engine+0x72/0x210 [hfi1] CPU: 0 PID: 1581081 Comm: mpicheck Tainted: G S 5.16.0-rc1+ #1 Hardware name: Intel Corporation S2600WT2R/S2600WT2R, BIOS SE5C610.86B.01.01.0016.033120161139 03/31/2016 Call Trace: <TASK> dump_stack_lvl+0x33/0x42 check_preemption_disabled+0xbf/0xe0 sdma_select_user_engine+0x72/0x210 [hfi1] ? _raw_spin_unlock_irqrestore+0x1f/0x31 ? hfi1_mmu_rb_insert+0x6b/0x200 [hfi1] hfi1_user_sdma_process_request+0xa02/0x1120 [hfi1] ? hfi1_write_iter+0xb8/0x200 [hfi1] hfi1_write_iter+0xb8/0x200 [hfi1] do_iter_readv_writev+0x163/0x1c0 do_iter_write+0x80/0x1c0 vfs_writev+0x88/0x1a0 ? recalibrate_cpu_khz+0x10/0x10 ? ktime_get+0x3e/0xa0 ? __fget_files+0x66/0xa0 do_writev+0x65/0x100 do_syscall_64+0x3a/0x80 Fix this long standing bug by moving the smp_processor_id() to after the rcu_read_lock(). The rcu_read_lock() implicitly disables preemption. Link: https://lore.kernel.org/r/20211129191958.101968.87329.stgit@awfm-01.cornelisnetworks.com Cc: stable@vger.kernel.org Fixes: 0cb2aa690c7e ("IB/hfi1: Add sysfs interface for affinity setup") Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-12-07IB/hfi1: Correct guard on eager buffer deallocationMike Marciniszyn
The code tests the dma address which legitimately can be 0. The code should test the kernel logical address to avoid leaking eager buffer allocations that happen to map to a dma address of 0. Fixes: 60368186fd85 ("IB/hfi1: Fix user-space buffers mapping with IOMMU enabled") Link: https://lore.kernel.org/r/20211129191952.101968.17137.stgit@awfm-01.cornelisnetworks.com Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-12-07nvme: fix use after free when disconnecting a reconnecting ctrlRuozhu Li
A crash happens when trying to disconnect a reconnecting ctrl: 1) The network was cut off when the connection was just established, scan work hang there waiting for some IOs complete. Those I/Os were retried because we return BLK_STS_RESOURCE to blk in reconnecting. 2) After a while, I tried to disconnect this connection. This procedure also hangs because it tried to obtain ctrl->scan_lock. It should be noted that now we have switched the controller state to NVME_CTRL_DELETING. 3) In nvme_check_ready(), we always return true when ctrl->state is NVME_CTRL_DELETING, so those retrying I/Os were issued to the bottom device which was already freed. To fix this, when ctrl->state is NVME_CTRL_DELETING, issue cmd to bottom device only when queue state is live. If not, return host path error to the block layer Signed-off-by: Ruozhu Li <liruozhu@huawei.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-12-07nvme-multipath: set ana_log_size to 0 after free ana_log_bufHou Tao
Set ana_log_size to 0 when ana_log_buf is freed to make sure nvme_mpath_init_identify will do the right thing when retrying after an earlier failure. Signed-off-by: Hou Tao <houtao1@huawei.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-12-07PCI: apple: Follow the PCIe specifications when resetting the portMarc Zyngier
While the Apple PCIe driver works correctly when directly booted from the firmware, it fails to initialise when the kernel is booted from a bootloader using PCIe such as u-boot. That's because we're missing a proper reset of the port (we only clear the reset, but never assert it). The PCIe spec requirements are two-fold: - PERST# must be asserted before setting up the clocks and stay asserted for at least 100us (Tperst-clk) - Once PERST# is deasserted, the OS must wait for at least 100ms "from the end of a Conventional Reset" before we can start talking to the devices Implementing this results in a booting system. [bhelgaas: #PERST -> PERST#, update spec references to current] Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up") Link: https://lore.kernel.org/r/20211123180636.80558-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Acked-by: Pali Rohár <pali@kernel.org> Cc: Alyssa Rosenzweig <alyssa@rosenzweig.io> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-07Bluetooth: btusb: Return error code when getting patch status failedMark Chen
If there are failure cases in getting patch status, it should return the error code (-EIO). Fixes: fc342c4dc4087 ("Bluetooth: btusb: Add protocol support for MediaTek MT7921U USB devices") Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Mark Chen <mark-yw.chen@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-12-07Bluetooth: btusb: Handle download_firmware failure casesMark Chen
For Mediatek chipset, it can not enabled if there are something wrong in btmtk_setup_firmware_79xx(). Thus, the process must be terminated and returned error code. Fixes: fc342c4dc4087 ("Bluetooth: btusb: Add protocol support for MediaTek MT7921U USB devices") Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Mark Chen <mark-yw.chen@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-12-07Bluetooth: btusb: Add support for queuing during polling intervalLuiz Augusto von Dentz
This makes btusb to queue ACL and events during a polling interval by using of a delayed work, with the interval working as a time window where frames received from different endpoints are considered to be arrived at same time and then attempt to resolve potential conflics by processing the events ahead of ACL packets. It worth noting though that priorizing events over ACL data may result in inverting the order compared to how they appeared over the air, for instance there may be packets received before a disconnect event that will be discarded and unencrypted packets received before encryption change which would considered encrypted, because of these potential changes on the order the support for queuing during the polling interval is not enabled by default so it requires setting force_poll_sync debugfs while the adapter is down. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-12-07Bluetooth: btbcm: disable read tx power for some Macs with the T2 Security chipAditya Garg
Some Macs with the T2 security chip had Bluetooth not working. To fix it we add DMI based quirks to disable querying of LE Tx power. Signed-off-by: Aditya Garg <gargaditya08@live.com> Reported-by: Orlando Chamberlain <redecorating@protonmail.com> Tested-by: Orlando Chamberlain <redecorating@protonmail.com> Link: https://lore.kernel.org/r/4970a940-211b-25d6-edab-21a815313954@protonmail.com Fixes: 7c395ea521e6 ("Bluetooth: Query LE tx power on startup") Cc: stable@vger.kernel.org Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-12-07Bluetooth: btmtksdio: enable AOSP extension for MT7921Sean Wang
Similar to MT7921 btusb, we enable AOSP extension for MT7921 btmtksdio as well. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-12-07Bluetooth: btmtksdio: enable msft opcodeŁukasz Bartosik
Enable msft opcode for mt7921 chip. Signed-off-by: Łukasz Bartosik <lb@semihalf.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-12-07Bluetooth: btusb: Add one more Bluetooth part for WCN6855Zijun Hu
Add a USB ID 0489:e0e3 of HP to usb_device_id table for WCN6855. -Device(0489:e0e3) from /sys/kernel/debug/usb/devices T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e0e3 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I: If#= 1 Alt= 7 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 65 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 65 Ivl=1ms Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-12-07ath11k: change to use dynamic memory for channel list of scanWen Gong
Currently there are about 60 channels for 6 GHz, then the size of chan_list in struct scan_req_params which is 40 is not enough to fill all the channel list of 6 GHz. Use dynamic memory to save the channel list of scan. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211129110939.15711-1-quic_wgong@quicinc.com
2021-12-07ath11k: Fix QMI file type enum valueSeevalamuthu Mariappan
bdf_type for caldata in QMI_WLANFW_BDF_DOWNLOAD_REQ_V01 is wrongly sent as 1. But, expected bdf_type value for caldata and EEPROM is 2 and 3 respectively. It leads to firmware crash. Fix ath11k_qmi_file_type enum values. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1 Fixes: 336e7b53c82f ("ath11k: clean up BDF download functions") Signed-off-by: Seevalamuthu Mariappan <quic_seevalam@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1638182754-18408-1-git-send-email-quic_seevalam@quicinc.com
2021-12-07ath11k: add support for WCN6855 hw2.1Baochen Qiang
Ath11k fails to probe WCN6855 hw2.1 chip: [ 6.983821] ath11k_pci 0000:06:00.0: enabling device (0000 -> 0002) [ 6.983841] ath11k_pci 0000:06:00.0: Unsupported WCN6855 SOC hardware version: 18 17 This is caused by the wrong bit mask setting of hardware major version: for QCA6390/QCN6855, it should be BIT8-11, not BIT8-16, so change the definition to GENMASK(11, 8). Also, add a separate entry for WCN6855 hw2.1 in ath11k_hw_params. Please note that currently WCN6855 hw2.1 shares the same firmwares as hw2.0, so users of this chip need to create a symlink as below: ln -s hw2.0 hw2.1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Fixes: 18ac1665e785 ("ath11k: pci: check TCSR_SOC_HW_VERSION") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211129025613.21594-1-quic_bqiang@quicinc.com
2021-12-07ath9k: switch to rate table based lookupJonas Jelonek
This patch changes mac80211 rate control for the ath9k driver. The rate lookup per packet is changed from legacy usage of ieee80211_get_tx_rates() to the new rate table based lookup in struct ieee80211_sta->rates. The most recent rate control API, introduced with commit 0d528d85c519 ("mac80211: improve the rate control API"), allows drivers to directly get rates from ieee80211_sta->rates. This is not used by every driver yet, the translation/merge is currently performed in ieee80211_get_tx_rates. This patch changes the behaviour and avoids the call to ieee80211_get_tx_rates and subsequent calls. ath9k now directly reads rates from sta->rates into its rate table. Cause ath9k does not expect rate selection in SKB->CB, the table merge does not consider rate array in SKB->CB except for the first entry (used for probing). Tested with a 8devices Rambutan with QCA9558 SoC by performing two runs, one without the patch and one with. Generated traffic between AP and multiple STAs in each run, measured throughput and captured rc_stats. Comparison of both runs resulted in same rate selection and no performance loss or other negative effects. Co-developed-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de> Signed-off-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211128090753.958-1-jelonek.jonas@gmail.com
2021-12-07ath10k: Fix the MTU size on QCA9377 SDIOFabio Estevam
On an imx6dl-pico-pi board with a QCA9377 SDIO chip, simply trying to connect via ssh to another machine causes: [ 55.824159] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12 [ 55.832169] ath10k_sdio mmc1:0001:1: failed to submit frame: -12 [ 55.838529] ath10k_sdio mmc1:0001:1: failed to push frame: -12 [ 55.905863] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12 [ 55.913650] ath10k_sdio mmc1:0001:1: failed to submit frame: -12 [ 55.919887] ath10k_sdio mmc1:0001:1: failed to push frame: -12 , leading to an ssh connection failure. One user inspected the size of frames on Wireshark and reported the followig: "I was able to narrow the issue down to the mtu. If I set the mtu for the wlan0 device to 1486 instead of 1500, the issue does not happen. The size of frames that I see on Wireshark is exactly 1500 after setting it to 1486." Clearing the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE avoids the problem and the ssh command works successfully after that. Introduce a 'credit_size_workaround' field to ath10k_hw_params for the QCA9377 SDIO, so that the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE is not set in this case. Tested with QCA9377 SDIO with firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1. Fixes: 2f918ea98606 ("ath10k: enable alt data of TX path for sdio") Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211124131047.713756-1-festevam@denx.de
2021-12-07iwlwifi: mvm: demote non-compliant kernel-doc headerYang Shen
Fixes the following W=1 kernel build warning: drivers/net/wireless/intel/iwlwifi/mvm/rfi.c:11: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: Yang Shen <shenyang39@huawei.com> [removed the static const fix, since it's already done and updated the commit message accordingly.] Link: https://lore.kernel.org/r/20210517050141.61488-7-shenyang39@huawei.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07wireless: iwlwifi: Fix a double free in iwl_txq_dyn_alloc_dmaLv Yunlong
In iwl_txq_dyn_alloc_dma, txq->tfds is freed at first time by: iwl_txq_alloc()->goto err_free_tfds->dma_free_coherent(). But it forgot to set txq->tfds to NULL. Then the txq->tfds is freed again in iwl_txq_dyn_alloc_dma by: goto error->iwl_txq_gen2_free_memory()->dma_free_coherent(). My patch sets txq->tfds to NULL after the first free to avoid the double free. Fixes: 0cd1ad2d7fd41 ("iwlwifi: move all bus-independent TX functions to common code") Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn> Link: https://lore.kernel.org/r/20210403054755.4781-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: fix a possible NULL pointer deferenceEmmanuel Grumbach
Smatch spot a possible NULL pointer dereference. Fix it. __iwl_mvm_mac_set_key can be called with sta = NULL Also add a NULL pointer check after memory allocation. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://lore.kernel.org/r/20211130105951.85539-1-emmanuel.grumbach@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mei: Fix spelling mistake "req_ownserhip" -> "req_ownership"Colin Ian King
There is a spelling mistake in a debugfs filename. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20211129124921.11817-1-colin.i.king@gmail.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mei: don't rely on the size from the shared areaEmmanuel Grumbach
If CSME is compromised, it could report a bigger queue size in the share area and make the host perform an out of bound access. Instead of reading the size of the queue from the shared area, store it in the regular context which is not accessible by CSME. While at it, fix a small typo in an error print. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://lore.kernel.org/r/20211128121509.3952-1-emmanuel.grumbach@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07irqchip/apple-aic: Mark aic_init_smp() as __initDonghyeok Kim
This function is only called from the driver init code. Signed-off-by: Donghyeok Kim <dthex5d@gmail.com> Acked-by: Hector Martin <marcan@marcan.st> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211204164228.5920-1-dthex5d@gmail.com
2021-12-07can: m_can: pci: use custom bit timings for Elkhart LakeMatthias Schiffer
The relevant datasheet [1] specifies nonstandard limits for the bit timing parameters. While it is unclear what the exact effect of violating these limits is, it seems like a good idea to adhere to the documentation. [1] Intel Atom® x6000E Series, and Intel® Pentium® and Celeron® N and J Series Processors for IoT Applications Datasheet, Volume 2 (Book 3 of 3), July 2021, Revision 001 Fixes: cab7ffc0324f ("can: m_can: add PCI glue driver for Intel Elkhart Lake") Link: https://lore.kernel.org/all/9eba5d7c05a48ead4024ffa6e5926f191d8c6b38.1636967198.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-12-07can: m_can: make custom bittiming fields constMatthias Schiffer
The assigned timing structs will be defined a const anyway, so we can avoid a few casts by declaring the struct fields as const as well. Link: https://lore.kernel.org/all/4508fa4e639164b2584c49a065d90c78a91fa568.1636967198.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
generated by cgit (git 2.34.1) at 2025-09-15 19:03:58 +0000