kernel/drivers/net/wireless/intel, branch linux-5.12.y

iwlwifi: pcie: fix context info freeing

2021-07-19T08:01:05Z

[ Upstream commit 26d18c75a7496c4c52b0b6789e713dc76ebfbc87 ] After firmware alive, iwl_trans_pcie_gen2_fw_alive() is called to free the context info. However, on gen3 that will then free the context info with the wrong size. Since we free this allocation later, let it stick around until the device is stopped for now, freeing some of it earlier is a separate change. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210618105614.afb63fb8cbc1.If4968db8e09f4ce2a1d27a6d750bca3d132d7d70@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin

iwlwifi: pcie: free IML DMA memory allocation

2021-07-19T08:01:05Z

[ Upstream commit 310f60f53a86eba680d9bc20a371e13b06a5f903 ] In the case of gen3 devices with image loader (IML) support, we were leaking the IML DMA allocation and never freeing it. Fix that. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210618105614.07e117dbedb7.I7bb9ebbe0617656986c2a598ea5e827b533bd3b9@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin

iwlwifi: mvm: fix error print when session protection ends

2021-07-19T08:01:05Z

[ Upstream commit 976ac0af7ba2c5424bc305b926c0807d96fdcc83 ] When the session protection ends and the Driver is not associated or a beacon was not heard, the Driver prints "No beacons heard...". That's confusing for the case where not associated. Change the print when not associated to "Not associated...". Signed-off-by: Shaul Triebitz Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210617100544.41a5a5a894fa.I9eabb76e7a3a7f4abbed8f2ef918f1df8e825726@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin

iwlwifi: mvm: apply RX diversity per PHY context

2021-07-19T08:01:05Z

[ Upstream commit a171399fd687a7d2fa56a10c9a2d7084a647677d ] SMPS requests may differ per interfaces due to e.g. Bluetooth only interfering on 2.4 GHz, so if that's the case we should, in the case of multiple PHY contexts, still allow RX diversity on PHY context that have no interfaces with SMPS requests. Fix the code to pass through the PHY context in question and skip interfaces with non-matching PHY context while iterating. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210617100544.123c6b05809d.I992e3d1c6a29850d02eeec01712b5b685b963a87@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin

iwlwifi: mvm: don't change band on bound PHY contexts

2021-07-19T08:01:05Z

[ Upstream commit 8835a64f74c46baebfc946cd5a2c861b866ebcee ] When we have a P2P Device active, we attempt to only change the PHY context it uses when we get a new remain-on-channel, if the P2P Device is the only user of the PHY context. This is fine if we're switching within a band, but if we're switching bands then the switch implies a removal and re-add of the PHY context, which isn't permitted by the firmware while it's bound to an interface. Fix the code to skip the unbind/release/... cycle only if the band doesn't change (or we have old devices that can switch the band on the fly as well.) Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210612142637.e9ac313f70f3.I713b9d109957df7e7d9ed0861d5377ce3f8fccd3@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin

iwlwifi: increase PNVM load timeout

2021-07-14T14:59:59Z

[ Upstream commit 5cc816ef9db1fe03f73e56e9d8f118add9c6efe4 ] The FW has a watchdog of 200ms in the PNVM load flow, so the driver should have a slightly higher timeout. Change the timeout from 100ms to 250ms. Signed-off-by: Luca Coelho Fixes: 70d3ca86b025 ("iwlwifi: mvm: ring the doorbell and wait for PNVM load completion") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210612142637.ba22aec1e2be.I36bfadc28c480f4fc57266c075a79e8ea4a6934f@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin

mac80211: remove iwlwifi specific workaround that broke sta NDP tx

2021-07-14T14:59:07Z

commit e41eb3e408de27982a5f8f50b2dd8002bed96908 upstream. Sending nulldata packets is important for sw AP link probing and detecting 4-address mode links. The checks that dropped these packets were apparently added to work around an iwlwifi firmware bug with multi-TID aggregation. Fixes: 41cbb0f5a295 ("mac80211: add support for HE") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20210619101517.90806-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

iwlwifi: trans/pcie: defer transport initialisation

2021-05-19T08:56:16Z

[ Upstream commit d12455fdbfe9430affd88bfbfee51777356667a0 ] In a few PCIe devices we may have to swap out the configuration after we allocate/initialise some parts of the device because we only know the correct one after reading some registers. This causes some things such as the byte-count table allocations to be incorrect, since the configuration is swapped for one with a bigger queue size. Fix this by initialising most of the transport much later, only after the configuration has finally been determined. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210411132130.8f5db97db1e4.Ic622da559b586a04ca536a0ec49ed5ecf03a9354@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin

iwlwifi: queue: avoid memory leak in reset flow

2021-05-19T08:56:16Z

[ Upstream commit 4cf2f5904d971a461f67825434ae3c31900ff84b ] In case the device is stopped any usage of hw queues needs to be reallocated in fw due to fw reset after device stop, so all driver internal queue should also be freed, and if we don't free the next usage would leak the old memory and get in recover flows "iwlwifi 0000:00:03.0: dma_pool_destroy iwlwifi:bc" warning. Also warn about trying to reuse an internal allocated queue. Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210411124417.c72d2f0355c4.Ia3baff633b9b9109f88ab379ef0303aa152c16bf@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin

iwlwifi: pcie: make cfg vs. trans_cfg more robust

2021-05-19T08:56:16Z

[ Upstream commit 48a5494d6a4cb5812f0640d9515f1876ffc7a013 ] If we (for example) have a trans_cfg entry in the PCI IDs table, but then don't find a full cfg entry for it in the info table, we fall through to the code that treats the PCI ID table entry as a full cfg entry. This obviously causes crashes later, e.g. when trying to build the firmware name string. Avoid such crashes by using the low bit of the pointer as a tag for trans_cfg entries (automatically using a macro that checks the type when assigning) and then checking that before trying to use the data as a full entry - if it's just a partial entry at that point, fail. Since we're adding some macro magic, also check that the type is in fact either struct iwl_cfg_trans_params or struct iwl_cfg, failing compilation ("initializer element is not constant") if it isn't. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210330162204.6f69fe6e4128.I921d4ae20ef5276716baeeeda0b001cf25b9b968@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin