[PATCH] ath10k: Re-enable TXQs for all devices

2017-11-08 Thread Toke Høiland-Jørgensen 
Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
mac80211 TXQs for some devices because of a theoretical throughput
regression. We have not seen this regression for a while now, so it
should be safe to re-enable TXQs.

Signed-off-by: Toke Høiland-Jørgensen 
---
This has been in LEDE trunk for a couple of months now with good results.

 drivers/net/wireless/ath/ath10k/mac.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947eef348d..ca596ecd2d64 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -8329,15 +8329,6 @@ int ath10k_mac_register(struct ath10k *ar)
ath10k_warn(ar, "failed to initialise DFS pattern 
detector\n");
}
 
-   /* Current wake_tx_queue implementation imposes a significant
-* performance penalty in some setups. The tx scheduling code needs
-* more work anyway so disable the wake_tx_queue unless firmware
-* supports the pull-push mechanism.
-*/
-   if (!test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
- ar->running_fw->fw_file.fw_features))
-   ar->ops->wake_tx_queue = NULL;
-
ret = ath10k_mac_init_rd(ar);
if (ret) {
ath10k_err(ar, "failed to derive regdom: %d\n", ret);
-- 
2.15.0

Re: Need support for Intel new wifi module 9462NGW

2017-11-08 Thread Luca Coelho 
Hi Chris,


On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
> Hi Luca,
> Any suggestion for the "Failed to start INIT ucode: -110" issue
> for the firmware?

We are investigating this now.  This seems to be related to the secure
boot key not being valid...

I'll let you know when we progress on this.


--
Cheers,
Luca.

Re: Need support for Intel new wifi module 9462NGW

2017-11-08 Thread Chris Chiu 
Hi Luca,
Any suggestion for the "Failed to start INIT ucode: -110" issue
for the firmware?

Chris

On Tue, Nov 7, 2017 at 12:26 PM, Chris Chiu  wrote:
> Hi Luca,
> I just tried the firmware but seems still something wrong. dmesg
> shows me the following
>
> [   17.786041] Intel(R) Wireless WiFi driver for Linux
> [   17.786042] Copyright(c) 2003- 2015 Intel Corporation
> [   18.120052] iwlwifi :00:0c.0: loaded firmware version
> 33.610294.0 op_mode iwlmvm
> [   20.995731] iwlwifi :00:0c.0: Detected Intel(R) Dual Band
> Wireless AC 9460, REV=0x318
> [   22.012109] iwlwifi :00:0c.0: SecBoot CPU1 Status: 0x3, CPU2
> Status: 0x2339
> [   22.012115] iwlwifi :00:0c.0: Failed to start INIT ucode: -110
> [   22.024100] iwlwifi :00:0c.0: Failed to run INIT ucode: -110
>
> Any more information you need from me?
>
> Chris
>
> On Mon, Nov 6, 2017 at 3:22 PM, Luca Coelho  wrote:
>> On Mon, 2017-11-06 at 11:22 +0800, Chris Chiu wrote:
>>> Hi Luca,
>>
>> Hi Chris,
>>
>>
>>> Any update for the firmware approval?
>>
>> Yes, I published it last Thursday.  Sorry, I was in such a hurry that I
>>  forgot to tell you about it.
>>
>> You can find it here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-9260-th-b0-jf-b0-33.ucode?id=f132386b542b52ade0416ecb6cb7aef426f5d175
>>
>> Let me know how it goes.
>>
>> --
>> Cheers,
>> Luca.

[PATCH V2 0/7] brcmfmac: firmware halt and scan cleanup

2017-11-08 Thread Arend van Spriel 
This series is a resubmission. No changes were being made compared
to the previous series.

  * handling firmware halt indication.
  * cleanup scan related code.

The series applies to the master branch of the wireless-drivers-next
repository and is intended for v4.15 kernel.

Arend Van Spriel (6):
  brcmfmac: handle FWHALT mailbox indication
  brcmfmac: cleanup brcmf_cfg80211_escan() function
  brcmfmac: use msecs_to_jiffies() instead of calculation using HZ
  brcmfmac: get rid of brcmf_cfg80211_escan() function
  brcmfmac: get rid of struct brcmf_cfg80211_info::active_scan field
  brcmfmac: move configuration of probe request IEs

Franky Lin (1):
  brcmfmac: disable packet filtering in promiscuous mode

 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 162 -
 .../broadcom/brcm80211/brcmfmac/cfg80211.h |   2 -
 .../wireless/broadcom/brcm80211/brcmfmac/core.c|  38 +
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|   1 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c |  11 +-
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c|  14 +-
 6 files changed, 77 insertions(+), 151 deletions(-)

-- 
1.9.1

[PATCH V2 6/7] brcmfmac: get rid of struct brcmf_cfg80211_info::active_scan field

2017-11-08 Thread Arend van Spriel 
From: Arend Van Spriel 

The field struct brcmf_cfg80211_info::active_scan is set to true upon
initializing the driver instance, but it is never changed so simply
get rid of it.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 10 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h |  2 --
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c  |  5 +
 3 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 31a80a6..9b334e2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1043,7 +1043,6 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
 {
struct brcmf_cfg80211_info *cfg = ifp->drvr->config;
s32 err;
-   u32 passive_scan;
struct brcmf_scan_results *results;
struct escan_info *escan = >escan_info;
 
@@ -1051,13 +1050,7 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
escan->ifp = ifp;
escan->wiphy = cfg->wiphy;
escan->escan_state = WL_ESCAN_STATE_SCANNING;
-   passive_scan = cfg->active_scan ? 0 : 1;
-   err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_PASSIVE_SCAN,
-   passive_scan);
-   if (err) {
-   brcmf_err("error (%d)\n", err);
-   return err;
-   }
+
brcmf_scan_config_mpc(ifp, 0);
results = (struct brcmf_scan_results *)cfg->escan_info.escan_buf;
results->version = 0;
@@ -5767,7 +5760,6 @@ static s32 wl_init_priv(struct brcmf_cfg80211_info *cfg)
 
cfg->scan_request = NULL;
cfg->pwr_save = true;
-   cfg->active_scan = true;/* we do active scan per default */
cfg->dongle_up = false; /* dongle is not up yet */
err = brcmf_init_priv_mem(cfg);
if (err)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
index 7b2835e..b5b5f0f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
@@ -283,7 +283,6 @@ struct brcmf_cfg80211_wowl {
  * @scan_status: scan activity on the dongle.
  * @pub: common driver information.
  * @channel: current channel.
- * @active_scan: current scan mode.
  * @int_escan_map: bucket map for which internal e-scan is done.
  * @ibss_starter: indicates this sta is ibss starter.
  * @pwr_save: indicate whether dongle to support power save mode.
@@ -316,7 +315,6 @@ struct brcmf_cfg80211_info {
unsigned long scan_status;
struct brcmf_pub *pub;
u32 channel;
-   bool active_scan;
u32 int_escan_map;
bool ibss_starter;
bool pwr_save;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index 1c450c0..c6cccb8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -692,10 +692,7 @@ static s32 brcmf_p2p_escan(struct brcmf_p2p_info *p2p, u32 
num_chans,
 
/* determine the scan engine parameters */
sparams->bss_type = DOT11_BSSTYPE_ANY;
-   if (p2p->cfg->active_scan)
-   sparams->scan_type = 0;
-   else
-   sparams->scan_type = 1;
+   sparams->scan_type = BRCMF_SCANTYPE_ACTIVE;
 
eth_broadcast_addr(sparams->bssid);
sparams->home_time = cpu_to_le32(P2PAPI_SCAN_HOME_TIME_MS);
-- 
1.9.1

[PATCH V2 1/7] brcmfmac: handle FWHALT mailbox indication

2017-11-08 Thread Arend van Spriel 
From: Arend Van Spriel 

The firmware uses a mailbox to communicate to the host what is going
on. In the driver we validate the bit received. Various people seen
the following message:

 brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Bit 4 is cause of this message, but this actually indicates the firmware
has halted. Handle this bit by giving a more meaningful error message.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 5adce0e..00de73d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -260,10 +260,11 @@ struct rte_console {
 #define I_HMB_HOST_INT I_HMB_SW3   /* Miscellaneous Interrupt */
 
 /* tohostmailboxdata */
-#define HMB_DATA_NAKHANDLED1   /* retransmit NAK'd frame */
-#define HMB_DATA_DEVREADY  2   /* talk to host after enable */
-#define HMB_DATA_FC4   /* per prio flowcontrol update flag */
-#define HMB_DATA_FWREADY   8   /* fw ready for protocol activity */
+#define HMB_DATA_NAKHANDLED0x0001  /* retransmit NAK'd frame */
+#define HMB_DATA_DEVREADY  0x0002  /* talk to host after enable */
+#define HMB_DATA_FC0x0004  /* per prio flowcontrol update flag */
+#define HMB_DATA_FWREADY   0x0008  /* fw ready for protocol activity */
+#define HMB_DATA_FWHALT0x0010  /* firmware halted */
 
 #define HMB_DATA_FCDATA_MASK   0xff00
 #define HMB_DATA_FCDATA_SHIFT  24
@@ -1094,6 +1095,10 @@ static u32 brcmf_sdio_hostmail(struct brcmf_sdio *bus)
  offsetof(struct sdpcmd_regs, tosbmailbox));
bus->sdcnt.f1regdata += 2;
 
+   /* dongle indicates the firmware has halted/crashed */
+   if (hmb_data & HMB_DATA_FWHALT)
+   brcmf_err("mailbox indicates firmware halted\n");
+
/* Dongle recomposed rx frames, accept them again */
if (hmb_data & HMB_DATA_NAKHANDLED) {
brcmf_dbg(SDIO, "Dongle reports NAK handled, expect rtx of 
%d\n",
@@ -1151,6 +1156,7 @@ static u32 brcmf_sdio_hostmail(struct brcmf_sdio *bus)
 HMB_DATA_NAKHANDLED |
 HMB_DATA_FC |
 HMB_DATA_FWREADY |
+HMB_DATA_FWHALT |
 HMB_DATA_FCDATA_MASK | HMB_DATA_VERSION_MASK))
brcmf_err("Unknown mailbox data content: 0x%02x\n",
  hmb_data);
-- 
1.9.1

[PATCH V2 3/7] brcmfmac: cleanup brcmf_cfg80211_escan() function

2017-11-08 Thread Arend van Spriel 
From: Arend Van Spriel 

The function brcmf_cfg80211_escan() was always called with a non-null
request parameter and null pointer for this_ssid parameter. Clean up
the function removing the dead code path.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 76 --
 1 file changed, 11 insertions(+), 65 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 051d51d..1283798 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1072,18 +1072,10 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
 
 static s32
 brcmf_cfg80211_escan(struct wiphy *wiphy, struct brcmf_cfg80211_vif *vif,
-struct cfg80211_scan_request *request,
-struct cfg80211_ssid *this_ssid)
+struct cfg80211_scan_request *request)
 {
-   struct brcmf_if *ifp = vif->ifp;
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
-   struct cfg80211_ssid *ssids;
-   u32 passive_scan;
-   bool escan_req;
-   bool spec_scan;
s32 err;
-   struct brcmf_ssid_le ssid_le;
-   u32 SSID_len;
 
brcmf_dbg(SCAN, "START ESCAN\n");
 
@@ -1101,8 +1093,8 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
  cfg->scan_status);
return -EAGAIN;
}
-   if (test_bit(BRCMF_VIF_STATUS_CONNECTING, >vif->sme_state)) {
-   brcmf_err("Connecting: status (%lu)\n", ifp->vif->sme_state);
+   if (test_bit(BRCMF_VIF_STATUS_CONNECTING, >sme_state)) {
+   brcmf_err("Connecting: status (%lu)\n", vif->sme_state);
return -EAGAIN;
}
 
@@ -1110,63 +1102,17 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
if (vif == cfg->p2p.bss_idx[P2PAPI_BSSCFG_DEVICE].vif)
vif = cfg->p2p.bss_idx[P2PAPI_BSSCFG_PRIMARY].vif;
 
-   escan_req = false;
-   if (request) {
-   /* scan bss */
-   ssids = request->ssids;
-   escan_req = true;
-   } else {
-   /* scan in ibss */
-   /* we don't do escan in ibss */
-   ssids = this_ssid;
-   }
-
cfg->scan_request = request;
set_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status);
-   if (escan_req) {
-   cfg->escan_info.run = brcmf_run_escan;
-   err = brcmf_p2p_scan_prep(wiphy, request, vif);
-   if (err)
-   goto scan_out;
-
-   err = brcmf_do_escan(vif->ifp, request);
-   if (err)
-   goto scan_out;
-   } else {
-   brcmf_dbg(SCAN, "ssid \"%s\", ssid_len (%d)\n",
- ssids->ssid, ssids->ssid_len);
-   memset(_le, 0, sizeof(ssid_le));
-   SSID_len = min_t(u8, sizeof(ssid_le.SSID), ssids->ssid_len);
-   ssid_le.SSID_len = cpu_to_le32(0);
-   spec_scan = false;
-   if (SSID_len) {
-   memcpy(ssid_le.SSID, ssids->ssid, SSID_len);
-   ssid_le.SSID_len = cpu_to_le32(SSID_len);
-   spec_scan = true;
-   } else
-   brcmf_dbg(SCAN, "Broadcast scan\n");
 
-   passive_scan = cfg->active_scan ? 0 : 1;
-   err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_PASSIVE_SCAN,
-   passive_scan);
-   if (err) {
-   brcmf_err("WLC_SET_PASSIVE_SCAN error (%d)\n", err);
-   goto scan_out;
-   }
-   brcmf_scan_config_mpc(ifp, 0);
-   err = brcmf_fil_cmd_data_set(ifp, BRCMF_C_SCAN, _le,
-sizeof(ssid_le));
-   if (err) {
-   if (err == -EBUSY)
-   brcmf_dbg(INFO, "BUSY: scan for \"%s\" 
canceled\n",
- ssid_le.SSID);
-   else
-   brcmf_err("WLC_SCAN error (%d)\n", err);
+   cfg->escan_info.run = brcmf_run_escan;
+   err = brcmf_p2p_scan_prep(wiphy, request, vif);
+   if (err)
+   goto scan_out;
 
-   brcmf_scan_config_mpc(ifp, 1);
-   goto scan_out;
-   }
-   }
+   err = brcmf_do_escan(vif->ifp, request);
+   if (err)
+   goto scan_out;
 
/* Arm scan timeout timer */
mod_timer(>escan_timeout, jiffies +
@@

[PATCH V2 4/7] brcmfmac: use msecs_to_jiffies() instead of calculation using HZ

2017-11-08 Thread Arend van Spriel 
From: Arend Van Spriel 

Minor cleanup using provided macro to convert milliseconds interval
to jiffies in brcmf_cfg80211_escan().

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 1283798..afdf6bb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1115,8 +1115,8 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
goto scan_out;
 
/* Arm scan timeout timer */
-   mod_timer(>escan_timeout, jiffies +
-   BRCMF_ESCAN_TIMER_INTERVAL_MS * HZ / 1000);
+   mod_timer(>escan_timeout,
+ jiffies + msecs_to_jiffies(BRCMF_ESCAN_TIMER_INTERVAL_MS));
 
return 0;
 
-- 
1.9.1

[PATCH V2 7/7] brcmfmac: move configuration of probe request IEs

2017-11-08 Thread Arend van Spriel 
From: Arend Van Spriel 

The configuration of the IEs for probe requests was done in a P2P
related function, which is not very obvious. Moving it to
.scan callback function, ie. brcmf_cfg80211_scan().

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c  | 6 ++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 9b334e2..6e70df9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1108,6 +1108,11 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
if (err)
goto scan_out;
 
+   err = brcmf_vif_set_mgmt_ie(vif, BRCMF_VNDR_IE_PRBREQ_FLAG,
+   request->ie, request->ie_len);
+   if (err)
+   goto scan_out;
+
err = brcmf_do_escan(vif->ifp, request);
if (err)
goto scan_out;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index c6cccb8..2ee5413 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -881,7 +881,7 @@ int brcmf_p2p_scan_prep(struct wiphy *wiphy,
 {
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
struct brcmf_p2p_info *p2p = >p2p;
-   int err = 0;
+   int err;
 
if (brcmf_p2p_scan_is_p2p_request(request)) {
/* find my listen channel */
@@ -904,9 +904,7 @@ int brcmf_p2p_scan_prep(struct wiphy *wiphy,
/* override .run_escan() callback. */
cfg->escan_info.run = brcmf_p2p_run_escan;
}
-   err = brcmf_vif_set_mgmt_ie(vif, BRCMF_VNDR_IE_PRBREQ_FLAG,
-   request->ie, request->ie_len);
-   return err;
+   return 0;
 }
 
 
-- 
1.9.1

[PATCH V2 5/7] brcmfmac: get rid of brcmf_cfg80211_escan() function

2017-11-08 Thread Arend van Spriel 
From: Arend Van Spriel 

The function brcmf_cfg80211_escan() is only called by brcmf_cfg80211_scan()
so there is no reason to split in two function especially since the latter
does not do an awful lot.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 34 +++---
 1 file changed, 10 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index afdf6bb..31a80a6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1071,13 +1071,16 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
 }
 
 static s32
-brcmf_cfg80211_escan(struct wiphy *wiphy, struct brcmf_cfg80211_vif *vif,
-struct cfg80211_scan_request *request)
+brcmf_cfg80211_scan(struct wiphy *wiphy, struct cfg80211_scan_request *request)
 {
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
-   s32 err;
+   struct brcmf_cfg80211_vif *vif;
+   s32 err = 0;
 
-   brcmf_dbg(SCAN, "START ESCAN\n");
+   brcmf_dbg(TRACE, "Enter\n");
+   vif = container_of(request->wdev, struct brcmf_cfg80211_vif, wdev);
+   if (!check_vif_up(vif))
+   return -EIO;
 
if (test_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status)) {
brcmf_err("Scanning already: status (%lu)\n", cfg->scan_status);
@@ -1102,6 +1105,8 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
if (vif == cfg->p2p.bss_idx[P2PAPI_BSSCFG_DEVICE].vif)
vif = cfg->p2p.bss_idx[P2PAPI_BSSCFG_PRIMARY].vif;
 
+   brcmf_dbg(SCAN, "START ESCAN\n");
+
cfg->scan_request = request;
set_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status);
 
@@ -1121,31 +1126,12 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
return 0;
 
 scan_out:
+   brcmf_err("scan error (%d)\n", err);
clear_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status);
cfg->scan_request = NULL;
return err;
 }
 
-static s32
-brcmf_cfg80211_scan(struct wiphy *wiphy, struct cfg80211_scan_request *request)
-{
-   struct brcmf_cfg80211_vif *vif;
-   s32 err = 0;
-
-   brcmf_dbg(TRACE, "Enter\n");
-   vif = container_of(request->wdev, struct brcmf_cfg80211_vif, wdev);
-   if (!check_vif_up(vif))
-   return -EIO;
-
-   err = brcmf_cfg80211_escan(wiphy, vif, request);
-
-   if (err)
-   brcmf_err("scan error (%d)\n", err);
-
-   brcmf_dbg(TRACE, "Exit\n");
-   return err;
-}
-
 static s32 brcmf_set_rts(struct net_device *ndev, u32 rts_threshold)
 {
s32 err = 0;
-- 
1.9.1

[PATCH V2 2/7] brcmfmac: disable packet filtering in promiscuous mode

2017-11-08 Thread Arend van Spriel 
From: Franky Lin 

Disable arp and nd offload to allow all packets sending to host.

Reported-by: Phil Elwell 
Tested-by: Phil Elwell 
Reviewed-by: Arend Van Spriel 
Signed-off-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 41 --
 .../wireless/broadcom/brcm80211/brcmfmac/core.c| 38 
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|  1 +
 3 files changed, 39 insertions(+), 41 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 4bfd43a..051d51d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -472,47 +472,6 @@ static void convert_key_from_CPU(struct brcmf_wsec_key 
*key,
return err;
 }
 
-static s32
-brcmf_configure_arp_nd_offload(struct brcmf_if *ifp, bool enable)
-{
-   s32 err;
-   u32 mode;
-
-   if (enable)
-   mode = BRCMF_ARP_OL_AGENT | BRCMF_ARP_OL_PEER_AUTO_REPLY;
-   else
-   mode = 0;
-
-   /* Try to set and enable ARP offload feature, this may fail, then it  */
-   /* is simply not supported and err 0 will be returned */
-   err = brcmf_fil_iovar_int_set(ifp, "arp_ol", mode);
-   if (err) {
-   brcmf_dbg(TRACE, "failed to set ARP offload mode to 0x%x, err = 
%d\n",
- mode, err);
-   err = 0;
-   } else {
-   err = brcmf_fil_iovar_int_set(ifp, "arpoe", enable);
-   if (err) {
-   brcmf_dbg(TRACE, "failed to configure (%d) ARP offload 
err = %d\n",
- enable, err);
-   err = 0;
-   } else
-   brcmf_dbg(TRACE, "successfully configured (%d) ARP 
offload to 0x%x\n",
- enable, mode);
-   }
-
-   err = brcmf_fil_iovar_int_set(ifp, "ndoe", enable);
-   if (err) {
-   brcmf_dbg(TRACE, "failed to configure (%d) ND offload err = 
%d\n",
- enable, err);
-   err = 0;
-   } else
-   brcmf_dbg(TRACE, "successfully configured (%d) ND offload to 
0x%x\n",
- enable, mode);
-
-   return err;
-}
-
 static void
 brcmf_cfg80211_update_proto_addr_mode(struct wireless_dev *wdev)
 {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 5cc3a07..9c7536d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -71,6 +71,43 @@ struct brcmf_if *brcmf_get_ifp(struct brcmf_pub *drvr, int 
ifidx)
return ifp;
 }
 
+void brcmf_configure_arp_nd_offload(struct brcmf_if *ifp, bool enable)
+{
+   s32 err;
+   u32 mode;
+
+   if (enable)
+   mode = BRCMF_ARP_OL_AGENT | BRCMF_ARP_OL_PEER_AUTO_REPLY;
+   else
+   mode = 0;
+
+   /* Try to set and enable ARP offload feature, this may fail, then it  */
+   /* is simply not supported and err 0 will be returned */
+   err = brcmf_fil_iovar_int_set(ifp, "arp_ol", mode);
+   if (err) {
+   brcmf_dbg(TRACE, "failed to set ARP offload mode to 0x%x, err = 
%d\n",
+ mode, err);
+   } else {
+   err = brcmf_fil_iovar_int_set(ifp, "arpoe", enable);
+   if (err) {
+   brcmf_dbg(TRACE, "failed to configure (%d) ARP offload 
err = %d\n",
+ enable, err);
+   } else {
+   brcmf_dbg(TRACE, "successfully configured (%d) ARP 
offload to 0x%x\n",
+ enable, mode);
+   }
+   }
+
+   err = brcmf_fil_iovar_int_set(ifp, "ndoe", enable);
+   if (err) {
+   brcmf_dbg(TRACE, "failed to configure (%d) ND offload err = 
%d\n",
+ enable, err);
+   } else {
+   brcmf_dbg(TRACE, "successfully configured (%d) ND offload to 
0x%x\n",
+ enable, mode);
+   }
+}
+
 static void _brcmf_set_multicast_list(struct work_struct *work)
 {
struct brcmf_if *ifp;
@@ -134,6 +171,7 @@ static void _brcmf_set_multicast_list(struct work_struct 
*work)
if (err < 0)
brcmf_err("Setting BRCMF_C_SET_PROMISC failed, %d\n",
  err);
+   brcmf_configure_arp_nd_offload(ifp, !cmd_value);
 }
 
 #if IS_ENABLED(CONFIG_IPV6)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h

Re: [PATCH] brcmfmac: add support for external 32khz clock

2017-11-08 Thread Simon Shields 
On Wed, Nov 08, 2017 at 10:43:05PM +1100, Simon Shields wrote:
> Hi Arend,
> 
> On Wed, Nov 08, 2017 at 11:38:11AM +0100, Arend van Spriel wrote:
> > + Stefan
> > 
> > On 11/7/2017 2:31 PM, Simon Shields wrote:
> > > Hi Arend,
> > > 
> > > On Tue, Nov 07, 2017 at 12:09:23PM +0100, Arend van Spriel wrote:
> > > > On 11/6/2017 12:27 PM, Simon Shields wrote:
> > > > > On Mon, Nov 06, 2017 at 11:59:37AM +0100, Arend van Spriel wrote:
> > > > > > On 11/4/2017 2:24 PM, Simon Shields wrote:
> > > > > > > Some boards use an external 32khz clock for low-power
> > > > > > > mode timing. Make sure the clock is powered on while the chipset
> > > > > > > is active.
> > > > > > 
> > > > > > Do you have such a board? With the little documentation I can get 
> > > > > > my hands
> > > > > > on here I wonder whether the clock needs to be enabled before the 
> > > > > > device is
> > > > > > powered. If you have the hardware I would like to check some 
> > > > > > registers in
> > > > > > the device.
> > > > > > 
> > > > > 
> > > > > Yes. Trats2 (exynos4412-based) has such a setup. The BCM4334 works 
> > > > > fine
> > > > > with this patch and one more that enables the WL_REG_EN pin when
> > > > > brcmfmac is probed.
> > > > 
> > > > Ok. So this is exactly the thing I was wondering about. So it makes me
> > > > curious how the WL_REG_EN patch looks like. Can you provide that?
> > > > 
> > > 
> > > Here[0] is a link to the patch in its current state. Obviously, it's not
> > > ready at all for mainlining :-)
> > > 
> > > [0]: 
> > > https://github.com/fourkbomb/linux/commit/436e59e58b44d856c186fc4767560cecbcbc0c59.patch
> > 
> > Thanks. Indeed doing it in module_init of brcmfmac is not going to fly.
> > Actually the MMC stack has a mechanism to power the SDIO device. This can be
> > configured through the device tree [1]. I just checked and it actually
> > includes specifying the external clock as well.
> > 
> 
> It looks like mmc-pwrseq-simple would handle the clock case, but it
> doesn't handle the regulator properly: it sets the GPIO to high before
> powering on, then lowers it immediately after powering it on.
> 
> I guess a simpler approach here would be to extend pwrseq-simple to behave
> as we need it to.

I missed something really obvious... All that's needed is to invert the
GPIO, like this[0]. Thanks for the pointer :)

Cheers,
Simon

[0]: https://patchwork.kernel.org/patch/10048501/

Re: zd1201: remove unused variable framelen

2017-11-08 Thread Kalle Valo 
Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Variable framelen is assigned but never read, hence it is redundant
> and can be removed. Cleans up clang warning:
> 
> drivers/net/wireless/zydas/zd1201.c:234:3: warning: Value stored
> to 'framelen' is never read
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

03e40f1e7680 zd1201: remove unused variable framelen

-- 
https://patchwork.kernel.org/patch/10047145/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: iwlegacy: remove redundant pointer sta_priv

2017-11-08 Thread Kalle Valo 
Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Pointer sta_priv is assigned but never read, hence it is redundant
> and can be removed. Cleans up clang warning:
> 
> drivers/net/wireless/intel/iwlegacy/4965-rs.c:2163:2: warning: Value
> stored to 'sta_priv' is never read
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

6c6e25311312 iwlegacy: remove redundant pointer sta_priv

-- 
https://patchwork.kernel.org/patch/10036047/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [08/11] rtlwifi: rtl_pci: Refactor TX/RX flow

2017-11-08 Thread Kalle Valo 
Larry Finger  wrote:

> From: Steven Ting 
> 
> After this refactoring, the variables wp and rp in TX ring can only be
> updated in OP_TX and TX_OK respectively without protection. The other
> changes are listed below:
> 
> 1. remove avl_desc from TX ring, because it can be calculated by wp and rp.
>Moreover, we update this variable in op_tx (thread context) and TX_OK
>(BH context) without protection.
> 2. extend calc_fifo_space(rp, wp) to calc_fifo_space(rp, wp, size), and fix
>the caller's parameter 'size'.
> 3. Get RX remaining counter only if it count down to zero.
> 4. remove available_desc check from Tx ISR
> 
> Signed-off-by: Steven Ting 
> Signed-off-by: Ping-Ke Shih 
> Signed-off-by: Larry Finger 
> Cc: Yan-Hsuan Chuang 
> Cc: Birming Chiu 
> Cc: Shaofu 

Dropping the rest of the series based on my comments.

4 patches set to Changes Requested.

10036501 [08/11] rtlwifi: rtl_pci: Refactor TX/RX flow
10036503 [09/11] rtlwifi: rtl_pci: 8822BE puts broadcast and multicast packet 
to HIQ
10036507 [10/11] rtlwifi: Add beacon check mechanism to check if AP settings 
changed.
10036505 [11/11] rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.

-- 
https://patchwork.kernel.org/patch/10036501/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: rtlwifi: remove redundant initialization to cfg_cmd

2017-11-08 Thread Kalle Valo 
Colin Ian King  wrote:

> From: Colin Ian King 
> 
> cfg_cmd is initialized to zero and this value is never read, instead
> it is over-written in the start of a do-while loop. Remove the
> redundant initialization. Cleans up clang warning:
> 
> drivers/net/wireless/realtek/rtlwifi/core.c:1750:22: warning: Value
> stored to 'cfg_cmd' during its initialization is never read
> 
> Signed-off-by: Colin Ian King 
> Acked-by: Larry Finger 

Patch applied to wireless-drivers-next.git, thanks.

f80ead1cd5fa rtlwifi: remove redundant initialization to cfg_cmd

-- 
https://patchwork.kernel.org/patch/10041685/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: rtlwifi: remove redundant pointer tid_data

2017-11-08 Thread Kalle Valo 
Colin Ian King  wrote:

> From: Colin Ian King 
> 
> tid_data is assigned but never read, hence it is redundant
> and can be removed. Cleans up clang warning:
> 
> drivers/net/wireless/realtek/rtlwifi/base.c:1581:2: warning: Value
> stored to 'tid_data' is never read
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

82e730e521ce rtlwifi: remove redundant pointer tid_data

-- 
https://patchwork.kernel.org/patch/10040293/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [1/3] rtlwifi: fix uninitialized rtlhal->last_suspend_sec time

2017-11-08 Thread Kalle Valo 
Arnd Bergmann  wrote:

> We set rtlhal->last_suspend_sec to an uninitialized stack variable,
> but unfortunately gcc never warned about this, I only found it
> while working on another patch. I opened a gcc bug for this.
> 
> Presumably the value of rtlhal->last_suspend_sec is not all that
> important, but it does get used, so we probably want the
> patch backported to stable kernels.
> 
> Cc: sta...@vger.kernel.org
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839
> Signed-off-by: Arnd Bergmann 
> Acked-by: Larry Finger 

3 patches applied to wireless-drivers-next.git, thanks.

3f2a162fab15 rtlwifi: fix uninitialized rtlhal->last_suspend_sec time
3c92d5517af8 rtlwifi: use ktime_get_real_seconds() for suspend time
ac978dc79a91 rtlwifi: drop unused ppsc->last_wakeup_time

-- 
https://patchwork.kernel.org/patch/10043505/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [01/11] rtlwifi: rtl_pci: Fix formatting errors in pci.h

2017-11-08 Thread Kalle Valo 
Larry Finger  wrote:

> Checkpatch.pl reports a number of formatting problems in this header
> file. None of the changes cause any functional changes in the driver.
> 
> Signed-off-by: Larry Finger 
> Cc: Ping-Ke Shih 
> Cc: Yan-Hsuan Chuang 
> Cc: Birming Chiu 
> Cc: Shaofu 
> Cc: Steven Ting 

7 patches applied to wireless-drivers-next.git, thanks.

6bc05d5d8e9d rtlwifi: rtl_pci: Fix formatting errors in pci.h
ae0122b6793d rtlwifi: rtl_pci: Fix formatting problems in pci.c
5f647f4dfe41 rtlwifi: rtl_pci: Simplify some code be eliminating extraneous 
variables
57869e4ba77a rtlwifi: rtl_pci: Add support for 8822be TX/RX BD
89d3e8abcf24 rtlwifi: rtl_pci: Add fill_tx_special_desc to issue H2C data, and 
process TXOK in interrupt.
68929a838000 rtlwifi: rtl_pci: Add ID for 8822BE
c1b586402c15 rtlwifi: rtl_pci: Extend recognized interrupt parameters from two 
to four ISR

-- 
https://patchwork.kernel.org/patch/10036495/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 08/11] rtlwifi: rtl_pci: Refactor TX/RX flow

2017-11-08 Thread Kalle Valo 
Larry Finger  writes:

> From: Steven Ting 
>
> After this refactoring, the variables wp and rp in TX ring can only be
> updated in OP_TX and TX_OK respectively without protection.

Why? Try to always answer that, that's the most important part of the
commit log. Are you fixing a bug (if yes, describe it briefly), is this
just code cleanup or what's your motivation to change the code?

> The other changes are listed below:
>
> 1. remove avl_desc from TX ring, because it can be calculated by wp and rp.
>Moreover, we update this variable in op_tx (thread context) and TX_OK
>(BH context) without protection.
> 2. extend calc_fifo_space(rp, wp) to calc_fifo_space(rp, wp, size), and fix
>the caller's parameter 'size'.
> 3. Get RX remaining counter only if it count down to zero.
> 4. remove available_desc check from Tx ISR

One logical change per patch, please. One good rule of thumb is that if
you have to list the changes made in patch you need to split the patch.

-- 
Kalle Valo

Re: [PATCH 07/11] rtlwifi: rtl_pci: Extend recognized interrupt parameters from two to four ISR

2017-11-08 Thread Kalle Valo 
Larry Finger  writes:

> From: Ping-Ke Shih 
>
> 8822be checks H2CQ by int_d, so we extend to four ISR.
> Also, irq_mask is extended to four.
>
> Signed-off-by: Ping-Ke Shih 
> Signed-off-by: Larry Finger 
> Cc: Yan-Hsuan Chuang 
> Cc: Birming Chiu 
> Cc: Shaofu 
> Cc: Steven Ting 

[...]

> @@ -936,7 +937,7 @@ static irqreturn_t _rtl_pci_interrupt(int irq, void 
> *dev_id)
>   rtlpriv->cfg->ops->disable_interrupt(hw);
>  
>   /*read ISR: 4/8bytes */
> - rtlpriv->cfg->ops->interrupt_recognized(hw, , );
> + rtlpriv->cfg->ops->interrupt_recognized(hw, , , , );
>  
>   /*Shared IRQ or HW disappeared */
>   if (!inta || inta == 0x)
> diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.h 
> b/drivers/net/wireless/realtek/rtlwifi/pci.h
> index ce33fe7bc7c4..e7d070e8da2d 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/pci.h
> +++ b/drivers/net/wireless/realtek/rtlwifi/pci.h
> @@ -211,7 +211,7 @@ struct rtl_pci {
>  
>   /*irq */
>   u8 irq_alloc;
> - u32 irq_mask[2];
> + u32 irq_mask[4];/* 0-1: normal, 2: unused, 3: h2c */
>   u32 sys_irq_mask;
>  
>   /*Bcn control register setting */
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c 
> b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
> index 2c671364c521..e30a18e64ff5 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
> @@ -1472,7 +1472,8 @@ void rtl88ee_card_disable(struct ieee80211_hw *hw)
>  }
>  
>  void rtl88ee_interrupt_recognized(struct ieee80211_hw *hw,
> -   u32 *p_inta, u32 *p_intb)
> +   u32 *p_inta, u32 *p_intb,
> +   u32 *p_intc, u32 *p_intd)
>  {

In the future you might want to convert this to a struct which is a lot
easier to handle. But no need to resend because of this.

-- 
Kalle Valo

Re: [1/7] brcmfmac: handle FWHALT mailbox indication

2017-11-08 Thread Kalle Valo 
Arend van Spriel  writes:

> Hi Kalle,
>
> I was preparing a new patch series and got a bit confused. Turns out
> there was a series still pending in patchwork.
>
> https://patchwork.kernel.org/patch/9948825/

That's not pending, it's in "Changes Requested" meaning that I have
dropped them:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork

"Deferred" is the state when patch is pending an action from me. Yes,
patchwork state names suck :)

> So I applied the pending series on wireless-drivers-next and it
> compiles fine. So what I think happened is that the series depended on
> a patch that was submitted to wireless-drivers at that time. Can these
> patches be taken now or do I need to resubmit.

To keep things simple I would prefer you resubmit them. I'm at Netdev
2.2 right now so on a quite tight schedule to get everything ready
before the weekend when the merge window opens.

-- 
Kalle Valo

Re: [PATCH] brcmfmac: add support for external 32khz clock

2017-11-08 Thread Simon Shields 
Hi Arend,

On Wed, Nov 08, 2017 at 11:38:11AM +0100, Arend van Spriel wrote:
> + Stefan
> 
> On 11/7/2017 2:31 PM, Simon Shields wrote:
> > Hi Arend,
> > 
> > On Tue, Nov 07, 2017 at 12:09:23PM +0100, Arend van Spriel wrote:
> > > On 11/6/2017 12:27 PM, Simon Shields wrote:
> > > > On Mon, Nov 06, 2017 at 11:59:37AM +0100, Arend van Spriel wrote:
> > > > > On 11/4/2017 2:24 PM, Simon Shields wrote:
> > > > > > Some boards use an external 32khz clock for low-power
> > > > > > mode timing. Make sure the clock is powered on while the chipset
> > > > > > is active.
> > > > > 
> > > > > Do you have such a board? With the little documentation I can get my 
> > > > > hands
> > > > > on here I wonder whether the clock needs to be enabled before the 
> > > > > device is
> > > > > powered. If you have the hardware I would like to check some 
> > > > > registers in
> > > > > the device.
> > > > > 
> > > > 
> > > > Yes. Trats2 (exynos4412-based) has such a setup. The BCM4334 works fine
> > > > with this patch and one more that enables the WL_REG_EN pin when
> > > > brcmfmac is probed.
> > > 
> > > Ok. So this is exactly the thing I was wondering about. So it makes me
> > > curious how the WL_REG_EN patch looks like. Can you provide that?
> > > 
> > 
> > Here[0] is a link to the patch in its current state. Obviously, it's not
> > ready at all for mainlining :-)
> > 
> > [0]: 
> > https://github.com/fourkbomb/linux/commit/436e59e58b44d856c186fc4767560cecbcbc0c59.patch
> 
> Thanks. Indeed doing it in module_init of brcmfmac is not going to fly.
> Actually the MMC stack has a mechanism to power the SDIO device. This can be
> configured through the device tree [1]. I just checked and it actually
> includes specifying the external clock as well.
> 

It looks like mmc-pwrseq-simple would handle the clock case, but it
doesn't handle the regulator properly: it sets the GPIO to high before
powering on, then lowers it immediately after powering it on.

I guess a simpler approach here would be to extend pwrseq-simple to behave
as we need it to.

> Regards,
> Arend
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt

Cheers,
Simon

Re: Soft lockup in rt2x00usb_work_rxdone()

2017-11-08 Thread Stanislaw Gruszka 
On Wed, Nov 08, 2017 at 12:07:15PM +0100, Richard Genoud wrote:
> > No, that not I wanted you to do. Please remove those options and just
> > do
> > below on tracing directory.
> > 
> > echo 0 > tracing_on 
> > cat trace >  /dev/null
> > echo "function_graph" > current_tracer 
> > echo "rt2*" > set_ftrace_filter 
> > echo 1 > tracing_on
> > echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
> > echo 0 > tracing_on
> > cat trace > ~/trace.txt
> 
> Well, there's clearly a misunderstanding here :
> After the command "echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind"
> I can't type *anything*
> The only thing I can do is plug off the board.
> This command never returns, so I can't stop the tracing...
> 
> Or I missed something ?
> 
> (maybe if there was more than one CPU on the board, I could do
> something, but that's not the case)

I was not aware that soft-lock up can hung the system.

Below patch should prevent/help with the issue. This is
not right fix, it's for futher debugging.

Regards
Stanislaw 

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index e2f4f5778267..d76ca608c722 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -321,8 +321,8 @@ static bool rt2x00usb_kick_tx_entry(struct queue_entry 
*entry, void *data)
 
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
-   if (status == -ENODEV)
-   clear_bit(DEVICE_STATE_PRESENT, >flags);
+   printk("submit TX urb ERROR %d\n", status);
+   clear_bit(DEVICE_STATE_PRESENT, >flags);
set_bit(ENTRY_DATA_IO_FAILED, >flags);
rt2x00lib_dmadone(entry);
}
@@ -410,8 +410,8 @@ static bool rt2x00usb_kick_rx_entry(struct queue_entry 
*entry, void *data)
 
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
-   if (status == -ENODEV)
-   clear_bit(DEVICE_STATE_PRESENT, >flags);
+   printk("submit RX urb ERROR %d\n", status);
+   clear_bit(DEVICE_STATE_PRESENT, >flags);
set_bit(ENTRY_DATA_IO_FAILED, >flags);
rt2x00lib_dmadone(entry);
}

Re: Soft lockup in rt2x00usb_work_rxdone()

2017-11-08 Thread Richard Genoud 
Le mercredi 08 novembre 2017 à 11:37 +0100, Stanislaw Gruszka a écrit :
> On Tue, Nov 07, 2017 at 12:01:23PM +0100, Richard Genoud wrote:
> > Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a
> > écrit :
> > > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > > > 3 short articles how to configure and use ftrace are here:
> > > > > https://lwn.net/Articles/365835/
> > > > > https://lwn.net/Articles/366796/
> > > > > https://lwn.net/Articles/370423/
> > > > > 
> > > > 
> > > > I tried with ftrace, but I don't think there's a way to dump
> > > > the
> > > > trace
> > > > when there's a soft lock-up
> > > > (I can't do anything after the unbind, even the heartbeat led
> > > > stopped blinking).
> > > > I saw the /proc/sys/kernel/ftrace_dump_on_oops file, but
> > > > there's no
> > > > /proc/sys/kernel/ftrace_dump_on_soft_lock-up file :)
> > > 
> > > You should configure function trace with rt2x* functions. After
> > > that
> > > start tracing, unbind the device, then stop tracing and provide
> > > trace
> > > output.
> > 
> > Ok, I found a way to display the trace (after the unbind, the board
> > is
> > frozen and I can't type anything).
> > Adding
> > CONFIG_SOFTLOCKUP_DETECTOR=y
> > CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
> > along with echo 1 > /proc/sys/kernel/ftrace_dump_on_oops does the
> > trick
> 
> No, that not I wanted you to do. Please remove those options and just
> do
> below on tracing directory.
> 
> echo 0 > tracing_on 
> cat trace >  /dev/null
> echo "function_graph" > current_tracer 
> echo "rt2*" > set_ftrace_filter 
> echo 1 > tracing_on
> echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
> echo 0 > tracing_on
> cat trace > ~/trace.txt

Well, there's clearly a misunderstanding here :
After the command "echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind"
I can't type *anything*
The only thing I can do is plug off the board.
This command never returns, so I can't stop the tracing...

Or I missed something ?

(maybe if there was more than one CPU on the board, I could do
something, but that's not the case)

> 
> and provide trace.txt to me (can be in private email if big).
> 
> Thanks
> Stanislaw

Thanks,
Richard.

Re: Soft lockup in rt2x00usb_work_rxdone()

2017-11-08 Thread Stanislaw Gruszka 
On Tue, Nov 07, 2017 at 12:13:47PM +0100, Richard Genoud wrote:
> Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit :
> > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > > 3 short articles how to configure and use ftrace are here:
> > > > https://lwn.net/Articles/365835/
> > > > https://lwn.net/Articles/366796/
> > > > https://lwn.net/Articles/370423/
> > > > 
> > > 
> > > I tried with ftrace, but I don't think there's a way to dump the
> > > trace
> > > when there's a soft lock-up
> > > (I can't do anything after the unbind, even the heartbeat led
> > > stopped blinking).
> > > I saw the /proc/sys/kernel/ftrace_dump_on_oops file, but there's no
> > > /proc/sys/kernel/ftrace_dump_on_soft_lock-up file :)
> > 
> > You should configure function trace with rt2x* functions. After that
> > start tracing, unbind the device, then stop tracing and provide trace
> > output.
> Here is another trace, with rt2* as function filter.
> (sorry for the noise)
> 
> Dumping ftrace buffer:
> -
> CPU:0 [LOST 3606923 EVENTS]
>  0)   0.000 us|  } /* rt2x00usb_clear_entry */
>  0)   0.000 us|} /* rt2x00lib_rxdone */
>  0)   0.000 us|rt2x00queue_get_entry();
>  0)   |rt2x00lib_rxdone() {
>  0)   0.000 us|  rt2x00queue_index_inc();
>  0)   |  rt2x00usb_clear_entry() {
>  0)   |rt2x00usb_kick_rx_entry() {

We do that only if: 

if (test_bit(DEVICE_STATE_PRESENT, >flags) &&
test_bit(DEVICE_STATE_ENABLED_RADIO, >flags))
rt2x00dev->ops->lib->clear_entry(entry);

so looks like DEVICE_STATE_PRESENT is not cleared. That mean
usb driver do not call disconnect callback on unbind. That seems
to be usb driver bug. Anyway please provide requested traces,
so I will see what happen.

Stanislaw

Re: Soft lockup in rt2x00usb_work_rxdone()

2017-11-08 Thread Stanislaw Gruszka 
On Tue, Nov 07, 2017 at 12:01:23PM +0100, Richard Genoud wrote:
> Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit :
> > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > > 3 short articles how to configure and use ftrace are here:
> > > > https://lwn.net/Articles/365835/
> > > > https://lwn.net/Articles/366796/
> > > > https://lwn.net/Articles/370423/
> > > > 
> > > 
> > > I tried with ftrace, but I don't think there's a way to dump the
> > > trace
> > > when there's a soft lock-up
> > > (I can't do anything after the unbind, even the heartbeat led
> > > stopped blinking).
> > > I saw the /proc/sys/kernel/ftrace_dump_on_oops file, but there's no
> > > /proc/sys/kernel/ftrace_dump_on_soft_lock-up file :)
> > 
> > You should configure function trace with rt2x* functions. After that
> > start tracing, unbind the device, then stop tracing and provide trace
> > output.
> Ok, I found a way to display the trace (after the unbind, the board is
> frozen and I can't type anything).
> Adding
> CONFIG_SOFTLOCKUP_DETECTOR=y
> CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
> along with echo 1 > /proc/sys/kernel/ftrace_dump_on_oops does the trick

No, that not I wanted you to do. Please remove those options and just do
below on tracing directory.

echo 0 > tracing_on 
cat trace >  /dev/null
echo "function_graph" > current_tracer 
echo "rt2*" > set_ftrace_filter 
echo 1 > tracing_on
echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
echo 0 > tracing_on
cat trace > ~/trace.txt

and provide trace.txt to me (can be in private email if big).

Thanks
Stanislaw

RE: [1/7] brcmfmac: handle FWHALT mailbox indication

2017-11-08 Thread Arend van Spriel 

Hi Kalle,

I was preparing a new patch series and got a bit confused. Turns out 
there was a series still pending in patchwork.


https://patchwork.kernel.org/patch/9948825/

So I applied the pending series on wireless-drivers-next and it compiles 
fine. So what I think happened is that the series depended on a patch 
that was submitted to wireless-drivers at that time. Can these patches 
be taken now or do I need to resubmit.


Regards,
Arend