Re: [PATCH 1/3] cfg80211: Make pre-CAC results valid only for ETSI domain

[Thiagarajan, Vasanthakumar]

On Monday 27 February 2017 08:08 PM, Johannes Berg wrote:
> On Mon, 2017-02-20 at 16:09 +0530, Vasanthakumar Thiagarajan wrote:
>> DFS requirement for ETSI domain (section 4.7.1.4 in
>> ETSI EN 301 893 V1.8.1) is the only one which explicitly
>> states that once DFS channel is marked as available afer
>> the CAC, this channel will remain in available state even
>> moving to a different operating channel. But the same is
>> not explicitly stated in FCC DFS requirement. Also, Pre-CAC
>> requriements are not explicitly mentioned in FCC requirement.
>> Current implementation in keeping DFS channel in available
>> state is same as described in ETSI domain.
>>
>> For ETSI DFS domain, this patch gives a grace period of 2 seconds
>
> You mean non-ETSI, right?

Correct, I meant non-ETSI.

>
> Just making sure I understood correctly - no need to resend, I can fix
> that.

Thanks for pointing it out and fixing.

Vasanth

[PATCH v2 2/4] mac80211-hwsim: remove dmesg spam about get-survey.

[greearb]

From: Ben Greear 

This message just fills up dmesg and/or kernel logs and does
not provide any useful information.

Signed-off-by: Ben Greear 
---
 drivers/net/wireless/mac80211_hwsim.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index 12e9333..635ad03 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -1860,8 +1860,6 @@ static int mac80211_hwsim_get_survey(
 {
struct ieee80211_conf *conf = >conf;
 
-   wiphy_debug(hw->wiphy, "%s (idx=%d)\n", __func__, idx);
-
if (idx != 0)
return -ENOENT;
 
-- 
2.4.11

[PATCH v2 1/4] mac80211-hwsim: notify user-space about channel change.

[greearb]

From: Ben Greear 

The goal is to allow the user-space application to properly
filter packets before sending them down to the kernel.  This
should more closely mimic what a real piece of hardware would
do.

Signed-off-by: Ben Greear 
---
v2:  Change IDs, add new ones for width, freq1, freq2.

 drivers/net/wireless/mac80211_hwsim.c | 67 +++
 drivers/net/wireless/mac80211_hwsim.h | 16 +
 2 files changed, 83 insertions(+)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index 0150747..12e9333 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -527,6 +527,10 @@ struct mac80211_hwsim_data {
u8 scan_addr[ETH_ALEN];
 
struct ieee80211_channel *channel;
+   enum nl80211_chan_width ch_width;
+   u32 center_freq1;
+   u32 center_freq2;
+
u64 beacon_int  /* beacon interval in us */;
unsigned int rx_filter;
bool started, idle, scanning;
@@ -998,6 +1002,64 @@ static int hwsim_unicast_netgroup(struct 
mac80211_hwsim_data *data,
return res;
 }
 
+static void mac80211_hwsim_check_nl_notify(struct mac80211_hwsim_data *data)
+{
+   struct sk_buff *skb;
+   u32 center_freq = 0;
+   u32 _portid;
+   void *msg_head;
+
+   /* wmediumd mode check */
+   _portid = READ_ONCE(data->wmediumd);
+
+   if (!_portid)
+   return;
+
+   skb = genlmsg_new(GENLMSG_DEFAULT_SIZE, GFP_ATOMIC);
+   if (!skb)
+   goto err_print;
+
+   msg_head = genlmsg_put(skb, 0, 0, _genl_family, 0,
+  HWSIM_CMD_NOTIFY_CH_CHANGE);
+   if (!msg_head) {
+   pr_debug("mac80211_hwsim: problem with msg_head, 
notify-ch-change\n");
+   goto nla_put_failure;
+   }
+
+   if (nla_put_u32(skb, HWSIM_ATTR_RADIO_ID, data->idx))
+   goto nla_put_failure;
+
+   if (nla_put(skb, HWSIM_ATTR_ADDR_TRANSMITTER,
+   ETH_ALEN, data->addresses[1].addr))
+   goto nla_put_failure;
+
+   if (data->channel)
+   center_freq = data->channel->center_freq;
+
+   if (nla_put_u32(skb, HWSIM_ATTR_FREQ, center_freq))
+   goto nla_put_failure;
+
+   if (nla_put_u32(skb, HWSIM_ATTR_CH_FREQ1, data->center_freq1))
+   goto nla_put_failure;
+
+   if (nla_put_u32(skb, HWSIM_ATTR_CH_FREQ2, data->center_freq2))
+   goto nla_put_failure;
+
+   if (nla_put_u32(skb, HWSIM_ATTR_CH_WIDTH, data->ch_width))
+   goto nla_put_failure;
+
+   genlmsg_end(skb, msg_head);
+   if (genlmsg_unicast(_net, skb, _portid))
+   goto err_print;
+
+   return;
+
+nla_put_failure:
+   nlmsg_free(skb);
+err_print:
+   pr_debug("mac80211_hwsim: error occurred in %s\n", __func__);
+}
+
 static void mac80211_hwsim_tx_frame_nl(struct ieee80211_hw *hw,
   struct sk_buff *my_skb,
   int dst_portid)
@@ -1599,6 +1661,9 @@ static int mac80211_hwsim_config(struct ieee80211_hw *hw, 
u32 changed)
data->idle = !!(conf->flags & IEEE80211_CONF_IDLE);
 
data->channel = conf->chandef.chan;
+   data->ch_width = conf->chandef.width;
+   data->center_freq1 = conf->chandef.center_freq1;
+   data->center_freq2 = conf->chandef.center_freq2;
 
WARN_ON(data->channel && data->use_chanctx);
 
@@ -1615,6 +1680,8 @@ static int mac80211_hwsim_config(struct ieee80211_hw *hw, 
u32 changed)
  HRTIMER_MODE_REL);
}
 
+   mac80211_hwsim_check_nl_notify(data);
+
return 0;
 }
 
diff --git a/drivers/net/wireless/mac80211_hwsim.h 
b/drivers/net/wireless/mac80211_hwsim.h
index 39f2246..1251fdd 100644
--- a/drivers/net/wireless/mac80211_hwsim.h
+++ b/drivers/net/wireless/mac80211_hwsim.h
@@ -71,6 +71,15 @@ enum hwsim_tx_control_flags {
  * @HWSIM_CMD_DEL_RADIO: destroy a radio, reply is multicasted
  * @HWSIM_CMD_GET_RADIO: fetch information about existing radios, uses:
  * %HWSIM_ATTR_RADIO_ID
+ * @HWSIM_CMD_NOTIFY_CH_CHANGE: notify user-space about channel-change.  This 
is
+ * designed to help the user-space app better emulate radio hardware.
+ * This command uses:
+ * %HWSIM_ATTR_FREQ # Notify current operating center frequency.
+ * %HWSIM_ATTR_CH_FREQ1 # Configured center-freq-1.
+ * %HWSIM_ATTR_CH_FREQ2 # Configured center-freq-2.
+ * %HWSIM_ATTR_CH_WIDTH # Configured channel width.
+ * %HWSIM_ATTR_ADDR_TRANSMITTER # ID which radio we are notifying about.
+ * %HWSIM_ATTR_ADDR_ID # Numeric Radio ID.
  * @__HWSIM_CMD_MAX: enum limit
  */
 enum {
@@ -81,6 +90,7 @@ enum {
HWSIM_CMD_NEW_RADIO,
HWSIM_CMD_DEL_RADIO,
HWSIM_CMD_GET_RADIO,
+   HWSIM_CMD_NOTIFY_CH_CHANGE,
__HWSIM_CMD_MAX,
 };
 #define HWSIM_CMD_MAX 

[PATCH v2 4/4] mac80211-hwsim: add length checks before allocating skb.

[greearb]

From: Ben Greear 

Modify the receive-from-user-space logic to do length
and 'is-down' checks before trying to allocate an skb.

And, if we are going to ignore the pkt due to radio idle,
then do not return an error code to user-space.  User-space
cannot reliably know exactly when a radio is idle or not.

Signed-off-by: Ben Greear 
---

v2:  Don't return success when radio is idle, but do return unique
 error code (ENETDOWN) in hopes user-space can make a distinction.

 drivers/net/wireless/mac80211_hwsim.c | 41 +++
 1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index c259b99..73dc627 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3020,6 +3020,7 @@ static int hwsim_cloned_frame_received_nl(struct sk_buff 
*skb_2,
int frame_data_len;
void *frame_data;
struct sk_buff *skb = NULL;
+   int rv = -EINVAL;
 
if (!info->attrs[HWSIM_ATTR_ADDR_RECEIVER] ||
!info->attrs[HWSIM_ATTR_FRAME] ||
@@ -3034,25 +3035,6 @@ static int hwsim_cloned_frame_received_nl(struct sk_buff 
*skb_2,
frame_data_len = nla_len(info->attrs[HWSIM_ATTR_FRAME]);
frame_data = (void *)nla_data(info->attrs[HWSIM_ATTR_FRAME]);
 
-   /* Allocate new skb here */
-   skb = alloc_skb(frame_data_len, GFP_KERNEL);
-   if (skb == NULL) {
-   if (hwsim_ratelimit())
-   printk(KERN_DEBUG " hwsim rx-nl: skb alloc failed, len: 
%d\n",
-  frame_data_len);
-   goto out;
-   }
-
-   if (frame_data_len > IEEE80211_MAX_DATA_LEN) {
-   if (hwsim_ratelimit())
-   printk(KERN_DEBUG " hwsim rx-nl: data lenth error: %d  
max: %d\n",
-  frame_data_len, IEEE80211_MAX_DATA_LEN);
-   goto out;
-   }
-
-   /* Copy the data */
-   memcpy(skb_put(skb, frame_data_len), frame_data, frame_data_len);
-
data2 = get_hwsim_data_ref_from_addr(dst);
 
if (!data2) {
@@ -3081,9 +3063,30 @@ static int hwsim_cloned_frame_received_nl(struct sk_buff 
*skb_2,
if (((cnt++ & 0x3FF) == 0x3FF) && hwsim_ratelimit())
printk(KERN_DEBUG " hwsim rx-nl: radio %pM idle: %d or 
not started: %d cnt: %d\n",
   dst, data2->idle, !data2->started, cnt);
+   rv = -ENETDOWN;
goto out;
}
 
+   if (frame_data_len > IEEE80211_MAX_DATA_LEN) {
+   if (hwsim_ratelimit())
+   printk(KERN_DEBUG " hwsim rx-nl: data lenth error: %d  
max: %d\n",
+  frame_data_len, IEEE80211_MAX_DATA_LEN);
+   goto out;
+   }
+
+
+   /* Allocate new skb here */
+   skb = alloc_skb(frame_data_len, GFP_KERNEL);
+   if (skb == NULL) {
+   if (hwsim_ratelimit())
+   printk(KERN_DEBUG " hwsim rx-nl: skb alloc failed, len: 
%d\n",
+  frame_data_len);
+   goto out;
+   }
+
+   /* Copy the data */
+   memcpy(skb_put(skb, frame_data_len), frame_data, frame_data_len);
+
/* A frame is received from user space */
memset(_status, 0, sizeof(rx_status));
if (info->attrs[HWSIM_ATTR_FREQ]) {
-- 
2.4.11

[PATCH v2 3/4] mac80211-hwsim: add rate-limited debugging for rx-netlink

[greearb]

From: Ben Greear 

This makes it easier to understand why wmediumd (or similar)
is getting errors when sending frames to the kernel.

Signed-off-by: Ben Greear 
---

v2:  Add and use hwsim_ratelimit() instead of net_ratelimit.
 Squash two patches into this one.

 drivers/net/wireless/mac80211_hwsim.c | 55 +++
 1 file changed, 43 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index 635ad03..c259b99 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -137,6 +137,12 @@ static int regtest = HWSIM_REGTEST_DISABLED;
 module_param(regtest, int, 0444);
 MODULE_PARM_DESC(regtest, "The type of regulatory test we want to run");
 
+DEFINE_RATELIMIT_STATE(hwsim_ratelimit_state, 5 * HZ, 10);
+int hwsim_ratelimit(void)
+{
+   return __ratelimit(_ratelimit_state);
+}
+
 static const char *hwsim_alpha2s[] = {
"FI",
"AL",
@@ -1641,7 +1647,7 @@ static int mac80211_hwsim_config(struct ieee80211_hw *hw, 
u32 changed)
 
if (conf->chandef.chan)
wiphy_debug(hw->wiphy,
-   "%s (freq=%d(%d - %d)/%s idle=%d ps=%d smps=%s)\n",
+   "%s (chandef-chan freq=%d(%d - %d)/%s idle=%d ps=%d 
smps=%s)\n",
__func__,
conf->chandef.chan->center_freq,
conf->chandef.center_freq1,
@@ -1652,7 +1658,7 @@ static int mac80211_hwsim_config(struct ieee80211_hw *hw, 
u32 changed)
smps_modes[conf->smps_mode]);
else
wiphy_debug(hw->wiphy,
-   "%s (freq=0 idle=%d ps=%d smps=%s)\n",
+   "%s (no-chandef-chan freq=0 idle=%d ps=%d 
smps=%s)\n",
__func__,
!!(conf->flags & IEEE80211_CONF_IDLE),
!!(conf->flags & IEEE80211_CONF_PS),
@@ -3018,8 +3024,11 @@ static int hwsim_cloned_frame_received_nl(struct sk_buff 
*skb_2,
if (!info->attrs[HWSIM_ATTR_ADDR_RECEIVER] ||
!info->attrs[HWSIM_ATTR_FRAME] ||
!info->attrs[HWSIM_ATTR_RX_RATE] ||
-   !info->attrs[HWSIM_ATTR_SIGNAL])
+   !info->attrs[HWSIM_ATTR_SIGNAL]) {
+   if (hwsim_ratelimit())
+   printk(KERN_DEBUG " hwsim rx-nl: Missing required 
attribute\n");
goto out;
+   }
 
dst = (void *)nla_data(info->attrs[HWSIM_ATTR_ADDR_RECEIVER]);
frame_data_len = nla_len(info->attrs[HWSIM_ATTR_FRAME]);
@@ -3027,29 +3036,53 @@ static int hwsim_cloned_frame_received_nl(struct 
sk_buff *skb_2,
 
/* Allocate new skb here */
skb = alloc_skb(frame_data_len, GFP_KERNEL);
-   if (skb == NULL)
-   goto err;
+   if (skb == NULL) {
+   if (hwsim_ratelimit())
+   printk(KERN_DEBUG " hwsim rx-nl: skb alloc failed, len: 
%d\n",
+  frame_data_len);
+   goto out;
+   }
 
-   if (frame_data_len > IEEE80211_MAX_DATA_LEN)
-   goto err;
+   if (frame_data_len > IEEE80211_MAX_DATA_LEN) {
+   if (hwsim_ratelimit())
+   printk(KERN_DEBUG " hwsim rx-nl: data lenth error: %d  
max: %d\n",
+  frame_data_len, IEEE80211_MAX_DATA_LEN);
+   goto out;
+   }
 
/* Copy the data */
memcpy(skb_put(skb, frame_data_len), frame_data, frame_data_len);
 
data2 = get_hwsim_data_ref_from_addr(dst);
-   if (!data2)
+
+   if (!data2) {
+   if (hwsim_ratelimit())
+   printk(KERN_DEBUG " hwsim rx-nl: Cannot find radio 
%pM\n",
+  dst);
goto out;
+   }
 
if (hwsim_net_get_netgroup(genl_info_net(info)) != data2->netgroup)
goto out;
 
-   if (info->snd_portid != data2->wmediumd)
+   if (info->snd_portid != data2->wmediumd) {
+   if (hwsim_ratelimit())
+   printk(KERN_DEBUG " hwsim rx-nl: portid mismatch, 
snd_portid: %d  portid %d\n",
+  info->snd_portid, data2->wmediumd);
goto out;
+   }
 
/* check if radio is configured properly */
 
-   if (data2->idle || !data2->started)
+   if (data2->idle || !data2->started) {
+   static unsigned int cnt = 0;
+   /* This is fairly common, and usually not a bug.  So, print 
errors
+  rarely. */
+   if (((cnt++ & 0x3FF) == 0x3FF) && hwsim_ratelimit())
+   printk(KERN_DEBUG " hwsim rx-nl: radio %pM idle: %d or 
not started: %d cnt: %d\n",
+  dst, data2->idle, !data2->started, cnt);
goto out;
+   }
 
/* A 

Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO

[Ben Greear]

On 02/27/2017 05:23 PM, Andrew Zaborowski wrote:

Hi,

On 27 February 2017 at 18:10, Ben Greear  wrote:

On 02/27/2017 07:26 AM, Andrew Zaborowski wrote:

As it turns out it can be read from /sys, but I do need it so I can
know what to put in HWSIM_ATTR_ADDR_RECEIVER based on the destination
addr in the frame or if I want to forward the frame to all radios.  Or
is there another way to know that?



I'd actually prefer to *only* have the wiphy index, and I don't really
see a problem with moving the wiphy_idx from struct
cfg80211_registered_device to struct wiphy.



Ok, I'll try that.  get_wiphy_idx can stay in place, not sure if I
should just drop it.

By having *only* the wiphy index you don't mean dropping the radio
names altogether?  The don't seem useful but userspace may expect
them.



I find the name and addr more useful than an 'index', because if you
remove/add
a virtual phy, then the index will probably change, even if name and MAC


I don't think you can remove/add a phy without removing the hwsim
radio.  A hwsim radio is tied to some wiphy at all times.


You can specify the MAC address and name (ie, wiphy0) when creating a hwsim 
radio.
You cannot specify the index.  So, from a user-space perspective,
I think the name and MAC is more important than the index.

Anyway, I think you are correct to pay attention to the MAC address and use
that as the identifying key.

Thanks,
Ben


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

Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO

[Andrew Zaborowski]

Hi,

On 27 February 2017 at 18:10, Ben Greear  wrote:
> On 02/27/2017 07:26 AM, Andrew Zaborowski wrote:
>> As it turns out it can be read from /sys, but I do need it so I can
>> know what to put in HWSIM_ATTR_ADDR_RECEIVER based on the destination
>> addr in the frame or if I want to forward the frame to all radios.  Or
>> is there another way to know that?
>>
>>>
>>> I'd actually prefer to *only* have the wiphy index, and I don't really
>>> see a problem with moving the wiphy_idx from struct
>>> cfg80211_registered_device to struct wiphy.
>>
>>
>> Ok, I'll try that.  get_wiphy_idx can stay in place, not sure if I
>> should just drop it.
>>
>> By having *only* the wiphy index you don't mean dropping the radio
>> names altogether?  The don't seem useful but userspace may expect
>> them.
>
>
> I find the name and addr more useful than an 'index', because if you
> remove/add
> a virtual phy, then the index will probably change, even if name and MAC

I don't think you can remove/add a phy without removing the hwsim
radio.  A hwsim radio is tied to some wiphy at all times.

> addr may stay
> the same (and so probably be the same logical entitity).

They may stay the same or not, you can't assume either.  Sorry I don't
understand your point.

Best regards

[PATCH v2 4/4] brcmfmac: Handle status == BRCMF_E_STATUS_ABORT in cfg80211_escan_handler

[Hans de Goede]

If a scan gets aborted BRCMF_SCAN_STATUS_BUSY gets cleared in
cfg->scan_status and when we receive an abort event from the firmware
the BRCMF_SCAN_STATUS_BUSY check in the cfg80211_escan_handler will
trigger resulting in multiple errors getting logged.

Check for a status of BRCMF_E_STATUS_ABORT and in this case simply
cleanly exit the cfg80211_escan_handler. This also avoids a
BRCMF_E_STATUS_ABORT event arriving after a new scan has been started
causing the new scan to complete prematurely without any data.

Signed-off-by: Hans de Goede 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index c0b7f69..4c740b74 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3105,6 +3105,9 @@ brcmf_cfg80211_escan_handler(struct brcmf_if *ifp,
 
status = e->status;
 
+   if (status == BRCMF_E_STATUS_ABORT)
+   goto exit;
+
if (!test_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status)) {
brcmf_err("scan not ready, bsscfgidx=%d\n", ifp->bsscfgidx);
return -EPERM;
-- 
2.9.3

[PATCH] wireless: ipw2200: remove redundant check of rc < 0

[Colin King]

From: Colin Ian King 

The check for rc < 0 is always false so the check is redundant
and can be removed.

Detected with CoverityScan, CID#101143 ("Logically dead code")

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/intel/ipw2x00/ipw2200.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c 
b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 5ef3c5c..bbc579b 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -3539,9 +3539,6 @@ static int ipw_load(struct ipw_priv *priv)
fw_img = >data[le32_to_cpu(fw->boot_size) +
   le32_to_cpu(fw->ucode_size)];
 
-   if (rc < 0)
-   goto error;
-
if (!priv->rxq)
priv->rxq = ipw_rx_queue_alloc(priv);
else
-- 
2.10.2

Re: [PATCH 3/3] ath9k: ahb: Add OF support

[Rafał Miłecki]

On 27 February 2017 at 23:48, Alban  wrote:
> On Mon, 27 Feb 2017 22:13:21 +0100
> Rafał Miłecki  wrote:
>
>> Why you didn't cc linux-wireless?!?!
>
> I first wanted to be sure that the devdata part was generally
> acceptable, this patch was just included as an example of a user.
> But it sound like that part will have to move to nvmem first.
> I'll come back with a new patch once MTD support for nvmem is
> done.

OK, I just realized this was supposed to be RFC (for some reason this
patch didn't include RFC tag). At least this is was I assume to by
looking at the:
[RFC 0/3] drivers: Add an API to read device specific config data

Good luck!

Re: [PATCH 3/3] ath9k: ahb: Add OF support

[Alban]

On Mon, 27 Feb 2017 22:13:21 +0100
Rafał Miłecki  wrote:

> Why you didn't cc linux-wireless?!?!

I first wanted to be sure that the devdata part was generally
acceptable, this patch was just included as an example of a user.
But it sound like that part will have to move to nvmem first.
I'll come back with a new patch once MTD support for nvmem is
done.

> On 27 February 2017 at 21:28, Alban  wrote:
> > @@ -513,6 +515,43 @@ static void ath9k_eeprom_release(struct ath_softc *sc)
> > release_firmware(sc->sc_ah->eeprom_blob);
> >  }
> >
> > +#ifdef CONFIG_OF
> > +static int ath9k_init_of(struct ath_softc *sc)
> > +{
> > +   struct device_node *np = sc->dev->of_node;
> > +   struct ath_hw *ah = sc->sc_ah;
> > +   const void *macaddr;
> > +   struct clk *clk;
> > +   int ret = 0;
> > +
> > +   if (!np) {
> > +   dev_err(sc->dev, "no platform data or OF node\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   clk = clk_get(sc->dev, "ref");
> > +   if (!IS_ERR(clk)) {
> > +   ah->is_clk_25mhz = (clk_get_rate(clk) == 2500);
> > +   clk_put(clk);
> > +   }
> > +
> > +   ah->disable_2ghz = of_property_read_bool(np, "qca,disable-2ghz");
> > +   ah->disable_5ghz = of_property_read_bool(np, "qca,disable-5ghz");  
> 
> Please use ieee80211-freq-limit:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b330b25eaabda00d74e47566d9200907da381896
> 
> Most likely with the wiphy_read_of_freq_limits helper:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e691ac2f75b69bee743f0370d79454ba4429b17
> 
> Example:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f83ff69735651cc7a3d150466a5257ff829b62b

Thanks, I'll check this.

Alban


pgp1CpCcvmKQV.pgp
Description: OpenPGP digital signature

[PATCH v2 1/4] brcmfmac: Do not print the firmware version as an error

[Hans de Goede]

Using pr_err for things which are not errors is a bad idea. E.g. it
will cause the plymouth bootsplash screen to drop back to the text
console so that the user can see the error, which is not what we
normally want to happen.

Instead add a new brcmf_info macro and use that.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Fix brcm_err typo (should be brcmf_err) in CONFIG_BRCM_TRACING case
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h  | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 3e15d64..6d565f1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -161,7 +161,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
strsep(, "\n");
 
/* Print fw version info */
-   brcmf_err("Firmware version = %s\n", buf);
+   brcmf_info("Firmware version = %s\n", buf);
 
/* locate firmware version number for ethtool */
ptr = strrchr(buf, ' ') + 1;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
index 6687812..605f260 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
@@ -59,11 +59,14 @@
pr_err("%s: " fmt, __func__, ##__VA_ARGS__);\
} while (0)
 #endif
+#define brcmf_info(fmt, ...)   pr_info("%s: " fmt, __func__, ##__VA_ARGS__)
 #else
 __printf(2, 3)
 void __brcmf_err(const char *func, const char *fmt, ...);
 #define brcmf_err(fmt, ...) \
__brcmf_err(__func__, fmt, ##__VA_ARGS__)
+/* For tracing purposes treat info messages as errors */
+#define brcmf_info brcmf_err
 #endif
 
 #if defined(DEBUG) || defined(CONFIG_BRCM_TRACING)
-- 
2.9.3

[PATCH v2 2/4] brcmfmac: p2p and normal ap access are not always possible at the same time

[Hans de Goede]

The firmware responding with -EBUSY when trying to add an extra virtual-if
is a normal thing, do not print an error for this.

Signed-off-by: Hans de Goede 
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14 ++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c |  5 -
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 7ffc4ab..c54e8b4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -688,11 +688,17 @@ static struct wireless_dev 
*brcmf_cfg80211_add_iface(struct wiphy *wiphy,
return ERR_PTR(-EINVAL);
}
 
-   if (IS_ERR(wdev))
-   brcmf_err("add iface %s type %d failed: err=%d\n",
- name, type, (int)PTR_ERR(wdev));
-   else
+   if (IS_ERR(wdev)) {
+   err = PTR_ERR(wdev);
+   if (err != -EBUSY)
+   brcmf_err("add iface %s type %d failed: err=%d\n",
+ name, type, err);
+   else
+   brcmf_dbg(INFO, "add iface %s type %d failed: err=%d\n",
+ name, type, err);
+   } else {
brcmf_cfg80211_update_proto_addr_mode(wdev);
+   }
 
return wdev;
 }
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index de19c7c..b5df0a0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -2090,7 +2090,10 @@ static struct wireless_dev 
*brcmf_p2p_create_p2pdev(struct brcmf_p2p_info *p2p,
/* Initialize P2P Discovery in the firmware */
err = brcmf_fil_iovar_int_set(pri_ifp, "p2p_disc", 1);
if (err < 0) {
-   brcmf_err("set p2p_disc error\n");
+   if (err != -EBUSY)
+   brcmf_err("set p2p_disc error\n");
+   else
+   brcmf_dbg(INFO, "set p2p_disc error\n");
brcmf_fweh_p2pdev_setup(pri_ifp, false);
brcmf_cfg80211_arm_vif_event(p2p->cfg, NULL);
goto fail;
-- 
2.9.3

[PATCH v2 3/4] brcmfmac: Do not complain about country code "00"

[Hans de Goede]

The country code gets set to "00" by default at boot, ignore this
rather then logging an error about it.

Signed-off-by: Hans de Goede 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index c54e8b4..c0b7f69 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6705,6 +6705,10 @@ static void brcmf_cfg80211_reg_notifier(struct wiphy 
*wiphy,
s32 err;
int i;
 
+   /* The country code gets set to "00" by default at boot, ignore */
+   if (req->alpha2[0] == '0' && req->alpha2[1] == '0')
+   return;
+
/* ignore non-ISO3166 country codes */
for (i = 0; i < sizeof(req->alpha2); i++)
if (req->alpha2[i] < 'A' || req->alpha2[i] > 'Z') {
-- 
2.9.3

Re: [PATCH 3/3] ath9k: ahb: Add OF support

[Rafał Miłecki]

Why you didn't cc linux-wireless?!?!

On 27 February 2017 at 21:28, Alban  wrote:
> @@ -513,6 +515,43 @@ static void ath9k_eeprom_release(struct ath_softc *sc)
> release_firmware(sc->sc_ah->eeprom_blob);
>  }
>
> +#ifdef CONFIG_OF
> +static int ath9k_init_of(struct ath_softc *sc)
> +{
> +   struct device_node *np = sc->dev->of_node;
> +   struct ath_hw *ah = sc->sc_ah;
> +   const void *macaddr;
> +   struct clk *clk;
> +   int ret = 0;
> +
> +   if (!np) {
> +   dev_err(sc->dev, "no platform data or OF node\n");
> +   return -EINVAL;
> +   }
> +
> +   clk = clk_get(sc->dev, "ref");
> +   if (!IS_ERR(clk)) {
> +   ah->is_clk_25mhz = (clk_get_rate(clk) == 2500);
> +   clk_put(clk);
> +   }
> +
> +   ah->disable_2ghz = of_property_read_bool(np, "qca,disable-2ghz");
> +   ah->disable_5ghz = of_property_read_bool(np, "qca,disable-5ghz");

Please use ieee80211-freq-limit:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b330b25eaabda00d74e47566d9200907da381896

Most likely with the wiphy_read_of_freq_limits helper:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e691ac2f75b69bee743f0370d79454ba4429b17

Example:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f83ff69735651cc7a3d150466a5257ff829b62b

Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.

[Ben Greear]

On 02/23/2017 10:36 PM, Johannes Berg wrote:




+   msg_head = genlmsg_put(skb, 0, 0, _genl_family, 0,
+  HWSIM_CMD_NOTIFY);


I think you should use a more specific command name.


+   if (nla_put(skb, HWSIM_ATTR_ADDR_TRANSMITTER,
+   ETH_ALEN, data->addresses[1].addr))
+   goto nla_put_failure;


and at least also add a more specific identifier like the radio ID.


+   if (data->channel)
+   center_freq = data->channel->center_freq;
+
+   if (nla_put_u32(skb, HWSIM_ATTR_FREQ, center_freq))
+   goto nla_put_failure;


and have the full channel definition


Also the indentation in the documentation didn't match the convention
used there.


Looks like there are two conventions used (see HWSIM_CMD_TX_INFO_FRAME,
and HWSIM_CMD_NEW_RADIO).  I guess you want it indented like the NEW_RADIO
command?

Thanks,
Ben



johannes




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

Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.

[Ben Greear]

On 02/23/2017 10:36 PM, Johannes Berg wrote:




+   msg_head = genlmsg_put(skb, 0, 0, _genl_family, 0,
+  HWSIM_CMD_NOTIFY);


I think you should use a more specific command name.


+   if (nla_put(skb, HWSIM_ATTR_ADDR_TRANSMITTER,
+   ETH_ALEN, data->addresses[1].addr))
+   goto nla_put_failure;


and at least also add a more specific identifier like the radio ID.


+   if (data->channel)
+   center_freq = data->channel->center_freq;
+
+   if (nla_put_u32(skb, HWSIM_ATTR_FREQ, center_freq))
+   goto nla_put_failure;


and have the full channel definition


You want chandef.center_freq1,
 chandef.center_freq2,
 chandef.width?


Anything else?

Thanks,
Ben


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

Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

[Alexis Green]

Hi Johannes,

This is loosely based on RFC5148, specifically event-triggered message 
generation as described in section 5.2.
The frames are not duplicated, but, hopefully offset enough so they don't 
collide at the receiver (and, since, these are management frames, there is no 
retransmission and we may lose the information contained in them). If the two 
(or more) devices that reply are synchronized well enough, carrier sense will 
tell them that air is clear and messages will go out at the same time. It 
doesn't happen too often, but we found it noticeable enough in our testing.

Best regards,

Alexis Green

On 2/27/2017 5:30 AM, Johannes Berg wrote:
> On Fri, 2017-02-24 at 11:58 -0800, Alexis Green wrote:
>> From: Jesse Jones 
>>
>> When more than one station hears a broadcast request, it is possible
>> that multiple devices will reply at the same time, potentially
>> causing collision. This patch helps reduce this issue.
> 
> It's not clear to me what you mean by "collision"? Over the air the NAV
> should handle the avoidance thereof, so I don't really see what this
> does wrt. collisions?
> 
> Are these frames somehow duplicates? But I don't see any suppression if
> you've already put a frame on the "jittered" list then it will never be
> deleted from it again, so it doesn't suppress anything in that sense?
> 
> johannes
> 

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

[Jörg Krause]

Hi Arend,

On Fri, 2017-02-24 at 13:15 +0100, Arend Van Spriel wrote:
> On 24-2-2017 11:26, Jörg Krause wrote:
> > Hi Arend,
> > 
> > On Fri, 2017-02-24 at 10:58 +0100, Arend Van Spriel wrote:
> > > On 24-2-2017 10:43, Jörg Krause wrote:
> > > > Hi Arend,
> > > > 
> > > > On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
> > > > > 
> > > > > On 23-2-2017 21:21, Jörg Krause wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When
> > > > > > running
> > > > > > 'wpa_cli wps_pin any', the following messages are printed:
> > > > > > 
> > > > > > """
> > > > > > > wps_pin any 
> > > > > > 
> > > > > > [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set
> > > > > > error :
> > > > > > -30
> > > > > > [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set
> > > > > > Beacon IE
> > > > > > Failed
> > > > > > """
> > > > > > 
> > > > > > .. and nothing happens. The data sheet for the BCM43362
> > > > > > states
> > > > > > that
> > > > > > the
> > > > > > module supports WPS.
> > > > > 
> > > > > Hi Jörg,
> > > > > 
> > > > > We have never tested WPS with brcmfmac. Most of it is in
> > > > > firmware
> > > > > so
> > > > > it
> > > > > might work. We had some fixes related to setting management
> > > > > IE,
> > > > > but
> > > > > it
> > > > > should be in 4.9. I did not check it (yet).
> > > > 
> > > > As it turns out, WPS does not work if a network configuration
> > > > in
> > > > wpa_supplicant has the flag `mode=2` (access point mode) set:
> > > > 
> > > > """
> > > > ctrl_interface=/var/run/wpa_supplicant
> > > > update_config=1
> > > > 
> > > > network={
> > > > ssid="AP"
> > > > key_mgmt=NONE
> > > > mode=2
> > > > id_str="ap"
> > > > }
> > > > """
> > > > 
> > > > Setting mode=2 for a network and having ap_scan=1 (default)
> > > > means
> > > > if no
> > > > APs matching to the currently enabled networks are found, a new
> > > > network
> > > >  (IBSS or AP mode operation) may be initialized (if
> > > > configured).
> > > > 
> > > > So, WPS does not work if the interface is operating in AP mode.
> > > > I
> > > > wonder, if this is a desired behavior? At least, wpa_supplicant
> > > > does
> > > > not complain, but prints "WPS-PBC-ACTIVE", but no messages are
> > > > following, until "WPS-TIMEOUT".
> > > 
> > > So what do you expect exactly? Are you trying to connect with
> > > some
> > > other
> > > device to this AP interface?
> > 
> > Sorry, I got confused. The device operating in AP mode shall be
> > connected to some other AP as a station. Of course, WPS cannot be
> > used
> > to do so as long as the interface is operation in AP mode, as the
> > device should be the WPS enrollee and not the registrar. My bad!
> > Thanks
> > for pointing that out.
> > 
> > So, to use WPS for connecting the device to another AP I have to
> > bring
> > the interface into an non-AP mode first.
> > 
> > So, I can confirm that using WPS works when the interface is
> > unconfigured. However, if the in the interface is in AP mode and
> > WPS is
> > started the error messages pop up.
> 
> You mean the message you emailed earlier as below?
> 
> [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set
> error :
> -30
> [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
> Failed
> 
> You get firmware error -30 which is BCME_NOTFOUND. This can happen in
> firmware upon deleting an IE. However, it is hard to say what is
> exactly
> happening without knowing the message content that goes to firmware.
> You
> can enable firmware console logging to see if you get any message
> regarding this, eg. "wlc_del_ie: IE not in list". Do insmod with
> debug=0x0010.
> 
>   if (total_ie_buf_len) {
>   err  = brcmf_fil_bsscfg_data_set(ifp, "vndr_ie",
> iovar_ie_buf,
>    total_ie_buf_len);
>   if (err)
>   brcmf_err("vndr ie set error : %d\n", err);
>   }
> 
> If this happens in the .start_ap() callback the error is ignored so
> it
> should not affect AP operation although beacon may not be setup
> properly.

I loaded the brcmfmac driver with the debug setting and started wpa_cli
wps_pbc while the device operates in AP mode.

This is the log after running the command:

"""
kern.err kernel: [   73.277473] brcmfmac: brcmf_vif_set_mgmt_ie: vndr
ie set error : -30
kern.err kernel: [   73.284647] brcmfmac: brcmf_config_ap_mgmt_ie: Set
Beacon IE Failed
daemon.err wpa_supplicant[176]: Failed to set beacon parameters
daemon.notice wpa_supplicant[176]: wlan0: WPS-PBC-ACTIVE 
kern.debug kernel: [   73.298749] brcmfmac: CONSOLE: 
user.notice ACTION_WPA: WPS-PBC-ACTIVE
daemon.notice wpa_supplicant[176]: wlan0: WPS-TIMEOUT 
daemon.err wpa_supplicant[176]: Failed to set beacon parameters
kern.err kernel: [  193.319897] brcmfmac: brcmf_vif_set_mgmt_ie: vndr
ie set error : -30
kern.err kernel: [  193.333464] brcmfmac: brcmf_config_ap_mgmt_ie: 

Re: [PATCH 4.12] brcmfmac: move brcmf_txcomplete function to fwsignal.c

[kbuild test robot]

Hi Rafał,

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on next-20170227]
[cannot apply to v4.10]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/brcmfmac-move-brcmf_txcomplete-function-to-fwsignal-c/20170228-004934
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: In function 
'brcmf_sdio_txpkt':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2268:3: error: 
>> implicit declaration of function 'brcmf_fws_txcomplete' 
>> [-Werror=implicit-function-declaration]
  brcmf_fws_txcomplete(bus->sdiodev->dev, pkt_next, ret == 0);
  ^~~~
   cc1: some warnings being treated as errors
--
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function 
'brcmf_usb_tx_complete':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:485:2: error: 
>> implicit declaration of function 'brcmf_fws_txcomplete' 
>> [-Werror=implicit-function-declaration]
 brcmf_fws_txcomplete(devinfo->dev, req->skb, urb->status == 0);
 ^~~~
   cc1: some warnings being treated as errors

vim +/brcmf_fws_txcomplete +2268 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c

  2262  done:
  2263  brcmf_sdio_txpkt_postp(bus, pktq);
  2264  if (ret == 0)
  2265  bus->tx_seq = (bus->tx_seq + pktq->qlen) % 
SDPCM_SEQ_WRAP;
  2266  skb_queue_walk_safe(pktq, pkt_next, tmp) {
  2267  __skb_unlink(pkt_next, pktq);
> 2268  brcmf_fws_txcomplete(bus->sdiodev->dev, pkt_next, ret 
> == 0);
  2269  }
  2270  return ret;
  2271  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] ath9k: don't trigger spectral scan when not enabled

[Zefir Kurtisi]

Doing so enables the FFT generation without prior
configuration, leading to an IRQ storm caused by
invalid (or at least unwanted) PHY errors.

Signed-off-by: Zefir Kurtisi 
---
 drivers/net/wireless/ath/ath9k/common-spectral.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c 
b/drivers/net/wireless/ath/ath9k/common-spectral.c
index 58f1ed1..51b618c 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -739,6 +739,9 @@ void ath9k_cmn_spectral_scan_trigger(struct ath_common 
*common,
return;
}
 
+   if (!spec_priv->spec_config.enabled)
+   return;
+
ath_ps_ops(common)->wakeup(common);
rxfilter = ath9k_hw_getrxfilter(ah);
ath9k_hw_setrxfilter(ah, rxfilter |
-- 
2.7.4

Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO

[Ben Greear]

On 02/27/2017 07:26 AM, Andrew Zaborowski wrote:

Hi,

On 27 February 2017 at 14:27, Johannes Berg  wrote:

Additionally I tried to add a HWSIM_ATTR_WIPHY to report the wiphy
index directly without users going through wiphy name to index
mapping, but get_wiphy_idx() is internal to cfg80211.  The index is
exposed to userspace and is more useful than the name so I wonder if
this function should be exported from cfg80211.


Do you really need the address?


As it turns out it can be read from /sys, but I do need it so I can
know what to put in HWSIM_ATTR_ADDR_RECEIVER based on the destination
addr in the frame or if I want to forward the frame to all radios.  Or
is there another way to know that?



I'd actually prefer to *only* have the wiphy index, and I don't really
see a problem with moving the wiphy_idx from struct
cfg80211_registered_device to struct wiphy.


Ok, I'll try that.  get_wiphy_idx can stay in place, not sure if I
should just drop it.

By having *only* the wiphy index you don't mean dropping the radio
names altogether?  The don't seem useful but userspace may expect
them.


I find the name and addr more useful than an 'index', because if you remove/add
a virtual phy, then the index will probably change, even if name and MAC addr 
may stay
the same (and so probably be the same logical entitity).

Since phys can be renamed, you cannot assume that the phy will be called
phyX where X is the device-id.

Thanks,
Ben

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

Re: BUG_ON in sg code

[Johannes Berg]

On Mon, 2017-02-27 at 15:10 +, Ard Biesheuvel wrote:
> 
> > because you put odata/idata on the stack. What's going on there? I
> > thought we knew we can't do that? Did I miss something?
> > 
> 
> It was I who missed something, obviously.

Ok. I thought maybe I missed a plan to actually make it allowed or
something :)

Thanks!

johannes

Re: [PATCH 1/2] mac80211_hwsim: Make sure NEW_RADIO contains final name

[Johannes Berg]

> > [HWSIM_ATTR_RADIO_NAME] = { .type = NLA_STRING },
> > 
> > enforces that a NUL byte *must* be present when userspace gives us
> > the
> > information, so we're save - just asymmetric.
> 
> It seems that would be NLA_NUL_STRING, whlie for NLA_STRING it's
> optional, 

Oops. I indeed misread the code there.

> I know because I didn't add the NUL in my userspace and
> things still worked.

:)
Then you probably had some 0 padding or so.

> We can copy the received nla_data into a buffer
> and add the 0-byte there to support this as an option.

I'll do that.

johannes

Re: [PATCH 1/3] cfg80211: Make pre-CAC results valid only for ETSI domain

[Johannes Berg]

On Mon, 2017-02-20 at 16:09 +0530, Vasanthakumar Thiagarajan wrote:
> DFS requirement for ETSI domain (section 4.7.1.4 in
> ETSI EN 301 893 V1.8.1) is the only one which explicitly
> states that once DFS channel is marked as available afer
> the CAC, this channel will remain in available state even
> moving to a different operating channel. But the same is
> not explicitly stated in FCC DFS requirement. Also, Pre-CAC
> requriements are not explicitly mentioned in FCC requirement.
> Current implementation in keeping DFS channel in available
> state is same as described in ETSI domain.
> 
> For ETSI DFS domain, this patch gives a grace period of 2 seconds

You mean non-ETSI, right?

Just making sure I understood correctly - no need to resend, I can fix
that.

johannes

Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO

[Andrew Zaborowski]

Hi,

On 27 February 2017 at 14:27, Johannes Berg  wrote:
>> Additionally I tried to add a HWSIM_ATTR_WIPHY to report the wiphy
>> index directly without users going through wiphy name to index
>> mapping, but get_wiphy_idx() is internal to cfg80211.  The index is
>> exposed to userspace and is more useful than the name so I wonder if
>> this function should be exported from cfg80211.
>
> Do you really need the address?

As it turns out it can be read from /sys, but I do need it so I can
know what to put in HWSIM_ATTR_ADDR_RECEIVER based on the destination
addr in the frame or if I want to forward the frame to all radios.  Or
is there another way to know that?

>
> I'd actually prefer to *only* have the wiphy index, and I don't really
> see a problem with moving the wiphy_idx from struct
> cfg80211_registered_device to struct wiphy.

Ok, I'll try that.  get_wiphy_idx can stay in place, not sure if I
should just drop it.

By having *only* the wiphy index you don't mean dropping the radio
names altogether?  The don't seem useful but userspace may expect
them.

Best regards

BUG_ON in sg code

[Johannes Berg]

Hi Ard,

Apologies for the non-follow-up - couldn't find the original patch.

Your patch "crypto: ccm - switch to separate cbcmac driver" causes a
BUG_ON when virtual stacks are used, in crypto_ccm_auth() is called,
because you put odata/idata on the stack. What's going on there? I
thought we knew we can't do that? Did I miss something?

johannes

Re: [PATCH 160/306] mac80211-hwsim: add rate-limited debugging for rx-netlink

[Johannes Berg]

On Fri, 2017-02-24 at 07:27 -0800, Ben Greear wrote:
> 
> On 02/23/2017 10:39 PM, Johannes Berg wrote:
> > 
> > > + !info->attrs[HWSIM_ATTR_SIGNAL]) {
> > > + if (net_ratelimit())
> > > + printk(KERN_DEBUG " hwsim rx-nl: Missing
> > > required attribute\n");
> > 
> > I'm not convinced net_ratelimit() is a good idea, that's a global
> > rate limiter.
> 
> Is there a better rate-limiter w/out hand-crafting something?

You can use include/linux/ratelimit.h to do that?

johannes

Re: [PATCH 1/2] mac80211_hwsim: Make sure NEW_RADIO contains final name

[Andrew Zaborowski]

Hi,

On 27 February 2017 at 14:24, Johannes Berg  wrote:
> On Fri, 2017-02-24 at 01:08 +0100, Andrew Zaborowski wrote:
>> Also related to this I find that the HWSIM_ATTR_RADIO_NAME attributes
>> emitted contain the name string and are exactly of the right length
>> while the HWSIM_ATTR_RADIO_NAME attributes received by the kernel are
>> assumed to be NUL-terminated.
>
> I'll agree this is a bit strange - I guess it's too late to fix now
> though since userspace might assume "length/data" is the string, rather
> than "0-terminated" (especially if there's something like python
> userspace where strings can trivially contain NUL bytes).
>
> nla_put_string() would have added the NUL byte.
>
>> Is there a guarantee that a 0-byte
>> follows an attribute, or should this be changed for consistency?
>
> [HWSIM_ATTR_RADIO_NAME] = { .type = NLA_STRING },
>
> enforces that a NUL byte *must* be present when userspace gives us the
> information, so we're save - just asymmetric.

It seems that would be NLA_NUL_STRING, whlie for NLA_STRING it's
optional, I know because I didn't add the NUL in my userspace and
things still worked.  We can copy the received nla_data into a buffer
and add the 0-byte there to support this as an option.  I don't have a
problem with the asymmetric usage though.

>
> Anyway, patch applied.

Thanks
Best regards

Re: [PATCH] mac80211: Print text for disassociation reason

[Johannes Berg]

On Wed, 2017-02-15 at 14:21 +0100, Arkadiusz Miśkiewicz wrote:
> When disassociation happens only numeric reason is printed
> in ieee80211_rx_mgmt_disassoc(). Add text variant, too.

Applied, thanks.

johannes

Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

[Johannes Berg]

On Fri, 2017-02-24 at 11:58 -0800, Alexis Green wrote:
> From: Jesse Jones 
> 
> Changes since v1: Only flush tx queue if interface is mesh mode.
>   This prevents kernel panics due to uninitialized spin_lock.
> 
> When more than one station hears a broadcast request, it is possible
> that multiple devices will reply at the same time, potentially
> causing collision. This patch helps reduce this issue.

It's not clear to me what you mean by "collision"? Over the air the NAV
should handle the avoidance thereof, so I don't really see what this
does wrt. collisions?

Are these frames somehow duplicates? But I don't see any suppression if
you've already put a frame on the "jittered" list then it will never be
deleted from it again, so it doesn't suppress anything in that sense?

johannes

Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO

[Johannes Berg]

> Additionally I tried to add a HWSIM_ATTR_WIPHY to report the wiphy
> index directly without users going through wiphy name to index
> mapping, but get_wiphy_idx() is internal to cfg80211.  The index is
> exposed to userspace and is more useful than the name so I wonder if
> this function should be exported from cfg80211.

Do you really need the address?

I'd actually prefer to *only* have the wiphy index, and I don't really
see a problem with moving the wiphy_idx from struct
cfg80211_registered_device to struct wiphy.

johannes

ANNOUNCE: Netdev 2.1 update Feb 27

[Jamal Hadi Salim]

A few announcements:

1) The CFP is now officially closed. Thanks to everyone who submitted.

2) We are extending the early registration to March 5.

Register early so we can plan better (and so you can save some $$).
https://onlineregistrations.ca/netdev21/

- hotel (If you can get the hotel cheaper online than conference
rates please send us email, dont book ):
https://www.netdevconf.org/2.1/hotel.html

3) Tech committee would like to make two announcements:

First, a talk by Hajime Tazaki titled "Playing BBR with a userspace 
network stack"


-
Linux kernel library (LKL) is aimed to run Linux kernel code upon
different environment such as Linux userspace, Windows userspace,
hypervisors, etc.  With the userspace deployments, an application can
benefit new additional features such as TCP extensions without
involving the update of host kernel.

This characteristic of network stack personality is useful since we
don't have to instantiate a virtual machine instance to use a new
feature of network stack (e.g., a TCP extension).  Instead, we just
need a single (userspace) process to introduce new features.

One concern of userspace network stack in general, and addressed by
David Miller in the last netdev conference (in Tokyo), is the achieved
timing accuracy in userspace which the important network feature such
as packet pacing and transport protocols requires.

In this talk, we're going to present our performance studies on this
timing accuracy concern of a userspace network stack. We present the
result of netperf benchmarks with a couple of congestion control
algorithm of TCP, BBR and cubic with the LKL-ed netperf and ordinal
netperf with Linux kernel.
We're trying to reveal that what is the obstacle of LKL (userspace
network stack) and what can be fixed to reach the performance goal of
LKL (i.e., x1 performance of the original kernel network stack).

Second, our first workshop announcement on "IoT related MAC layers, header
compression and routing protocols" chaired by Stefan Schmidt.
---
This workshop aims to identify generic requirements for the networking
subsystem for IoT and starting the process of addressing the gaps
found. The workshop will encompass related MAC layers, networking
protocols, adaptation layers, header compression, routing protocols
and application layers.

As a starting point we will look at existing subsystems (Bluetooth,
802.15.4, 6LoWPAN, etc) and discuss a way forward to  address the gaps
posed. An overview of MAC layers and open IoT related specifications
will help to identify things we should probably support in the future
(LPWAN, SCHC, RPL, Thread, etc). Note: We emphasize only on open
protocols and specifications as well as IPv6 instead of company grown
networking layers.
Additional user-space interfaces might be needed to cater for the
requirements of application layer stacks (ZigBee, IoTivity, etc.).
What kind of interfaces besides the normal socket API and existing
netlink interfaces do they need?
(header compression configuration, DTLS support in AF_KTLS, etc.)

A primary goal of this workshop is initially to target Linux as a
gateway or border router at the edge of IoT networks, be it industrial
or home automation.

A future scope, starting with discussions at the workshop, could be for
Linux to replace RTOSes on leaf nodes which operate on very constrained
hardware and power limits; such an effort would need a serious amount
of work towards tinyfication in all parts of the kernel.

We expect the workshop to ignite efforts on these topics and followup
discussions on mailing lists and future netdevs to produce results that
make it a possibility.


cheers,
jamal

Re: [PATCH 1/2] mac80211_hwsim: Make sure NEW_RADIO contains final name

[Johannes Berg]

On Fri, 2017-02-24 at 01:08 +0100, Andrew Zaborowski wrote:
> On 23 February 2017 at 13:02, Andrew Zaborowski
>  wrote:
> > ieee80211_alloc_hw_nm will validate the requested name (if any)
> > before
> > creating the new device and may use a name different from the one
> > requested rather than fail.  Make sure the HWSIM_CMD_NEW_RADIO
> > event/response generated has the final name or userspace will
> > receive
> > the wrong name.  Note that mac80211_hwsim_new_radio may now modify
> > params.
> 
> Also related to this I find that the HWSIM_ATTR_RADIO_NAME attributes
> emitted contain the name string and are exactly of the right length
> while the HWSIM_ATTR_RADIO_NAME attributes received by the kernel are
> assumed to be NUL-terminated.  

I'll agree this is a bit strange - I guess it's too late to fix now
though since userspace might assume "length/data" is the string, rather
than "0-terminated" (especially if there's something like python
userspace where strings can trivially contain NUL bytes).

nla_put_string() would have added the NUL byte.

> Is there a guarantee that a 0-byte
> follows an attribute, or should this be changed for consistency?

[HWSIM_ATTR_RADIO_NAME] = { .type = NLA_STRING },

enforces that a NUL byte *must* be present when userspace gives us the
information, so we're save - just asymmetric.

Anyway, patch applied.

johannes

Re: [PATCH v2] mac80211: allow overriding station bandwidth.

[Johannes Berg]

On Wed, 2017-02-15 at 17:16 -0800, gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> This allows one to disable VHT160 (or 80+80) on hardware
> that might otherwise try to use it.

I just decided against applying this now because of the changing VHT
extended NSS BW stuff. This would in that case not actually override
the 160/80+80 capability, which would probably actually be the right
thing given how this works (mask & shift stuff), but without also
allowing to override the *new* things you'd not actually gain the
ability to get rid of 160/80+80... so overall I think right now that's
just confusing things even more.

johannes

[PATCH 4.12] brcmfmac: move brcmf_txcomplete function to fwsignal.c

[Rafał Miłecki]

From: Rafał Miłecki 

This function is called by USB and SDIO only, both using BCDC & FW
Signalling. Move it out of core.c to make this file more generic and
allow making fwsignal optional in the future.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h |  3 ---
 .../net/wireless/broadcom/brcm80211/brcmfmac/core.c| 18 --
 .../wireless/broadcom/brcm80211/brcmfmac/fwsignal.c| 18 ++
 .../wireless/broadcom/brcm80211/brcmfmac/fwsignal.h|  5 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/sdio.c|  2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c |  2 +-
 6 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
index 76693df34742..059e40fdc3d5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
@@ -232,9 +232,6 @@ void brcmf_dev_reset(struct device *dev);
 /* Indication from bus module to change flow-control state */
 void brcmf_txflowblock(struct device *dev, bool state);
 
-/* Notify the bus has transferred the tx packet to firmware */
-void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
-
 /* Configure the "global" bus state used by upper layers */
 void brcmf_bus_change_state(struct brcmf_bus *bus, enum brcmf_bus_state state);
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 59831dc446d6..47cfb82dbfeb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -383,24 +383,6 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff 
*txp, bool success)
brcmu_pkt_buf_free_skb(txp);
 }
 
-void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success)
-{
-   struct brcmf_bus *bus_if = dev_get_drvdata(dev);
-   struct brcmf_pub *drvr = bus_if->drvr;
-   struct brcmf_if *ifp;
-
-   /* await txstatus signal for firmware if active */
-   if (brcmf_fws_fc_active(drvr->fws)) {
-   if (!success)
-   brcmf_fws_bustxfail(drvr->fws, txp);
-   } else {
-   if (brcmf_proto_hdrpull(drvr, false, txp, ))
-   brcmu_pkt_buf_free_skb(txp);
-   else
-   brcmf_txfinalize(ifp, txp, success);
-   }
-}
-
 static void brcmf_ethtool_get_drvinfo(struct net_device *ndev,
struct ethtool_drvinfo *info)
 {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
index 5f1a5929cb30..07f0b3cfd59c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
@@ -2445,6 +2445,24 @@ bool brcmf_fws_fc_active(struct brcmf_fws_info *fws)
return fws->fcmode != BRCMF_FWS_FCMODE_NONE;
 }
 
+void brcmf_fws_txcomplete(struct device *dev, struct sk_buff *txp, bool 
success)
+{
+   struct brcmf_bus *bus_if = dev_get_drvdata(dev);
+   struct brcmf_pub *drvr = bus_if->drvr;
+   struct brcmf_if *ifp;
+
+   /* await txstatus signal for firmware if active */
+   if (brcmf_fws_fc_active(drvr->fws)) {
+   if (!success)
+   brcmf_fws_bustxfail(drvr->fws, txp);
+   } else {
+   if (brcmf_proto_hdrpull(drvr, false, txp, ))
+   brcmu_pkt_buf_free_skb(txp);
+   else
+   brcmf_txfinalize(ifp, txp, success);
+   }
+}
+
 void brcmf_fws_bustxfail(struct brcmf_fws_info *fws, struct sk_buff *skb)
 {
u32 hslot;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
index bb4591c4a14a..d534164785de 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
@@ -32,6 +32,11 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct 
sk_buff *skb);
 void brcmf_fws_reset_interface(struct brcmf_if *ifp);
 void brcmf_fws_add_interface(struct brcmf_if *ifp);
 void brcmf_fws_del_interface(struct brcmf_if *ifp);
+
+/* Notify the bus has transferred the tx packet to firmware */
+void brcmf_fws_txcomplete(struct device *dev, struct sk_buff *txp,
+ bool success);
+
 void brcmf_fws_bustxfail(struct brcmf_fws_info *fws, struct sk_buff *skb);
 void brcmf_fws_bus_blocked(struct brcmf_pub *drvr, bool flow_blocked);
 void brcmf_fws_rxreorder(struct brcmf_if *ifp, struct sk_buff *skb);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 

[PATCH 4.12] brcmfmac: get rid of brcmf_txflowblock helper function

[Rafał Miłecki]

From: Rafał Miłecki 

This helper function is pretty trivial and we can easily do without it.
What's important though it's one of FWS (Firmware Signalling)
dependencies in core.c. The plan is to make FWS required by BCDC only so
we don't have to use/compile it when using msgbuf.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 10 --
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h |  4 
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c |  7 +--
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c  |  7 +--
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 2f2f3a5ad86a..59831dc446d6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -283,16 +283,6 @@ void brcmf_txflowblock_if(struct brcmf_if *ifp,
spin_unlock_irqrestore(>netif_stop_lock, flags);
 }
 
-void brcmf_txflowblock(struct device *dev, bool state)
-{
-   struct brcmf_bus *bus_if = dev_get_drvdata(dev);
-   struct brcmf_pub *drvr = bus_if->drvr;
-
-   brcmf_dbg(TRACE, "Enter\n");
-
-   brcmf_fws_bus_blocked(drvr, state);
-}
-
 void brcmf_netif_rx(struct brcmf_if *ifp, struct sk_buff *skb)
 {
if (skb->pkt_type == PACKET_MULTICAST)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
index 96df66073b2a..bb4591c4a14a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
@@ -18,6 +18,10 @@
 #ifndef FWSIGNAL_H_
 #define FWSIGNAL_H_
 
+struct brcmf_fws_info;
+struct brcmf_if;
+struct brcmf_pub;
+
 int brcmf_fws_init(struct brcmf_pub *drvr);
 void brcmf_fws_deinit(struct brcmf_pub *drvr);
 bool brcmf_fws_queue_skbs(struct brcmf_fws_info *fws);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index c5744b45ec8f..10522edc9750 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -44,6 +44,7 @@
 #include "firmware.h"
 #include "core.h"
 #include "common.h"
+#include "fwsignal.h"
 
 #define DCMD_RESP_TIMEOUT  msecs_to_jiffies(2500)
 #define CTL_DONE_TIMEOUT   msecs_to_jiffies(2500)
@@ -2272,6 +2273,7 @@ static int brcmf_sdio_txpkt(struct brcmf_sdio *bus, 
struct sk_buff_head *pktq,
 
 static uint brcmf_sdio_sendfromq(struct brcmf_sdio *bus, uint maxframes)
 {
+   struct brcmf_pub *pub = bus->sdiodev->bus_if->drvr;
struct sk_buff *pkt;
struct sk_buff_head pktq;
u32 intstatus = 0;
@@ -2328,7 +2330,7 @@ static uint brcmf_sdio_sendfromq(struct brcmf_sdio *bus, 
uint maxframes)
if ((bus->sdiodev->state == BRCMF_SDIOD_DATA) &&
bus->txoff && (pktq_len(>txq) < TXLOW)) {
bus->txoff = false;
-   brcmf_txflowblock(bus->sdiodev->dev, false);
+   brcmf_fws_bus_blocked(pub, false);
}
 
return cnt;
@@ -2723,6 +2725,7 @@ static int brcmf_sdio_bus_txdata(struct device *dev, 
struct sk_buff *pkt)
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
struct brcmf_sdio *bus = sdiodev->bus;
+   struct brcmf_pub *pub = bus->sdiodev->bus_if->drvr;
 
brcmf_dbg(TRACE, "Enter: pkt: data %p len %d\n", pkt->data, pkt->len);
if (sdiodev->state != BRCMF_SDIOD_DATA)
@@ -2753,7 +2756,7 @@ static int brcmf_sdio_bus_txdata(struct device *dev, 
struct sk_buff *pkt)
 
if (pktq_len(>txq) >= TXHI) {
bus->txoff = true;
-   brcmf_txflowblock(dev, true);
+   brcmf_fws_bus_blocked(pub, true);
}
spin_unlock_bh(>txq_lock);
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index d93ebbdc7737..c527aa8a5f8f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -26,6 +26,7 @@
 #include "bus.h"
 #include "debug.h"
 #include "firmware.h"
+#include "fwsignal.h"
 #include "usb.h"
 #include "core.h"
 #include "common.h"
@@ -476,6 +477,7 @@ static void brcmf_usb_tx_complete(struct urb *urb)
 {
struct brcmf_usbreq *req = (struct brcmf_usbreq *)urb->context;
struct brcmf_usbdev_info *devinfo = req->devinfo;
+   struct brcmf_pub *pub = devinfo->bus_pub.bus->drvr;
unsigned long flags;
 
brcmf_dbg(USB, "Enter, urb->status=%d, skb=%p\n", urb->status,
@@ -488,7 +490,7 @@ static void brcmf_usb_tx_complete(struct urb *urb)
spin_lock_irqsave(>tx_flowblock_lock, 

[PATCH 0/4] brcmfmac: Remove a bunch of false positive error logs

[Hans de Goede]

Hi All,

Here is a small series to stop brcmfmac from spamming dmesg with errors
which are not really errors at all.

Note the 4th patch actually contains a small behavior change rather then
just changing logging, so it needs a bit of extra review attention.

Regards,

Hans

[PATCH 4/4] brcmfmac: Handle status == BRCMF_E_STATUS_ABORT in cfg80211_escan_handler

[Hans de Goede]

If a scan gets aborted BRCMF_SCAN_STATUS_BUSY gets cleared in
cfg->scan_status and when we receive an abort event from the firmware
the BRCMF_SCAN_STATUS_BUSY check in the cfg80211_escan_handler will
trigger resulting in multiple errors getting logged.

Check for a status of BRCMF_E_STATUS_ABORT and in this case simply
cleanly exit the cfg80211_escan_handler. This also avoids a
BRCMF_E_STATUS_ABORT event arriving after a new scan has been started
causing the new scan to complete prematurely without any data.

Signed-off-by: Hans de Goede 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index c0b7f69..4c740b74 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3105,6 +3105,9 @@ brcmf_cfg80211_escan_handler(struct brcmf_if *ifp,
 
status = e->status;
 
+   if (status == BRCMF_E_STATUS_ABORT)
+   goto exit;
+
if (!test_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status)) {
brcmf_err("scan not ready, bsscfgidx=%d\n", ifp->bsscfgidx);
return -EPERM;
-- 
2.9.3

[PATCH V2 2/3] cfg80211: Disallow moving out of operating DFS channel in non-ETSI

[Vasanthakumar Thiagarajan]

For non-ETSI regulatory domain, CAC result on DFS channel
may not be valid once moving out of that channel (as done
during remain-on-channel, scannning and off-channel tx).
Running CAC on an operating DFS channel after every off-channel
operation will only add complexity and disturb the current
link. Better do not allow any off-channel switch from a DFS
operating channel in non-ETSI domain.

Signed-off-by: Vasanthakumar Thiagarajan 
---
 net/wireless/nl80211.c | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d516527..b15903b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6556,6 +6556,19 @@ static int nl80211_parse_random_mac(struct nlattr 
**attrs,
return 0;
 }
 
+static bool cfg80211_off_channel_oper_allowed(struct wireless_dev *wdev)
+{
+   ASSERT_WDEV_LOCK(wdev);
+
+   if (!cfg80211_beaconing_iface_active(wdev))
+   return true;
+
+   if (!(wdev->chandef.chan->flags & IEEE80211_CHAN_RADAR))
+   return true;
+
+   return regulatory_pre_cac_allowed(wdev->wiphy);
+}
+
 static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
 {
struct cfg80211_registered_device *rdev = info->user_ptr[0];
@@ -6681,6 +6694,25 @@ static int nl80211_trigger_scan(struct sk_buff *skb, 
struct genl_info *info)
 
request->n_channels = i;
 
+   wdev_lock(wdev);
+   if (!cfg80211_off_channel_oper_allowed(wdev)) {
+   struct ieee80211_channel *chan;
+
+   if (request->n_channels != 1) {
+   wdev_unlock(wdev);
+   err = -EBUSY;
+   goto out_free;
+   }
+
+   chan = request->channels[0];
+   if (chan->center_freq != wdev->chandef.chan->center_freq) {
+   wdev_unlock(wdev);
+   err = -EBUSY;
+   goto out_free;
+   }
+   }
+   wdev_unlock(wdev);
+
i = 0;
if (n_ssids) {
nla_for_each_nested(attr, info->attrs[NL80211_ATTR_SCAN_SSIDS], 
tmp) {
@@ -9103,6 +9135,7 @@ static int nl80211_remain_on_channel(struct sk_buff *skb,
struct cfg80211_registered_device *rdev = info->user_ptr[0];
struct wireless_dev *wdev = info->user_ptr[1];
struct cfg80211_chan_def chandef;
+   const struct cfg80211_chan_def *compat_chandef;
struct sk_buff *msg;
void *hdr;
u64 cookie;
@@ -9131,6 +9164,18 @@ static int nl80211_remain_on_channel(struct sk_buff *skb,
if (err)
return err;
 
+   wdev_lock(wdev);
+   if (!cfg80211_off_channel_oper_allowed(wdev) &&
+   !cfg80211_chandef_identical(>chandef, )) {
+   compat_chandef = cfg80211_chandef_compatible(>chandef,
+);
+   if (compat_chandef != ) {
+   wdev_unlock(wdev);
+   return -EBUSY;
+   }
+   }
+   wdev_unlock(wdev);
+
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
if (!msg)
return -ENOMEM;
@@ -9306,6 +9351,13 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct 
genl_info *info)
if (!chandef.chan && params.offchan)
return -EINVAL;
 
+   wdev_lock(wdev);
+   if (params.offchan && !cfg80211_off_channel_oper_allowed(wdev)) {
+   wdev_unlock(wdev);
+   return -EBUSY;
+   }
+   wdev_unlock(wdev);
+
params.buf = nla_data(info->attrs[NL80211_ATTR_FRAME]);
params.len = nla_len(info->attrs[NL80211_ATTR_FRAME]);
 
-- 
1.9.1

[PATCH V2 3/3] cfg80211: Share Channel DFS state across wiphys of same DFS domain

[Vasanthakumar Thiagarajan]

Sharing DFS channel state across multiple wiphys (radios) could
be useful with multiple radios on the system. When one radio
completes CAC and markes the channel available another radio
can use this information and start beaconing without really doing
CAC.

Whenever there is a state change in dfs channel associated to
a particular wiphy the the same state change is propagated to
other wiphys having the same DFS reg domain configuration.
Also when a new wiphy is created the dfs channel state of
other existing wiphys of same DFS domain is copied.

Signed-off-by: Vasanthakumar Thiagarajan 
---

V2:

- Add a sanity check on the chandef in regulatory_propagate_dfs_state()
  to make sure the channel is valid before proceeding with dfs state
  propagation for the channel.

 net/wireless/chan.c |  30 ++---
 net/wireless/core.c |  37 
 net/wireless/core.h |   6 +++
 net/wireless/mlme.c |  10 +
 net/wireless/reg.c  | 120 
 net/wireless/reg.h  |  22 ++
 6 files changed, 218 insertions(+), 7 deletions(-)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 099f13c..b8aa5a7 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -531,16 +531,11 @@ bool cfg80211_beaconing_iface_active(struct wireless_dev 
*wdev)
return active;
 }
 
-bool cfg80211_any_wiphy_oper_chan(struct wiphy *wiphy,
- struct ieee80211_channel *chan)
+static bool cfg80211_is_wiphy_oper_chan(struct wiphy *wiphy,
+   struct ieee80211_channel *chan)
 {
struct wireless_dev *wdev;
 
-   ASSERT_RTNL();
-
-   if (!(chan->flags & IEEE80211_CHAN_RADAR))
-   return false;
-
list_for_each_entry(wdev, >wdev_list, list) {
wdev_lock(wdev);
if (!cfg80211_beaconing_iface_active(wdev)) {
@@ -558,6 +553,27 @@ bool cfg80211_any_wiphy_oper_chan(struct wiphy *wiphy,
return false;
 }
 
+bool cfg80211_any_wiphy_oper_chan(struct wiphy *wiphy,
+ struct ieee80211_channel *chan)
+{
+   struct cfg80211_registered_device *rdev;
+
+   ASSERT_RTNL();
+
+   if (!(chan->flags & IEEE80211_CHAN_RADAR))
+   return false;
+
+   list_for_each_entry(rdev, _rdev_list, list) {
+   if (!reg_dfs_domain_same(wiphy, >wiphy))
+   continue;
+
+   if (cfg80211_is_wiphy_oper_chan(>wiphy, chan))
+   return true;
+   }
+
+   return false;
+}
+
 static bool cfg80211_get_chans_dfs_available(struct wiphy *wiphy,
 u32 center_freq,
 u32 bandwidth)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 04143df..a5630e9 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -357,6 +357,38 @@ static void cfg80211_sched_scan_stop_wk(struct work_struct 
*work)
rtnl_unlock();
 }
 
+static void cfg80211_propagate_radar_detect_wk(struct work_struct *work)
+{
+   struct cfg80211_registered_device *rdev;
+
+   rdev = container_of(work, struct cfg80211_registered_device,
+   propagate_radar_detect_wk);
+
+   rtnl_lock();
+
+   regulatory_propagate_dfs_state(>wiphy, >radar_chandef,
+  NL80211_DFS_UNAVAILABLE,
+  NL80211_RADAR_DETECTED);
+
+   rtnl_unlock();
+}
+
+static void cfg80211_propagate_cac_done_wk(struct work_struct *work)
+{
+   struct cfg80211_registered_device *rdev;
+
+   rdev = container_of(work, struct cfg80211_registered_device,
+   propagate_cac_done_wk);
+
+   rtnl_lock();
+
+   regulatory_propagate_dfs_state(>wiphy, >cac_done_chandef,
+  NL80211_DFS_AVAILABLE,
+  NL80211_RADAR_CAC_FINISHED);
+
+   rtnl_unlock();
+}
+
 /* exported functions */
 
 struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, int sizeof_priv,
@@ -456,6 +488,9 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, 
int sizeof_priv,
spin_lock_init(>destroy_list_lock);
INIT_WORK(>destroy_work, cfg80211_destroy_iface_wk);
INIT_WORK(>sched_scan_stop_wk, cfg80211_sched_scan_stop_wk);
+   INIT_WORK(>propagate_radar_detect_wk,
+ cfg80211_propagate_radar_detect_wk);
+   INIT_WORK(>propagate_cac_done_wk, cfg80211_propagate_cac_done_wk);
 
 #ifdef CONFIG_CFG80211_DEFAULT_PS
rdev->wiphy.flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT;
@@ -915,6 +950,8 @@ void wiphy_unregister(struct wiphy *wiphy)
flush_work(>destroy_work);
flush_work(>sched_scan_stop_wk);
flush_work(>mlme_unreg_wk);
+   flush_work(>propagate_radar_detect_wk);
+   flush_work(>propagate_cac_done_wk);
 
 #ifdef CONFIG_PM
  

[PATCH V2 1/3] cfg80211: Make pre-CAC results valid only for ETSI domain

[Vasanthakumar Thiagarajan]

DFS requirement for ETSI domain (section 4.7.1.4 in
ETSI EN 301 893 V1.8.1) is the only one which explicitly
states that once DFS channel is marked as available afer
the CAC, this channel will remain in available state even
moving to a different operating channel. But the same is
not explicitly stated in FCC DFS requirement. Also, Pre-CAC
requriements are not explicitly mentioned in FCC requirement.
Current implementation in keeping DFS channel in available
state is same as described in ETSI domain.

For ETSI DFS domain, this patch gives a grace period of 2 seconds
since the completion of successful CAC before moving the channel's
DFS state to 'usable' from 'available' state. The same grace period
is checked against the channel's dfs_state_entered timestamp while
deciding if a DFS channel is available for operation. There is a new
radar event, NL80211_RADAR_PRE_CAC_EXPIRED, reported when DFS channel
is moved from available to usable state after the grace period. Also
make sure the DFS channel state is reset to usable once the beaconing
operation on that channel is brought down (like stop_ap, leave_ibss
and leave_mesh) in non-ETSI domain.

Signed-off-by: Vasanthakumar Thiagarajan 
---
 include/uapi/linux/nl80211.h |   5 +++
 net/wireless/ap.c|   5 +++
 net/wireless/chan.c  | 101 +++
 net/wireless/core.h  |  10 +
 net/wireless/ibss.c  |   1 +
 net/wireless/mesh.c  |   1 +
 net/wireless/mlme.c  |  40 +
 net/wireless/reg.c   |  28 
 net/wireless/reg.h   |  14 ++
 9 files changed, 196 insertions(+), 9 deletions(-)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 9a499b1..cd4dfef 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4913,12 +4913,17 @@ enum nl80211_smps_mode {
  * change to the channel status.
  * @NL80211_RADAR_NOP_FINISHED: The Non-Occupancy Period for this channel is
  * over, channel becomes usable.
+ * @NL80211_RADAR_PRE_CAC_EXPIRED: Channel Availability Check done on this
+ * non-operating channel is expired and no longer valid. New CAC must
+ * be done on this channel before starting the operation. This is not
+ * applicable for ETSI dfs domain where pre-CAC is valid for ever.
  */
 enum nl80211_radar_event {
NL80211_RADAR_DETECTED,
NL80211_RADAR_CAC_FINISHED,
NL80211_RADAR_CAC_ABORTED,
NL80211_RADAR_NOP_FINISHED,
+   NL80211_RADAR_PRE_CAC_EXPIRED,
 };
 
 /**
diff --git a/net/wireless/ap.c b/net/wireless/ap.c
index bdad1f9..25666d3 100644
--- a/net/wireless/ap.c
+++ b/net/wireless/ap.c
@@ -32,6 +32,11 @@ int __cfg80211_stop_ap(struct cfg80211_registered_device 
*rdev,
rdev_set_qos_map(rdev, dev, NULL);
if (notify)
nl80211_send_ap_stopped(wdev);
+
+   /* Should we apply the grace period during beaconing interface
+* shutdown also?
+*/
+   cfg80211_sched_dfs_chan_update(rdev);
}
 
return err;
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 5497d022..099f13c 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -456,6 +456,107 @@ bool cfg80211_chandef_dfs_usable(struct wiphy *wiphy,
return (r1 + r2 > 0);
 }
 
+/*
+ * Checks if center frequency of chan falls with in the bandwidth
+ * range of chandef.
+ */
+bool cfg80211_is_sub_chan(struct cfg80211_chan_def *chandef,
+ struct ieee80211_channel *chan)
+{
+   int width;
+   u32 cf_offset, freq;
+
+   if (chandef->chan->center_freq == chan->center_freq)
+   return true;
+
+   width = cfg80211_chandef_get_width(chandef);
+   if (width <= 20)
+   return false;
+
+   cf_offset = width / 2 - 10;
+
+   for (freq = chandef->center_freq1 - width / 2 + 10;
+freq <= chandef->center_freq1 + width / 2 - 10; freq += 20) {
+   if (chan->center_freq == freq)
+   return true;
+   }
+
+   if (!chandef->center_freq2)
+   return false;
+
+   for (freq = chandef->center_freq2 - width / 2 + 10;
+freq <= chandef->center_freq2 + width / 2 - 10; freq += 20) {
+   if (chan->center_freq == freq)
+   return true;
+   }
+
+   return false;
+}
+
+bool cfg80211_beaconing_iface_active(struct wireless_dev *wdev)
+{
+   bool active = false;
+
+   ASSERT_WDEV_LOCK(wdev);
+
+   if (!wdev->chandef.chan)
+   return false;
+
+   switch (wdev->iftype) {
+   case NL80211_IFTYPE_AP:
+   case NL80211_IFTYPE_P2P_GO:
+   active = wdev->beacon_interval != 0;
+   break;
+   case NL80211_IFTYPE_ADHOC:
+   active = wdev->ssid_len != 0;
+   break;
+   case 

[PATCH V2 0/3] Pre-CAC and sharing DFS state across multiple radios

[Vasanthakumar Thiagarajan]

Currently irrespective of dfs domain and radar detection activity
pre-CAC results for a wiphy are retained till the wiphy is detroyed.
This may not be preferred in non-ETSI dfs domain where pre-CAC is not
explicitly mentioned in the respective DFS requirement spec. This patch
set modifies the current behaviour of pre-CAC for non-ETSI domain by
giving 2 seconds grace period for dfs master interface to start operating
on the CAC completed channel.

This patch set also adds support to share dfs channel state across
multiple radios of the same regulatory configuration.

Vasanthakumar Thiagarajan (3):
  cfg80211: Make pre-CAC results valid only for ETSI domain
  cfg80211: Disallow moving out of operating DFS channel in non-ETSI
  cfg80211: Share Channel DFS state across wiphys of same DFS domain

 include/uapi/linux/nl80211.h |   5 ++
 net/wireless/ap.c|   5 ++
 net/wireless/chan.c  | 117 ++
 net/wireless/core.c  |  37 +++
 net/wireless/core.h  |  16 +
 net/wireless/ibss.c  |   1 +
 net/wireless/mesh.c  |   1 +
 net/wireless/mlme.c  |  50 ---
 net/wireless/nl80211.c   |  52 +++
 net/wireless/reg.c   | 148 +++
 net/wireless/reg.h   |  36 +++
 11 files changed, 459 insertions(+), 9 deletions(-)

-- 
1.9.1

Subcarrier nulling in ath9k

[Gaurang Ramesh Naik]

Hi,

Is it possible to null specific subcarriers through the ath9k driver
code or ath9k firmware? Or is it completely done at the hardware?

Any help is appreciated.

Thanks,
GN

Re: [PATCH] NFC: remove TI nfcwilink driver

[Samuel Ortiz]

Hi Rob,

On Wed, Jan 25, 2017 at 04:23:07PM -0600, Rob Herring wrote:
> It appears that TI WiLink devices including NFC (WL185x/WL189x) never
> shipped. The only information I found were announcements in Feb
> 2012 about the parts. There's been no activity on this driver besided
> common changes since initially added in Jan 2012. There's also no in
> users that instantiate the platform device (nor DT bindings).
> 
> This is a first step in removing TI ST (shared transport) driver in
> favor of extending the BT hci_ll driver to support WL183x chips.
> 
> Cc: Ilan Elias 
> Cc: Marcel Holtmann 
> Cc: Samuel Ortiz 
> Cc: Lauro Ramos Venancio 
> Cc: Aloisio Almeida Jr 
> Cc: linux-wireless@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/nfc/Kconfig |  11 -
>  drivers/nfc/Makefile|   1 -
>  drivers/nfc/nfcwilink.c | 578 
> 
>  3 files changed, 590 deletions(-)
>  delete mode 100644 drivers/nfc/nfcwilink.c
Applied to nfc-next, thanks.

Cheers,
Samuel.

Re: [PATCH resend 1/4] nfc: Add support RC-S380P to port100

[Samuel Ortiz]

Hi Hirofumi,

On Sat, Feb 04, 2017 at 10:15:22AM +0900, OGAWA Hirofumi wrote:
> 
> 
> Signed-off-by: OGAWA Hirofumi 
> ---
> 
>  drivers/nfc/port100.c |8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
All 4 patches applied, thanks.

Cheers,
Samuel.

Re: [PATCH] NFC: remove TI nfcwilink driver

[Samuel Ortiz]

Hi Rob,

On Fri, Feb 24, 2017 at 02:56:48PM -0600, Rob Herring wrote:
> On Wed, Jan 25, 2017 at 11:54 PM, Marcel Holtmann  wrote:
> > Hi Rob,
> >
> >> It appears that TI WiLink devices including NFC (WL185x/WL189x) never
> >> shipped. The only information I found were announcements in Feb
> >> 2012 about the parts. There's been no activity on this driver besided
> >> common changes since initially added in Jan 2012. There's also no in
> >> users that instantiate the platform device (nor DT bindings).
> >>
> >> This is a first step in removing TI ST (shared transport) driver in
> >> favor of extending the BT hci_ll driver to support WL183x chips.
> >
> > since the firmware files TINfcInit_* also never made it into the 
> > linux-firmware tree, I have no idea who is using this driver. I am actually 
> > fine with removing it since it would be easy enough to bring back based on 
> > hci_ll driver once there is hardware to test this on.
> 
> Ping. Someone going to pick up this patch?
I'll take it, I need to catch up with pending NFC patches this week.

Cheers,
Samuel.

RE: [PATCHv2 0/4] cfg80211: mac80211: BTCOEX feature support

[Raja, Tamizh Chelvam]

Hi Arend,

> >
> > This patchset add support for BTCOEX feature to enable/disable and
> > modifying btcoex priority value via nl80211
> >
> > Tamizh chelvam (4):
> >   ath10k: Add support to enable or disable btcoex via nl80211
> >   ath10k: Add support to update btcoex priority value via nl80211
> >   dt: bindings: add new dt entry for BTCOEX feature in qcom,ath10k.txt
> >   ath10k: Add support to read btcoex related data from DT
> 
> This cover letter does not seem to reflect the other patches that were sent to
> the wireless list as those are about cfg80211/mac80211; not ath10k?

[Tamizh] ath10k patches are under progress, will send it soon.

> 
> Regards,
> Arend
> 
> > v2 :
> >   * Introduced NL80211_CMD_SET_BTCOEX to enable/disable btcoex and
> > to set/modify btcoex_priority.
> >   * Added bool variable in wiphy structure to advertise btcoex_priority
> > feature and removed BITMAP calculation for btcoex_priority value.
> >
> >  .../bindings/net/wireless/qcom,ath10k.txt  |4 +
> >  drivers/net/wireless/ath/ath10k/core.c |   44 -
> >  drivers/net/wireless/ath/ath10k/core.h |9 ++
> >  drivers/net/wireless/ath/ath10k/debug.c|   40 ++---
> >  drivers/net/wireless/ath/ath10k/mac.c  |   94
> +++-
> >  drivers/net/wireless/ath/ath10k/mac.h  |1 +
> >  drivers/net/wireless/ath/ath10k/wmi-ops.h  |   19 
> >  drivers/net/wireless/ath/ath10k/wmi.c  |   20 +
> >  drivers/net/wireless/ath/ath10k/wmi.h  |   20 +
> >  9 files changed, 215 insertions(+), 36 deletions(-)
> >

[PATCH 2/4] brcmfmac: p2p and normal ap access are not always possible at the same time

[Hans de Goede]

The firmware responding with -EBUSY when trying to add an extra virtual-if
is a normal thing, do not print an error for this.

Signed-off-by: Hans de Goede 
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14 ++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c |  5 -
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 7ffc4ab..c54e8b4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -688,11 +688,17 @@ static struct wireless_dev 
*brcmf_cfg80211_add_iface(struct wiphy *wiphy,
return ERR_PTR(-EINVAL);
}
 
-   if (IS_ERR(wdev))
-   brcmf_err("add iface %s type %d failed: err=%d\n",
- name, type, (int)PTR_ERR(wdev));
-   else
+   if (IS_ERR(wdev)) {
+   err = PTR_ERR(wdev);
+   if (err != -EBUSY)
+   brcmf_err("add iface %s type %d failed: err=%d\n",
+ name, type, err);
+   else
+   brcmf_dbg(INFO, "add iface %s type %d failed: err=%d\n",
+ name, type, err);
+   } else {
brcmf_cfg80211_update_proto_addr_mode(wdev);
+   }
 
return wdev;
 }
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index de19c7c..b5df0a0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -2090,7 +2090,10 @@ static struct wireless_dev 
*brcmf_p2p_create_p2pdev(struct brcmf_p2p_info *p2p,
/* Initialize P2P Discovery in the firmware */
err = brcmf_fil_iovar_int_set(pri_ifp, "p2p_disc", 1);
if (err < 0) {
-   brcmf_err("set p2p_disc error\n");
+   if (err != -EBUSY)
+   brcmf_err("set p2p_disc error\n");
+   else
+   brcmf_dbg(INFO, "set p2p_disc error\n");
brcmf_fweh_p2pdev_setup(pri_ifp, false);
brcmf_cfg80211_arm_vif_event(p2p->cfg, NULL);
goto fail;
-- 
2.9.3

[PATCH 3/4] brcmfmac: Do not complain about country code "00"

[Hans de Goede]

The country code gets set to "00" by default at boot, ignore this
rather then logging an error about it.

Signed-off-by: Hans de Goede 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index c54e8b4..c0b7f69 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6705,6 +6705,10 @@ static void brcmf_cfg80211_reg_notifier(struct wiphy 
*wiphy,
s32 err;
int i;
 
+   /* The country code gets set to "00" by default at boot, ignore */
+   if (req->alpha2[0] == '0' && req->alpha2[1] == '0')
+   return;
+
/* ignore non-ISO3166 country codes */
for (i = 0; i < sizeof(req->alpha2); i++)
if (req->alpha2[i] < 'A' || req->alpha2[i] > 'Z') {
-- 
2.9.3

[PATCH 1/4] brcmfmac: Do not print the firmware version as an error

[Hans de Goede]

Using pr_err for things which are not errors is a bad idea. E.g. it
will cause the plymouth bootsplash screen to drop back to the text
console so that the user can see the error, which is not what we
normally want to happen.

Instead add a new brcmf_info macro and use that.

Signed-off-by: Hans de Goede 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h  | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 3e15d64..6d565f1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -161,7 +161,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
strsep(, "\n");
 
/* Print fw version info */
-   brcmf_err("Firmware version = %s\n", buf);
+   brcmf_info("Firmware version = %s\n", buf);
 
/* locate firmware version number for ethtool */
ptr = strrchr(buf, ' ') + 1;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
index 6687812..d0d8180 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
@@ -59,11 +59,14 @@
pr_err("%s: " fmt, __func__, ##__VA_ARGS__);\
} while (0)
 #endif
+#define brcmf_info(fmt, ...)   pr_info("%s: " fmt, __func__, ##__VA_ARGS__)
 #else
 __printf(2, 3)
 void __brcmf_err(const char *func, const char *fmt, ...);
 #define brcmf_err(fmt, ...) \
__brcmf_err(__func__, fmt, ##__VA_ARGS__)
+/* For tracing purposes treat info messages as errors */
+#define brcmf_info brcm_err
 #endif
 
 #if defined(DEBUG) || defined(CONFIG_BRCM_TRACING)
-- 
2.9.3