Re: [PATCH RFC 2/2] brcmfmac: add brcmf_err_pub macro for better error messages

[Arend Van Spriel]

On 20-1-2017 12:17, Rafał Miłecki wrote:
> On 01/20/2017 11:26 AM, Arend Van Spriel wrote:
>> On 18-1-2017 15:27, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <ra...@milecki.pl>
>>>
>>> This macro accepts an extra argument of struct brcmf_pub pointer. It
>>> allows referencing struct device and printing error using dev_err. This
>>> is very useful on devices with more than one wireless card suppored by
>>> brcmfmac. Thanks for dev_err it's possible to identify device that error
>>> is related to.
>>>
>>> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
>>> ---
>>> I could convert few more brcmf_err calls to this new brcmf_err_pub
>>> but I don't
>>> want to spent too much time on this in case someone has a better idea.
>>>
>>> If you do, comment! :)
>>
>> I do not, but still comment ;-). Like the idea. Was on our list because
>> it is damn convenient when testing on router with multiple devices. I
>> would prefer to replace the existing brcmf_err() rather than introducing
>> a new one and would like to do the same for brcmf_dbg(). However, not
>> all call sites have a struct brcmf_pub instance available. Everywhere
>> before completing brcmf_attach() that is.
> 
> I decided to try new macro because:
> 1) I was too lazy to convert all calls at once
> 2) I could stick to brcmf_err when struct brcmf_pub isn't available yet
> 
> In theory we could pass NULL to dev_err, I'd result in something like:
> [   14.746754] (NULL device *): brcmf_c_preinit_dcmds: Firmware version
> = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> 
> Unfortunately AFAIK it's not possible to handle
> brcmf_err(NULL "Foo\n");
> calls while keeping brcmf_err a macro.
> 
> I was thinking about something like:
> #define brcmf_err(pub, fmt, ...)\
> do {\
> if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit())\
> dev_err(pub ? pub->bus_if->dev : NULL,\
> "%s: " fmt, __func__,\
> ##__VA_ARGS__);\
> } while (0)
> 
> but this wouldn't compile because for brcmf_err(NULL "Foo\n"); it would
> roll
> out to:
> dev_err(NULL ? NULL->bus_if->dev : NULL, "Foo\n");
> 
> I *can* support brcmf_err(NULL "Foo\n"); calls if I change brcmf_err from
> macro to a function (inline probably). Do you think it's a good idea?

I was wondering if brcmf_err(ptr, "bla\n") could determine the pointer
type and accept 'struct device *' and 'struct brcmf_pub *'. I think we
always have a struct device pointer. Only in brcmf_module_init() we do not.

Regards,
Arend

Re: [PATCH RFC 1/2] brcmfmac: merge two brcmf_err macros into one

[Arend Van Spriel]

On 20-1-2017 11:58, Rafał Miłecki wrote:
> On 20 January 2017 at 11:14, Arend Van Spriel
> <arend.vanspr...@broadcom.com> wrote:
>> On 20-1-2017 11:13, Arend Van Spriel wrote:
>>> On 18-1-2017 15:27, Rafał Miłecki wrote:
>>>> From: Rafał Miłecki <ra...@milecki.pl>
>>>>
>>>> This allows simplifying the code by adding a simple IS_ENABLED check for
>>>> CONFIG_BRCMDB symbol.
>>
>> Actually it should be CONFIG_BRCMDBG above.
>>
>> Kalle,
>>
>> Can you fix that in the commit message?
> 
> It's only RFC, I'll make sure to fix that in final version

You're right. Missed that.

Regards,
Arend

Re: [PATCH RFC 2/2] brcmfmac: add brcmf_err_pub macro for better error messages

[Arend Van Spriel]

On 18-1-2017 15:27, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This macro accepts an extra argument of struct brcmf_pub pointer. It
> allows referencing struct device and printing error using dev_err. This
> is very useful on devices with more than one wireless card suppored by
> brcmfmac. Thanks for dev_err it's possible to identify device that error
> is related to.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> I could convert few more brcmf_err calls to this new brcmf_err_pub but I don't
> want to spent too much time on this in case someone has a better idea.
> 
> If you do, comment! :)

I do not, but still comment ;-). Like the idea. Was on our list because
it is damn convenient when testing on router with multiple devices. I
would prefer to replace the existing brcmf_err() rather than introducing
a new one and would like to do the same for brcmf_dbg(). However, not
all call sites have a struct brcmf_pub instance available. Everywhere
before completing brcmf_attach() that is.

Regards,
Arend

> Example
> Before:
> [   14.735640] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 
> 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> [   15.155732] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 
> 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> [   15.535682] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 
> 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> After:
> [   14.746754] brcmfmac :01:00.0: brcmf_c_preinit_dcmds: Firmware version 
> = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> [   15.166854] brcmfmac 0001:03:00.0: brcmf_c_preinit_dcmds: Firmware version 
> = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> [   15.546807] brcmfmac 0001:04:00.0: brcmf_c_preinit_dcmds: Firmware version 
> = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> ---
>  .../wireless/broadcom/brcm80211/brcmfmac/common.c  | 19 ++---
>  .../wireless/broadcom/brcm80211/brcmfmac/core.c| 31 
> +++---
>  .../wireless/broadcom/brcm80211/brcmfmac/debug.h   | 17 
>  .../broadcom/brcm80211/brcmfmac/tracepoint.c   |  4 +--
>  4 files changed, 40 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index 5fb4a14..7a05de78 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -108,6 +108,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>  {
>   s8 eventmask[BRCMF_EVENTING_MASK_LEN];
>   u8 buf[BRCMF_DCMD_SMLEN];
> + struct brcmf_pub *pub = ifp->drvr;
>   struct brcmf_rev_info_le revinfo;
>   struct brcmf_rev_info *ri;
>   char *ptr;
> @@ -117,7 +118,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>   err = brcmf_fil_iovar_data_get(ifp, "cur_etheraddr", ifp->mac_addr,
>  sizeof(ifp->mac_addr));
>   if (err < 0) {
> - brcmf_err("Retreiving cur_etheraddr failed, %d\n", err);
> + brcmf_err_pub(pub, "Retreiving cur_etheraddr failed, %d\n", 
> err);
>   goto done;
>   }
>   memcpy(ifp->drvr->mac, ifp->mac_addr, sizeof(ifp->drvr->mac));
> @@ -126,7 +127,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>, sizeof(revinfo));
>   ri = >drvr->revinfo;
>   if (err < 0) {
> - brcmf_err("retrieving revision info failed, %d\n", err);
> + brcmf_err_pub(pub, "retrieving revision info failed, %d\n", 
> err);
>   } else {
>   ri->vendorid = le32_to_cpu(revinfo.vendorid);
>   ri->deviceid = le32_to_cpu(revinfo.deviceid);
> @@ -153,7 +154,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>   strcpy(buf, "ver");
>   err = brcmf_fil_iovar_data_get(ifp, "ver", buf, sizeof(buf));
>   if (err < 0) {
> - brcmf_err("Retreiving version information failed, %d\n",
> + brcmf_err_pub(pub, "Retreiving version information failed, 
> %d\n",
> err);
>   goto done;
>   }
> @@ -161,7 +162,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>   strsep(, "\n");
>  
>   /* Print fw version info */
> - brcmf_err("Firmware version = %s\n", buf);
> + brcmf_err_pub(pub, "Firmware version = %s\n", buf);
>  
>   /* locate firmware version number for ethtool */
>   ptr = strrchr(buf, ' ') + 1;
> @@ -170,7 +171,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>   /* set mpc */
>   err = brcmf_fil_iovar_int_set(ifp, "mpc", 1);
>   if (err) {
> - brcmf_err("failed setting mpc\n");
> + brcmf_err_pub(pub, "failed setting mpc\n");
>   goto done;
>   }
>  
> 

Re: [PATCH] brcmfmac: drop duplicated core selection from brcmf_pcie_attach

[Arend Van Spriel]

On 19-1-2017 10:51, Rafał Miłecki wrote:
> From: Rafał Miłecki <ra...@milecki.pl>
> 
> It was left after reworking PCIe reset in commit 07fe2e38c7fd
> ("brcmfmac: Reset PCIE devices after recognition.").
> 
> Cc: Hante Meuleman <hante.meule...@broadcom.com>
Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 19db8f2..6fae4cf 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -601,7 +601,6 @@ static void brcmf_pcie_attach(struct brcmf_pciedev_info 
> *devinfo)
>  {
>   u32 config;
>  
> - brcmf_pcie_select_core(devinfo, BCMA_CORE_PCIE2);
>   /* BAR1 window may not be sized properly */
>   brcmf_pcie_select_core(devinfo, BCMA_CORE_PCIE2);
>   brcmf_pcie_write_reg32(devinfo, BRCMF_PCIE_PCIE2REG_CONFIGADDR, 0x4e0);
> 

Re: [PATCH RFC 1/2] brcmfmac: merge two brcmf_err macros into one

[Arend Van Spriel]

On 20-1-2017 11:13, Arend Van Spriel wrote:
> On 18-1-2017 15:27, Rafał Miłecki wrote:
>> From: Rafał Miłecki <ra...@milecki.pl>
>>
>> This allows simplifying the code by adding a simple IS_ENABLED check for
>> CONFIG_BRCMDB symbol.

Actually it should be CONFIG_BRCMDBG above.

Kalle,

Can you fix that in the commit message?

Regards,
Arend

> Nice!
> 
> Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
>> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
>> ---
>>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h | 8 ++--
>>  1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h 
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
>> index 6687812..1fe4aa9 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
>> @@ -45,20 +45,16 @@
>>  #undef pr_fmt
>>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>>  
>> +#ifndef CONFIG_BRCM_TRACING
>>  /* Macro for error messages. net_ratelimit() is used when driver
>>   * debugging is not selected. When debugging the driver error
>>   * messages are as important as other tracing or even more so.
>>   */
>> -#ifndef CONFIG_BRCM_TRACING
>> -#ifdef CONFIG_BRCMDBG
>> -#define brcmf_err(fmt, ...) pr_err("%s: " fmt, __func__, ##__VA_ARGS__)
>> -#else
>>  #define brcmf_err(fmt, ...) \
>>  do {\
>> -if (net_ratelimit())\
>> +if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit())  \
>>  pr_err("%s: " fmt, __func__, ##__VA_ARGS__);\
>>  } while (0)
>> -#endif
>>  #else
>>  __printf(2, 3)
>>  void __brcmf_err(const char *func, const char *fmt, ...);
>>

Re: [PATCH RFC 1/2] brcmfmac: merge two brcmf_err macros into one

[Arend Van Spriel]

On 18-1-2017 15:27, Rafał Miłecki wrote:
> From: Rafał Miłecki <ra...@milecki.pl>
> 
> This allows simplifying the code by adding a simple IS_ENABLED check for
> CONFIG_BRCMDB symbol.

Nice!

Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> index 6687812..1fe4aa9 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> @@ -45,20 +45,16 @@
>  #undef pr_fmt
>  #define pr_fmt(fmt)  KBUILD_MODNAME ": " fmt
>  
> +#ifndef CONFIG_BRCM_TRACING
>  /* Macro for error messages. net_ratelimit() is used when driver
>   * debugging is not selected. When debugging the driver error
>   * messages are as important as other tracing or even more so.
>   */
> -#ifndef CONFIG_BRCM_TRACING
> -#ifdef CONFIG_BRCMDBG
> -#define brcmf_err(fmt, ...)  pr_err("%s: " fmt, __func__, ##__VA_ARGS__)
> -#else
>  #define brcmf_err(fmt, ...)  \
>   do {\
> - if (net_ratelimit())\
> + if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit())  \
>   pr_err("%s: " fmt, __func__, ##__VA_ARGS__);\
>   } while (0)
> -#endif
>  #else
>  __printf(2, 3)
>  void __brcmf_err(const char *func, const char *fmt, ...);
> 

Re: [PATCH v2 01/13] wil6210: add sysfs file for FTM calibration

[Arend Van Spriel]

On 19-1-2017 13:36, Lior David wrote:
> On 1/19/2017 2:24 PM, Valo, Kalle wrote:
>> Maya Erez  writes:
>>
>>> From: Lior David 
>>>
>>> In fine timing measurements, the calculation is affected by
>>> 2 parts: timing of packets over the air, which is platform
>>> independent, and platform-specific delays, which are dependent
>>> on things like antenna cable length and type.
>>> Add a sysfs file which allows to get/set these platform specific
>>> delays, separated into the TX and RX components.
>>> There are 2 key scenarios where the file can be used:
>>> 1. Calibration - start with some initial values (for example,
>>> the default values at startup), make measurements at a known
>>> distance, then iteratively change the values until the
>>> measurement results match the known distance.
>>> 2. Adjust the delays when platform starts up, based on known
>>> values.
>>>
>>> Signed-off-by: Lior David 
>>> Signed-off-by: Maya Erez 
>>
>> Can't this go via nl80211? sysfs is not really supposed to be used for
>> something like this.
>>
> There is no nl80211 API for this (yet?).

So come up with one...?

> Will it be ok to put this in debugfs? Normally this will be in the board
> file (as part of RF configuration) but it will be useful to play
> with these values for debugging/diagnostics.

What is doing the FTM measurements? Is it all done in user-space? That
would mean you also need measurement data exported to user-space. How is
that done? Intel has a FTM api proposal, but it has not been submitted
upstream (yet?).

Regards,
Arend

Re: [PATCH] nl80211: fix validation of scheduled scan info for wowlan netdetect

[Arend Van Spriel]

On 19-1-2017 13:00, Luca Coelho wrote:
> On Thu, 2017-01-19 at 10:01 +0000, Arend van Spriel wrote:
>> For wowlan netdetect a separate limit is defined for the number of
>> matchsets. Currently, this limit is ignored and the regular limit
>> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
>> used for the net-detect case as well.
>>
>> Cc: Luciano Coelho <luciano.coe...@intel.com>
>> Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
>> ---
> 
> What?! You don't have the same number of matchsets for both? :P

Actually I have, but your comment mentioned they do not have to be the
same. brcmfmac actually did not set max_nd_match_sets so I was surprised
it worked. That said this patch will result in regression in brcmfmac
:-p Not sure about other drivers supporting net-detect.

Regards,
Arend

> Looks good.
> 
> Reviewed-by: Luca Coelho <luciano.coe...@intel.com>
> 
> --
> Luca.
> 

[PATCH] nl80211: fix validation of scheduled scan info for wowlan netdetect

[Arend van Spriel]

For wowlan netdetect a separate limit is defined for the number of
matchsets. Currently, this limit is ignored and the regular limit
for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
used for the net-detect case as well.

Cc: Luciano Coelho <luciano.coe...@intel.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 net/wireless/nl80211.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b4e7bdd..df0675d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6852,7 +6852,7 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct 
genl_info *info)
 
 static struct cfg80211_sched_scan_request *
 nl80211_parse_sched_scan(struct wiphy *wiphy, struct wireless_dev *wdev,
-struct nlattr **attrs)
+struct nlattr **attrs, int max_match_sets)
 {
struct cfg80211_sched_scan_request *request;
struct nlattr *attr;
@@ -6917,7 +6917,7 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct 
genl_info *info)
if (!n_match_sets && default_match_rssi != NL80211_SCAN_RSSI_THOLD_OFF)
n_match_sets = 1;
 
-   if (n_match_sets > wiphy->max_match_sets)
+   if (n_match_sets > max_match_sets)
return ERR_PTR(-EINVAL);
 
if (attrs[NL80211_ATTR_IE])
@@ -7217,7 +7217,8 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
return -EINPROGRESS;
 
sched_scan_req = nl80211_parse_sched_scan(>wiphy, wdev,
- info->attrs);
+ info->attrs,
+ rdev->wiphy.max_match_sets);
 
err = PTR_ERR_OR_ZERO(sched_scan_req);
if (err)
@@ -10030,7 +10031,8 @@ static int nl80211_parse_wowlan_nd(struct 
cfg80211_registered_device *rdev,
if (err)
goto out;
 
-   trig->nd_config = nl80211_parse_sched_scan(>wiphy, NULL, tb);
+   trig->nd_config = nl80211_parse_sched_scan(>wiphy, NULL, tb,
+  wowlan->max_nd_match_sets);
err = PTR_ERR_OR_ZERO(trig->nd_config);
if (err)
trig->nd_config = NULL;
-- 
1.9.1

Re: [PATCH V2 4/4] brcmfmac: rename brcmf_bus_start function to brcmf_bus_started

[Arend Van Spriel]

On 18-1-2017 11:48, Rafał Miłecki wrote:
> From: Rafał Miłecki <ra...@milecki.pl>
> 
> This intends to make init/attach process slightly easier to follow.
> 
> What driver was doing in brcmf_bus_start wasn't bus specific at all and
> function brcmf_bus_stop wasn't undoing things done there. This function
> is supposed to be called by bus specific code when the bus is ready.

Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
> ---
> V2: Use "brcmf_bus_started" name instead of "brcmf_attach_phase2", don't 
> rename
> brcmf_attach.
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h| 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c   | 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c   | 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c   | 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c| 2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> index b5bb971..76693df 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> @@ -238,7 +238,7 @@ 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);
>  
> -int brcmf_bus_start(struct device *dev);
> +int brcmf_bus_started(struct device *dev);
>  s32 brcmf_iovar_data_set(struct device *dev, char *name, void *data, u32 
> len);
>  void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
>  
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index 3e15d64..5fb4a14 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -74,7 +74,7 @@ module_param_named(roamoff, brcmf_roamoff, int, S_IRUSR);
>  MODULE_PARM_DESC(roamoff, "Do not use internal roaming engine");
>  
>  #ifdef DEBUG
> -/* always succeed brcmf_bus_start() */
> +/* always succeed brcmf_bus_started() */
>  static int brcmf_ignore_probe_fail;
>  module_param_named(ignore_probe_fail, brcmf_ignore_probe_fail, int, 0);
>  MODULE_PARM_DESC(ignore_probe_fail, "always succeed probe for debugging");
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index 372d2c4..b73a55b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -966,7 +966,7 @@ static int brcmf_revinfo_read(struct seq_file *s, void 
> *data)
>   return 0;
>  }
>  
> -int brcmf_bus_start(struct device *dev)
> +int brcmf_bus_started(struct device *dev)
>  {
>   int ret = -1;
>   struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 048027f..19db8f2 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -1572,7 +1572,7 @@ static int brcmf_pcie_attach_bus(struct 
> brcmf_pciedev_info *devinfo)
>   if (ret) {
>   brcmf_err("brcmf_attach failed\n");
>   } else {
> - ret = brcmf_bus_start(>pdev->dev);
> + ret = brcmf_bus_started(>pdev->dev);
>   if (ret)
>   brcmf_err("dongle is not responding\n");
>   }
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index dfb0658..5298582 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -4065,7 +4065,7 @@ static void brcmf_sdio_firmware_callback(struct device 
> *dev,
>  
>   sdio_release_host(sdiodev->func[1]);
>  
> - err = brcmf_bus_start(dev);
> + err = brcmf_bus_started(dev);
>   if (err != 0) {
>   brcmf_err("dongle is not responding\n");
>   goto fail;
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c 
> b/drivers/net/wireless/broadcom/brc

Re: [PATCH v3] brcmfmac: fix incorrect event channel deduction

[Arend Van Spriel]

On 18-1-2017 0:24, gavi...@thegavinli.com wrote:
> From: Gavin Li <g...@thegavinli.com>
> 
> brcmf_sdio_fromevntchan() was being called on the the data frame
> rather than the software header, causing some frames to be
> mischaracterized as on the event channel rather than the data channel.
> 
> This fixes a major performance regression (due to dropped packets).
> 
> Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet")

Actually would prefer Franky to chime in as well as he made the change
and confirm correctness. It was introduced a couple of kernel versions
back and only a performance regression so seems ok to let this go in
4.11 for now and backport as needed for stable later.

Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
> Signed-off-by: Gavin Li <g...@thegavinli.com>
> Cc: <sta...@vger.kernel.org> [4.7+]
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index dfb0658713d9..d2219885071f 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -1661,7 +1661,7 @@ static u8 brcmf_sdio_rxglom(struct brcmf_sdio *bus, u8 
> rxseq)
>  pfirst->len, pfirst->next,
>  pfirst->prev);
>   skb_unlink(pfirst, >glom);
> - if (brcmf_sdio_fromevntchan(pfirst->data))
> + if (brcmf_sdio_fromevntchan([SDPCM_HWHDR_LEN]))
>   brcmf_rx_event(bus->sdiodev->dev, pfirst);
>   else
>   brcmf_rx_frame(bus->sdiodev->dev, pfirst,
> 

Re: [PATCH 1/2] brcmfmac: rename brcmf_bus_start function to brcmf_attach_phase2

[Arend Van Spriel]

On 18-1-2017 10:51, Rafał Miłecki wrote:
> On 18 January 2017 at 10:25, Arend Van Spriel
> <arend.vanspr...@broadcom.com> wrote:
>> On 17-1-2017 20:23, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <ra...@milecki.pl>
>>>
>>> This change intends to make init/attach process easier to follow.
>>>
>>> What driver were doing in brcmf_bus_start wasn't bus specific at all and
>>> function brcmf_bus_stop wasn't undoing things done there. It seems
>>> brcmf_detach was actually undoing things done in both: brcmf_attach and
>>> brcmf_bus_start.
>>>
>>> To me it makes more sense to call these two function in a similar way as
>>> they both handle some part of attaching process. It also makes
>>> brcmf_detach more meaningful.
>>
>> To me this is all bike-shedding and I have two options 1) what's in a
>> name and let it pass, or 2) explain the naming. Let's try option 2). It
>> seems your expectation was different because of the name
>> brcmf_*bus*_start(). The function brcmf_attach() is called by
>> bus-specific code, ie. sdio, pcie, or usb, to instantiate the common
>> driver structures and essential common facilities, eg. debugfs, and
>> brcmf_bus_start() is called by bus-specific code when everything is
>> ready for use. For PCIe there is nothing between those calls but for
>> SDIO there are several steps before the party can start, hence the name.
> 
> Sorry you find this cleanup try this way. If you still have some
> patience for this /silly/ stuff, I've one more question.
> 
> So as you noticed (and confirmed my note) both: brcmf_attach and
> brcmf_bus_start are called from bus specific code. They initialize
> some *common* stuff. How did you come with the "brcmf_bus_start" name
> then?
> 1) It's called after bus got initialized (started?)
> 2) It's initializes common stuff
> 3) It doesn't execute bus specific code
> 
> My point is "brcmf_bus_start" name doesn't seem to make much sense. If
> you have any better suggestion than "brcmf_bus_start" and
> "brcmf_attach_phase2", I'll be happy to use it. What could it be?
> brcmf_attach_after_bus_started would be more accurate but too long.

It is a signal given by bus specific code that common code can "start
using the bus" for communication with the device. Maybe
brcmf_bus_started() is more accurate. The fact that common code uses
that signal to execute more initialization stuff is irrelevant.

Regards,
Arend

Re: [PATCH 2/2] brcmfmac: move function declarations to proper headers

[Arend Van Spriel]

On 18-1-2017 10:06, Rafał Miłecki wrote:
> On 18 January 2017 at 09:58, Arend Van Spriel
> <arend.vanspr...@broadcom.com> wrote:
>> On 17-1-2017 17:34, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <ra...@milecki.pl>
>>>
>>> Function brcmf_c_set_joinpref_default is in common.c, so move it to the
>>> related header. All other (touched) ones are in core.c so take them out
>>> of the bus.h.
>>> I just needed to include bus.h to have enum brcmf_bus_state defined.
>>
>> I prefer to keep the bus api in separate include file so please leave
>> those. That leaves the move of brcmf_c_set_joinpref_default(). Please
>> send a v2 and consider it acked by me.
> 
> Oh, I just realized there isn't bus.c! Would that make sense to move
> these functions from core.c to new bus.c then?

I have no strong opinion about it. Right now it seems a bit overzealous,
but I have been considering adding counters/statistics on bus layer so
the amount of code may justify a separate source file.

Regards,
Arend

Re: [PATCH 2/2] brcmfmac: drop brcmf_bus_detach and inline its code

[Arend Van Spriel]

On 17-1-2017 20:23, Rafał Miłecki wrote:
> From: Rafał Miłecki <ra...@milecki.pl>
> 
> Driver used to call brcmf_bus_detach only from one place and it already
> contained a check for drvr not being NULL. We can get rid of this extra
> function, call brcmf_bus_stop directly and simplify the code.
> There also isn't brcmf_bus_attach function which one could expect so it
> looks more consistent this way.

Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index adf8eb1..122c79d 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -1075,16 +1075,6 @@ void brcmf_bus_add_txhdrlen(struct device *dev, uint 
> len)
>   }
>  }
>  
> -static void brcmf_bus_detach(struct brcmf_pub *drvr)
> -{
> - brcmf_dbg(TRACE, "Enter\n");
> -
> - if (drvr) {
> - /* Stop the bus module */
> - brcmf_bus_stop(drvr->bus_if);
> - }
> -}
> -
>  void brcmf_dev_reset(struct device *dev)
>  {
>   struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> @@ -1131,7 +1121,7 @@ void brcmf_detach(struct device *dev)
>  
>   brcmf_fws_deinit(drvr);
>  
> - brcmf_bus_detach(drvr);
> + brcmf_bus_stop(drvr->bus_if);
>  
>   brcmf_proto_detach(drvr);
>  
> 

Re: [PATCH 1/2] brcmfmac: rename brcmf_bus_start function to brcmf_attach_phase2

[Arend Van Spriel]

On 17-1-2017 20:23, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This change intends to make init/attach process easier to follow.
> 
> What driver were doing in brcmf_bus_start wasn't bus specific at all and
> function brcmf_bus_stop wasn't undoing things done there. It seems
> brcmf_detach was actually undoing things done in both: brcmf_attach and
> brcmf_bus_start.
> 
> To me it makes more sense to call these two function in a similar way as
> they both handle some part of attaching process. It also makes
> brcmf_detach more meaningful.

To me this is all bike-shedding and I have two options 1) what's in a
name and let it pass, or 2) explain the naming. Let's try option 2). It
seems your expectation was different because of the name
brcmf_*bus*_start(). The function brcmf_attach() is called by
bus-specific code, ie. sdio, pcie, or usb, to instantiate the common
driver structures and essential common facilities, eg. debugfs, and
brcmf_bus_start() is called by bus-specific code when everything is
ready for use. For PCIe there is nothing between those calls but for
SDIO there are several steps before the party can start, hence the name.

Regards,
Arend

> Signed-off-by: Rafał Miłecki 
> ---
> This patchset is based on top of
> [PATCH 2/2] brcmfmac: move function declarations to proper headers
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c   | 4 ++--
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h   | 4 ++--
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c   | 6 +++---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c   | 6 +++---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c| 6 +++---
>  6 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index 3e15d64..6fb7d12 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -74,7 +74,7 @@ module_param_named(roamoff, brcmf_roamoff, int, S_IRUSR);
>  MODULE_PARM_DESC(roamoff, "Do not use internal roaming engine");
>  
>  #ifdef DEBUG
> -/* always succeed brcmf_bus_start() */
> +/* always succeed brcmf_attach_phase2() */
>  static int brcmf_ignore_probe_fail;
>  module_param_named(ignore_probe_fail, brcmf_ignore_probe_fail, int, 0);
>  MODULE_PARM_DESC(ignore_probe_fail, "always succeed probe for debugging");
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index 9e6f60a..adf8eb1 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -893,7 +893,7 @@ static int brcmf_inet6addr_changed(struct notifier_block 
> *nb,
>  }
>  #endif
>  
> -int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings)
> +int brcmf_attach_phase1(struct device *dev, struct brcmf_mp_device *settings)
>  {
>   struct brcmf_pub *drvr = NULL;
>   int ret = 0;
> @@ -966,7 +966,7 @@ static int brcmf_revinfo_read(struct seq_file *s, void 
> *data)
>   return 0;
>  }
>  
> -int brcmf_bus_start(struct device *dev)
> +int brcmf_attach_phase2(struct device *dev)
>  {
>   int ret = -1;
>   struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> index d92beca..df4189e 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> @@ -226,8 +226,8 @@ void brcmf_rx_event(struct device *dev, struct sk_buff 
> *rxp);
>  void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
>  void brcmf_net_setcarrier(struct brcmf_if *ifp, bool on);
>  /* Indication from bus module regarding presence/insertion of dongle. */
> -int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings);
> -int brcmf_bus_start(struct device *dev);
> +int brcmf_attach_phase1(struct device *dev, struct brcmf_mp_device 
> *settings);
> +int brcmf_attach_phase2(struct device *dev);
>  void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
>  /* Indication from bus module that dongle should be reset */
>  void brcmf_dev_reset(struct device *dev);
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 048027f..bbc3ded 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -1568,11 +1568,11 @@ static int brcmf_pcie_attach_bus(struct 
> brcmf_pciedev_info *devinfo)
>   int ret;
>  
>   /* Attach to the common driver interface */
> - ret = 

Re: [PATCH 2/2] brcmfmac: move function declarations to proper headers

[Arend Van Spriel]

On 17-1-2017 17:34, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Function brcmf_c_set_joinpref_default is in common.c, so move it to the
> related header. All other (touched) ones are in core.c so take them out
> of the bus.h.
> I just needed to include bus.h to have enum brcmf_bus_state defined.

I prefer to keep the bus api in separate include file so please leave
those. That leaves the move of brcmf_c_set_joinpref_default(). Please
send a v2 and consider it acked by me.

> Signed-off-by: Rafał Miłecki 
> ---
>  .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 28 
> --
>  .../wireless/broadcom/brcm80211/brcmfmac/common.h  |  2 ++
>  .../wireless/broadcom/brcm80211/brcmfmac/core.h| 21 +++-
>  3 files changed, 22 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> index b5bb971..58a3de6 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> @@ -214,34 +214,6 @@ int brcmf_bus_get_memdump(struct brcmf_bus *bus, void 
> *data, size_t len)
>   return bus->ops->get_memdump(bus->dev, data, len);
>  }
>  
> -/*
> - * interface functions from common layer
> - */
> -
> -/* Receive frame for delivery to OS.  Callee disposes of rxp. */
> -void brcmf_rx_frame(struct device *dev, struct sk_buff *rxp, bool 
> handle_event);
> -/* Receive async event packet from firmware. Callee disposes of rxp. */
> -void brcmf_rx_event(struct device *dev, struct sk_buff *rxp);
> -
> -/* Indication from bus module regarding presence/insertion of dongle. */
> -int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings);
> -/* Indication from bus module regarding removal/absence of dongle */
> -void brcmf_detach(struct device *dev);
> -/* Indication from bus module that dongle should be reset */
> -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);
> -
> -int brcmf_bus_start(struct device *dev);
> -s32 brcmf_iovar_data_set(struct device *dev, char *name, void *data, u32 
> len);
> -void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
> -
>  #ifdef CONFIG_BRCMFMAC_SDIO
>  void brcmf_sdio_exit(void);
>  void brcmf_sdio_register(void);
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> index bd095ab..a62f8e7 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> @@ -65,6 +65,8 @@ struct brcmf_mp_device {
>   } bus;
>  };
>  
> +void brcmf_c_set_joinpref_default(struct brcmf_if *ifp);
> +
>  struct brcmf_mp_device *brcmf_get_module_param(struct device *dev,
>  enum brcmf_bus_type bus_type,
>  u32 chip, u32 chiprev);
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> index c94dcab..d92beca 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> @@ -22,6 +22,7 @@
>  #define BRCMFMAC_CORE_H
>  
>  #include 
> +#include "bus.h"
>  #include "fweh.h"
>  
>  #define TOE_TX_CSUM_OL   0x0001
> @@ -213,10 +214,28 @@ struct brcmf_if *brcmf_add_if(struct brcmf_pub *drvr, 
> s32 bsscfgidx, s32 ifidx,
>  void brcmf_remove_interface(struct brcmf_if *ifp, bool rtnl_locked);
>  void brcmf_txflowblock_if(struct brcmf_if *ifp,
> enum brcmf_netif_stop_reason reason, bool state);
> +/* Indication from bus module to change flow-control state */
> +void brcmf_txflowblock(struct device *dev, bool state);
>  void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool 
> success);
>  void brcmf_netif_rx(struct brcmf_if *ifp, struct sk_buff *skb);
> +/* Receive frame for delivery to OS.  Callee disposes of rxp. */
> +void brcmf_rx_frame(struct device *dev, struct sk_buff *rxp, bool 
> handle_event);
> +/* Receive async event packet from firmware. Callee disposes of rxp. */
> +void brcmf_rx_event(struct device *dev, struct sk_buff *rxp);
> +/* Notify the bus has transferred the tx packet to firmware */
> +void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
>  void brcmf_net_setcarrier(struct brcmf_if *ifp, bool on);
> -void brcmf_c_set_joinpref_default(struct brcmf_if 

Re: [PATCH 1/2] brcmfmac: drop unneeded function declarations from headers

[Arend Van Spriel]

On 17-1-2017 17:34, Rafał Miłecki wrote:
> From: Rafał Miłecki <ra...@milecki.pl>
> 
> Functions brcmf_c_prec_enq and brcmf_sdio_init don't exist so we
> really don't need their declarations. Function brcmf_parse_tlvs is used
> in cfg80211.c only so make it static and drop from header as well.

brcmf_c_prec_enq has been long gone (3.18 or so). Thanks for the cleanup.

Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h  | 4 
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h | 2 --
>  3 files changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> index e21f760..b5bb971 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> @@ -218,9 +218,6 @@ int brcmf_bus_get_memdump(struct brcmf_bus *bus, void 
> *data, size_t len)
>   * interface functions from common layer
>   */
>  
> -bool brcmf_c_prec_enq(struct device *dev, struct pktq *q, struct sk_buff 
> *pkt,
> -   int prec);
> -
>  /* Receive frame for delivery to OS.  Callee disposes of rxp. */
>  void brcmf_rx_frame(struct device *dev, struct sk_buff *rxp, bool 
> handle_event);
>  /* Receive async event packet from firmware. Callee disposes of rxp. */
> @@ -247,7 +244,6 @@ void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
>  
>  #ifdef CONFIG_BRCMFMAC_SDIO
>  void brcmf_sdio_exit(void);
> -void brcmf_sdio_init(void);
>  void brcmf_sdio_register(void);
>  #endif
>  #ifdef CONFIG_BRCMFMAC_USB
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 729bf33..ec1171c 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -326,7 +326,7 @@ u16 channel_to_chanspec(struct brcmu_d11inf *d11inf,
>   * triples, returning a pointer to the substring whose first element
>   * matches tag
>   */
> -const struct brcmf_tlv *
> +static const struct brcmf_tlv *
>  brcmf_parse_tlvs(const void *buf, int buflen, uint key)
>  {
>   const struct brcmf_tlv *elt = buf;
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
> index 0c9a708..8f19d95 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
> @@ -396,8 +396,6 @@ void brcmf_free_vif(struct brcmf_cfg80211_vif *vif);
>  s32 brcmf_vif_set_mgmt_ie(struct brcmf_cfg80211_vif *vif, s32 pktflag,
> const u8 *vndr_ie_buf, u32 vndr_ie_len);
>  s32 brcmf_vif_clear_mgmt_ies(struct brcmf_cfg80211_vif *vif);
> -const struct brcmf_tlv *
> -brcmf_parse_tlvs(const void *buf, int buflen, uint key);
>  u16 channel_to_chanspec(struct brcmu_d11inf *d11inf,
>   struct ieee80211_channel *ch);
>  bool brcmf_get_vif_state_any(struct brcmf_cfg80211_info *cfg,
> 

[RFC V2 0/5] cfg80211: support multiple scheduled scans

[Arend van Spriel]

After sending out the initial RFC for multiple scheduled scan support [1]
here a series that deal with it all (I hope) so including events and the
driver function call apis. Resending it due to build issue and it was based
on old mac80211-next master revision.

*Now* it does apply to the master branch of the mac80211-next repository.

Arend van Spriel (5):
  nl80211: allow multiple active scheduled scan requests
  nl80211: include request id in scheduled scan event messages
  cfg80211: add request id parameter to .sched_scan_stop() signature
  cfg80211: add request id to cfg80211_sched_scan_results() api
  cfg80211: add request id in cfg80211_sched_scan_stopped{,_rtnl}() api

 drivers/net/wireless/ath/ath6kl/cfg80211.c |   4 +-
 drivers/net/wireless/ath/ath6kl/wmi.c  |   2 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c |  10 +-
 drivers/net/wireless/marvell/mwifiex/cfg80211.c|   8 +-
 drivers/net/wireless/marvell/mwifiex/main.c|   2 +-
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c |   2 +-
 drivers/net/wireless/marvell/mwifiex/sta_event.c   |   2 +-
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   |   2 +-
 include/net/cfg80211.h |  32 +++--
 include/uapi/linux/nl80211.h   |  12 +-
 net/mac80211/cfg.c |   3 +-
 net/mac80211/pm.c  |   2 +-
 net/mac80211/scan.c|   4 +-
 net/mac80211/util.c|   2 +-
 net/wireless/core.c|  31 +++--
 net/wireless/core.h|  11 +-
 net/wireless/nl80211.c |  62 +++---
 net/wireless/nl80211.h |   3 +-
 net/wireless/rdev-ops.h|   8 +-
 net/wireless/scan.c| 135 +++--
 net/wireless/trace.h   |  54 ++---
 21 files changed, 271 insertions(+), 120 deletions(-)

--
1.9.1

[RFC V2 4/5] cfg80211: add request id to cfg80211_sched_scan_results() api

[Arend van Spriel]

Have proper request id filled in the SCHED_SCAN_RESULTS notification
toward user-space by having the driver provide it through the api.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 drivers/net/wireless/ath/ath6kl/wmi.c  |  2 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c |  2 +-
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c |  2 +-
 include/net/cfg80211.h |  4 ++-
 net/mac80211/scan.c|  2 +-
 net/wireless/core.c|  1 -
 net/wireless/core.h|  1 -
 net/wireless/nl80211.c |  2 ++
 net/wireless/scan.c| 30 +++---
 net/wireless/trace.h   | 17 +---
 10 files changed, 37 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c 
b/drivers/net/wireless/ath/ath6kl/wmi.c
index 84a6d12..04df853 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -1082,7 +1082,7 @@ void ath6kl_wmi_sscan_timer(unsigned long ptr)
 {
struct ath6kl_vif *vif = (struct ath6kl_vif *) ptr;
 
-   cfg80211_sched_scan_results(vif->ar->wiphy);
+   cfg80211_sched_scan_results(vif->ar->wiphy, 0);
 }
 
 static int ath6kl_wmi_bssinfo_event_rx(struct wmi *wmi, u8 *datap, int len,
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 8280f19..34d318e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -766,7 +766,7 @@ s32 brcmf_notify_escan_complete(struct brcmf_cfg80211_info 
*cfg,
brcmf_dbg(SCAN, "scheduled scan completed\n");
cfg->internal_escan = false;
if (!aborted)
-   cfg80211_sched_scan_results(cfg_to_wiphy(cfg));
+   cfg80211_sched_scan_results(cfg_to_wiphy(cfg), 0);
} else if (scan_request) {
struct cfg80211_scan_info info = {
.aborted = aborted,
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
index 8548027..12b471f 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
@@ -1201,7 +1201,7 @@ int mwifiex_process_sta_cmdresp(struct mwifiex_private 
*priv, u16 cmdresp_no,
break;
case HostCmd_CMD_802_11_BG_SCAN_QUERY:
ret = mwifiex_ret_802_11_scan(priv, resp);
-   cfg80211_sched_scan_results(priv->wdev.wiphy);
+   cfg80211_sched_scan_results(priv->wdev.wiphy, 0);
mwifiex_dbg(adapter, CMD,
"info: CMD_RESP: BG_SCAN result is ready!\n");
break;
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 0a65cfe..8a635e0 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1702,6 +1702,7 @@ struct cfg80211_sched_scan_request {
struct cfg80211_bss_select_adjust rssi_adjust;
 
/* internal */
+   struct work_struct results_wk;
struct wiphy *wiphy;
struct net_device *dev;
unsigned long scan_start;
@@ -4455,8 +4456,9 @@ void cfg80211_scan_done(struct cfg80211_scan_request 
*request,
  * cfg80211_sched_scan_results - notify that new scan results are available
  *
  * @wiphy: the wiphy which got scheduled scan results
+ * @reqid: identifier for the related scheduled scan request
  */
-void cfg80211_sched_scan_results(struct wiphy *wiphy);
+void cfg80211_sched_scan_results(struct wiphy *wiphy, u64 reqid);
 
 /**
  * cfg80211_sched_scan_stopped - notify that the scheduled scan has stopped
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index faab3c4..3fd8757 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -1219,7 +1219,7 @@ void ieee80211_sched_scan_results(struct ieee80211_hw *hw)
 
trace_api_sched_scan_results(local);
 
-   cfg80211_sched_scan_results(hw->wiphy);
+   cfg80211_sched_scan_results(hw->wiphy, 0);
 }
 EXPORT_SYMBOL(ieee80211_sched_scan_results);
 
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 1f91e85..3ac0f91 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -442,7 +442,6 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, 
int sizeof_priv,
INIT_LIST_HEAD(>bss_list);
INIT_LIST_HEAD(>sched_scan_req_list);
INIT_WORK(>scan_done_wk, __cfg80211_scan_done);
-   INIT_WORK(>sched_

[RFC V2 1/5] nl80211: allow multiple active scheduled scan requests

[Arend van Spriel]

This patch implements the idea to have multiple scheduled scan requests
running concurrently. It mainly illustrates how to deal with the incoming
request from user-space in terms of backward compatibility. In order to
use multiple scheduled scans user-space needs to provide a flag attribute
NL80211_ATTR_SCHED_SCAN_MULTI to indicate support. If not the request is
treated as a legacy scan.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 include/net/cfg80211.h   |  7 
 include/uapi/linux/nl80211.h | 12 +-
 net/wireless/core.c  | 30 +-
 net/wireless/core.h  | 10 -
 net/wireless/nl80211.c   | 37 +++--
 net/wireless/rdev-ops.h  |  2 +-
 net/wireless/scan.c  | 96 
 net/wireless/trace.h | 18 ++---
 8 files changed, 173 insertions(+), 39 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b7aba6e..4b98ff8 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1633,6 +1633,7 @@ struct cfg80211_bss_select_adjust {
 /**
  * struct cfg80211_sched_scan_request - scheduled scan request description
  *
+ * @reqid: identifies this request.
  * @ssids: SSIDs to scan for (passed in the probe_reqs in active scans)
  * @n_ssids: number of SSIDs
  * @n_channels: total number of channels to scan
@@ -1661,6 +1662,7 @@ struct cfg80211_bss_select_adjust {
  * @rcu_head: RCU callback used to free the struct
  * @owner_nlportid: netlink portid of owner (if this should is a request
  * owned by a particular socket)
+ * @list: for keeping list of requests.
  * @delay: delay in seconds to use before starting the first scan
  * cycle.  The driver may ignore this parameter and start
  * immediately (or at any other time), if this feature is not
@@ -1677,6 +1679,7 @@ struct cfg80211_bss_select_adjust {
  * comparisions.
  */
 struct cfg80211_sched_scan_request {
+   u64 reqid;
struct cfg80211_ssid *ssids;
int n_ssids;
u32 n_channels;
@@ -1704,6 +1707,7 @@ struct cfg80211_sched_scan_request {
unsigned long scan_start;
struct rcu_head rcu_head;
u32 owner_nlportid;
+   struct list_head list;
 
/* keep last */
struct ieee80211_channel *channels[0];
@@ -3457,6 +3461,8 @@ struct wiphy_iftype_ext_capab {
  * this variable determines its size
  * @max_scan_ssids: maximum number of SSIDs the device can scan for in
  * any given scan
+ * @max_sched_scan_reqs: maximum number of scheduled scan requests that
+ * the device can run concurrently.
  * @max_sched_scan_ssids: maximum number of SSIDs the device can scan
  * for in any given scheduled scan
  * @max_match_sets: maximum number of match sets the device can handle
@@ -3589,6 +3595,7 @@ struct wiphy {
 
int bss_priv_size;
u8 max_scan_ssids;
+   u8 max_sched_scan_reqs;
u8 max_sched_scan_ssids;
u8 max_match_sets;
u16 max_scan_ie_len;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index c51b40c..961e381 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -351,7 +351,9 @@
  * are used.  Extra IEs can also be passed from the userspace by
  * using the %NL80211_ATTR_IE attribute.  The first cycle of the
  * scheduled scan can be delayed by %NL80211_ATTR_SCHED_SCAN_DELAY
- * is supplied.
+ * is supplied. If the device supports multiple concurrent scheduled
+ * scans, it will allow such when the caller provides the flag attribute
+ * %NL80211_ATTR_SCHED_SCAN_MULTI to indicate user-space support for it.
  * @NL80211_CMD_STOP_SCHED_SCAN: stop a scheduled scan. Returns -ENOENT if
  * scheduled scan is not running. The caller may assume that as soon
  * as the call returns, it is safe to start a new scheduled scan again.
@@ -2000,6 +2002,11 @@ enum nl80211_commands {
  * u32 attribute with an  nl80211_timeout_reason value. This is used,
  * e.g., with %NL80211_CMD_CONNECT event.
  *
+ * @NL80211_ATTR_SCHED_SCAN_MULTI: flag attribute which user-space shall use to
+ * indicate that it supports multiple active scheduled scan requests.
+ * @NL80211_ATTR_SCHED_SCAN_MAX_REQS: indicates maximum number of scheduled
+ * scan request that may be active for the device (u8).
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2411,6 +2418,9 @@ enum nl80211_attrs {
 
NL80211_ATTR_TIMEOUT_REASON,
 
+   NL80211_ATTR_SCHED_SCAN_MULTI,
+   NL80211_ATTR_SCHED_SCAN_MAX_REQS,
+
/* add attributes here, update

[RFC V2 2/5] nl80211: include request id in scheduled scan event messages

[Arend van Spriel]

Include the request id in the event messages so user-space knows
which scan the event relates to.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 net/wireless/nl80211.c | 23 +++
 net/wireless/nl80211.h |  3 +--
 net/wireless/scan.c|  5 ++---
 3 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 411774b..f303f6f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7249,8 +7249,7 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
 
cfg80211_add_sched_scan_req(rdev, sched_scan_req);
 
-   nl80211_send_sched_scan(rdev, dev,
-   NL80211_CMD_START_SCHED_SCAN);
+   nl80211_send_sched_scan(sched_scan_req, NL80211_CMD_START_SCHED_SCAN);
return 0;
 
 out_free:
@@ -12932,18 +12931,19 @@ static int nl80211_prep_scan_msg(struct sk_buff *msg,
 
 static int
 nl80211_prep_sched_scan_msg(struct sk_buff *msg,
-   struct cfg80211_registered_device *rdev,
-   struct net_device *netdev,
-   u32 portid, u32 seq, int flags, u32 cmd)
+   struct cfg80211_sched_scan_request *req, u32 cmd)
 {
void *hdr;
 
-   hdr = nl80211hdr_put(msg, portid, seq, flags, cmd);
+   hdr = nl80211hdr_put(msg, 0, 0, 0, cmd);
if (!hdr)
return -1;
 
-   if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) ||
-   nla_put_u32(msg, NL80211_ATTR_IFINDEX, netdev->ifindex))
+   if (nla_put_u32(msg, NL80211_ATTR_WIPHY,
+   wiphy_to_rdev(req->wiphy)->wiphy_idx) ||
+   nla_put_u32(msg, NL80211_ATTR_IFINDEX, req->dev->ifindex) ||
+   nla_put_u64_64bit(msg, NL80211_ATTR_COOKIE, req->reqid,
+ NL80211_ATTR_PAD))
goto nla_put_failure;
 
genlmsg_end(msg, hdr);
@@ -13003,8 +13003,7 @@ void nl80211_send_scan_msg(struct 
cfg80211_registered_device *rdev,
NL80211_MCGRP_SCAN, GFP_KERNEL);
 }
 
-void nl80211_send_sched_scan(struct cfg80211_registered_device *rdev,
-struct net_device *netdev, u32 cmd)
+void nl80211_send_sched_scan(struct cfg80211_sched_scan_request *req, u32 cmd)
 {
struct sk_buff *msg;
 
@@ -13012,12 +13011,12 @@ void nl80211_send_sched_scan(struct 
cfg80211_registered_device *rdev,
if (!msg)
return;
 
-   if (nl80211_prep_sched_scan_msg(msg, rdev, netdev, 0, 0, 0, cmd) < 0) {
+   if (nl80211_prep_sched_scan_msg(msg, req, cmd) < 0) {
nlmsg_free(msg);
return;
}
 
-   genlmsg_multicast_netns(_fam, wiphy_net(>wiphy), msg, 0,
+   genlmsg_multicast_netns(_fam, wiphy_net(req->wiphy), msg, 0,
NL80211_MCGRP_SCAN, GFP_KERNEL);
 }
 
diff --git a/net/wireless/nl80211.h b/net/wireless/nl80211.h
index e488dca..eb66de6 100644
--- a/net/wireless/nl80211.h
+++ b/net/wireless/nl80211.h
@@ -16,8 +16,7 @@ struct sk_buff *nl80211_build_scan_msg(struct 
cfg80211_registered_device *rdev,
   struct wireless_dev *wdev, bool aborted);
 void nl80211_send_scan_msg(struct cfg80211_registered_device *rdev,
   struct sk_buff *msg);
-void nl80211_send_sched_scan(struct cfg80211_registered_device *rdev,
-struct net_device *netdev, u32 cmd);
+void nl80211_send_sched_scan(struct cfg80211_sched_scan_request *req, u32 cmd);
 void nl80211_common_reg_change_event(enum nl80211_commands cmd_id,
 struct regulatory_request *request);
 
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 6704198..f2b2064 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -379,8 +379,7 @@ void __cfg80211_sched_scan_results(struct work_struct *wk)
spin_unlock_bh(>bss_lock);
request->scan_start = jiffies;
}
-   nl80211_send_sched_scan(rdev, request->dev,
-   NL80211_CMD_SCHED_SCAN_RESULTS);
+   nl80211_send_sched_scan(request, 
NL80211_CMD_SCHED_SCAN_RESULTS);
}
 
rtnl_unlock();
@@ -429,7 +428,7 @@ int cfg80211_stop_sched_scan_req(struct 
cfg80211_registered_device *rdev,
return err;
}
 
-   nl80211_send_sched_scan(rdev, req->dev, NL80211_CMD_SCHED_SCAN_STOPPED);
+   nl80211_send_sched_scan(req, NL80211_CMD_SCHED_SCAN_STOPPED);
 
cfg80211_del_sched_scan_req(rdev, req);
 
-- 
1.9.1

[RFC V2 5/5] cfg80211: add request id in cfg80211_sched_scan_stopped{,_rtnl}() api

[Arend van Spriel]

Allow driver to indicate which scheduled scan request is being aborted
by providing the request id.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 drivers/net/wireless/ath/ath6kl/cfg80211.c  |  2 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c |  2 +-
 drivers/net/wireless/marvell/mwifiex/cfg80211.c |  6 +++---
 drivers/net/wireless/marvell/mwifiex/main.c |  2 +-
 drivers/net/wireless/marvell/mwifiex/sta_event.c|  2 +-
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c|  2 +-
 include/net/cfg80211.h  |  6 --
 net/mac80211/pm.c   |  2 +-
 net/mac80211/scan.c |  2 +-
 net/mac80211/util.c |  2 +-
 net/wireless/scan.c | 10 +-
 net/wireless/trace.h| 17 +++--
 12 files changed, 31 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 1509286..e52aef8 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -170,7 +170,7 @@ static void ath6kl_cfg80211_sscan_disable(struct ath6kl_vif 
*vif)
if (!stopped)
return;
 
-   cfg80211_sched_scan_stopped(ar->wiphy);
+   cfg80211_sched_scan_stopped(ar->wiphy, 0);
 }
 
 static int ath6kl_set_wpa_version(struct ath6kl_vif *vif,
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 34d318e..8c5e54a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3359,7 +3359,7 @@ static int brcmf_start_internal_escan(struct brcmf_if 
*ifp,
goto free_req;
 
 out_err:
-   cfg80211_sched_scan_stopped(wiphy);
+   cfg80211_sched_scan_stopped(wiphy, 0);
 free_req:
kfree(request);
return err;
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 243349476..b5b7741 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2036,7 +2036,7 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy,
struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
 
if (!mwifiex_stop_bg_scan(priv))
-   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
+   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy, 0);
 
if (mwifiex_deauthenticate(priv, NULL))
return -EFAULT;
@@ -2304,7 +2304,7 @@ static int mwifiex_cfg80211_inform_ibss_bss(struct 
mwifiex_private *priv)
(int)sme->ssid_len, (char *)sme->ssid, sme->bssid);
 
if (!mwifiex_stop_bg_scan(priv))
-   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
+   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy, 0);
 
ret = mwifiex_cfg80211_assoc(priv, sme->ssid_len, sme->ssid, sme->bssid,
 priv->bss_mode, sme->channel, sme, 0);
@@ -2513,7 +2513,7 @@ static int mwifiex_set_ibss_params(struct mwifiex_private 
*priv,
priv->scan_block = false;
 
if (!mwifiex_stop_bg_scan(priv))
-   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
+   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy, 0);
 
user_scan_cfg = kzalloc(sizeof(*user_scan_cfg), GFP_KERNEL);
if (!user_scan_cfg)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index e5c3a8a..ff9b767 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -750,7 +750,7 @@ static int mwifiex_init_hw_fw(struct mwifiex_adapter 
*adapter,
mwifiex_dbg(priv->adapter, INFO,
"aborting bgscan on ndo_stop\n");
mwifiex_stop_bg_scan(priv);
-   cfg80211_sched_scan_stopped(priv->wdev.wiphy);
+   cfg80211_sched_scan_stopped(priv->wdev.wiphy, 0);
}
 
return 0;
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c 
b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index 9df0c4d..cce61d8 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -793,7 +793,7 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
 
 

[RFC V2 3/5] cfg80211: add request id parameter to .sched_scan_stop() signature

[Arend van Spriel]

For multiple scheduled scan support the driver needs to know which
scheduled scan request is being stopped. Pass the request id in the
.sched_scan_stop() callback.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 drivers/net/wireless/ath/ath6kl/cfg80211.c|  2 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c   |  6 +++---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c   |  2 +-
 include/net/cfg80211.h| 15 ---
 net/mac80211/cfg.c|  3 ++-
 net/wireless/rdev-ops.h   |  6 +++---
 net/wireless/scan.c   |  2 +-
 net/wireless/trace.h  | 10 +-
 8 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index b7fe0af..1509286 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3354,7 +3354,7 @@ static int ath6kl_cfg80211_sscan_start(struct wiphy 
*wiphy,
 }
 
 static int ath6kl_cfg80211_sscan_stop(struct wiphy *wiphy,
- struct net_device *dev)
+ struct net_device *dev, u64 reqid)
 {
struct ath6kl_vif *vif = netdev_priv(dev);
bool stopped;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..8280f19 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3392,7 +3392,7 @@ static int brcmf_start_internal_escan(struct brcmf_if 
*ifp,
 }
 
 static int brcmf_cfg80211_sched_scan_stop(struct wiphy *wiphy,
- struct net_device *ndev)
+ struct net_device *ndev, u64 reqid)
 {
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
struct brcmf_if *ifp = netdev_priv(ndev);
@@ -3595,7 +3595,7 @@ static s32 brcmf_cfg80211_resume(struct wiphy *wiphy)
  cfg->wowl.pre_pmmode);
cfg->wowl.active = false;
if (cfg->wowl.nd_enabled) {
-   brcmf_cfg80211_sched_scan_stop(cfg->wiphy, ifp->ndev);
+   brcmf_cfg80211_sched_scan_stop(cfg->wiphy, ifp->ndev, 
0);
brcmf_fweh_unregister(cfg->pub, BRCMF_E_PFN_NET_FOUND);
brcmf_fweh_register(cfg->pub, BRCMF_E_PFN_NET_FOUND,
brcmf_notify_sched_scan_results);
@@ -3679,7 +3679,7 @@ static s32 brcmf_cfg80211_suspend(struct wiphy *wiphy,
 
/* Stop scheduled scan */
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_PNO))
-   brcmf_cfg80211_sched_scan_stop(wiphy, ndev);
+   brcmf_cfg80211_sched_scan_stop(wiphy, ndev, 0);
 
/* end any scanning */
if (test_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status))
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 1e3bd43..243349476 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2701,7 +2701,7 @@ static int mwifiex_set_ibss_params(struct mwifiex_private 
*priv,
  * previous bgscan configuration in the firmware
  */
 static int mwifiex_cfg80211_sched_scan_stop(struct wiphy *wiphy,
-   struct net_device *dev)
+   struct net_device *dev, u64 reqid)
 {
struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
 
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 4b98ff8..0a65cfe 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2709,12 +2709,12 @@ struct cfg80211_nan_func {
  * @set_cqm_txe_config: Configure connection quality monitor TX error
  * thresholds.
  * @sched_scan_start: Tell the driver to start a scheduled scan.
- * @sched_scan_stop: Tell the driver to stop an ongoing scheduled scan. This
- * call must stop the scheduled scan and be ready for starting a new one
- * before it returns, i.e. @sched_scan_start may be called immediately
- * after that again and should not fail in that case. The driver should
- * not call cfg80211_sched_scan_stopped() for a requested stop (when this
- * method returns 0.)
+ * @sched_scan_stop: Tell the driver to stop an ongoing scheduled scan with
+ * given request id. This call must stop the scheduled scan and be 

Re: [PATCH] brcmfmac: add support for BCM43455 with modalias sdio:c00v02D0dA9BF

[Arend Van Spriel]

On 16-1-2017 11:17, Martin Blumenstingl wrote:
> BCM43455 is a more recent revision of the BCM4345. Some of the BCM43455
> got a dedicated SDIO device ID which is currently not supported by
> brcmfmac.
> Adding the new sdio_device_id to brcmfmac is enough to get the BCM43455
> supported because the chip itself is already supported (due to BCM4345
> support in the driver).

Hopefully Kalle can take this through his tree, ie. wireless-drivers-next.

Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
> Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
> ---
> This is the proper patch following the (short) discussion from [0]
> 
> [0] https://marc.info/?l=linux-wireless=148455981002310=2
> 
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
>  include/linux/mmc/sdio_ids.h  | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index 72139b579b18..5bc2ba214735 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -1104,6 +1104,7 @@ static const struct sdio_device_id brcmf_sdmmc_ids[] = {
>   BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4339),
>   BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43430),
>   BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4345),
> + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43455),
>   BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4354),
>   BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4356),
>   { /* end: all zeroes */ }
> diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
> index d43ef96bf075..71b113e1223f 100644
> --- a/include/linux/mmc/sdio_ids.h
> +++ b/include/linux/mmc/sdio_ids.h
> @@ -36,6 +36,7 @@
>  #define SDIO_DEVICE_ID_BROADCOM_433620xa962
>  #define SDIO_DEVICE_ID_BROADCOM_434300xa9a6
>  #define SDIO_DEVICE_ID_BROADCOM_4345 0x4345
> +#define SDIO_DEVICE_ID_BROADCOM_434550xa9bf
>  #define SDIO_DEVICE_ID_BROADCOM_4354 0x4354
>  #define SDIO_DEVICE_ID_BROADCOM_4356 0x4356
>  
> 

Re: support for Ampak AP6255 (bcm43455c0 with SDIO device ID 0xa9bf)

[Arend Van Spriel]

On 15-1-2017 0:18, Martin Blumenstingl wrote:
> Hello,
> 
> I recently got a "Khadas VIM Pro" (see [0] for more information)
> The "Pro" version comes with an AP6255 wifi chipset.
> Looking at the vendor firmware this seems to be a bcm43455 device: [1]
> 
> To my surprise brcmfmac from a mainline 4.10-rc3 kernel did not pick
> this device up.
> So I started investigating:
> $ grep "" 
> /sys/class/mmc_host/mmc2/mmc2\:0001/mmc2\:0001\:*/{class,device,vendor}
> /sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:1/class:0x00
> /sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:2/class:0x00
> /sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:3/class:0x02
> /sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:1/device:0xa9bf
> /sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:2/device:0xa9bf
> /sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:3/device:0xa9bf
> /sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:1/vendor:0x02d0
> /sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:2/vendor:0x02d0
> /sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:3/vendor:0x02d0
> 
> I then went ahead and added the device ID to
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c (sample
> patch attached)
> as a result of that the device is now being detected.
> it boots fine with the firmware found in linux-firmware: [2] (plus the
> nvram.txt from the vendor repo [1] renamed to brcmfmac43455-sdio.txt)
> 
> $ cat /sys/kernel/debug/brcmfmac/mmc2\:0001\:1/revinfo
> vendorid: 0x14e4
> deviceid: 0x43ab
> radiorev: 0.88.3.11
> chipnum: 17221 (4345)
> chiprev: 6
> chippkg: 2
> corerev: 54
> boardid: 0x06e4
> boardvendor: 0x14e4
> boardrev: P304
> driverrev: 7.45.18
> ucoderev: 0
> bus: 0
> phytype: 11
> phyrev: 20
> anarev: 0
> nvramrev: 00079ac5
> 
> downloading a random 100MB file from the internet using curl confirms this.
> There are no hangs, connection drops, other devices are also working fine.
> 
> the problem I'm facing is very simply (but unfortunately a very common
> development problem): naming things (the SDIO_DEVICE_ID_BROADCOM_TODO
> constant)!
> there's already a definition for SDIO_DEVICE_ID_BROADCOM_4345 with
> value 0x4345, does that mean 0xa9bf should be
> SDIO_DEVICE_ID_BROADCOM_43455?

Yup. That seems a good name to me.

Regards,
Arend

> Regards,
> Martin
> 
> 
> [0] http://khadas.com/vim/
> [1] 
> https://github.com/khadas/android_hardware_amlogic_wifi/tree/b6709758755568e4a0ff6e80993be0fc64c77fb9/bcm_ampak/config/6255
> [2] 
> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/brcm/brcmfmac43455-sdio.bin?id=b9a38d041d38ac6cf47274e9933f8083e12fc601
> 

Re: linux driver bcm4311 failure

[Arend Van Spriel]

On 14-1-2017 11:15, message wrote:
> On 2017-01-02 20:04, Arend van Spriel wrote:
>> On 02-01-17 15:33, message wrote:
>>> On 2016-12-30 19:46, message wrote:
>>>> On 2016-09-17 08:11, message wrote:
>>>>> On 2016-09-09 07:57, Arend Van Spriel wrote:
>>>>>>
>>>>>> The device is claimed by b43-pci-bridge so I would suggest:
>>>>>>
>>>>>> blacklist b43-pci-bridge
>>>>>>
>>>
>>> The wifi card indicator now appears to start after computer switch on
>>> (twice in a row now!)
>>>
>>> Neither networkmanager or wicd are accepting the password.
>>>
>>> Even:
>>>
>>> wicd-cli --wireless -c [wifihotspotname]
>>> done!
>>>
>>> is false and internet access not found.
>>>
>>> wpa_supplicant continues to report 'conn_failed' error.
>>>
>>> Connection to same network is successful using debian on chromebook
>>> (crouton)
>>
>> I am confused by all your messages. In the previous one you did a
>> 'modprobe b43'. So what driver do you intend to use here. b43 is not a
>> driver maintained by broadcom. You should ask for help on the b43
>> mailing list [1] if you want to use that driver.
>>
>> Regards,
>> Arend
>>
>> [1] http://lists.infradead.org/mailman/listinfo/b43-dev
> 
> After system upgrade, wifi card fails to be recognised.
> 
> For the benefit of other users: save your time and avoid broadcom
> products; they are terrible.

Why sending these types of messages hiding in anonymity without
responding to any of the questions in my email responses. Again what
driver are you using. If it is b43 you want you should not blacklist
b43-pci-bridge. Whether or not b43 supports your device can be found
here [2]. Supposedly it is. If not you might try your luck at the b43
mailing list I gave you in earlier email.

Regards,
Arend

[2] https://wireless.wiki.kernel.org/en/users/drivers/b43#list_of_hardware

Re: [RFC 4/5] cfg80211: add request id to cfg80211_sched_scan_results() api

[Arend Van Spriel]

On 13-1-2017 13:47, Arend van Spriel wrote:
> Have proper request id filled in the SCHED_SCAN_RESULTS notification
> toward user-space by having the driver provide it through the api.
> 
> Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
> Reviewed-by: Franky Lin <franky....@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
> ---
>  drivers/net/wireless/ath/ath6kl/wmi.c  |  2 +-
>  .../broadcom/brcm80211/brcmfmac/cfg80211.c |  2 +-
>  drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c |  2 +-
>  include/net/cfg80211.h |  4 ++-
>  net/mac80211/scan.c|  2 +-
>  net/wireless/core.c|  1 -
>  net/wireless/core.h|  1 -
>  net/wireless/nl80211.c |  2 ++
>  net/wireless/scan.c| 30 
> +++---
>  net/wireless/trace.h   | 17 +---
>  10 files changed, 37 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c 
> b/drivers/net/wireless/ath/ath6kl/wmi.c
> index 84a6d12..04df853 100644
> --- a/drivers/net/wireless/ath/ath6kl/wmi.c
> +++ b/drivers/net/wireless/ath/ath6kl/wmi.c
> @@ -1082,7 +1082,7 @@ void ath6kl_wmi_sscan_timer(unsigned long ptr)
>  {
>   struct ath6kl_vif *vif = (struct ath6kl_vif *) ptr;
>  
> - cfg80211_sched_scan_results(vif->ar->wiphy);
> + cfg80211_sched_scan_results(vif->ar->wiphy, 0);
>  }
>  
>  static int ath6kl_wmi_bssinfo_event_rx(struct wmi *wmi, u8 *datap, int len,
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 8280f19..34d318e 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -766,7 +766,7 @@ s32 brcmf_notify_escan_complete(struct 
> brcmf_cfg80211_info *cfg,
>   brcmf_dbg(SCAN, "scheduled scan completed\n");
>   cfg->internal_escan = false;
>   if (!aborted)
> - cfg80211_sched_scan_results(cfg_to_wiphy(cfg));
> + cfg80211_sched_scan_results(cfg_to_wiphy(cfg), 0);
>   } else if (scan_request) {
>   struct cfg80211_scan_info info = {
>   .aborted = aborted,
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c 
> b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
> index 8548027..12b471f 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
> @@ -1201,7 +1201,7 @@ int mwifiex_process_sta_cmdresp(struct mwifiex_private 
> *priv, u16 cmdresp_no,
>   break;
>   case HostCmd_CMD_802_11_BG_SCAN_QUERY:
>   ret = mwifiex_ret_802_11_scan(priv, resp);
> - cfg80211_sched_scan_results(priv->wdev.wiphy);
> + cfg80211_sched_scan_results(priv->wdev.wiphy, 0);
>   mwifiex_dbg(adapter, CMD,
>   "info: CMD_RESP: BG_SCAN result is ready!\n");
>   break;
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 880a57a..17c78c4 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1677,6 +1677,7 @@ struct cfg80211_sched_scan_request {
>   u8 mac_addr_mask[ETH_ALEN] __aligned(2);
>  
>   /* internal */
> + struct work_struct results_wk;

When this worker is queued I suppose we should avoid the scheduled scan
request to be freed. Probable need cancel_work_sync() in
cfg80211_del_sched_scan_req().

Regards,
Arend

[RFC 1/5] nl80211: allow multiple active scheduled scan requests

[Arend van Spriel]

This patch implements the idea to have multiple scheduled scan requests
running concurrently. It mainly illustrates how to deal with the incoming
request from user-space in terms of backward compatibility. In order to
use multiple scheduled scans user-space needs to provide a flag attribute
NL80211_ATTR_SCHED_SCAN_MULTI to indicate support. If not the request is
treated as a legacy scan.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 include/net/cfg80211.h   |  7 
 include/uapi/linux/nl80211.h | 12 +-
 net/wireless/core.c  | 30 +-
 net/wireless/core.h  | 10 -
 net/wireless/nl80211.c   | 37 +++--
 net/wireless/rdev-ops.h  |  2 +-
 net/wireless/scan.c  | 96 
 net/wireless/trace.h | 18 ++---
 8 files changed, 173 insertions(+), 39 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index cb13789..4c77c82 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1622,6 +1622,7 @@ struct cfg80211_sched_scan_plan {
 /**
  * struct cfg80211_sched_scan_request - scheduled scan request description
  *
+ * @reqid: identifies this request.
  * @ssids: SSIDs to scan for (passed in the probe_reqs in active scans)
  * @n_ssids: number of SSIDs
  * @n_channels: total number of channels to scan
@@ -1650,12 +1651,14 @@ struct cfg80211_sched_scan_plan {
  * @rcu_head: RCU callback used to free the struct
  * @owner_nlportid: netlink portid of owner (if this should is a request
  * owned by a particular socket)
+ * @list: for keeping list of requests.
  * @delay: delay in seconds to use before starting the first scan
  * cycle.  The driver may ignore this parameter and start
  * immediately (or at any other time), if this feature is not
  * supported.
  */
 struct cfg80211_sched_scan_request {
+   u64 reqid;
struct cfg80211_ssid *ssids;
int n_ssids;
u32 n_channels;
@@ -1679,6 +1682,7 @@ struct cfg80211_sched_scan_request {
unsigned long scan_start;
struct rcu_head rcu_head;
u32 owner_nlportid;
+   struct list_head list;
 
/* keep last */
struct ieee80211_channel *channels[0];
@@ -3443,6 +3447,8 @@ struct wiphy_iftype_ext_capab {
  * this variable determines its size
  * @max_scan_ssids: maximum number of SSIDs the device can scan for in
  * any given scan
+ * @max_sched_scan_reqs: maximum number of scheduled scan requests that
+ * the device can run concurrently.
  * @max_sched_scan_ssids: maximum number of SSIDs the device can scan
  * for in any given scheduled scan
  * @max_match_sets: maximum number of match sets the device can handle
@@ -3575,6 +3581,7 @@ struct wiphy {
 
int bss_priv_size;
u8 max_scan_ssids;
+   u8 max_sched_scan_reqs;
u8 max_sched_scan_ssids;
u8 max_match_sets;
u16 max_scan_ie_len;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 174f4b3..70dc5a6 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -351,7 +351,9 @@
  * are used.  Extra IEs can also be passed from the userspace by
  * using the %NL80211_ATTR_IE attribute.  The first cycle of the
  * scheduled scan can be delayed by %NL80211_ATTR_SCHED_SCAN_DELAY
- * is supplied.
+ * is supplied. If the device supports multiple concurrent scheduled
+ * scans, it will allow such when the caller provides the flag attribute
+ * %NL80211_ATTR_SCHED_SCAN_MULTI to indicate user-space support for it.
  * @NL80211_CMD_STOP_SCHED_SCAN: stop a scheduled scan. Returns -ENOENT if
  * scheduled scan is not running. The caller may assume that as soon
  * as the call returns, it is safe to start a new scheduled scan again.
@@ -1982,6 +1984,11 @@ enum nl80211_commands {
  * @NL80211_ATTR_BSSID: The BSSID of the AP. Note that %NL80211_ATTR_MAC is 
also
  * used in various commands/events for specifying the BSSID.
  *
+ * @NL80211_ATTR_SCHED_SCAN_MULTI: flag attribute which user-space shall use to
+ * indicate that it supports multiple active scheduled scan requests.
+ * @NL80211_ATTR_SCHED_SCAN_MAX_REQS: indicates maximum number of scheduled
+ * scan request that may be active for the device (u8).
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2388,6 +2395,9 @@ enum nl80211_attrs {
 
NL80211_ATTR_BSSID,
 
+   NL80211_ATTR_SCHED_SCAN_MULTI,
+   NL80211_ATTR_SCHED_SCAN_MAX_REQS,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
diff --git

[RFC 4/5] cfg80211: add request id to cfg80211_sched_scan_results() api

[Arend van Spriel]

Have proper request id filled in the SCHED_SCAN_RESULTS notification
toward user-space by having the driver provide it through the api.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 drivers/net/wireless/ath/ath6kl/wmi.c  |  2 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c |  2 +-
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c |  2 +-
 include/net/cfg80211.h |  4 ++-
 net/mac80211/scan.c|  2 +-
 net/wireless/core.c|  1 -
 net/wireless/core.h|  1 -
 net/wireless/nl80211.c |  2 ++
 net/wireless/scan.c| 30 +++---
 net/wireless/trace.h   | 17 +---
 10 files changed, 37 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c 
b/drivers/net/wireless/ath/ath6kl/wmi.c
index 84a6d12..04df853 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -1082,7 +1082,7 @@ void ath6kl_wmi_sscan_timer(unsigned long ptr)
 {
struct ath6kl_vif *vif = (struct ath6kl_vif *) ptr;
 
-   cfg80211_sched_scan_results(vif->ar->wiphy);
+   cfg80211_sched_scan_results(vif->ar->wiphy, 0);
 }
 
 static int ath6kl_wmi_bssinfo_event_rx(struct wmi *wmi, u8 *datap, int len,
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 8280f19..34d318e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -766,7 +766,7 @@ s32 brcmf_notify_escan_complete(struct brcmf_cfg80211_info 
*cfg,
brcmf_dbg(SCAN, "scheduled scan completed\n");
cfg->internal_escan = false;
if (!aborted)
-   cfg80211_sched_scan_results(cfg_to_wiphy(cfg));
+   cfg80211_sched_scan_results(cfg_to_wiphy(cfg), 0);
} else if (scan_request) {
struct cfg80211_scan_info info = {
.aborted = aborted,
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
index 8548027..12b471f 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
@@ -1201,7 +1201,7 @@ int mwifiex_process_sta_cmdresp(struct mwifiex_private 
*priv, u16 cmdresp_no,
break;
case HostCmd_CMD_802_11_BG_SCAN_QUERY:
ret = mwifiex_ret_802_11_scan(priv, resp);
-   cfg80211_sched_scan_results(priv->wdev.wiphy);
+   cfg80211_sched_scan_results(priv->wdev.wiphy, 0);
mwifiex_dbg(adapter, CMD,
"info: CMD_RESP: BG_SCAN result is ready!\n");
break;
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 880a57a..17c78c4 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1677,6 +1677,7 @@ struct cfg80211_sched_scan_request {
u8 mac_addr_mask[ETH_ALEN] __aligned(2);
 
/* internal */
+   struct work_struct results_wk;
struct wiphy *wiphy;
struct net_device *dev;
unsigned long scan_start;
@@ -4441,8 +4442,9 @@ void cfg80211_scan_done(struct cfg80211_scan_request 
*request,
  * cfg80211_sched_scan_results - notify that new scan results are available
  *
  * @wiphy: the wiphy which got scheduled scan results
+ * @reqid: identifier for the related scheduled scan request
  */
-void cfg80211_sched_scan_results(struct wiphy *wiphy);
+void cfg80211_sched_scan_results(struct wiphy *wiphy, u64 reqid);
 
 /**
  * cfg80211_sched_scan_stopped - notify that the scheduled scan has stopped
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index faab3c4..3fd8757 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -1219,7 +1219,7 @@ void ieee80211_sched_scan_results(struct ieee80211_hw *hw)
 
trace_api_sched_scan_results(local);
 
-   cfg80211_sched_scan_results(hw->wiphy);
+   cfg80211_sched_scan_results(hw->wiphy, 0);
 }
 EXPORT_SYMBOL(ieee80211_sched_scan_results);
 
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 1f91e85..3ac0f91 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -442,7 +442,6 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, 
int sizeof_priv,
INIT_LIST_HEAD(>bss_list);
INIT_LIST_HEAD(>sched_scan_req_list);
INIT_WORK(>scan_done_wk, __cfg80211_scan_done);
-   INIT_WORK(>sched_scan_results_wk, __cfg802

[RFC 3/5] cfg80211: add request id parameter to .sched_scan_stop() signature

[Arend van Spriel]

For multiple scheduled scan support the driver needs to know which
scheduled scan request is being stopped. Pass the request id in the
.sched_scan_stop() callback.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 drivers/net/wireless/ath/ath6kl/cfg80211.c|  2 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c   |  6 +++---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c   |  2 +-
 include/net/cfg80211.h| 15 ---
 net/mac80211/cfg.c|  3 ++-
 net/wireless/rdev-ops.h   |  6 +++---
 net/wireless/scan.c   |  2 +-
 net/wireless/trace.h  | 10 +-
 8 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index b7fe0af..1509286 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3354,7 +3354,7 @@ static int ath6kl_cfg80211_sscan_start(struct wiphy 
*wiphy,
 }
 
 static int ath6kl_cfg80211_sscan_stop(struct wiphy *wiphy,
- struct net_device *dev)
+ struct net_device *dev, u64 reqid)
 {
struct ath6kl_vif *vif = netdev_priv(dev);
bool stopped;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..8280f19 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3392,7 +3392,7 @@ static int brcmf_start_internal_escan(struct brcmf_if 
*ifp,
 }
 
 static int brcmf_cfg80211_sched_scan_stop(struct wiphy *wiphy,
- struct net_device *ndev)
+ struct net_device *ndev, u64 reqid)
 {
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
struct brcmf_if *ifp = netdev_priv(ndev);
@@ -3595,7 +3595,7 @@ static s32 brcmf_cfg80211_resume(struct wiphy *wiphy)
  cfg->wowl.pre_pmmode);
cfg->wowl.active = false;
if (cfg->wowl.nd_enabled) {
-   brcmf_cfg80211_sched_scan_stop(cfg->wiphy, ifp->ndev);
+   brcmf_cfg80211_sched_scan_stop(cfg->wiphy, ifp->ndev, 
0);
brcmf_fweh_unregister(cfg->pub, BRCMF_E_PFN_NET_FOUND);
brcmf_fweh_register(cfg->pub, BRCMF_E_PFN_NET_FOUND,
brcmf_notify_sched_scan_results);
@@ -3679,7 +3679,7 @@ static s32 brcmf_cfg80211_suspend(struct wiphy *wiphy,
 
/* Stop scheduled scan */
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_PNO))
-   brcmf_cfg80211_sched_scan_stop(wiphy, ndev);
+   brcmf_cfg80211_sched_scan_stop(wiphy, ndev, 0);
 
/* end any scanning */
if (test_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status))
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 1e3bd43..243349476 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2701,7 +2701,7 @@ static int mwifiex_set_ibss_params(struct mwifiex_private 
*priv,
  * previous bgscan configuration in the firmware
  */
 static int mwifiex_cfg80211_sched_scan_stop(struct wiphy *wiphy,
-   struct net_device *dev)
+   struct net_device *dev, u64 reqid)
 {
struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
 
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 4c77c82..880a57a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2695,12 +2695,12 @@ struct cfg80211_nan_func {
  * @set_cqm_txe_config: Configure connection quality monitor TX error
  * thresholds.
  * @sched_scan_start: Tell the driver to start a scheduled scan.
- * @sched_scan_stop: Tell the driver to stop an ongoing scheduled scan. This
- * call must stop the scheduled scan and be ready for starting a new one
- * before it returns, i.e. @sched_scan_start may be called immediately
- * after that again and should not fail in that case. The driver should
- * not call cfg80211_sched_scan_stopped() for a requested stop (when this
- * method returns 0.)
+ * @sched_scan_stop: Tell the driver to stop an ongoing scheduled scan with
+ * given request id. This call must stop the scheduled scan and be 

[RFC 0/5] cfg80211: support multiple scheduled scans

[Arend van Spriel]

After sending out the initial RFC for multiple scheduled scan support [1]
here a series that deal with it all (I hope) so including events and the
driver function call apis.

It is applies to the master branch of the mac80211-next repository.

Arend van Spriel (5):
  nl80211: allow multiple active scheduled scan requests
  nl80211: include request id in scheduled scan event messages
  cfg80211: add request id parameter to .sched_scan_stop() signature
  cfg80211: add request id to cfg80211_sched_scan_results() api
  cfg80211: add request id in cfg80211_sched_scan_stopped{,_rtnl}() api

 drivers/net/wireless/ath/ath6kl/cfg80211.c |   4 +-
 drivers/net/wireless/ath/ath6kl/wmi.c  |   2 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c |  10 +-
 drivers/net/wireless/marvell/mwifiex/cfg80211.c|   8 +-
 drivers/net/wireless/marvell/mwifiex/main.c|   2 +-
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c |   2 +-
 drivers/net/wireless/marvell/mwifiex/sta_event.c   |   2 +-
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   |   2 +-
 include/net/cfg80211.h |  32 +++--
 include/uapi/linux/nl80211.h   |  12 +-
 net/mac80211/cfg.c |   3 +-
 net/mac80211/pm.c  |   2 +-
 net/mac80211/scan.c|   4 +-
 net/mac80211/util.c|   2 +-
 net/wireless/core.c|  31 +++--
 net/wireless/core.h|  11 +-
 net/wireless/nl80211.c |  62 +++---
 net/wireless/nl80211.h |   3 +-
 net/wireless/rdev-ops.h|   8 +-
 net/wireless/scan.c| 135 +++--
 net/wireless/trace.h   |  54 ++---
 21 files changed, 271 insertions(+), 120 deletions(-)

--
1.9.1

[RFC 2/5] nl80211: include request id in scheduled scan event messages

[Arend van Spriel]

Include the request id in the event messages so user-space knows
which scan the event relates to.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 net/wireless/nl80211.c | 23 +++
 net/wireless/nl80211.h |  3 +--
 net/wireless/scan.c|  5 ++---
 3 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 4d1070a..a0cd0e2 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7218,8 +7218,7 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
 
cfg80211_add_sched_scan_req(rdev, sched_scan_req);
 
-   nl80211_send_sched_scan(rdev, dev,
-   NL80211_CMD_START_SCHED_SCAN);
+   nl80211_send_sched_scan(sched_scan_req, NL80211_CMD_START_SCHED_SCAN);
return 0;
 
 out_free:
@@ -12887,18 +12886,19 @@ static int nl80211_prep_scan_msg(struct sk_buff *msg,
 
 static int
 nl80211_prep_sched_scan_msg(struct sk_buff *msg,
-   struct cfg80211_registered_device *rdev,
-   struct net_device *netdev,
-   u32 portid, u32 seq, int flags, u32 cmd)
+   struct cfg80211_sched_scan_request *req, u32 cmd)
 {
void *hdr;
 
-   hdr = nl80211hdr_put(msg, portid, seq, flags, cmd);
+   hdr = nl80211hdr_put(msg, 0, 0, 0, cmd);
if (!hdr)
return -1;
 
-   if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) ||
-   nla_put_u32(msg, NL80211_ATTR_IFINDEX, netdev->ifindex))
+   if (nla_put_u32(msg, NL80211_ATTR_WIPHY,
+   wiphy_to_rdev(req->wiphy)->wiphy_idx) ||
+   nla_put_u32(msg, NL80211_ATTR_IFINDEX, req->dev->ifindex) ||
+   nla_put_u64_64bit(msg, NL80211_ATTR_COOKIE, req->reqid,
+ NL80211_ATTR_PAD))
goto nla_put_failure;
 
genlmsg_end(msg, hdr);
@@ -12958,8 +12958,7 @@ void nl80211_send_scan_msg(struct 
cfg80211_registered_device *rdev,
NL80211_MCGRP_SCAN, GFP_KERNEL);
 }
 
-void nl80211_send_sched_scan(struct cfg80211_registered_device *rdev,
-struct net_device *netdev, u32 cmd)
+void nl80211_send_sched_scan(struct cfg80211_sched_scan_request *req, u32 cmd)
 {
struct sk_buff *msg;
 
@@ -12967,12 +12966,12 @@ void nl80211_send_sched_scan(struct 
cfg80211_registered_device *rdev,
if (!msg)
return;
 
-   if (nl80211_prep_sched_scan_msg(msg, rdev, netdev, 0, 0, 0, cmd) < 0) {
+   if (nl80211_prep_sched_scan_msg(msg, req, cmd) < 0) {
nlmsg_free(msg);
return;
}
 
-   genlmsg_multicast_netns(_fam, wiphy_net(>wiphy), msg, 0,
+   genlmsg_multicast_netns(_fam, wiphy_net(req->wiphy), msg, 0,
NL80211_MCGRP_SCAN, GFP_KERNEL);
 }
 
diff --git a/net/wireless/nl80211.h b/net/wireless/nl80211.h
index 75f8252..33d4a0a 100644
--- a/net/wireless/nl80211.h
+++ b/net/wireless/nl80211.h
@@ -16,8 +16,7 @@ struct sk_buff *nl80211_build_scan_msg(struct 
cfg80211_registered_device *rdev,
   struct wireless_dev *wdev, bool aborted);
 void nl80211_send_scan_msg(struct cfg80211_registered_device *rdev,
   struct sk_buff *msg);
-void nl80211_send_sched_scan(struct cfg80211_registered_device *rdev,
-struct net_device *netdev, u32 cmd);
+void nl80211_send_sched_scan(struct cfg80211_sched_scan_request *req, u32 cmd);
 void nl80211_common_reg_change_event(enum nl80211_commands cmd_id,
 struct regulatory_request *request);
 
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 6704198..f2b2064 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -379,8 +379,7 @@ void __cfg80211_sched_scan_results(struct work_struct *wk)
spin_unlock_bh(>bss_lock);
request->scan_start = jiffies;
}
-   nl80211_send_sched_scan(rdev, request->dev,
-   NL80211_CMD_SCHED_SCAN_RESULTS);
+   nl80211_send_sched_scan(request, 
NL80211_CMD_SCHED_SCAN_RESULTS);
}
 
rtnl_unlock();
@@ -429,7 +428,7 @@ int cfg80211_stop_sched_scan_req(struct 
cfg80211_registered_device *rdev,
return err;
}
 
-   nl80211_send_sched_scan(rdev, req->dev, NL80211_CMD_SCHED_SCAN_STOPPED);
+   nl80211_send_sched_scan(req, NL80211_CMD_SCHED_SCAN_STOPPED);
 
cfg80211_del_sched_scan_req(rdev, req);
 
-- 
1.9.1

[RFC 5/5] cfg80211: add request id in cfg80211_sched_scan_stopped{,_rtnl}() api

[Arend van Spriel]

Allow driver to indicate which scheduled scan request is being aborted
by providing the request id.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 drivers/net/wireless/ath/ath6kl/cfg80211.c |  2 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c |  2 +-
 drivers/net/wireless/marvell/mwifiex/cfg80211.c|  6 ++---
 drivers/net/wireless/marvell/mwifiex/main.c|  2 +-
 drivers/net/wireless/marvell/mwifiex/sta_event.c   |  2 +-
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   |  2 +-
 include/net/cfg80211.h |  6 +++--
 net/mac80211/pm.c  |  2 +-
 net/mac80211/scan.c|  2 +-
 net/mac80211/util.c|  2 +-
 net/wireless/scan.c| 10 
 net/wireless/trace.h   | 27 +-
 12 files changed, 36 insertions(+), 29 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 1509286..e52aef8 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -170,7 +170,7 @@ static void ath6kl_cfg80211_sscan_disable(struct ath6kl_vif 
*vif)
if (!stopped)
return;
 
-   cfg80211_sched_scan_stopped(ar->wiphy);
+   cfg80211_sched_scan_stopped(ar->wiphy, 0);
 }
 
 static int ath6kl_set_wpa_version(struct ath6kl_vif *vif,
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 34d318e..8c5e54a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3359,7 +3359,7 @@ static int brcmf_start_internal_escan(struct brcmf_if 
*ifp,
goto free_req;
 
 out_err:
-   cfg80211_sched_scan_stopped(wiphy);
+   cfg80211_sched_scan_stopped(wiphy, 0);
 free_req:
kfree(request);
return err;
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 243349476..b5b7741 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2036,7 +2036,7 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy,
struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
 
if (!mwifiex_stop_bg_scan(priv))
-   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
+   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy, 0);
 
if (mwifiex_deauthenticate(priv, NULL))
return -EFAULT;
@@ -2304,7 +2304,7 @@ static int mwifiex_cfg80211_inform_ibss_bss(struct 
mwifiex_private *priv)
(int)sme->ssid_len, (char *)sme->ssid, sme->bssid);
 
if (!mwifiex_stop_bg_scan(priv))
-   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
+   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy, 0);
 
ret = mwifiex_cfg80211_assoc(priv, sme->ssid_len, sme->ssid, sme->bssid,
 priv->bss_mode, sme->channel, sme, 0);
@@ -2513,7 +2513,7 @@ static int mwifiex_set_ibss_params(struct mwifiex_private 
*priv,
priv->scan_block = false;
 
if (!mwifiex_stop_bg_scan(priv))
-   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
+   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy, 0);
 
user_scan_cfg = kzalloc(sizeof(*user_scan_cfg), GFP_KERNEL);
if (!user_scan_cfg)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index e5c3a8a..ff9b767 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -750,7 +750,7 @@ static int mwifiex_init_hw_fw(struct mwifiex_adapter 
*adapter,
mwifiex_dbg(priv->adapter, INFO,
"aborting bgscan on ndo_stop\n");
mwifiex_stop_bg_scan(priv);
-   cfg80211_sched_scan_stopped(priv->wdev.wiphy);
+   cfg80211_sched_scan_stopped(priv->wdev.wiphy, 0);
}
 
return 0;
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c 
b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index 9df0c4d..cce61d8 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -793,7 +793,7 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
 
case EVENT_BG_SCAN_STOPPED:
dev_dbg(adapt

Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout

[Arend Van Spriel]

On 9-1-2017 18:53, Jouni Malinen wrote:
> From: Purushottam Kushwaha 
> 
> This enhances the connect timeout API to also carry the reason for the
> timeout. These reason codes for the connect time out are represented by
> enum nl80211_timeout_reason and are passed to user space through a new
> attribute NL80211_ATTR_TIMEOUT_REASON (u32).
> 
> Signed-off-by: Purushottam Kushwaha 
> Signed-off-by: Jouni Malinen 
> ---

[...]

> diff --git a/net/wireless/sme.c b/net/wireless/sme.c
> index 4669391..472225d 100644
> --- a/net/wireless/sme.c
> +++ b/net/wireless/sme.c
> @@ -38,6 +38,7 @@ struct cfg80211_conn {
>   CFG80211_CONN_ASSOCIATE_NEXT,
>   CFG80211_CONN_ASSOCIATING,
>   CFG80211_CONN_ASSOC_FAILED,
> + CFG80211_CONN_ASSOC_FAILED_TIMEOUT,

Was kinda expecting AUTH_FAILED_TIMEOUT

>   CFG80211_CONN_DEAUTH,
>   CFG80211_CONN_ABANDON,
>   CFG80211_CONN_CONNECTED,
> @@ -140,7 +141,8 @@ static int cfg80211_conn_scan(struct wireless_dev *wdev)
>   return err;
>  }
>  
> -static int cfg80211_conn_do_work(struct wireless_dev *wdev)
> +static int cfg80211_conn_do_work(struct wireless_dev *wdev,
> +  enum nl80211_timeout_reason *treason)
>  {
>   struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy);
>   struct cfg80211_connect_params *params;
> @@ -172,6 +174,7 @@ static int cfg80211_conn_do_work(struct wireless_dev 
> *wdev)
> params->key, params->key_len,
> params->key_idx, NULL, 0);
>   case CFG80211_CONN_AUTH_FAILED:
> + *treason = NL80211_TIMEOUT_AUTH;

... but it seems AUTH failure always is a timeout?

Regards,
Arend

Re: [PATCH v3 1/3] cfg80211: Add support to sched scan to report better BSSs

[Arend Van Spriel]

On 9-1-2017 18:53, Jouni Malinen wrote:
> From: vamsi krishna 
> 
> Enhance sched scan to support option of finding a better BSS while in
> connected state. Firmware scans the medium and reports when it finds a
> known BSS which has better RSSI than the current connected BSS. New
> attributes to specify the relative RSSI (compared to the current BSS)
> are added to the sched scan to implement this.
> 
> Signed-off-by: vamsi krishna 
> Signed-off-by: Jouni Malinen 
> ---
>  include/net/cfg80211.h   | 36 ++--
>  include/uapi/linux/nl80211.h | 29 ++
>  net/wireless/nl80211.c   | 49 
> ++--
>  3 files changed, 101 insertions(+), 13 deletions(-)
> 
> v3:
> - use struct cfg80211_bss_select_adjust as the data structure for
>   specifying band preference (instead of attr hardcoded for 5 GHz)
> - add relative_rssi_set boolean to have a robust mechanism for
>   determining whether the NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI
>   attribute was included
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index cb13789..9dc11d3 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1620,6 +1620,17 @@ struct cfg80211_sched_scan_plan {
>  };
>  
>  /**
> + * struct cfg80211_bss_select_adjust - BSS selection with RSSI adjustment.
> + *
> + * @band: band of BSS which should match for RSSI level adjustment.
> + * @delta: value of RSSI level adjustment.
> + */
> +struct cfg80211_bss_select_adjust {
> + enum nl80211_band band;
> + s8 delta;
> +};
> +
> +/**
>   * struct cfg80211_sched_scan_request - scheduled scan request description
>   *
>   * @ssids: SSIDs to scan for (passed in the probe_reqs in active scans)
> @@ -1654,6 +1665,16 @@ struct cfg80211_sched_scan_plan {
>   *   cycle.  The driver may ignore this parameter and start
>   *   immediately (or at any other time), if this feature is not
>   *   supported.
> + * @relative_rssi_set: Indicates whether @relative_rssi is set or not.

So you see a use-case for doing a scan with @relative_rssi being zero,
right?

> + * @relative_rssi: Relative RSSI threshold in dB to restrict scan result
> + *   reporting in connected state to cases where a matching BSS is determined
> + *   to have better RSSI than the current connected BSS. The relative RSSI
> + *   threshold values are ignored in disconnected state.

The description says "better RSSI" so I suppose it could be typed as u8.
The last sentence is intended driver behavior

> + * @rssi_adjust: delta dB of RSSI preference to be given to the BSSs that 
> belong
> + *   to the specified band while deciding whether a better BSS is reported
> + *   using @relative_rssi. If delta is a negative number, the BSSs that
> + *   belong to the specified band will be penalized by delta dB in relative
> + *   comparisions.
>   */
>  struct cfg80211_sched_scan_request {
>   struct cfg80211_ssid *ssids;
> @@ -1673,6 +1694,10 @@ struct cfg80211_sched_scan_request {
>   u8 mac_addr[ETH_ALEN] __aligned(2);
>   u8 mac_addr_mask[ETH_ALEN] __aligned(2);
>  
> + bool relative_rssi_set;
> + s8 relative_rssi;
> + struct cfg80211_bss_select_adjust rssi_adjust;
> +
>   /* internal */
>   struct wiphy *wiphy;
>   struct net_device *dev;
> @@ -1981,17 +2006,6 @@ struct cfg80211_ibss_params {
>  };
>  
>  /**
> - * struct cfg80211_bss_select_adjust - BSS selection with RSSI adjustment.
> - *
> - * @band: band of BSS which should match for RSSI level adjustment.
> - * @delta: value of RSSI level adjustment.
> - */
> -struct cfg80211_bss_select_adjust {
> - enum nl80211_band band;
> - s8 delta;
> -};
> -
> -/**
>   * struct cfg80211_bss_selection - connection parameters for BSS selection.
>   *
>   * @behaviour: requested BSS selection behaviour.
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 174f4b3..4e8bf28 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -1982,6 +1982,19 @@ enum nl80211_commands {
>   * @NL80211_ATTR_BSSID: The BSSID of the AP. Note that %NL80211_ATTR_MAC is 
> also
>   *   used in various commands/events for specifying the BSSID.
>   *
> + * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI: Relative RSSI threshold by which
> + *   other BSSs has to be better than the current connected BSS so that they
> + *   get reported to user space. This will give an opportunity to userspace
> + *   to consider connecting to other matching BSSs which have better RSSI
> + *   than the current connected BSS by using an offloaded operation to avoid
> + *   unnecessary wakeups.
> + *
> + * @NL80211_ATTR_SCHED_SCAN_RSSI_ADJUST: When present the RSSI level for 
> BSSs in
> + *   the specified band is to be adjusted before doing
> + *   %NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI based comparision to figure out
> + *   better BSSs. The 

Re: [PATCH] cfg80211: size various nl80211 messages correctly

[Arend Van Spriel]

On 9-1-2017 11:10, Johannes Berg wrote:
> From: Johannes Berg 
> 
> Ilan reported that sometimes nl80211 messages weren't working if
> the frames being transported got very large, which was really a
> problem for userspace-to-kernel messages, but prompted me to look
> at the code.
> 
> Upon review, I found various places where variable-length data is
> transported in an nl80211 message but the message isn't allocated
> taking that into account. This shouldn't cause any problems since
> the frames aren't really that long, apart in one place where two
> (possibly very long frames) might not fit.
> 
> Fix all the places (that I found) that get variable length data
> from the driver and put it into a message to take the length of
> the variable data into account. The 100 there is just a safe
> constant for the remaining message overhead (it's usually around
> 50 for most messages.)
> 
> Signed-off-by: Johannes Berg 
> ---
>  net/wireless/nl80211.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 23692658fe98..f55b251e4b0d 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -13249,7 +13249,7 @@ void nl80211_send_disconnected(struct 
> cfg80211_registered_device *rdev,
>   struct sk_buff *msg;
>   void *hdr;
>  
> - msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> + msg = nlmsg_new(100 + ie_len, GFP_KERNEL);

Don't you want the '100' to be a define?

Regards,
Arend

Re: [PATCH] RFC: Universal scan proposal

[Arend Van Spriel]

On 9-1-2017 11:48, Johannes Berg wrote:
> On Thu, 2017-01-05 at 20:59 +0100, Arend Van Spriel wrote:
>>
>> From what Dmitry listed I guess there's really only one.
> 
> Ok. I guess I need to go back to that then.
> 
>> Early on in the thread Luca gave some other examples of scan
>> extensions so may need to consider notification/dump methods that are
>> extensible. It seems awkward to have a single "initiate" command and
>> a couple of "notification/retrieval" commands. It may not be so bad
>> as long as it is clear which retrieval command goes with a
>> notification.
> 
> Well, we might not even need different commands. We need different
> storage internally, but if you request the results for a given scan ID
> then you might get a totally different result format? Though that
> wouldn't lend itself well to query "everything you have" which is also
> useful. But even then, it could be done by passing the appropriate
> "report type" attribute to the dump command - we need that anyway for
> trigger.

True. With "report type" attribute you do not mean the actual
report_type thing, right. Hopefully you mean the parameter attribute
that implicitly relates to a "report type". The risk here is that it
requires careful description of what user-space needs to look for if it
gets a notification. I think having separate notification/retrieval
commands lowers the risk of misinterpretation.

> I think with that discussion we're getting ahead of ourselves though -
> do we really know that we just need the two result types
> 
>  * full, and
>  * partial (for history scan)
> 
> and have we even defined the attributes we want in the partial one?

Not sure if we're getting ahead of ourselves. Yes, we have to determine
attributes for each scan "report type", but it is not a prerequisite for
the other topic. I guess to answer the question about the partial
results attributes we need to know what the possible higher-level
use-cases are. Other source of information would be to look what is done
for g-scan in Android "M" or "N", but not sure if that is best approach
as we may not consider all use-cases.

Regards,
Arend

Re: [PATCH] RFC: Universal scan proposal

[Arend Van Spriel]

On 9-1-2017 11:45, Johannes Berg wrote:
> On Thu, 2017-01-05 at 12:45 -0800, Dmitry Shmidt wrote:
>>
>>> Oh, then again, maybe you're thinking of full-MAC devices - does a
>>> roam/autojoin scan really already *imply* a new connection? And if
>>> so, do we have to do it that way, or can we remove that type of
>>> action and make a connection decision in higher layers, so it's
>>> really the same as "report when suitable results are found"?
>>
>> We need to consider case when FW may do some actions like connection
>> during roaming/autojoin.
> 
> Ok. I was unsure if that was happening. So you're saying that the scan
> parameters are determined by the host, and the scan is triggered from
> there, but the action (like roaming) is taken by the firmware?
> 
> How does that differ to
> 
>  1) the scan being started by the firmware, possibly based on the BSS
> selection configuration Arend added?

Currently, the BSS selection configuration is used in CMD_CONNECT. It
can probably be used for scanning as well. The presence of the attribute
would indicate the scan may result in a roam or connect event.

>  2) the scan result being reported to the host, and BSS selection done
> there?

Not sure if we need to consider this one, do we?

>> It depends how we want to make it flexible. For example we
>> may allow to FW to report even usual scan results not one by one
>> but as a chunk.
> 
> Firmware can do that, but is there any point in doing that in the
> cfg80211 API? If it properly has full results, the driver can always
> unbundle them and call the report function for each BSS and everything
> should work just fine, no?

Agree.

>>> There's a bit more complication wrt. the level of detail in results
>>> though - sometimes the result may include all IEs (normal/sched
>>> scan), sometimes it may not ("history scan") - are we sure we
>>> really only need one new get_scan_results()?
>>
>> Maybe not - it is possible I missed something. 
> 
> I was hoping you could clarify the requirements :-)
> 
>> Also looking at our
>> conversation I think we should consider separate command pair
>> for history scan.
> 
> Perhaps, yes. Although perhaps having it triggered through the same
> (new or extended) command, but results reported depending on the
> "report type" would make sense. I think we need to clarify the exact
> requirements before we make that call.

Leaning towards single initiate command and a notification and results
command per "report type".

Regards,
Arend

Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits

[Arend Van Spriel]

On 9-1-2017 9:58, Johannes Berg wrote:
> On Sat, 2017-01-07 at 13:58 +0100, Rafał Miłecki wrote:
> 
>>> I indeed prefer to talk about the driver instead of we. Indeed it
>>> is true due to the orig_flags behavior although that only seems to
>>> involve regulatory code. Could it be that brcmfmac undo that
>>> through the notifier?
>>
>> I guess you could touch orig_flags, but I don't know if it's
>> preferred way. This is probably question to Johannes & cfg80211 guys.
> 
> Right now - before the OF patch - there can't really be any orig_flags
> with DISABLED since the driver doesn't set flags to DISABLED before
> registering, does it? While registering, flags are copied to orig_flags
> so the driver can register with flags like DFS or NO_IR already enabled
> - say the firmware requires that - and they will never be overwritten
> by cfg80211.

Actually, in brcmfmac we do set channels to DISABLED before registering.
I was blissfully unaware of the orig_flags when I added the channel
setup in our probe sequence.

> Arguably, what the driver does today - before OF - isn't incorrect
> either, since it simply doesn't care about anything it registered with
> at all.

Given the statement above I think brcmfmac is incorrect.

> However, with the OF, I argued (succesfully it seems :P) that the
> sensible thing to do was to register with the DISABLED flag and thereby
> "permanently" disable the channels that OF didn't think were usable,
> but in this case now the driver has to adhere to the cfg80211 logic of
> preserving orig_flags forever.

By adhere you mean we should not enable channes for which orig_flags
indicate DISABLED?

Regards,
Arend

Re: [PATCH 2/2] brcmfmac: setup wiphy bands after registering it first

[Arend Van Spriel]

On 7-1-2017 21:36, Rafał Miłecki wrote:
> From: Rafał Miłecki <ra...@milecki.pl>
> 
> During bands setup we disable all channels that firmware doesn't support
> in the current regulatory setup. If we do this before wiphy_register
> it will result in copying set flags (including IEEE80211_CHAN_DISABLED)
> to the orig_flags which is supposed to be persistent. We don't want this
> as regulatory change may result in enabling some channels. We shouldn't
> mess with orig_flags then (by changing them or ignoring them) so it's
> better to just take care of their proper values.
> 
> This patch cleanups code a bit (by taking orig_flags more seriously) and
> allows further improvements like disabling really unavailable channels.
> We will need that e.g. if some frequencies should be disabled for good
> due to hardware setup (design).

I think this and previous patch are too dependent and prefer to have
them in a single patch. Despite that for both:

Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 45ee5b6..729bf33 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -6477,8 +6477,7 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, 
> struct brcmf_if *ifp)
>   wiphy->bands[NL80211_BAND_5GHZ] = band;
>   }
>   }
> - err = brcmf_setup_wiphybands(wiphy);
> - return err;
> + return 0;
>  }
>  
>  static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg)
> @@ -6843,6 +6842,12 @@ struct brcmf_cfg80211_info 
> *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
>   goto priv_out;
>   }
>  
> + err = brcmf_setup_wiphybands(wiphy);
> + if (err) {
> + brcmf_err("Setting wiphy bands failed (%d)\n", err);
> + goto wiphy_unreg_out;
> + }
> +
>   /* If cfg80211 didn't disable 40MHz HT CAP in wiphy_register(),
>* setup 40MHz in 2GHz band and enable OBSS scanning.
>*/
> 

Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits

[Arend Van Spriel]

On 5-1-2017 11:02, Rafał Miłecki wrote:
> On 5 January 2017 at 10:31, Arend Van Spriel
> <arend.vanspr...@broadcom.com> wrote:
>> On 4-1-2017 22:19, Rafał Miłecki wrote:
>>> On 4 January 2017 at 21:07, Arend Van Spriel
>>> <arend.vanspr...@broadcom.com> wrote:
>>>> On 4-1-2017 18:58, Rafał Miłecki wrote:
>>>>> From: Rafał Miłecki <ra...@milecki.pl>
>>>>>
>>>>> There are some devices (e.g. Netgear R8000 home router) with one chipset
>>>>> model used for different radios, some of them limited to subbands. NVRAM
>>>>> entries don't contain any extra info on such limitations and firmware
>>>>> reports full list of channels to us. We need to store extra limitation
>>>>> info in DT to support such devices properly.
>>>>>
>>>>> Now there is a cfg80211 helper for reading such info use it in brcmfmac.
>>>>> This patch adds check for channel being disabled with orig_flags which
>>>>> is how this wiphy helper and wiphy_register work.
>>>>>
>>>>> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
>>>>> ---
>>>>> This patch should probably go through wireless-driver-next which is why
>>>>> it got weird number 4/3. I'm sending it just as a proof of concept.
>>>>> It was succesfully tested on SmartRG SR400ac with BCM43602.
>>>>>
>>>>> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
>>>>> V5: Update commit message
>>>>> V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to make 
>>>>> it work
>>>>> with helper setting "flags" instead of "orig_flags".
>>>>> ---
>>>>>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 -
>>>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
>>>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> index ccae3bb..a008ba5 100644
>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>>> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct 
>>>>> brcmf_cfg80211_info *cfg,
>>>>>  band->band);
>>>>>   channel[index].hw_value = ch.control_ch_num;
>>>>>
>>>>> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
>>>>> + continue;
>>>>> +
>>>>
>>>> So to be clear this is still needed for subsequent calls to
>>>> brcmf_setup_wiphybands(). The subsequent calls are done from the
>>>> regulatory notifier. So I think we have an issue with this approach. Say
>>>> the device comes up with US. That would set DISABLED flags for channels
>>>> 12 to 14. With a country update to PL we would want to enable channels
>>>> 12 and 13, right? The orig_flags are copied from the initial flags
>>>> during wiphy_register() so it seems we will skip enabling 12 and 13. I
>>>> think we should remove the check above and call
>>>> wiphy_read_of_freq_limits() as a last step within
>>>> brcmf_setup_wiphybands(). It means it is called every time, but it
>>>> safeguards that the limits in DT are always applied.
>>>
>>> I'm not exactly happy with channels management in brcmfmac. Before
>>> calling wiphy_register it already disables channels unavailable for
>>> current country. This results in setting IEEE80211_CHAN_DISABLED in
>>
>> What do you mean by current country. There is none that we are aware off
>> in the driver. So we obtain the channels for the current
>> country/revision in the firmware and enable those before
>> wiphy_register(). This all is within the probe/init sequence so I do not
>> really see an issue. As the wiphy object is not yet registered there is
>> no user-space awareness
> 
> It seems I'm terrible as describing my patches/problems/ideas :( Here
> I used 1 inaccurate word and you couldn't understand my point.

Well. Because of our track record of miscommunication and other
annoyances I want to be sure this time :-p

> By "current country" I meant current region (and so a set of
> regulatory rules) used by the firmware. I believe firmware descr

Re: [PATCH] brcmfmac: check if we can support used firmware API version

[Arend Van Spriel]

On 5-1-2017 11:06, Rafał Miłecki wrote:
> On 5 January 2017 at 10:50, Arend Van Spriel
> <arend.vanspr...@broadcom.com> wrote:
>> On 3-1-2017 17:11, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <ra...@milecki.pl>
>>>
>>> Every new firmware API will most likely require changes in our code to
>>> support it. Right now we support 2 versions only. Refuse to init if we
>>> detect newer version.
>>>
>>> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
>>> ---
>>> Hi Arend,
>>>
>>> I think you were concerned about possible firmware API changes. Please
>>> review this patch, I hope it's a proper check for running unsupported
>>> firmware version which could result in broken communication between host
>>> driver and a device.
>>> ---
>>>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> index 0babfc7..c69ae84 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> @@ -6816,6 +6816,11 @@ struct brcmf_cfg80211_info 
>>> *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
>>>   brcmf_err("Failed to get D11 version (%d)\n", err);
>>>   goto priv_out;
>>>   }
>>> + if (io_type > BRCMU_D11AC_IOTYPE) {
>>> + brcmf_err("Unsupported IO version %d\n", io_type);
>>> + goto priv_out;
>>> + }
>>
>> I prefer to have this in brcmu_d11_attach() and have it return an error.
> 
> My too, but since you made brcmu_d11_attach part of *utils* and new IO
> version support may require driver changes, I didn't want to mess
> these two.
> 
> If it was up to me, I would keep brcmu_d11_attach in brcmfmac code and
> then add a proper check in this function indeed.
> 
> Is there any reason you made brcmu_d11_attach part of utils?

The plan was/is to add 11ac support in brcmsmac so it would need the
brcmu_d11_*() functions.

Regards,
Arend

Re: [PATCH] RFC: Universal scan proposal

[Arend Van Spriel]

On 5-1-2017 14:44, Johannes Berg wrote:
> On Thu, 2017-01-05 at 14:39 +0100, Arend Van Spriel wrote:
> 
>> Today we already have roaming offload, right? 
> 
> I guess - you defined the BSS selection stuff for it :)

Well I was referring to:
 3047 WIPHY_FLAG_SUPPORTS_FW_ROAM = BIT(13),

>> Roaming scan would indeed
>> be the same if roaming offload is not used unless you would want
>> cfg80211 to make the decision, but then I would expect parameters for
>> making that decision in the request. Same/similar for autojoin.
> 
> Right.
> 
>>> Actually I think I'm just misinterpreting your wording - you mean
>>> that we can use the different final actions for the different scan
>>> types, not that we should actually say - in driver/firmware/... -
>>> "this is a history scan because the action is to report buffer
>>> full", right?
>>
>> Do we care? The scan engine in our firmware does have use a scan type
>> concept, but that is hidden by the firmware api. I guess your point
>> would be that if user-space would prefer scan types and
>> driver/firmware uses that as well, we might do the same in
>> cfg80211/mac80211. How can we assure the scan types we come up with
>> match those employed in any and all wireless devices/firmwares.
> 
> To be clear: I *don't* like having scan types in the APIs. I think it
> muddies the waters and makes it less likely people will implement it
> precisely as requested, because they'll argue "this is only for roam,
> we'll implement our own magic there" etc.

To be clear: me neither ;-) On the same page here.

>> As Johannes points out it needs to be clear to user-space what its
>> next step should be in obtaining results. Does it make sense to have
>> a separate notification for the history scan results (not calling it
>> that of course :-p ) triggered by the action "Report when buffer is
>> full / almost full" or should user-space determine what to do based
>> on request id that would be included in the (scheduled) scan results
>> notification.
> 
> Yeah, that's a good question - based on the current behaviours etc. I
> was assuming it'd be a new notification/result type.

fair enough.

>>> There's a bit more complication wrt. the level of detail in results
>>> though - sometimes the result may include all IEs (normal/sched
>>> scan),
>>> sometimes it may not ("history scan") - are we sure we really only
>>> need
>>> one new get_scan_results()?
>>
>> So could the "all IEs" case not be handled by the existing BSS
>> storage? Is it still our intention to handle normal scan (no interval
>> provided?) as well in the universal scan approach.
> 
> Yes, the "all IEs" (essentially "all information") case is handled by
> the existing storage/dump methods/etc. but obviously the other cases
> can't be - so my question was if there's really only one more other
> case, or if we might have more new cases - or something that's flexible
> wrt. the data we get?

>From what Dmitry listed I guess there's really only one. Early on in the
thread Luca gave some other examples of scan extensions so may need to
consider notification/dump methods that are extensible. It seems awkward
to have a single "initiate" command and a couple of
"notification/retrieval" commands. It may not be so bad as long as it is
clear which retrieval command goes with a notification.

Regards,
Arend

Re: [PATCH] RFC: Universal scan proposal

[Arend Van Spriel]

Merging my draft reply in this one. Hope it still makes sense :-p

On 5-1-2017 12:46, Johannes Berg wrote:
> 
>> If we go with approach to use parameters and let FW or MAC80211
>> layer to decide what type of scan to do, 
> 
> At that point though, is it even meaningful to ask "what type of scan
> is this"? Or put another way - what does "scan type" even mean?
> 
>> then in general the only
>> difference between different types of scan is what to do with result:
>> - Normal scan: ssid list, channel list, dwell params, etc...
>> - Sched scan: ssid list, channel list, interval
>> - BSSID scan: bssid list, channel list, interval
>> Action: Report when suitable results are found (in case of Normal
>> scan it will be at the end of scan)
>>
>> - Roaming / Autojoin: ssid list, channel list, interval
>> Action: Connect when suitable results are found
>>
>> - History scan: bssid list, channel list, interval
>> Action: Report when buffer is full / almost full
> 
> Exactly. But the type of action is something set by the entity that
> triggered the scan, right? normal and roam would be equivalent anyway,
> no? wpa_supplicant would make a decision to connect - after the results
> are coming in.
> 
> Oh, then again, maybe you're thinking of full-MAC devices - does a
> roam/autojoin scan really already *imply* a new connection? And if so,
> do we have to do it that way, or can we remove that type of action and
> make a connection decision in higher layers, so it's really the same as
> "report when suitable results are found"?

Today we already have roaming offload, right? Roaming scan would indeed
be the same if roaming offload is not used unless you would want
cfg80211 to make the decision, but then I would expect parameters for
making that decision in the request. Same/similar for autojoin.

>> So we can literally distinguish scan types by final action.
> 
> Actually I think I'm just misinterpreting your wording - you mean that
> we can use the different final actions for the different scan types,
> not that we should actually say - in driver/firmware/... - "this is a
> history scan because the action is to report buffer full", right?

Do we care? The scan engine in our firmware does have use a scan type
concept, but that is hidden by the firmware api. I guess your point
would be that if user-space would prefer scan types and driver/firmware
uses that as well, we might do the same in cfg80211/mac80211. How can we
assure the scan types we come up with match those employed in any and
all wireless devices/firmwares.

>> And for History scan we need new get_scan_results() command.
>>
>> Does it sound reasonable?
> 
> I think it does.

I think so too, but what I am missing in this is who is responsible for
the actions above. I mean do we want to consider option for offloading
from the start or add it later. We may use the new "history scan"
storage in cfg80211 only for devices that do not support offloading it
and provide a .get_scan_results() callback for those that do.

As Johannes points out it needs to be clear to user-space what its next
step should be in obtaining results. Does it make sense to have a
separate notification for the history scan results (not calling it that
of course :-p ) triggered by the action "Report when buffer is full /
almost full" or should user-space determine what to do based on request
id that would be included in the (scheduled) scan results notification.

> There's a bit more complication wrt. the level of detail in results
> though - sometimes the result may include all IEs (normal/sched scan),
> sometimes it may not ("history scan") - are we sure we really only need
> one new get_scan_results()?

So could the "all IEs" case not be handled by the existing BSS storage?
Is it still our intention to handle normal scan (no interval provided?)
as well in the universal scan approach.

Regards,
Arend

Re: [PATCH] brcmfmac: check if we can support used firmware API version

[Arend Van Spriel]

On 3-1-2017 17:11, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Every new firmware API will most likely require changes in our code to
> support it. Right now we support 2 versions only. Refuse to init if we
> detect newer version.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> Hi Arend,
> 
> I think you were concerned about possible firmware API changes. Please
> review this patch, I hope it's a proper check for running unsupported
> firmware version which could result in broken communication between host
> driver and a device.
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 0babfc7..c69ae84 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -6816,6 +6816,11 @@ struct brcmf_cfg80211_info 
> *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
>   brcmf_err("Failed to get D11 version (%d)\n", err);
>   goto priv_out;
>   }
> + if (io_type > BRCMU_D11AC_IOTYPE) {
> + brcmf_err("Unsupported IO version %d\n", io_type);
> + goto priv_out;
> + }

I prefer to have this in brcmu_d11_attach() and have it return an error.
Now this actually does not cover the API version in its entirety. The
broadcom firmware API is a bit more complicated. Firmware commands may
use structured data where we may only add fields at the end to keep it
backward compatible and they are versioned if that can not be avoided.
As example see recent patch [1].

Regards,
Arend

[1] https://patchwork.kernel.org/patch/9442873/
>   cfg->d11inf.io_type = (u8)io_type;
>   brcmu_d11_attach(>d11inf);
>  
> 

Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits

[Arend Van Spriel]

On 4-1-2017 22:19, Rafał Miłecki wrote:
> On 4 January 2017 at 21:07, Arend Van Spriel
> <arend.vanspr...@broadcom.com> wrote:
>> On 4-1-2017 18:58, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <ra...@milecki.pl>
>>>
>>> There are some devices (e.g. Netgear R8000 home router) with one chipset
>>> model used for different radios, some of them limited to subbands. NVRAM
>>> entries don't contain any extra info on such limitations and firmware
>>> reports full list of channels to us. We need to store extra limitation
>>> info in DT to support such devices properly.
>>>
>>> Now there is a cfg80211 helper for reading such info use it in brcmfmac.
>>> This patch adds check for channel being disabled with orig_flags which
>>> is how this wiphy helper and wiphy_register work.
>>>
>>> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
>>> ---
>>> This patch should probably go through wireless-driver-next which is why
>>> it got weird number 4/3. I'm sending it just as a proof of concept.
>>> It was succesfully tested on SmartRG SR400ac with BCM43602.
>>>
>>> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
>>> V5: Update commit message
>>> V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to make it 
>>> work
>>> with helper setting "flags" instead of "orig_flags".
>>> ---
>>>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 -
>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> index ccae3bb..a008ba5 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct 
>>> brcmf_cfg80211_info *cfg,
>>>  band->band);
>>>   channel[index].hw_value = ch.control_ch_num;
>>>
>>> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
>>> + continue;
>>> +
>>
>> So to be clear this is still needed for subsequent calls to
>> brcmf_setup_wiphybands(). The subsequent calls are done from the
>> regulatory notifier. So I think we have an issue with this approach. Say
>> the device comes up with US. That would set DISABLED flags for channels
>> 12 to 14. With a country update to PL we would want to enable channels
>> 12 and 13, right? The orig_flags are copied from the initial flags
>> during wiphy_register() so it seems we will skip enabling 12 and 13. I
>> think we should remove the check above and call
>> wiphy_read_of_freq_limits() as a last step within
>> brcmf_setup_wiphybands(). It means it is called every time, but it
>> safeguards that the limits in DT are always applied.
> 
> I'm not exactly happy with channels management in brcmfmac. Before
> calling wiphy_register it already disables channels unavailable for
> current country. This results in setting IEEE80211_CHAN_DISABLED in

What do you mean by current country. There is none that we are aware off
in the driver. So we obtain the channels for the current
country/revision in the firmware and enable those before
wiphy_register(). This all is within the probe/init sequence so I do not
really see an issue. As the wiphy object is not yet registered there is
no user-space awareness

> orig_flags of channels that may become available later, after country
> change. Please note it happens even right now, without this patch.

Nope. As stated earlier the country setting in firmware is not updated
unless you provide a *proper* mapping of user-space country code to
firmware country code/revision. That is the reason, ie. firmware simply
returns the same list of channels as nothing changed from its
perspective. We may actually drop 11d support.

> Maybe you can workaround this by ignoring orig_flags in custom
> regulatory code, but I'd just prefer to have it nicely handled in the
> first place.

Please care to explain your ideas before putting any effort in this
"feature". As the author of the code that makes you unhappy and as
driver maintainer I would like to get a clearer picture of your point of
view. What exactly is the issue that makes you unhappy.

> This is the next feature I'm going to work on. AFAIU this patch won't
> be applied for now (it's for wireless-drivers-next and we first need
> to get wiphy_read_of_f

Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits

[Arend Van Spriel]

On 4-1-2017 18:58, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> There are some devices (e.g. Netgear R8000 home router) with one chipset
> model used for different radios, some of them limited to subbands. NVRAM
> entries don't contain any extra info on such limitations and firmware
> reports full list of channels to us. We need to store extra limitation
> info in DT to support such devices properly.
> 
> Now there is a cfg80211 helper for reading such info use it in brcmfmac.
> This patch adds check for channel being disabled with orig_flags which
> is how this wiphy helper and wiphy_register work.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> This patch should probably go through wireless-driver-next which is why
> it got weird number 4/3. I'm sending it just as a proof of concept.
> It was succesfully tested on SmartRG SR400ac with BCM43602.
> 
> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
> V5: Update commit message
> V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to make it 
> work
> with helper setting "flags" instead of "orig_flags".
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index ccae3bb..a008ba5 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct 
> brcmf_cfg80211_info *cfg,
>  band->band);
>   channel[index].hw_value = ch.control_ch_num;
>  
> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
> + continue;
> +

So to be clear this is still needed for subsequent calls to
brcmf_setup_wiphybands(). The subsequent calls are done from the
regulatory notifier. So I think we have an issue with this approach. Say
the device comes up with US. That would set DISABLED flags for channels
12 to 14. With a country update to PL we would want to enable channels
12 and 13, right? The orig_flags are copied from the initial flags
during wiphy_register() so it seems we will skip enabling 12 and 13. I
think we should remove the check above and call
wiphy_read_of_freq_limits() as a last step within
brcmf_setup_wiphybands(). It means it is called every time, but it
safeguards that the limits in DT are always applied.

Regards,
Arend

>   /* assuming the chanspecs order is HT20,
>* HT40 upper, HT40 lower, and VHT80.
>*/
> @@ -6478,7 +6481,11 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, 
> struct brcmf_if *ifp)
>   }
>   }
>   err = brcmf_setup_wiphybands(wiphy);
> - return err;
> + if (err)
> + return err;
> + wiphy_read_of_freq_limits(wiphy);
> +
> + return 0;
>  }
>  
>  static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg)
> 

Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties

[Arend Van Spriel]

On 4-1-2017 15:53, Rafał Miłecki wrote:
> On 4 January 2017 at 15:32, Kalle Valo  wrote:
>> Rafał Miłecki  writes:
>>
>>> On 3 January 2017 at 20:55, Rob Herring  wrote:
 On Wed, Dec 28, 2016 at 04:59:54PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki 
>
> This new file should be used for properties handled at higher level and
> so usable with all drivers.

 Why is this needed? Where would this data normally come from?
>>>
>>> Vendors limit choice of channels at their web user interface level. I
>>> want to do better and report proper channels directly at kernel level
>>> instead of masking them in every possible configuration tool.
>>
>> Why do vendors limit the channels? Is it because of a hardware
>> limitation (antenna does not support, or not calibrated, for a certain
>> band etc) or something else?
> 
> Please review & comment on the latest version, currently V5:
> https://patchwork.kernel.org/patch/9495795/
> "This can be used to specify extra hardware limitations caused by e.g.
> used antennas or power amplifiers."

Just to be clear, it is does not need to be a hardware limitation, but
simply a way to assure that multiple wlan radios are not interfering
with each other and crank up the total bandwidth that vendors can put on
their box.

Regards,
Arend

Re: [PATCH V3] brcmfmac: avoid writing channel out of allocated array

[Arend Van Spriel]

On 4-1-2017 12:09, Rafał Miłecki wrote:
> From: Rafał Miłecki <ra...@milecki.pl>

Not taking a break?

> Our code was assigning number of channels to the index variable by
> default. If firmware reported channel we didn't predict this would
> result in using that initial index value and writing out of array. This
> never happened so far (we got a complete list of supported channels) but
> it means possible memory corruption so we should handle it anyway.
> 
> This patch simply detects unexpected channel and ignores it.
> 
> As we don't try to create new entry now, it's also safe to drop hw_value
> and center_freq assignment. For known channels we have these set anyway.
> 
> I decided to fix this issue by assigning NULL or a target channel to the
> channel variable. This was one of possible ways, I prefefred this one as
> it also avoids using channel[index] over and over.
> 
> Fixes: 58de92d2f95e ("brcmfmac: use static superset of channels for wiphy 
> bands")
Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
> ---
> V2: Add extra comment in code for not-found channel.
> Make it clear this problem have never been seen so far
> Explain why it's safe to drop extra assignments
> Note & reason changing channel variable usage
> V3: Update error message as suggested by Arend.
> ---
>  .../broadcom/brcm80211/brcmfmac/cfg80211.c | 32 
> --
>  1 file changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 9c2c128..75ef23b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -5825,7 +5825,6 @@ static int brcmf_construct_chaninfo(struct 
> brcmf_cfg80211_info *cfg,
>   u32 i, j;
>   u32 total;
>   u32 chaninfo;
> - u32 index;
>  
>   pbuf = kzalloc(BRCMF_DCMD_MEDLEN, GFP_KERNEL);
>  
> @@ -5873,33 +5872,36 @@ static int brcmf_construct_chaninfo(struct 
> brcmf_cfg80211_info *cfg,
>   ch.bw == BRCMU_CHAN_BW_80)
>   continue;
>  
> - channel = band->channels;
> - index = band->n_channels;
> + channel = NULL;
>   for (j = 0; j < band->n_channels; j++) {
> - if (channel[j].hw_value == ch.control_ch_num) {
> - index = j;
> + if (band->channels[j].hw_value == ch.control_ch_num) {
> + channel = >channels[j];
>   break;
>   }
>   }
> - channel[index].center_freq =
> - ieee80211_channel_to_frequency(ch.control_ch_num,
> -band->band);
> - channel[index].hw_value = ch.control_ch_num;
> + if (!channel) {
> + /* It seems firmware supports some channel we never
> +  * considered. Something new in IEEE standard?
> +  */
> + brcmf_err("Ignoring unexpected firmware channel %d\n",
> +   ch.control_ch_num);
> + continue;
> + }
>  
>   /* assuming the chanspecs order is HT20,
>* HT40 upper, HT40 lower, and VHT80.
>*/
>   if (ch.bw == BRCMU_CHAN_BW_80) {
> - channel[index].flags &= ~IEEE80211_CHAN_NO_80MHZ;
> + channel->flags &= ~IEEE80211_CHAN_NO_80MHZ;
>   } else if (ch.bw == BRCMU_CHAN_BW_40) {
> - brcmf_update_bw40_channel_flag([index], );
> + brcmf_update_bw40_channel_flag(channel, );
>   } else {
>   /* enable the channel and disable other bandwidths
>* for now as mentioned order assure they are enabled
>* for subsequent chanspecs.
>*/
> - channel[index].flags = IEEE80211_CHAN_NO_HT40 |
> -IEEE80211_CHAN_NO_80MHZ;
> + channel->flags = IEEE80211_CHAN_NO_HT40 |
> +  IEEE80211_CHAN_NO_80MHZ;
>   ch.bw = BRCMU_CHAN_BW_20;
>   cfg->d11inf.encchspec();
>   chaninfo = ch.chspec;
> @@ -5

[PATCH] cfg80211: only pass sband to set_mandatory_flags_band()

[Arend van Spriel]

The supported band structure contains the band is applies to
so no need to pass it separately. Also added a default case
to the switch for completeness. The current code base does not
call this function with NUM_NL80211_BANDS but kept that case
statement although default case would cover that.

Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
Stumbled upon this function and wanted to start the new year lightly.
It applies to master branch of mac80211-next repo.

Best wishes,
Arend
---
 net/wireless/util.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 2cf7df8..c91bc25 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -136,12 +136,11 @@ struct ieee80211_channel *ieee80211_get_channel(struct 
wiphy *wiphy, int freq)
 }
 EXPORT_SYMBOL(ieee80211_get_channel);
 
-static void set_mandatory_flags_band(struct ieee80211_supported_band *sband,
-enum nl80211_band band)
+static void set_mandatory_flags_band(struct ieee80211_supported_band *sband)
 {
int i, want;
 
-   switch (band) {
+   switch (sband->band) {
case NL80211_BAND_5GHZ:
want = 3;
for (i = 0; i < sband->n_bitrates; i++) {
@@ -191,6 +190,7 @@ static void set_mandatory_flags_band(struct 
ieee80211_supported_band *sband,
WARN_ON((sband->ht_cap.mcs.rx_mask[0] & 0x1e) != 0x1e);
break;
case NUM_NL80211_BANDS:
+   default:
WARN_ON(1);
break;
}
@@ -202,7 +202,7 @@ void ieee80211_set_bitrate_flags(struct wiphy *wiphy)
 
for (band = 0; band < NUM_NL80211_BANDS; band++)
if (wiphy->bands[band])
-   set_mandatory_flags_band(wiphy->bands[band], band);
+   set_mandatory_flags_band(wiphy->bands[band]);
 }
 
 bool cfg80211_supported_cipher_suite(struct wiphy *wiphy, u32 cipher)
-- 
1.9.1

Re: [PATCH next V2] brcmfmac: avoid writing channel out of allocated array

[Arend Van Spriel]

On 4-1-2017 11:40, Rafał Miłecki wrote:
> On 4 January 2017 at 10:39, Arend Van Spriel
> <arend.vanspr...@broadcom.com> wrote:
>> On 3-1-2017 17:49, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <ra...@milecki.pl>
>>>
>>> Our code was assigning number of channels to the index variable by
>>> default. If firmware reported channel we didn't predict this would
>>> result in using that initial index value and writing out of array. This
>>> never happened so far (we got a complete list of supported channels) but
>>> it means possible memory corruption so we should handle it anyway.
>>>
>>> This patch simply detects unexpected channel and ignores it.
>>>
>>> As we don't try to create new entry now, it's also safe to drop hw_value
>>> and center_freq assignment. For known channels we have these set anyway.
>>>
>>> I decided to fix this issue by assigning NULL or a target channel to the
>>> channel variable. This was one of possible ways, I prefefred this one as
>>> it also avoids using channel[index] over and over.
>>>
>>> Fixes: 58de92d2f95e ("brcmfmac: use static superset of channels for wiphy 
>>> bands")
>>> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
>>> ---
>>> V2: Add extra comment in code for not-found channel.
>>> Make it clear this problem have never been seen so far
>>> Explain why it's safe to drop extra assignments
>>> Note & reason changing channel variable usage
>>> ---
>>>  .../broadcom/brcm80211/brcmfmac/cfg80211.c | 32 
>>> --
>>>  1 file changed, 17 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> index 9c2c128..a16dd7b 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>> @@ -5825,7 +5825,6 @@ static int brcmf_construct_chaninfo(struct 
>>> brcmf_cfg80211_info *cfg,
>>>   u32 i, j;
>>>   u32 total;
>>>   u32 chaninfo;
>>> - u32 index;
>>>
>>>   pbuf = kzalloc(BRCMF_DCMD_MEDLEN, GFP_KERNEL);
>>>
>>> @@ -5873,33 +5872,36 @@ static int brcmf_construct_chaninfo(struct 
>>> brcmf_cfg80211_info *cfg,
>>>   ch.bw == BRCMU_CHAN_BW_80)
>>>   continue;
>>>
>>> - channel = band->channels;
>>> - index = band->n_channels;
>>> + channel = NULL;
>>>   for (j = 0; j < band->n_channels; j++) {
>>> - if (channel[j].hw_value == ch.control_ch_num) {
>>> - index = j;
>>> + if (band->channels[j].hw_value == ch.control_ch_num) {
>>> + channel = >channels[j];
>>>   break;
>>>   }
>>>   }
>>> - channel[index].center_freq =
>>> - ieee80211_channel_to_frequency(ch.control_ch_num,
>>> -band->band);
>>> - channel[index].hw_value = ch.control_ch_num;
>>> + if (!channel) {
>>> + /* It seems firmware supports some channel we never
>>> +  * considered. Something new in IEEE standard?
>>> +  */
>>> + brcmf_err("Firmware reported unexpected channel %d\n",
>>> +   ch.control_ch_num);
>>
>> Maybe rephrase to "Ignoring unexpected firmware channel %d\n" so
>> end-users are not alarmed by this error message. I think using
>> brcmf_err() is justified, but you may even consider chiming down to
>> brcmf_dbg(INFO, ...).
> 
> Can you suggest a better error message? It seems I'm too brave and I
> don't find this one alarming, so I need suggestion.

Uhm. There is a suggestion above. :-p

Regards,
Arend

Re: [RFC] nl80211: allow multiple active scheduled scan requests

[Arend Van Spriel]

On 4-1-2017 11:30, Johannes Berg wrote:
>> However, we need to prefer something
>>> -
>>> always preferring the new sched scan could lead to bounces, so we
>>> can
>>> prefer (1) existing, (2) legacy-single type or (3) new-multi type,
>>> but
>>> not (4) new sched scan.
>>
>> Not sure I can follow. What is the difference between (1) and (2). 
> 
> (1) would never cancel any existing sched scan, regardless of type
> (legacy vs. multi-capable)
> 
> (2) would cancel an existing sched scan (in favour of a new one) if the
> existing one is multi-capable
> 
> (3) would cancel an existing sched scan (in favour of a new one) if the
> existing one is legacy type

yes, yes. sinking in :-p

>> Also
>> what do you consider (4) new sched scan. You mean the additional
>> parameterization of the scheduled scan?
> 
> No, I just meant any new request.

Yeah, so there is already an existing/active sched scan. Clear.

>>> I think preferring the existing would probably be best, i.e. refuse
>>> legacy if any sched scan is running, and refuse multi if legacy is
>>> running?
>>
>> Whatever the response above, I can understand this and it seems most
>> straightforward. So I tend agree this is our best option although
>> maybe for the wrong reason.
> 
> :)

Thanks for clarifying it.

Gr. AvS

Re: [RFC] nl80211: allow multiple active scheduled scan requests

[Arend Van Spriel]

On 4-1-2017 10:59, Johannes Berg wrote:
> On Tue, 2017-01-03 at 13:25 +0100, Arend Van Spriel wrote:
>> On 2-1-2017 11:44, Johannes Berg wrote:
>>>
>>>> +  /*
>>>> +   * allow only one legacy scheduled scan if user-space
>>>> +   * does not indicate multiple scheduled scan support.
>>>> +   */
>>>> +  if (!info->attrs[NL80211_ATTR_SCHED_SCAN_MULTI] &&
>>>> +  cfg80211_legacy_sched_scan_active(rdev))
>>>>return -EINPROGRESS;
>>>
>>> That probably doesn't go far enough - if legacy one is active then
>>> we
>>> probably shouldn't allow a new MULTI one either (or abandon the
>>> legacy
>>> one) so that older userspace doesn't get confused with multiple
>>> notifications from sched scans it didn't start.
>>
>> I considered that although not taking the notifications into account.
>> Will change it. Abandoning the legacy one would be a behavioral
>> change so probably not acceptable, right?
> 
> Well, it would be acceptable since it's documented that it's possible
> it might stop for any reason. However, we need to prefer something -
> always preferring the new sched scan could lead to bounces, so we can
> prefer (1) existing, (2) legacy-single type or (3) new-multi type, but
> not (4) new sched scan.

Not sure I can follow. What is the difference between (1) and (2). Also
what do you consider (4) new sched scan. You mean the additional
parameterization of the scheduled scan?

> I think preferring the existing would probably be best, i.e. refuse
> legacy if any sched scan is running, and refuse multi if legacy is
> running?

Whatever the response above, I can understand this and it seems most
straightforward. So I tend agree this is our best option although maybe
for the wrong reason.

>> I guess your remark means this clarifies your earlier question about
>> the request id, right?
> 
> yeah.

Thanks,
Arend

Re: [PATCH V5 1/3] dt-bindings: document common IEEE 802.11 frequency limit property

[Arend Van Spriel]

On 4-1-2017 7:20, Rafał Miłecki wrote:
> Hi Rob,
> 
> On 01/03/2017 11:57 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki 
>>
>> This new file should be used for properties that apply to all wireless
>> devices.
>>
>> Signed-off-by: Rafał Miłecki 
>> ---
>> V2: Switch to a single ieee80211-freq-limit property that allows
>> specifying
>> *multiple* ranges. This resolves problem with more complex rules
>> as pointed
>> by Felx.
>> Make description implementation agnostic as pointed by Arend.
>> Rename node to wifi as suggested by Martin.
>> V3: Use more real-life frequencies in the example.
>> V5: Describe hardware design as possible use for this property
>> ---
>>  .../devicetree/bindings/net/wireless/ieee80211.txt   | 20
>> 
>>  1 file changed, 20 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> new file mode 100644
>> index 000..1c82c16
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> @@ -0,0 +1,20 @@
>> +Common IEEE 802.11 properties
>> +
>> +This provides documentation of common properties that are valid for
>> all wireless
>> +devices.
>> +
>> +Optional properties:
>> + - ieee80211-freq-limit : list of supported frequency ranges in KHz.
>> This can be
>> +used to specify extra hardware limitations caused by e.g. used
>> antennas
>> +or power amplifiers.
> 
> Do you find this description sufficient now? I'm not sure how/if I could
> answer
> "Where would this data normally come from?" question.
>
> One vendor may hardcode choice of channels in their PHP web UI.
> Another one may do it in Andoid app.
> OpenWrt so far was describing this limitation on their wiki page.
> 
> It doesn't sound like any valuable info if I understand this correctly.
> We also
> don't describe where to get information about amount o RAM. One may just
> check
> the hardware, one may use vendor firmware, one could check product data
> sheet.
> 
> If I missed the point, could you help me get this?


There is probably no easy answer. DT is used to describe device
properties that are not otherwise discoverable (at least that is my rule
of thumb). So what is the "device" in this context? You may consider
just the chip, but in this case it is combination of the chip and its RF
path that determine the frequency range that it can operate in.
Apparently this was assured in user-space due to lack of a better
option. Having this specified in DT seems a viable option getting rid of
having a particular platform impose a requirement upon user-space.

You could consider these properties global as they are describing the
platform, but again this depends on what you consider the "device". If
you want to do this global you may add a global node for wifi properties
and use references to the device.

Regards,
Arend

Re: [PATCH next V2] brcmfmac: avoid writing channel out of allocated array

[Arend Van Spriel]

On 3-1-2017 17:49, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Our code was assigning number of channels to the index variable by
> default. If firmware reported channel we didn't predict this would
> result in using that initial index value and writing out of array. This
> never happened so far (we got a complete list of supported channels) but
> it means possible memory corruption so we should handle it anyway.
> 
> This patch simply detects unexpected channel and ignores it.
> 
> As we don't try to create new entry now, it's also safe to drop hw_value
> and center_freq assignment. For known channels we have these set anyway.
> 
> I decided to fix this issue by assigning NULL or a target channel to the
> channel variable. This was one of possible ways, I prefefred this one as
> it also avoids using channel[index] over and over.
> 
> Fixes: 58de92d2f95e ("brcmfmac: use static superset of channels for wiphy 
> bands")
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Add extra comment in code for not-found channel.
> Make it clear this problem have never been seen so far
> Explain why it's safe to drop extra assignments
> Note & reason changing channel variable usage
> ---
>  .../broadcom/brcm80211/brcmfmac/cfg80211.c | 32 
> --
>  1 file changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 9c2c128..a16dd7b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -5825,7 +5825,6 @@ static int brcmf_construct_chaninfo(struct 
> brcmf_cfg80211_info *cfg,
>   u32 i, j;
>   u32 total;
>   u32 chaninfo;
> - u32 index;
>  
>   pbuf = kzalloc(BRCMF_DCMD_MEDLEN, GFP_KERNEL);
>  
> @@ -5873,33 +5872,36 @@ static int brcmf_construct_chaninfo(struct 
> brcmf_cfg80211_info *cfg,
>   ch.bw == BRCMU_CHAN_BW_80)
>   continue;
>  
> - channel = band->channels;
> - index = band->n_channels;
> + channel = NULL;
>   for (j = 0; j < band->n_channels; j++) {
> - if (channel[j].hw_value == ch.control_ch_num) {
> - index = j;
> + if (band->channels[j].hw_value == ch.control_ch_num) {
> + channel = >channels[j];
>   break;
>   }
>   }
> - channel[index].center_freq =
> - ieee80211_channel_to_frequency(ch.control_ch_num,
> -band->band);
> - channel[index].hw_value = ch.control_ch_num;
> + if (!channel) {
> + /* It seems firmware supports some channel we never
> +  * considered. Something new in IEEE standard?
> +  */
> + brcmf_err("Firmware reported unexpected channel %d\n",
> +   ch.control_ch_num);

Maybe rephrase to "Ignoring unexpected firmware channel %d\n" so
end-users are not alarmed by this error message. I think using
brcmf_err() is justified, but you may even consider chiming down to
brcmf_dbg(INFO, ...).

Regards,
Arend

Re: [PATCH] brcmfmac: avoid writing channel out of allocated array

[Arend Van Spriel]

On 3-1-2017 12:31, Rafał Miłecki wrote:
>>> + if (!channel) {
>>> + brcmf_err("Firmware reported unexpected channel %d\n",
>>> +   ch.control_ch_num);
>>> + continue;
>>> + }
>> As stated above something is really off when this happens so should we
>> continue and try to make sense of what firmware provides or simply fail.
> Well, I could image something like this happening and not being critical.
> The simplest case: Broadcom team releases a new firmware which
> supports extra 5 GHz channels (e.g. due to the IEEE standard change).
> Why should we refuse to run & support all "old" channel just because of that?

Fair enough. I was assuming we keep __wl_{2,5}ghz_channels up to date
with IEEE standard.

> What do you mean by "make sense of what firmware provides"? Would kind
> of solution would you suggest?

When the above assumption can be assured (by us) the only other scenario
would be a change in the firmware API where we wrongly interpret the
information retrieved. In this case all subsequent channels will likely
result in bogus or accidental matches hence it seems better to bail out
early.

Regards,
Arend

Re: [PATCH V4 3/2] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits

[Arend Van Spriel]

What is with the patch numbering, ie. 3/2?

On 3-1-2017 12:03, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> There are some devices (e.g. Netgear R8000 home router) with one chipset
> model used for different radios, some of them limited to subbands. NVRAM
> entries don't contain any extra info on such limitations and firmware
> reports full list of channels to us. We need to store extra limitation
> info on DT to support such devices properly.
> 
> This patch adds check for channel being disabled with orig_flags which
> is how this wiphy helper works.

this is the first mention about the wiphy helper. Probably need
statement here that call to wiphy_read_of_freq_limits() was added in
this patch which applies the extra limitation info read from DT.

> Signed-off-by: Rafał Miłecki 
> ---
> This patch should probably go through wireless-driver-next, I'm sending
> it just as a proof of concept. It was succesfully tested on SmartRG
> SR400ac with BCM43602.
> 
> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
> ---
>  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 ccae3bb..f95e316 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct 
> brcmf_cfg80211_info *cfg,
>  band->band);
>   channel[index].hw_value = ch.control_ch_num;
>  
> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
> + continue;
> +
>   /* assuming the chanspecs order is HT20,
>* HT40 upper, HT40 lower, and VHT80.
>*/
> @@ -6477,6 +6480,7 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, 
> struct brcmf_if *ifp)
>   wiphy->bands[NL80211_BAND_5GHZ] = band;
>   }
>   }
> + wiphy_read_of_freq_limits(wiphy);

The return value is ignored, which I suppose is fine. So does the
function need a return value at all? Is there a scenario where the DT
info *must* be supplied?

Regards,
Arend

Re: [RFC] nl80211: allow multiple active scheduled scan requests

[Arend Van Spriel]

On 2-1-2017 11:44, Johannes Berg wrote:
> 
>> +/*
>> + * allow only one legacy scheduled scan if user-space
>> + * does not indicate multiple scheduled scan support.
>> + */
>> +if (!info->attrs[NL80211_ATTR_SCHED_SCAN_MULTI] &&
>> +cfg80211_legacy_sched_scan_active(rdev))
>>  return -EINPROGRESS;
> 
> That probably doesn't go far enough - if legacy one is active then we
> probably shouldn't allow a new MULTI one either (or abandon the legacy
> one) so that older userspace doesn't get confused with multiple
> notifications from sched scans it didn't start.

I considered that although not taking the notifications into account.
Will change it. Abandoning the legacy one would be a behavioral change
so probably not acceptable, right?

>> +if (rdev->sched_scan_req_count == rdev->wiphy.max_sched_scan_reqs)
>> +return -ENOSPC;
> 
> Do we really want to do the double-accounting, just to avoid counting
> the list length here?

Ok. I have no strong preference.

>> +/* leave request id zero for legacy request */
> 
> why? The ID would be ignored, so why special-case it?

It makes the function cfg80211_legacy_sched_scan_active() easier, ie.
not needing a is_legacy flag in struct cfg80211_sched_scan_request.

>> +static void cfg80211_del_sched_scan_req(struct
>> cfg80211_registered_device *rdev,
>> +struct
>> cfg80211_sched_scan_request *req)
>> +{
>> +list_del_rcu(>list);
>> +kfree_rcu(req, rcu_head);
>> +synchronize_rcu();
>> +rdev->sched_scan_req_count--;
>> +}
> 
> That's bogus - either you use kfree_rcu() or synchronize_rcu() (the
> former is much better); combining both makes no sense.

Thanks. Both functions mentioned the rcu grace period so I was doubtful.
Will change it.

>> +bool cfg80211_legacy_sched_scan_active(struct
>> cfg80211_registered_device *rdev)
>> +{
>> +struct cfg80211_sched_scan_request *req;
>> +
>> +req = list_first_or_null_rcu(>sched_scan_req_list,
>> + struct
>> cfg80211_sched_scan_request, list);
>> +/* request id 0 indicates legacy request in progress */
>> +return req && !req->reqid;
>> +}
> 
> Ok, fair enough.

I guess your remark means this clarifies your earlier question about the
request id, right?

Regards,
Arend

Re: [PATCH V4 2/2] cfg80211: support ieee80211-freq-limit DT property

[Arend Van Spriel]

On 3-1-2017 12:03, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This patch adds a helper for reading that new property and applying
> limitations or supported channels specified this way.
> It may be useful for specifying single band devices or devices that
> support only some part of the whole band. It's common that tri-band
> routers have separated radios for lower and higher part of 5 GHz band.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Put main code in core.c as it isn't strictly part of regulatory - pointed
> by Arend.
> Update to support ieee80211-freq-limit (new property).
> V3: Introduce separated wiphy_read_of_freq_limits function.
> Add extra sanity checks for DT data.
> Move code back to reg.c as suggested by Johannes.
> V4: Move code to of.c
> Use one helper called at init time (no runtime hooks)
> Modify orig_flags
> ---
>  include/net/cfg80211.h |  26 ++
>  net/wireless/Makefile  |   1 +
>  net/wireless/of.c  | 137 
> +
>  net/wireless/reg.c |   4 +-
>  net/wireless/reg.h |   2 +
>  5 files changed, 168 insertions(+), 2 deletions(-)
>  create mode 100644 net/wireless/of.c
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index ca2ac1c..d7723a8 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -311,6 +311,32 @@ struct ieee80211_supported_band {
>   struct ieee80211_sta_vht_cap vht_cap;
>  };
>  
> +/**
> + * wiphy_read_of_freq_limits - read frequency limits from device tree
> + *
> + * @wiphy: the wireless device to get extra limits for
> + *
> + * Some devices may have extra limitations specified in DT. This may be 
> useful
> + * for chipsets that normally support more bands but are limited due to board
> + * design (e.g. by antennas or extermal power amplifier).
> + *
> + * This function reads info from DT and uses it to *modify* channels (disable
> + * unavailable ones). It's usually a *bad* idea to use it in drivers with
> + * shared channel data as DT limitations are device specific.
> + *
> + * As this function access device node it has to be called after 
> set_wiphy_dev.

You are aware that you need to modify this description with earlier
patch "cfg80211: allow passing struct device in the wiphy_new call",
right? :-p

> + * It also modifies channels so they have to be set first.
> + */
> +#ifdef CONFIG_OF
> +int wiphy_read_of_freq_limits(struct wiphy *wiphy);
> +#else /* CONFIG_OF */
> +static inline int wiphy_read_of_freq_limits(struct wiphy *wiphy)
> +{
> + return 0;
> +}
> +#endif /* !CONFIG_OF */
> +
> +

[...]

> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 5dbac37..bda0e9e 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -748,8 +748,8 @@ static bool is_valid_rd(const struct ieee80211_regdomain 
> *rd)
>   return true;
>  }
>  
> -static bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
> - u32 center_freq_khz, u32 bw_khz)
> +bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
> +  u32 center_freq_khz, u32 bw_khz)
>  {
>   u32 start_freq_khz, end_freq_khz;

would it be more appropriate to move this function to util.c?

Regards,
Arend

Re: [PATCH] brcmfmac: avoid writing channel out of allocated array

[Arend Van Spriel]

On 3-1-2017 9:38, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Our code was assigning number of channels to the index variable by
> default. If firmware reported channel we didn't predict this would
> result in using that initial index value and writing out of array.
> 
> Fix this by detecting unexpected channel and ignoring it.
> 
> Fixes: 58de92d2f95e ("brcmfmac: use static superset of channels for wiphy 
> bands")
> Signed-off-by: Rafał Miłecki 
> ---
> I'm not sure what kind of material it is. It fixes possible memory corruption
> (serious thing?) but this bug was there since Apr 2015, so is it worth fixing
> in 4.10? Or maybe I should even cc stable?
> I don't think any released firmware reports any unexpected channel, so I guess
> noone ever hit this problem. I just noticed this possible problem when working
> on another feature.

Looking at the change I was going to ask if you actually hit the issue
you are addressing here. The channels in __wl_2ghz_channels and
__wl_5ghz_channels are complete list of channels for the particular band
so it would mean firmware behaves out-of-spec or firmware api was
changed. For robustness a change is acceptable I guess.

My general policy is to submit fixes to wireless-drivers (and stable)
only if it resolves a critical issue found during testing or a reported
issue.

> ---
>  .../broadcom/brcm80211/brcmfmac/cfg80211.c | 29 
> +++---
>  1 file changed, 14 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 13ca3eb..0babfc7 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -5825,7 +5825,6 @@ static int brcmf_construct_chaninfo(struct 
> brcmf_cfg80211_info *cfg,
>   u32 i, j;
>   u32 total;
>   u32 chaninfo;
> - u32 index;
>  
>   pbuf = kzalloc(BRCMF_DCMD_MEDLEN, GFP_KERNEL);
>  
> @@ -5873,33 +5872,33 @@ static int brcmf_construct_chaninfo(struct 
> brcmf_cfg80211_info *cfg,
>   ch.bw == BRCMU_CHAN_BW_80)
>   continue;
>  
> - channel = band->channels;
> - index = band->n_channels;
> + channel = NULL;
>   for (j = 0; j < band->n_channels; j++) {
> - if (channel[j].hw_value == ch.control_ch_num) {
> - index = j;
> + if (band->channels[j].hw_value == ch.control_ch_num) {
> + channel = >channels[j];
>   break;
>   }
>   }

You could have kept the index construct and simply check if j ==
band->n_channels here to determine something is wrong.

> - channel[index].center_freq =
> - ieee80211_channel_to_frequency(ch.control_ch_num,
> -band->band);
> - channel[index].hw_value = ch.control_ch_num;

So you are also removing these assignments which indeed seem redundant.
Maybe make note of that in the commit message?

> + if (!channel) {
> + brcmf_err("Firmware reported unexpected channel %d\n",
> +   ch.control_ch_num);
> + continue;
> + }

As stated above something is really off when this happens so should we
continue and try to make sense of what firmware provides or simply fail.

Regards,
Arend

Re: [PATCH V3 2/2] cfg80211: support ieee80211-freq-limit DT property

[Arend van Spriel]

On 02-01-17 18:52, Johannes Berg wrote:
>> +static void wiphy_freq_limits_apply(struct wiphy *wiphy)
> [...]
>> +if (!wiphy_freq_limits_valid_chan(wiphy,
>> chan)) {
>> +pr_debug("Disabling freq %d MHz as
>> it's out of OF limits\n",
>> + chan->center_freq);
>> +chan->flags |=
>> IEEE80211_CHAN_DISABLED;
> 
> I think you didn't address the problem in the best way now.
> 
> The problem with the channel sharing was the way you're applying the
> limits - at runtime. This is now OK since the new function shouldn't be
> called when the channel structs are shared, but hooking it all into thes 
> regulatory code is now no longer needed.
> 
> What you can do now, when reading the OF data, is actually apply it to
> the channel flags immediately. If done *before* wiphy_register(), these
> flags will be preserved forever, so you no longer need any hooks in
> regulatory code at all - you can just set the original channel flags
> according to the OF data.

I suppose this then can also be done early in the wiphy_register()
function itself, right?

> I think this greatly simplifies the flow, since you can also remove
> wiphy->freq_limits (and n_freq_limits) completely, since now the only
> effect of the function would be to modify the channel list, and later
> regulatory updates would always preserve the flags.

So does it mean the function can go in core.c again :-p If it is likely
there will be other properties being added it might justify adding a new
source file, eg. of.c, and only compile it when CONFIG_OF is set. Just a
thought.

Regards,
Arend

Re: [PATCH 2/2] cfg80211: reg: support ieee80211-(min|max)-center-freq DT properties

[Arend van Spriel]

On 29-12-16 10:43, Rafał Miłecki wrote:
> On 29 December 2016 at 09:57, Arend van Spriel
> <arend.vanspr...@broadcom.com> wrote:
>> On 28-12-16 22:30, Rafał Miłecki wrote:
>>> On 28 December 2016 at 22:28, Rafał Miłecki <zaj...@gmail.com> wrote:
>>>> On 28 December 2016 at 22:07, Arend van Spriel
>>>> <arend.vanspr...@broadcom.com> wrote:
>>>>> On 28-12-16 16:59, Rafał Miłecki wrote:
>>>>>> From: Rafał Miłecki <ra...@milecki.pl>
>>>>>>
>>>>>> They allow specifying hardware limitations of supported channels. This
>>>>>> may be useful for specifying single band devices or devices that support
>>>>>> only some part of the whole band.
>>>>>> E.g. some tri-band routers have separated radios for lower and higher
>>>>>> part of 5 GHz band.
>>>>>>
>>>>>> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
>>>>>> ---
>>>>>>  net/wireless/reg.c | 34 ++
>>>>>>  1 file changed, 34 insertions(+)
>>>>>>
>>>>>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
>>>>>> index 5dbac37..35ba5c7 100644
>>>>>> --- a/net/wireless/reg.c
>>>>>> +++ b/net/wireless/reg.c
>>>>>> @@ -1123,6 +1123,26 @@ const char *reg_initiator_name(enum 
>>>>>> nl80211_reg_initiator initiator)
>>>>>>  }
>>>>>>  EXPORT_SYMBOL(reg_initiator_name);
>>>>>>
>>>>>> +static bool reg_center_freq_of_valid(struct wiphy *wiphy,
>>>>>> +  struct ieee80211_channel *chan)
>>>>>> +{
>>>>>> + struct device_node *np = wiphy_dev(wiphy)->of_node;
>>>>>> + u32 val;
>>>>>> +
>>>>>> + if (!np)
>>>>>> + return true;
>>>>>> +
>>>>>> + if (!of_property_read_u32(np, "ieee80211-min-center-freq", ) &&
>>>>>> + chan->center_freq < KHZ_TO_MHZ(val))
>>>>>> + return false;
>>>>>> +
>>>>>> + if (!of_property_read_u32(np, "ieee80211-max-center-freq", ) &&
>>>>>> + chan->center_freq > KHZ_TO_MHZ(val))
>>>>>> + return false;
>>>>>
>>>>> I suspect these functions rely on CONFIG_OF. So might not build for
>>>>> !CONFIG_OF.
>>>>
>>>> I compiled it with
>>>> # CONFIG_OF is not set
>>>>
>>>> Can you test it and provide a non-working config if you see a
>>>> compilation error, please?
>>>
>>> include/linux/of.h provides a lot of dummy static inline functions if
>>> CONFIG_OF is not used (they also allow compiler to drop most of the
>>> code).
>>
>> of_propeirty_read_u32 is static inline in of.h calling
>> of_property_read_u32_array, which has a dummy variant in of.h returning
>> -ENOSYS so -38. Pretty sure that is not what you want. At least it does
>> not allow the compiler to drop any code so probably better to do:
>>
>> if (!IS_ENABLED(CONFIG_OF) || !np)
>> return true;
> 
> Please verify that using a compiler. If there is a problem I'll be
> happy to work on it, but I need a proof it exists.

I am on vacation right now so not having much more than email and web
browser to use as review reference.

> If compilers sees a:
> if (!-ENOSYS && chan->center_freq < KHZ_TO_MHZ(val))
> condition, it's pretty clear it can be dropped. With both conditional
> blocks dropped function always returns "true" and... can be dropped.
> 
> Let me see if I can convince you with the following test:

No need to convince me. I made a mistake reviewing the code. Thanks for
clarifying it.

> $ grep -m 1 CONFIG_OF .config
> # CONFIG_OF is not set
> $ objdump --syms net/wireless/reg.o | grep -c reg_center_freq_of_valid
> 0
> 
> $ grep -m 1 CONFIG_OF .config
> CONFIG_OF=y
> $ objdump --syms net/wireless/reg.o | grep -c reg_center_freq_of_valid
> 1
> 
> 
>> So with this patch you change the channel to DISABLED. I am not very
>> familiar with reg.c so do you know if this is done before or after
>> calling regulatory notifier in the driver. brcmfmac will enable channels
>> querying the device upon regulatory notifier call, which may undo the
>> behavior introduced by your patch.
> 
> I'm not regulatory export, so I hope someone will review this patch.
> So far I can say it works for me after trying it on SR400ac with
> BCM43602.

But you probably do not have a mapping table for mapping country code
received in notifier to firmware regulatory code/revision. Only if you
have that, brcmfmac will update the channels in the bands.

Giving this some more consideration I am not sure if this is the proper
place to handle this. ieee80211-(min|max)-center-freq is platform
specific configuration allowing multiple cards to be used in different
(sub)bands. This has nothing to do with regulatory. So probably better
to move it to core.c or chan.c.

Regards,
Arend

Re: [PATCH 2/2] cfg80211: reg: support ieee80211-(min|max)-center-freq DT properties

[Arend van Spriel]

On 28-12-16 22:30, Rafał Miłecki wrote:
> On 28 December 2016 at 22:28, Rafał Miłecki <zaj...@gmail.com> wrote:
>> On 28 December 2016 at 22:07, Arend van Spriel
>> <arend.vanspr...@broadcom.com> wrote:
>>> On 28-12-16 16:59, Rafał Miłecki wrote:
>>>> From: Rafał Miłecki <ra...@milecki.pl>
>>>>
>>>> They allow specifying hardware limitations of supported channels. This
>>>> may be useful for specifying single band devices or devices that support
>>>> only some part of the whole band.
>>>> E.g. some tri-band routers have separated radios for lower and higher
>>>> part of 5 GHz band.
>>>>
>>>> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
>>>> ---
>>>>  net/wireless/reg.c | 34 ++
>>>>  1 file changed, 34 insertions(+)
>>>>
>>>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
>>>> index 5dbac37..35ba5c7 100644
>>>> --- a/net/wireless/reg.c
>>>> +++ b/net/wireless/reg.c
>>>> @@ -1123,6 +1123,26 @@ const char *reg_initiator_name(enum 
>>>> nl80211_reg_initiator initiator)
>>>>  }
>>>>  EXPORT_SYMBOL(reg_initiator_name);
>>>>
>>>> +static bool reg_center_freq_of_valid(struct wiphy *wiphy,
>>>> +  struct ieee80211_channel *chan)
>>>> +{
>>>> + struct device_node *np = wiphy_dev(wiphy)->of_node;
>>>> + u32 val;
>>>> +
>>>> + if (!np)
>>>> + return true;
>>>> +
>>>> + if (!of_property_read_u32(np, "ieee80211-min-center-freq", ) &&
>>>> + chan->center_freq < KHZ_TO_MHZ(val))
>>>> + return false;
>>>> +
>>>> + if (!of_property_read_u32(np, "ieee80211-max-center-freq", ) &&
>>>> + chan->center_freq > KHZ_TO_MHZ(val))
>>>> + return false;
>>>
>>> I suspect these functions rely on CONFIG_OF. So might not build for
>>> !CONFIG_OF.
>>
>> I compiled it with
>> # CONFIG_OF is not set
>>
>> Can you test it and provide a non-working config if you see a
>> compilation error, please?
> 
> include/linux/of.h provides a lot of dummy static inline functions if
> CONFIG_OF is not used (they also allow compiler to drop most of the
> code).

of_propeirty_read_u32 is static inline in of.h calling
of_property_read_u32_array, which has a dummy variant in of.h returning
-ENOSYS so -38. Pretty sure that is not what you want. At least it does
not allow the compiler to drop any code so probably better to do:

if (!IS_ENABLED(CONFIG_OF) || !np)
return true;

So with this patch you change the channel to DISABLED. I am not very
familiar with reg.c so do you know if this is done before or after
calling regulatory notifier in the driver. brcmfmac will enable channels
querying the device upon regulatory notifier call, which may undo the
behavior introduced by your patch.

Regards,
Arend

Re: [PATCH 2/2] cfg80211: reg: support ieee80211-(min|max)-center-freq DT properties

[Arend van Spriel]

On 28-12-16 16:59, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> They allow specifying hardware limitations of supported channels. This
> may be useful for specifying single band devices or devices that support
> only some part of the whole band.
> E.g. some tri-band routers have separated radios for lower and higher
> part of 5 GHz band.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  net/wireless/reg.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 5dbac37..35ba5c7 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -1123,6 +1123,26 @@ const char *reg_initiator_name(enum 
> nl80211_reg_initiator initiator)
>  }
>  EXPORT_SYMBOL(reg_initiator_name);
>  
> +static bool reg_center_freq_of_valid(struct wiphy *wiphy,
> +  struct ieee80211_channel *chan)
> +{
> + struct device_node *np = wiphy_dev(wiphy)->of_node;
> + u32 val;
> +
> + if (!np)
> + return true;
> +
> + if (!of_property_read_u32(np, "ieee80211-min-center-freq", ) &&
> + chan->center_freq < KHZ_TO_MHZ(val))
> + return false;
> +
> + if (!of_property_read_u32(np, "ieee80211-max-center-freq", ) &&
> + chan->center_freq > KHZ_TO_MHZ(val))
> + return false;

I suspect these functions rely on CONFIG_OF. So might not build for
!CONFIG_OF.

Regards,
Arend

Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties

[Arend van Spriel]

On 28-12-16 16:59, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This new file should be used for properties handled at higher level and
> so usable with all drivers.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  .../devicetree/bindings/net/wireless/ieee80211.txt   | 16 
> 
>  1 file changed, 16 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt 
> b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> new file mode 100644
> index 000..c762769
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> @@ -0,0 +1,16 @@
> +Common IEEE 802.11 properties
> +
> +This provides documentation of common properties that are handled by a proper
> +net layer and don't require extra driver code.

Please do not make any assumptions on how DT properties are handled nor
by what. Just state that these properties apply to all wireless devices
and are applicable to device specific bindings.

> +Optional properties:
> + - ieee80211-min-center-freq : minimal supported frequency in KHz
> + - ieee80211-max-center-freq : maximal supported frequency in KHz
> +
> +Example:
> +
> +pcie@0,0 {
> + reg = <0x 0 0 0 0>;
> + ieee80211-min-center-freq = <2437000>;
> + ieee80211-max-center-freq = <2457000>;
> +};

Is this the proper level to define it. I was expecting a child node of
the pci(e) controller. Maybe I am misreading the example.

Regards,

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Arend Van Spriel]

On 24-12-2016 17:52, Pali Rohár wrote:
> NVS calibration data for wl1251 are model specific. Every one device with
> wl1251 chip has different and calibrated in factory.
> 
> Not all wl1251 chips have own EEPROM where are calibration data stored. And
> in that case there is no "standard" place. Every device has stored them on
> different place (some in rootfs file, some in dedicated nand partition,
> some in another proprietary structure).
> 
> Kernel wl1251 driver cannot support every one different storage decided by
> device manufacture so it will use request_firmware_prefer_user() call for
> loading NVS calibration data and userspace helper will be responsible to
> prepare correct data.

Responding to this patch as it provides a lot of context to discuss. As
you might have gathered from earlier discussions I am not a fan of using
user-space helper. I can agree that the kernel driver, wl1251 in this
case, should be agnostic to platform specific details regarding storage
solutions and the firmware api should hide that. However, it seems your
only solution is adding user-space to the mix and changing the api
towards that. Can we solve it without user-space help?

The firmware_class already supports a number of path prefixes it
traverses looking for the requested firmware. So I was thinking about
adding a hashtable in which a platform driver can add firmware which are
stored in the hashtable using the hashed firmware name. Upon a firmware
request from the driver we could check the hashtable before traversing
the path prefixes on VFS. The obvious problem is that the request may
come before the firmware is added to the hashtable. Just wanted to pitch
the idea first and hear what others think about it and maybe someone has
a nice solution for this problem. Fingers crossed :-p

> In case userspace helper fails request_firmware_prefer_user() still try to
> load data file directly from VFS as fallback mechanism.
> 
> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
> devices.

With the firmware hashtable api on N900 a platform driver could
interpret the CAL data in the nand partition and provide it through the
firmware_class.

> With this patch it is finally possible to load correct model specific NVS
> calibration data for Nokia N900.

But on other devices that use wl1251, but for instance have no userspace
helper the request to userspace will fail (after 60 sec?) and try VFS
after that. Maybe not so nice. You should consider other device
configurations. Not just N900.

Regards,
Arend

> Signed-off-by: Pali Rohár 
> ---
>  drivers/net/wireless/ti/wl1251/Kconfig |1 +
>  drivers/net/wireless/ti/wl1251/main.c  |2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig 
> b/drivers/net/wireless/ti/wl1251/Kconfig
> index 7142ccf..affe154 100644
> --- a/drivers/net/wireless/ti/wl1251/Kconfig
> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
> @@ -2,6 +2,7 @@ config WL1251
>   tristate "TI wl1251 driver support"
>   depends on MAC80211
>   select FW_LOADER
> + select FW_LOADER_USER_HELPER
>   select CRC7
>   ---help---
> This will enable TI wl1251 driver support. The drivers make
> diff --git a/drivers/net/wireless/ti/wl1251/main.c 
> b/drivers/net/wireless/ti/wl1251/main.c
> index 208f062..24f8866 100644
> --- a/drivers/net/wireless/ti/wl1251/main.c
> +++ b/drivers/net/wireless/ti/wl1251/main.c
> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
>   struct device *dev = wiphy_dev(wl->hw->wiphy);
>   int ret;
>  
> - ret = request_firmware(, WL1251_NVS_NAME, dev);
> + ret = request_firmware_prefer_user(, WL1251_NVS_NAME, dev);
>  
>   if (ret < 0) {
>   wl1251_error("could not get nvs file: %d", ret);
> 

Re: [PATCH] brcmfmac: fix spelling mistakes on "Ivalid"

[Arend Van Spriel]

On 23-12-2016 1:43, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
> 
> Trivial fixes to spelling mistake "Ivalid" to "Invalid" in
> brcmf_err error messages.

Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> ---
>  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 7ffc4ab..15eaf72 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -3971,7 +3971,7 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
>   pval |= AES_ENABLED;
>   break;
>   default:
> - brcmf_err("Ivalid unicast security info\n");
> + brcmf_err("Invalid unicast security info\n");
>   }
>   offset++;
>   }
> @@ -4015,7 +4015,7 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
>   wpa_auth |= WPA2_AUTH_1X_SHA256;
>   break;
>   default:
> - brcmf_err("Ivalid key mgmt info\n");
> + brcmf_err("Invalid key mgmt info\n");
>   }
>   offset++;
>   }
> 

Re: [PATCH 2/2] net: wireless: fix to uses struct

[Arend Van Spriel]

On 21-12-2016 23:23, Ozgur Karatas wrote:
> 
> The patch fixed to struct uses in reg.c, I think doesn't need to be use to 
> "struct". 
> There is dataype not have to logical link and each is different definitons.
> 
> I'm undecided on this patch. I compiled and didn't to errors.

There must be something wrong in the way you build stuff, but still just
looking at your patch it is fundamentally wrong, which is what makes
people say "do a basic C course". Let me try and explain below.

> Signed-off-by: Ozgur Karatas 
> ---
>  net/wireless/reg.c  | 10 +-
>  1 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 5dbac37..5b70970 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
>   if (!regdom)
>   return -ENODATA;
>  
> - request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
> + request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);

Making it more abstract to explain what you are doing:

x = foo(sizeof(T), GFP_KERNEL); where T is "struct Y".

which you change to:

x = foo(sizeof(*Y), GFP_KERNEL);

Y has no meaning for the sizeof operator and the compiler will yell at
it being an unknown identifier. In a lot of kernel code you will find:

x = foo(sizeof(*x), GFP_KERNEL);

which is probably the coding style fix you are attempting to make, but
miserably fail to do so. There is nothing linux kernel specific about
this. It is really fundamental knowledge of the C language. The correct
change for this instance is:

-   request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+   request = kzalloc(sizeof(*request), GFP_KERNEL);

Hope this helps to come up with a working V2 of this patch.

Regards,
Arend

[RFC] nl80211: allow multiple active scheduled scan requests

[Arend van Spriel]

This patch implements the idea to have multiple scheduled scan requests
running concurrently. It mainly illustrates how to deal with the incoming
request from user-space in terms of backward compatibility. In order to
use multiple scheduled scans user-space needs to provide a flag attribute
NL80211_ATTR_SCHED_SCAN_MULTI to indicate support. If not the request is
treated as a legacy scan.

Cc: Dmitry Shmidt <dimitr...@google.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
Hi Johannes,

Did a bit of coding on the Universal/multi-scheduled scan idea. This
just deals with handling requests. Not sure if I got the RCU stuff
right so any remarks are welcome.

Regards,
Arend
---
 include/net/cfg80211.h   |  7 
 include/uapi/linux/nl80211.h | 12 ++-
 net/wireless/core.c  | 30 ++--
 net/wireless/core.h  | 10 +-
 net/wireless/nl80211.c   | 38 ++--
 net/wireless/scan.c  | 83 +++-
 6 files changed, 148 insertions(+), 32 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 814be4b..f5c0592 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1594,6 +1594,7 @@ struct cfg80211_sched_scan_plan {
 /**
  * struct cfg80211_sched_scan_request - scheduled scan request description
  *
+ * @reqid: identifies this request.
  * @ssids: SSIDs to scan for (passed in the probe_reqs in active scans)
  * @n_ssids: number of SSIDs
  * @n_channels: total number of channels to scan
@@ -1622,12 +1623,14 @@ struct cfg80211_sched_scan_plan {
  * @rcu_head: RCU callback used to free the struct
  * @owner_nlportid: netlink portid of owner (if this should is a request
  * owned by a particular socket)
+ * @list: for keeping list of requests.
  * @delay: delay in seconds to use before starting the first scan
  * cycle.  The driver may ignore this parameter and start
  * immediately (or at any other time), if this feature is not
  * supported.
  */
 struct cfg80211_sched_scan_request {
+   u64 reqid;
struct cfg80211_ssid *ssids;
int n_ssids;
u32 n_channels;
@@ -1651,6 +1654,7 @@ struct cfg80211_sched_scan_request {
unsigned long scan_start;
struct rcu_head rcu_head;
u32 owner_nlportid;
+   struct list_head list;
 
/* keep last */
struct ieee80211_channel *channels[0];
@@ -3415,6 +3419,8 @@ struct wiphy_iftype_ext_capab {
  * this variable determines its size
  * @max_scan_ssids: maximum number of SSIDs the device can scan for in
  * any given scan
+ * @max_sched_scan_reqs: maximum number of scheduled scan requests that
+ * the device can run concurrently.
  * @max_sched_scan_ssids: maximum number of SSIDs the device can scan
  * for in any given scheduled scan
  * @max_match_sets: maximum number of match sets the device can handle
@@ -3547,6 +3553,7 @@ struct wiphy {
 
int bss_priv_size;
u8 max_scan_ssids;
+   u8 max_sched_scan_reqs;
u8 max_sched_scan_ssids;
u8 max_match_sets;
u16 max_scan_ie_len;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6b76e3b..4045058 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -351,7 +351,9 @@
  * are used.  Extra IEs can also be passed from the userspace by
  * using the %NL80211_ATTR_IE attribute.  The first cycle of the
  * scheduled scan can be delayed by %NL80211_ATTR_SCHED_SCAN_DELAY
- * is supplied.
+ * is supplied. If the device supports multiple concurrent scheduled
+ * scans, it will allow such when the caller provides the flag attribute
+ * %NL80211_ATTR_SCHED_SCAN_MULTI to indicate user-space support for it.
  * @NL80211_CMD_STOP_SCHED_SCAN: stop a scheduled scan. Returns -ENOENT if
  * scheduled scan is not running. The caller may assume that as soon
  * as the call returns, it is safe to start a new scheduled scan again.
@@ -1980,6 +1982,11 @@ enum nl80211_commands {
  * @NL80211_ATTR_BSSID: The BSSID of the AP. Note that %NL80211_ATTR_MAC is 
also
  * used in various commands/events for specifying the BSSID.
  *
+ * @NL80211_ATTR_SCHED_SCAN_MULTI: flag attribute which user-space shall use to
+ * indicate that it supports multiple active scheduled scan requests.
+ * @NL80211_ATTR_SCHED_SCAN_MAX_REQS: indicates maximum number of scheduled
+ * scan request that may be active for the device (u8).
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2386,6 +2393,9 @@ enum nl80211_attrs {
 
NL80211_ATTR_BSSID,
 
+   NL80211_ATTR_SCHED_SCAN_MULTI,
+   NL80211_ATTR_SCHED_SCAN_MAX_REQS,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/core.c b/

Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs

[Arend Van Spriel]

On 20-12-2016 21:52, Malinen, Jouni wrote:
> On Fri, Dec 16, 2016 at 10:56:51AM +0100, Johannes Berg wrote:
>> On Thu, 2016-12-15 at 11:06 +, Malinen, Jouni wrote:
>>> Maybe the nl80211.h description was not clear enough, but the
>>> comments in cfg80211.h should be quite clear on how this was designed
>>> to work at the implementation level:
>>>
>>> "If the current connected BSS is in the 2.4 GHz band, other BSSs in
>>> the 2.4 GHz band to be reported should have better RSSI by
>>> @relative_rssi and other BSSs in the 5 GHz band to be reported should
>>> have better RSSI by (@relative_rssi - @relative_rssi_5g_pref).
>>> If the current connected BSS is in the 5 GHz band, other BSSs in the
>>> 2.4 GHz band to be reported should have better RSSI by
>>> (@relative_rssi + @relative_rssi_5g_pref) and other BSSs in the 5 GHz
>>> band to be reported should have better RSSI by by @relative_rssi."
>>
>> Oh, right. Should probably be in nl80211.h too, to set expectations
>> from userspace.
> 
> Sure, we can update that in the next revision.
> 
>>> At minimum, we would need to clearly document struct
>>> nl80211_bss_select_rssi_adjust, but even if we do, I'm not sure it
>>> really is ideal mechanism to move to now that I realized it is not an
>>> array, but a single band,delta pair.
>>
>> We can move to an array easily in the future by extending the attribute
>> length and advertising the number of array entries that are supported,
>> if that's your biggest concern? I don't see it as being very useful
>> right now since I don't think we'll see offloaded roaming between 2.4/5
>> and 60 GHz anytime soon. This may change when we add more bands later,
>> I suppose.
> 
> Hmm.. So do you want us to move to using this packed struct in the new
> attribute instead of using a signed 8-bit integer as the variable value?

That was my suggestion so it is more clear what user-space wants by
making it specify the band explicitly. So in the explanation above
reference to "5g" should be "specified band" etc. Whether you reuse the
packed struct nl80211_bss_select_rssi_adjust or come up with a new
(identical?) one is irrelevant to me.

Also I don't see the array issue. @relative_rssi_5g_pref with s8 value
seems same as @rssi_adjust with (band=5g, s8 value) packed together. Or
am I missing something here.

>>> If we are talking only about roaming within an ESS (a single SSID),
>>> that would sound clear, but which relative RSSI rules would apply if
>>> there are match sets for both the currently connected SSID and
>>> another SSID that the candidate BSS is for?
>>
>> Right, I see how this might become a problem. I generally see no issue
>> with supporting multiple matchsets with different SSIDs but all having
>> the "relative to connected BSS RSSI filter" (which would disregard the
>> SSID specified in the matchset), but this then would become a problem
>> when multiple matchsets are specified with *different* such RSSI
>> filters, e.g. one matchset would specify that you want a 5G preference
>> of 10dB, but the other would specify a preference of only 5dB.
>>
>> Conceptually in this approach, that would be supported, but firmware
>> likely would not be able to express this, I suppose?
> 
> That's certainly not at the level we were planning on implementing.. :)

Right. So having "relative rssi" matchset attribute is off the table as
far as I am concerned.

>>> I think I'm missing something here.. Where would the threshold value
>>> (how much better new BSS needs to be) be stored? And do we really
>>> want something like the combination of
>>> NL80211_BSS_SELECT_ATTR_BAND_PREF and
>>> NL80211_BSS_SELECT_ATTR_RSSI_ADJUST which seems to be two different
>>> ways of doing band preference (the former without specifying delta
>>> and the latter with specific delta)? Or am I still not understanding
>>> how NL80211_BSS_SELECT_ATTR_* really works?

It is documented here:

/**
 * enum nl80211_bss_select_attr - attributes for bss selection.
 *
[...]
 *
 * One and only one of these attributes are found within
%NL80211_ATTR_BSS_SELECT
 * for %NL80211_CMD_CONNECT. It specifies the required BSS selection
behaviour
 * which the driver shall use.
 */

It is checked in nl80211.c [1]

>> No, you're right, I missed the "better by" threshold.
>>
>> I think between that (unless we add that, we could technically extend
>> flag attributes to allow them being an int as well, or add a new one)
>> and the fact that the device may not support different relative RSSI
>> matches in different matchsets, I'm almost convinced that adding new
>> attributes is better.
> 
> I'm not completely sure how to interpret all this and also the last
> email from Arend in this thread. Could either (or both :) of you provide
> more detailed suggestion on what exactly you would like us to change, if
> anything, in the attribute design now so that we can try to close on
> this?

To summarize: 1) stick with the new attributes on request level (so not
matchset level), 2) use packed 

Re: [PATCH 1/2] brcm: add firmware for the BCM4356 SDIO device

[Arend Van Spriel]

On 19-12-2016 1:28, Rafał Miłecki wrote:
> Hi Arend,
> 
> On 18 December 2016 at 21:16, Arend van Spriel
> <arend.vanspr...@broadcom.com> wrote:
>> This patch adds firmware for the BCM4356 2x2 11ac SDIO device.
> 
> I'm really happy to see Broadcom submitting firmwares again! Is this a
> good moment to re-request for 4366c0 one?

Different business segment. Router group still working on a solution.
Will ask about status again :-(

Regards,
Arend

Re: wl1251 & mac address & calibration data

[Arend Van Spriel]

On 18-12-2016 13:09, Pali Rohár wrote:
> On Sunday 18 December 2016 12:54:00 Arend Van Spriel wrote:
>> On 18-12-2016 12:04, Pali Rohár wrote:
>>> On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
>>>> On 16-12-2016 11:40, Pali Rohár wrote:
>>>>> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
>>>>>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
>>>>>>> For the new API a solution for "fallback mechanisms" should be
>>>>>>> clean though and I am looking to stay as far as possible from
>>>>>>> the existing mess. A solution to help both the old API and new
>>>>>>> API is possible for the "fallback mechanism" though -- but for
>>>>>>> that I can only refer you at this point to some of Daniel
>>>>>>> Wagner and Tom Gunderson's firmwared deamon prospect. It
>>>>>>> should help pave the way for a clean solution and help address
>>>>>>> other stupid issues.
>>>>>>
>>>>>> The firmwared project is hosted here
>>>>>>
>>>>>> https://github.com/teg/firmwared
>>>>>>
>>>>>> As Luis pointed out, firmwared relies on
>>>>>> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
>>>>>
>>>>> I know. But it does not mean that I cannot enable this option at
>>>>> kernel compile time.
>>>>>
>>>>> Bigger problem is that currently request_firmware() first try to
>>>>> load firmware directly from VFS and after that (if fails)
>>>>> fallback to user helper.
>>>>>
>>>>> So I would need to extend kernel firmware code with new function
>>>>> (or flag) to not use VFS and try only user mode helper.
>>>>
>>>> Why do you need the user-mode helper anyway. This is all static
>>>> data, right?
>>>
>>> Those are static data, but device specific!
>>
>> So what?
>>
>>>> So why not cook up a firmware file in user-space once and put
>>>> it in /lib/firmware for the driver to request directly.
>>>
>>> 1. Violates FHS
>>
>> How?
>>
>>> 2. Does not work for readonly /, readonly /lib, readonly
>>> /lib/firmware
>>
>> Que?
>>
>>> 3. Backup & restore of rootfs between same devices does not work
>>> (as rootfs now contains device specific data).
>>
>> True.
>>
>>> 4. Sharing one rootfs (either via nfs or other technology) does not
>>> work for more devices (even in state when rootfs is used only by
>>> one device at one time).
>>
>> Indeed.
>>
>>> And it is common that N900 developers have rootfs in laptop and via
>>> usb (cdc_ether) exports it over nfs to N900 device and boot
>>> system. It basically break booting from one nfs-exported rootfs,
>>> as that export become model specific...
>>
>> These are all you choices and more a logistic issue. If your take is
>> that udev is the way to solve those, fine by me.
>>
>>>> Seems a bit
>>>> overkill to have a {e,}udev or whatever daemon running if the
>>>> result is always the same. Just my 2 cents.
>>>
>>> No it is not. It will break couple of other things in Linux and
>>> device
>>
>> Now I am curious. What "couple of other things" will be broken.
>>
>>> and model specific calibration data should not be in /lib/firmware!
>>> That directory is used for firmware files, not calibration.
>>
>> What is "firmware"? Really. These are binary blobs required to make
>> the device work. And guess what, your device needs calibration data.
>> Why make the distinction.
>>
>> Regards,
>> Arend
> 
> File wl1251-nvs.bin is provided by linux-firmware package and contains 
> default data which should be overriden by model specific calibrated 
> data.

Ah. Someone thought it was a good idea to provide the "one ring to rule
them all". Nice.

> But overwriting that one file is not possible as it next update of 
> linux-firmware package will overwrite it back. It break any normal usage 
> of package management.
> 
> Also it is ridiculously broken by design if some "boot" files needs to 
> be overwritten to initialize hardware properly. To not break booting you 
> need to overwrite that file before first boot. But without booting 
> device you cannot read calibration data. So some hack with autoreboot 
> after boot is needed. And how to detect that we have real overwritten 
> calibration data and not default one from linux-firmware? Any heuristic 
> or checks will be broken here. And no, nothing like you need to reboot 
> your device now (and similar concept) from windows world is not 
> accepted.

Well. After reading and creating calibration data you could just rebind
the driver to the device to have it probed again. But yeah, the default
one from linux-firmware should never have been there in the first place.

> "firmware" is one for chip. Any N900 device with wl1251 chip needs 
> exactly same firmware "wl1251-fw.bin". But every N900 needs different 
> calibration data which is not firmware.

Ok. This is exactly why Luis is giving the new API different name just
calling it "data".

Regards,
Arend

Re: wl1251 & mac address & calibration data

[Arend Van Spriel]

On 18-12-2016 12:04, Pali Rohár wrote:
> On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
>> On 16-12-2016 11:40, Pali Rohár wrote:
>>> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
>>>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
>>>>> For the new API a solution for "fallback mechanisms" should be
>>>>> clean though and I am looking to stay as far as possible from the
>>>>> existing mess. A solution to help both the old API and new API is
>>>>> possible for the "fallback mechanism" though -- but for that I
>>>>> can only refer you at this point to some of Daniel Wagner and
>>>>> Tom Gunderson's firmwared deamon prospect. It should help pave
>>>>> the way for a clean solution and help address other stupid
>>>>> issues.
>>>>
>>>> The firmwared project is hosted here
>>>>
>>>> https://github.com/teg/firmwared
>>>>
>>>> As Luis pointed out, firmwared relies on
>>>> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
>>>
>>> I know. But it does not mean that I cannot enable this option at
>>> kernel compile time.
>>>
>>> Bigger problem is that currently request_firmware() first try to
>>> load firmware directly from VFS and after that (if fails) fallback
>>> to user helper.
>>>
>>> So I would need to extend kernel firmware code with new function
>>> (or flag) to not use VFS and try only user mode helper.
>>
>> Why do you need the user-mode helper anyway. This is all static data,
>> right?
> 
> Those are static data, but device specific!

So what?

>> So why not cook up a firmware file in user-space once and put
>> it in /lib/firmware for the driver to request directly.
> 
> 1. Violates FHS

How?

> 2. Does not work for readonly /, readonly /lib, readonly /lib/firmware

Que?

> 3. Backup & restore of rootfs between same devices does not work (as 
> rootfs now contains device specific data).

True.

> 4. Sharing one rootfs (either via nfs or other technology) does not work 
> for more devices (even in state when rootfs is used only by one device 
> at one time).

Indeed.

> And it is common that N900 developers have rootfs in laptop and via usb 
> (cdc_ether) exports it over nfs to N900 device and boot system. It 
> basically break booting from one nfs-exported rootfs, as that export 
> become model specific...

These are all you choices and more a logistic issue. If your take is
that udev is the way to solve those, fine by me.

>> Seems a bit
>> overkill to have a {e,}udev or whatever daemon running if the result
>> is always the same. Just my 2 cents.
> 
> No it is not. It will break couple of other things in Linux and device 

Now I am curious. What "couple of other things" will be broken.

> and model specific calibration data should not be in /lib/firmware! That 
> directory is used for firmware files, not calibration.

What is "firmware"? Really. These are binary blobs required to make the
device work. And guess what, your device needs calibration data. Why
make the distinction.

Regards,
Arend

Re: wl1251 & mac address & calibration data

[Arend Van Spriel]

On 16-12-2016 11:40, Pali Rohár wrote:
> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
>>> For the new API a solution for "fallback mechanisms" should be
>>> clean though and I am looking to stay as far as possible from the
>>> existing mess. A solution to help both the old API and new API is
>>> possible for the "fallback mechanism" though -- but for that I can
>>> only refer you at this point to some of Daniel Wagner and Tom
>>> Gunderson's firmwared deamon prospect. It should help pave the way
>>> for a clean solution and help address other stupid issues.
>>
>> The firmwared project is hosted here
>>
>> https://github.com/teg/firmwared
>>
>> As Luis pointed out, firmwared relies on
>> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
> 
> I know. But it does not mean that I cannot enable this option at kernel 
> compile time.
> 
> Bigger problem is that currently request_firmware() first try to load 
> firmware directly from VFS and after that (if fails) fallback to user 
> helper.
> 
> So I would need to extend kernel firmware code with new function (or 
> flag) to not use VFS and try only user mode helper.

Why do you need the user-mode helper anyway. This is all static data,
right? So why not cook up a firmware file in user-space once and put it
in /lib/firmware for the driver to request directly. Seems a bit
overkill to have a {e,}udev or whatever daemon running if the result is
always the same. Just my 2 cents.

Regards,
Arend

Re: [RFC V3 03/11] nl80211: add support for gscan

[Arend Van Spriel]

On 16-12-2016 11:13, Johannes Berg wrote:
> On Wed, 2016-12-14 at 10:01 +0100, Arend Van Spriel wrote:
> 
>> Had to look for "> 16" ;-)
> 
> Sorry.
> 
>> Here an instance of the tab vs. space issue you mentioned. Will go
>> over the patch and fix that.
> 
> There were a few, not really interesting though - git would probably
> flag it anyway, or checkpatch :)
> 
>>> +   if (num_chans > 16)
>>> +   return -EINVAL;
>>
>> I suspect this is the restriction you were referring to. 
> 
> Yes.
> 
>> There is no
>> reason for this although the android wifi hal has max 16 channels in
>> a bucket so I might have picked that up. 
> 
> I thought I saw something with a u16 bitmap that seemed related, but I
> don't see that now so I'm probably just confused.
> 
>> So could a driver have a similar limit and should we add such to the
>> gscan capabilities? For instance our firmware api has a nasty
>> restriction of 64 channels for all buckets together, eg. can do 4
>> buckets of 16 channels each.
> 
> We do have a limit of the maximum scan buckets, which seems to be 16
> right now. We also have a limit on the number of channels per bucket,
> which is also 16, but no combined limit afaict (so 16x16 seems fine).
> 
> Maybe we do need some advertisement in that area then? Right now,
> wifihal seems to be able to read as capabilities the number of buckets
> (wifi_gscan_capabilities), but assumes the number of channels:
> 
> const unsigned MAX_CHANNELS= 16;
> const unsigned MAX_BUCKETS = 16;
> 
> I guess we took that and combined it, and you had more negotiation with
> Google ;-)

I was not so much involved with the initial gscan effort, but I guess
for brcm it might be true.

> We may then have to actually advertise the limit you have ("64 channels
> combined over all buckets"), unless you can get away with just
> advertising 4 buckets (and us saying 16 channels per bucket is enough?)
> 
> I'm a bit tempted to make this more forward compatible though and not
> hard-limit the number of channels per bucket in the code.

Indeed so I will remove it.

Regards,
Arend

Re: [RFC V3 04/11] nl80211: add driver api for gscan notifications

[Arend Van Spriel]

On 16-12-2016 11:02, Johannes Berg wrote:
> 
>> Not sure what is meant by "through the buckets".
> 
> TBH, I was handwaving because I don't understand this part of gscan
> well :-)
> 
>> Referring to your
>> remark/question in the "Unversal scan proposal" thread:
>>
>> """
>> I'm much more worried about the "bucket reporting" since that doesn't
>> fit into the current full BSS reporting model at all. What's your
>> suggestion for this?
>> """
>>
>> So this is exactly the dilemma I considered so I decided to stick
>> with the full BSS reporting model for gscan as well merely to get it
>> discussed so glad you brought it up ;-).
> 
> Heh.
> 
> Ok, so I missed that. Somehow I thought hidden in the buckets was a
> partial reporting :-)
> 
>> The problem here is that gscan is a vehicle that serves a number of
>> use-cases. So ignoring hotlists, ePNO, etc. the gscan configuration
>> still hold several notification types:
>>
>> - report after completing M scans capturing N best APs or a
>>   percentage of (M * N).
>> - report after completing a scan include a specific bucket.
>> - report full scan results.
>>
>> The first two notification trigger retrieval of gscan results which
>> are historic, ie. partial scan results for max M scans.
>>
>> As said earlier the universal scan proposal has some similarities to
>> gscan. Guess you share that as you are using the term "bucket
>> reporting" in that discussion ;-). The historic results are needed
>> for location (if I am not mistaken) so the full BSS reporting model
>> does not fit that. Question is what particular attribute in the
>> historic results is needed for location (suspecting only rssi and
>> possibly the timestamp, but would like to see that confirmed). I was
>> thinking about have historic storage in cfg80211 so we do not need a
>> per-driver solution.
> 
> Ok, now I'm starting to understand this better, I guess.
> 
> As far as I can tell from our code, for cached results we're reporting
> the following data:
> 
>  * some flags
>  * a scan ID
>  * and for each AP:
>* RSSI
>* timestamp
>* channel
>* BSSID
>* SSID (which internally we even have a separate table for and each
>AP just has an index to it, to save memory I guess)
>* beacon period
>* capability field
> 
> No IEs and similar things like differentiating probe response/beacon,
> so we can't use the full reporting for this.
> 
> I have no problem introducing a common storage for this, if necessary
> with some fields/nl attributes being optional, but I suspect this is
> actually a necessary part of gscan, otherwise you're not able to report
> all the necessary data?

If you just look at the gscan api in wifihal then yes. I was just
wondering whether "all the necessary data" really comprises all these
from a use-case perspective. As an example the api also has rtt fields,
but both brcm and intel solutions do not report that.

Regards,
Arend

[PATCH] nl80211: better describe field in struct nl80211_bss_select_rssi_adjust

[Arend van Spriel]

The two fields in struct nl80211_bss_select_rssi_adjust did not state
their type or unit. Adding documentation.

Reported-by: Jouni Malinen <j...@w1.fi>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 include/uapi/linux/nl80211.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6b76e3b..d74e10b 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4964,8 +4964,9 @@ enum nl80211_sched_scan_plan {
 /**
  * struct nl80211_bss_select_rssi_adjust - RSSI adjustment parameters.
  *
- * @band: band of BSS that must match for RSSI value adjustment.
- * @delta: value used to adjust the RSSI value of matching BSS.
+ * @band: band of BSS that must match for RSSI value adjustment. The value
+ * of this field is according to  nl80211_band.
+ * @delta: value used to adjust the RSSI value of matching BSS in dB.
  */
 struct nl80211_bss_select_rssi_adjust {
__u8 band;
-- 
1.9.1

[PATCH] nl80211: rework {sched_,}scan event related functions

[Arend van Spriel]

A couple of functions used with scan events were named with
term "send" although they were only preparing the the event
message so renamed those.

Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 net/wireless/nl80211.c | 34 --
 net/wireless/nl80211.h |  6 ++
 net/wireless/scan.c|  9 +
 3 files changed, 15 insertions(+), 34 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 3df85a7..727ca50 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -12810,7 +12810,7 @@ static int nl80211_add_scan_req(struct sk_buff *msg,
return -ENOBUFS;
 }
 
-static int nl80211_send_scan_msg(struct sk_buff *msg,
+static int nl80211_prep_scan_msg(struct sk_buff *msg,
 struct cfg80211_registered_device *rdev,
 struct wireless_dev *wdev,
 u32 portid, u32 seq, int flags,
@@ -12841,7 +12841,7 @@ static int nl80211_send_scan_msg(struct sk_buff *msg,
 }
 
 static int
-nl80211_send_sched_scan_msg(struct sk_buff *msg,
+nl80211_prep_sched_scan_msg(struct sk_buff *msg,
struct cfg80211_registered_device *rdev,
struct net_device *netdev,
u32 portid, u32 seq, int flags, u32 cmd)
@@ -12873,7 +12873,7 @@ void nl80211_send_scan_start(struct 
cfg80211_registered_device *rdev,
if (!msg)
return;
 
-   if (nl80211_send_scan_msg(msg, rdev, wdev, 0, 0, 0,
+   if (nl80211_prep_scan_msg(msg, rdev, wdev, 0, 0, 0,
  NL80211_CMD_TRIGGER_SCAN) < 0) {
nlmsg_free(msg);
return;
@@ -12892,7 +12892,7 @@ struct sk_buff *nl80211_build_scan_msg(struct 
cfg80211_registered_device *rdev,
if (!msg)
return NULL;
 
-   if (nl80211_send_scan_msg(msg, rdev, wdev, 0, 0, 0,
+   if (nl80211_prep_scan_msg(msg, rdev, wdev, 0, 0, 0,
  aborted ? NL80211_CMD_SCAN_ABORTED :
NL80211_CMD_NEW_SCAN_RESULTS) < 0) {
nlmsg_free(msg);
@@ -12902,31 +12902,13 @@ struct sk_buff *nl80211_build_scan_msg(struct 
cfg80211_registered_device *rdev,
return msg;
 }
 
-void nl80211_send_scan_result(struct cfg80211_registered_device *rdev,
- struct sk_buff *msg)
-{
-   if (!msg)
-   return;
-
-   genlmsg_multicast_netns(_fam, wiphy_net(>wiphy), msg, 0,
-   NL80211_MCGRP_SCAN, GFP_KERNEL);
-}
-
-void nl80211_send_sched_scan_results(struct cfg80211_registered_device *rdev,
-struct net_device *netdev)
+/* send message created by nl80211_build_scan_msg() */
+void nl80211_send_scan_msg(struct cfg80211_registered_device *rdev,
+  struct sk_buff *msg)
 {
-   struct sk_buff *msg;
-
-   msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
if (!msg)
return;
 
-   if (nl80211_send_sched_scan_msg(msg, rdev, netdev, 0, 0, 0,
-   NL80211_CMD_SCHED_SCAN_RESULTS) < 0) {
-   nlmsg_free(msg);
-   return;
-   }
-
genlmsg_multicast_netns(_fam, wiphy_net(>wiphy), msg, 0,
NL80211_MCGRP_SCAN, GFP_KERNEL);
 }
@@ -12940,7 +12922,7 @@ void nl80211_send_sched_scan(struct 
cfg80211_registered_device *rdev,
if (!msg)
return;
 
-   if (nl80211_send_sched_scan_msg(msg, rdev, netdev, 0, 0, 0, cmd) < 0) {
+   if (nl80211_prep_sched_scan_msg(msg, rdev, netdev, 0, 0, 0, cmd) < 0) {
nlmsg_free(msg);
return;
}
diff --git a/net/wireless/nl80211.h b/net/wireless/nl80211.h
index 7e3821d..75f8252 100644
--- a/net/wireless/nl80211.h
+++ b/net/wireless/nl80211.h
@@ -14,12 +14,10 @@ void nl80211_send_scan_start(struct 
cfg80211_registered_device *rdev,
 struct wireless_dev *wdev);
 struct sk_buff *nl80211_build_scan_msg(struct cfg80211_registered_device *rdev,
   struct wireless_dev *wdev, bool aborted);
-void nl80211_send_scan_result(struct cfg80211_registered_device *rdev,
- struct sk_buff *msg);
+void nl80211_send_scan_msg(struct cfg80211_registered_device *rdev,
+  struct sk_buff *msg);
 void nl80211_send_sched_scan(struct cfg80211_registered_device *rdev,
 struct net_device *netdev, u32 cmd);
-void nl80211_send_sched_scan_results(struct cfg80211_registered_device *rdev,
-struct net_device *netdev);
 void nl80211_common_reg_change_event(enum nl80211_commands cmd_id,
 struct regulatory_request *request);
 
diff --git a/net/wireless/scan.

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

[Arend Van Spriel]

On 15-12-2016 6:15, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
> 
> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
> ---
>  drivers/bluetooth/Makefile| 2 --
>  drivers/net/can/Makefile  | 1 -
>  drivers/net/ethernet/altera/Makefile  | 1 -
>  drivers/net/ethernet/atheros/alx/Makefile | 1 -
>  drivers/net/ethernet/freescale/Makefile   | 2 --
>  drivers/net/wireless/ath/Makefile | 2 --
>  drivers/net/wireless/ath/wil6210/Makefile | 2 --
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
>  drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -

For brcm80211 drivers:

Acked-by: Arend van Spriel <arend.vanspr...@broadcom.com>

Regards,
Arend

Re: wl1251 & mac address & calibration data

[Arend Van Spriel]

On 15-12-2016 16:33, Pali Rohár wrote:
> On Thu Dec 15 09:18:44 2016 Kalle Valo  wrote:
>> (Adding Luis because he has been working on request_firmware() lately)
>>
>> Pali Rohár  writes:
>>
> So no, there is no argument against... request_firmware() in
> fallback mode with userspace helper is by design blocking and
> waiting for userspace. But waiting for some change in DTS in
> kernel is just nonsense.

 I would just mark the wlan device with status = "disabled" and
 enable it in the overlay together with adding the NVS & MAC info.
>>>
>>> So if you think that this solution make sense, we can wait what net 
>>> wireless maintainers say about it...
>>>
>>> For me it looks like that solution can be:
>>>
>>> extending request_firmware() to use only userspace helper
>>
>> I haven't followed the discussion very closely but this is my preference
>> what drivers should do:
>>
>> 1) First the driver should do try to get the calibration data and mac
>>address from the device tree.
>>
> 
> Ok, but there is no (dynamic, device specific) data in DTS for N900. So 1) is 
> noop.

Uhm. What do you mean? You can propose a patch to the DT bindings [1] to
get it in there and create your N900 DTB or am I missing something here.
Are there hardware restrictions that do not allow you to boot with your
own DTB.

>> 2) If they are not in DT the driver should retrieve the calibration data
>>with request_firmware(). BUT with an option for user space to
>>implement that with a helper script so that the data can be created
>>dynamically, which I believe openwrt does with ath10k calibration
>>data right now.
> 
> Currently there is flag for request_firmware() that it should fallback to 
> user helper if direct VFS access not find needed firmware.
> 
> But this flag is not suitable as /lib/firmware already provides default (not 
> device specific) calibration data.
> 
> So I would suggest to add another flag/function which will primary use user 
> helper.

I recall Luis saying that user-mode helper (fallback) should be
discouraged, because there is no assurance that there is a user-mode
helper so you might just be pissing in the wind. The idea was to have a
dedicated API call that explicitly does the request towards user-space.

By the way, are we talking here about wl1251 device or driver as you
also mentioned wl12xx? I did not read the entire thread.

Regards,
Arend

Re: [RFC V3 04/11] nl80211: add driver api for gscan notifications

[Arend Van Spriel]

On 13-12-2016 17:20, Johannes Berg wrote:
> On Mon, 2016-12-12 at 11:59 +0000, Arend van Spriel wrote:
>> The driver can indicate gscan results are available or gscan
>> operation has stopped.
> 
> This patch is renumbering the previous patches' nl80211 API, which is
> best avoided, even if I do realize it doesn't matter now. :)

Indeed. Will be more careful in upcoming revision(s).

> Even here it's not clear how things are reported though. Somehow I
> thought that gscan was reporting only partial information through the
> buckets, or is that not true?

Not sure what is meant by "through the buckets". Referring to your
remark/question in the "Unversal scan proposal" thread:

"""
I'm much more worried about the "bucket reporting" since that doesn't
fit into the current full BSS reporting model at all. What's your
suggestion for this?
"""

So this is exactly the dilemma I considered so I decided to stick with
the full BSS reporting model for gscan as well merely to get it
discussed so glad you brought it up ;-). The problem here is that
gscan is a vehicle that serves a number of use-cases. So ignoring
hotlists, ePNO, etc. the gscan configuration still hold several
notification types:

- report after completing M scans capturing N best APs or a
  percentage of (M * N).
- report after completing a scan include a specific bucket.
- report full scan results.

The first two notification trigger retrieval of gscan results which are
historic, ie. partial scan results for max M scans.

As said earlier the universal scan proposal has some similarities to
gscan. Guess you share that as you are using the term "bucket reporting"
in that discussion ;-). The historic results are needed for location (if
I am not mistaken) so the full BSS reporting model does not fit that.
Question is what particular attribute in the historic results is needed
for location (suspecting only rssi and possibly the timestamp, but would
like to see that confirmed). I was thinking about have historic storage
in cfg80211 so we do not need a per-driver solution.

Regards,
Arend

Re: [RFC V3 03/11] nl80211: add support for gscan

[Arend Van Spriel]

On 13-12-2016 23:29, Johannes Berg wrote:
> On Tue, 2016-12-13 at 21:09 +0100, Arend Van Spriel wrote:
>>  
>>> There's a bit of a weird hard-coded restriction to 16 channels too,
>>> that's due to the bucket map?
>>
>> Uhm. Is there? I will check, but if you can give me a pointer where
>> to look it is appreciated.
> 
> Just look for "< 16" or "<= 16" or so in the patch. I do think that's
> because the channel map is a u16 though, not sure we'd want to change
> that.

Had to look for "> 16" ;-)

> + /* ignore channels if band is specified */
> + if (band_select)
> + return 0;
> +
> +nla_for_each_nested(chan,
tb[NL80211_GSCAN_BUCKET_ATTR_CHANNELS], rem) {
> +num_chans++;
> +}

Here an instance of the tab vs. space issue you mentioned. Will go over
the patch and fix that.

> + if (num_chans > 16)
> + return -EINVAL;

I suspect this is the restriction you were referring to. There is no
reason for this although the android wifi hal has max 16 channels in a
bucket so I might have picked that up. So could a driver have a similar
limit and should we add such to the gscan capabilities? For instance our
firmware api has a nasty restriction of 64 channels for all buckets
together, eg. can do 4 buckets of 16 channels each.

Regards,
Arend

Re: [RFC V3 03/11] nl80211: add support for gscan

[Arend Van Spriel]

On 13-12-2016 17:19, Johannes Berg wrote:
> On Mon, 2016-12-12 at 11:59 +0000, Arend van Spriel wrote:
>> This patch adds support for GScan which is a scan offload feature
>> used in Android.
> 
> Found a few places with spaces instead of tabs as indentation, and
> spurious braces around single-statement things, but other than that it
> looks fine from a patch/nl80211 POV.

I added a check in wiphy_register() in this patch which actually is more
appropriate with the "gscan capabilities" patch.

> Haven't really looked into the details of gscan itself now though,
> sorry.
> 
> There's a bit of a weird hard-coded restriction to 16 channels too,
> that's due to the bucket map?

Uhm. Is there? I will check, but if you can give me a pointer where to
look it is appreciated.

Regards,
Arend

Re: [RFC V3 01/11] nl80211: add reporting of gscan capabilities

[Arend Van Spriel]

On 13-12-2016 17:15, Johannes Berg wrote:
> 
>> +case 14:
>> +if (!rdev->wiphy.gscan) {
>> +/* done */
>> +state->split_start = 0;
>> +break;
>> +}
>>
> 
> Nit, but I'm not really happy with this - this assumes that case 14 is
> the last case, if anyone ever adds one we break this code but it would
> still work if the device has gscan. Move the gscan stuff into a new
> function and make that return immediately if gscan is NULL or so?

Agree. When coding this piece I was aware that this would need to change
when 'case 15' would be added, which is probably too easy to overlook. I
will change it.

Regards,
Arend

Re: [RFC V3 03/11] nl80211: add support for gscan

[Arend Van Spriel]

On 12-12-2016 18:43, Dan Williams wrote:
>> +
>> +/**
>> + * enum nl80211_bucket_band - GScan bucket band selection.
> Quite possibly this was already covered and somebody requested you to
> change this to the current name.  If that's the case, ignore this.

Nope. You are the first ;-)

> But shouldn't this enum and bucket_event_report include "gscan" in
> their name, like the other gscan specific stuff does?  Are these going
> to get used for something else too, and will that thing make sense with
> the word "bucket"?  Just "nl80211_bucket_band" is pretty generic.

I figured the term bucket was making it gscan specific, but you are
right. Will change it.

Thanks,
Arend

[RFC V3 04/11] nl80211: add driver api for gscan notifications

[Arend van Spriel]

The driver can indicate gscan results are available or gscan operation
has stopped.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 include/net/cfg80211.h   | 28 +
 include/uapi/linux/nl80211.h |  2 ++
 net/wireless/core.c  |  2 ++
 net/wireless/core.h  |  2 ++
 net/wireless/nl80211.c   | 19 +++
 net/wireless/nl80211.h   |  2 ++
 net/wireless/scan.c  | 58 
 net/wireless/trace.h | 10 
 8 files changed, 123 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8bc8842..4b02585 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4552,6 +4552,34 @@ void cfg80211_scan_done(struct cfg80211_scan_request 
*request,
 void cfg80211_sched_scan_stopped_rtnl(struct wiphy *wiphy);

 /**
+ * cfg80211_gscan_results - notify that new scan results are available
+ *
+ * @wiphy: the wiphy which got GScan results
+ */
+void cfg80211_gscan_results(struct wiphy *wiphy);
+
+/**
+ * cfg80211_gscan_stopped - notify that the GScan has stopped
+ *
+ * @wiphy: the wiphy on which the GScan stopped.
+ *
+ * The driver can call this function to inform cfg80211 that the
+ * GScan had to be stopped, for whatever reason.
+ */
+void cfg80211_gscan_stopped(struct wiphy *wiphy);
+
+/**
+ * cfg80211_gscan_stopped_rtnl - notify that the GScan has stopped
+ *
+ * @wiphy: the wiphy on which the GScan stopped.
+ *
+ * The driver can call this function to inform cfg80211 that the
+ * GScan had to be stopped, for whatever reason.
+ * This function should be called with rtnl locked.
+ */
+void cfg80211_gscan_stopped_rtnl(struct wiphy *wiphy);
+
+/**
  * cfg80211_inform_bss_frame_data - inform cfg80211 of a received BSS frame
  * @wiphy: the wiphy reporting the BSS
  * @data: the BSS metadata
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 5e42383..fd7ccd2 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -896,6 +896,7 @@
  *
  * @NL80211_CMD_START_GSCAN: start GScan.
  * @NL80211_CMD_STOP_GSCAN: request to stop current GScan.
+ * @NL80211_CMD_GSCAN_RESULTS: indicates that there GScan results available.
  * @NL80211_CMD_GSCAN_STOPPED: indicates that the currently running GScan
  * has stopped. This event is generated upon @NL80211_CMD_STOP_GSCAN and
  * the driver may issue this event at any time when a GScan is running.
@@ -1101,6 +1102,7 @@ enum nl80211_commands {

NL80211_CMD_START_GSCAN,
NL80211_CMD_STOP_GSCAN,
+   NL80211_CMD_GSCAN_RESULTS,
NL80211_CMD_GSCAN_STOPPED,

/* add new commands above here */
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 760a2fb..69eea4c 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -453,6 +453,7 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, 
int sizeof_priv,
INIT_LIST_HEAD(>bss_list);
INIT_WORK(>scan_done_wk, __cfg80211_scan_done);
INIT_WORK(>sched_scan_results_wk, __cfg80211_sched_scan_results);
+   INIT_WORK(>gscan_results_wk, __cfg80211_gscan_results);
INIT_LIST_HEAD(>mlme_unreg);
spin_lock_init(>mlme_unreg_lock);
INIT_WORK(>mlme_unreg_wk, cfg80211_mlme_unreg_wk);
@@ -935,6 +936,7 @@ void wiphy_unregister(struct wiphy *wiphy)
cancel_delayed_work_sync(>dfs_update_channels_wk);
flush_work(>destroy_work);
flush_work(>sched_scan_stop_wk);
+   flush_work(>gscan_stop_wk);
flush_work(>mlme_unreg_wk);

 #ifdef CONFIG_PM
diff --git a/net/wireless/core.h b/net/wireless/core.h
index ee1d162..89e934f 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -79,6 +79,7 @@ struct cfg80211_registered_device {
unsigned long suspend_at;
struct work_struct scan_done_wk;
struct work_struct sched_scan_results_wk;
+   struct work_struct gscan_results_wk;

struct genl_info *cur_cmd_info;

@@ -424,6 +425,7 @@ void ___cfg80211_scan_done(struct 
cfg80211_registered_device *rdev,
 void __cfg80211_sched_scan_results(struct work_struct *wk);
 int __cfg80211_stop_sched_scan(struct cfg80211_registered_device *rdev,
   bool driver_initiated);
+void __cfg80211_gscan_results(struct work_struct *wk);
 int __cfg80211_stop_gscan(struct cfg80211_registered_device *rdev,
  bool driver_initiated);
 void cfg80211_upload_connect_keys(struct wireless_dev *wdev);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 4186ece..7699b16 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -13302,6 +13302,25 @@ void nl80211_send_sched_scan_results(struct 
cfg80211_registered_devi

[RFC V3 06/11] brcmfmac: fix uninitialized field in scheduled scan ssid configuration

[Arend van Spriel]

The scheduled scan ssid configuration in firmware has a flags field that
was not initialized resulting in unexpected behaviour.

Fixes: e3bdb7cc0300 ("brcmfmac: fix handling ssids in .sched_scan_start() 
callback")
Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
index f273cab..9a25e79 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
@@ -137,6 +137,7 @@ static int brcmf_pno_add_ssid(struct brcmf_if *ifp, struct 
cfg80211_ssid *ssid,
pfn.wpa_auth = cpu_to_le32(BRCMF_PNO_WPA_AUTH_ANY);
pfn.wsec = cpu_to_le32(0);
pfn.infra = cpu_to_le32(1);
+   pfn.flags = 0;
if (active)
pfn.flags = cpu_to_le32(1 << BRCMF_PNO_HIDDEN_BIT);
pfn.ssid.SSID_len = cpu_to_le32(ssid->ssid_len);
--
1.9.1

[RFC V3 05/11] brcmfmac: fix memory leak in brcmf_cfg80211_attach()

[Arend van Spriel]

In brcmf_cfg80211_attach() there was one error path not properly
handled as it leaked memory allocated in brcmf_btcoex_attach().

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..7ffc4ab 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6868,7 +6868,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct 
brcmf_pub *drvr,

err = brcmf_p2p_attach(cfg, p2pdev_forced);
if (err) {
-   brcmf_err("P2P initilisation failed (%d)\n", err);
+   brcmf_err("P2P initialisation failed (%d)\n", err);
goto wiphy_unreg_out;
}
err = brcmf_btcoex_attach(cfg);
@@ -6893,7 +6893,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct 
brcmf_pub *drvr,
err = brcmf_fweh_activate_events(ifp);
if (err) {
brcmf_err("FWEH activation failed (%d)\n", err);
-   goto wiphy_unreg_out;
+   goto detach;
}

/* Fill in some of the advertised nl80211 supported features */
@@ -6908,6 +6908,9 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct 
brcmf_pub *drvr,

return cfg;

+detach:
+   brcmf_btcoex_detach(cfg);
+   brcmf_p2p_detach(>p2p);
 wiphy_unreg_out:
wiphy_unregister(cfg->wiphy);
 priv_out:
--
1.9.1

[RFC V3 10/11] brcmfmac: handle gscan events from firmware

[Arend van Spriel]

Handle the gscan events similar to scheduled scan. Collect all SSIDs found
in batch scan and add them to BSS list in cfg80211.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 200 ++---
 .../broadcom/brcm80211/brcmfmac/cfg80211.h |  10 +-
 .../wireless/broadcom/brcm80211/brcmfmac/fweh.h|   1 +
 .../broadcom/brcm80211/brcmfmac/fwil_types.h   |  29 +++
 4 files changed, 214 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 2b86c72..61636ad 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -733,6 +733,7 @@ s32 brcmf_notify_escan_complete(struct brcmf_cfg80211_info 
*cfg,
 {
struct brcmf_scan_params_le params_le;
struct cfg80211_scan_request *scan_request;
+   enum brcmf_internal_escan_requestor rid;
s32 err = 0;

brcmf_dbg(SCAN, "Enter\n");
@@ -763,7 +764,7 @@ s32 brcmf_notify_escan_complete(struct brcmf_cfg80211_info 
*cfg,
err = brcmf_fil_cmd_data_set(ifp, BRCMF_C_SCAN,
 _le, sizeof(params_le));
if (err)
-   brcmf_err("Scan abort  failed\n");
+   brcmf_err("Scan abort failed\n");
}

brcmf_scan_config_mpc(ifp, 1);
@@ -772,11 +773,22 @@ s32 brcmf_notify_escan_complete(struct 
brcmf_cfg80211_info *cfg,
 * e-scan can be initiated internally
 * which takes precedence.
 */
-   if (cfg->internal_escan) {
-   brcmf_dbg(SCAN, "scheduled scan completed\n");
-   cfg->internal_escan = false;
+   if (cfg->escan_rid) {
+   rid = cfg->escan_rid;
+   cfg->escan_rid = INT_ESCAN_REQ_NONE;
+   brcmf_dbg(SCAN, "internal scan completed (%d)\n", rid);
if (!aborted)
-   cfg80211_sched_scan_results(cfg_to_wiphy(cfg));
+   switch (rid) {
+   case INT_ESCAN_REQ_SCHED_SCAN:
+   cfg80211_sched_scan_results(cfg_to_wiphy(cfg));
+   break;
+   case INT_ESCAN_REQ_GSCAN:
+   cfg80211_gscan_results(cfg_to_wiphy(cfg));
+   break;
+   default:
+   /* never happens */
+   break;
+   }
} else if (scan_request) {
struct cfg80211_scan_info info = {
.aborted = aborted,
@@ -1025,7 +1037,7 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
if (!ssid_le.SSID_len)
brcmf_dbg(SCAN, "%d: Broadcast scan\n", i);
else
-   brcmf_dbg(SCAN, "%d: scan for  %s size =%d\n",
+   brcmf_dbg(SCAN, "%d: scan for  %.32s size=%d\n",
  i, ssid_le.SSID, ssid_le.SSID_len);
memcpy(ptr, _le, sizeof(ssid_le));
ptr += sizeof(ssid_le);
@@ -3025,7 +3037,7 @@ void brcmf_abort_scanning(struct brcmf_cfg80211_info *cfg)
struct escan_info *escan = >escan_info;

set_bit(BRCMF_SCAN_STATUS_ABORT, >scan_status);
-   if (cfg->internal_escan || cfg->scan_request) {
+   if (cfg->escan_rid || cfg->scan_request) {
escan->escan_state = WL_ESCAN_STATE_IDLE;
brcmf_notify_escan_complete(cfg, escan->ifp, true, true);
}
@@ -3048,7 +3060,7 @@ static void brcmf_escan_timeout(unsigned long data)
struct brcmf_cfg80211_info *cfg =
(struct brcmf_cfg80211_info *)data;

-   if (cfg->internal_escan || cfg->scan_request) {
+   if (cfg->escan_rid || cfg->scan_request) {
brcmf_err("timer expired\n");
schedule_work(>escan_timeout_work);
}
@@ -3131,7 +3143,7 @@ static void brcmf_escan_timeout(unsigned long data)
if (brcmf_p2p_scan_finding_common_channel(cfg, bss_info_le))
goto exit;

-   if (!cfg->internal_escan && !cfg->scan_request) {
+   if (!cfg->escan_rid && !cfg->scan_request) {
brcmf_dbg(SCAN, "result without cfg80211 requ

[RFC V3 03/11] nl80211: add support for gscan

[Arend van Spriel]

This patch adds support for GScan which is a scan offload feature
used in Android.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
Changes:
 V2
  - remove pr_err() statement from nl80211.c
  - get rid of #if 0 code.
 V3
  - change and document storage type of gscan attributes.
  - remove base period attribute from nl80211.
  - bucket periods are changed to be seconds.
  - change NO_IR attribute to PASSIVE.
  - check for NL80211_ATTR_MAC{,_MASK} if random mac support is requested.
  - remove NL80211_SCAN_FLAG_IE_DATA.
---
 include/net/cfg80211.h   |  91 +++
 include/uapi/linux/nl80211.h | 146 ++
 net/wireless/core.c  |  31 
 net/wireless/core.h  |   4 +
 net/wireless/nl80211.c   | 356 ++-
 net/wireless/rdev-ops.h  |  25 +++
 net/wireless/scan.c  |  28 
 net/wireless/trace.h |   9 ++
 8 files changed, 685 insertions(+), 5 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b78377f..8bc8842 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2453,6 +2453,92 @@ struct cfg80211_nan_func {
 };

 /**
+ * struct cfg80211_gscan_channel - GScan channel parameters.
+ *
+
+ * @ch: specific channel.
+ * @dwell_time: hint for dwell time in milliseconds.
+ * @passive: indicates passive scan is requested.
+ */
+struct cfg80211_gscan_channel {
+struct ieee80211_channel *ch;
+u8 dwell_time;
+bool passive;
+};
+
+/**
+ * struct cfg80211_gscan_bucket - GScan bucket parameters.
+ *
+ * @idx: unique bucket index.
+ * @band: bit flags for band(s) to use, see %enum nl80211_bucket_band.
+ * @report_events: This is a bit field according %enum 
nl80211_bucket_report_event.
+ * @period: period in which the bucket is scheduled to be scanned. If the
+ * period is too small for driver it should not fail but report results
+ * as fast as it can. For exponential backoff bucket this is the minimum
+ * period.
+ * @max_period: used only for the exponential backoff bucket whose scan period
+ * will grow exponentially to a maximum period of max_period.
+ * @exponent: used only for the exponential backoff bucket.
+ * @step_count: used only for the exponential backoff bucket.
+ * @n_channels: number of channels in @channels array.
+ * @channels: channels to scan which may include DFS channels.
+ */
+struct cfg80211_gscan_bucket {
+   u32 idx;
+   u16 period;
+   u8 band;
+   u8 report_events;
+   u16 max_period;
+   u8 exponent;
+   u8 step_count;
+   u8 n_channels;
+   struct cfg80211_gscan_channel *channels;
+};
+
+/**
+ * struct cfg80211_gscan_request - GScan request parameters.
+ *
+ * @flags: scan request flags according %enum nl80211_scan_flags.
+ * @base_period: base timer period in milliseconds.
+ * @max_ap_per_scan: number of APs to store in each scan entry in the 
BSSID/RSSI
+ * history buffer (keep APS with highest RSSI).
+ * @report_threshold_percent: wake up system when scan buffer is filled to this
+ * percentage.
+ * @report_threshold_num_scans: wake up system when this many scans are stored
+ * in scan buffer.
+ * @mac: MAC address used for randomisation.
+ * @mac_mask: MAC address mask. bits that are 0 in the mask should be
+ * randomised, bits that are 1 should be taken as is from @mac.
+ * @n_buckets: number of entries in @buckets array.
+ * @buckets: array of GScan buckets.
+ *
+ * @dev: net device for which GScan is requested.
+ * @rcu_head: RCU callback used to free the struct.
+ * @owner_nlportid: netlink port which initiated this request.
+ * @scan_start: start time of this scan in jiffies.
+ */
+struct cfg80211_gscan_request {
+   u32 flags;
+   u16 base_period;
+   u8 max_ap_per_scan;
+   u8 report_threshold_percent;
+   u8 report_threshold_num_scans;
+   u8 mac[ETH_ALEN];
+   u8 mac_mask[ETH_ALEN];
+
+   u8 n_buckets;
+
+   /* internal */
+   struct net_device *dev;
+   struct rcu_head rcu_head;
+   u32 owner_nlportid;
+   unsigned long scan_start;
+
+   /* keep last */
+   struct cfg80211_gscan_bucket buckets[0];
+};
+
+/**
  * struct cfg80211_ops - backend description for wireless configuration
  *
  * This struct is registered by fullmac card drivers and/or wireless stacks
@@ -2764,6 +2850,8 @@ struct cfg80211_nan_func {
  * All other parameters must be ignored.
  *
  * @set_multicast_to_unicast: configure multicast to unicast conversion for BSS
+ * @start_gscan: start the GSCAN scanning offload.
+ * @stop_gscan: stop the GSCAN scanning offload.
  */
 struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -3048,6 +3136,9 @@ struct cf

[RFC V3 08/11] brcmfmac: report gscan capabilities if firmware supports it

[Arend van Spriel]

From: Arend van Spriel <ar...@broadcom.com>

Fill the gscan capability information in the wiphy structure if
it is supported by firmware. The values are hardcoded as it can
not be obtained from firmware.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <ar...@broadcom.com>
---
 .../wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 7ffc4ab..374b72c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -207,6 +207,16 @@ static bool check_vif_up(struct brcmf_cfg80211_vif *vif)
REG_RULE(5470-10, 5850+10, 80, 6, 20, 0), }
 };

+static const struct wiphy_gscan_caps brcmf_gscan_caps = {
+   .max_scan_cache_size = 320,
+   .max_scan_buckets = 8,
+   .max_ap_cache_per_scan = 32,
+   .max_rssi_sample_size = 8,
+   .max_scan_reporting_threshold = 100,
+   .max_hotlist_bssids = 64,
+   .max_significant_wifi_change_aps = 16,
+};
+
 /* Note: brcmf_cipher_suites is an array of int defining which cipher suites
  * are supported. A pointer to this array and the number of entries is passed
  * on to upper layers. AES_CMAC defines whether or not the driver supports MFP.
@@ -6426,7 +6436,12 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct 
brcmf_if *ifp)
wiphy->max_remain_on_channel_duration = 5000;
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_PNO))
brcmf_wiphy_pno_params(wiphy);
-
+   if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_GSCAN)) {
+   wiphy->gscan = kmemdup(_gscan_caps,
+  sizeof(brcmf_gscan_caps), GFP_KERNEL);
+   if (!wiphy->gscan)
+   return -ENOMEM;
+   }
/* vendor commands/events support */
wiphy->vendor_commands = brcmf_vendor_cmds;
wiphy->n_vendor_commands = BRCMF_VNDR_CMDS_LAST - 1;
@@ -6735,6 +6750,7 @@ static void brcmf_free_wiphy(struct wiphy *wiphy)
if (!wiphy)
return;

+   kfree(wiphy->gscan);
if (wiphy->iface_combinations) {
for (i = 0; i < wiphy->n_iface_combinations; i++)
kfree(wiphy->iface_combinations[i].limits);
--
1.9.1

[RFC V3 00/11] nl80211: add support for g-scan

[Arend van Spriel]

Android employs a Wifi-HAL layer in its wireless frame. It basically abstracts
dealing with netlink messages from the framework. For some features it employs
nl80211 vendor commands. The goal I set myself is to be able to have a generic
nl80211 Wifi-HAL implementation. One of the features currently requiring the
vendor commands is g-scan. We can only guess what the 'g' stands for ;-) This
series converts the vendor command api into common nl80211 api.

This series adds basic support of g-scan (or GScan, or gscan, or something
completely different; suggestions are welcome). A basic g-scan request consists
of some common attributes and so-called buckets. Each bucket represents a
re-occurring scan request with a given interval and a set of channels. The
common attributes specify how much scans (m) should be stored and how many
BSS-es (n) should be kept per scan before an event is sent. The other option
is to specify a percentage at which an event is sent, where 100% equals (m * n).
A special case of bucket is the exponential backoff bucket, which has an
increasing interval.

The series is applied on top of master branch of wireless-testing as it relied
on patches pending in wireless-drivers-next. As such this series include two
fixes against those pending patched. Hopefully using wireless-testing allows
the nl80211 changes in this series to apply to mac80211-next. I consider it
still in RFC state so it may not matter right now.

Changes:
 V2
  - remove pr_err() statement from nl80211.c
  - get rid of #if 0 code.
  - reordered patches resolving compilation issue.
 V3
  - drop support for RTT info in scan results.
  - cleanup attribute definitions.
  - add driver implementation for brcmfmac.

Arend van Spriel (11):
  nl80211: add reporting of gscan capabilities
  nl80211: rename some notification functions
  nl80211: add support for gscan
  nl80211: add driver api for gscan notifications
  brcmfmac: fix memory leak in brcmf_cfg80211_attach()
  brcmfmac: fix uninitialized field in scheduled scan ssid configuration
  brcmfmac: add firmware feature detection for gscan feature
  brcmfmac: report gscan capabilities if firmware supports it
  brcmfmac: implement gscan functionality
  brcmfmac: handle gscan events from firmware
  brcmfmac: allow gscan to run concurrent with scheduled scan

 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 266 +++--
 .../broadcom/brcm80211/brcmfmac/cfg80211.h |  12 +-
 .../wireless/broadcom/brcm80211/brcmfmac/core.c|   5 +-
 .../wireless/broadcom/brcm80211/brcmfmac/debug.h   |   2 +
 .../wireless/broadcom/brcm80211/brcmfmac/feature.c |  22 +-
 .../wireless/broadcom/brcm80211/brcmfmac/feature.h |   4 +-
 .../wireless/broadcom/brcm80211/brcmfmac/fweh.h|   1 +
 .../broadcom/brcm80211/brcmfmac/fwil_types.h   |  92 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 381 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/pno.h |  37 ++
 include/net/cfg80211.h | 155 
 include/uapi/linux/nl80211.h   | 207 ++
 net/wireless/core.c|  33 ++
 net/wireless/core.h|   6 +
 net/wireless/nl80211.c | 430 -
 net/wireless/nl80211.h |   4 +-
 net/wireless/rdev-ops.h|  25 ++
 net/wireless/scan.c|  90 -
 net/wireless/trace.h   |  19 +
 19 files changed, 1726 insertions(+), 65 deletions(-)

--
1.9.1

[RFC V3 11/11] brcmfmac: allow gscan to run concurrent with scheduled scan

[Arend van Spriel]

On Android the gscan functionality is initiated by the wifi framework
whereas the scheduled scan can be initiated by wpa_supplicant. As such
it is required that these two scan types can run simultaneously.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c |  12 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.h |   2 +
 .../wireless/broadcom/brcm80211/brcmfmac/core.c|   5 +-
 .../wireless/broadcom/brcm80211/brcmfmac/debug.h   |   2 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 278 -
 .../net/wireless/broadcom/brcm80211/brcmfmac/pno.h |  28 +++
 6 files changed, 267 insertions(+), 60 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 61636ad..7749610 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3432,7 +3432,7 @@ static int brcmf_cfg80211_sched_scan_stop(struct wiphy 
*wiphy,
struct brcmf_if *ifp = netdev_priv(ndev);

brcmf_dbg(SCAN, "enter\n");
-   brcmf_pno_clean(ifp);
+   brcmf_pno_stop_sched_scan(ifp);
if (cfg->escan_rid)
brcmf_notify_escan_complete(cfg, ifp, true, true);
return 0;
@@ -5256,7 +5256,7 @@ static int brcmf_cfg80211_stop_gscan(struct wiphy *wiphy,

brcmf_dbg(TRACE, "Enter, bssidx=%d\n", ifp->bsscfgidx);

-   return brcmf_pno_clean(ifp);
+   return brcmf_pno_stop_gscan(ifp);
 }

 #ifdef CONFIG_PM
@@ -7076,6 +7076,13 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct 
brcmf_pub *drvr,
brcmf_p2p_detach(>p2p);
goto wiphy_unreg_out;
}
+   err = brcmf_pno_attach(ifp);
+   if (err) {
+   brcmf_err("PNO initialisation failed (%d)\n", err);
+   brcmf_btcoex_detach(cfg);
+   brcmf_p2p_detach(>p2p);
+   goto wiphy_unreg_out;
+   }

if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_TDLS)) {
err = brcmf_fil_iovar_int_set(ifp, "tdls_enable", 1);
@@ -7108,6 +7115,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct 
brcmf_pub *drvr,
return cfg;

 detach:
+   brcmf_pno_detach(ifp);
brcmf_btcoex_detach(cfg);
brcmf_p2p_detach(>p2p);
 wiphy_unreg_out:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
index ff65970..b9f9375 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
@@ -293,6 +293,7 @@ enum brcmf_internal_escan_requestor {
  * @vif_cnt: number of vif instances.
  * @vif_event: vif event signalling.
  * @wowl: wowl related information.
+ * @pi: information of pno module.
  */
 struct brcmf_cfg80211_info {
struct wiphy *wiphy;
@@ -326,6 +327,7 @@ struct brcmf_cfg80211_info {
struct brcmu_d11inf d11inf;
struct brcmf_assoclist_le assoclist;
struct brcmf_cfg80211_wowl wowl;
+   struct brcmf_pno_info *pi;
 };

 /**
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 9e6f60a..c72653d1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -30,6 +30,7 @@
 #include "debug.h"
 #include "fwil_types.h"
 #include "p2p.h"
+#include "pno.h"
 #include "cfg80211.h"
 #include "fwil.h"
 #include "fwsignal.h"
@@ -1118,8 +1119,10 @@ void brcmf_detach(struct device *dev)

/* stop firmware event handling */
brcmf_fweh_detach(drvr);
-   if (drvr->config)
+   if (drvr->config) {
+   brcmf_pno_detach(bus_if->drvr->iflist[0]);
brcmf_p2p_detach(>config->p2p);
+   }

brcmf_bus_change_state(bus_if, BRCMF_BUS_DOWN);

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
index 6687812..efc17b9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
@@ -82,6 +82,7 @@
 #define BRCMF_EVENT_ON()   (brcmf_msg_level & BRCMF_EVENT_VAL)
 #define BRCMF_FIL_ON() (brcmf_msg_level & BRCMF_FIL_VAL)
 #define BRCMF_FWCON_ON()   (brcmf_msg_level & BRCMF_FWCON_VAL)
+#define BRCMF_SCAN_ON()(brcmf_msg_level & BRCMF_SCAN_VAL)

 #else /* defined(DE

[RFC V3 09/11] brcmfmac: implement gscan functionality

[Arend van Spriel]

This patch implements configuration of gscan in the device. Handling
the results is done in subsequent change. This initial implementation
does not support running scheduled scan and gscan simultaneously.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c |  31 
 .../broadcom/brcm80211/brcmfmac/fwil_types.h   |  18 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 184 -
 .../net/wireless/broadcom/brcm80211/brcmfmac/pno.h |   9 +
 4 files changed, 233 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 374b72c..2b86c72 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -5081,6 +5081,35 @@ static int brcmf_cfg80211_tdls_oper(struct wiphy *wiphy,
return ret;
 }

+static int brcmf_cfg80211_start_gscan(struct wiphy *wiphy,
+ struct net_device *ndev,
+ struct cfg80211_gscan_request *req)
+{
+   struct brcmf_if *ifp = netdev_priv(ndev);
+   struct brcmf_cfg80211_info *cfg = wiphy_priv(wiphy);
+
+   brcmf_dbg(SCAN, "Enter: n_buckets=%d\n", req->n_buckets);
+
+   if (test_bit(BRCMF_SCAN_STATUS_SUPPRESS, >scan_status)) {
+   brcmf_err("Scanning suppressed: status (%lu)\n",
+ cfg->scan_status);
+   return -EAGAIN;
+   }
+
+   /* configure gscan */
+   return brcmf_pno_start_gscan(ifp, req);
+}
+
+static int brcmf_cfg80211_stop_gscan(struct wiphy *wiphy,
+struct net_device *ndev)
+{
+   struct brcmf_if *ifp = netdev_priv(ndev);
+
+   brcmf_dbg(TRACE, "Enter, bssidx=%d\n", ifp->bsscfgidx);
+
+   return brcmf_pno_clean(ifp);
+}
+
 #ifdef CONFIG_PM
 static int
 brcmf_cfg80211_set_rekey_data(struct wiphy *wiphy, struct net_device *ndev,
@@ -5148,6 +5177,8 @@ static int brcmf_cfg80211_tdls_oper(struct wiphy *wiphy,
.crit_proto_start = brcmf_cfg80211_crit_proto_start,
.crit_proto_stop = brcmf_cfg80211_crit_proto_stop,
.tdls_oper = brcmf_cfg80211_tdls_oper,
+   .start_gscan = brcmf_cfg80211_start_gscan,
+   .stop_gscan = brcmf_cfg80211_stop_gscan,
 };

 struct brcmf_cfg80211_vif *brcmf_alloc_vif(struct brcmf_cfg80211_info *cfg,
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index 8c18fad..262642d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -855,16 +855,20 @@ struct brcmf_gscan_bucket_config {
 };

 /* version supported which must match firmware */
-#define BRCMF_GSCAN_CFG_VERSION 1
+#define BRCMF_GSCAN_CFG_VERSION 2

 /**
  * enum brcmf_gscan_cfg_flags - bit values for gscan flags.
  *
  * @BRCMF_GSCAN_CFG_FLAGS_ALL_RESULTS: send probe responses/beacons to host.
+ * @BRCMF_GSCAN_CFG_ALL_BUCKETS_IN_1ST_SCAN: all buckets will be included in
+ * first scan cycle.
  * @BRCMF_GSCAN_CFG_FLAGS_CHANGE_ONLY: indicated only flags member is changed.
+ *
  */
 enum brcmf_gscan_cfg_flags {
BRCMF_GSCAN_CFG_FLAGS_ALL_RESULTS = BIT(0),
+   BRCMF_GSCAN_CFG_ALL_BUCKETS_IN_1ST_SCAN = BIT(3),
BRCMF_GSCAN_CFG_FLAGS_CHANGE_ONLY = BIT(7),
 };

@@ -884,12 +888,12 @@ enum brcmf_gscan_cfg_flags {
  */
 struct brcmf_gscan_config {
__le16 version;
-   u8  flags;
-   u8   buffer_threshold;
-   u8   swc_nbssid_threshold;
-   u8  swc_rssi_window_size;
-   u8  count_of_channel_buckets;
-   u8  retry_threshold;
+   u8 flags;
+   u8 buffer_threshold;
+   u8 swc_nbssid_threshold;
+   u8 swc_rssi_window_size;
+   u8 count_of_channel_buckets;
+   u8 retry_threshold;
__le16  lost_ap_window;
struct brcmf_gscan_bucket_config bucket[1];
 };
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
index 9a25e79..b868997 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
@@ -35,6 +35,9 @@
 #define BRCMF_PNO_HIDDEN_BIT   2
 #define BRCMF_PNO_SCHED_SCAN_PERIOD30

+#define GSCAN_BATCH_NO_THR_SET 101
+#define GSCAN_RETRY_THRESHOLD  3
+
 static int brcmf_pno_channel_config(struct brcmf_if *ifp,
struct brcmf_pno_config_le *cfg)
 {

[RFC V3 02/11] nl80211: rename some notification functions

[Arend van Spriel]

The functions nl80211_send_sched_scan() and nl80211_send_sched_scan_msg()
take command as parameter, which strictly speaking makes them general
purpose and not directly related to scheduled scan functionality. The
message are sent to "scan" multicast group so renaming them to
nl80211_send_scan_event{,_msg}().

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 net/wireless/nl80211.c | 10 +-
 net/wireless/nl80211.h |  2 +-
 net/wireless/scan.c|  4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 40209ec..14e1940 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7247,7 +7247,7 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,

rcu_assign_pointer(rdev->sched_scan_req, sched_scan_req);

-   nl80211_send_sched_scan(rdev, dev,
+   nl80211_send_scan_event(rdev, dev,
NL80211_CMD_START_SCHED_SCAN);
return 0;

@@ -12878,7 +12878,7 @@ static int nl80211_send_scan_msg(struct sk_buff *msg,
 }

 static int
-nl80211_send_sched_scan_msg(struct sk_buff *msg,
+nl80211_send_scan_event_msg(struct sk_buff *msg,
struct cfg80211_registered_device *rdev,
struct net_device *netdev,
u32 portid, u32 seq, int flags, u32 cmd)
@@ -12958,7 +12958,7 @@ void nl80211_send_sched_scan_results(struct 
cfg80211_registered_device *rdev,
if (!msg)
return;

-   if (nl80211_send_sched_scan_msg(msg, rdev, netdev, 0, 0, 0,
+   if (nl80211_send_scan_event_msg(msg, rdev, netdev, 0, 0, 0,
NL80211_CMD_SCHED_SCAN_RESULTS) < 0) {
nlmsg_free(msg);
return;
@@ -12968,7 +12968,7 @@ void nl80211_send_sched_scan_results(struct 
cfg80211_registered_device *rdev,
NL80211_MCGRP_SCAN, GFP_KERNEL);
 }

-void nl80211_send_sched_scan(struct cfg80211_registered_device *rdev,
+void nl80211_send_scan_event(struct cfg80211_registered_device *rdev,
 struct net_device *netdev, u32 cmd)
 {
struct sk_buff *msg;
@@ -12977,7 +12977,7 @@ void nl80211_send_sched_scan(struct 
cfg80211_registered_device *rdev,
if (!msg)
return;

-   if (nl80211_send_sched_scan_msg(msg, rdev, netdev, 0, 0, 0, cmd) < 0) {
+   if (nl80211_send_scan_event_msg(msg, rdev, netdev, 0, 0, 0, cmd) < 0) {
nlmsg_free(msg);
return;
}
diff --git a/net/wireless/nl80211.h b/net/wireless/nl80211.h
index 7e3821d..fb304ce9 100644
--- a/net/wireless/nl80211.h
+++ b/net/wireless/nl80211.h
@@ -16,7 +16,7 @@ struct sk_buff *nl80211_build_scan_msg(struct 
cfg80211_registered_device *rdev,
   struct wireless_dev *wdev, bool aborted);
 void nl80211_send_scan_result(struct cfg80211_registered_device *rdev,
  struct sk_buff *msg);
-void nl80211_send_sched_scan(struct cfg80211_registered_device *rdev,
+void nl80211_send_scan_event(struct cfg80211_registered_device *rdev,
 struct net_device *netdev, u32 cmd);
 void nl80211_send_sched_scan_results(struct cfg80211_registered_device *rdev,
 struct net_device *netdev);
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 35ad69f..174076b 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -378,7 +378,7 @@ int __cfg80211_stop_sched_scan(struct 
cfg80211_registered_device *rdev,
return err;
}

-   nl80211_send_sched_scan(rdev, dev, NL80211_CMD_SCHED_SCAN_STOPPED);
+   nl80211_send_scan_event(rdev, dev, NL80211_CMD_SCHED_SCAN_STOPPED);

RCU_INIT_POINTER(rdev->sched_scan_req, NULL);
kfree_rcu(sched_scan_req, rcu_head);
@@ -1147,7 +1147,7 @@ struct cfg80211_bss *
else
rcu_assign_pointer(tmp.pub.beacon_ies, ies);
rcu_assign_pointer(tmp.pub.ies, ies);
-
+
memcpy(tmp.pub.bssid, mgmt->bssid, ETH_ALEN);
tmp.pub.channel = channel;
tmp.pub.scan_width = data->scan_width;
--
1.9.1

[RFC V3 01/11] nl80211: add reporting of gscan capabilities

[Arend van Spriel]

From: Arend van Spriel <ar...@broadcom.com>

GScan is a scan offload feature used in recent Android releases. This
patch adds possibility for wireless device drivers to report their
capabilities and provide it to user-space.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <ar...@broadcom.com>
---
Changes:
 V3:
  - change storage types for capabilities.
---
 include/net/cfg80211.h   | 36 +++
 include/uapi/linux/nl80211.h | 59 
 net/wireless/nl80211.c   | 45 -
 3 files changed, 139 insertions(+), 1 deletion(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ef42749..b78377f 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3361,6 +3361,40 @@ struct wiphy_iftype_ext_capab {
 };

 /**
+ * struct wiphy_gscan_caps -  gscan capabilities of the device.
+ *
+ * @max_scan_cache_size: total space allocated for scan results (in bytes).
+ * @max_scan_buckets: maximum number of channel buckets.
+ * @max_ap_cache_per_scan: maximum number of APs that can be stored per scan.
+ * @max_rssi_sample_size: number of RSSI samples used for averaging RSSI.
+ * @max_scan_reporting_threshold: max possible report threshold. in percentage.
+ * @max_hotlist_bssids: maximum number of entries for hotlist BSSIDs.
+ * @max_hotlist_ssids: maximum number of entries for hotlist SSIDs.
+ * @max_significant_wifi_change_aps: maximum number of entries for significant
+ * change APs.
+ * @max_bssid_history_entries: number of BSSID/RSSI entries that device can
+ * hold.
+ * @max_epno_networks: max number of hashed epno entries.
+ * @max_epno_networks_by_ssid: max number of epno entries for which an
+ * exact match of SSID is required or which are hidded SSIDs.
+ * @max_white_list_ssid: max number of white listed SSIDs.
+ */
+struct wiphy_gscan_caps {
+   u16 max_scan_cache_size;
+   u8 max_scan_buckets;
+   u8 max_ap_cache_per_scan;
+   u8 max_rssi_sample_size;
+   u8 max_scan_reporting_threshold;
+   u8 max_hotlist_bssids;
+   u8 max_hotlist_ssids;
+   u8 max_significant_wifi_change_aps;
+   u8 max_bssid_history_entries;
+   u8 max_epno_hashed_networks;
+   u8 max_epno_exact_networks;
+   u8 max_white_list_ssid;
+};
+
+/**
  * struct wiphy - wireless hardware description
  * @reg_notifier: the driver's regulatory notification callback,
  * note that if your driver uses wiphy_apply_custom_regulatory()
@@ -3513,6 +3547,7 @@ struct wiphy_iftype_ext_capab {
  * @bss_select_support: bitmask indicating the BSS selection criteria supported
  * by the driver in the .connect() callback. The bit position maps to the
  * attribute indices defined in  nl80211_bss_select_attr.
+ * @gscan: structure holding the hardware capabilities for gscan.
  *
  * @cookie_counter: unique generic cookie counter, used to identify objects.
  */
@@ -3643,6 +3678,7 @@ struct wiphy {
u8 max_adj_channel_rssi_comp;

u32 bss_select_support;
+   const struct wiphy_gscan_caps *gscan;

u64 cookie_counter;

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6b76e3b..01ab2f7 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1980,6 +1980,9 @@ enum nl80211_commands {
  * @NL80211_ATTR_BSSID: The BSSID of the AP. Note that %NL80211_ATTR_MAC is 
also
  * used in various commands/events for specifying the BSSID.
  *
+ * @NL80211_ATTR_GSCAN_CAPS: indicating capabilities of GScan functionality
+ * of the device. This is a nested attribute.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2385,6 +2388,7 @@ enum nl80211_attrs {
NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED,

NL80211_ATTR_BSSID,
+   NL80211_ATTR_GSCAN_CAPS,

/* add attributes here, update the policy in nl80211.c */

@@ -5187,4 +5191,59 @@ enum nl80211_nan_match_attributes {
NL80211_NAN_MATCH_ATTR_MAX = NUM_NL80211_NAN_MATCH_ATTR - 1
 };

+/**
+ * enum nl80211_gscan_caps_attr - GScan capabilities attributes.
+ *
+ * @__NL80211_GSCAN_CAPS_ATTR_INVALID: reserved.
+ * @NL80211_GSCAN_CAPS_ATTR_MAX_SCAN_CACHE_SIZE: total space allocated for
+ * scan results in bytes (u16).
+ * @NL80211_GSCAN_CAPS_ATTR_MAX_SCAN_BUCKETS: maximum number of channel buckets
+ * allowed (u8).
+ * @NL80211_GSCAN_CAPS_ATTR_MAX_AP_CACHE_PER_SCAN: maximum number of APs that
+ * can be stored per scan (u8).
+ * @NL80211_GSCAN_CAPS_ATTR_MAX_RSSI_SAMPLE_SIZE: maximum number of RSSI 
samples
+ * used for averaging RSSI (u8).
+ * @NL80211_GSCAN_CAPS_ATTR_MAX_SCAN_REPORTING_THRESHOLD: maxi

[RFC V3 07/11] brcmfmac: add firmware feature detection for gscan feature

[Arend van Spriel]

From: Arend van Spriel <ar...@broadcom.com>

Detect gscan support in firmware by doing pfn_gscan_cfg iovar with
invalid version.

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <ar...@broadcom.com>
---
 .../wireless/broadcom/brcm80211/brcmfmac/feature.c | 22 +++-
 .../wireless/broadcom/brcm80211/brcmfmac/feature.h |  4 +-
 .../broadcom/brcm80211/brcmfmac/fwil_types.h   | 59 ++
 3 files changed, 83 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index 62985f2..8c7ef59 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -27,6 +27,7 @@
 #include "feature.h"
 #include "common.h"

+#define BRCMF_FW_UNSUPPORTED   23

 /*
  * expand feature list to array of feature strings.
@@ -113,6 +114,22 @@ static void brcmf_feat_iovar_int_get(struct brcmf_if *ifp,
}
 }

+static void brcmf_feat_iovar_data_set(struct brcmf_if *ifp,
+ enum brcmf_feat_id id, char *name,
+ const void *data, size_t len)
+{
+   int err;
+
+   err = brcmf_fil_iovar_data_set(ifp, name, data, len);
+   if (err != -BRCMF_FW_UNSUPPORTED) {
+   brcmf_dbg(INFO, "enabling feature: %s\n", brcmf_feat_names[id]);
+   ifp->drvr->feat_flags |= BIT(id);
+   } else {
+   brcmf_dbg(TRACE, "%s feature check failed: %d\n",
+ brcmf_feat_names[id], err);
+   }
+}
+
 static void brcmf_feat_firmware_capabilities(struct brcmf_if *ifp)
 {
char caps[256];
@@ -136,11 +153,14 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
 {
struct brcmf_if *ifp = brcmf_get_ifp(drvr, 0);
struct brcmf_pno_macaddr_le pfn_mac;
+   struct brcmf_gscan_config gscan_cfg;
u32 wowl_cap;
s32 err;

brcmf_feat_firmware_capabilities(ifp);
-
+   memset(_cfg, 0, sizeof(gscan_cfg));
+   brcmf_feat_iovar_data_set(ifp, BRCMF_FEAT_GSCAN, "pfn_gscan_cfg",
+ _cfg, sizeof(gscan_cfg));
brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_PNO, "pfn");
if (drvr->bus_if->wowl_supported)
brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_WOWL, "wowl");
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
index db4733a..c1dbd17 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
@@ -31,6 +31,7 @@
  * WOWL_GTK: (WOWL) GTK rekeying offload
  * WOWL_ARP_ND: ARP and Neighbor Discovery offload support during WOWL.
  * MFP: 802.11w Management Frame Protection.
+ * GSCAN: enhanced scan offload feature.
  */
 #define BRCMF_FEAT_LIST \
BRCMF_FEAT_DEF(MBSS) \
@@ -44,7 +45,8 @@
BRCMF_FEAT_DEF(WOWL_ND) \
BRCMF_FEAT_DEF(WOWL_GTK) \
BRCMF_FEAT_DEF(WOWL_ARP_ND) \
-   BRCMF_FEAT_DEF(MFP)
+   BRCMF_FEAT_DEF(MFP) \
+   BRCMF_FEAT_DEF(GSCAN)

 /*
  * Quirks:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index 9a1eb5a..8c18fad 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -835,4 +835,63 @@ struct brcmf_gtk_keyinfo_le {
u8 replay_counter[BRCMF_RSN_REPLAY_LEN];
 };

+/**
+ * struct brcmf_gscan_bucket_config - configuration data for channel bucket.
+ *
+ * @bucket_end_index: !unknown!
+ * @bucket_freq_multiple: !unknown!
+ * @flag: !unknown!
+ * @reserved: !unknown!
+ * @repeat: !unknown!
+ * @max_freq_multiple: !unknown!
+ */
+struct brcmf_gscan_bucket_config {
+   u8 bucket_end_index;
+   u8 bucket_freq_multiple;
+   u8 flag;
+   u8 reserved;
+   __le16 repeat;
+   __le16 max_freq_multiple;
+};
+
+/* version supported which must match firmware */
+#define BRCMF_GSCAN_CFG_VERSION 1
+
+/**
+ * enum brcmf_gscan_cfg_flags - bit values for gscan flags.
+ *
+ * @BRCMF_GSCAN_CFG_FLAGS_ALL_RESULTS: send probe responses/beacons to host.
+ * @BRCMF_GSCAN_CFG_FLAGS_CHANGE_ONLY: indicated only flags member is changed.
+ */
+enum brcmf_gscan_cfg_flags {
+   BRCMF_GSCAN_CFG_FLAGS_ALL_RESULTS = BIT(0),
+   BRCMF_GSCAN_CFG_FLAGS_CHANGE_ONLY = BIT(7),
+};
+
+/**
+ * struct brcmf_gscan_config - configuration data for gscan.
+ *
+ * @version: version of the api to match firmware.
+ * @flags: flags according %enum brcmf_gscan_cfg_flag

[PATCH for-4.10 2/2] brcmfmac: fix uninitialized field in scheduled scan ssid configuration

[Arend van Spriel]

The scheduled scan ssid configuration in firmware has a flags field that
was not initialized resulting in unexpected behaviour.

Fixes: e3bdb7cc0300 ("brcmfmac: fix handling ssids in .sched_scan_start() 
callback")
Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
index f273cab..9a25e79 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
@@ -137,6 +137,7 @@ static int brcmf_pno_add_ssid(struct brcmf_if *ifp, struct 
cfg80211_ssid *ssid,
pfn.wpa_auth = cpu_to_le32(BRCMF_PNO_WPA_AUTH_ANY);
pfn.wsec = cpu_to_le32(0);
pfn.infra = cpu_to_le32(1);
+   pfn.flags = 0;
if (active)
pfn.flags = cpu_to_le32(1 << BRCMF_PNO_HIDDEN_BIT);
pfn.ssid.SSID_len = cpu_to_le32(ssid->ssid_len);
--
1.9.1

[PATCH for-4.10 0/2] brcmfmac: small fixes for after merge window

[Arend van Spriel]

Two issues found during more testing. The first patch fixes a memory leak
in error path. The second one fixes a regression introduced by a change
that currently sits in wireless-drivers-next.

These patches have been applied on top of wireless-drivers-next/master branch
so it can apply on wireless-drivers/master after the merge window (fingers
crossed).

Arend van Spriel (2):
  brcmfmac: fix memory leak in brcmf_cfg80211_attach()
  brcmfmac: fix uninitialized field in scheduled scan ssid configuration

 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +--
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c  | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

--
1.9.1

[PATCH for-4.10 1/2] brcmfmac: fix memory leak in brcmf_cfg80211_attach()

[Arend van Spriel]

In brcmf_cfg80211_attach() there was one error path not properly
handled as it leaked memory allocated in brcmf_btcoex_attach().

Reviewed-by: Hante Meuleman <hante.meule...@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesbe...@broadcom.com>
Reviewed-by: Franky Lin <franky@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..7ffc4ab 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6868,7 +6868,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct 
brcmf_pub *drvr,

err = brcmf_p2p_attach(cfg, p2pdev_forced);
if (err) {
-   brcmf_err("P2P initilisation failed (%d)\n", err);
+   brcmf_err("P2P initialisation failed (%d)\n", err);
goto wiphy_unreg_out;
}
err = brcmf_btcoex_attach(cfg);
@@ -6893,7 +6893,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct 
brcmf_pub *drvr,
err = brcmf_fweh_activate_events(ifp);
if (err) {
brcmf_err("FWEH activation failed (%d)\n", err);
-   goto wiphy_unreg_out;
+   goto detach;
}

/* Fill in some of the advertised nl80211 supported features */
@@ -6908,6 +6908,9 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct 
brcmf_pub *drvr,

return cfg;

+detach:
+   brcmf_btcoex_detach(cfg);
+   brcmf_p2p_detach(>p2p);
 wiphy_unreg_out:
wiphy_unregister(cfg->wiphy);
 priv_out:
--
1.9.1