* [PATCH v2 12/12] mwifiex: pcie: stop checking for NULL adapter->card
From: Xinming Hu @ 2016-11-02 2:24 UTC (permalink / raw)
To: Linux Wireless
Cc: Kalle Valo, Brian Norris, Dmitry Torokhov, Amitkumar Karwar,
Cathy Luo, Brian Norris
In-Reply-To: <1478053488-16042-1-git-send-email-huxinming820@marvell.com>
From: Brian Norris <briannorris@chromium.org>
It should never be NULL here, and to think otherwise makes things
confusing.
---
v2: Same as v1
---
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 55 +++++++++++++----------------
1 file changed, 24 insertions(+), 31 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index c061d00..86e8ce6 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2990,31 +2990,28 @@ static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
- struct pci_dev *pdev;
+ struct pci_dev *pdev = card->dev;
int i;
- if (card) {
- pdev = card->dev;
- if (card->msix_enable) {
- for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
- synchronize_irq(card->msix_entries[i].vector);
+ if (card->msix_enable) {
+ for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
+ synchronize_irq(card->msix_entries[i].vector);
- for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
- free_irq(card->msix_entries[i].vector,
- &card->msix_ctx[i]);
+ for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
+ free_irq(card->msix_entries[i].vector,
+ &card->msix_ctx[i]);
- card->msix_enable = 0;
- pci_disable_msix(pdev);
- } else {
- mwifiex_dbg(adapter, INFO,
- "%s(): calling free_irq()\n", __func__);
- free_irq(card->dev->irq, &card->share_irq_ctx);
+ card->msix_enable = 0;
+ pci_disable_msix(pdev);
+ } else {
+ mwifiex_dbg(adapter, INFO,
+ "%s(): calling free_irq()\n", __func__);
+ free_irq(card->dev->irq, &card->share_irq_ctx);
- if (card->msi_enable)
- pci_disable_msi(pdev);
- }
- card->adapter = NULL;
- }
+ if (card->msi_enable)
+ pci_disable_msi(pdev);
+ }
+ card->adapter = NULL;
}
/* This function initializes the PCI-E host memory space, WCB rings, etc.
@@ -3097,18 +3094,14 @@ static void mwifiex_pcie_down_dev(struct mwifiex_adapter *adapter)
adapter->seq_num = 0;
adapter->tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K;
- if (card) {
- if (reg->sleep_cookie)
- mwifiex_pcie_delete_sleep_cookie_buf(adapter);
-
- mwifiex_pcie_delete_cmdrsp_buf(adapter);
- mwifiex_pcie_delete_evtbd_ring(adapter);
- mwifiex_pcie_delete_rxbd_ring(adapter);
- mwifiex_pcie_delete_txbd_ring(adapter);
- card->cmdrsp_buf = NULL;
- }
+ if (reg->sleep_cookie)
+ mwifiex_pcie_delete_sleep_cookie_buf(adapter);
- return;
+ mwifiex_pcie_delete_cmdrsp_buf(adapter);
+ mwifiex_pcie_delete_evtbd_ring(adapter);
+ mwifiex_pcie_delete_rxbd_ring(adapter);
+ mwifiex_pcie_delete_txbd_ring(adapter);
+ card->cmdrsp_buf = NULL;
}
static struct mwifiex_if_ops pcie_ops = {
--
1.8.1.4
^ permalink raw reply related
* [PATCH V2] mac80211: Ignore VHT IE from peer with wrong rx_mcs_map
From: Filip Matusiak @ 2016-11-02 9:04 UTC (permalink / raw)
To: linux-wireless
Cc: filip.matusiak, marek.kwaczynski, johannes, davem, netdev,
linux-kernel
This is a workaround for VHT-enabled STAs which break the spec
and have the VHT-MCS Rx map filled in with value 3 for all eight
spacial streams, an example is AR9462 in AP mode.
As per spec, in section 22.1.1 Introduction to the VHT PHY
A VHT STA shall support at least single spactial stream VHT-MCSs
0 to 7 (transmit and receive) in all supported channel widths.
Some devices in STA mode will get firmware assert when trying to
associate, examples are QCA9377 & QCA6174.
Packet example of broken VHT Cap IE of AR9462:
Tag: VHT Capabilities (IEEE Std 802.11ac/D3.1)
Tag Number: VHT Capabilities (IEEE Std 802.11ac/D3.1) (191)
Tag length: 12
VHT Capabilities Info: 0x00000000
VHT Supported MCS Set
Rx MCS Map: 0xffff
.... .... .... ..11 = Rx 1 SS: Not Supported (0x0003)
.... .... .... 11.. = Rx 2 SS: Not Supported (0x0003)
.... .... ..11 .... = Rx 3 SS: Not Supported (0x0003)
.... .... 11.. .... = Rx 4 SS: Not Supported (0x0003)
.... ..11 .... .... = Rx 5 SS: Not Supported (0x0003)
.... 11.. .... .... = Rx 6 SS: Not Supported (0x0003)
..11 .... .... .... = Rx 7 SS: Not Supported (0x0003)
11.. .... .... .... = Rx 8 SS: Not Supported (0x0003)
...0 0000 0000 0000 = Rx Highest Long GI Data Rate (in Mb/s, 0 = subfield not in use): 0x0000
Tx MCS Map: 0xffff
...0 0000 0000 0000 = Tx Highest Long GI Data Rate (in Mb/s, 0 = subfield not in use): 0x0000
Signed-off-by: Filip Matusiak <filip.matusiak@tieto.com>
---
net/mac80211/vht.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index ee71576..6832bf6 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -270,6 +270,22 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct ieee80211_sub_if_data *sdata,
vht_cap->vht_mcs.tx_mcs_map |= cpu_to_le16(peer_tx << i * 2);
}
+ /*
+ * This is a workaround for VHT-enabled STAs which break the spec
+ * and have the VHT-MCS Rx map filled in with value 3 for all eight
+ * spacial streams, an example is AR9462.
+ *
+ * As per spec, in section 22.1.1 Introduction to the VHT PHY
+ * A VHT STA shall support at least single spactial stream VHT-MCSs
+ * 0 to 7 (transmit and receive) in all supported channel widths.
+ */
+ if (vht_cap->vht_mcs.rx_mcs_map == cpu_to_le16(0xFFFF)) {
+ vht_cap->vht_supported = false;
+ sdata_info(sdata, "Ignoring VHT IE from %pM due to invalid rx_mcs_map\n",
+ sta->addr);
+ return;
+ }
+
/* finally set up the bandwidth */
switch (vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) {
case IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ:
--
2.7.4
^ permalink raw reply related
* [PATCH 00/10] rt2800: random fixes
From: Stanislaw Gruszka @ 2016-11-02 14:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Stanislaw Gruszka
Random fixes mostly related to HT performance.
Stanislaw Gruszka (10):
rt2800: correctly report MCS TX parameters
rt2800usb: do not wipe out USB_DMA_CFG settings
rt2800: OFDM rates are mandatory
rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE
rt2800: make ba_size depend on ampdu_factor
rt2800: correct AUTO_RSP_CFG
rt2800: correct TX_SW_CFG1 for 5592
rt2800: use RTS/CTS protection instead of CTS-to-self
rt2800: tune *_PROT_CFG parameters
rt2800: disable CCK rates on HT
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 62 +++++++++++----------
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 5 +--
drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 15 ++++--
3 files changed, 43 insertions(+), 39 deletions(-)
^ permalink raw reply
* [PATCH 01/10] rt2800: correctly report MCS TX parameters
From: Stanislaw Gruszka @ 2016-11-02 14:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1478095865-8651-1-git-send-email-sgruszka@redhat.com>
We should only set IEEE80211_HT_MCS_TX_RX_DIF when TX and RX MCS sets
are not equal, i.e. when number of tx streams is different than
number of RX streams.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 23 +++++++++++++----------
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index bf3f0a3..aab59f6 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -7464,7 +7464,7 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
char *default_power1;
char *default_power2;
char *default_power3;
- unsigned int i;
+ unsigned int i, tx_chains, rx_chains;
u32 reg;
/*
@@ -7589,21 +7589,24 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
IEEE80211_HT_CAP_SGI_20 |
IEEE80211_HT_CAP_SGI_40;
- if (rt2x00dev->default_ant.tx_chain_num >= 2)
+ tx_chains = rt2x00dev->default_ant.tx_chain_num;
+ rx_chains = rt2x00dev->default_ant.rx_chain_num;
+
+ if (tx_chains >= 2)
spec->ht.cap |= IEEE80211_HT_CAP_TX_STBC;
- spec->ht.cap |= rt2x00dev->default_ant.rx_chain_num <<
- IEEE80211_HT_CAP_RX_STBC_SHIFT;
+ spec->ht.cap |= rx_chains << IEEE80211_HT_CAP_RX_STBC_SHIFT;
spec->ht.ampdu_factor = 3;
spec->ht.ampdu_density = 4;
- spec->ht.mcs.tx_params =
- IEEE80211_HT_MCS_TX_DEFINED |
- IEEE80211_HT_MCS_TX_RX_DIFF |
- ((rt2x00dev->default_ant.tx_chain_num - 1) <<
- IEEE80211_HT_MCS_TX_MAX_STREAMS_SHIFT);
+ spec->ht.mcs.tx_params = IEEE80211_HT_MCS_TX_DEFINED;
+ if (tx_chains != rx_chains) {
+ spec->ht.mcs.tx_params |= IEEE80211_HT_MCS_TX_RX_DIFF;
+ spec->ht.mcs.tx_params |=
+ (tx_chains - 1) << IEEE80211_HT_MCS_TX_MAX_STREAMS_SHIFT;
+ }
- switch (rt2x00dev->default_ant.rx_chain_num) {
+ switch (rx_chains) {
case 3:
spec->ht.mcs.rx_mask[2] = 0xff;
case 2:
--
1.7.1
^ permalink raw reply related
* [PATCH 03/10] rt2800: OFDM rates are mandatory
From: Stanislaw Gruszka @ 2016-11-02 14:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1478095865-8651-1-git-send-email-sgruszka@redhat.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index aab59f6..feceb13 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -1707,7 +1707,7 @@ void rt2800_config_erp(struct rt2x00_dev *rt2x00dev, struct rt2x00lib_erp *erp,
if (changed & BSS_CHANGED_BASIC_RATES) {
rt2800_register_write(rt2x00dev, LEGACY_BASIC_RATE,
- erp->basic_rates);
+ 0xff0 | erp->basic_rates);
rt2800_register_write(rt2x00dev, HT_BASIC_RATE, 0x00008003);
}
--
1.7.1
^ permalink raw reply related
* [PATCH 02/10] rt2800usb: do not wipe out USB_DMA_CFG settings
From: Stanislaw Gruszka @ 2016-11-02 14:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1478095865-8651-1-git-send-email-sgruszka@redhat.com>
We should not reset USB_DMA_CFG on rt2800usb_init_registers() as this
function is called indirectly from rt2800_enable_radio(). If we
do so, we wipe out USB_DMA_CFG settings from rt2800usb_enable_radio().
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
index 4b0bb6b..9f61293 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -341,8 +341,6 @@ static int rt2800usb_init_registers(struct rt2x00_dev *rt2x00dev)
rt2x00_set_field32(®, MAC_SYS_CTRL_RESET_BBP, 1);
rt2x00usb_register_write(rt2x00dev, MAC_SYS_CTRL, reg);
- rt2x00usb_register_write(rt2x00dev, USB_DMA_CFG, 0x00000000);
-
rt2x00usb_vendor_request_sw(rt2x00dev, USB_DEVICE_MODE, 0,
USB_MODE_RESET, REGISTER_TIMEOUT);
@@ -353,12 +351,11 @@ static int rt2800usb_init_registers(struct rt2x00_dev *rt2x00dev)
static int rt2800usb_enable_radio(struct rt2x00_dev *rt2x00dev)
{
- u32 reg;
+ u32 reg = 0;
if (unlikely(rt2800_wait_wpdma_ready(rt2x00dev)))
return -EIO;
- rt2x00usb_register_read(rt2x00dev, USB_DMA_CFG, ®);
rt2x00_set_field32(®, USB_DMA_CFG_PHY_CLEAR, 0);
rt2x00_set_field32(®, USB_DMA_CFG_RX_BULK_AGG_EN, 0);
rt2x00_set_field32(®, USB_DMA_CFG_RX_BULK_AGG_TIMEOUT, 128);
--
1.7.1
^ permalink raw reply related
* [PATCH 04/10] rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE
From: Stanislaw Gruszka @ 2016-11-02 14:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1478095865-8651-1-git-send-email-sgruszka@redhat.com>
We already initlized WPDMA_GLO_CFG_WP_DMA_BURST_SIZE to 3 on
rt2800_init_registers().
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index feceb13..9ecdc4c 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -6756,7 +6756,6 @@ int rt2800_enable_radio(struct rt2x00_dev *rt2x00dev)
rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, ®);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_TX_DMA, 1);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_RX_DMA, 1);
- rt2x00_set_field32(®, WPDMA_GLO_CFG_WP_DMA_BURST_SIZE, 2);
rt2x00_set_field32(®, WPDMA_GLO_CFG_TX_WRITEBACK_DONE, 1);
rt2800_register_write(rt2x00dev, WPDMA_GLO_CFG, reg);
--
1.7.1
^ permalink raw reply related
* [PATCH 05/10] rt2800: make ba_size depend on ampdu_factor
From: Stanislaw Gruszka @ 2016-11-02 14:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1478095865-8651-1-git-send-email-sgruszka@redhat.com>
We can calculate BA window size (max number of pending frames not
yet block acked) of remote station using Maximum A-MPDU length factor
for that station.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
index 68b620b..9da89e3 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
@@ -305,14 +305,19 @@ static void rt2x00queue_create_tx_descriptor_ht(struct rt2x00_dev *rt2x00dev,
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ieee80211_tx_rate *txrate = &tx_info->control.rates[0];
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
- struct rt2x00_sta *sta_priv = NULL;
+ u8 ba_size = 0;
if (sta) {
- txdesc->u.ht.mpdu_density =
- sta->ht_cap.ampdu_density;
+ struct rt2x00_sta *sta_priv = sta_to_rt2x00_sta(sta);
- sta_priv = sta_to_rt2x00_sta(sta);
+ txdesc->u.ht.mpdu_density = sta->ht_cap.ampdu_density;
txdesc->u.ht.wcid = sta_priv->wcid;
+
+ if (!(tx_info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE)) {
+ ba_size = IEEE80211_MIN_AMPDU_BUF;
+ ba_size <<= sta->ht_cap.ampdu_factor;
+ ba_size = min_t(int, 63, ba_size - 1);
+ }
}
/*
@@ -345,7 +350,7 @@ static void rt2x00queue_create_tx_descriptor_ht(struct rt2x00_dev *rt2x00dev,
return;
}
- txdesc->u.ht.ba_size = 7; /* FIXME: What value is needed? */
+ txdesc->u.ht.ba_size = ba_size;
/*
* Only one STBC stream is supported for now.
--
1.7.1
^ permalink raw reply related
* [PATCH 06/10] rt2800: correct AUTO_RSP_CFG
From: Stanislaw Gruszka @ 2016-11-02 14:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1478095865-8651-1-git-send-email-sgruszka@redhat.com>
Initialize AUTO_RSP_CFG register to similar value as vendor driver does.
Do not set BAC_ACK_POLICY based on short preamble setting, those are
unrelated.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 9ecdc4c..ff4a7c3 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -1691,8 +1691,6 @@ void rt2800_config_erp(struct rt2x00_dev *rt2x00dev, struct rt2x00lib_erp *erp,
if (changed & BSS_CHANGED_ERP_PREAMBLE) {
rt2800_register_read(rt2x00dev, AUTO_RSP_CFG, ®);
- rt2x00_set_field32(®, AUTO_RSP_CFG_BAC_ACK_POLICY,
- !!erp->short_preamble);
rt2x00_set_field32(®, AUTO_RSP_CFG_AR_PREAMBLE,
!!erp->short_preamble);
rt2800_register_write(rt2x00dev, AUTO_RSP_CFG, reg);
@@ -4735,9 +4733,9 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
rt2800_register_read(rt2x00dev, AUTO_RSP_CFG, ®);
rt2x00_set_field32(®, AUTO_RSP_CFG_AUTORESPONDER, 1);
rt2x00_set_field32(®, AUTO_RSP_CFG_BAC_ACK_POLICY, 1);
- rt2x00_set_field32(®, AUTO_RSP_CFG_CTS_40_MMODE, 0);
+ rt2x00_set_field32(®, AUTO_RSP_CFG_CTS_40_MMODE, 1);
rt2x00_set_field32(®, AUTO_RSP_CFG_CTS_40_MREF, 0);
- rt2x00_set_field32(®, AUTO_RSP_CFG_AR_PREAMBLE, 1);
+ rt2x00_set_field32(®, AUTO_RSP_CFG_AR_PREAMBLE, 0);
rt2x00_set_field32(®, AUTO_RSP_CFG_DUAL_CTS_EN, 0);
rt2x00_set_field32(®, AUTO_RSP_CFG_ACK_CTS_PSM_BIT, 0);
rt2800_register_write(rt2x00dev, AUTO_RSP_CFG, reg);
--
1.7.1
^ permalink raw reply related
* [PATCH 07/10] rt2800: correct TX_SW_CFG1 for 5592
From: Stanislaw Gruszka @ 2016-11-02 14:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1478095865-8651-1-git-send-email-sgruszka@redhat.com>
Those TX_SW_CFG1 values are used in vendor driver.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index ff4a7c3..812f8e7 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -4670,11 +4670,14 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
0x00000000);
}
} else if (rt2x00_rt(rt2x00dev, RT5390) ||
- rt2x00_rt(rt2x00dev, RT5392) ||
- rt2x00_rt(rt2x00dev, RT5592)) {
+ rt2x00_rt(rt2x00dev, RT5392)) {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000404);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x00000000);
+ } else if (rt2x00_rt(rt2x00dev, RT5592)) {
+ rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000404);
+ rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00000000);
+ rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x00000000);
} else {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000000);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
--
1.7.1
^ permalink raw reply related
* [PATCH 08/10] rt2800: use RTS/CTS protection instead of CTS-to-self
From: Stanislaw Gruszka @ 2016-11-02 14:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1478095865-8651-1-git-send-email-sgruszka@redhat.com>
Change default to RTS/CTS protection. This has a cost of transmitting
one more control frame (RTS) however protect us from traffic from
hidden node.
On station mode will use CTS-to-self if AP will configure that
for the network.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 812f8e7..57bfec4 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -1621,7 +1621,7 @@ static void rt2800_config_ht_opmode(struct rt2x00_dev *rt2x00dev,
* => Protect all HT40 transmissions.
*/
mm20_mode = gf20_mode = 0;
- mm40_mode = gf40_mode = 2;
+ mm40_mode = gf40_mode = 1;
break;
case IEEE80211_HT_OP_MODE_PROTECTION_NONMEMBER:
@@ -1644,7 +1644,7 @@ static void rt2800_config_ht_opmode(struct rt2x00_dev *rt2x00dev,
* Legacy STAs are present
* => Protect all HT transmissions.
*/
- mm20_mode = mm40_mode = gf20_mode = gf40_mode = 2;
+ mm20_mode = mm40_mode = gf20_mode = gf40_mode = 1;
/*
* If erp protection is needed we have to protect HT
@@ -1660,7 +1660,7 @@ static void rt2800_config_ht_opmode(struct rt2x00_dev *rt2x00dev,
/* check for STAs not supporting greenfield mode */
if (any_sta_nongf)
- gf20_mode = gf40_mode = 2;
+ gf20_mode = gf40_mode = 1;
/* Update HT protection config */
rt2800_register_read(rt2x00dev, MM20_PROT_CFG, ®);
--
1.7.1
^ permalink raw reply related
* [PATCH 09/10] rt2800: tune *_PROT_CFG parameters
From: Stanislaw Gruszka @ 2016-11-02 14:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1478095865-8651-1-git-send-email-sgruszka@redhat.com>
Use RTS/CTS protection for TXOP on all rates modes as default and
disable CCK rates (this cause performance problems).
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 57bfec4..8d35b2e 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -4771,9 +4771,9 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
rt2800_register_read(rt2x00dev, MM20_PROT_CFG, ®);
rt2x00_set_field32(®, MM20_PROT_CFG_PROTECT_RATE, 0x4004);
- rt2x00_set_field32(®, MM20_PROT_CFG_PROTECT_CTRL, 0);
+ rt2x00_set_field32(®, MM20_PROT_CFG_PROTECT_CTRL, 1);
rt2x00_set_field32(®, MM20_PROT_CFG_PROTECT_NAV_SHORT, 1);
- rt2x00_set_field32(®, MM20_PROT_CFG_TX_OP_ALLOW_CCK, 1);
+ rt2x00_set_field32(®, MM20_PROT_CFG_TX_OP_ALLOW_CCK, 0);
rt2x00_set_field32(®, MM20_PROT_CFG_TX_OP_ALLOW_OFDM, 1);
rt2x00_set_field32(®, MM20_PROT_CFG_TX_OP_ALLOW_MM20, 1);
rt2x00_set_field32(®, MM20_PROT_CFG_TX_OP_ALLOW_MM40, 0);
@@ -4784,9 +4784,9 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
rt2800_register_read(rt2x00dev, MM40_PROT_CFG, ®);
rt2x00_set_field32(®, MM40_PROT_CFG_PROTECT_RATE, 0x4084);
- rt2x00_set_field32(®, MM40_PROT_CFG_PROTECT_CTRL, 0);
+ rt2x00_set_field32(®, MM40_PROT_CFG_PROTECT_CTRL, 1);
rt2x00_set_field32(®, MM40_PROT_CFG_PROTECT_NAV_SHORT, 1);
- rt2x00_set_field32(®, MM40_PROT_CFG_TX_OP_ALLOW_CCK, 1);
+ rt2x00_set_field32(®, MM40_PROT_CFG_TX_OP_ALLOW_CCK, 0);
rt2x00_set_field32(®, MM40_PROT_CFG_TX_OP_ALLOW_OFDM, 1);
rt2x00_set_field32(®, MM40_PROT_CFG_TX_OP_ALLOW_MM20, 1);
rt2x00_set_field32(®, MM40_PROT_CFG_TX_OP_ALLOW_MM40, 1);
@@ -4797,9 +4797,9 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
rt2800_register_read(rt2x00dev, GF20_PROT_CFG, ®);
rt2x00_set_field32(®, GF20_PROT_CFG_PROTECT_RATE, 0x4004);
- rt2x00_set_field32(®, GF20_PROT_CFG_PROTECT_CTRL, 0);
+ rt2x00_set_field32(®, GF20_PROT_CFG_PROTECT_CTRL, 1);
rt2x00_set_field32(®, GF20_PROT_CFG_PROTECT_NAV_SHORT, 1);
- rt2x00_set_field32(®, GF20_PROT_CFG_TX_OP_ALLOW_CCK, 1);
+ rt2x00_set_field32(®, GF20_PROT_CFG_TX_OP_ALLOW_CCK, 0);
rt2x00_set_field32(®, GF20_PROT_CFG_TX_OP_ALLOW_OFDM, 1);
rt2x00_set_field32(®, GF20_PROT_CFG_TX_OP_ALLOW_MM20, 1);
rt2x00_set_field32(®, GF20_PROT_CFG_TX_OP_ALLOW_MM40, 0);
@@ -4810,9 +4810,9 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
rt2800_register_read(rt2x00dev, GF40_PROT_CFG, ®);
rt2x00_set_field32(®, GF40_PROT_CFG_PROTECT_RATE, 0x4084);
- rt2x00_set_field32(®, GF40_PROT_CFG_PROTECT_CTRL, 0);
+ rt2x00_set_field32(®, GF40_PROT_CFG_PROTECT_CTRL, 1);
rt2x00_set_field32(®, GF40_PROT_CFG_PROTECT_NAV_SHORT, 1);
- rt2x00_set_field32(®, GF40_PROT_CFG_TX_OP_ALLOW_CCK, 1);
+ rt2x00_set_field32(®, GF40_PROT_CFG_TX_OP_ALLOW_CCK, 0);
rt2x00_set_field32(®, GF40_PROT_CFG_TX_OP_ALLOW_OFDM, 1);
rt2x00_set_field32(®, GF40_PROT_CFG_TX_OP_ALLOW_MM20, 1);
rt2x00_set_field32(®, GF40_PROT_CFG_TX_OP_ALLOW_MM40, 1);
--
1.7.1
^ permalink raw reply related
* [PATCH 10/10] rt2800: disable CCK rates on HT
From: Stanislaw Gruszka @ 2016-11-02 14:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1478095865-8651-1-git-send-email-sgruszka@redhat.com>
Sending frames in CCK rates on HT can cause performance problems.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 8d35b2e..2515702 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -7475,7 +7475,6 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
/*
* Initialize all hw fields.
*/
- ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_HT_CCK_RATES);
ieee80211_hw_set(rt2x00dev->hw, REPORTS_TX_ACK_STATUS);
ieee80211_hw_set(rt2x00dev->hw, AMPDU_AGGREGATION);
ieee80211_hw_set(rt2x00dev->hw, PS_NULLFUNC_STACK);
--
1.7.1
^ permalink raw reply related
* ath10k and compex WLE600V5-27
From: Matteo Grandi @ 2016-11-02 14:27 UTC (permalink / raw)
To: LinuxWireless Mailing List
Hello all,
I'm using two WiFi module Compex WLE600V5-27
http://www.compex.com.sg/product/wle600v5-27/
capable of 2x2 MIMO on two boards (Gateworks ventana 5410) using ath10k drivers.
The chipset is the Qualcomm-Atheros QCA9882 but I didn't find a
firmware for this chipset, so I'm using the QCA988X.
Everithing worked fine until I tried to plug 2 antennas in both cards
in order to make some data-rate tests. Even if there are two antennas
plugged in, there aren't any changes in the data-rate measured between
using one or two antennas. Sniffing the channel I sow that the Number
of STBC streams is 1 and iw list shows that only 1 spatial stream is
supported (but the card is capable of managing 2 spatial streams):
Wiphy phy0
Band 1:
Capabilities: 0x19e3
RX LDPC
HT20/HT40
Static SM Power Save
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-15
Frequencies:
* 5180 MHz [36] (17.0 dBm)
* 5200 MHz [40] (17.0 dBm)
...
Available Antennas: TX 0x3 RX 0x3
Configured Antennas: TX 0x3 RX 0x3
Supported interface modes:
* managed
* AP
* AP/VLAN
* monitor
* mesh point
I tried the tests both on channel 48 HT40- and 149 HT40+.
The RSSI measured with iw station dump lays around -40dBm
Is it an issue related to the firmware in use?
Or maybe there aren't the right conditions to have MIMO working?
Thanks in advence
All the best
Matteo
^ permalink raw reply
* Re: ath10k and compex WLE600V5-27
From: Sebastian Gottschall @ 2016-11-02 14:33 UTC (permalink / raw)
To: Matteo Grandi, LinuxWireless Mailing List
In-Reply-To: <CAHdg3xa1uOuBoncz5YwLRmC-HWMsuVmNkWoPB=0tWavcpWNkgQ@mail.gmail.com>
depends how you test. the antennas need to have the right distance from
each other (portion of lampda)
and mimo also doesnt work well at too short distances. so place them at
10 meters distance minimum
Am 02.11.2016 um 15:27 schrieb Matteo Grandi:
> Hello all,
> I'm using two WiFi module Compex WLE600V5-27
> http://www.compex.com.sg/product/wle600v5-27/
> capable of 2x2 MIMO on two boards (Gateworks ventana 5410) using ath10k drivers.
> The chipset is the Qualcomm-Atheros QCA9882 but I didn't find a
> firmware for this chipset, so I'm using the QCA988X.
> Everithing worked fine until I tried to plug 2 antennas in both cards
> in order to make some data-rate tests. Even if there are two antennas
> plugged in, there aren't any changes in the data-rate measured between
> using one or two antennas. Sniffing the channel I sow that the Number
> of STBC streams is 1 and iw list shows that only 1 spatial stream is
> supported (but the card is capable of managing 2 spatial streams):
>
> Wiphy phy0
> Band 1:
> Capabilities: 0x19e3
> RX LDPC
> HT20/HT40
> Static SM Power Save
> RX HT20 SGI
> RX HT40 SGI
> TX STBC
> RX STBC 1-stream
> Max AMSDU length: 7935 bytes
> DSSS/CCK HT40
> Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
> Minimum RX AMPDU time spacing: 8 usec (0x06)
> HT TX/RX MCS rate indexes supported: 0-15
> Frequencies:
> * 5180 MHz [36] (17.0 dBm)
> * 5200 MHz [40] (17.0 dBm)
> ...
>
> Available Antennas: TX 0x3 RX 0x3
> Configured Antennas: TX 0x3 RX 0x3
> Supported interface modes:
> * managed
> * AP
> * AP/VLAN
> * monitor
> * mesh point
>
>
> I tried the tests both on channel 48 HT40- and 149 HT40+.
> The RSSI measured with iw station dump lays around -40dBm
>
> Is it an issue related to the firmware in use?
> Or maybe there aren't the right conditions to have MIMO working?
>
> Thanks in advence
> All the best
>
> Matteo
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* Re: BCM43602 firmware reports multiple BRCMF_E_DEAUTH
From: Arend Van Spriel @ 2016-11-02 19:42 UTC (permalink / raw)
To: Rafał Miłecki, linux-wireless@vger.kernel.org,
brcm80211 development
In-Reply-To: <befa10f7-265e-3f4e-dd0c-ebcd0b32f3e2@gmail.com>
On 19-10-2016 14:34, Rafał Miłecki wrote:
> On 10/04/2016 08:15 PM, Rafał Miłecki wrote:
>> # My smartphone remains in the same place (1 m from the AP) but there
>> is some
>> # connection/A-MPDU problem.
>> Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509120] brcmfmac:
>> CONSOLE: 026970.308 ampdu_dbg: wl0.0 scb:0035ee78 tid:0
>> Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509250] brcmfmac:
>> CONSOLE: 026970.308 ampdu_dbg: wl0.0 dead_cnt 2 tx_in_transit 1
>> psm_mux 0xfff0 aqmqmap 0x0x101 aqmfifo_status 0x0x4000 fifordy 0x0
>> cpbusy 0x0
>> Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509304] brcmfmac:
>> CONSOLE: 026970.308 ampdu_dbg: ifsstat 0xaf nav_stat 0x0 txop 110486
>> Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509346] brcmfmac:
>> CONSOLE: 026970.308 ampdu_dbg: pktpend: 0 0 0 0 0 ap 1
>> Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509411] brcmfmac:
>> CONSOLE: 026970.308 ampdu_dbg: txall 4 txbcn 0 txrts 0 rxcts 0
>> rsptmout 0 rxstrt 0
>> Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509477] brcmfmac:
>> CONSOLE: 026970.308 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 4 0 0 0
>> 0 ifs_boff 0
>> Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509527] brcmfmac:
>> CONSOLE: 026970.308 ampdu_dbg: again1 ifsstat 0xaf nav_stat 0x0
>> Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509576] brcmfmac:
>> CONSOLE: 026970.308 ampdu_dbg: again2 ifsstat 0xaf nav_stat 0x0
>> Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509665] brcmfmac:
>> CONSOLE: 026970.308 wl0: wlc_ampdu_watchdog: cleaning up ini tid 0 due
>> to no progress for 2 secs tx_in_transit 1
>> Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509726] brcmfmac:
>> CONSOLE: 026970.308 wl0: wlc_ampdu_tx_send_delba: tid 0 initiator 1
>> reason 39
>> Tue Oct 4 17:22:41 2016 kern.debug kernel: [ 266.456860] brcmfmac:
>> CONSOLE: 026990.068 wl0.0: wlc_send_bar: seq 0x7c tid 0
>> Tue Oct 4 17:22:43 2016 kern.debug kernel: [ 268.178234] brcmfmac:
>> CONSOLE: 026991.783 pktid is NULL
>>
>> # After recovering from A-MPDU thing firmware sends BRCMF_E_DEAUTH and
>> # BRCMF_E_DISASSOC_IND events.
>> # My smartphone never receives deauth/disassoc and it believes it's still
>> # connected to the AP.
>> Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.275305] brcmfmac:
>> brcmf_notify_connect_status_ap event 5, reason 4
>> Tue Oct 4 17:23:24 2016 daemon.info hostapd: wlan1: STA
>> 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
>> Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.275354] brcmfmac:
>> brcmf_notify_connect_status_ap event 12, reason 8
>> Tue Oct 4 17:23:24 2016 daemon.info hostapd: wlan1: STA
>> 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
>> Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.275865] brcmfmac:
>> brcmf_cfg80211_del_key key index (0)
>> Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.276177] brcmfmac:
>> brcmf_cfg80211_del_key key index (0)
>> Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.276188] brcmfmac:
>> brcmf_cfg80211_del_key Ignore clearing of (never configured) key
>>
>> # My smartphone starts sending packets. It seems brcmfmac refuses them
>> due to
>> # STA not being connected and for each packet it reports
>> BRCMF_E_DEAUTH to the
>> # driver.
>> Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.000406] brcmfmac:
>> brcmf_notify_connect_status_ap event 5, reason 7
>> Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA
>> 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
>> Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.001227] brcmfmac:
>> brcmf_notify_connect_status_ap event 5, reason 7
>> Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA
>> 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
>> Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.001894] brcmfmac:
>> brcmf_notify_connect_status_ap event 5, reason 7
>> Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA
>> 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
>> Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.002594] brcmfmac:
>> brcmf_notify_connect_status_ap event 5, reason 7
>> Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA
>> 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
>> Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.003741] brcmfmac:
>> brcmf_notify_connect_status_ap event 5, reason 7
>> Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA
>> 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
>> Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.004096] brcmfmac:
>> brcmf_notify_connect_status_ap event 5, reason 7
>> Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA
>> 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
>> Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.004490] brcmfmac:
>> brcmf_notify_connect_status_ap event 5, reason 7
>> Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA
>> 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
>> Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.004936] brcmfmac:
>> brcmf_notify_connect_status_ap event 5, reason 7
>> Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA
>> 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
>
> I just got 400+ messages like this:
> wlan1: STA 84:38:38:e4:b5:ea IEEE 802.11: disassociated
> this time I was lucky enough to have monitor mode running on some
> independent
> notebook and I got it recorded.
>
> I'm attaching pcapng (Wireshark dump) file. You can see a lot of
> Deauthentication frames flying both ways with a reason code 0x0006 (Class 2
> frame received from nonauthenticated STA).
>
> I think this reason code seems to match my suspicions: STA didn't
> realize it was
> disconnected and it kept sending packets. Firmware reacted sending
> Deauth frames
Hi Rafał,
Staring at the wireshark dump I can not follow your suspicion above.
Where are the packets that STA was sending. The 802.11 spec mentions
there can be more deauth frames being transmitted during the deauth
procedure. So it seems they get stuck in the deauth procedure for some
reason.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 5/5] mwifiex: wait for firmware dump completion in remove_card
From: Brian Norris @ 2016-11-02 20:45 UTC (permalink / raw)
To: Kalle Valo
Cc: Dmitry Torokhov, Amitkumar Karwar, linux-wireless, Cathy Luo,
Nishant Sarmukadam, Xinming Hu
In-Reply-To: <87d1imudwm.fsf@purkki.adurom.net>
On Thu, Oct 27, 2016 at 04:20:25PM +0300, Kalle Valo wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
>
> >> +/* reset_trigger variable is used to identify if mwifiex_sdio_remove()
> >> + * is called by sdio_work during reset or the call is from sdio subsystem.
> >> + * We will cancel sdio_work only if the call is from sdio subsystem.
> >> + */
> >> +static u8 reset_triggered;
> >
> > It would be really great if the driver supported multiple devices. IOW
> > please avoid module-globals.
>
> Good catch, it's a hard requirement to support multiple devices at the
> same time.
BTW, this problem is repeated in several places throughout this driver.
For instance, look for 'user_rmmod' (why? you shouldn't need to treat
module unload differently...) and the work structs (and corresponding
'saved_adapter' and 'iface_flags') used for PCIe function-level reset
and SDIO reset.
Hopefully either Marvell's or my cleanups can move to get rid of these
anti-patterns soon...
Brian
^ permalink raw reply
* Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
From: Larry Finger @ 2016-11-03 1:00 UTC (permalink / raw)
To: John Heenan, Jes Sorensen, Kalle Valo, linux-wireless, netdev
Cc: linux-kernel
In-Reply-To: <20161030102112.GA5789@cube>
On 10/30/2016 05:21 AM, John Heenan wrote:
> Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set
> macpower, is never 0xea. It is only ever 0x01 (first time after modprobe)
> using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results
> occurs with 'Fix for authentication failure' [PATCH 1/2] in place.
>
> Whatever was returned, code tests always showed that at least
> rtl8xxxu_init_queue_reserved_page(priv);
> is always required. Not called if macpower set to true.
>
> Please see cover letter, [PATCH 0/2], for more information from tests.
That cover letter will NOT be included in the commit message, thus referring to
it here is totally pointless.
>
> For rtl8xxxu-devel branch of git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git
Same comment as for the previous patch.
Again I leave the review of the code changes to Jes.
Larry
^ permalink raw reply
* Re: [PATCH 1/2] rtl8xxxu: Fix for authentication failure
From: Larry Finger @ 2016-11-03 1:00 UTC (permalink / raw)
To: John Heenan, Jes Sorensen, Kalle Valo, linux-wireless, netdev
Cc: linux-kernel
In-Reply-To: <20161030102046.GA5784@cube>
On 10/30/2016 05:20 AM, John Heenan wrote:
> This fix enables the same sequence of init behaviour as the alternative
> working driver for the wireless rtl8723bu IC at
> https://github.com/lwfinger/rtl8723bu
>
> For exampe rtl8xxxu_init_device is now called each time
> userspace wpa_supplicant is executed instead of just once when
> modprobe is executed.
After all the trouble you have had with your patches, I would expect you to use
more care when composing the commit message. Note the typo in the paragraph above.
> Along with 'Fix for bogus data used to determine macpower',
> wpa_supplicant now reliably and successfully authenticates.
I'm not sure this paragraph belongs in the permanent commit record.
> For rtl8xxxu-devel branch of git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git
I know this line does not belong. If you want to include information like this,
include it after a line containing "---". Those lines will be available to
reviewers and maintainers, but will be stripped before it gets included in the
code base.
> Signed-off-by: John Heenan <john@zgus.com>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 04141e5..f25b4df 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -5779,6 +5779,11 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
>
> ret = 0;
>
> + ret = rtl8xxxu_init_device(hw);
> + if (ret)
> + goto error_out;
> +
> +
> init_usb_anchor(&priv->rx_anchor);
> init_usb_anchor(&priv->tx_anchor);
> init_usb_anchor(&priv->int_anchor);
> @@ -6080,10 +6085,6 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
> goto exit;
> }
>
> - ret = rtl8xxxu_init_device(hw);
> - if (ret)
> - goto exit;
> -
> hw->wiphy->max_scan_ssids = 1;
> hw->wiphy->max_scan_ie_len = IEEE80211_MAX_DATA_LEN;
> hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
>
I will let Jes comment on any side effects of this code change.
Larry
--
If I was stranded on an island and the only way to get off
the island was to make a pretty UI, I’d die there.
Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
From: David Miller @ 2016-11-03 2:58 UTC (permalink / raw)
To: Larry.Finger
Cc: john, Jes.Sorensen, kvalo, linux-wireless, netdev, linux-kernel
In-Reply-To: <10e32bb4-fe16-6a0f-eaf4-1142c23e7b56@lwfinger.net>
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Wed, 2 Nov 2016 20:00:03 -0500
> On 10/30/2016 05:21 AM, John Heenan wrote:
>> Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to
>> set
>> macpower, is never 0xea. It is only ever 0x01 (first time after
>> modprobe)
>> using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These
>> results
>> occurs with 'Fix for authentication failure' [PATCH 1/2] in place.
>>
>> Whatever was returned, code tests always showed that at least
>> rtl8xxxu_init_queue_reserved_page(priv);
>> is always required. Not called if macpower set to true.
>>
>> Please see cover letter, [PATCH 0/2], for more information from tests.
>
> That cover letter will NOT be included in the commit message, thus
> referring to it here is totally pointless.
This is why when a patch series is added to GIT, the cover letter
must be added to the merge commit that adds that series.
It is therefore perfectly valid to refer to such text from a
commit contained by that merge commit.
^ permalink raw reply
* Re: [PATCH 1/2] rtl8xxxu: Fix for authentication failure
From: John Heenan @ 2016-11-03 7:10 UTC (permalink / raw)
To: Larry Finger
Cc: Jes Sorensen, Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <8dba6346-332e-84e6-89b2-02033a449f25@lwfinger.net>
On 3 November 2016 at 11:00, Larry Finger <Larry.Finger@lwfinger.net> wrote=
:
> On 10/30/2016 05:20 AM, John Heenan wrote:
>>
>> This fix enables the same sequence of init behaviour as the alternative
>> working driver for the wireless rtl8723bu IC at
>> https://github.com/lwfinger/rtl8723bu
>>
>> For exampe rtl8xxxu_init_device is now called each time
>> userspace wpa_supplicant is executed instead of just once when
>> modprobe is executed.
>
>
> After all the trouble you have had with your patches, I would expect you =
to
> use more care when composing the commit message. Note the typo in the
> paragraph above.
>
OK, the nasty games continue and the message is not getting through.
An appropriate response by a maintainer would have been to request I
revise the code according to the way it has currently and elegantly
revised in.
[PATCH v2] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless I=
C
where I use a simple pointer comparison of priv->fops with &rtl8723bu_fops.
As far as I can see there is nothing more to be done on my part code
wise. The supposed issue with matching functions, as far as I can see,
is a non issue.
If you want to comment on comments in patch messages please do so on
the above current proposed patch instead of dragging up stale and
irreelvant patch proposals to make a petty point.
Jes has now moved the goal posts, indicating all drivers for rtl8xxxu
need to be tested fro similar issues. If there are problems with other
rtl8xxxu drives then it is not my problem and has nothing to do with
me. My issue is only with the rtl8723bu driver.
Such doubts also makes it look as if there was never any proper
testing and there is no real interest in proper testing. After all
that would involve cooperation and team work.
Want concrete evidence? I actually did report problems to Jes in
private emails, AS REQUESTED, in dmesg before I started tests and
posting patches. In the emalI stated I was willing to test drivers
with printk messages. I did not even get the courtesy of a reply.
Want even more concrete evidence? Jes has some very strange comments
in his tree for his current last commit
f958b1e0806c045830d78c4287fbcddf9e5fd9d0
" This uncovered a huge bug where the old code would use struct
ieee80211_rate.flags to test for rate parameters, which is always
zero, instead of the flags value from struct ieee80211_tx_rate.
"Time to find a brown paper bag :("
John Heenan
>> Along with 'Fix for bogus data used to determine macpower',
>> wpa_supplicant now reliably and successfully authenticates.
>
>
> I'm not sure this paragraph belongs in the permanent commit record.
>
>> For rtl8xxxu-devel branch of
>> git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git
>
>
> I know this line does not belong. If you want to include information like
> this, include it after a line containing "---". Those lines will be
> available to reviewers and maintainers, but will be stripped before it ge=
ts
> included in the code base.
>
>
>> Signed-off-by: John Heenan <john@zgus.com>
>> ---
>> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
>> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
>> index 04141e5..f25b4df 100644
>> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
>> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
>> @@ -5779,6 +5779,11 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw=
)
>>
>> ret =3D 0;
>>
>> + ret =3D rtl8xxxu_init_device(hw);
>> + if (ret)
>> + goto error_out;
>> +
>> +
>> init_usb_anchor(&priv->rx_anchor);
>> init_usb_anchor(&priv->tx_anchor);
>> init_usb_anchor(&priv->int_anchor);
>> @@ -6080,10 +6085,6 @@ static int rtl8xxxu_probe(struct usb_interface
>> *interface,
>> goto exit;
>> }
>>
>> - ret =3D rtl8xxxu_init_device(hw);
>> - if (ret)
>> - goto exit;
>> -
>> hw->wiphy->max_scan_ssids =3D 1;
>> hw->wiphy->max_scan_ie_len =3D IEEE80211_MAX_DATA_LEN;
>> hw->wiphy->interface_modes =3D BIT(NL80211_IFTYPE_STATION);
>>
>
> I will let Jes comment on any side effects of this code change.
>
> Larry
>
> --
> If I was stranded on an island and the only way to get off
> the island was to make a pretty UI, I=E2=80=99d die there.
>
> Linus Torvalds
^ permalink raw reply
* RE: [PATCH v2 1/5] mwifiex: remove redundant condition in main process
From: Xinming Hu @ 2016-11-03 8:04 UTC (permalink / raw)
To: Brian Norris, Amitkumar Karwar
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, briannorris@google.com,
dmitry.torokhov@gmail.com
In-Reply-To: <20161027183536.GA28717@localhost>
SGksDQoNCldlIGhhdmUgaW5jbHVkZSBiZWxvdyBjaGFuZ2UgaW4gbGF0ZXN0IHN1Ym1pdCBodHRw
czovL3BhdGNod29yay5rZXJuZWwub3JnL3BhdGNoLzk0MDcyODMvDQpQbGVhc2UgZHJvcCB0aGlz
IHBhdGNoLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGxpbnV4LXdp
cmVsZXNzLW93bmVyQHZnZXIua2VybmVsLm9yZw0KPiBbbWFpbHRvOmxpbnV4LXdpcmVsZXNzLW93
bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIE5vcnJpcw0KPiBTZW50OiAy
MDE2xOoxMNTCMjjI1SAyOjM2DQo+IFRvOiBBbWl0a3VtYXIgS2Fyd2FyDQo+IENjOiBsaW51eC13
aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IENhdGh5IEx1bzsgTmlzaGFudCBTYXJtdWthZGFtOw0K
PiByYWphdGphQGdvb2dsZS5jb207IGJyaWFubm9ycmlzQGdvb2dsZS5jb207IGRtaXRyeS50b3Jv
a2hvdkBnbWFpbC5jb20NCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MiAxLzVdIG13aWZpZXg6IHJl
bW92ZSByZWR1bmRhbnQgY29uZGl0aW9uIGluIG1haW4NCj4gcHJvY2Vzcw0KPiANCj4gT24gVGh1
LCBPY3QgMjcsIDIwMTYgYXQgMDI6NDI6MzlQTSArMDUzMCwgQW1pdGt1bWFyIEthcndhciB3cm90
ZToNCj4gPiBUaGlzIGNvbmRpdGlvbiB3aGlsZSBjYWxsaW5nIG13aWZpZXhfY2hlY2tfcHNfY29u
ZCgpIGlzIHJlZHVuZGFudC4NCj4gPiBUaGUgZnVuY3Rpb24gaW50ZXJuYWxseSBhbHJlYWR5IHRh
a2VzIGNhcmUgb2YgaXQuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBBbWl0a3VtYXIgS2Fyd2Fy
IDxha2Fyd2FyQG1hcnZlbGwuY29tPg0KPiA+IC0tLQ0KPiA+IHYyOiBTYW1lIGFzIHYxDQo+IA0K
PiBZb3UndmUgb21pdHRlZCB0aGUgUmV2aWV3ZWQtYnkgdGFncyBmcm9tIHYxOg0KPiANCj4gUmV2
aWV3ZWQtYnk6IEJyaWFuIE5vcnJpcyA8YnJpYW5ub3JyaXNAY2hyb21pdW0ub3JnPg0K
^ permalink raw reply
* RE: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Xinming Hu @ 2016-11-03 8:34 UTC (permalink / raw)
To: Dmitry Torokhov, Amitkumar Karwar
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, briannorris@google.com
In-Reply-To: <20161027174422.GA509@dtor-ws>
SGkgRG1pdHJ5LA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGxpbnV4
LXdpcmVsZXNzLW93bmVyQHZnZXIua2VybmVsLm9yZw0KPiBbbWFpbHRvOmxpbnV4LXdpcmVsZXNz
LW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIERtaXRyeSBUb3Jva2hvdg0KPiBT
ZW50OiAyMDE2xOoxMNTCMjjI1SAxOjQ0DQo+IFRvOiBBbWl0a3VtYXIgS2Fyd2FyDQo+IENjOiBs
aW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IENhdGh5IEx1bzsgTmlzaGFudCBTYXJtdWth
ZGFtOw0KPiByYWphdGphQGdvb2dsZS5jb207IGJyaWFubm9ycmlzQGdvb2dsZS5jb20NCj4gU3Vi
amVjdDogUmU6IFtQQVRDSCB2MiAyLzVdIG13aWZpZXg6IHVzZSBzcGlubG9jayBmb3IgJ213aWZp
ZXhfcHJvY2Vzc2luZycgaW4NCj4gc2h1dGRvd25fZHJ2DQo+IA0KPiBIaSBBbWl0LA0KPiANCj4g
T24gVGh1LCBPY3QgMjcsIDIwMTYgYXQgMDI6NDI6NDBQTSArMDUzMCwgQW1pdGt1bWFyIEthcndh
ciB3cm90ZToNCj4gPiBUaGlzIHZhcmlhYmxlIGlzIGd1YXJkZWQgYnkgc3BpbmxvY2sgYXQgYWxs
IG90aGVyIHBsYWNlcy4gVGhpcyBwYXRjaA0KPiA+IHRha2VzIGNhcmUgb2YgbWlzc2luZyBzcGlu
bG9jayB1c2FnZSBpbiBtd2lmaWV4X3NodXRkb3duX2RydigpLg0KPiANCj4gU2luY2UgaW4gdGhl
IHByZXZpb3VzIGRpc2N1c3Npb24geW91IHN0YXRlZCB0aGF0IHdlIGluaGliaXQgaW50ZXJydXB0
cyBhbmQgZmx1c2gNCj4gdGhlIHdvcmtxdWV1ZSBzbyB0aGF0IG13aWZpZXhfc2h1dGRvd25fZHJ2
KCkgY2FuJ3QgcnVuIHNpbXVsdGFuZW91c2x5IHdpdGgNCj4gdGhlIG1haW4gcHJvY2Vzc2luZyBy
b3V0aW5lLCB3aHkgZG8gd2UgbmVlZCB0aGlzPw0KPiANCj4gSW5zdGVhZCBwbGVhc2UgcmVtb3Zl
IGNhbGwgdG8gbXdpZmlleF9zaHV0ZG93bl9kcnYoKSBpbiB0aGUgbWFpbiByb3V0aW5lDQo+IGFu
ZCAiaWYgKGFkYXB0ZXItPm13aWZpZXhfcHJvY2Vzc2luZykiIGNoZWNrIGhlcmUuDQo+IA0KDQpt
d2lmaWV4X21haW5fcHJvY2VzcyB3aWxsIGJlIHVzZWQgZnJvbSBpbnRlcnJ1cHQgb3Igd29ya3F1
ZXVlLg0KTm93IHdlIGhhdmUgZGlzYWJsZWQgaW50ZXJydXB0IGFuZCBmbHVzaCB3b3JrcXVldWUs
IHNvIG13aWZpZXhfbWFpbl9wcm9jZXNzIHdvbid0IGJlIHNjaGVkdWxlZCBpbiB0aGUgZnV0dXJl
Lg0KQnV0IG13aWZpZXhfbWFpbl9wcm9jZXNzIG1pZ2h0IGp1c3QgcnVubmluZyBpbiBjb250ZXh0
IG9mIGxhc3QgaW50ZXJydXB0LCBzbyB3ZSBuZWVkIHdhaXQgY3VycmVudCBtYWluX3Byb2Nlc3Mg
Y29tcGxldGUgaW4gbXdpZmlleF9zaHV0ZG93bl9kcnYuDQoNCg0KPiBUaGFua3MuDQo+IA0KPiA+
DQo+ID4gU2lnbmVkLW9mZi1ieTogQW1pdGt1bWFyIEthcndhciA8YWthcndhckBtYXJ2ZWxsLmNv
bT4NCj4gPiAtLS0NCj4gPiB2MjogU2FtZSBhcyB2MQ0KPiA+IC0tLQ0KPiA+ICBkcml2ZXJzL25l
dC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvaW5pdC5jIHwgMyArKysNCj4gPiAgMSBmaWxlIGNo
YW5nZWQsIDMgaW5zZXJ0aW9ucygrKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0
L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9pbml0LmMNCj4gPiBiL2RyaXZlcnMvbmV0L3dpcmVs
ZXNzL21hcnZlbGwvbXdpZmlleC9pbml0LmMNCj4gPiBpbmRleCA4MjgzOWQ5Li44ZTVlNDI0IDEw
MDY0NA0KPiA+IC0tLSBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9pbml0
LmMNCj4gPiArKysgYi9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvaW5pdC5j
DQo+ID4gQEAgLTY3MCwxMSArNjcwLDE0IEBAIG13aWZpZXhfc2h1dGRvd25fZHJ2KHN0cnVjdCBt
d2lmaWV4X2FkYXB0ZXINCj4gPiAqYWRhcHRlcikNCj4gPg0KPiA+ICAJYWRhcHRlci0+aHdfc3Rh
dHVzID0gTVdJRklFWF9IV19TVEFUVVNfQ0xPU0lORzsNCj4gPiAgCS8qIHdhaXQgZm9yIG13aWZp
ZXhfcHJvY2VzcyB0byBjb21wbGV0ZSAqLw0KPiA+ICsJc3Bpbl9sb2NrX2lycXNhdmUoJmFkYXB0
ZXItPm1haW5fcHJvY19sb2NrLCBmbGFncyk7DQo+ID4gIAlpZiAoYWRhcHRlci0+bXdpZmlleF9w
cm9jZXNzaW5nKSB7DQo+ID4gKwkJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmYWRhcHRlci0+bWFp
bl9wcm9jX2xvY2ssIGZsYWdzKTsNCj4gPiAgCQltd2lmaWV4X2RiZyhhZGFwdGVyLCBXQVJOLA0K
PiA+ICAJCQkgICAgIm1haW4gcHJvY2VzcyBpcyBzdGlsbCBydW5uaW5nXG4iKTsNCj4gPiAgCQly
ZXR1cm4gcmV0Ow0KPiA+ICAJfQ0KPiA+ICsJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmYWRhcHRl
ci0+bWFpbl9wcm9jX2xvY2ssIGZsYWdzKTsNCj4gPg0KPiA+ICAJLyogY2FuY2VsIGN1cnJlbnQg
Y29tbWFuZCAqLw0KPiA+ICAJaWYgKGFkYXB0ZXItPmN1cnJfY21kKSB7DQo+ID4gLS0NCj4gPiAx
LjkuMQ0KPiA+DQo+IA0KPiAtLQ0KPiBEbWl0cnkNCg==
^ permalink raw reply
* Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
From: Joe Perches @ 2016-11-03 8:41 UTC (permalink / raw)
To: Jes Sorensen, John Heenan
Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <wrfjzillsan3.fsf@redhat.com>
On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote:
> Code is 80 characters wide, and comments are /* */ never the ugly C++
> crap.
You might look at the recent Linus Torvalds authored commit
5e467652ffef (?printk: re-organize log_output() to be more legible")
which does both of those: c99 // comments and > 80 columns.
Absolutes are for zealots.
^ permalink raw reply
* [PATCH] mac80211: fix broken AP mode handling of powersave clients
From: Felix Fietkau @ 2016-11-03 9:59 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, emmanuel.grumbach
Commit c68df2e7be0c ("mac80211: allow using AP_LINK_PS with
mac80211-generated TIM IE") introduced a logic error, where
__sta_info_recalc_tim turns into a no-op if local->ops->set_tim is not
set. This prevents the beacon TIM bit from being set for all drivers
that do not implement this op (almost all of them), thus thoroughly
essential AP mode powersave functionality.
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: c68df2e7be0c ("mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
net/mac80211/sta_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 236d47e..621734e 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -688,7 +688,7 @@ static void __sta_info_recalc_tim(struct sta_info *sta, bool ignore_pending)
}
/* No need to do anything if the driver does all */
- if (!local->ops->set_tim)
+ if (local->ops->set_tim)
return;
if (sta->dead)
--
2.10.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox