* [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
* Re: [PATCH] mac80211: fix broken AP mode handling of powersave clients
From: Emmanuel Grumbach @ 2016-11-03 10:51 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Johannes Berg, Emmanuel Grumbach
In-Reply-To: <20161103095938.84054-1-nbd@nbd.name>
On Thu, Nov 3, 2016 at 11:59 AM, Felix Fietkau <nbd@nbd.name> wrote:
> 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;
but ... then, you'll need call to drv_set_tim below...
Apparently, we can't rely on the ops pointer to enter or not enter this flow.
^ permalink raw reply
* Re: [PATCH] mac80211: fix broken AP mode handling of powersave clients
From: Emmanuel Grumbach @ 2016-11-03 10:51 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Johannes Berg, Emmanuel Grumbach
In-Reply-To: <CANUX_P0xv4a1O7tqBYABsXbRvRQm_3Va888EopKDz433cwjXew@mail.gmail.com>
On Thu, Nov 3, 2016 at 12:51 PM, Emmanuel Grumbach <egrumbach@gmail.com> wrote:
> On Thu, Nov 3, 2016 at 11:59 AM, Felix Fietkau <nbd@nbd.name> wrote:
>> 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;
>
> but ... then, you'll need call to drv_set_tim below...
s/need/never/
> Apparently, we can't rely on the ops pointer to enter or not enter this flow.
^ permalink raw reply
* Re: [PATCH] mac80211: fix broken AP mode handling of powersave clients
From: Felix Fietkau @ 2016-11-03 11:08 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless, Johannes Berg, Emmanuel Grumbach
In-Reply-To: <CANUX_P1vktccTAQZOFRdVS9ndg4XEZNw0Ec=0sFL+n7SL2g+dQ@mail.gmail.com>
On 2016-11-03 11:51, Emmanuel Grumbach wrote:
> On Thu, Nov 3, 2016 at 12:51 PM, Emmanuel Grumbach <egrumbach@gmail.com> wrote:
>> On Thu, Nov 3, 2016 at 11:59 AM, Felix Fietkau <nbd@nbd.name> wrote:
>>> 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;
>>
>> but ... then, you'll need call to drv_set_tim below...
>
> s/need/never/
>
>> Apparently, we can't rely on the ops pointer to enter or not enter this flow.
Are you going to submit a fix, or should I just send a revert of your
commit?
- Felix
^ permalink raw reply
* Re: [PATCH] mac80211: fix broken AP mode handling of powersave clients
From: Emmanuel Grumbach @ 2016-11-03 11:10 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Johannes Berg, Emmanuel Grumbach
In-Reply-To: <29865def-991d-9e0c-131b-430a9c0a694f@nbd.name>
On Thu, Nov 3, 2016 at 1:08 PM, Felix Fietkau <nbd@nbd.name> wrote:
> On 2016-11-03 11:51, Emmanuel Grumbach wrote:
>> On Thu, Nov 3, 2016 at 12:51 PM, Emmanuel Grumbach <egrumbach@gmail.com> wrote:
>>> On Thu, Nov 3, 2016 at 11:59 AM, Felix Fietkau <nbd@nbd.name> wrote:
>>>> 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;
>>>
>>> but ... then, you'll need call to drv_set_tim below...
>>
>> s/need/never/
>>
>>> Apparently, we can't rely on the ops pointer to enter or not enter this flow.
> Are you going to submit a fix, or should I just send a revert of your
> commit?
>
Go ahead and send a revert. I won't be fast enough :)
^ permalink raw reply
* [PATCH] Revert "mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE"
From: Felix Fietkau @ 2016-11-03 11:12 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, emmanuel.grumbach
This reverts commit c68df2e7be0c1238ea3c281fd744a204ef3b15a0.
__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..1711bae 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 (ieee80211_hw_check(&local->hw, AP_LINK_PS))
return;
if (sta->dead)
--
2.10.1
^ permalink raw reply related
* Re: [PATCH 1/2] rtl8xxxu: Fix for authentication failure
From: Larry Finger @ 2016-11-03 15:39 UTC (permalink / raw)
To: John Heenan
Cc: Jes Sorensen, Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <CAAye0QNZYjg1NDmXmjMXNJqa7nsbvfgoX8et1g1+HT2S2O=L1w@mail.gmail.com>
On 11/03/2016 02:10 AM, John Heenan wrote:
> 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.
I am NOT a maintainer for this driver. I do have an interest in it, but not in
any official capacity.
If you cannot accept constructive criticism, you are in the wrong activity.
Please grow up!
Larry
^ permalink raw reply
* Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
From: Larry Finger @ 2016-11-03 15:43 UTC (permalink / raw)
To: Joe Perches, Jes Sorensen, John Heenan
Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1478162497.1924.16.camel@perches.com>
On 11/03/2016 03:41 AM, Joe Perches wrote:
> 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.
Of course, but who is going to criticize Linus? I have gently chided him when an
untested patch of his was inserted just before the final release, and broke my
laptop. At least the bisection was pretty quick. :)
Larry
^ permalink raw reply
* Re: [PATCH v2 01/12] mwifiex: check tx_hw_pending before downloading sleep confirm
From: Brian Norris @ 2016-11-03 16:11 UTC (permalink / raw)
To: Xinming Hu
Cc: Linux Wireless, Kalle Valo, Dmitry Torokhov, Amitkumar Karwar,
Cathy Luo, Shengzhen Li, Xinming Hu, Wei-Ning Huang
In-Reply-To: <1478002098-14189-1-git-send-email-huxinming820@marvell.com>
+ Wei-Ning
On Tue, Nov 01, 2016 at 08:08:17PM +0800, Xinming Hu wrote:
> From: Shengzhen Li <szli@marvell.com>
>
> We may get SLEEP event from firmware even if TXDone interrupt
> for last Tx packet is still pending. In this case, we may
> end up accessing PCIe memory for handling TXDone after power
> save handshake is completed. This causes kernel crash with
> external abort.
>
> This patch will only allow downloading sleep confirm
> when no tx done interrupt is pending in the hardware.
>
> ---
> v2: address format issues(Brain)
> ---
Nit: typically, it's best if the changelog is placed after the
Sign-offs, so that the first "---" line denotes the beginning of text
that can be discarded. (Typically the changelog doesn't go into the
final git commit, and it also happens that git-am discards everything
between the first "---" line and the actual patch content.)
> Signed-off-by: Cathy Luo <cluo@marvell.com>
> Signed-off-by: Shengzhen Li <szli@marvell.com>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> drivers/net/wireless/marvell/mwifiex/cmdevt.c | 5 +++--
> drivers/net/wireless/marvell/mwifiex/init.c | 1 +
> drivers/net/wireless/marvell/mwifiex/main.h | 1 +
> drivers/net/wireless/marvell/mwifiex/pcie.c | 5 +++++
> 4 files changed, 10 insertions(+), 2 deletions(-)
Overall, I think this change is good, and it tests out fine for me so
far. Do we have the same problem for other interfaces too? e.g., SDIO?
It seems to me that the root problem is generic (i.e., don't try to
SLEEP while processing TX traffic) but the symptom just happened to be
fatal on a particular PCIe controller.
Brian
> diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> index 5347728..25a7475 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> @@ -1118,13 +1118,14 @@ mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter)
> void
> mwifiex_check_ps_cond(struct mwifiex_adapter *adapter)
> {
> - if (!adapter->cmd_sent &&
> + if (!adapter->cmd_sent && !atomic_read(&adapter->tx_hw_pending) &&
> !adapter->curr_cmd && !IS_CARD_RX_RCVD(adapter))
> mwifiex_dnld_sleep_confirm_cmd(adapter);
> else
> mwifiex_dbg(adapter, CMD,
> - "cmd: Delay Sleep Confirm (%s%s%s)\n",
> + "cmd: Delay Sleep Confirm (%s%s%s%s)\n",
> (adapter->cmd_sent) ? "D" : "",
> + atomic_read(&adapter->tx_hw_pending) ? "T" : "",
> (adapter->curr_cmd) ? "C" : "",
> (IS_CARD_RX_RCVD(adapter)) ? "R" : "");
> }
> diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
> index 82839d9..b36cb3f 100644
> --- a/drivers/net/wireless/marvell/mwifiex/init.c
> +++ b/drivers/net/wireless/marvell/mwifiex/init.c
> @@ -270,6 +270,7 @@ static void mwifiex_init_adapter(struct mwifiex_adapter *adapter)
> adapter->adhoc_11n_enabled = false;
>
> mwifiex_wmm_init(adapter);
> + atomic_set(&adapter->tx_hw_pending, 0);
>
> sleep_cfm_buf = (struct mwifiex_opt_sleep_confirm *)
> adapter->sleep_cfm->data;
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
> index d61fe3a..7f67f23 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.h
> +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> @@ -857,6 +857,7 @@ struct mwifiex_adapter {
> atomic_t rx_pending;
> atomic_t tx_pending;
> atomic_t cmd_pending;
> + atomic_t tx_hw_pending;
> struct workqueue_struct *workqueue;
> struct work_struct main_work;
> struct workqueue_struct *rx_workqueue;
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 063c707..4aa5d91 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -516,6 +516,7 @@ static int mwifiex_pcie_enable_host_int(struct mwifiex_adapter *adapter)
> }
> }
>
> + atomic_set(&adapter->tx_hw_pending, 0);
> return 0;
> }
>
> @@ -689,6 +690,7 @@ static void mwifiex_cleanup_txq_ring(struct mwifiex_adapter *adapter)
> card->tx_buf_list[i] = NULL;
> }
>
> + atomic_set(&adapter->tx_hw_pending, 0);
> return;
> }
>
> @@ -1126,6 +1128,7 @@ static int mwifiex_pcie_send_data_complete(struct mwifiex_adapter *adapter)
> -1);
> else
> mwifiex_write_data_complete(adapter, skb, 0, 0);
> + atomic_dec(&adapter->tx_hw_pending);
> }
>
> card->tx_buf_list[wrdoneidx] = NULL;
> @@ -1218,6 +1221,7 @@ mwifiex_pcie_send_data(struct mwifiex_adapter *adapter, struct sk_buff *skb,
> wrindx = (card->txbd_wrptr & reg->tx_mask) >> reg->tx_start_ptr;
> buf_pa = MWIFIEX_SKB_DMA_ADDR(skb);
> card->tx_buf_list[wrindx] = skb;
> + atomic_inc(&adapter->tx_hw_pending);
>
> if (reg->pfu_enabled) {
> desc2 = card->txbd_ring[wrindx];
> @@ -1295,6 +1299,7 @@ mwifiex_pcie_send_data(struct mwifiex_adapter *adapter, struct sk_buff *skb,
> done_unmap:
> mwifiex_unmap_pci_memory(adapter, skb, PCI_DMA_TODEVICE);
> card->tx_buf_list[wrindx] = NULL;
> + atomic_dec(&adapter->tx_hw_pending);
> if (reg->pfu_enabled)
> memset(desc2, 0, sizeof(*desc2));
> else
> --
> 1.8.1.4
>
^ permalink raw reply
* Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Dmitry Torokhov @ 2016-11-03 16:15 UTC (permalink / raw)
To: Xinming Hu
Cc: Amitkumar Karwar, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam, rajatja@google.com, briannorris@google.com
In-Reply-To: <b9fed0716cfb46818b0a93a925e5d37a@SC-EXCH02.marvell.com>
On Thu, Nov 03, 2016 at 08:34:06AM +0000, Xinming Hu wrote:
> Hi Dmitry,
>
> > -----Original Message-----
> > From: linux-wireless-owner@vger.kernel.org
> > [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Dmitry Torokhov
> > Sent: 2016年10月28日 1:44
> > To: Amitkumar Karwar
> > Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> > rajatja@google.com; briannorris@google.com
> > Subject: Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in
> > shutdown_drv
> >
> > Hi Amit,
> >
> > On Thu, Oct 27, 2016 at 02:42:40PM +0530, Amitkumar Karwar wrote:
> > > This variable is guarded by spinlock at all other places. This patch
> > > takes care of missing spinlock usage in mwifiex_shutdown_drv().
> >
> > Since in the previous discussion you stated that we inhibit interrupts and flush
> > the workqueue so that mwifiex_shutdown_drv() can't run simultaneously with
> > the main processing routine, why do we need this?
> >
> > Instead please remove call to mwifiex_shutdown_drv() in the main routine
> > and "if (adapter->mwifiex_processing)" check here.
> >
>
> mwifiex_main_process will be used from interrupt or workqueue.
> Now we have disabled interrupt and flush workqueue, so mwifiex_main_process won't be scheduled in the future.
> But mwifiex_main_process might just running in context of last interrupt, so we need wait current main_process complete in mwifiex_shutdown_drv.
synchronize_irq() is your friend then.
Thanks.
--
Dmitry
^ permalink raw reply
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