linux-stable.git/drivers/net/wireless/intel, branch v4.9.210

iwlwifi: check kasprintf() return value

2020-01-04T12:40:04+00:00

[ Upstream commit 5974fbb5e10b018fdbe3c3b81cb4cc54e1105ab9 ]

kasprintf() can fail, we should check the return value.

Fixes: 5ed540aecc2a ("iwlwifi: use mac80211 throughput trigger")
Fixes: 8ca151b568b6 ("iwlwifi: add the MVM driver")
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin

iwlwifi: mvm: fix unaligned read of rx_pkt_status

2020-01-04T12:39:58+00:00

[ Upstream commit c5aaa8be29b25dfe1731e9a8b19fd91b7b789ee3 ]

This is present since the introduction of iwlmvm.
Example stack trace on MIPS:

[] iwl_mvm_rx_rx_mpdu+0xa8/0xb88 [iwlmvm]
[] iwl_pcie_rx_handle+0x420/0xc48 [iwlwifi]

Tested with a Wireless AC 7265 for ~6 months, confirmed to fix the
problem. No other unaligned accesses are spotted yet.

Signed-off-by: Wang Xuerui 
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

iwlwifi: mvm: Send non offchannel traffic via AP sta

2019-12-21T09:40:52+00:00

[ Upstream commit dc1aca22f8f38b7e2ad7b118db87404d11e68771 ]

TDLS discovery response frame is a unicast direct frame to the peer.
Since we don't have a STA for this peer, this frame goes through
iwl_tx_skb_non_sta(). As the result aux_sta and some completely
arbitrary queue would be selected for this frame, resulting in a queue
hang.  Fix that by sending such frames through AP sta instead.

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin

iwlwifi: mvm: don't send keys when entering D3

2019-11-25T08:53:40+00:00

[ Upstream commit 8c7fd6a365eb5b2647b2c01918730d0a485b9f85 ]

In the past, we needed to program the keys when entering D3. This was
since we replaced the image. However, now that there is a single
image, this is no longer needed.  Note that RSC is sent separately in
a new command.  This solves issues with newer devices that support PN
offload. Since driver re-sent the keys, the PN got zeroed and the
receiver dropped the next packets, until PN caught up again.

Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin

iwlwifi: mvm: avoid sending too many BARs

2019-11-25T08:52:05+00:00

[ Upstream commit 1a19c139be18ed4d6d681049cc48586fae070120 ]

When we receive TX response, we may release a few packets
due to a hole that was closed in the transmission window.

However, if that frame failed, we will mark all the released
frames as failed and will send multiple BARs.

This affects statistics badly, and cause unnecessary frames
transmission.

Instead, mark all the following packets as success, with the
desired result of sending a bar for the failed frame only.

Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin

iwlwifi: don't unmap as page memory that was mapped as single

2019-08-25T08:51:39+00:00

commit 87e7e25aee6b59fef740856f4e86d4b60496c9e1 upstream.

In order to remember how to unmap a memory (as single or
as page), we maintain a bit per Transmit Buffer (TBs) in
the meta data (structure iwl_cmd_meta).
We maintain a bitmap: 1 bit per TB.
If the TB is set, we will free the memory as a page.
This bitmap was never cleared. Fix this.

Cc: stable@vger.kernel.org
Fixes: 3cd1980b0cdf ("iwlwifi: pcie: introduce new tfd and tb formats")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: don't service an interrupt that was masked

2019-08-04T07:33:26+00:00

commit 3b57a10ca14c619707398dc58fe5ece18c95b20b upstream.

Sometimes the register status can include interrupts that
were masked. We can, for example, get the RF-Kill bit set
in the interrupt status register although this interrupt
was masked. Then if we get the ALIVE interrupt (for example)
that was not masked, we need to *not* service the RF-Kill
interrupt.
Fix this in the MSI-X interrupt handler.

Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: Drop large non sta frames

2019-08-04T07:33:23+00:00

[ Upstream commit ac70499ee97231a418dc1a4d6c9dc102e8f64631 ]

In some buggy scenarios we could possible attempt to transmit frames larger
than maximum MSDU size. Since our devices don't know how to handle this,
it may result in asserts, hangs etc.
This can happen, for example, when we receive a large multicast frame
and try to transmit it back to the air in AP mode.
Since in a legal scenario this should never happen, drop such frames and
warn about it.

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin

iwlwifi: pcie: don't crash on invalid RX interrupt

2019-05-31T13:48:15+00:00

[ Upstream commit 30f24eabab8cd801064c5c37589d803cb4341929 ]

If for some reason the device gives us an RX interrupt before we're
ready for it, perhaps during device power-on with misconfigured IRQ
causes mapping or so, we can crash trying to access the queues.

Prevent that by checking that we actually have RXQs and that they
were properly allocated.

Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin

iwlwifi: pcie: fix emergency path

2019-04-05T20:29:11+00:00

[ Upstream commit c6ac9f9fb98851f47b978a9476594fc3c477a34d ]

Allocator swaps the pending requests with 0 when it starts
working. This means that relying on it n RX path to decide if
to move to emergency is not always a good idea, since it may
be zero, but there are still a lot of unallocated RBs in the
system. Change allocator to decrement the pending requests on
real time. It is more expensive since it accesses the atomic
variable more times, but it gives the RX path a better idea
of the system's status.

Reported-by: Ilan Peer 
Signed-off-by: Sara Sharon 
Fixes: 868a1e863f95 ("iwlwifi: pcie: avoid empty free RB queue")
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin