Re: [PATCH 40/45] iwlwifi: Update PCI IDs for 8000 and 9000 series

[Kalle Valo]

Emmanuel Grumbach  writes:

> From: Oren Givon 
>
> A new PCI IDs update to the 8000 and 9000 series.
>
> type=feature
>
> Signed-off-by: Oren Givon 
> Signed-off-by: Emmanuel Grumbach 

Forgot to clean the internal tags? :) No need to change anything now,
just keep on eye on these. Or better yet check these automatically.

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

Re: [PATCH v3 2/3] wlcore/wl12xx: spi: add device tree support

[Rob Herring]

On Mon, Dec 28, 2015 at 02:02:18PM +0200, Uri Mashiach wrote:
> Add DT support for the wl1271 SPI WiFi.
> 
> Add documentation file for the wl1271 SPI WiFi.
> 
> Signed-off-by: Uri Mashiach 
> Acked-by: Igor Grinberg 
> ---
> v1 -> v2: update interrupt documentation.
>   replace interrupts and interrupt-parent with interrupts-extended.

Why? interrupts-extended is really just for cases with 2 interrupt 
parents.

> IRQ parameters retrieved from spi_device instead of DT.
> remove redundant #ifdef CONFIG_OF
> v2 -> v3: Add MODULE_DEVICE_TABLE.
>   Remove #ifdef CONFIG_OF.
> Make the Kconfig symbol to depend on OF.
> Replace irqd_get_trigger_type() with irq_get_trigger_type().
> 
>  .../bindings/net/wireless/ti,wlcore,spi.txt| 34 

In any case:

Acked-by: Rob Herring 

>  drivers/net/wireless/ti/wlcore/Kconfig |  2 +-
>  drivers/net/wireless/ti/wlcore/spi.c   | 47 
> --
>  3 files changed, 78 insertions(+), 5 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

[Bjorn Andersson]

On Tue 29 Dec 10:34 PST 2015, Rob Herring wrote:

> On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> > Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> > Signed-off-by: Bjorn Andersson 
> > ---
> >  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> > ++
> >  1 file changed, 76 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> > b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > new file mode 100644
> > index ..7b314b9f30af
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > @@ -0,0 +1,76 @@
> > +Qualcomm WCN36xx WiFi Binding
> > +
> > +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware 
> > block
> > +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> > variety
> > +of Qualcomm platforms.
> 
> Are BT/FM functions completely separate? If so, separate bindings are 
> okay. If not, then we need to describe the full chip.
> 

It's three different hardware blocks (WiFi, BT and FM-radio) with shared
RF-hardware and an ARM core for control logic.

There seems to be some control commands going towards the BT part that
controls coexistence properties of the RF-hardware, but other than that
I see it as logically separate blocks.


So I think it's fine to model this as separate pieces in DT.

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

Re: pull request: iwlwifi-next-2015-12-21

[Kalle Valo]

"Grumbach, Emmanuel"  writes:

> Hi Kalle,
>
> here is a pull request for 4.5. I guess there will be one more after
> that depending on when Linus will open the merge window I guess. The
> diffstat look awful and I have no clue why. It looks as if I had done
> the whole code reorganisation... So we have a pretty large pull
> request here. We are facing big new things: a new device family with
> lots of work in the data path and such. Details in the tag. Let me
> know if you have issues. Note that as I said, I needed to merge
> Johannes's tree to get the new uAPSD helper I added and I merge
> iwlwifi-fixes.git to avoid conflicts.
>
> The following changes since commit 1b894521e60c1b91db1e8ba1278660e5c89f1b5f:
>
>   mac80211: handle HW ROC expired properly (2015-12-07 11:06:37 +0100)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
> tags/iwlwifi-next-for-kalle-2015-12-21

Pulled, thanks. Happy New Year! 

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

Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

[Andy Gross]

On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> 
> Signed-off-by: Bjorn Andersson 
> ---



> +
> +- qcom,wcnss-mmio:
> + Usage: required
> + Value type: 

nit:  encoded

> + Definition: should specify base address and size of the WiFi related
> + registers of WCNSS
> +
> +- qcom,state:
> + Usage: required
> + Value type: 
> + Definition: should specify the tx-enable and tx-ring-empty state
> + references
> +



Otherwise looks good.

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

Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

[Rob Herring]

On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> Signed-off-by: Bjorn Andersson 
> ---
>  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> ++
>  1 file changed, 76 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> new file mode 100644
> index ..7b314b9f30af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> @@ -0,0 +1,76 @@
> +Qualcomm WCN36xx WiFi Binding
> +
> +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware block
> +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> variety
> +of Qualcomm platforms.

Are BT/FM functions completely separate? If so, separate bindings are 
okay. If not, then we need to describe the full chip.

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

RE: Mac80211 : Wpa rekeying issue

[voncken]

> -Message d'origine-
> De : Emmanuel Grumbach [mailto:egrumb...@gmail.com]
> Envoyé : mardi 29 décembre 2015 15:20
> À : Cedric VONCKEN
> Cc : linux-wireless
> Objet : Re: Mac80211 : Wpa rekeying issue
> 
> On Tue, Dec 29, 2015 at 3:01 PM, Cedric VONCKEN 
> wrote:
> > Hi,
> >
> > My test plateform is:
> > 2 equipements
> > Both equipment used compat version 2015-07-21 from openwrt.
> > Both equipment used security WPA2
> >
> > The equipment #1 is an AP.
> > The Group rekey interval is set to 3601s
> > The Pair rekey interval set to 50s (I reduced this value to
> > show the issue often)
> > The Master rekey interval is set to 86400 s.
> >
> > The equipment #2 is a sta+wds
> >
> > I used a 5GHz channel to have a free channel (without other AP) I
> > connected a computer on each equipment.
> >
> > To reproduce the issue:
> > I ran iperf udp@50Mbps from computer connected to the AP to
> > the computer connected to the sta. After several WPA2 rekeying, iperf
> > server side didn't received any frame.
> >
> > I investigated in the driver. All packets are dropped in sta side,
> > because the function ieee80211_crypto_ccmp_decrypt return
> > Rx_DROP_UNUSABLE. This function return this code because the test
> > if(memcmp(pn,key->u.ccmp.rx_pn[queue],IEEE8021_CCMP_PN_LEN) <=0)
> > return true.
> >
> > Have you any idea to fix this issue?
> >
> 
> I don't remember exactly what we had, but you may look at
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137742

Thanks for the link, I think I'm in the same situation.

How can I fix this issue?

Because the patch sent by Alexander Wetzel was rejected by Johannes (for 
security reason), and if I disable the hw crypto I will have performance issue.


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

Re: [PATCH] ath6kl: Use vmalloc to allocate ar->fw for api1 method

[Souptick Joarder]

Brent,

On Tue, Dec 22, 2015 at 2:42 PM, Kalle Valo  wrote:
> Souptick Joarder  writes:
>
>> Hi Brent,
>>
>> On Tue, Dec 22, 2015 at 3:23 AM, Brent Taylor  wrote:
>>> On Mon, Dec 21, 2015 at 1:23 PM, Souptick Joarder  
>>> wrote:
 Hi Brent,

 On Tue, Dec 1, 2015 at 11:11 AM, Brent Taylor  wrote:

> --- a/drivers/net/wireless/ath/ath6kl/init.c
> +++ b/drivers/net/wireless/ath/ath6kl/init.c
> @@ -673,10 +673,15 @@ static int ath6kl_get_fw(struct ath6kl *ar, const 
> char *filename,
> return ret;
>
> *fw_len = fw_entry->size;
> -   *fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
> +   if (>fw == fw)
> +   *fw = vmalloc(fw_entry->size);
> +   else
> +   *fw = kmalloc(fw_entry->size, GFP_KERNEL)

   Why vmalloc and kmalloc both are required? can't use either
 vmalloc or kmalloc?
>>>
>>> My original problem was that kmemdup (which uses kmalloc) could not
>>> allocate enough memory
>>
>> If kmemdump ( which uses kmalloc) could not allocate memory then
>> using kmalloc again can lead to same problem.
>> I guess it will be correct to use
>> *fw = vmalloc(fw_entry->size);
>> Correct me if i am wrong.
>
> That sounds best. But remember take into account DMA requirements, IIRC
> you cannot DMA from vmalloc memory on all platforms.

Is it possible to modify the patch as per feedback from Kalle.

>
> --
> Kalle Valo

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

Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

[Rob Herring]

On Tue, Dec 29, 2015 at 11:03:57AM -0800, Bjorn Andersson wrote:
> On Tue 29 Dec 10:34 PST 2015, Rob Herring wrote:
> 
> > On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> > > Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> > > Signed-off-by: Bjorn Andersson 
> > > ---
> > >  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> > > ++
> > >  1 file changed, 76 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > > 
> > > diff --git 
> > > a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> > > b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > > new file mode 100644
> > > index ..7b314b9f30af
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > > @@ -0,0 +1,76 @@
> > > +Qualcomm WCN36xx WiFi Binding
> > > +
> > > +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware 
> > > block
> > > +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> > > variety
> > > +of Qualcomm platforms.
> > 
> > Are BT/FM functions completely separate? If so, separate bindings are 
> > okay. If not, then we need to describe the full chip.
> > 
> 
> It's three different hardware blocks (WiFi, BT and FM-radio) with shared
> RF-hardware and an ARM core for control logic.
> 
> There seems to be some control commands going towards the BT part that
> controls coexistence properties of the RF-hardware, but other than that
> I see it as logically separate blocks.
> 
> 
> So I think it's fine to model this as separate pieces in DT.

Okay.

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

Re: [PATCH] mwifiex: correctly handling kzalloc

[Andy Shevchenko]

On Tue, Dec 29, 2015 at 10:17 PM, Insu Yun  wrote:

Empty commit message?

> Signed-off-by: Insu Yun 
> ---
>  drivers/net/wireless/mwifiex/sdio.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/wireless/mwifiex/sdio.c 
> b/drivers/net/wireless/mwifiex/sdio.c
> index 78a8474..a8af72d 100644
> --- a/drivers/net/wireless/mwifiex/sdio.c
> +++ b/drivers/net/wireless/mwifiex/sdio.c
> @@ -2053,8 +2053,19 @@ static int mwifiex_init_sdio(struct mwifiex_adapter 
> *adapter)
> /* Allocate skb pointer buffers */
> card->mpa_rx.skb_arr = kzalloc((sizeof(void *)) *
>card->mp_agg_pkt_limit, GFP_KERNEL);

Just noticed: Looks like good candidate for kcalloc or kmalloc_array,
whichever is suitable.

> +   if (!card->mpa_rx.skb_arr) {
> +   kfree(card->mp_regs);
> +   return -ENOMEM;
> +   }
> +
> card->mpa_rx.len_arr = kzalloc(sizeof(*card->mpa_rx.len_arr) *
>card->mp_agg_pkt_limit, GFP_KERNEL);

Ditto.

> +   if (!card->mpa_rx.len_arr) {
> +   kfree(card->mp_regs);
> +   kfree(card->mpa_rx.skb_arr);


> +   return -ENOMEM;
> +   }
> +
> ret = mwifiex_alloc_sdio_mpa_buffers(adapter,
>  card->mp_tx_agg_buf_size,
>  card->mp_rx_agg_buf_size);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



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

[PATCH] mwifiex: correctly handling kzalloc

[Insu Yun]

Signed-off-by: Insu Yun 
---
 drivers/net/wireless/mwifiex/sdio.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/wireless/mwifiex/sdio.c 
b/drivers/net/wireless/mwifiex/sdio.c
index 78a8474..a8af72d 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -2053,8 +2053,19 @@ static int mwifiex_init_sdio(struct mwifiex_adapter 
*adapter)
/* Allocate skb pointer buffers */
card->mpa_rx.skb_arr = kzalloc((sizeof(void *)) *
   card->mp_agg_pkt_limit, GFP_KERNEL);
+   if (!card->mpa_rx.skb_arr) {
+   kfree(card->mp_regs);
+   return -ENOMEM;
+   }
+
card->mpa_rx.len_arr = kzalloc(sizeof(*card->mpa_rx.len_arr) *
   card->mp_agg_pkt_limit, GFP_KERNEL);
+   if (!card->mpa_rx.len_arr) {
+   kfree(card->mp_regs);
+   kfree(card->mpa_rx.skb_arr);
+   return -ENOMEM;
+   }
+
ret = mwifiex_alloc_sdio_mpa_buffers(adapter,
 card->mp_tx_agg_buf_size,
 card->mp_rx_agg_buf_size);
-- 
1.9.1

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

Re: [PATCH 3/7] brcmfmac: Add support for scheduled scan mac randomization

[Mathy Vanhoef]

On Mon, Dec 14, 2015 at 2:39 PM, Arend van Spriel  wrote:
> From: Hante Meuleman 
>
> Scheduled scan be requested to use mac randomization. This patch
> checks the flags and enables the randomization if desired.

The driver also needs to advertise support for this using the
NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR flag, if the firmware
supports it. This can be done in brcmf_setup_wiphy. Otherwise
tools like wpa_supplicant won't use randomization.

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

[PATCH] mwifiex: correctly handling kzalloc

[Insu Yun]

Since kzalloc can be failed in memory pressure,
it needs to be handled as above kzalloc.

Signed-off-by: Insu Yun 
---
 drivers/net/wireless/mwifiex/sdio.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/mwifiex/sdio.c 
b/drivers/net/wireless/mwifiex/sdio.c
index 78a8474..d114934 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -2053,8 +2053,14 @@ static int mwifiex_init_sdio(struct mwifiex_adapter 
*adapter)
/* Allocate skb pointer buffers */
card->mpa_rx.skb_arr = kzalloc((sizeof(void *)) *
   card->mp_agg_pkt_limit, GFP_KERNEL);
+   if (!card->mpa_rx.skb_arr)
+   return -ENOMEM;
+
card->mpa_rx.len_arr = kzalloc(sizeof(*card->mpa_rx.len_arr) *
   card->mp_agg_pkt_limit, GFP_KERNEL);
+   if (!card->mpa_rx.len_arr)
+   return -ENOMEM;
+
ret = mwifiex_alloc_sdio_mpa_buffers(adapter,
 card->mp_tx_agg_buf_size,
 card->mp_rx_agg_buf_size);
-- 
1.9.1

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

Re: [PATCH 4/7] brcmfmac: obtain feature info using 'cap' firmware command

[Mathy Vanhoef]

On Mon, Dec 14, 2015 at 2:39 PM, Arend van Spriel  wrote:
> Several features in the driver directly map to a firmware feature
> listed in response of the 'cap' firmware command. For those features
> this response will be examined instead of attempting individual
> firmware commands.
>
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Franky (Zhenhui) Lin 
> Reviewed-by: Pieter-Paul Giesberts 
> Signed-off-by: Arend van Spriel 
> ---
>  .../wireless/broadcom/brcm80211/brcmfmac/feature.c | 51 
> +-
>  1 file changed, 30 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> index d9d1ca4..08b7200 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> @@ -40,6 +40,17 @@ static const char *brcmf_feat_names[] = {
>  };
>  #undef BRCMF_FEAT_DEF
>
> +struct brcmf_feat_fwcap {
> +   enum brcmf_feat_id feature;
> +   const char * const fwcap_id;
> +};
> +
> +static const struct brcmf_feat_fwcap brcmf_fwcap_map[] = {
> +   { BRCMF_FEAT_MBSS, "mbss" },
> +   { BRCMF_FEAT_MCHAN, "mchan" },
> +   { BRCMF_FEAT_P2P, "p2p" },
> +};
> +
>  #ifdef DEBUG
>  /*
>   * expand quirk list to array of quirk strings.
> @@ -104,25 +115,22 @@ static void brcmf_feat_iovar_int_get(struct brcmf_if 
> *ifp,
> }
>  }
>
> -/**
> - * brcmf_feat_iovar_int_set() - determine feature through iovar set.
> - *
> - * @ifp: interface to query.
> - * @id: feature id.
> - * @name: iovar name.
> - */
> -static void brcmf_feat_iovar_int_set(struct brcmf_if *ifp,
> -enum brcmf_feat_id id, char *name, u32 
> val)
> +static void brcmf_feat_firmware_capabilities(struct brcmf_if *ifp)
>  {
> -   int err;
> -
> -   err = brcmf_fil_iovar_int_set(ifp, name, val);
> -   if (err == 0) {
> -   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);
> +   char caps[256];
> +   enum brcmf_feat_id id;
> +   int i;
> +
> +   brcmf_fil_iovar_data_get(ifp, "cap", caps, sizeof(caps));
> +   brcmf_dbg(INFO, "[ %s]\n", caps);
> +
> +   for (i = 0; i < ARRAY_SIZE(brcmf_fwcap_map); i++) {
> +   if (strnstr(caps, brcmf_fwcap_map[i].fwcap_id, sizeof(caps))) 
> {
> +   id = brcmf_fwcap_map[i].feature;
> +   brcmf_dbg(INFO, "enabling feature: %s\n",
> + brcmf_feat_names[id]);
> +   ifp->drvr->feat_flags |= BIT(id);
> +   }
> }
>  }
>
> @@ -130,13 +138,14 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
>  {
> struct brcmf_if *ifp = brcmf_get_ifp(drvr, 0);
>
> -   brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_MCHAN, "mchan");
> +   brcmf_feat_firmware_capabilities(ifp);
> +
> 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");
> +   /* MBSS does not work for 43362 */
> if (drvr->bus_if->chip != BRCM_CC_43362_CHIP_ID)
> -   brcmf_feat_iovar_int_set(ifp, BRCMF_FEAT_MBSS, "mbss", 0);
> -   brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_P2P, "p2p");
> +   ifp->drvr->feat_flags &= BIT(BRCMF_FEAT_MBSS);

Missing ~ before the BIT() declaration? If the if-test fails, all bits are
cleared except BRCMF_FEAT_MBSS. I think the if-test also needs to be updated
to an equals `==` instead of the old inequality. So one would get:

/* clear MBSS feature for the 43362 (does not work) */
if (drvr->bus_if->chip == BRCM_CC_43362_CHIP_ID)
ifp->drvr->feat_flags &= ~BIT(BRCMF_FEAT_MBSS);

Also, happy holidays!
Mathy

> brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_RSDB, "rsdb_mode");
> brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_TDLS, "tdls_enable");
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Mac80211 : Wpa rekeying issue

[Emmanuel Grumbach]

On Tue, Dec 29, 2015 at 3:01 PM, Cedric VONCKEN
 wrote:
> Hi,
>
> My test plateform is:
> 2 equipements
> Both equipment used compat version 2015-07-21 from openwrt.
> Both equipment used security WPA2
>
> The equipment #1 is an AP.
> The Group rekey interval is set to 3601s
> The Pair rekey interval set to 50s (I reduced this value to show
> the issue often)
> The Master rekey interval is set to 86400 s.
>
> The equipment #2 is a sta+wds
>
> I used a 5GHz channel to have a free channel (without other AP)
> I connected a computer on each equipment.
>
> To reproduce the issue:
> I ran iperf udp@50Mbps from computer connected to the AP to the
> computer connected to the sta. After several WPA2 rekeying, iperf server
> side didn't received any frame.
>
> I investigated in the driver. All packets are dropped in sta side,
> because the function ieee80211_crypto_ccmp_decrypt return
> Rx_DROP_UNUSABLE. This function return this code because the test
> if(memcmp(pn,key->u.ccmp.rx_pn[queue],IEEE8021_CCMP_PN_LEN) <=0) return
> true.
>
> Have you any idea to fix this issue?
>

I don't remember exactly what we had, but you may look at
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137742
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html