lwn.git/drivers/net/wireless/intel/iwlwifi/pcie/rx.c, branch v5.14

iwlwifi: pcie: remove TR/CR tail allocations

2021-06-22T13:57:55+00:00

The TR/CR tail data are meant to be per-queue-arrays, however, we allocate them completely wrong (we have a separate allocation per queue). Looking at this more closely, it turns out that the hardware never uses these - we have a separate free list per RX queue and maintain a write pointer for that in a register, and the RX itself is indicated in the RB status (rb_stts) DMA region. Despite nothing using the tail pointers, the hardware will unconditionally access them to write updates, even when we aren't using CRs/TRs. Give it dummy values that we never use/update so it can do that without causing trouble. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210617110647.5f5764e04c46.I4d5de1929be048085767f1234a1e07b517ab6a2d@changeid Signed-off-by: Luca Coelho

iwlwifi: pcie: add ISR debug info for msix debug

2021-04-14T09:07:19+00:00

The debug prints help in case we get timeout on waiting for hw. Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210411124417.306e2e56d3e8.I72e2977abbb1fddf23b8476bedf6a183fe969ff5@changeid Signed-off-by: Luca Coelho

iwlwifi: pcie: merge napi_poll_msix functions

2021-04-14T09:07:19+00:00

The only difference between iwl_pcie_napi_poll_msix_shared() and iwl_pcie_napi_poll_msix() is when we have a shared queue and nothing in the rx queue. This case doesn't affect CPU performance, so we can merge the two functions. Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210411124417.9d1b61ef53a5.I60b33d5379cf7c12f1de30fc3fd4cefc38220141@changeid Signed-off-by: Luca Coelho

iwlwifi: pcie: clear only FH bits handle in the interrupt

2021-04-14T09:07:16+00:00

For simplicity we assume that msix has 2 IRQ lines one used for rx data called msix_non_share, and another used for one bit flags messages (alive, hw error, sw error, rx data flag) called msix_share. Every time the FW has data to send it puts it on the RX queue and HW turns on the flags in msix_share (inta_fw) indicating about rx data, and HW sends an interrupt a bit later to the msix_non_share _unless_ the msix_shared RX data bit was cleared. Currently in the code every time we get an msix_shared we clear all bits including rx data queue bits. So we can have a race ---------------------------------------------------- DRIVER | HW | FW ---------------------------------------------------- - send host cmd to FW | | | | - handle message | | and put a response | | on the RX queue | - RX flag on | | | - send alive msix | - alive flag on | | - interrupt | | msix_share driver | - handle msix_shared | | and clear all flags | | bits | | | - don't send an | | interrupt on | | msix_non_shared | | (driver cleared) | - driver timeout on | | waiting for host cmd | | respond | | | | ---------------------------------------------------- The change is to clear only the msi_shared flags that are handled in the msix_shared flow, which will cause the hardware to send an interrupt on the msix_non_share line as well, when it has data. Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210330162204.a1cdda2fa270.I02a82312679f4541f30bb8db8747a797dbb70ee7@changeid Signed-off-by: Luca Coelho

iwlwifi: don't call netif_napi_add() with rxq->lock held (was Re: Lockdep warning in iwl_pcie_rx_handle())

2021-03-03T15:59:16+00:00

We can't call netif_napi_add() with rxq-lock held, as there is a potential for deadlock as spotted by lockdep (see below). rxq->lock is not protecting anything over the netif_napi_add() codepath anyway, so let's drop it just before calling into NAPI. ======================================================== WARNING: possible irq lock inversion dependency detected 5.12.0-rc1-00002-gbada49429032 #5 Not tainted -------------------------------------------------------- irq/136-iwlwifi/565 just changed the state of lock: ffff89f28433b0b0 (&rxq->lock){+.-.}-{2:2}, at: iwl_pcie_rx_handle+0x7f/0x960 [iwlwifi] but this lock took another, SOFTIRQ-unsafe lock in the past: (napi_hash_lock){+.+.}-{2:2} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(napi_hash_lock); local_irq_disable(); lock(&rxq->lock); lock(napi_hash_lock); lock(&rxq->lock); *** DEADLOCK *** 1 lock held by irq/136-iwlwifi/565: #0: ffff89f2b1440170 (sync_cmd_lockdep_map){+.+.}-{0:0}, at: iwl_pcie_irq_handler+0x5/0xb30 the shortest dependencies between 2nd lock and 1st lock: -> (napi_hash_lock){+.+.}-{2:2} { HARDIRQ-ON-W at: lock_acquire+0x277/0x3d0 _raw_spin_lock+0x2c/0x40 netif_napi_add+0x14b/0x270 e1000_probe+0x2fe/0xee0 [e1000e] local_pci_probe+0x42/0x90 pci_device_probe+0x10b/0x1c0 really_probe+0xef/0x4b0 driver_probe_device+0xde/0x150 device_driver_attach+0x4f/0x60 __driver_attach+0x9c/0x140 bus_for_each_dev+0x79/0xc0 bus_add_driver+0x18d/0x220 driver_register+0x5b/0xf0 do_one_initcall+0x5b/0x300 do_init_module+0x5b/0x21c load_module+0x1dae/0x22c0 __do_sys_finit_module+0xad/0x110 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae SOFTIRQ-ON-W at: lock_acquire+0x277/0x3d0 _raw_spin_lock+0x2c/0x40 netif_napi_add+0x14b/0x270 e1000_probe+0x2fe/0xee0 [e1000e] local_pci_probe+0x42/0x90 pci_device_probe+0x10b/0x1c0 really_probe+0xef/0x4b0 driver_probe_device+0xde/0x150 device_driver_attach+0x4f/0x60 __driver_attach+0x9c/0x140 bus_for_each_dev+0x79/0xc0 bus_add_driver+0x18d/0x220 driver_register+0x5b/0xf0 do_one_initcall+0x5b/0x300 do_init_module+0x5b/0x21c load_module+0x1dae/0x22c0 __do_sys_finit_module+0xad/0x110 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae INITIAL USE at: lock_acquire+0x277/0x3d0 _raw_spin_lock+0x2c/0x40 netif_napi_add+0x14b/0x270 e1000_probe+0x2fe/0xee0 [e1000e] local_pci_probe+0x42/0x90 pci_device_probe+0x10b/0x1c0 really_probe+0xef/0x4b0 driver_probe_device+0xde/0x150 device_driver_attach+0x4f/0x60 __driver_attach+0x9c/0x140 bus_for_each_dev+0x79/0xc0 bus_add_driver+0x18d/0x220 driver_register+0x5b/0xf0 do_one_initcall+0x5b/0x300 do_init_module+0x5b/0x21c load_module+0x1dae/0x22c0 __do_sys_finit_module+0xad/0x110 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae } ... key at: [] napi_hash_lock+0x18/0x40 ... acquired at: _raw_spin_lock+0x2c/0x40 netif_napi_add+0x14b/0x270 _iwl_pcie_rx_init+0x1f4/0x710 [iwlwifi] iwl_pcie_rx_init+0x1b/0x3b0 [iwlwifi] iwl_trans_pcie_start_fw+0x2ac/0x6a0 [iwlwifi] iwl_mvm_load_ucode_wait_alive+0x116/0x460 [iwlmvm] iwl_run_init_mvm_ucode+0xa4/0x3a0 [iwlmvm] iwl_op_mode_mvm_start+0x9ed/0xbf0 [iwlmvm] _iwl_op_mode_start.isra.4+0x42/0x80 [iwlwifi] iwl_opmode_register+0x71/0xe0 [iwlwifi] iwl_mvm_init+0x34/0x1000 [iwlmvm] do_one_initcall+0x5b/0x300 do_init_module+0x5b/0x21c load_module+0x1dae/0x22c0 __do_sys_finit_module+0xad/0x110 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae [ ... lockdep output trimmed .... ] Fixes: 25edc8f259c7106 ("iwlwifi: pcie: properly implement NAPI") Signed-off-by: Jiri Kosina Acked-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2103021134060.12405@cbobk.fhfr.pm

iwlwifi: pcie: don't crash when rx queues aren't allocated in interrupt

2021-02-10T12:39:43+00:00

WARNING is better than crashing. Since this happened to me, be on the safe side. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210210142629.d4651427fcda.I1bcecb73676d039e2521309c07fc6b6314a90546@changeid Signed-off-by: Luca Coelho

iwlwifi: remove flags argument for nic_access

2021-02-10T12:39:40+00:00

Since we no longer save interrupts, we no longer need the flags argument here, remove it throughout. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210210142629.8de8fe6f9fff.If040b056d0e8c771c65ac5c29230f939354a142b@changeid Signed-off-by: Luca Coelho

iwlwifi: pcie: NULLify pointers after free

2021-02-10T12:37:30+00:00

Remember that those pointers have been freed by setting them to NULL. Otherwise, we'd keep rxq pointing to random memory which would prevent us from trying to re-allocate the Rx resources if we call rx_alloc again. Also, propagate the allocation failure to the caller of iwl_pcie_nic_init so that we won't go further in the start flow. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210210135352.996b400d2f1c.I630379c504644700322f57b259383ae0af8d1975@changeid Signed-off-by: Luca Coelho

iwlwifi: pcie: Disable softirqs during Rx queue init

2021-02-05T10:00:13+00:00

When Rx queues are configured during module init, NAPI is enabled while the Rx queue lock is held. However, since softirqs are not disabled, it is possible that and IRQ would fire and call iwl_pcie_rx_handle() which would also try to acquire the Rx lock. Prevent this by disabling softirqs during Rx queue configuration, as part of module init flow. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210205110447.d206ac428823.Ia19339efb09f9d80143f0d0e398a158180754cfa@changeid Signed-off-by: Luca Coelho

iwlwifi: tx: move handing sync/async host command to trans

2021-02-05T09:55:19+00:00

Handling host commands in a sync way is not directly related to PCIe transport, and can serve as common logic for any transport, so move it to trans layer. Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210117164916.fde99af4e0f7.I4cab95919eb35cc5bfb26d32dcf5e15419d0e0ef@changeid Signed-off-by: Luca Coelho