linux-stable.git/drivers/net, branch v4.8.6 Linux kernel stable tree iwlwifi: mvm: bail out if CTDP start operation fails 2016-10-31T11:02:14+00:00 Luca Coelho luciano.coelho@intel.com 2016-09-14T08:54:36+00:00 935c26d0fc449ed8803c27c340a3cc552961edab commit 75cfe338b8a6fadaa28879a969047554701a7589 upstream. We were assigning the return value of iwl_mvm_ctdp_command() to a variable, but never checking it. If this command fails, we should not allow the interface up process to proceed, since it is potentially dangerous to ignore thermal management requirements. Fixes: commit 5c89e7bc557e ("iwlwifi: mvm: add registration to cooling device") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 75cfe338b8a6fadaa28879a969047554701a7589 upstream.

We were assigning the return value of iwl_mvm_ctdp_command() to a
variable, but never checking it.  If this command fails, we should not
allow the interface up process to proceed, since it is potentially
dangerous to ignore thermal management requirements.

Fixes: commit 5c89e7bc557e ("iwlwifi: mvm: add registration to cooling device")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: mvm: disable P2P queue on mac context release 2016-10-31T11:02:14+00:00 Sara Sharon sara.sharon@intel.com 2016-08-18T17:14:38+00:00 e1a322b9dab0280f5bd8f7e00e81d7ecee6c2b7a commit 341d7eb8223bdd48bdf75729487a2de5e01623b3 upstream. AP queue is properly released, but P2P queue isn't. Fixes: commit 4c965139a3cd ("iwlwifi: mvm: support p2p device frames tx on dqa queue #2") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 341d7eb8223bdd48bdf75729487a2de5e01623b3 upstream.

AP queue is properly released, but P2P queue isn't.

Fixes: commit 4c965139a3cd ("iwlwifi: mvm: support p2p device frames tx on dqa queue #2")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: mvm: support BAR in reorder buffer 2016-10-31T11:02:14+00:00 Sara Sharon sara.sharon@intel.com 2016-08-08T10:07:01+00:00 4dfdaf3433a8d9d5c418e8dfebe74eb0414a974d commit 9a73a7d24d51eaf9e43c771c53cf7b594e5b5334 upstream. On default queue we will not receive frame release notification, but the BAR itself. Upon receiving the BAR driver should look at the NSSN and adjust window accordingly. Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 9a73a7d24d51eaf9e43c771c53cf7b594e5b5334 upstream.

On default queue we will not receive frame release notification,
but the BAR itself.
Upon receiving the BAR driver should look at the NSSN and adjust
window accordingly.

Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: mvm: free reserved queue on STA removal 2016-10-31T11:02:14+00:00 Liad Kaufman liad.kaufman@intel.com 2016-07-07T10:25:59+00:00 3eb8b9e6f5c1f38e159e7853a0d9a44b8d8eac8e commit a0315dea9091d1ebc1534f6129b3fc9942b8ca99 upstream. When a STA is removed in DQA mode, if no traffic went through its reserved queue, the txq continues to be marked as reserved and no STA can use it. Make sure that in such a case the reserved queue is marked as free when the STA is removed. Fixes: commit 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues") Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a0315dea9091d1ebc1534f6129b3fc9942b8ca99 upstream.

When a STA is removed in DQA mode, if no traffic went through
its reserved queue, the txq continues to be marked as
reserved and no STA can use it.

Make sure that in such a case the reserved queue is marked
as free when the STA is removed.

Fixes: commit 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues")
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: mvm: call a different txq_enable function 2016-10-31T11:02:13+00:00 Sara Sharon sara.sharon@intel.com 2016-06-30T13:14:02+00:00 e294beae968b4a5615f3219c77cd2d9cb148bcd3 commit ca3b9c6b6d4db9a8ba5fc8b95664e75468c59f9f upstream. Since the SCD_QUEUE_CFG command was introduced the driver calls iwl_trans_txq_enable_cfg() with a NULL for scd_cfg parameter. This makes the transport avoid writing to the SCD pointers, since it can cause races with firmware, which is also accessing the registers. The transport only updates the write pointer in that case. Fix a wrong call to iwl_trans_txq_enable() which caused a scd_cfg parameter to be sent to transport, resulting with an access to SCD registers. Fixes: 58f2cc57dc6a ("iwlwifi: mvm: support dqa-mode scd queue redirection") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ca3b9c6b6d4db9a8ba5fc8b95664e75468c59f9f upstream.

Since the SCD_QUEUE_CFG command was introduced the driver
calls iwl_trans_txq_enable_cfg() with a NULL for scd_cfg
parameter.
This makes the transport avoid writing to the SCD pointers,
since it can cause races with firmware, which is also accessing
the registers.
The transport only updates the write pointer in that case.
Fix a wrong call to iwl_trans_txq_enable() which caused a
scd_cfg parameter to be sent to transport, resulting with an
access to SCD registers.

Fixes: 58f2cc57dc6a ("iwlwifi: mvm: support dqa-mode scd queue redirection")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: mvm: fix pending frames tracking on tx resp 2016-10-31T11:02:13+00:00 Liad Kaufman liad.kaufman@intel.com 2016-07-07T08:00:26+00:00 c8058c456d48b6a12d6ae1aff055473ed68dbe2a commit 7585c354637bb003ce612dd22f5047c015545ef4 upstream. In iwl_mvm_rx_tx_cmd_single(), when checking if a given TID is aggregated, the driver doesn't check whether or not the queue itself can be aggregated. For example, a management queue might be marked as aggregated if TID 0 is aggregated on a (different) data queue. Make sure that mgmt frames are sent with TID IWL_TID_NON_QOS, and in this way make sure no mixups of this sort happen. Fixes: commit 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues") Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7585c354637bb003ce612dd22f5047c015545ef4 upstream.

In iwl_mvm_rx_tx_cmd_single(), when checking if a given TID is
aggregated, the driver doesn't check whether or not the queue
itself can be aggregated. For example, a management queue might
be marked as aggregated if TID 0 is aggregated on a (different)
data queue.

Make sure that mgmt frames are sent with TID IWL_TID_NON_QOS,
and in this way make sure no mixups of this sort happen.

Fixes: commit 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues")
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: check for valid ethernet address provided by OEM 2016-10-31T11:02:13+00:00 Haim Dreyfuss haim.dreyfuss@intel.com 2016-08-02T12:28:23+00:00 8a0b49af92c655b72f37bb445a3b8748de1160dc commit a6c934b364948cd4de5bd9ab055bb65206ec70f3 upstream. In 9000 family products we added an option to let the OEM fuse the mac address via registers. If these registers are zeroed we use the OTP address instead. Make sure that the address provided by the OEM is valid and, if not, fall back to the OTP address as well. Fixes: commit 17c867bfe89b ("iwlwifi: add support for getting HW address from CSR") Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a6c934b364948cd4de5bd9ab055bb65206ec70f3 upstream.

In 9000 family products we added an option to let the OEM fuse the
mac address via registers. If these registers are zeroed we use the OTP
address instead. Make sure that the address provided by the OEM is valid
and, if not, fall back to the OTP address as well.

Fixes: commit 17c867bfe89b ("iwlwifi: add support for getting HW address from CSR")
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ath10k: fix throughput regression in multi client mode 2016-10-31T11:02:09+00:00 Rajkumar Manoharan rmanohar@qti.qualcomm.com 2016-09-02T16:46:10+00:00 f163372f569bf80fd3d14bcedb1a31aa1f954a1d commit 18f53fe0f30331e826b075709ed7b26b9283235e upstream. commit 7a0adc83f34d ("ath10k: improve tx scheduling") is causing severe throughput drop in multi client mode. This issue is originally reported in veriwave setup with 50 clients with TCP downlink traffic. While increasing number of clients, the average throughput drops gradually. With 50 clients, the combined peak throughput is decreased to 98 Mbps whereas reverting given commit restored it to 550 Mbps. Processing txqs for every tx completion is causing overhead. Ideally for management frame tx completion, pending txqs processing can be avoided. The change partly reverts the commit "ath10k: improve tx scheduling". Processing pending txqs after all skbs tx completion will yeild enough room to burst tx frames. Fixes: 7a0adc83f34d ("ath10k: improve tx scheduling") Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 18f53fe0f30331e826b075709ed7b26b9283235e upstream.

commit 7a0adc83f34d ("ath10k: improve tx scheduling") is causing
severe throughput drop in multi client mode. This issue is originally
reported in veriwave setup with 50 clients with TCP downlink traffic.
While increasing number of clients, the average throughput drops
gradually. With 50 clients, the combined peak throughput is decreased
to 98 Mbps whereas reverting given commit restored it to 550 Mbps.

Processing txqs for every tx completion is causing overhead. Ideally for
management frame tx completion, pending txqs processing can be avoided.
The change partly reverts the commit "ath10k: improve tx scheduling".
Processing pending txqs after all skbs tx completion will yeild enough
room to burst tx frames.

Fixes: 7a0adc83f34d ("ath10k: improve tx scheduling")
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ath10k: fix reporting channel survey data 2016-10-31T11:02:09+00:00 Ashok Raj Nagarajan arnagara@qti.qualcomm.com 2016-09-02T05:29:53+00:00 7acf11980844be117549b306e2f2c713b97dcbc1 commit 77eb3d693182b4eaa88c6ba406fbb92b1f1bd636 upstream. When user requests for survey dump data, driver is providing wrong survey information. This information we sent is the survey data that we have collected during previous user request. This issue occurs because we request survey dump for wrong channel. With this change, we correctly display the correct and current survey information to userspace. Fixes: fa7937e3d5c2 ("ath10k: update bss channel survey information") Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 77eb3d693182b4eaa88c6ba406fbb92b1f1bd636 upstream.

When user requests for survey dump data, driver is providing wrong survey
information. This information we sent is the survey data that we have
collected during previous user request.

This issue occurs because we request survey dump for wrong channel. With
this change, we correctly display the correct and current survey
information to userspace.

Fixes: fa7937e3d5c2 ("ath10k: update bss channel survey information")
Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ath10k: fix sending frame in management path in push txq logic 2016-10-31T11:02:09+00:00 Ashok Raj Nagarajan arnagara@qti.qualcomm.com 2016-08-18T10:00:04+00:00 4464c51c0cd00b1ef2e4959175b2e1729a1f7452 commit e4fd726f21cdae0dc9cea6cbfcb7e27f21393f88 upstream. In the wake tx queue path, we are not checking if the frame to be sent takes management path or not. For eg. QOS null func frame coming here will take the management path. Since we are not incrementing the descriptor counter (num_pending_mgmt_tx) w.r.t tx management, on tx completion it is possible to see negative values. When the above counter reaches a negative value, we will not be sending a probe response out. if (is_presp && ar->hw_params.max_probe_resp_desc_thres < htt->num_pending_mgmt_tx) For IPQ4019, max_probe_resp_desc_thres (u32) is 24 is compared against num_pending_mgmt_tx (int) and the above condtions comes true if the counter is negative and we drop the probe response. To avoid this, check on the wake tx queue path as well for the tx path of the frame and increment the appropriate counters Fixes: cac085524cf1 "ath10k: move mgmt descriptor limit handle under mgmt_tx" Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e4fd726f21cdae0dc9cea6cbfcb7e27f21393f88 upstream.

In the wake tx queue path, we are not checking if the frame to be sent
takes management path or not. For eg. QOS null func frame coming here will
take the management path. Since we are not incrementing the descriptor
counter (num_pending_mgmt_tx) w.r.t tx management, on tx completion it is
possible to see negative values.

When the above counter reaches a negative value, we will not be sending a
probe response out.

    if (is_presp &&
	ar->hw_params.max_probe_resp_desc_thres < htt->num_pending_mgmt_tx)

For IPQ4019, max_probe_resp_desc_thres (u32) is 24 is compared against
num_pending_mgmt_tx (int) and the above condtions comes true if the counter
is negative and we drop the probe response.

To avoid this, check on the wake tx queue path as well for the tx path of
the frame and increment the appropriate counters

Fixes: cac085524cf1 "ath10k: move mgmt descriptor limit handle under mgmt_tx"
Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>