linux/drivers/net/wireless/intel, branch v5.5

Merge tag 'wireless-drivers-2020-01-23' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers

2020-01-23T13:30:20Z

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

net: Fix packet reordering caused by GRO and listified RX cooperation

2020-01-22T19:36:37Z

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 Cc: Alexander Lobakin Cc: Edward Cree Acked-by: Alexander Lobakin Acked-by: Saeed Mahameed Acked-by: Edward Cree Signed-off-by: David S. Miller

iwlwifi: mvm: don't send the IWL_MVM_RXQ_NSSN_SYNC notif to Rx queues

2020-01-22T17:13:28Z

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: # 5.3+ Signed-off-by: Emmanuel Grumbach Signed-off-by: Kalle Valo

Revert "iwlwifi: mvm: fix scan config command size"

2019-12-30T13:43:40Z

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 [ Luca: reworded the commit message a bit. ] Signed-off-by: Luca Coelho

iwlwifi: fw: make pos static in iwl_sar_get_ewrd_table() loop

2019-12-23T23:34:52Z

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 Signed-off-by: Luca Coelho Fixes: ba3224db7803 ("iwlwifi: mvm: fix an out-of-bound access") Signed-off-by: Luca Coelho

iwlwifi: remove lar_disable module parameter

2019-12-23T23:34:52Z

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

iwlwifi: dbg: force stop the debug monitor HW

2019-12-23T23:34:52Z

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 Signed-off-by: Luca Coelho

iwlwifi: pcie: always disable L0S states

2019-12-23T23:34:52Z

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

iwlwifi: pcie: rename L0S_ENABLED bit to L0S_DISABLED

2019-12-23T23:34:52Z

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

iwlwifi: mvm: fix potential SKB leak on TXQ TX

2019-12-23T23:34:52Z

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 Fixes: cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model") Signed-off-by: Luca Coelho