linux-stable.git/drivers/net/wireless/intel, branch v5.1.7

iwlwifi: mvm: IBSS: use BE FIFO for multicast

2019-05-31T13:43:42+00:00

[ Upstream commit 192a7e1f731fd9a64216cce35287eb23360437f6 ]

Back in commit 4d339989acd7 ("iwlwifi: mvm: support ibss in dqa mode")
we changed queue selection for IBSS to be:

    if (ieee80211_is_probe_resp(fc) || ieee80211_is_auth(fc) ||
        ieee80211_is_deauth(fc))
            return IWL_MVM_DQA_AP_PROBE_RESP_QUEUE;
    if (info->hw_queue == info->control.vif->cab_queue)
            return info->hw_queue;
    return IWL_MVM_DQA_AP_PROBE_RESP_QUEUE;

Clearly, the thought at the time must've been that mac80211 will
select the hw_queue as the cab_queue, so that we'll return and use
that, where we store the multicast queue for IBSS. This, however,
isn't true because mac80211 doesn't implement powersave for IBSS
and thus selects the normal IBSS interface AC queue (best effort).

This therefore always used the probe response queue, which maps to
the BE FIFO.

In commit cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model")
we rethought this code, and as a consequence now started mapping the
multicast traffic to the multicast hardware queue since we no longer
relied on mac80211 selecting the queue, doing it ourselves instead.
This queue is mapped to the MCAST FIFO. however, this isn't actually
enabled/controlled by the firmware in IBSS mode because we don't
implement powersave, and frames from this queue can never go out in
this case.

Therefore, we got queue hang reports such as
https://bugzilla.kernel.org/show_bug.cgi?id=201707

Fix this by mapping the multicast queue to the BE FIFO in IBSS so
that all the frames can go out.

Fixes: cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model")
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin

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

2019-05-31T13:43:20+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: mvm: fix merge damage in iwl_mvm_vif_dbgfs_register()

2019-04-28T06:59:59+00:00

When I rebased Greg's patch, I accidentally left the old if block that
was already there.  Remove it.

Fixes: 154d4899e411 ("iwlwifi: mvm: properly check debugfs dentry before using it")
Signed-off-by: Luca Coelho

iwlwifi: fix driver operation for 5350

2019-04-28T06:59:59+00:00

We introduced a bug that prevented this old device from
working. The driver would simply not be able to complete
the INIT flow while spewing this warning:

 CSR addresses aren't configured
 WARNING: CPU: 0 PID: 819 at drivers/net/wireless/intel/iwlwifi/pcie/drv.c:917
 iwl_pci_probe+0x160/0x1e0 [iwlwifi]

Cc: stable@vger.kernel.org # v4.18+
Fixes: a8cbb46f831d ("iwlwifi: allow different csr flags for different device families")
Signed-off-by: Emmanuel Grumbach 
Fixes: c8f1b51e506d ("iwlwifi: allow different csr flags for different device families")
Signed-off-by: Luca Coelho

iwlwifi: mvm: check for length correctness in iwl_mvm_create_skb()

2019-04-28T06:59:59+00:00

We don't check for the validity of the lengths in the packet received
from the firmware.  If the MPDU length received in the rx descriptor
is too short to contain the header length and the crypt length
together, we may end up trying to copy a negative number of bytes
(headlen - hdrlen < 0) which will underflow and cause us to try to
copy a huge amount of data.  This causes oopses such as this one:

BUG: unable to handle kernel paging request at ffff896be2970000
PGD 5e201067 P4D 5e201067 PUD 5e205067 PMD 16110d063 PTE 8000000162970161
Oops: 0003 [#1] PREEMPT SMP NOPTI
CPU: 2 PID: 1824 Comm: irq/134-iwlwifi Not tainted 4.19.33-04308-geea41cf4930f #1
Hardware name: [...]
RIP: 0010:memcpy_erms+0x6/0x10
Code: 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1  a4 c3
 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe
RSP: 0018:ffffa4630196fc60 EFLAGS: 00010287
RAX: ffff896be2924618 RBX: ffff896bc8ecc600 RCX: 00000000fffb4610
RDX: 00000000fffffff8 RSI: ffff896a835e2a38 RDI: ffff896be2970000
RBP: ffffa4630196fd30 R08: ffff896bc8ecc600 R09: ffff896a83597000
R10: ffff896bd6998400 R11: 000000000200407f R12: ffff896a83597050
R13: 00000000fffffff8 R14: 0000000000000010 R15: ffff896a83597038
FS:  0000000000000000(0000) GS:ffff896be8280000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff896be2970000 CR3: 000000005dc12002 CR4: 00000000003606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 iwl_mvm_rx_mpdu_mq+0xb51/0x121b [iwlmvm]
 iwl_pcie_rx_handle+0x58c/0xa89 [iwlwifi]
 iwl_pcie_irq_rx_msix_handler+0xd9/0x12a [iwlwifi]
 irq_thread_fn+0x24/0x49
 irq_thread+0xb0/0x122
 kthread+0x138/0x140
 ret_from_fork+0x1f/0x40

Fix that by checking the lengths for correctness and trigger a warning
to show that we have received wrong data.

Signed-off-by: Luca Coelho

iwlwifi: cfg: use family 22560 based_params for AX210 family

2019-04-18T12:06:44+00:00

Specifically, max_tfd_queue_size should be 0x10000 like in
22560 family and not 0x100 like in 22000 family.

Signed-off-by: Shaul Triebitz 
Signed-off-by: Luca Coelho

iwlwifi: mvm: properly check debugfs dentry before using it

2019-04-18T12:06:44+00:00

debugfs can now report an error code if something went wrong instead of
just NULL.  So if the return value is to be used as a "real" dentry, it
needs to be checked if it is an error before dereferencing it.

This is now happening because of ff9fb72bc077 ("debugfs: return error
values, not NULL").  If multiple iwlwifi devices are in the system, this
can cause problems when the driver attempts to create the main debugfs
directory again.  Later on in the code we fail horribly by trying to
dereference a pointer that is an error value.

Reported-by: Laura Abbott 
Reported-by: Gabriel Ramirez 
Cc: Johannes Berg 
Cc: Emmanuel Grumbach 
Cc: Luca Coelho 
Cc: Intel Linux Wireless 
Cc: Kalle Valo 
Cc: stable  # 5.0
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Luca Coelho

iwlwifi: dbg_ini: check debug TLV type explicitly

2019-04-18T11:07:39+00:00

In ini debug TLVs bit 24 is set. The driver relies on it in the memory
allocation for the debug configuration. This implementation is
problematic in case of a new debug TLV that is not supported yet is added
and uses bit 24. In such a scenario the driver allocate space without
using it which causes errors in the apply point enabling flow.

Solve it by explicitly checking if a given TLV is part of the list of
the supported ini debug TLVs.

Signed-off-by: Shahar S Matityahu 
Fixes: f14cda6f3b31 ("iwlwifi: trans: parse and store debug ini TLVs")
Signed-off-by: Luca Coelho

iwlwifi: mvm: don't attempt debug collection in rfkill

2019-04-18T11:07:39+00:00

If we fail to initialize because rfkill is enabled, then trying
to do debug collection currently just fails. Prevent that in the
high-level code, although we should probably also fix the lower
level code to do things more carefully.

It's not 100% clear that it fixes this commit, as the original
dump code at the time might've been more careful. In any case,
we don't really need to dump anything in this expected scenario.

Signed-off-by: Johannes Berg 
Fixes: 7125648074e8 ("iwlwifi: add fw dump upon RT ucode start failure")
Signed-off-by: Luca Coelho

iwlwifi: don't panic in error path on non-msix systems

2019-04-18T11:07:39+00:00

The driver uses msix causes-register to handle both msix and non msix
interrupts when performing sync nmi.  On devices that do not support
msix this register is unmapped and accessing it causes a kernel panic.

Solve this by differentiating the two cases and accessing the proper
causes-register in each case.

Reported-by: Michal Hocko 
Signed-off-by: Shahar S Matityahu 
Signed-off-by: Luca Coelho