[PATCH] wireless: wlcore: spi: remove unnecessary variable

[Gustavo A. R. Silva]

Remove unnecessary variable and refactor the code.

Addresses-Coverity-ID: 1365000
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/wireless/ti/wlcore/spi.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index fa3547e..d2d899a 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -366,17 +366,14 @@ static int __wl12xx_spi_raw_write(struct device *child, 
int addr,
 static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
 void *buf, size_t len, bool fixed)
 {
-   int ret;
-
/* The ELP wakeup write may fail the first time due to internal
 * hardware latency. It is safer to send the wakeup command twice to
 * avoid unexpected failures.
 */
if (addr == HW_ACCESS_ELP_CTRL_REG)
-   ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
-   ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
+   __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
 
-   return ret;
+   return __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
 }
 
 /**
-- 
2.5.0

Re: Question on setting key right after the EAPOL 4/4 is sent.

[Denis Kenzior]

Hi Ben,

On 06/08/2017 06:43 PM, Ben Greear wrote:

On 06/08/2017 04:36 PM, Denis Kenzior wrote:

Hi Ben,


The problem I see is that sometimes (and quite often when I am using
lots
of vdevs and thus the NIC is busy), the keys are set before the EAPOL
4/4
hits the air.  When the key is set, the NIC will no longer transmit the
frame because of key-length issues in the tx-descriptor (ath10k wave-2
in this case).


We have encountered something similar.  In our case we were seeing PAE
packets (e.g. 4WayHandshake packet 1 of 4) before seeing the connect
events on nl80211.


I suspect that there is a fundamental race between the EAPOL packet-tx
logic and the key-set logic, but supplicant appears to act as though
they are natually synchronized.


Fundamentally there is a race between the genl/nl80211 socket to the
kernel and the PAE socket that handles the authentication aspects.  I
think the only way to
fix this is to make sure that PAE flows over the genl/nl80211 socket
to preserve the proper order of events.  However there are lots of
dragons in the kernel
side of this and we haven't been brave enough to venture into the
depths yet :)


I think that would just push the problem lower.  Probably a real fix
would be to somehow propagate
the tx-status for the specific packet back to the supplicant and only
then it would know that the
key could be set.



Having userspace track individual packets in the kernel sounds  wrong to 
me.  This also won't help with the packets being received out-of-order. 
It would be nice if both the RX and TX ordering was preserved.  Hence my 
thinking about running PAE over NL80211.  It would then be up to the 
kernel / drivers to guarantee that the various packets are ordered 
appropriately.


Regardless of the solution, we're happy to help in order to get this fixed.

Regards,
-Denis

Re: Question on setting key right after the EAPOL 4/4 is sent.

[Ben Greear]

On 06/08/2017 04:36 PM, Denis Kenzior wrote:

Hi Ben,


The problem I see is that sometimes (and quite often when I am using lots
of vdevs and thus the NIC is busy), the keys are set before the EAPOL 4/4
hits the air.  When the key is set, the NIC will no longer transmit the
frame because of key-length issues in the tx-descriptor (ath10k wave-2
in this case).


We have encountered something similar.  In our case we were seeing PAE packets 
(e.g. 4WayHandshake packet 1 of 4) before seeing the connect events on nl80211.


I suspect that there is a fundamental race between the EAPOL packet-tx
logic and the key-set logic, but supplicant appears to act as though
they are natually synchronized.


Fundamentally there is a race between the genl/nl80211 socket to the kernel and 
the PAE socket that handles the authentication aspects.  I think the only way to
fix this is to make sure that PAE flows over the genl/nl80211 socket to 
preserve the proper order of events.  However there are lots of dragons in the 
kernel
side of this and we haven't been brave enough to venture into the depths yet :)


I think that would just push the problem lower.  Probably a real fix would be 
to somehow propagate
the tx-status for the specific packet back to the supplicant and only then it 
would know that the
key could be set.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: Question on setting key right after the EAPOL 4/4 is sent.

[Denis Kenzior]

Hi Ben,


The problem I see is that sometimes (and quite often when I am using lots
of vdevs and thus the NIC is busy), the keys are set before the EAPOL 4/4
hits the air.  When the key is set, the NIC will no longer transmit the
frame because of key-length issues in the tx-descriptor (ath10k wave-2
in this case).


We have encountered something similar.  In our case we were seeing PAE 
packets (e.g. 4WayHandshake packet 1 of 4) before seeing the connect 
events on nl80211.



I suspect that there is a fundamental race between the EAPOL packet-tx
logic and the key-set logic, but supplicant appears to act as though
they are natually synchronized.


Fundamentally there is a race between the genl/nl80211 socket to the 
kernel and the PAE socket that handles the authentication aspects.  I 
think the only way to fix this is to make sure that PAE flows over the 
genl/nl80211 socket to preserve the proper order of events.  However 
there are lots of dragons in the kernel side of this and we haven't been 
brave enough to venture into the depths yet :)


Regards,
-Denis

Question on setting key right after the EAPOL 4/4 is sent.

[Ben Greear]

I believe I found a problem that may be larger than my little sandbox.

The problem I see is that sometimes (and quite often when I am using lots
of vdevs and thus the NIC is busy), the keys are set before the EAPOL 4/4
hits the air.  When the key is set, the NIC will no longer transmit the
frame because of key-length issues in the tx-descriptor (ath10k wave-2
in this case).

If I add a sleep before setting the key, then it works much more
reliably.

I suspect that there is a fundamental race between the EAPOL packet-tx
logic and the key-set logic, but supplicant appears to act as though
they are natually synchronized.

So, any suggestions on how to do this right?

Thanks,
Ben

greearb@v-f24-64 hostap]$ git diff
diff --git a/src/rsn_supp/wpa.c b/src/rsn_supp/wpa.c
index 8a1d164..50a3006 100644
--- a/src/rsn_supp/wpa.c
+++ b/src/rsn_supp/wpa.c
@@ -1423,6 +1423,11 @@ static void wpa_supplicant_process_3_of_4(struct wpa_sm 
*sm,
sm->renew_snonce = 1;

if (key_info & WPA_KEY_INFO_INSTALL) {
+   /* Well now...what if the NIC hasn't actually put the 4/4 on 
the air
+* yet?  If we set the key too soon, it is liable to corrupt 
the pkt being
+* sent..   I don't know a good fix, but here is a hack.
+*/
+   os_sleep(0, 1); /* sleep 10ms */
if (wpa_supplicant_install_ptk(sm, key))
goto failed;
}


--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

[PATCHv5] wlcore: add wl1285 compatible

[Sebastian Reichel]

Motorola Droid 4 uses a WL 1285C. With differences between
chips not being public let's add explicit binding for wl1285
instead of relying on wl1283 being very similar.

Reviewed-by: Rob Herring 
Acked-by: Kalle Valo 
Acked-by: Tony Lindgren 
Signed-off-by: Sebastian Reichel 
---
Changes since PATCHv4:
 - Dropped droid4.dts change, patch can go in normally now
Changes since PATCHv3:
 - add net...@vger.kernel.org to cc
 - add Acked-By from Tony & Kalle
Changes since PATCHv2:
 - merge patch for DTS and driver
 - add Acked-By from Rob
Changes since PATCHv1:
 - patches did not exist in patchv1
---
 Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt | 1 +
 drivers/net/wireless/ti/wlcore/sdio.c| 1 +
 drivers/net/wireless/ti/wlcore/spi.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
index 2a3d90de18ee..7b2cbb14113e 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
@@ -10,6 +10,7 @@ Required properties:
 * "ti,wl1273"
 * "ti,wl1281"
 * "ti,wl1283"
+* "ti,wl1285"
 * "ti,wl1801"
 * "ti,wl1805"
 * "ti,wl1807"
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index 287023ef4a78..2fb38717346f 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -237,6 +237,7 @@ static const struct of_device_id 
wlcore_sdio_of_match_table[] = {
{ .compatible = "ti,wl1273", .data = _data },
{ .compatible = "ti,wl1281", .data = _data },
{ .compatible = "ti,wl1283", .data = _data },
+   { .compatible = "ti,wl1285", .data = _data },
{ .compatible = "ti,wl1801", .data = _data },
{ .compatible = "ti,wl1805", .data = _data },
{ .compatible = "ti,wl1807", .data = _data },
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index f949ad2bd898..1f5d9ebb0925 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -433,6 +433,7 @@ static const struct of_device_id 
wlcore_spi_of_match_table[] = {
{ .compatible = "ti,wl1273", .data = _data},
{ .compatible = "ti,wl1281", .data = _data},
{ .compatible = "ti,wl1283", .data = _data},
+   { .compatible = "ti,wl1285", .data = _data},
{ .compatible = "ti,wl1801", .data = _data},
{ .compatible = "ti,wl1805", .data = _data},
{ .compatible = "ti,wl1807", .data = _data},
-- 
2.11.0

Re: porting 'mwifiex: resolve races between async FW init (failure) and device removal' to kernel 4.1.x

[Brian Norris]

On Thu, Jun 08, 2017 at 01:11:28PM +, Chadzynski, MikolajX wrote:
> Races between async firmware initialization and device removal appears on 
> kernel 4.1.x.
> Whole scenario leading to the error together with logs is in 
> https://bugzilla.kernel.org/show_bug.cgi?id=196003
> Mapping the patch from kernel 4.11.x "mwifiex: resolve races between async FW 
> init (failure) and device removal" solved the problem.

FWIW, that patch was also in v4.10.

> In Bugzilla I've also attached patch which I've tested for pcie interface and 
> it works.

What are you asking for? An official backport to the 4.1.x stable
series? I'm not super interested in trying to do that. And IIUC, your
patch is a no-go, as it will break the SDIO and USB driver builds.

If you do try to go forward with this, do try to note any follow-up
patches. I don't recall how many other related bugs there might have
been. I tried to mark things correctly with Fixes tags, but I may have
missed something, especially if such bugfixes also made it into 4.10.

Brian

Re: [PATCH 1/1] mac80211: ieee80211_rx_napi: remove warning

[Erik Stromdahl]

On 2017-06-07 23:57, Johannes Berg wrote:

On Sun, 2017-06-04 at 15:11 +0200, Erik Stromdahl wrote:

The softirq count is not always incremented during driver
operation. This is the case for usb and sdio network
drivers.


I'm pretty sure the warning is correct, and we do rely on having
local_bh_disable(), otherwise we may end up taking a soft-IRQ and I
believe there are some things that could get messed up in that case.


Ok, I will make sure to increment the softirq counter before calling
ieee80211_rx then.


So - I think the warning is there for a reason, and drivers should just
local_bh_disable() before calling into that. What's wrong with that?

I guess there is nothing wrong with that, it's just that ath10k does not
call local_bh_disable anywhere in the code.
I guess it is relying on lower layers (pcie?) to do that.
When introducing sdio and usb support these calls will have to be added
explicitly in ath10k.



johannes

Re: Wifi-Event for when initial 4-way completes?

[Ben Greear]

On 06/08/2017 08:21 AM, Ben Greear wrote:

On 06/07/2017 12:25 AM, Wojciech Dubowik wrote:

Hello Ben,

I have been using this part of wpa_supplicant to notify that 4-Way handshake is 
completed.

around line 868 in wpa_supplicant.c

#if defined(CONFIG_CTRL_IFACE) || !defined(CONFIG_NO_STDOUT_DEBUG)
wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_CONNECTED "- Connection to "
MACSTR " completed [id=%d id_str=%s%s]",
MAC2STR(wpa_s->bssid),
ssid ? ssid->id : -1,
ssid && ssid->id_str ? ssid->id_str : "",
fils_hlp_sent ? " FILS_HLP_SENT" : "");
#endif /* CONFIG_CTRL_IFACE || !CONFIG_NO_STDOUT_DEBUG */

You can pack whatever notification message inside the if statement.


I'm not sure that actually is correct?  For instance, I see this in a case where
WPA-2 was not succesfully negotiated (note the reason-2 disconnect)

IFNAME=sta9 <3>SME: Trying to authenticate with 00:0e:8e:f8:73:96 
(SSID='ota-9k-2 space' freq=5180 MHz)
IFNAME=sta9 <3>Trying to associate with 00:0e:8e:f8:73:96 (SSID='ota-9k-2 
space' freq=5180 MHz)
IFNAME=sta9 <3>Associated with 00:0e:8e:f8:73:96
IFNAME=sta9 <3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
IFNAME=sta9 <3>WPA: Key negotiation completed with 00:0e:8e:f8:73:96 [PTK=CCMP 
GTK=CCMP]
IFNAME=sta9 <3>CTRL-EVENT-CONNECTED - Connection to 00:0e:8e:f8:73:96 completed 
[id=0 id_str=]
IFNAME=sta9 <3>WPA: Key negotiation completed with 00:0e:8e:f8:73:96 [PTK=CCMP 
GTK=CCMP]
IFNAME=sta9 <3>WPA: Key negotiation completed with 00:0e:8e:f8:73:96 [PTK=CCMP 
GTK=CCMP]
IFNAME=sta9 <3>WPA: Key negotiation completed with 00:0e:8e:f8:73:96 [PTK=CCMP 
GTK=CCMP]
IFNAME=sta9 <3>CTRL-EVENT-DISCONNECTED bssid=00:0e:8e:f8:73:96 reason=2


Looks like I might need to add another message about EAPOL 4-way completing?


Based on a sniff, it seems that the 3/4 was sent in this case, but the 4/4 was 
not
received from the AP.  Maybe the 3/4 is (re)sent incorrectly sometimesI 
have run into similar
bugs in the past.

Thanks,
Ben


--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: Wifi-Event for when initial 4-way completes?

[Ben Greear]

On 06/07/2017 12:25 AM, Wojciech Dubowik wrote:

Hello Ben,

I have been using this part of wpa_supplicant to notify that 4-Way handshake is 
completed.

around line 868 in wpa_supplicant.c

#if defined(CONFIG_CTRL_IFACE) || !defined(CONFIG_NO_STDOUT_DEBUG)
wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_CONNECTED "- Connection to "
MACSTR " completed [id=%d id_str=%s%s]",
MAC2STR(wpa_s->bssid),
ssid ? ssid->id : -1,
ssid && ssid->id_str ? ssid->id_str : "",
fils_hlp_sent ? " FILS_HLP_SENT" : "");
#endif /* CONFIG_CTRL_IFACE || !CONFIG_NO_STDOUT_DEBUG */

You can pack whatever notification message inside the if statement.


I'm not sure that actually is correct?  For instance, I see this in a case where
WPA-2 was not succesfully negotiated (note the reason-2 disconnect)

IFNAME=sta9 <3>SME: Trying to authenticate with 00:0e:8e:f8:73:96 
(SSID='ota-9k-2 space' freq=5180 MHz)
IFNAME=sta9 <3>Trying to associate with 00:0e:8e:f8:73:96 (SSID='ota-9k-2 
space' freq=5180 MHz)
IFNAME=sta9 <3>Associated with 00:0e:8e:f8:73:96
IFNAME=sta9 <3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
IFNAME=sta9 <3>WPA: Key negotiation completed with 00:0e:8e:f8:73:96 [PTK=CCMP 
GTK=CCMP]
IFNAME=sta9 <3>CTRL-EVENT-CONNECTED - Connection to 00:0e:8e:f8:73:96 completed 
[id=0 id_str=]
IFNAME=sta9 <3>WPA: Key negotiation completed with 00:0e:8e:f8:73:96 [PTK=CCMP 
GTK=CCMP]
IFNAME=sta9 <3>WPA: Key negotiation completed with 00:0e:8e:f8:73:96 [PTK=CCMP 
GTK=CCMP]
IFNAME=sta9 <3>WPA: Key negotiation completed with 00:0e:8e:f8:73:96 [PTK=CCMP 
GTK=CCMP]
IFNAME=sta9 <3>CTRL-EVENT-DISCONNECTED bssid=00:0e:8e:f8:73:96 reason=2


Looks like I might need to add another message about EAPOL 4-way completing?

Thanks,
Ben




Br,

Wojtek


On 07/06/17 02:46, Ben Greear wrote:

I have been tracking down a nasty EAPOL related bug in ath10k, and found 
something that may be peripheral, or maybe
it is significant.

My logic is basically to kick supplicant, watch 'iw events', and then when I 
see something
like "sta62 (phy #5): connected to 00:0e:8e:f8:73:96", I consider it connected 
and start
dhcpd.

But, it appears that the 'connected' message comes out before the EAPOL 4-way 
completes, so
I am starting dhclient before the encryption is really set up properly.  At 
best, this slows
things down and makes dhclient have to retry.

Is there some existing event or state I can probe to determine when the initial 
4-way is complete?

In case there is not, maybe that event would be worth adding?

Or, should I hack on supplicant instead and grab the info out of it somehow?

Thanks,
Ben






--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] mwifiex: Replace semaphore async_sem with mutex

[Arnd Bergmann]

On Thu, Jun 8, 2017 at 12:03 PM, Binoy Jayan  wrote:
> The semaphore 'async_sem' is used as a simple mutex, so
> it should be written as one. Semaphores are going away in the future.
>
> Signed-off-by: Binoy Jayan 
> ---
>
> This patch is part of a bigger effort to eliminate unwanted
> semaphores from the linux kernel.

Looks good,

Reviewed-by: Arnd Bergmann 

porting 'mwifiex: resolve races between async FW init (failure) and device removal' to kernel 4.1.x

[Chadzynski, MikolajX]

Races between async firmware initialization and device removal appears on 
kernel 4.1.x.
Whole scenario leading to the error together with logs is in 
https://bugzilla.kernel.org/show_bug.cgi?id=196003
Mapping the patch from kernel 4.11.x "mwifiex: resolve races between async FW 
init (failure) and device removal" solved the problem.
In Bugzilla I've also attached patch which I've tested for pcie interface and 
it works.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: linux-next: build failure after merge of the wireless-drivers-next tree

[Stephen Rothwell]

Hi Kalle,

On Thu, 08 Jun 2017 15:07:00 +0300 Kalle Valo  wrote:
>
> Stephen Rothwell  writes:
> 
> > On Wed, 7 Jun 2017 19:43:18 -0700 Igor Mitsyanko 
> >  wrote:  
> >>
> >> thanks. As I understand, you've applied this patch during a merge and no 
> >> further actions are required, correct?  
> >
> > Dave Miller will need to apply that patch (or something similar) when
> > he merges the wireless-drivers-next tree into the net-next tree.  I
> > will keep applying the patch each day until then.  
> 
> Thanks, I'll remind Dave about this when i submit the pull request (very
> soon now).

It occurred to me just after I wrote the previous message that it would
only be true after he merges the current net tree into the net-next tree.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the wireless-drivers-next tree

[Kalle Valo]

Stephen Rothwell  writes:

> Hi Igor,
>
> On Wed, 7 Jun 2017 19:43:18 -0700 Igor Mitsyanko 
>  wrote:
>>
>> thanks. As I understand, you've applied this patch during a merge and no 
>> further actions are required, correct?
>
> Dave Miller will need to apply that patch (or something similar) when
> he merges the wireless-drivers-next tree into the net-next tree.  I
> will keep applying the patch each day until then.

Thanks, I'll remind Dave about this when i submit the pull request (very
soon now).

-- 
Kalle Valo

[PATCH] mac80211: don't look at the PM bit of BAR frames

[Emmanuel Grumbach]

When a peer sends a BAR frame with PM bit clear, we should
not modify its PM state as madated by the spec in
802.11-20012 10.2.1.2.

Signed-off-by: Emmanuel Grumbach 
---
 net/mac80211/rx.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index e48724a6725e..bb1e4bbf55e2 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1558,12 +1558,16 @@ ieee80211_rx_h_sta_process(struct ieee80211_rx_data *rx)
 */
if (!ieee80211_hw_check(>local->hw, AP_LINK_PS) &&
!ieee80211_has_morefrags(hdr->frame_control) &&
+   !ieee80211_is_back_req(hdr->frame_control) &&
!(status->rx_flags & IEEE80211_RX_DEFERRED_RELEASE) &&
(rx->sdata->vif.type == NL80211_IFTYPE_AP ||
 rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN) &&
-   /* PM bit is only checked in frames where it isn't reserved,
+   /*
+* PM bit is only checked in frames where it isn't reserved,
 * in AP mode it's reserved in non-bufferable management frames
 * (cf. IEEE 802.11-2012 8.2.4.1.7 Power Management field)
+* BAR frames should be ignored as specified in
+* IEEE 802.11-2012 10.2.1.2.
 */
(!ieee80211_is_mgmt(hdr->frame_control) ||
 ieee80211_is_bufferable_mmpdu(hdr->frame_control))) {
-- 
2.9.3

[PATCH] mwifiex: Replace semaphore async_sem with mutex

[Binoy Jayan]

The semaphore 'async_sem' is used as a simple mutex, so
it should be written as one. Semaphores are going away in the future.

Signed-off-by: Binoy Jayan 
---

This patch is part of a bigger effort to eliminate unwanted
semaphores from the linux kernel.

 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 +-
 drivers/net/wireless/marvell/mwifiex/main.h | 2 +-
 drivers/net/wireless/marvell/mwifiex/scan.c | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 7ec06bf..9e0d638 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3059,7 +3059,7 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct 
wiphy *wiphy,
INIT_DELAYED_WORK(>dfs_chan_sw_work,
  mwifiex_dfs_chan_sw_work_queue);
 
-   sema_init(>async_sem, 1);
+   mutex_init(>async_mutex);
 
mwifiex_dbg(adapter, INFO,
"info: %s: Marvell 802.11 Adapter\n", dev->name);
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index bb2a467..9c2cb33 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -628,7 +628,7 @@ struct mwifiex_private {
struct dentry *dfs_dev_dir;
 #endif
u16 current_key_index;
-   struct semaphore async_sem;
+   struct mutex async_mutex;
struct cfg80211_scan_request *scan_request;
u8 cfg_bssid[6];
struct wps wps;
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c 
b/drivers/net/wireless/marvell/mwifiex/scan.c
index ce6936d..ae9630b 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -2809,7 +2809,7 @@ int mwifiex_request_scan(struct mwifiex_private *priv,
 {
int ret;
 
-   if (down_interruptible(>async_sem)) {
+   if (mutex_lock_interruptible(>async_mutex)) {
mwifiex_dbg(priv->adapter, ERROR,
"%s: acquire semaphore fail\n",
__func__);
@@ -2825,7 +2825,7 @@ int mwifiex_request_scan(struct mwifiex_private *priv,
/* Normal scan */
ret = mwifiex_scan_networks(priv, NULL);
 
-   up(>async_sem);
+   mutex_unlock(>async_mutex);
 
return ret;
 }
-- 
Binoy Jayan

RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask

[Grumbach, Emmanuel]

> 
> On Thu, Jun 08, 2017 at 06:31:01AM +, Grumbach, Emmanuel wrote:
> > Hi,
> 
> Hi,
> 
> > True, OTOH we need tid to be 8 sometimes. We *just* need to make sure
> > that we don't index tid_data with this. Hence I think the proper fix is:
> >
> > diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > index 06ac3f1..16a8646 100644
> > --- a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > +++ b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> > @@ -1190,11 +1190,11 @@ void iwlagn_rx_reply_tx(struct iwl_priv *priv,
> struct iwl_rx_cmd_buffer *rxb)
> > next_reclaimed;
> > IWL_DEBUG_TX_REPLY(priv, "Next reclaimed 
> > packet:%d\n",
> >   next_reclaimed);
> > +   iwlagn_check_ratid_empty(priv, sta_id, tid);
> > }
> >
> > iwl_trans_reclaim(priv->trans, txq_id, ssn, );
> >
> > -   iwlagn_check_ratid_empty(priv, sta_id, tid);
> > freed = 0;
> >
> > /* process frames */
> 
> I can confirm it works. You can add my Tested-By.

Patch in review in our internal tree. It'll be upstreamed through the regular 
process.
Thanks for your report and debug work.

Re: [PATCH] cfg80211: Fix grammar issue in error message

[Arend van Spriel]

Please use the driver name as prefix, ie. brcmfmac: iso cfg80211:

On 08-06-17 10:01, Martin Michlmayr wrote:
> Fix grammar issue in error message about ISO3166.

Other than that

Acked-by: Arend van Spriel 
> Signed-off-by: Martin Michlmayr 
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c

Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)

[Oleksij Rempel]

Am 08.06.2017 um 00:39 schrieb Tobias Diedrich:
> Oleksij Rempel wrote:
>> Am 07.06.2017 um 02:12 schrieb Tobias Diedrich:
>>> Oleksij Rempel wrote:
 Yes, this is "normal" problem. The firmware has no error handler for PCI
 bus related exceptions. So if we filed to read PCI bus first time, we
 have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot
 and provide an kernel "firmware panic!" message.
 Every one who can or will to fix this, is welcome.

> *
> Jun 02 14:55:30 computer kernel: usb 1-1.1: ath: firmware panic!
> exccause: 0x000d; pc: 0x0090ae81; badvaddr: 0x10ff4038.
>>> [...]
>>>
 memdmp 50ae78 50ae88
>>>
>>> 50ae78: 6c10 0412 6aa2 0c02 0088 20c0 2008 1940  l...j..@
>>>
>>> [...copy to bin...]
>>> $ bin/objdump -b binary -m xtensa  -D /tmp/memdump.bin 
>>> [..]
>>>0:   6c1004  entry   a1, 32
>>>3:   126aa2  l32ra2, 0xfffdaa8c
>>>6:   0c0200  memw
>>>9:   8820l32i.n  a8, a2, 0  <--Exception cause 
>>> PC still points at load
>>>b:   c020movi.n  a2, 0
>>>d:   081940  extui   a9, a8, 1, 1
>>>
>>> Judging from that it should be fairly simple to at least implement
>>> some sort of retry, possible after triggering a PCIe link retrain?
>>
>> I assume, yes.
>>
>>> There are some related PCIe root complex registers that may point to
>>> what exactly failed if they were dumped.
>>>
>>> The root complex registers live at 0x0004 and I think match the
>>> registers described for the root complex in the AR9344 datasheet.
>>
>> Suddenly I don't have ar7010 docs to tell..
>>
>>> PCIE_INT_MASK would map to 0x40050 and has a bit for SYS_ERR:
>>> "A system error. The RC Core asserts CFG_SYS_ERR_RC if any device in
>>> the hierarchy reports any of the following errors and the associated
>>> enable bit is set in the Root Control register: ERR_COR, ERR_FATAL,
>>> ERR_NONFATAL."
>>>
>>> AFAICS link retrain can be done by setting bit3 (INIT_RST,
>>> "Application request to initiate a training reset") in
>>> PCIE_APP (0x4).
>>>
>>> See sboot/magpie_1_1/sboot/cmnos/eeprom/src/cmnos_eeprom.c (which
>>> flips some bits in the RC to enable the PCIe bus for reading the
>>> EEPROM).
>>>
>>> The root complex pci configuration space is at 0x2 which could
>>> have further error details:
 memdmp 2 20200
>>>
>>> 02: a02a 168c 0010 0006  0001 0001   .*..
>>> 020010:          
>>> 020020:          
>>> 020030:    0040    01ff  ...@
>>> 020040: 5bc3 5001        [.P.
>>> 020050: 0080 7005        ..p.
>>> 020060:          
>>> 020070: 0042 0010  8701  2010 0013 4411  .BD.
>>> 020080: 3011    00c0 03c0    0...
>>> 020090:    0010      
>>> 0200a0:          
>>> 0200b0:          
>>> 0200c0:          
>>> 0200d0:          
>>> 0200e0:          
>>> 0200f0:          
>>> 020100: 1401 0001     0006 2030  ...0
>>> 020110:    2000  00a0    
>>> 020120:          
>>> 020130:          
>>> 020140: 0001 0002        
>>> 020150:   8000 00ff      
>>> 020160:          
>>> 020170:          
>>> 020180:          
>>> 020190:          
>>> 0201a0:          
>>> 0201b0:          
>>> 0201c0:          
>>> 0201d0:          
>>> 0201e0:          
>>> 0201f0:          
>>>
>>> Transformed into something suitable for feeding into lspci -F:
>>>
>>> 00:00.0 Description filled in by lspci
>>> 00: 8c 16 2a a0 06 00 10 00 01 00 00 00 00 00 01 00
>>> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
>>> 40: 

[PATCH] cfg80211: Fix grammar issue in error message

[Martin Michlmayr]

Fix grammar issue in error message about ISO3166.

Signed-off-by: Martin Michlmayr 

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index cd1d6730eab7..c1ad81f34658 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6767,7 +6767,7 @@ static void brcmf_cfg80211_reg_notifier(struct wiphy 
*wiphy,
/* ignore non-ISO3166 country codes */
for (i = 0; i < sizeof(req->alpha2); i++)
if (req->alpha2[i] < 'A' || req->alpha2[i] > 'Z') {
-   brcmf_err("not a ISO3166 code (0x%02x 0x%02x)\n",
+   brcmf_err("not an ISO3166 code (0x%02x 0x%02x)\n",
  req->alpha2[0], req->alpha2[1]);
return;
}

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask

[Seraphime Kirkovski]

On Thu, Jun 08, 2017 at 06:31:01AM +, Grumbach, Emmanuel wrote:
> Hi,

Hi,

> True, OTOH we need tid to be 8 sometimes. We *just* need to make sure
> that we don't index tid_data with this. Hence I think the proper fix is:
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c 
> b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> index 06ac3f1..16a8646 100644
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
> @@ -1190,11 +1190,11 @@ void iwlagn_rx_reply_tx(struct iwl_priv *priv, struct 
> iwl_rx_cmd_buffer *rxb)
> next_reclaimed;
> IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
>   next_reclaimed);
> +   iwlagn_check_ratid_empty(priv, sta_id, tid);
> }
> 
> iwl_trans_reclaim(priv->trans, txq_id, ssn, );
> 
> -   iwlagn_check_ratid_empty(priv, sta_id, tid);
> freed = 0;
> 
> /* process frames */

I can confirm it works. You can add my Tested-By.

Thanks,
Seraph

RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask

[Grumbach, Emmanuel]

Hi,

> Subject: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask
> 
> Currently the tid mask covers the first 4 bits of iwlagn_tx_resp::ra_tid,
> which gives 16 possible values for tid.
> This is problematic because IWL_MAX_TID_COUNT is 8, so indexing
> iwl_priv::tid_data can go very wrong.

True, OTOH we need tid to be 8 sometimes. We *just* need to make sure
that we don't index tid_data with this. Hence I think the proper fix is:

diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c 
b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
index 06ac3f1..16a8646 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
@@ -1190,11 +1190,11 @@ void iwlagn_rx_reply_tx(struct iwl_priv *priv, struct 
iwl_rx_cmd_buffer *rxb)
next_reclaimed;
IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
  next_reclaimed);
+   iwlagn_check_ratid_empty(priv, sta_id, tid);
}

iwl_trans_reclaim(priv->trans, txq_id, ssn, );

-   iwlagn_check_ratid_empty(priv, sta_id, tid);
freed = 0;

/* process frames */


Clearly calling iwlagn_check_ratid_empty with tid = IWL_TID_NON_QOS is a bad 
idea.

> 
> With UBSAN I can it happening while establishing the first connection
> after module load.
> 
> [  272.143440] UBSAN: Undefined behaviour in
> drivers/net/wireless/intel/iwlwifi/dvm/tx.c:777:32
> [  272.143447] index 8 is out of range for type 'iwl_tid_data [8]'
> [  272.143457] CPU: 0 PID: 4605 Comm: irq/32-iwlwifi Not tainted 4.12.0-dirty
> #2
> [  272.143460] Hardware name: Hewlett-Packard HP EliteBook 2560p/162B,
> BIOS 68SSU Ver. F.02 07/26/2011
> [  272.143462] Call Trace:
> [  272.143472]  dump_stack+0x9c/0x10b
> [  272.143477]  ? _atomic_dec_and_lock+0x285/0x285
> [  272.143486]  ubsan_epilogue+0xd/0x4e
> [  272.143493]  __ubsan_handle_out_of_bounds+0xef/0x118
> [  272.143498]  ? __ubsan_handle_shift_out_of_bounds+0x221/0x221
> [  272.143519]  ? iwl_trans_pcie_reclaim+0x153/0xc90 [iwlwifi]
> [  272.143539]  iwlagn_check_ratid_empty+0x337/0x410 [iwldvm]
> [  272.143556]  ? iwl_hcmd_names_cmp+0x2f/0x60 [iwlwifi]
> [  272.143571]  iwlagn_rx_reply_tx+0x8a4/0x1820 [iwldvm]
> 
> Signed-off-by: Seraphime Kirkovski 
> ---
>I'm currently running this patch on my machines and I have wifi.
>The patch presumes а cleanup patch, I sent yesterday:
>   https://www.spinics.net/lists/kernel/msg2526314.html
> 
>  drivers/net/wireless/intel/iwlwifi/dvm/commands.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> index 37d2ba5ae852..e5994df9ea4c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> @@ -1448,7 +1448,7 @@ struct agg_tx_status {
>   */
>  /* refer to ra_tid */
>  #define IWLAGN_TX_RES_TID_POS0
> -#define IWLAGN_TX_RES_TID_MSK0x0f
> +#define IWLAGN_TX_RES_TID_MSK0x07
>  #define IWLAGN_TX_RES_RA_POS 4
>  #define IWLAGN_TX_RES_RA_MSK 0xf0
> 
> --
> 2.11.0
> 
> -
> linuxw...@eclists.intel.com
> https://eclists.intel.com/sympa/info/linuxwifi
> Unsubscribe by sending email to sy...@eclists.intel.com with subject
> "Unsubscribe linuxwifi"