summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c
AgeCommit message (Collapse)Author
2019-04-12rt2x00: do not increment sequence number while re-transmittingVijayakumar Durai
Currently rt2x00 devices retransmit the management frames with incremented sequence number if hardware is assigning the sequence. This is HW bug fixed already for non-QOS data frames, but it should be fixed for management frames except beacon. Without fix retransmitted frames have wrong SN: AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1648, FN=0, Flags=........C Frame is not being retransmitted 1648 1 AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1649, FN=0, Flags=....R...C Frame is being retransmitted 1649 1 AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1650, FN=0, Flags=....R...C Frame is being retransmitted 1650 1 With the fix SN stays correctly the same: 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=........C 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=....R...C 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=....R...C Cc: stable@vger.kernel.org Signed-off-by: Vijayakumar Durai <vijayakumar.durai1@vivint.com> [sgruszka: simplify code, change comments and changelog] Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-01rt2x00: use different txstatus timeouts when flushingStanislaw Gruszka
Use different tx status timeouts for normal operation and when flushing. This increase timeout to 2s for normal operation as when there are bad radio conditions and frames are reposted many times device can not provide the status for quite long. With new timeout we can still get valid status on such bad conditions. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-07-31rt2x00: remove redundant functions rt2x00mac_sta_{add/remove}YueHaibing
Only rt2800 subdriver of rt2x00 implement sta_add() and sta_remove(), rt2x00mac_sta_add and rt2x00mac_sta_remove has no callers after commit 9c87758cf089 ("rt2x00: call sta_add/remove directly in rt2800"). So can be removed. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-05-04rt2x00: check against flushing empty queueStanislaw Gruszka
We have check if queue is not empty when start flushing queues on by mac80211 callback, but we also can start flushing queues by internal driver calls. So move check into rt2x00queue_flush_queue() to assure we do not flush empty queue anytime. Additionally add warning if we start to kick empty queue as in such situation we set wrong index in the HW queue, what can confuse the HW and have various negative consequences. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-01-08rt2x00: do not pause queue unconditionally on error pathStanislaw Gruszka
Pausing queue without checking threshold is racy with txdone path. Moreover we do not need pause queue on any error, but only if queue is full - in case when we send RTS frame ( other cases of almost full queue are already handled in rt2x00queue_write_tx_frame() ). Patch fixes of theoretically possible problem of pausing empty queue. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Tested-by: Enrico Mioso <mrkiko.rs@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-01-08rt2x00: pause almost full queue earlyStanislaw Gruszka
Do not drop &queue->tx_lock and acquire it again to pause queue when available entries are below the threshold. Patch should mitigate problem of frequently printed errors: "Error - Dropping frame due to full tx queue" Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Tested-by: Enrico Mioso@gmail.com Tested-by: Enrico Mioso <mrkiko.rs@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-17rt2x00: do not flush empty queueStanislaw Gruszka
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-12-30rt2x00: add mutex to synchronize config and link tunerStanislaw Gruszka
Do not perform mac80211 config and link_tuner at the same time, this can possibly result in wrong RF or BBP configuration. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-12-30rt2800: set MAX_PSDU len according to remote STAs capabilitiesStanislaw Gruszka
MAX_LEN_CFG_MAX_PSDU specify maximum transmitted by HW AMPDU length (0 - 8kB, 1 - 16kB, 2 - 32kB, 3 - 64kB). Set this option according to remote stations capabilities (based on HT ampdu_factor). However limit the value based our hardware TX capabilities as some chips can not send more than 16kB (factor 1). Limit for all chips is currently 32kB (factor 2), but perhaps for some chips this could be increased to 64kB by setting drv_data->max_psdu to 3. Since MAX_LEN_CFG_MAX_PSDU is global setting, on multi stations modes (AP, IBSS, mesh) we limit according to less capable remote STA. We can not set bigger value to speed up communication with some stations and do not break communication with slow stations. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-01-25rt2x00: fix monitor mode regressionEli Cooper
Since commit df1404650ccb ("mac80211: remove support for IFF_PROMISC") monitor mode for rt2x00 has been made effectively useless because the hardware filter is configured to drop packets whose intended recipient is not the device, regardless of the presence of monitor mode interfaces. This patch fixes this regression by adding explicit monitor mode support, and by configuring the hardware filter accordingly. Signed-off-by: Eli Cooper <elicooper@gmx.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2015-11-18rt2x00: move under ralink vendor directoryKalle Valo
Part of reorganising wireless drivers directory and Kconfig. Signed-off-by: Kalle Valo <kvalo@codeaurora.org>