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

iwlwifi: a000: fix memory offsets and lengths

2018-03-24T10:00:11+00:00

[ Upstream commit f4d1047914ea05e0f8393944da18f6ee5dad24c4 ]

Memory offsets and lengths for A000 HW is different
than currently specified.

Fixes: e34d975e40ff ("iwlwifi: Add a000 HW family support")
Signed-off-by: Liad Kaufman 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: split the handler and the wake parts of the notification infra

2018-03-24T10:00:11+00:00

[ Upstream commit 2220fb2960b72915e7fd9da640a4695dceff238c ]

The notification infrastructure (iwl_notification_wait_*
functions) allows to wait until a list of notifications
will come up from the firmware and to run a special handler
(notif_wait handler) when those are received.

The operation mode notifies the notification infrastructure
about any Rx being received by the mean of
iwl_notification_wait_notify() which will do two things:
1) call the notif_wait handler
2) wakeup the thread that was waiting for the notification

Typically, only after those two steps happened, the
operation mode will run its own handler for the notification
that was received from the firmware. This means that the
thread that was waiting for that notification can be
running before the operation mode's handler was called.

When the operation mode's handler is ASYNC, things get even
worse since the thread that was waiting for the
notification isn't even guaranteed that the ASYNC callback
was added to async_handlers_list before it starts to run.
This means that even calling
iwl_mvm_wait_for_async_handlers() can't guarantee that
absolutely everything related to that notification has run.
The following can happen:

Thread sending the command        Operation mode's Rx path
--------------------------        ------------------------
iwl_init_notification_wait()
iwl_mvm_send_cmd()
                                  iwl_mvm_rx_common()
                                  iwl_notification_wait_notify()
iwl_mvm_wait_for_async_handlers()
// Possibly free some data
// structure
                                  list_add_tail(async_handlers_list);
                                  schedule_work(async_handlers_wk);
                                  // Access the freed structure

Split the 'run notif_wait's handler' and the 'wake up the
thread' parts to fix this. This allows the operation mode
to do the following:

Thread sending the command        Operation mode's Rx path
--------------------------        ------------------------
iwl_init_notification_wait()
iwl_mvm_send_cmd()
                                  iwl_mvm_rx_common()
                                  iwl_notification_wait()
                                  // Will run the notif_wait's handler
                                  list_add_tail(async_handlers_list);
                                  schedule_work(async_handlers_wk);
                                  iwl_notification_notify()
iwl_mvm_wait_for_async_handlers()

This way, the waiter is guaranteed that all the handlers
have been run (if SYNC), or at least enqueued (if ASYNC)
by the time it wakes up.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: rs: don't override the rate history in the search cycle

2018-03-22T08:17:53+00:00

[ Upstream commit 992172e3aec19e5b0ea5b757ba40a146b9282d1e ]

When we are in a search cycle, we try different combinations
of parameters. Those combinations are called 'columns'.
When we switch to a new column, we first need to check if
this column has a suitable rate, if not, we can't try it.
This means we must not erase the statistics we gathered
for the previous column until we are sure that we are
indeed switching column.

The code that tries to switch to a new column first sets
a whole bunch of things for the new column, and only then
checks that we can find suitable rates in that column.
While doing that, the code mistakenly erased the rate
statistics. This code was right until
struct iwl_scale_tbl_info grew up for TPC.

Fix this to make sure we don't erase the rate statistics
until we are sure that we can indeed switch to the new
column.

Note that this bug is really harmless since it causes a
change in the behavior only when we can't find any rate
in the new column which should really not happen. In the
case we do find a suitable we reset the rate statistics
a few lines later anyway.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: fix RX SKB header size and align it properly

2018-03-22T08:17:51+00:00

[ Upstream commit 5cddd05c9cbe420436799716d009bc0372ef8268 ]

When receiving a frame, we currently pull in sizeof(*hdr) plus
some extra (crypto/snap), which is too much, most headers aren't
actually sizeof(*hdr) since that takes into account the 4-address
format but doesn't take into account QoS. As a result, a typical
frame will have 4 bytes of the payload in the SKB header already.

Fix this by calculating the correct header length, and now that
we have that, align the end of the SKB header to a multiple of 4
so that the IP header will be aligned properly when pulled in.

Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type

2018-02-03T16:05:41+00:00

[ Upstream commit d1b275ffec459c5ae12b5c7086c84175696e5a9f ]

The MONITOR type is missing in the interface type switch.
Add it.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: cleanup pending frames in DQA mode

2017-12-20T09:07:23+00:00

[ Upstream commit 9a3fcf912ef7f5c6e18f9af6875dd13f7311f7aa ]

When a station is asleep, the fw will set it as "asleep".
All queues that are used only by one station will be stopped by
the fw.

In pre-DQA mode this was relevant for aggregation queues. However,
in DQA mode a queue is owned by one station only, so all queues
will be stopped.
As a result, we don't expect to get filtered frames back to
mac80211 and don't have to maintain the entire pending_frames
state logic, the same way as we do in aggregations.

The correct behavior is to align DQA behavior with the aggregation
queue behaviour pre-DQA:
- Don't count pending frames.
- Let mac80211 know we have frames in these queues so that it can
properly handle trigger frames.

When a trigger frame is received, mac80211 tells the driver to send
frames from the queues using release_buffered_frames.
The driver will tell the fw to let frames out even if the station
is asleep. This is done by iwl_mvm_sta_modify_sleep_tx_count.

Reported-and-tested-by: Jens Axboe 
Reported-by: Linus Torvalds 
Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: use the PROBE_RESP_QUEUE to send deauth to unknown station

2017-11-08T09:08:35+00:00

[ Upstream commit d45cb20e123c5d7d6cd56301bc98f0bfd725cd77 ]

When we send a deauth to a station we don't know about, we
need to use the PROBE_RESP queue. This can happen when we
send a deauth to a station that is not associated to us.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: add workaround to disable wide channels in 5GHz

2017-10-12T09:51:25+00:00

commit 01a9c948a09348950515bf2abb6113ed83e696d8 upstream.

The OTP in some SKUs have erroneously allowed 40MHz and 80MHz channels
in the 5.2GHz band.  The firmware has been modified to not allow this
in those SKUs, so the driver needs to do the same otherwise the
firmware will assert when we try to use it.

Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD

2017-10-12T09:51:25+00:00

commit 97bce57bd7f96e1218751996f549a6e61f18cc8c upstream.

The MCAST_FILTER_CMD can get quite large when we have many mcast
addresses to set (we support up to 255).  So the command should be
send as NOCOPY to prevent a warning caused by too-long commands:

WARNING: CPU: 0 PID: 9700 at /root/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/pcie/tx.c:1550 iwl_pcie_enqueue_hcmd+0x8c7/0xb40 [iwlwifi]
Command MCAST_FILTER_CMD (0x1d0) is too large (328 bytes)

This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196743

Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pci: add new PCI ID for 7265D

2017-09-09T15:39:40+00:00

commit 3f7a5e13e85026b6e460bbd6e87f87379421d272 upstream.

We have a new PCI subsystem ID for 7265D.  Add it to the list.

Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman