date:20150709

Hey guys, I'm afraid I hit another brcmfmac bug.

First of all, I implemented a trivial workaround for the previous bug
reported in the:
brcmfmac: one faulty "iw interface add" command breaks in-firmware BSS state
See my workaround in OpenWrt git:
http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=0e6c9bd9556eea98b476ad371d64d8d16e3a9f9c

So now OpenWrt's user space calls using "iw" tool don't trigger
brcmfmac BSSes bug anymore. I can successfully use one AP interface
per device.

The problem appears when trying to use more than 1 interface. It gets
created correctly, but setting its MAC fails. It results in wlan0-1
having the same MAC as wlan0 and finally having two networks (SSIDs)
using the same MAC. That obviously doesn't work.

The error I see is:
brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52
with -52 meaning BCME_IE_NOTFOUND.

-- 
Rafał
[   17.014251] brcmfmac :01:00.0: enabling device (0140 -> 0142)
[   17.028974] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[   17.036950] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[   17.044939] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 
mBm), (N/A)
[   17.052922] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (N/A)
[   17.062363] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (0 s)
[   17.071805] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 
mBm), (0 s)
[   17.079859] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 
mBm), (N/A)
[   17.087842] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 
mBm), (N/A)
[   17.867533] brcmfmac :01:00.0: Direct firmware load for 
brcm/brcmfmac43602-pcie.txt failed with error -2
[   17.877408] brcmfmac :01:00.0: Falling back to user helper
[   17.892499] firmware brcm!brcmfmac43602-pcie.txt: firmware_loading_store: 
map pages failed
[   17.901084] brcmfmac: brcmf_fw_request_nvram_done: Found platform NVRAM 
(19204 B)
[   18.163675] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Mar  3 
2015 04:46:51 version 7.35.177.33 (r538052) FWID 01-c8317c80
[   18.184345] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[  203.691845] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[  203.698361] brcmfmac: brcmf_add_if: ignore IF event
[  203.866214] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[  203.872750] brcmfmac: brcmf_add_if: ignore IF event
[  203.932492] brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, 
-52
[  204.088635] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[  204.095205] brcmfmac: brcmf_add_if: ignore IF event


hostapd.conf
Description: Binary data

[PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive

2015-07-09 Thread Vineet Gupta

There's already a generic implementation so use that instead.
---
I'm not sure if the driver usage of atomic_or?() is correct in terms of
storage size of @val for 64 bit arches.

Assuming LP64 programming model for linux on say x86_64: atomic_or()
callers in this driver use long (sana 64 bit) storage and pass it to
atomic_orr/atomic_or which downcasts it to 32 bits. Is that OK ?
---
Cc: Brett Rudley 
Cc: Arend van Spriel 
Cc: "Franky (Zhenhui) Lin" 
Cc: Hante Meuleman 
Cc: Kalle Valo 
Cc: Pieter-Paul Giesberts 
Cc: Daniel Kim 
Cc: linux-wireless@vger.kernel.org
Cc: brcm80211-dev-l...@broadcom.com
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: net...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Vineet Gupta 

Signed-off-by: Vineet Gupta 
---
 drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
index d36f5f3d931b..f990e3d0e696 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
@@ -2564,15 +2564,6 @@ static inline void brcmf_sdio_clrintr(struct brcmf_sdio 
*bus)
}
 }
 
-static void atomic_orr(int val, atomic_t *v)
-{
-   int old_val;
-
-   old_val = atomic_read(v);
-   while (atomic_cmpxchg(v, old_val, val | old_val) != old_val)
-   old_val = atomic_read(v);
-}
-
 static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus)
 {
struct brcmf_core *buscore;
@@ -2595,7 +2586,7 @@ static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus)
if (val) {
brcmf_sdiod_regwl(bus->sdiodev, addr, val, &ret);
bus->sdcnt.f1regdata++;
-   atomic_orr(val, &bus->intstatus);
+   atomic_or(val, &bus->intstatus);
}
 
return ret;
@@ -2712,7 +2703,7 @@ static void brcmf_sdio_dpc(struct brcmf_sdio *bus)
 
/* Keep still-pending events for next scheduling */
if (intstatus)
-   atomic_orr(intstatus, &bus->intstatus);
+   atomic_or(intstatus, &bus->intstatus);
 
brcmf_sdio_clrintr(bus);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ath10k: ensure pktlog disable cmd reaches fw before pdev suspend

2015-07-09 Thread Raja Mani

Found incorrect sequence in ath10k_core_stop() where wmi pktlog
disable cmd is passed from ath10k_debug_stop() to firmware
immediately after wmi pdev suspend cmd. Firmware will not accept
any wmi cmd after receiving wmi pdev suspend cmd.

Fix this issue in ath10k_core_stop() by moving ath10k_debug_stop()
just before sending pdev suspend cmd. So that pktlog disable cmd
will get passed before pdev suspend cmd.

Signed-off-by: Raja Mani 
---
 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index f79fa6c..6d19d3d 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1368,13 +1368,13 @@ int ath10k_wait_for_suspend(struct ath10k *ar, u32 
suspend_opt)
 void ath10k_core_stop(struct ath10k *ar)
 {
lockdep_assert_held(&ar->conf_mutex);
+   ath10k_debug_stop(ar);
 
/* try to suspend target */
if (ar->state != ATH10K_STATE_RESTARTING &&
ar->state != ATH10K_STATE_UTF)
ath10k_wait_for_suspend(ar, WMI_PDEV_SUSPEND_AND_DISABLE_INTR);
 
-   ath10k_debug_stop(ar);
ath10k_hif_stop(ar);
ath10k_htt_tx_free(&ar->htt);
ath10k_htt_rx_free(&ar->htt);
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ath10k: free collected fw stats memory if .pull_fw_stats fails

2015-07-09 Thread Raja Mani

If .pull_fw_stats() fails for some reason while processing
fw stats event, collected pdev/vdev/peer stats just before
the failure should be freed. This is unlikely to happen,
just code review catch.

Signed-off-by: Raja Mani 
---
 drivers/net/wireless/ath/ath10k/debug.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index edf6047..fc6852c 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -321,7 +321,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
struct sk_buff *skb)
ret = ath10k_wmi_pull_fw_stats(ar, skb, &stats);
if (ret) {
ath10k_warn(ar, "failed to pull fw stats: %d\n", ret);
-   goto unlock;
+   goto free;
}
 
/* Stat data may exceed htc-wmi buffer limit. In such case firmware
@@ -384,7 +384,6 @@ free:
ath10k_debug_fw_stats_vdevs_free(&stats.vdevs);
ath10k_debug_fw_stats_peers_free(&stats.peers);
 
-unlock:
spin_unlock_bh(&ar->data_lock);
 }
 
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ath9k: fix moredata flag endianness in cabq tx

While compiling ath9k with some extra flags I've
found that:

 ath9k/xmit.c +2473 ## 16: warning: restricted __le16 degrades to integer
 ath9k/xmit.c +2474 ## 36: warning: invalid assignment: &=
 ath9k/xmit.c +2474 ## 36:left side has type restricted __le16
 ath9k/xmit.c +2474 ## 36:right side has type int

There's no way for frame ftype/stype to be
mistreated as the offending 'moredata' flag when
considering cab queue.

This could've however theoretically led sometimes
to increased power consumption on connected
stations as they would keep their Rx active
waiting for frames that would never come.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath9k/xmit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 3ad79bb4f2c2..d8cc45106f85 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2470,8 +2470,8 @@ void ath_tx_cabq(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
bf = list_first_entry(&bf_q, struct ath_buf, list);
hdr = (struct ieee80211_hdr *) bf->bf_mpdu->data;
 
-   if (hdr->frame_control & IEEE80211_FCTL_MOREDATA) {
-   hdr->frame_control &= ~IEEE80211_FCTL_MOREDATA;
+   if (hdr->frame_control & cpu_to_le16(IEEE80211_FCTL_MOREDATA)) {
+   hdr->frame_control &= ~cpu_to_le16(IEEE80211_FCTL_MOREDATA);
dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
sizeof(*hdr), DMA_TO_DEVICE);
}
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52

On 9 July 2015 at 09:07, Rafał Miłecki  wrote:
> The problem appears when trying to use more than 1 interface. It gets
> created correctly, but setting its MAC fails. It results in wlan0-1
> having the same MAC as wlan0 and finally having two networks (SSIDs)
> using the same MAC. That obviously doesn't work.
>
> The error I see is:
> brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52
> with -52 meaning BCME_IE_NOTFOUND.

I managed to find/guess what exactly BCM43602 firmware rejects. It
doesn't like 2 MAC addresses that differ by the locally administrated
bit only. In my case it was 00:23:6a:a3:7d:95 + 02:23:6a:a3:7d:95.

When I change MAC addresses to some other combination, e.g.:
00:23:6a:a3:7d:95 + 00:23:6a:a3:7d:96
02:23:6a:a3:7d:95 + 00:23:6a:a3:7d:96
it works correctly.

Any idea why Broadcom driver/firmware team decided to reject MAC
address that differ by locally administrated bit only from the already
used one? I don't think there is anything wrong with that in general.

Is there a chance to release fixed firmware?

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/6] ath10k: random fixes 2015-07-09

I've done most of the patches while testing P2P
but they aren't limited to that scope.

There are no inter-dependencies within the patchset
so single patches should be easily cherry-pickable
in case, e.g. some patches raise concerns or are
decided to be dropped during review.


Michal Kazior (6):
  ath10k: don't set cck/ofdm scan flags
  ath10k: limit multi-vif ps more aggresivelly
  ath10k: fix hw roc expiration notifcation
  ath10k: update vdev ps state on start
  ath10k: fix per-vif queue locking
  ath10k: tweak interface combinations

 drivers/net/wireless/ath/ath10k/core.h|   1 +
 drivers/net/wireless/ath/ath10k/mac.c | 115 ++
 drivers/net/wireless/ath/ath10k/mac.h |   6 +-
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |  32 +++--
 drivers/net/wireless/ath/ath10k/wmi.c |   1 -
 5 files changed, 99 insertions(+), 56 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/6] ath10k: fix hw roc expiration notifcation

The expiration function must not be called when
roc is explicitly cancelled by mac80211. However
since fcf9844636be ("ath10k: fix hw roc
expiration") the notification was never sent when
roc actually expired.

This fixes some P2P connection setup issues.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/core.h |  1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 12 +---
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 2e5c935579c4..78e07051b897 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -633,6 +633,7 @@ struct ath10k {
bool is_roc;
int vdev_id;
int roc_freq;
+   bool roc_notify;
} scan;
 
struct {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 115889cb0ff6..a060b7708f4a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3449,14 +3449,13 @@ void __ath10k_scan_finish(struct ath10k *ar)
case ATH10K_SCAN_IDLE:
break;
case ATH10K_SCAN_RUNNING:
-   if (ar->scan.is_roc)
-   ieee80211_remain_on_channel_expired(ar->hw);
-   /* fall through */
case ATH10K_SCAN_ABORTING:
if (!ar->scan.is_roc)
ieee80211_scan_completed(ar->hw,
 (ar->scan.state ==
  ATH10K_SCAN_ABORTING));
+   else if (ar->scan.roc_notify)
+   ieee80211_remain_on_channel_expired(ar->hw);
/* fall through */
case ATH10K_SCAN_STARTING:
ar->scan.state = ATH10K_SCAN_IDLE;
@@ -5459,6 +5458,7 @@ static int ath10k_remain_on_channel(struct ieee80211_hw 
*hw,
ar->scan.is_roc = true;
ar->scan.vdev_id = arvif->vdev_id;
ar->scan.roc_freq = chan->center_freq;
+   ar->scan.roc_notify = true;
ret = 0;
break;
case ATH10K_SCAN_STARTING:
@@ -5522,7 +5522,13 @@ static int ath10k_cancel_remain_on_channel(struct 
ieee80211_hw *hw)
struct ath10k *ar = hw->priv;
 
mutex_lock(&ar->conf_mutex);
+
+   spin_lock_bh(&ar->data_lock);
+   ar->scan.roc_notify = false;
+   spin_unlock_bh(&ar->data_lock);
+
ath10k_scan_abort(ar);
+
mutex_unlock(&ar->conf_mutex);
 
cancel_delayed_work_sync(&ar->scan.timeout);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/6] ath10k: tweak interface combinations

Concurrent AP/GO operation on different channels
isn't really supported well by the firmware so
it's better to remove it from being advertised.

Also tune the way station and p2p client interface
limits are expressed to allow station + 2x p2p
client or station + p2p client + p2p go.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/mac.c | 39 ++-
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 0ef568c36db9..c41b34843a82 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6557,8 +6557,11 @@ static const struct ieee80211_iface_combination 
ath10k_10x_if_comb[] = {
 static const struct ieee80211_iface_limit ath10k_tlv_if_limit[] = {
{
.max = 2,
-   .types = BIT(NL80211_IFTYPE_STATION) |
-BIT(NL80211_IFTYPE_AP) |
+   .types = BIT(NL80211_IFTYPE_STATION),
+   },
+   {
+   .max = 2,
+   .types = BIT(NL80211_IFTYPE_AP) |
 BIT(NL80211_IFTYPE_P2P_CLIENT) |
 BIT(NL80211_IFTYPE_P2P_GO),
},
@@ -6568,6 +6571,26 @@ static const struct ieee80211_iface_limit 
ath10k_tlv_if_limit[] = {
},
 };
 
+static const struct ieee80211_iface_limit ath10k_tlv_qcs_if_limit[] = {
+   {
+   .max = 2,
+   .types = BIT(NL80211_IFTYPE_STATION),
+   },
+   {
+   .max = 2,
+   .types = BIT(NL80211_IFTYPE_P2P_CLIENT),
+   },
+   {
+   .max = 1,
+   .types = BIT(NL80211_IFTYPE_AP) |
+BIT(NL80211_IFTYPE_P2P_GO),
+   },
+   {
+   .max = 1,
+   .types = BIT(NL80211_IFTYPE_P2P_DEVICE),
+   },
+};
+
 static const struct ieee80211_iface_limit ath10k_tlv_if_limit_ibss[] = {
{
.max = 1,
@@ -6586,7 +6609,7 @@ static struct ieee80211_iface_combination 
ath10k_tlv_if_comb[] = {
{
.limits = ath10k_tlv_if_limit,
.num_different_channels = 1,
-   .max_interfaces = 3,
+   .max_interfaces = 4,
.n_limits = ARRAY_SIZE(ath10k_tlv_if_limit),
},
{
@@ -6600,9 +6623,15 @@ static struct ieee80211_iface_combination 
ath10k_tlv_if_comb[] = {
 static struct ieee80211_iface_combination ath10k_tlv_qcs_if_comb[] = {
{
.limits = ath10k_tlv_if_limit,
+   .num_different_channels = 1,
+   .max_interfaces = 4,
+   .n_limits = ARRAY_SIZE(ath10k_tlv_if_limit),
+   },
+   {
+   .limits = ath10k_tlv_qcs_if_limit,
.num_different_channels = 2,
-   .max_interfaces = 3,
-   .n_limits = ARRAY_SIZE(ath10k_tlv_if_limit),
+   .max_interfaces = 4,
+   .n_limits = ARRAY_SIZE(ath10k_tlv_qcs_if_limit),
},
{
.limits = ath10k_tlv_if_limit_ibss,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/6] ath10k: don't set cck/ofdm scan flags

mac80211 already does provide complete IEs for
Probe Requests for hw scan and ath10k firmware was
appending duplicate Supported Rates IEs
unnecessarily.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/mac.c | 3 ---
 drivers/net/wireless/ath/ath10k/wmi.c | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index b5b74e84ad16..63c59593494e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4641,9 +4641,6 @@ static int ath10k_hw_scan(struct ieee80211_hw *hw,
arg.vdev_id = arvif->vdev_id;
arg.scan_id = ATH10K_SCAN_ID;
 
-   if (!req->no_cck)
-   arg.scan_ctrl_flags |= WMI_SCAN_ADD_CCK_RATES;
-
if (req->ie_len) {
arg.ie_len = req->ie_len;
memcpy(arg.ie, req->ie, arg.ie_len);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 638332e96931..0791a4336e80 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5180,7 +5180,6 @@ void ath10k_wmi_start_scan_init(struct ath10k *ar,
| WMI_SCAN_EVENT_BSS_CHANNEL
| WMI_SCAN_EVENT_FOREIGN_CHANNEL
| WMI_SCAN_EVENT_DEQUEUED;
-   arg->scan_ctrl_flags |= WMI_SCAN_ADD_OFDM_RATES;
arg->scan_ctrl_flags |= WMI_SCAN_CHAN_STAT_EVENT;
arg->n_bssids = 1;
arg->bssids[0].bssid = "\xFF\xFF\xFF\xFF\xFF\xFF";
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/6] ath10k: update vdev ps state on start

Psmode can be forcefully enabled when vdev isn't
started. It isn't guaranteed that mac80211 will
re-issue psmode setting after vdev is started
unless actual bss_conf.ps value has changed.

Even if this doesn't fix any problems now it may
prevent future breakage.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/mac.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index a060b7708f4a..e25e6a8f44a5 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6222,6 +6222,13 @@ ath10k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
 
arvif->is_started = true;
 
+   ret = ath10k_mac_vif_setup_ps(arvif);
+   if (ret) {
+   ath10k_warn(ar, "failed to update vdev %i ps: %d\n",
+   arvif->vdev_id, ret);
+   goto err_stop;
+   }
+
if (vif->type == NL80211_IFTYPE_MONITOR) {
ret = ath10k_wmi_vdev_up(ar, arvif->vdev_id, 0, vif->addr);
if (ret) {
@@ -6239,6 +6246,7 @@ ath10k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
 err_stop:
ath10k_vdev_stop(arvif);
arvif->is_started = false;
+   ath10k_mac_vif_setup_ps(arvif);
 
 err:
mutex_unlock(&ar->conf_mutex);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/6] ath10k: limit multi-vif ps more aggresivelly

Further testing proved that multi-channel AP+STA
on QCA6174 with RM.2.0-00088 should have powersave
force-disabled to avoid beacon misses/skipping on
either side which in turn could disrupt
communication.

Since AP never has arvif->ps don't even bother
checking it. Other combinations may be broken as
well so disallow powersave with multivif outright
unless firmware advertises otherwise.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/mac.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 63c59593494e..115889cb0ff6 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1668,7 +1668,7 @@ static int ath10k_mac_vif_recalc_ps_poll_count(struct 
ath10k_vif *arvif)
return 0;
 }
 
-static int ath10k_mac_ps_vif_count(struct ath10k *ar)
+static int ath10k_mac_num_vifs_started(struct ath10k *ar)
 {
struct ath10k_vif *arvif;
int num = 0;
@@ -1676,7 +1676,7 @@ static int ath10k_mac_ps_vif_count(struct ath10k *ar)
lockdep_assert_held(&ar->conf_mutex);
 
list_for_each_entry(arvif, &ar->arvifs, list)
-   if (arvif->ps)
+   if (arvif->is_started)
num++;
 
return num;
@@ -1700,7 +1700,7 @@ static int ath10k_mac_vif_setup_ps(struct ath10k_vif 
*arvif)
 
enable_ps = arvif->ps;
 
-   if (enable_ps && ath10k_mac_ps_vif_count(ar) > 1 &&
+   if (enable_ps && ath10k_mac_num_vifs_started(ar) > 1 &&
!test_bit(ATH10K_FW_FEATURE_MULTI_VIF_PS_SUPPORT,
  ar->fw_features)) {
ath10k_warn(ar, "refusing to enable ps on vdev %i: not 
supported by fw\n",
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/6] ath10k: fix per-vif queue locking

Whenever any vdev was supposed to be paused all Tx
queues were stopped (except offchannel) instead of
only these associated with the given vdev.

This caused subtle issues with
multi-channel/multi-vif scenarios, e.g.
authentication of station vif could sometimes fail
depending on fw tx pause request timing.

Fixes: b4aa539dd8f2 ("ath10k: implement tx pause wmi event")
Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/mac.c | 47 +--
 drivers/net/wireless/ath/ath10k/mac.h |  6 ++--
 drivers/net/wireless/ath/ath10k/wmi-tlv.c | 32 +
 3 files changed, 44 insertions(+), 41 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index e25e6a8f44a5..0ef568c36db9 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3034,38 +3034,16 @@ static void ath10k_mac_vif_handle_tx_pause(struct 
ath10k_vif *arvif,
 
lockdep_assert_held(&ar->htt.tx_lock);
 
-   switch (pause_id) {
-   case WMI_TLV_TX_PAUSE_ID_MCC:
-   case WMI_TLV_TX_PAUSE_ID_P2P_CLI_NOA:
-   case WMI_TLV_TX_PAUSE_ID_P2P_GO_PS:
-   case WMI_TLV_TX_PAUSE_ID_AP_PS:
-   case WMI_TLV_TX_PAUSE_ID_IBSS_PS:
-   switch (action) {
-   case WMI_TLV_TX_PAUSE_ACTION_STOP:
-   ath10k_mac_vif_tx_lock(arvif, pause_id);
-   break;
-   case WMI_TLV_TX_PAUSE_ACTION_WAKE:
-   ath10k_mac_vif_tx_unlock(arvif, pause_id);
-   break;
-   default:
-   ath10k_warn(ar, "received unknown tx pause action %d on 
vdev %i, ignoring\n",
-   action, arvif->vdev_id);
-   break;
-   }
+   switch (action) {
+   case WMI_TLV_TX_PAUSE_ACTION_STOP:
+   ath10k_mac_vif_tx_lock(arvif, pause_id);
+   break;
+   case WMI_TLV_TX_PAUSE_ACTION_WAKE:
+   ath10k_mac_vif_tx_unlock(arvif, pause_id);
break;
-   case WMI_TLV_TX_PAUSE_ID_AP_PEER_PS:
-   case WMI_TLV_TX_PAUSE_ID_AP_PEER_UAPSD:
-   case WMI_TLV_TX_PAUSE_ID_STA_ADD_BA:
-   case WMI_TLV_TX_PAUSE_ID_HOST:
default:
-   /* FIXME: Some pause_ids aren't vdev specific. Instead they
-* target peer_id and tid. Implementing these could improve
-* traffic scheduling fairness across multiple connected
-* stations in AP/IBSS modes.
-*/
-   ath10k_dbg(ar, ATH10K_DBG_MAC,
-  "mac ignoring unsupported tx pause vdev %i id %d\n",
-  arvif->vdev_id, pause_id);
+   ath10k_warn(ar, "received unknown tx pause action %d on vdev 
%i, ignoring\n",
+   action, arvif->vdev_id);
break;
}
 }
@@ -3082,12 +3060,15 @@ static void ath10k_mac_handle_tx_pause_iter(void *data, 
u8 *mac,
struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
struct ath10k_mac_tx_pause *arg = data;
 
+   if (arvif->vdev_id != arg->vdev_id)
+   return;
+
ath10k_mac_vif_handle_tx_pause(arvif, arg->pause_id, arg->action);
 }
 
-void ath10k_mac_handle_tx_pause(struct ath10k *ar, u32 vdev_id,
-   enum wmi_tlv_tx_pause_id pause_id,
-   enum wmi_tlv_tx_pause_action action)
+void ath10k_mac_handle_tx_pause_vdev(struct ath10k *ar, u32 vdev_id,
+enum wmi_tlv_tx_pause_id pause_id,
+enum wmi_tlv_tx_pause_action action)
 {
struct ath10k_mac_tx_pause arg = {
.vdev_id = vdev_id,
diff --git a/drivers/net/wireless/ath/ath10k/mac.h 
b/drivers/net/wireless/ath/ath10k/mac.h
index b291f063705c..e3cefe4c7cfd 100644
--- a/drivers/net/wireless/ath/ath10k/mac.h
+++ b/drivers/net/wireless/ath/ath10k/mac.h
@@ -61,9 +61,9 @@ int ath10k_mac_vif_chan(struct ieee80211_vif *vif,
 
 void ath10k_mac_handle_beacon(struct ath10k *ar, struct sk_buff *skb);
 void ath10k_mac_handle_beacon_miss(struct ath10k *ar, u32 vdev_id);
-void ath10k_mac_handle_tx_pause(struct ath10k *ar, u32 vdev_id,
-   enum wmi_tlv_tx_pause_id pause_id,
-   enum wmi_tlv_tx_pause_action action);
+void ath10k_mac_handle_tx_pause_vdev(struct ath10k *ar, u32 vdev_id,
+enum wmi_tlv_tx_pause_id pause_id,
+enum wmi_tlv_tx_pause_action action);
 
 u8 ath10k_mac_hw_rate_to_idx(const struct ieee80211_supported_band *sband,
 u8 hw_rate);
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index ced35a1e0675..4189d4a90ce0 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath

Re: [PATCH 11/13] wil6210: TSO implementation

2015-07-09 Thread Vladimir Kondratiev

On Wednesday, July 08, 2015 10:06:37 PM Emmanuel Grumbach wrote:
> So your device is able to replicate and update the IP / TCP header?
> I don't really follow what your device is able to do.
> You seem to be cutting the frags so that their length sums up to mss.
> Which hints that your device can't segment the buffer by itself. OTOH,
> I don't see how you treat the IP / TCP header copy and modification.
> 
Emmanuel:
Yes, it is correct - hardware know to replicate IP/TCP header; and
DMA written in such a way that I have to arrange fragments to
sums up to MSS.

So this code fragment is OK. We tested it with lots of traffic.
However, after your comments for another code fragment,
I found there is a way to do it better. I'll rework and send updated patch.

Kalle: please drop this patch. The rest of patches should apply cleanly
without this one.

Thanks, Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ath9k: setup rxfilter when offchannel

2015-07-09 Thread Janusz Dziedzic

Setup rxfiler correctly for offchannel ctx.

This fix problem we didn't configure rxfilter, next
didn't receive probe requests and next failed
p2p_find. This was seen when ath9k loaded with
use_chanctx=1

Signed-off-by: Janusz Dziedzic 
---
 drivers/net/wireless/ath/ath9k/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/main.c 
b/drivers/net/wireless/ath/ath9k/main.c
index 3de829f..b45084d 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1468,6 +1468,7 @@ static void ath9k_configure_filter(struct ieee80211_hw 
*hw,
spin_lock_bh(&sc->chan_lock);
ath_for_each_chanctx(sc, ctx)
ctx->rxfilter = *total_flags;
+   sc->offchannel.chan.rxfilter = *total_flags;
spin_unlock_bh(&sc->chan_lock);
 
ath9k_ps_wakeup(sc);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ath9k: setup rxfilter for all chanctx

2015-07-09 Thread Janusz Dziedzic

While mac80211 setup this per HW, set same
rxfilter configuration for all chanctx.

Signed-off-by: Janusz Dziedzic 
---
 drivers/net/wireless/ath/ath9k/main.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/main.c 
b/drivers/net/wireless/ath/ath9k/main.c
index b7b77e0..3de829f 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1459,13 +1459,15 @@ static void ath9k_configure_filter(struct ieee80211_hw 
*hw,
   u64 multicast)
 {
struct ath_softc *sc = hw->priv;
+   struct ath_chanctx *ctx;
u32 rfilt;
 
changed_flags &= SUPPORTED_FILTERS;
*total_flags &= SUPPORTED_FILTERS;
 
spin_lock_bh(&sc->chan_lock);
-   sc->cur_chan->rxfilter = *total_flags;
+   ath_for_each_chanctx(sc, ctx)
+   ctx->rxfilter = *total_flags;
spin_unlock_bh(&sc->chan_lock);
 
ath9k_ps_wakeup(sc);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52

On 9 July 2015 at 12:38, Rafał Miłecki  wrote:
> On 9 July 2015 at 09:07, Rafał Miłecki  wrote:
>> The problem appears when trying to use more than 1 interface. It gets
>> created correctly, but setting its MAC fails. It results in wlan0-1
>> having the same MAC as wlan0 and finally having two networks (SSIDs)
>> using the same MAC. That obviously doesn't work.
>>
>> The error I see is:
>> brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52
>> with -52 meaning BCME_IE_NOTFOUND.
>
> I managed to find/guess what exactly BCM43602 firmware rejects. It
> doesn't like 2 MAC addresses that differ by the locally administrated
> bit only. In my case it was 00:23:6a:a3:7d:95 + 02:23:6a:a3:7d:95.
>
> When I change MAC addresses to some other combination, e.g.:
> 00:23:6a:a3:7d:95 + 00:23:6a:a3:7d:96
> 02:23:6a:a3:7d:95 + 00:23:6a:a3:7d:96
> it works correctly.

Oh, it appeared to be more tricky. What BCM43602 firmware doesn't
allow is using the same value in the last 2 bits for different BSSes.

Few examples:
00:23:6a:a3:7d:90 + 00:23:6a:a3:7d:91 is GOOD
00:23:6a:a3:7d:90 + 00:23:6a:a3:7d:93 is GOOD
00:23:6a:a3:7d:90 + 00:23:6a:a3:7d:94 is BAD (last two bits are 0x0)
00:23:6a:a3:7d:92 + 00:23:6a:a3:7d:9a is BAD (last two bits are 0x2)

What's weird, all other numbers can be used as you want:
00:23:6A:A3:7D:90 + 00:7D:A3:6A:23:92 is GOOD

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/13] wil6210: TSO implementation

2015-07-09 Thread Emmanuel Grumbach

On Thu, Jul 9, 2015 at 2:37 PM, Vladimir Kondratiev
 wrote:
> On Wednesday, July 08, 2015 10:06:37 PM Emmanuel Grumbach wrote:
>> So your device is able to replicate and update the IP / TCP header?
>> I don't really follow what your device is able to do.
>> You seem to be cutting the frags so that their length sums up to mss.
>> Which hints that your device can't segment the buffer by itself. OTOH,
>> I don't see how you treat the IP / TCP header copy and modification.
>>
> Emmanuel:
> Yes, it is correct - hardware know to replicate IP/TCP header; and
> DMA written in such a way that I have to arrange fragments to
> sums up to MSS.

Ok - thanks for clarifying this.

>
> So this code fragment is OK. We tested it with lots of traffic.
> However, after your comments for another code fragment,
> I found there is a way to do it better. I'll rework and send updated patch.
>

I am working on something similar but our hardware does nothing for
us. I hope to send my version next week as an RFC.

> Kalle: please drop this patch. The rest of patches should apply cleanly
> without this one.
>
> Thanks, Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Association race when acting as AP?

On 7 July 2015 at 17:00, Jouni Malinen  wrote:
> On Thu, Jul 02, 2015 at 10:24:33AM +0200, Michal Kazior wrote:
>> After looking into hostapd code I noticed something strange and I wonder if
>> anyone else is already aware of this problem:
>>
>>  1. AP starts
>>  2. STA->AP auth OTA
>>  3. AP->STA auth OTA
>>  4. STA->AP assoc req OTA
>>  5. AP->STA assoc resp OTA
>>  6. STA sends NullFunc with "STA will go to sleep" bit set
>>  7. AP driver/device sees a frame from with unknown TA/SA and issues Deauth
>> w/ Reason 7
>>(this Deauth doesn't originate from hostapd; it comes from the device FW
>> in my case)
>
> If there is a driver or firmware design that sends these
> Deauthentication frames on their own, they better be able to handle race
> conditions and enable this functionality at the correct time..

At least one ath10k qca61x4 firmware seems to send Deauth when it gets
a NullFunc from DA which doesn't have an internal peer entry. It
doesn't seem to care whether peer is authenticated or associated
though. Probably having none->auth, auth->assoc state transitions
(instead of a single none->assoc) would be enough - at least for
ath10k today.


> Sure,
> cfg80211 and hostapd may need modifications to make this work better,
> but this needs to be done for things to work properly. There's a good
> reason for hostapd having code to check the internal STA associated
> flag before triggering deauthentication based on EVENT_RX_FROM_UNKNOWN
> events..
>
>> To me this looks like a race in hostapd. The station should be installed to
>> driver _before_ sending Assoc Resp frame, not after. My quick-n-dirty hack
>> seems to help:
>
> Adding a STA entry before sending Association Response frame would be
> fine, but this change would do more: it would claim that STA entry to be
> in associated state. That is not correct from the IEEE 802.11 standard
> view point. On the AP side, a STA becomes associated when an ACK frame
> to the (Re)Association Response frame is received by the AP.

This seems pretty racy inherently. Driver/firmware actually needs to
be aware of this requirement and make sure to avoid reordering Tx ACK
processing and Rx. Since Tx/Rx engines are often (if not always?)
independent of each other I imagine this could be a common problem
across many devices today but perhaps not easily observable due to
narrow time window this could happen in.

Anyway - thank you for your great insight!


Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] brcmfmac: set wiphy's addr_mask to force using valid MACs

Broadcom's firmware requires every BSS to use MAC address with unique
last 2 bits. Otherwise it rejects submitted MAC which results in:
brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52

Set addr_mask properly to hint only last 2 bits can be modified. This
isn't exactly true as all bits can be changed but that's the only way
to force unique values in the last 2 bits.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
index d86d1f1..4ab1d92 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
@@ -6100,6 +6100,11 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct 
brcmf_pub *drvr,
return NULL;
}
memcpy(wiphy->perm_addr, drvr->mac, ETH_ALEN);
+   /* Firmware requires last 2 bits to contain unique value for every BSS.
+* Unfortunately this will also disallow changing other bits (firmware
+* supports it as long as last 2 bits are unique) but it's the only way.
+*/
+   wiphy->addr_mask[ETH_ALEN - 1] = 0x02;
set_wiphy_dev(wiphy, busdev);
 
cfg = wiphy_priv(wiphy);
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: wireless: reduce log level of CRDA related messages

2015-07-09 Thread Thomas Petazzoni

With a basic Linux userspace, the messages "Calling CRDA to update
world regulatory domain" appears 10 times after boot every second or
so, followed by a final "Exceeded CRDA call max attempts. Not calling
CRDA". For those of us not having the corresponding userspace parts,
having those messages repeatedly displayed at boot time is a bit
annoying, so this commit reduces their log level to pr_debug().

Signed-off-by: Thomas Petazzoni 
---
 net/wireless/reg.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index d359e06..29134c8 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -544,15 +544,15 @@ static int call_crda(const char *alpha2)
reg_regdb_query(alpha2);
 
if (reg_crda_timeouts > REG_MAX_CRDA_TIMEOUTS) {
-   pr_info("Exceeded CRDA call max attempts. Not calling CRDA\n");
+   pr_debug("Exceeded CRDA call max attempts. Not calling CRDA\n");
return -EINVAL;
}
 
if (!is_world_regdom((char *) alpha2))
-   pr_info("Calling CRDA for country: %c%c\n",
+   pr_debug("Calling CRDA for country: %c%c\n",
alpha2[0], alpha2[1]);
else
-   pr_info("Calling CRDA to update world regulatory domain\n");
+   pr_debug("Calling CRDA to update world regulatory domain\n");
 
return kobject_uevent_env(®_pdev->dev.kobj, KOBJ_CHANGE, env);
 }
-- 
2.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel BUG in rtl92s_phy_chk_fwcmd_iodone():<0-0> Set FW Cmd fail

2015-07-09 Thread Christian Lamparter

On Tuesday, July 07, 2015 11:56:21 PM Szőts Ákos wrote:
> I have an RTL8191SU 802.11n USB WLAN Adapter with rtl8192su driver. 
> Unfortunately, I have to turn it off and on sometimes to make it work. I use 
> NetworkManager with KDE 5 nm-applet in which I simply turn off the wireless 
> capability then on again.
> 
> Once I did this, I got a kernel BUG. Here is the link for the full text: 
> http://paste.opensuse.org/view/simple/25089935

This message lets you know that a firmware command has timed out.
A call trace is included to let you know what the driver was doing
at the time. If this problem bothers you, the information from the
trace should help to debug it and make a patch.
 
> kernel: rtl8192s_common:rtl92s_phy_chk_fwcmd_iodone():<0-0> Set FW Cmd fail!!
> kernel: [ cut here ]
> kernel: WARNING: CPU: 3 PID: 1105 at 
> /home/aki/temp/rtl8192su/rtlwifi/rtl8192s/phy_common.c:1192 
> rtl92s_phy_chk_fwcmd_iodone+0x65/0xb0 [rtl8192s_common]()
> kernel: Modules linked in: rtl8192su(O) rtl8192s_common(O) rtl_usb(O) 
> rtlwifi(O)...
> kernel: Call Trace:
> kernel:  [] dump_stack+0x4c/0x6e
> kernel:  [] warn_slowpath_common+0x8a/0xc0
> kernel:  [] warn_slowpath_null+0x1a/0x20
> kernel:  [] rtl92s_phy_chk_fwcmd_iodone+0x65/0xb0 
> [rtl8192s_common]
> kernel:  [] _rtl92s_phy_set_fwcmd_io+0xe1/0x670 
> [rtl8192s_common]
> kernel:  [] rtl92s_phy_set_fw_cmd+0xb9/0x7b0 
> [rtl8192s_common]
> kernel:  [] rtl92s_phy_scan_operation_backup+0x3a/0x90 
> [rtl8192s_common]
> kernel:  [] rtl_op_sw_scan_start+0xa9/0x170 [rtlwifi]

Regards,
Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless-regdb: update CA rules for 5600 - 5650 mHz

2015-07-09 Thread Seth Forshee

On Wed, Jul 08, 2015 at 12:19:18PM +0200, Zefir Kurtisi wrote:
> My claim is that in its current state the regdb does not exactly formalize the
> limitations given by regulatory for a simple reason: it uses channel semantics
> where it should only handle frequency ranges. Take the discussed rules for CA 
> at
> hand: while the linked document considers frequencies from 5150 to 5350, the
> according rule for CA is defined as (5170 - 5250 @ 80). Why 5170 instead of 
> 5150?
> Because we know there is no channel defined below 5170 - but why do we need to
> embed this information as a rule when it is already handled by SW?
> 
> In the current regdb, both semantics are used, e.g. UA (5150-5350) vs. CA
> (5170-5250) or ES (5470-5725) vs. FI (5490-5710)).

I'm not surprised. I don't know that anyone has given it that much
thought before.

> This might sound like an irrelevant difference, but here is why it matters: 
> the
> above mentioned rules for ES and FI would give the same channel lists - as 
> long as
> we think in HT20 and HT40. But only ES gives access to 10 and 5MHz operation 
> on
> channel 144.

Good example.

> My bottom line is: regulatory rules must not contain channel semantics - this 
> is
> done by the SW. Rules must be a literal formalization of the country's 
> regulatory,
> which always uses frequency ranges within defined band edges.

I'm generally in agreement. I'll try to pay closer attention to this in
the future.

> Sorry for this going off-topic. It has nothing to do with the changes 
> proposed by
> Wei, but is more about something to keep in mind when considering upcoming 
> support
> for narrow band channels at band edges.

Except that it seems to have inspired Wei to change the patch to do
exactly what you're arguing against ;-)

Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: set wiphy's addr_mask to force using valid MACs

On 9 July 2015 at 14:46, Rafał Miłecki  wrote:
> Broadcom's firmware requires every BSS to use MAC address with unique
> last 2 bits. Otherwise it rejects submitted MAC which results in:
> brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52
>
> Set addr_mask properly to hint only last 2 bits can be modified. This
> isn't exactly true as all bits can be changed but that's the only way
> to force unique values in the last 2 bits.

I asked Felix about this and he pointed it may be not a good idea to
disallow using locally administrated bit.

I'll rework my fix to provide a full list of addresses that shall be
used. Please drop this one.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] brcmfmac: set wiphy's addresses to provide valid MACs

Broadcom's firmware requires every BSS to use MAC address with unique
last few bits. The amount of bits may depend on a particular firmware,
it was verified to be 2 for BCM43602 one.
If this condition won't be fulfilled firmware will reject such MAC:
brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52

We don't want to simply set addr_mask as it would also disallow using
locally administrated bit. Instead let's build a list of addresses
manually enabling 0x2 bit for extra interfaces.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 14 ++
 drivers/net/wireless/brcm80211/brcmfmac/core.h |  3 +++
 2 files changed, 17 insertions(+)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
index d86d1f1..ffe5260 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
@@ -5785,6 +5785,7 @@ static void brcmf_wiphy_wowl_params(struct wiphy *wiphy)
 
 static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp)
 {
+   struct brcmf_pub *drvr = ifp->drvr;
struct ieee80211_supported_band *band;
__le32 bandlist[3];
u32 n_bands;
@@ -5798,6 +5799,19 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct 
brcmf_if *ifp)
if (err)
return err;
 
+   for (i = 0; i < wiphy->iface_combinations->max_interfaces &&
+i < ARRAY_SIZE(drvr->addresses); i++) {
+   u8 *addr = drvr->addresses[i].addr;
+
+   memcpy(addr, drvr->mac, ETH_ALEN);
+   if (i) {
+   addr[0] |= BIT(1);
+   addr[ETH_ALEN - 1] ^= i;
+   }
+   }
+   wiphy->addresses = drvr->addresses;
+   wiphy->n_addresses = i;
+
wiphy->signal_type = CFG80211_SIGNAL_TYPE_MBM;
wiphy->cipher_suites = __wl_cipher_suites;
wiphy->n_cipher_suites = ARRAY_SIZE(__wl_cipher_suites);
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/core.h 
b/drivers/net/wireless/brcm80211/brcmfmac/core.h
index fd74a9c..7463041 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/core.h
+++ b/drivers/net/wireless/brcm80211/brcmfmac/core.h
@@ -21,6 +21,7 @@
 #ifndef BRCMFMAC_CORE_H
 #define BRCMFMAC_CORE_H
 
+#include 
 #include "fweh.h"
 
 #define TOE_TX_CSUM_OL 0x0001
@@ -118,6 +119,8 @@ struct brcmf_pub {
/* Multicast data packets sent to dongle */
unsigned long tx_multicast;
 
+   struct mac_address addresses[BRCMF_MAX_IFS];
+
struct brcmf_if *iflist[BRCMF_MAX_IFS];
 
struct mutex proto_block;
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: Update regulatory rules for Taiwan (TW)

2015-07-09 Thread Seth Forshee

On Wed, Jul 08, 2015 at 11:07:20AM +0800, Chen-Yu Tsai wrote:
> > Thanks. I think there should be a written document about what the
> > rules should be like, or what is expected:
> >
> >   1. WiFi channel boundaries or band boundaries
> >   2. peak output power or peak power spectral density
> >
> > In http://lists.infradead.org/pipermail/wireless-regdb/2015-July/000856.html
> > you mentioned the software is smart enough to work out how to combine
> > different bands and what channels to use, so I see no reason to explicitly
> > chop up contiguous spectrum, unless there are explicit rules forbidding
> > combined use of bands with different regulatory rules. AFAIK the FCC
> > only requires one to satisfy all rules when usage crosses band boundaries.
> >
> > http://lists.infradead.org/pipermail/wireless-regdb/2015-July/000857.html
> > also raises a similar question.

I was really commenting about the transmit power updates in your patch.
I just compared the frequency changes to the documentation you linked to
and those do look okay to me.

> >> I would however consider an update for 5.15-5.25 GHz and 5.6-5.65 GHz
> >> provided that there's official documentation to substantiate the change.
> >> I unfortunately cannot read Chinese, so I would need some assistance to
> >> confirm the documentation.
> >
> > I could possibly ask around, though I'm not optimistic. The "official"
> > documents are just transcripts from NCC hosted Q&A sessions regarding
> > the latest regulations. Proposals/questions are submitted by vendors,
> > and the NCC responds and puts together an aggregated transcript.
> 
> Just got off the phone with the NCC. Their position is, spectrum allocation
> is not within their purview, but the Ministry of Transportation and
> Communications. As noted in the patch, they have already opened up the
> spectrum to U-NII and low power radio usage. What remains is that the
> NCC revise its testing standards. Until then, their position is that,
> since their testing standards are modeled after FCC standards, vendors
> can just test under FCC standards, then convert the reports into LP0002
> format, and cite the FCC test report.
> 
> There is no formal English version of the Q&A transcript, at least not
> until some foreign testing body requests it. The person in charge just
> asked me to translate it myself...

If you send a patch which updates only the frequencies I would likely
apply that after allowing a week or so for others to either ack or nack
it (and running the stuff you linked to through google translate and
seeing if I could make any sense of the output).

I think the power updates are probably based on a misunderstanding, and
may not even be completely correct. For the most part after they've been
converted to EIRP (eirp = 10 * log10(mW)) they don't turn out to be
substantially different than what we have now. I think the value in
5250-5350 MHz is probably incorrect however. Based on my quick skim of
the document you linked to it should be 50 mW rather than 250. 50 mW
also roughly matches to the 17 dBm which is in the database today,
whereas 250 mW is closer to 24 dBm.

My suggestion would be update the frequencies but not the existing
transmit power limits, unless you discover that any of the power limits
are definitely incorrect.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] Add new mac80211 driver mwlwifi.

2015-07-09 Thread Maxime Bizon

On Fri, 2015-07-03 at 06:10 +, David Lin wrote:

Hello,

> The Linux driver for WRT1900AC. The work was initially developed as
> part of openwrt effort and maintained on
> https://github.com/kaloz/mwlwifi.

I see *massive* code duplication with the mwl8k driver.

This is, I guess, not a surprise since the supported chipset are an
evolution of the ones supported by mwl8k, just look at how close/similar
the descriptor format is.

The problem is that each new Marvell chipset comes with a new firmware
version, and there is no effort to have a common firmware API or code
base that supports multiple chipsets.

That pushes the bloat on the kernel side, do we really agree on that ?

-- 
Maxime

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4 v2] staging: vt6655: Fix missing power saving support

Add IEEE80211_HW_SUPPORTS_PS to ieee80211_hw flags
enabling this feature.

Signed-off-by: Malcolm Priestley 

---
v2 rebased for 4.2

 drivers/staging/vt6655/device_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index b0c8e23..e78bd5e 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1811,6 +1811,7 @@ vt6655_probe(struct pci_dev *pcid, const struct 
pci_device_id *ent)
ieee80211_hw_set(priv->hw, SIGNAL_DBM);
ieee80211_hw_set(priv->hw, RX_INCLUDES_FCS);
ieee80211_hw_set(priv->hw, REPORTS_TX_ACK_STATUS);
+   ieee80211_hw_set(priv->hw, SUPPORTS_PS);
 
priv->hw->max_signal = 100;
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] staging: vt6655: vnt_tx_packet don't wakeup from power saving.

mac80211 changes the wake state before attempting to tx data

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/device_main.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index e78bd5e..c245dea 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1211,9 +1211,6 @@ static int vnt_tx_packet(struct vnt_private *priv, struct 
sk_buff *skb)
 
vnt_generate_fifo_header(priv, dma_idx, head_td, skb);
 
-   if (MACbIsRegBitsOn(priv->PortOffset, MAC_REG_PSCTL, PSCTL_PS))
-   MACbPSWakeup(priv->PortOffset);
-
spin_lock_irqsave(&priv->lock, flags);
 
priv->bPWBitOn = false;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] staging: vt6655: Correct listen interval TBTT wake up

PSbIsNextTBTTWakeUp is called at beacon intervals.

The should listen to next beacon on count down of wake_up_count == 1.

This restores this back to vendors code but modified for mac80211.

Signed-off-by: Malcolm Priestley 
---
 drivers/staging/vt6655/device.h |  1 +
 drivers/staging/vt6655/power.c  | 16 
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/vt6655/device.h b/drivers/staging/vt6655/device.h
index 5cf1b33..6aebb49 100644
--- a/drivers/staging/vt6655/device.h
+++ b/drivers/staging/vt6655/device.h
@@ -403,6 +403,7 @@ struct vnt_private {
unsigned char abyEEPROM[EEP_MAX_CONTEXT_SIZE]; /* unsigned long 
alignment */
 
unsigned short wBeaconInterval;
+   u16 wake_up_count;
 
struct work_struct interrupt_work;
 
diff --git a/drivers/staging/vt6655/power.c b/drivers/staging/vt6655/power.c
index be3c4e9..06e6b9d 100644
--- a/drivers/staging/vt6655/power.c
+++ b/drivers/staging/vt6655/power.c
@@ -157,10 +157,18 @@ PSbIsNextTBTTWakeUp(
struct ieee80211_conf *conf = &hw->conf;
bool bWakeUp = false;
 
-   if (conf->listen_interval == 1) {
-   /* Turn on wake up to listen next beacon */
-   MACvRegBitsOn(pDevice->PortOffset, MAC_REG_PSCTL, PSCTL_LNBCN);
-   bWakeUp = true;
+   if (conf->listen_interval > 1) {
+   if (!pDevice->wake_up_count)
+   pDevice->wake_up_count = conf->listen_interval;
+
+   --pDevice->wake_up_count;
+
+   if (pDevice->wake_up_count == 1) {
+   /* Turn on wake up to listen next beacon */
+   MACvRegBitsOn(pDevice->PortOffset,
+ MAC_REG_PSCTL, PSCTL_LNBCN);
+   bWakeUp = true;
+   }
}
 
return bWakeUp;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] staging: vt6655: check ieee80211_bss_conf bssid not NULL

Sometimes bssid can go null on failed association.

Signed-off-by: Malcolm Priestley 
Cc:  # v3.19+
---
 drivers/staging/vt6655/device_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index ed040fb..b0c8e23 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1418,7 +1418,7 @@ static void vnt_bss_info_changed(struct ieee80211_hw *hw,
 
priv->current_aid = conf->aid;
 
-   if (changed & BSS_CHANGED_BSSID) {
+   if (changed & BSS_CHANGED_BSSID && conf->bssid) {
unsigned long flags;
 
spin_lock_irqsave(&priv->lock, flags);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] staging: vt6656: check ieee80211_bss_conf bssid not NULL

Sometimes bssid can go null on failed association.

Signed-off-by: Malcolm Priestley 
Cc:  # v3.17+
---
 drivers/staging/vt6656/main_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6656/main_usb.c 
b/drivers/staging/vt6656/main_usb.c
index f97323f..af572d7 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -701,7 +701,7 @@ static void vnt_bss_info_changed(struct ieee80211_hw *hw,
 
priv->current_aid = conf->aid;
 
-   if (changed & BSS_CHANGED_BSSID)
+   if (changed & BSS_CHANGED_BSSID && conf->bssid)
vnt_mac_set_bssid_addr(priv, (u8 *)conf->bssid);
 
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Clarification for the use of additional fields in the message body

2015-07-09 Thread Theodore Ts'o

On Wed, Jul 08, 2015 at 05:27:38PM +0200, SF Markus Elfring wrote:
> > Note also that some maintainers have work flow that deliberately smash
> > the date (i.e., because they are using a system such as guilt),
> > so if you are depending on the submitted timestamp, it's going to
> > break on you.
> 
> Thanks for your hint.
> 
> I am just trying to offer the possibility for the reuse of a more
> precise commit timestamp together with an appropriate author mail
> address for my update suggestions.
> Do you reject any more such message field overrides?

Well, I won't hold it against you, since I also often need to fix
patches or git commit descriptions anyway.  But at the same time, my
workflow (which you have no right to dictate) **will** destroy your
timestamp.  Given that you haven't explained why you want to do this,
I'm not going have much sympathy if you complain.

Personally, given that you're going through some extremely baroque
e-mail/patchsubmission scheme, I don't understand why you can't also
arrange to override the Date field in the e-mail header.  But I don't
really care all that much, because I can ignore your timestamp no
matter where you put it.

Regards,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: brcmfmac/core.c:1144 brcmf_netdev_wait_pend8021x

Hello again.

After fixing user space <-> brcmfmac communication for using valid MACs:
[PATCH] brcmfmac: set wiphy's addresses to provide valid MACs
i started testing multiple interfaces.

It seems there are many bugs in brcmfmac :(

So after running 3 AP interfaces and switching my STA device between them I
started seeing WARNINGs triggered by brcmf_netdev_wait_pend8021x. It was
brcmf_cfg80211_del_key that was calling above function.

The problem is that brcmf_netdev_start_xmit increases interfaces's
pend_8021x_cnt on every transmission of ETH_P_PAE but brcmf_txfinalize fails
(from time to time?) do decrease it.

There is a bug in brcmf_txfinalize that stops it from finding an interface for
the received TX transmission success. I added some debugging to brcmfmac as you
can see below and this is what I got:
[   39.394022] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c72c1dc0 on ifidx:0
[   39.413251] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c72c1dc0 on ifidx:2
[   39.421887] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c725a7c0 on ifidx:1
[   39.431720] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c6a78a00 on ifidx:0
[   39.442829] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a7c0 
but got invalid ifidx:1
[   39.451773] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c726ee80 on ifidx:2
[   39.460384] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c725a7c0 on ifidx:1
[   39.536224] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a7c0 
but got invalid ifidx:1
[   51.884737] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c714cd00 on ifidx:1
[   51.895577] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c714cd00 
but got invalid ifidx:1
[   51.904592] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c707de80 on ifidx:2
[   51.913195] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c7011e80 on ifidx:0
[   51.922900] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c725a280 on ifidx:1
[   51.933988] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a280 
but got invalid ifidx:1
[   51.942979] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c714cd00 on ifidx:2
[   51.951602] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c707de80 on ifidx:0
[   55.228402] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4
[   55.278395] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4
[   55.328394] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4
[   55.336211] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c7070b80 on ifidx:2
[   55.347075] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c7070b80 
and decreased pend_8021x_cnt for ifidx:2 but got negative count -1!
[   55.387991] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c6a78a00 on ifidx:1
[   55.396601] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c7070b80 on ifidx:0
[   55.406245] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c707d400 on ifidx:2
[   55.417257] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c6a78a00 
but got invalid ifidx:1
[   55.426144] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c707d400 
and decreased pend_8021x_cnt for ifidx:2 but got negative count -1!
[   55.439019] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c714cd00 on ifidx:1
[   55.447611] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c72c2580 on ifidx:0
[   55.498397] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:6
[   55.504785] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c714cd00 
but got invalid ifidx:1

As you can see brcmf_txfinalize fails to find interface for ifidx:1. Why is
that? It seems that drvr->iflist is an array indexed by bssidx, but
brcmf_txfinalize uses ifidx to access it. Obviously ifidx != bssidx.

This also results in decreasing pend_8021x_cnt for wrong interfaces and some
negative values.

Will you fix this?
---
 drivers/net/wireless/brcm80211/brcmfmac/core.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/brcm80211/brcmfmac/core.c
index 5663870..e521ce5 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/core.c
@@ -238,8 +238,10 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff 
*skb,
goto done;
}
 
-   if (eh->h_proto == htons(ETH_P_PAE))
+   if (eh->h_proto == htons(ETH_P_PAE)) {
+   pr_info("[%s] Transmitting ETH_P_PAE skb:%p on ifidx:%d\n", 
__FUNCTION__, skb, ifp->ifidx);
atomic_inc(&ifp->pend_8021x_cnt);
+   }
 
ret = brcmf_fws_process_skb(ifp, skb);
 
@@ -543,6 +545,8 @@ void brcmf_

Re: brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52

On 07/09/2015 09:07 AM, Rafał Miłecki wrote:

Hey guys, I'm afraid I hit another brcmfmac bug.

First of all, I implemented a trivial workaround for the previous bug
reported in the:
brcmfmac: one faulty "iw interface add" command breaks in-firmware BSS state
See my workaround in OpenWrt git:
http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=0e6c9bd9556eea98b476ad371d64d8d16e3a9f9c

So now OpenWrt's user space calls using "iw" tool don't trigger
brcmfmac BSSes bug anymore. I can successfully use one AP interface
per device.

The problem appears when trying to use more than 1 interface. It gets
created correctly, but setting its MAC fails. It results in wlan0-1
having the same MAC as wlan0 and finally having two networks (SSIDs)
using the same MAC. That obviously doesn't work.

Can we please take one step back. I am not understanding how you guys
use the multiple interfaces. The multiple AP interfaces in brcmfmac are
only intended for Multiple-BSS feature as described in hostapd.conf
which changes wlan0 from STA to AP and creates additional AP interfaces,
but you seem to be creating an AP interface with iw next to a STA interface.

I actually have patches pending that correct the announced interface
combinations. I am currently on vacation as my family expanded with a
baby girl.

Regards,
Arend

The error I see is:
brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52
with -52 meaning BCME_IE_NOTFOUND.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive


On 07/09/2015 10:13 AM, Vineet Gupta wrote:

There's already a generic implementation so use that instead.


There is or there was? If there is now I am fine with this patch, but if 
it already was there the author might have had a reason for adding a 
local function and I would like to hear that reason.



---
I'm not sure if the driver usage of atomic_or?() is correct in terms of
storage size of @val for 64 bit arches.

Assuming LP64 programming model for linux on say x86_64: atomic_or()
callers in this driver use long (sana 64 bit) storage and pass it to
atomic_orr/atomic_or which downcasts it to 32 bits. Is that OK ?


The function is used with 32bit register value from the device so I 
think it is ok.


Regards,
Arend


---
Cc: Brett Rudley 
Cc: Arend van Spriel 
Cc: "Franky (Zhenhui) Lin" 
Cc: Hante Meuleman 
Cc: Kalle Valo 
Cc: Pieter-Paul Giesberts 
Cc: Daniel Kim 
Cc: linux-wireless@vger.kernel.org
Cc: brcm80211-dev-l...@broadcom.com
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: net...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Vineet Gupta 

Signed-off-by: Vineet Gupta 
---
  drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 13 ++---
  1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
index d36f5f3d931b..f990e3d0e696 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
@@ -2564,15 +2564,6 @@ static inline void brcmf_sdio_clrintr(struct brcmf_sdio 
*bus)
}
  }

-static void atomic_orr(int val, atomic_t *v)
-{
-   int old_val;
-
-   old_val = atomic_read(v);
-   while (atomic_cmpxchg(v, old_val, val | old_val) != old_val)
-   old_val = atomic_read(v);
-}
-
  static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus)
  {
struct brcmf_core *buscore;
@@ -2595,7 +2586,7 @@ static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus)
if (val) {
brcmf_sdiod_regwl(bus->sdiodev, addr, val, &ret);
bus->sdcnt.f1regdata++;
-   atomic_orr(val, &bus->intstatus);
+   atomic_or(val, &bus->intstatus);
}

return ret;
@@ -2712,7 +2703,7 @@ static void brcmf_sdio_dpc(struct brcmf_sdio *bus)

/* Keep still-pending events for next scheduling */
if (intstatus)
-   atomic_orr(intstatus, &bus->intstatus);
+   atomic_or(intstatus, &bus->intstatus);

brcmf_sdio_clrintr(bus);




--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive


On 07/09/2015 08:25 PM, Arend van Spriel wrote:

On 07/09/2015 10:13 AM, Vineet Gupta wrote:

There's already a generic implementation so use that instead.


There is or there was? If there is now I am fine with this patch, but if
it already was there the author might have had a reason for adding a
local function and I would like to hear that reason.


Nevermind. Just noticed you are proposing the generic implementation in 
this series. Currently on vacation and want to discuss with Hante about 
this change.


Regards,
Arend


---
I'm not sure if the driver usage of atomic_or?() is correct in terms of
storage size of @val for 64 bit arches.

Assuming LP64 programming model for linux on say x86_64: atomic_or()
callers in this driver use long (sana 64 bit) storage and pass it to
atomic_orr/atomic_or which downcasts it to 32 bits. Is that OK ?


The function is used with 32bit register value from the device so I
think it is ok.

Regards,
Arend


---
Cc: Brett Rudley 
Cc: Arend van Spriel 
Cc: "Franky (Zhenhui) Lin" 
Cc: Hante Meuleman 
Cc: Kalle Valo 
Cc: Pieter-Paul Giesberts 
Cc: Daniel Kim 
Cc: linux-wireless@vger.kernel.org
Cc: brcm80211-dev-l...@broadcom.com
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: net...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Vineet Gupta 

Signed-off-by: Vineet Gupta 
---
  drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 13 ++---
  1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
index d36f5f3d931b..f990e3d0e696 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
@@ -2564,15 +2564,6 @@ static inline void brcmf_sdio_clrintr(struct
brcmf_sdio *bus)
  }
  }

-static void atomic_orr(int val, atomic_t *v)
-{
-int old_val;
-
-old_val = atomic_read(v);
-while (atomic_cmpxchg(v, old_val, val | old_val) != old_val)
-old_val = atomic_read(v);
-}
-
  static int brcmf_sdio_intr_rstatus(struct brcmf_sdio *bus)
  {
  struct brcmf_core *buscore;
@@ -2595,7 +2586,7 @@ static int brcmf_sdio_intr_rstatus(struct
brcmf_sdio *bus)
  if (val) {
  brcmf_sdiod_regwl(bus->sdiodev, addr, val, &ret);
  bus->sdcnt.f1regdata++;
-atomic_orr(val, &bus->intstatus);
+atomic_or(val, &bus->intstatus);
  }

  return ret;
@@ -2712,7 +2703,7 @@ static void brcmf_sdio_dpc(struct brcmf_sdio *bus)

  /* Keep still-pending events for next scheduling */
  if (intstatus)
-atomic_orr(intstatus, &bus->intstatus);
+atomic_or(intstatus, &bus->intstatus);

  brcmf_sdio_clrintr(bus);






--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] brcmsmac: Use kstrdup to simplify code


On 07/08/2015 10:22 PM, Christophe JAILLET wrote:

Replace a kmalloc+strcpy by an equivalent kstrdup in order to improve
readability.


Not sure if readability is really the issue here. At most it is a small 
reduction of driver code by using kstrdup(). Anyway, the patch looks fine so


Acked-by: Arend van Spriel 

Signed-off-by: Christophe JAILLET 
---
v2: fix the subject

  drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c 
b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
index 4813506..8a6c077 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
@@ -1476,9 +1476,7 @@ struct brcms_timer *brcms_init_timer(struct brcms_info 
*wl,
wl->timers = t;

  #ifdef DEBUG
-   t->name = kmalloc(strlen(name) + 1, GFP_ATOMIC);
-   if (t->name)
-   strcpy(t->name, name);
+   t->name = kstrdup(name, GFP_ATOMIC);
  #endif

return t;



--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: WARNING: brcmfmac/core.c:1144 brcmf_netdev_wait_pend8021x


On 07/09/2015 08:01 PM, Rafał Miłecki wrote:

Hello again.

After fixing user space <-> brcmfmac communication for using valid MACs:
[PATCH] brcmfmac: set wiphy's addresses to provide valid MACs
i started testing multiple interfaces.

It seems there are many bugs in brcmfmac :(


Well, you are using the device outside its capability, because brcmfmac 
does not properly announce interface combinations. I will submit patches 
for that.



So after running 3 AP interfaces and switching my STA device between them I
started seeing WARNINGs triggered by brcmf_netdev_wait_pend8021x. It was
brcmf_cfg80211_del_key that was calling above function.

The problem is that brcmf_netdev_start_xmit increases interfaces's
pend_8021x_cnt on every transmission of ETH_P_PAE but brcmf_txfinalize fails
(from time to time?) do decrease it.

There is a bug in brcmf_txfinalize that stops it from finding an interface for
the received TX transmission success. I added some debugging to brcmfmac as you
can see below and this is what I got:
[   39.394022] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c72c1dc0 on ifidx:0
[   39.413251] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c72c1dc0 on ifidx:2
[   39.421887] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c725a7c0 on ifidx:1
[   39.431720] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c6a78a00 on ifidx:0
[   39.442829] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a7c0 
but got invalid ifidx:1
[   39.451773] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c726ee80 on ifidx:2
[   39.460384] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c725a7c0 on ifidx:1
[   39.536224] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a7c0 
but got invalid ifidx:1
[   51.884737] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c714cd00 on ifidx:1
[   51.895577] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c714cd00 
but got invalid ifidx:1
[   51.904592] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c707de80 on ifidx:2
[   51.913195] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c7011e80 on ifidx:0
[   51.922900] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c725a280 on ifidx:1
[   51.933988] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c725a280 
but got invalid ifidx:1
[   51.942979] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c714cd00 on ifidx:2
[   51.951602] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c707de80 on ifidx:0
[   55.228402] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4
[   55.278395] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4
[   55.328394] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:4
[   55.336211] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c7070b80 on ifidx:2
[   55.347075] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c7070b80 
and decreased pend_8021x_cnt for ifidx:2 but got negative count -1!
[   55.387991] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c6a78a00 on ifidx:1
[   55.396601] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c7070b80 on ifidx:0
[   55.406245] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c707d400 on ifidx:2
[   55.417257] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c6a78a00 
but got invalid ifidx:1
[   55.426144] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c707d400 
and decreased pend_8021x_cnt for ifidx:2 but got negative count -1!
[   55.439019] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c714cd00 on ifidx:1
[   55.447611] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE 
skb:c72c2580 on ifidx:0
[   55.498397] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING pend_8021x_cnt:6
[   55.504785] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE skb:c714cd00 
but got invalid ifidx:1

As you can see brcmf_txfinalize fails to find interface for ifidx:1. Why is
that? It seems that drvr->iflist is an array indexed by bssidx, but
brcmf_txfinalize uses ifidx to access it. Obviously ifidx != bssidx.

This also results in decreasing pend_8021x_cnt for wrong interfaces and some
negative values.

Will you fix this?


I have some patches reworking the driver using drvr->iflist. One of the 
fixes involves calling brcmf_txfinalize with brcmf_if instance. I need 
to do more testing on those patches before submitting them. If you are 
willing to give them a try as well I can provide them.


Regards,
Arend


---
  drivers/net/wireless/brcm80211/brcmfmac/core.c | 22 ++
  1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/brcm80211/brcmfmac/core.c
index 5663870..e521ce5 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/core.c
+++ b/drivers/net/

Re: brcmfmac: _brcmf_set_mac_address: Setting cur_etheraddr failed, -52

On 9 July 2015 at 20:08, Arend van Spriel  wrote:
> On 07/09/2015 09:07 AM, Rafał Miłecki wrote:
>>
>> Hey guys, I'm afraid I hit another brcmfmac bug.
>>
>> First of all, I implemented a trivial workaround for the previous bug
>> reported in the:
>> brcmfmac: one faulty "iw interface add" command breaks in-firmware BSS
>> state
>> See my workaround in OpenWrt git:
>>
>> http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=0e6c9bd9556eea98b476ad371d64d8d16e3a9f9c
>>
>> So now OpenWrt's user space calls using "iw" tool don't trigger
>> brcmfmac BSSes bug anymore. I can successfully use one AP interface
>> per device.
>>
>> The problem appears when trying to use more than 1 interface. It gets
>> created correctly, but setting its MAC fails. It results in wlan0-1
>> having the same MAC as wlan0 and finally having two networks (SSIDs)
>> using the same MAC. That obviously doesn't work.
>
>
> Can we please take one step back. I am not understanding how you guys use
> the multiple interfaces. The multiple AP interfaces in brcmfmac are only
> intended for Multiple-BSS feature as described in hostapd.conf which changes
> wlan0 from STA to AP and creates additional AP interfaces, but you seem to
> be creating an AP interface with iw next to a STA interface.

OpenWrt tries to remove all existing interfaces and then create needed
ones from the scratch. So e.g. after loading brcmfmac you have:
wlan0

Lets say OpenWrt wants 2 AP interfaces, so it calls:
iw dev wlan0 del
iw phy phy0 interface add wlan0 type __ap
iw phy phy0 interface add wlan0-1 type __ap

The first command fails (brcmfmac limitation), the second one gets
rejected (wlan0 already exists) and the third one creates new virtual
interface. This results in having two interfaces: STA and AP.
Then OpenWrt finally runs hostapd which changes wlan0 to AP and starts
AP on both interfaces.


> I actually have patches pending that correct the announced interface
> combinations. I am currently on vacation as my family expanded with a baby
> girl.

Have fun! :)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: WARNING: brcmfmac/core.c:1144 brcmf_netdev_wait_pend8021x

On 9 July 2015 at 20:48, Arend van Spriel  wrote:
> On 07/09/2015 08:01 PM, Rafał Miłecki wrote:
>> After fixing user space <-> brcmfmac communication for using valid MACs:
>> [PATCH] brcmfmac: set wiphy's addresses to provide valid MACs
>> i started testing multiple interfaces.
>>
>> It seems there are many bugs in brcmfmac :(
>
>
> Well, you are using the device outside its capability, because brcmfmac does
> not properly announce interface combinations. I will submit patches for
> that.

Really? I'm just running 3 interfaces, all of them in AP mode, nothing
unexpected I believe.


>> So after running 3 AP interfaces and switching my STA device between them
>> I
>> started seeing WARNINGs triggered by brcmf_netdev_wait_pend8021x. It was
>> brcmf_cfg80211_del_key that was calling above function.
>>
>> The problem is that brcmf_netdev_start_xmit increases interfaces's
>> pend_8021x_cnt on every transmission of ETH_P_PAE but brcmf_txfinalize
>> fails
>> (from time to time?) do decrease it.
>>
>> There is a bug in brcmf_txfinalize that stops it from finding an interface
>> for
>> the received TX transmission success. I added some debugging to brcmfmac
>> as you
>> can see below and this is what I got:
>> [   39.394022] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c72c1dc0 on ifidx:0
>> [   39.413251] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c72c1dc0 on ifidx:2
>> [   39.421887] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c725a7c0 on ifidx:1
>> [   39.431720] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c6a78a00 on ifidx:0
>> [   39.442829] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE
>> skb:c725a7c0 but got invalid ifidx:1
>> [   39.451773] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c726ee80 on ifidx:2
>> [   39.460384] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c725a7c0 on ifidx:1
>> [   39.536224] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE
>> skb:c725a7c0 but got invalid ifidx:1
>> [   51.884737] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c714cd00 on ifidx:1
>> [   51.895577] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE
>> skb:c714cd00 but got invalid ifidx:1
>> [   51.904592] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c707de80 on ifidx:2
>> [   51.913195] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c7011e80 on ifidx:0
>> [   51.922900] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c725a280 on ifidx:1
>> [   51.933988] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE
>> skb:c725a280 but got invalid ifidx:1
>> [   51.942979] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c714cd00 on ifidx:2
>> [   51.951602] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c707de80 on ifidx:0
>> [   55.228402] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING
>> pend_8021x_cnt:4
>> [   55.278395] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING
>> pend_8021x_cnt:4
>> [   55.328394] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING
>> pend_8021x_cnt:4
>> [   55.336211] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c7070b80 on ifidx:2
>> [   55.347075] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE
>> skb:c7070b80 and decreased pend_8021x_cnt for ifidx:2 but got negative count
>> -1!
>> [   55.387991] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c6a78a00 on ifidx:1
>> [   55.396601] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c7070b80 on ifidx:0
>> [   55.406245] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c707d400 on ifidx:2
>> [   55.417257] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE
>> skb:c6a78a00 but got invalid ifidx:1
>> [   55.426144] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE
>> skb:c707d400 and decreased pend_8021x_cnt for ifidx:2 but got negative count
>> -1!
>> [   55.439019] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c714cd00 on ifidx:1
>> [   55.447611] brcmfmac: [brcmf_netdev_start_xmit] Transmitting ETH_P_PAE
>> skb:c72c2580 on ifidx:0
>> [   55.498397] brcmfmac: [brcmf_netdev_wait_pend8021x] WARNING
>> pend_8021x_cnt:6
>> [   55.504785] brcmfmac: [brcmf_txfinalize] Finalized ETH_P_PAE
>> skb:c714cd00 but got invalid ifidx:1
>>
>> As you can see brcmf_txfinalize fails to find interface for ifidx:1. Why
>> is
>> that? It seems that drvr->iflist is an array indexed by bssidx, but
>> brcmf_txfinalize uses ifidx to access it. Obviously ifidx != bssidx.
>>
>> This also results in decreasing pend_8021x_cnt for wrong interfaces and
>> some
>> negative values.
>>
>> Will you fix this?
>
>
> I have some patches reworking the driver using drvr->iflist. One of the
> fixes involves calling brcmf_txfinalize with brcmf_if instance. I need to do
> more testing on those patches before submitting them. If you are willing to
> give them a try as

Re: [PATCH v2 3/3] mac80211: select an AID when creating new mesh STAs

2015-07-09 Thread Bob Copeland

On Fri, Jul 3, 2015 at 3:41 PM, Bob Copeland  wrote:
> Instead of using peer link id for AID, generate a new
> AID when creating mesh STAs in the kernel peering manager.

I missed a case where llid was used for aid in
ieee80211_mps_frame_release() -- will send a v3 for the series.

-- 
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive

2015-07-09 Thread Peter Zijlstra

On Thu, Jul 09, 2015 at 08:31:16PM +0200, Arend van Spriel wrote:
> >There is or there was? If there is now I am fine with this patch, but if
> >it already was there the author might have had a reason for adding a
> >local function and I would like to hear that reason.
> 
> Nevermind. Just noticed you are proposing the generic implementation in this
> series. Currently on vacation and want to discuss with Hante about this
> change.

No there is one in linux/atomic.h, he just renamed the #ifdef guard and
provided a 'sane' implementation for his arch.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

How is AP supposed to handle power-save packets from peer?

2015-07-09 Thread Ben Greear

Suppose one is doing heavy download (AP -> peer traffic), and there are lots of 
frames in the
NIC's tx buffers (ath10k firmware, in this case).

Then, peer sends a power-save pkt telling AP it is going off-channel or 
otherwise
will be unavailable.

What is the appropriate behaviour from the AP?  Can the firmware just drop all 
those tx frames to
make room to handle other stations?  Maybe report ACK failure and hope the 
upper level stacks
retransmit as appropriate?

Or, is the host supposed to flush the peer's packets to clear out the frames?

Or, is firmware somehow supposed to keep all the frames for when the peer comes 
back?

Thanks,
Ben

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

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive

2015-07-09 Thread Vineet Gupta

On Thursday 09 July 2015 11:55 PM, Arend van Spriel wrote:
> On 07/09/2015 10:13 AM, Vineet Gupta wrote:
>> > There's already a generic implementation so use that instead.
> There is or there was? If there is now I am fine with this patch, but if 
> it already was there the author might have had a reason for adding a 
> local function and I would like to hear that reason.
>

atomic_orr() was introduced to this driver with

2014-03-06 5cbb9c285bdc brcmfmac: Use atomic functions for intstatus update. 

as it seems atomic_set_mask() was not available cross arch. And atomic_or() in
generic code was indeed introduced after that

2014-04-23 560cb12a4080 locking,arch: Rewrite generic atomic support 

Hence likely the reason author went with home grown atomic_orr()

-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How is AP supposed to handle power-save packets from peer?

On 10 July 2015 at 02:03, Ben Greear  wrote:
> Suppose one is doing heavy download (AP -> peer traffic), and there are lots 
> of frames in the
> NIC's tx buffers (ath10k firmware, in this case).
>
> Then, peer sends a power-save pkt telling AP it is going off-channel or 
> otherwise
> will be unavailable.

I assume you're exploring the worst-case scenario when all tx buffers
are consumed and peer goes to sleep, am I correct?

>
> What is the appropriate behaviour from the AP?  Can the firmware just drop 
> all those tx frames to
> make room to handle other stations?  Maybe report ACK failure and hope the 
> upper level stacks
> retransmit as appropriate?
>
> Or, is the host supposed to flush the peer's packets to clear out the frames?
>
> Or, is firmware somehow supposed to keep all the frames for when the peer 
> comes back?

Firmware will keep frames buffered until station wakes up again.

There's a timeout to detect stale stations as far as I'm aware and the
default value is 10s (sounds familiar? this goes back to mgmt tx/
credit starvation). This makes to handle stations that go to sleep and
then out of range/away. AP doesn't need to keep frames buffered till
the end of time. Once the timeout is hit firmware stops caring about
station's last seen sleep state transition and marks it as awake and
just sends frames to it (with tons of retransmits if it's really not
there anymore since there'd be noone to ACK) - in which case you'll
get no_ack=1 in tx status.

See: WMI_10X_VDEV_PARAM_AP_DETECT_OUT_OF_SYNC_SLEEPING_STA_TIME_SECS

Ideally there should be little to no buffer bloat but it's difficult
to do that considering aggregation sizes of 11ac..

Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] staging: wilc1000: rework integer value for x64

Hello Greg.

This driver convert pointer address to integer value and use it
as function argument. because the value has a limited 32bit size,
current driver happen many issues on x64 machine.

I have split it up enough sensibliy to allow review. If this patches
are accepted, I will update more patches related with this patch.

Best regards.
Johnny.

Johnny Kim (3):
  staging: wilc1000: wilc_wlan_cfg_commit(): replace integer with
pointer
  staging: wilc1000: wilc_wlan_cfg_get(): replace integer with void
pointer
  staging: wilc1000: wilc_wlan_cfg_set(): replace integer with void
pointer

 drivers/staging/wilc1000/coreconfigurator.c |  4 ++--
 drivers/staging/wilc1000/linux_wlan.c   |  2 +-
 drivers/staging/wilc1000/wilc_wlan.c| 12 ++--
 drivers/staging/wilc1000/wilc_wlan_if.h |  4 ++--
 4 files changed, 11 insertions(+), 11 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] staging: wilc1000: wilc_wlan_cfg_commit(): replace integer with pointer

A argument of wilc_wlan_cfg_commit() is address of structure.
But because the size is restricted to 32bit, it is not correct
for 64bit machine.

So, this changes the interger value to obvious structure pointer.

Signed-off-by: Johnny Kim 
---
 drivers/staging/wilc1000/wilc_wlan.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index def72fd..d32e45e 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -1862,13 +1862,13 @@ static void wilc_wlan_cleanup(void)
 
 }
 
-static int wilc_wlan_cfg_commit(int type, uint32_t drvHandler)
+static int wilc_wlan_cfg_commit(int type, tstrWILC_WFIDrv *drvHandler)
 {
wilc_wlan_dev_t *p = (wilc_wlan_dev_t *)&g_wlan;
wilc_cfg_frame_t *cfg = &p->cfg_frame;
int total_len = p->cfg_frame_offset + 4 + DRIVER_HANDLER_SIZE;
int seq_no = p->cfg_seq_no % 256;
-   int driver_handler = (u32)drvHandler;
+   uintptr_t driver_handler = (uintptr_t)drvHandler;
 
 
/**
@@ -1923,7 +1923,7 @@ static int wilc_wlan_cfg_set(int start, uint32_t wid, 
uint8_t *buffer, uint32_t
p->cfg_frame_in_use = 1;
 
/*Edited by Amr - BugID_4720*/
-   if (wilc_wlan_cfg_commit(WILC_CFG_SET, drvHandler))
+   if (wilc_wlan_cfg_commit(WILC_CFG_SET, (tstrWILC_WFIDrv 
*)drvHandler))
ret_size = 0;   /* BugID_5213 */
 
if (p->os_func.os_wait(p->cfg_wait, CFG_PKTS_TIMEOUT)) {
@@ -1960,7 +1960,7 @@ static int wilc_wlan_cfg_get(int start, uint32_t wid, int 
commit, uint32_t drvHa
p->cfg_frame_in_use = 1;
 
/*Edited by Amr - BugID_4720*/
-   if (wilc_wlan_cfg_commit(WILC_CFG_QUERY, drvHandler))
+   if (wilc_wlan_cfg_commit(WILC_CFG_QUERY, (tstrWILC_WFIDrv 
*)drvHandler))
ret_size = 0;   /* BugID_5213 */
 
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] staging: wilc1000: change variable of limited 32bit size to pointer

gu8FlushedJoinReqDrvHandler variable is be using to save structure pointer.
But because that is restricted to 32bit and has needless casting,
the varibale should be changed to pointer of same type.

Signed-off-by: Johnny Kim 
---
 drivers/staging/wilc1000/host_interface.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index dfd8e01..a82e0a8 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -581,7 +581,7 @@ u8 gu8Flushed11iMode;
 u8 gu8FlushedAuthType;
 u32 gu32FlushedJoinReqSize;
 u32 gu32FlushedInfoElemAsocSize;
-u32 gu8FlushedJoinReqDrvHandler;
+tstrWILC_WFIDrv *gu8FlushedJoinReqDrvHandler;
 #define REAL_JOIN_REQ 0
 #define FLUSHED_JOIN_REQ 1
 #define FLUSHED_BYTE_POS 79 /* Position the byte indicating flushing in 
the flushed request */
@@ -1948,7 +1948,7 @@ static s32 Handle_Connect(void *drvHandler, 
tstrHostIFconnectAttr *pstrHostIFcon
/*BugID_5137*/
if (WILC_memcmp("DIRECT-", pstrHostIFconnectAttr->pu8ssid, 7)) {
memcpy(gu8FlushedJoinReq, pu8CurrByte, gu32FlushedJoinReqSize);
-   gu8FlushedJoinReqDrvHandler = (u32)pstrWFIDrv;
+   gu8FlushedJoinReqDrvHandler = pstrWFIDrv;
}
 
PRINT_D(GENERIC_DBG, "send HOST_IF_WAITING_CONN_RESP\n");
@@ -2199,11 +2199,11 @@ static s32 Handle_ConnectTimeout(void *drvHandler)
WILC_memset(u8ConnectedSSID, 0, ETH_ALEN);
/*BugID_5213*/
/*Freeing flushed join request params on connect timeout*/
-   if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == 
(u32)drvHandler) {
+   if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == 
drvHandler) {
WILC_FREE(gu8FlushedJoinReq);
gu8FlushedJoinReq = NULL;
}
-   if (gu8FlushedInfoElemAsoc != NULL && gu8FlushedJoinReqDrvHandler == 
(u32)drvHandler) {
+   if (gu8FlushedInfoElemAsoc != NULL && gu8FlushedJoinReqDrvHandler == 
drvHandler) {
WILC_FREE(gu8FlushedInfoElemAsoc);
gu8FlushedInfoElemAsoc = NULL;
}
@@ -2624,11 +2624,11 @@ static s32 Handle_RcvdGnrlAsyncInfo(void *drvHandler, 
tstrRcvdGnrlAsyncInfo *pst
/*BugID_5213*/
/*Freeing flushed join request params on receiving*/
/*MAC_DISCONNECTED while connected*/
-   if (gu8FlushedJoinReq != NULL && 
gu8FlushedJoinReqDrvHandler == (u32)drvHandler) {
+   if (gu8FlushedJoinReq != NULL && 
gu8FlushedJoinReqDrvHandler == drvHandler) {
WILC_FREE(gu8FlushedJoinReq);
gu8FlushedJoinReq = NULL;
}
-   if (gu8FlushedInfoElemAsoc != NULL && 
gu8FlushedJoinReqDrvHandler == (u32)drvHandler) {
+   if (gu8FlushedInfoElemAsoc != NULL && 
gu8FlushedJoinReqDrvHandler == drvHandler) {
WILC_FREE(gu8FlushedInfoElemAsoc);
gu8FlushedInfoElemAsoc = NULL;
}
@@ -3125,11 +3125,11 @@ static void Handle_Disconnect(void *drvHandler)
 
 
/*BugID_5137*/
-   if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == 
(u32)drvHandler) {
+   if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == 
drvHandler) {
WILC_FREE(gu8FlushedJoinReq);
gu8FlushedJoinReq = NULL;
}
-   if (gu8FlushedInfoElemAsoc != NULL && 
gu8FlushedJoinReqDrvHandler == (u32)drvHandler) {
+   if (gu8FlushedInfoElemAsoc != NULL && 
gu8FlushedJoinReqDrvHandler == drvHandler) {
WILC_FREE(gu8FlushedInfoElemAsoc);
gu8FlushedInfoElemAsoc = NULL;
}
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] staging: wilc1000: wilc_wlan_cfg_get(): replace integer with void pointer

Last argument of wilc_wlan_cfg_get function is actually structure's address.
This should be changed to be compatible with 64bit machine.
Because wilc_wlan_cfg_get function is mapped by function pointer later,
wilc_wlan_oup_t.wlan_cfg_get should be changed together.

tstrWILC_WFIDrv structure is defined after wilc_wlan_oup_t.wlan_cfg_get
is defined. So, this patch changes the argument to void type pointer.

Signed-off-by: Johnny Kim 
---
 drivers/staging/wilc1000/coreconfigurator.c | 2 +-
 drivers/staging/wilc1000/wilc_wlan.c| 2 +-
 drivers/staging/wilc1000/wilc_wlan_if.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
b/drivers/staging/wilc1000/coreconfigurator.c
index b069614..141d7b4 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -2094,7 +2094,7 @@ s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs,
   (counter == u32WIDsCount - 1));
if (!gpstrWlanOps->wlan_cfg_get(!counter,

pstrWIDs[counter].u16WIDid,
-   (counter == 
u32WIDsCount - 1), drvHandler)) {
+   (counter == 
u32WIDsCount - 1), (void *)drvHandler)) {
ret = -1;
printk("[Sendconfigpkt]Get Timed out\n");
break;
diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index d32e45e..c0a8063 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -1938,7 +1938,7 @@ static int wilc_wlan_cfg_set(int start, uint32_t wid, 
uint8_t *buffer, uint32_t
 
return ret_size;
 }
-static int wilc_wlan_cfg_get(int start, uint32_t wid, int commit, uint32_t 
drvHandler)
+static int wilc_wlan_cfg_get(int start, uint32_t wid, int commit, void* 
drvHandler)
 {
wilc_wlan_dev_t *p = (wilc_wlan_dev_t *)&g_wlan;
uint32_t offset;
diff --git a/drivers/staging/wilc1000/wilc_wlan_if.h 
b/drivers/staging/wilc1000/wilc_wlan_if.h
index 8735a6a..8c293ab 100644
--- a/drivers/staging/wilc1000/wilc_wlan_if.h
+++ b/drivers/staging/wilc1000/wilc_wlan_if.h
@@ -194,7 +194,7 @@ typedef struct {
void (*wlan_handle_rx_isr)(void);
void (*wlan_cleanup)(void);
int (*wlan_cfg_set)(int, uint32_t, uint8_t *, uint32_t, int, uint32_t);
-   int (*wlan_cfg_get)(int, uint32_t, int, uint32_t);
+   int (*wlan_cfg_get)(int, uint32_t, int, void *);
int (*wlan_cfg_get_value)(uint32_t, uint8_t *, uint32_t);
/*Bug3959: transmitting mgmt frames received from host*/
#if defined(WILC_AP_EXTERNAL_MLME) || defined(WILC_P2P)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] staging: wilc1000: wilc_wlan_cfg_set(): replace integer with void pointer

Last argument of wilc_wlan_cfg_set function is actually structure's address.
This should be changed to be compatible with 64bit machine.
Because wilc_wlan_cfg_set function is mapped by function pointer later,
wilc_wlan_oup_t.wlan_cfg_set should be changed together.

tstrWILC_WFIDrv structure is defined after wilc_wlan_oup_t.wlan_cfg_set
is defined. So, this patch changes the argument to void type pointer.

Signed-off-by: Johnny Kim 
---
 drivers/staging/wilc1000/coreconfigurator.c | 2 +-
 drivers/staging/wilc1000/linux_wlan.c   | 2 +-
 drivers/staging/wilc1000/wilc_wlan.c| 2 +-
 drivers/staging/wilc1000/wilc_wlan_if.h | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
b/drivers/staging/wilc1000/coreconfigurator.c
index 141d7b4..5c1096d 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -2117,7 +2117,7 @@ s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs,
if (!gpstrWlanOps->wlan_cfg_set(!counter,

pstrWIDs[counter].u16WIDid, pstrWIDs[counter].ps8WidVal,

pstrWIDs[counter].s32ValueSize,
-   (counter == 
u32WIDsCount - 1), drvHandler)) {
+   (counter == 
u32WIDsCount - 1), (void *)drvHandler)) {
ret = -1;
printk("[Sendconfigpkt]Set Timed out\n");
break;
diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 5a794df..eadc500 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1340,7 +1340,7 @@ static int linux_wlan_init_test_config(struct net_device 
*dev, linux_wlan_t *p_n
goto _fail_;
 
c_val[0] = 1; /* Enable N with immediate block ack. */
-   if (!g_linux_wlan->oup.wlan_cfg_set(0, WID_11N_IMMEDIATE_BA_ENABLED, 
c_val, 1, 1, (u32)pstrWFIDrv))
+   if (!g_linux_wlan->oup.wlan_cfg_set(0, WID_11N_IMMEDIATE_BA_ENABLED, 
c_val, 1, 1, (void *)pstrWFIDrv))
goto _fail_;
 
return 0;
diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index c0a8063..f9dbd40 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -1899,7 +1899,7 @@ static int wilc_wlan_cfg_commit(int type, tstrWILC_WFIDrv 
*drvHandler)
return 0;
 }
 
-static int wilc_wlan_cfg_set(int start, uint32_t wid, uint8_t *buffer, 
uint32_t buffer_size, int commit, uint32_t drvHandler)
+static int wilc_wlan_cfg_set(int start, uint32_t wid, uint8_t *buffer, 
uint32_t buffer_size, int commit, void *drvHandler)
 {
wilc_wlan_dev_t *p = (wilc_wlan_dev_t *)&g_wlan;
uint32_t offset;
diff --git a/drivers/staging/wilc1000/wilc_wlan_if.h 
b/drivers/staging/wilc1000/wilc_wlan_if.h
index 8c293ab..9d42bd8 100644
--- a/drivers/staging/wilc1000/wilc_wlan_if.h
+++ b/drivers/staging/wilc1000/wilc_wlan_if.h
@@ -193,7 +193,7 @@ typedef struct {
void (*wlan_handle_rx_que)(void);
void (*wlan_handle_rx_isr)(void);
void (*wlan_cleanup)(void);
-   int (*wlan_cfg_set)(int, uint32_t, uint8_t *, uint32_t, int, uint32_t);
+   int (*wlan_cfg_set)(int, uint32_t, uint8_t *, uint32_t, int, void *);
int (*wlan_cfg_get)(int, uint32_t, int, void *);
int (*wlan_cfg_get_value)(uint32_t, uint8_t *, uint32_t);
/*Bug3959: transmitting mgmt frames received from host*/
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] staging: wilc1000: SendConfigPkt(): replace integer with void pointer

This patch replaces a integer argument of SendConfigPkt function with
void type pointer and fix code that the function is called.

Because tstrWILC_WFIDrv structure is defined after SendConfigPkt function
is defined, the function can not refer to the structure type.
So this patch change the argument to void type pointer.

Signed-off-by: Johnny Kim 
---
 drivers/staging/wilc1000/coreconfigurator.c |   4 +-
 drivers/staging/wilc1000/coreconfigurator.h |   2 +-
 drivers/staging/wilc1000/host_interface.c   | 102 ++--
 3 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
b/drivers/staging/wilc1000/coreconfigurator.c
index 5c1096d..e274f1b 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -1893,7 +1893,7 @@ s32 ConfigWaitResponse(char *pcRespBuffer, s32 
s32MaxRespBuffLen, s32 *ps32Bytes
  */
 #ifdef SIMULATION
 s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs,
- u32 u32WIDsCount, bool bRespRequired, u32 drvHandler)
+ u32 u32WIDsCount, bool bRespRequired, void 
*drvHandler)
 {
s32 s32Error = WILC_SUCCESS;
s32 err = WILC_SUCCESS;
@@ -2072,7 +2072,7 @@ extern wilc_wlan_oup_t *gpstrWlanOps;
  *  @version   1.0
  */
 s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs,
- u32 u32WIDsCount, bool bRespRequired, u32 drvHandler)
+ u32 u32WIDsCount, bool bRespRequired, void 
*drvHandler)
 {
s32 counter = 0, ret = 0;
if (gpstrWlanOps == NULL) {
diff --git a/drivers/staging/wilc1000/coreconfigurator.h 
b/drivers/staging/wilc1000/coreconfigurator.h
index 9059c8d..c39802f 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -175,7 +175,7 @@ extern s32 CoreConfiguratorInit(void);
 extern s32 CoreConfiguratorDeInit(void);
 
 extern s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs,
-u32 u32WIDsCount, bool bRespRequired, u32 
drvHandler);
+u32 u32WIDsCount, bool bRespRequired, void 
*drvHandler);
 extern s32 ParseNetworkInfo(u8 *pu8MsgBuffer, tstrNetworkInfo 
**ppstrNetworkInfo);
 extern s32 DeallocateNetworkInfo(tstrNetworkInfo *pstrNetworkInfo);
 
diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index c089e73..dfd8e01 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -619,7 +619,7 @@ static s32 Handle_SetChannel(void *drvHandler, 
tstrHostIFSetChan *pstrHostIFSetC
 
PRINT_D(HOSTINF_DBG, "Setting channel\n");
/*Sending Cfg*/
-   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv);
+   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, pstrWFIDrv);
if (s32Error) {
PRINT_ER("Failed to set channel\n");
WILC_ERRORREPORT(s32Error, WILC_INVALID_STATE);
@@ -656,7 +656,7 @@ static s32 Handle_SetWfiDrvHandler(tstrHostIfSetDrvHandler 
*pstrHostIfSetDrvHand
 
/*Sending Cfg*/
 
-   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv);
+   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, pstrWFIDrv);
 
 
if ((pstrHostIfSetDrvHandler->u32Address) == (u32)NULL)
@@ -701,7 +701,7 @@ static s32 Handle_SetOperationMode(void *drvHandler, 
tstrHostIfSetOperationMode
/*Sending Cfg*/
PRINT_INFO(HOSTINF_DBG, "pstrWFIDrv= %p\n", pstrWFIDrv);
 
-   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv);
+   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, pstrWFIDrv);
 
 
if ((pstrHostIfSetOperationMode->u32Mode) == (u32)NULL)
@@ -750,7 +750,7 @@ s32 Handle_set_IPAddress(void *drvHandler, u8 *pu8IPAddr, 
u8 idx)
strWID.ps8WidVal = (u8 *)pu8IPAddr;
strWID.s32ValueSize = IP_ALEN;
 
-   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv);
+   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, pstrWFIDrv);
 
 
 
@@ -794,7 +794,7 @@ s32 Handle_get_IPAddress(void *drvHandler, u8 *pu8IPAddr, 
u8 idx)
strWID.ps8WidVal = (u8 *)WILC_MALLOC(IP_ALEN);
strWID.s32ValueSize = IP_ALEN;
 
-   s32Error = SendConfigPkt(GET_CFG, &strWID, 1, true, (u32)pstrWFIDrv);
+   s32Error = SendConfigPkt(GET_CFG, &strWID, 1, true, pstrWFIDrv);
 
PRINT_INFO(HOSTINF_DBG, "%pI4\n", strWID.ps8WidVal);
 
@@ -855,7 +855,7 @@ static s32 Handle_SetMacAddress(void *drvHandler, 
tstrHostIfSetMacAddress *pstrH
strWID.s32ValueSize = ETH_ALEN;
PRINT_D(GENERIC_DBG, "mac addr = :%x:%x:%x:%x:%x:%x\n", 
strWID.ps8WidVal[0], strWID.ps8WidVal[1], strWID.ps8WidVal[2], 
strWID.ps8WidVal[3], strWID.ps8WidVal[4], strWID.ps8WidVal[5]);
/*Sending Cfg*/
-   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv);
+   s32Error = SendConfigPkt(SET

Re: [PATCH 1/3] staging: wilc1000: wilc_wlan_cfg_commit(): replace integer with pointer

Hi Johnny,

On Fri, Jul 10, 2015 at 3:55 PM, Johnny Kim  wrote:
> A argument of wilc_wlan_cfg_commit() is address of structure.
> But because the size is restricted to 32bit, it is not correct
> for 64bit machine.
>
> So, this changes the interger value to obvious structure pointer.
>
> Signed-off-by: Johnny Kim 
> ---
>  drivers/staging/wilc1000/wilc_wlan.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
> b/drivers/staging/wilc1000/wilc_wlan.c
> index def72fd..d32e45e 100644
> --- a/drivers/staging/wilc1000/wilc_wlan.c
> +++ b/drivers/staging/wilc1000/wilc_wlan.c
> @@ -1862,13 +1862,13 @@ static void wilc_wlan_cleanup(void)
>
>  }
>
> -static int wilc_wlan_cfg_commit(int type, uint32_t drvHandler)
> +static int wilc_wlan_cfg_commit(int type, tstrWILC_WFIDrv *drvHandler)
>  {
> wilc_wlan_dev_t *p = (wilc_wlan_dev_t *)&g_wlan;
> wilc_cfg_frame_t *cfg = &p->cfg_frame;
> int total_len = p->cfg_frame_offset + 4 + DRIVER_HANDLER_SIZE;
> int seq_no = p->cfg_seq_no % 256;
> -   int driver_handler = (u32)drvHandler;
> +   uintptr_t driver_handler = (uintptr_t)drvHandler;

Er, why not just remove this variable and use drvHandler directly?

> @@ -1923,7 +1923,7 @@ static int wilc_wlan_cfg_set(int start, uint32_t wid, 
> uint8_t *buffer, uint32_t
> p->cfg_frame_in_use = 1;
>
> /*Edited by Amr - BugID_4720*/
> -   if (wilc_wlan_cfg_commit(WILC_CFG_SET, drvHandler))
> +   if (wilc_wlan_cfg_commit(WILC_CFG_SET, (tstrWILC_WFIDrv 
> *)drvHandler))

No need to cast it to it's own type.

> ret_size = 0;   /* BugID_5213 */
>
> if (p->os_func.os_wait(p->cfg_wait, CFG_PKTS_TIMEOUT)) {
> @@ -1960,7 +1960,7 @@ static int wilc_wlan_cfg_get(int start, uint32_t wid, 
> int commit, uint32_t drvHa
> p->cfg_frame_in_use = 1;
>
> /*Edited by Amr - BugID_4720*/
> -   if (wilc_wlan_cfg_commit(WILC_CFG_QUERY, drvHandler))
> +   if (wilc_wlan_cfg_commit(WILC_CFG_QUERY, (tstrWILC_WFIDrv 
> *)drvHandler))

Ditto.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] staging: wilc1000: wilc_wlan_cfg_get(): replace integer with void pointer

Hi Johnny,

On Fri, Jul 10, 2015 at 3:55 PM, Johnny Kim  wrote:
> Last argument of wilc_wlan_cfg_get function is actually structure's address.
> This should be changed to be compatible with 64bit machine.
> Because wilc_wlan_cfg_get function is mapped by function pointer later,
> wilc_wlan_oup_t.wlan_cfg_get should be changed together.
>
> tstrWILC_WFIDrv structure is defined after wilc_wlan_oup_t.wlan_cfg_get
> is defined. So, this patch changes the argument to void type pointer.

Why not add a patch moving the structure definition before
wilc_wlan_oup_t.wlan_cfg_get is defined?

> Signed-off-by: Johnny Kim 
> ---
>  drivers/staging/wilc1000/coreconfigurator.c | 2 +-
>  drivers/staging/wilc1000/wilc_wlan.c| 2 +-
>  drivers/staging/wilc1000/wilc_wlan_if.h | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
> b/drivers/staging/wilc1000/coreconfigurator.c
> index b069614..141d7b4 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.c
> +++ b/drivers/staging/wilc1000/coreconfigurator.c
> @@ -2094,7 +2094,7 @@ s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs,
>(counter == u32WIDsCount - 1));
> if (!gpstrWlanOps->wlan_cfg_get(!counter,
> 
> pstrWIDs[counter].u16WIDid,
> -   (counter == 
> u32WIDsCount - 1), drvHandler)) {
> +   (counter == 
> u32WIDsCount - 1), (void *)drvHandler)) {

If I recall correctly, you shouldn't need void * casts.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] nfc: Drop owner assignment from i2c_driver

2015-07-09 Thread Krzysztof Kozlowski

i2c_driver does not need to set an owner because i2c_register_driver()
will set it.

Signed-off-by: Krzysztof Kozlowski 

---

The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
 drivers/nfc/nxp-nci/i2c.c  | 1 -
 drivers/nfc/pn544/i2c.c| 1 -
 drivers/nfc/st-nci/i2c.c   | 1 -
 drivers/nfc/st21nfca/i2c.c | 1 -
 4 files changed, 4 deletions(-)

diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 2f77f1d03638..6c5e63cd0022 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -450,7 +450,6 @@ MODULE_DEVICE_TABLE(acpi, acpi_id);
 static struct i2c_driver nxp_nci_i2c_driver = {
.driver = {
   .name = NXP_NCI_I2C_DRIVER_NAME,
-  .owner  = THIS_MODULE,
   .acpi_match_table = ACPI_PTR(acpi_id),
   .of_match_table = of_match_ptr(of_nxp_nci_i2c_match),
  },
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index fa75c53f3fa5..a095523309cf 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -1162,7 +1162,6 @@ MODULE_DEVICE_TABLE(of, of_pn544_i2c_match);
 static struct i2c_driver pn544_hci_i2c_driver = {
.driver = {
   .name = PN544_HCI_I2C_DRIVER_NAME,
-  .owner  = THIS_MODULE,
   .of_match_table = of_match_ptr(of_pn544_i2c_match),
   .acpi_match_table = ACPI_PTR(pn544_hci_i2c_acpi_match),
  },
diff --git a/drivers/nfc/st-nci/i2c.c b/drivers/nfc/st-nci/i2c.c
index 06175ce769bb..c21c45c656c0 100644
--- a/drivers/nfc/st-nci/i2c.c
+++ b/drivers/nfc/st-nci/i2c.c
@@ -370,7 +370,6 @@ MODULE_DEVICE_TABLE(of, of_st_nci_i2c_match);
 
 static struct i2c_driver st_nci_i2c_driver = {
.driver = {
-   .owner = THIS_MODULE,
.name = ST_NCI_I2C_DRIVER_NAME,
.of_match_table = of_match_ptr(of_st_nci_i2c_match),
},
diff --git a/drivers/nfc/st21nfca/i2c.c b/drivers/nfc/st21nfca/i2c.c
index a32143951616..6f987fa36371 100644
--- a/drivers/nfc/st21nfca/i2c.c
+++ b/drivers/nfc/st21nfca/i2c.c
@@ -680,7 +680,6 @@ MODULE_DEVICE_TABLE(of, of_st21nfca_i2c_match);
 
 static struct i2c_driver st21nfca_hci_i2c_driver = {
.driver = {
-   .owner = THIS_MODULE,
.name = ST21NFCA_HCI_I2C_DRIVER_NAME,
.of_match_table = of_match_ptr(of_st21nfca_i2c_match),
},
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] staging: wilc1000: wilc_wlan_cfg_set(): replace integer with void pointer

Hi Johnny,

On Fri, Jul 10, 2015 at 3:55 PM, Johnny Kim  wrote:
> Last argument of wilc_wlan_cfg_set function is actually structure's address.
> This should be changed to be compatible with 64bit machine.
> Because wilc_wlan_cfg_set function is mapped by function pointer later,
> wilc_wlan_oup_t.wlan_cfg_set should be changed together.
>
> tstrWILC_WFIDrv structure is defined after wilc_wlan_oup_t.wlan_cfg_set
> is defined. So, this patch changes the argument to void type pointer.

Same question, why not move the structure definition before this op is defined?

> Signed-off-by: Johnny Kim 
> ---
>  drivers/staging/wilc1000/coreconfigurator.c | 2 +-
>  drivers/staging/wilc1000/linux_wlan.c   | 2 +-
>  drivers/staging/wilc1000/wilc_wlan.c| 2 +-
>  drivers/staging/wilc1000/wilc_wlan_if.h | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
> b/drivers/staging/wilc1000/coreconfigurator.c
> index 141d7b4..5c1096d 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.c
> +++ b/drivers/staging/wilc1000/coreconfigurator.c
> @@ -2117,7 +2117,7 @@ s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs,
> if (!gpstrWlanOps->wlan_cfg_set(!counter,
> 
> pstrWIDs[counter].u16WIDid, pstrWIDs[counter].ps8WidVal,
> 
> pstrWIDs[counter].s32ValueSize,
> -   (counter == 
> u32WIDsCount - 1), drvHandler)) {
> +   (counter == 
> u32WIDsCount - 1), (void *)drvHandler)) {

Again, you shouldn't need a void * cast.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] staging: wilc1000: SendConfigPkt(): replace integer with void pointer