General VHT rate-ctrl question

[Ben Greear]

If a station and it's peer can both do VHT, is there ever a good reason
to even try HT rates?

Thanks,
Ben

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

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

[PATCH v4] brcmfmac: Decrease 8021x_cnt for dropped packets

[per . forlin]

From: Per Forlin 

This patch resolves an issue where pend_8021x_cnt was not decreased
on txfinalize. This caused brcmf_netdev_wait_pend8021x to timeout
because the counter indicated pending packets.

WARNING: at .../brcmfmac/core.c:1289 brcmf_netdev_wait_pend8021x
  (warn_slowpath_common)
  (warn_slowpath_null)
  (brcmf_netdev_wait_pend8021x [brcmfmac])
  (send_key_to_dongle [brcmfmac])
  (brcmf_cfg80211_del_key [brcmfmac])
  (nl80211_del_key [cfg80211])
  (genl_rcv_msg)
  (netlink_rcv_skb)
  (genl_rcv)
  (netlink_unicast)
  (netlink_sendmsg)
  (sock_sendmsg)
  (___sys_sendmsg)
  (__sys_sendmsg)
  (SyS_sendmsg)

The solution is to pull back the header offset in case
of an error in txdata(), which may happen in case of
packet overload in brcmf_sdio_bus_txdata.

Overloading an WLAN interface is not an unlikely scenario.
In case of packet overload the error print "out of bus->txq"
is very verbose. To reduce SPAM degrade it to a debug print.

Signed-off-by: Per Forlin 
---
Change log:
 v2 - Add variable to know whether the counter is increased or not
 v3 - txfinalize should decrease the counter. Adjust skb header offset
 v4 - Fix build error

drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 4 +++-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index ed9998b..f342f7c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -541,6 +541,9 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff 
*txp, bool success)
struct ethhdr *eh;
u16 type;
 
+   if (!ifp)
+   goto free;
+
eh = (struct ethhdr *)(txp->data);
type = ntohs(eh->h_proto);
 
@@ -553,6 +556,7 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff 
*txp, bool success)
if (!success)
ifp->stats.tx_errors++;
 
+free:
brcmu_pkt_buf_free_skb(txp);
 }
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
index f82c9ab..98cb83f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
@@ -1899,8 +1899,10 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct 
sk_buff *skb)
 
if (fws->avoid_queueing) {
rc = brcmf_proto_txdata(drvr, ifp->ifidx, 0, skb);
-   if (rc < 0)
+   if (rc < 0) {
+   (void)brcmf_proto_hdrpull(drvr, false, skb, );
brcmf_txfinalize(ifp, skb, false);
+   }
return rc;
}
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index a14d9d9d..485e2ad 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -2721,7 +2721,7 @@ static int brcmf_sdio_bus_txdata(struct device *dev, 
struct sk_buff *pkt)
*(u16 *)(pkt->cb) = 0;
if (!brcmf_sdio_prec_enq(>txq, pkt, prec)) {
skb_pull(pkt, bus->tx_hdrlen);
-   brcmf_err("out of bus->txq !!!\n");
+   brcmf_dbg(INFO, "out of bus->txq !!!\n");
ret = -ENOSR;
} else {
ret = 0;
-- 
2.1.4

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

Re: [PATCH v3] brcmfmac: Decrease 8021x_cnt for dropped packets

[kbuild test robot]

Hi Per,

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.6-rc3 next-20160412]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/per-forlin-gmail-com/brcmfmac-Decrease-8021x_cnt-for-dropped-packets/20160413-045216
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: mips-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c: In function 
'brcmf_proto_bcdc_txdata':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c:336:41: error: 
>> passing argument 3 of 'brcmf_proto_bcdc_hdrpull' from incompatible pointer 
>> type [-Werror=incompatible-pointer-types]
  brcmf_proto_bcdc_hdrpull(drvr, false, , pktbuf);
^
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c:277:1: note: 
expected 'struct sk_buff *' but argument is of type 'int *'
brcmf_proto_bcdc_hdrpull(struct brcmf_pub *drvr, bool do_fws,
^
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c:336:49: error: 
passing argument 4 of 'brcmf_proto_bcdc_hdrpull' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  brcmf_proto_bcdc_hdrpull(drvr, false, , pktbuf);
^
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c:277:1: note: 
expected 'struct brcmf_if **' but argument is of type 'struct sk_buff *'
brcmf_proto_bcdc_hdrpull(struct brcmf_pub *drvr, bool do_fws,
^
   cc1: some warnings being treated as errors

vim +/brcmf_proto_bcdc_hdrpull +336 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c

   330  struct sk_buff *pktbuf)
   331  {
   332  int res;
   333  brcmf_proto_bcdc_hdrpush(drvr, ifidx, offset, pktbuf);
   334  res = brcmf_bus_txdata(drvr->bus_if, pktbuf);
   335  if (res < 0)
 > 336  brcmf_proto_bcdc_hdrpull(drvr, false, , pktbuf);
   337  return res;
   338  }
   339  

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


.config.gz
Description: Binary data

Re: [PATCH v3] brcmfmac: Decrease 8021x_cnt for dropped packets

[kbuild test robot]

Hi Per,

[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.6-rc3 next-20160412]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/per-forlin-gmail-com/brcmfmac-Decrease-8021x_cnt-for-dropped-packets/20160413-045216
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: xtensa-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c: In function 
'brcmf_proto_bcdc_txdata':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c:336:3: warning: 
>> passing argument 3 of 'brcmf_proto_bcdc_hdrpull' from incompatible pointer 
>> type
  brcmf_proto_bcdc_hdrpull(drvr, false, , pktbuf);
  ^
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c:277:1: note: 
expected 'struct sk_buff *' but argument is of type 'int *'
brcmf_proto_bcdc_hdrpull(struct brcmf_pub *drvr, bool do_fws,
^
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c:336:3: warning: 
passing argument 4 of 'brcmf_proto_bcdc_hdrpull' from incompatible pointer type
  brcmf_proto_bcdc_hdrpull(drvr, false, , pktbuf);
  ^
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c:277:1: note: 
expected 'struct brcmf_if **' but argument is of type 'struct sk_buff *'
brcmf_proto_bcdc_hdrpull(struct brcmf_pub *drvr, bool do_fws,
^

vim +/brcmf_proto_bcdc_hdrpull +336 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c

   320  
   321  if (pktbuf->len == 0)
   322  return -ENODATA;
   323  
   324  *ifp = tmp_if;
   325  return 0;
   326  }
   327  
   328  static int
   329  brcmf_proto_bcdc_txdata(struct brcmf_pub *drvr, int ifidx, u8 offset,
   330  struct sk_buff *pktbuf)
   331  {
   332  int res;
   333  brcmf_proto_bcdc_hdrpush(drvr, ifidx, offset, pktbuf);
   334  res = brcmf_bus_txdata(drvr->bus_if, pktbuf);
   335  if (res < 0)
 > 336  brcmf_proto_bcdc_hdrpull(drvr, false, , pktbuf);
   337  return res;
   338  }
   339  
   340  static void
   341  brcmf_proto_bcdc_configure_addr_mode(struct brcmf_pub *drvr, int ifidx,
   342   enum proto_addr_mode addr_mode)
   343  {
   344  }

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


.config.gz
Description: Binary data

Re: [PATCH MOREWORK 14/19] rtl818x_pci: Fix a memory leak in rtl8180_init_rx_ring

[Andrea Merello]

On Mon, Apr 11, 2016 at 2:11 AM, Julian Calaby  wrote:
> Hi Andrea,
>
> On Sat, Apr 9, 2016 at 4:56 AM, Andrea Merello  
> wrote:
>>
>> On Fri, Mar 18, 2016 at 3:27 AM, Julian Calaby 
>> wrote:
>>> From: Jia-Ju Bai 
>>>
>>> When dev_alloc_skb or pci_dma_mapping_error in rtl8180_init_rx_ring fails,
>>> the memory allocated by pci_zalloc_consistent is not freed.
>>>
>>> This patch fixes the bug by adding pci_free_consistent
>>> in error handling code.
>>>
>>> Signed-off-by: Jia-Ju Bai 
>>> Signed-off-by: Julian Calaby 
>>>
>>> ---
>>>
>>> Could someone else please review this?
>>
>> This patch does address one leak, but the piece of code it changes is
>> totally leaky and IMHO it probably needs to be reworked more deeply, maybe
>> in a single shot. This is why I didn't acked the patch.
>
> Ugh.
>
> I can't work on this as I don't have hardware to test it with, could
> you (or someone who does) please have a good look at this section of
> the Realtek drivers (I see a lot of this pattern repeated in them) and
> craft (a) patch(es) to fix this properly?

On my TODO list. BTW Unfortunately I have a huge TODO list, and my
WiFi test box is currently unusable, so it will probably not happen
very soon on my side :(

>> BTW if you feel that this could be better than nothing, please feel free to
>> apply it :).
>
> IMHO this patch makes things better in that there's less options for a
> leak, however I marked this as "morework" as it clearly doesn't solve
> the _entire_ problem.
>
> I feel it should be applied as it does make it better, however this
> isn't my driver and I'd appreciate a nod of approval from someone who
> knows it better than I do.

I don't consider myself one that should finally decide about what to
merge into the Kernel, BTW I don't see any drawback in merging it.

>>> In particular, immediately after the call to pci_zalloc_coherent(), it
>>> fails if the result is null or if '(unsigned long)result & 0xFF'.
>>>
>>> Is the second arm of the or statement possible, and if so, should we be
>>> pci_free_coherent()ing the result there too?
>>
>> I honestly don't know if the coherent allocator is supposed to always return
>> page-aligned memory areas (I'm assuming a page wouldn't be smaller than 256
>> bytes); AFAIK no one ever hit that.
>>
>> If there are cases/archs where it can  really happen, then allocating an
>> oversized memory area, and providing to the HW an aligned pointer inside
>> that area, may be the way to go (IIRC calling pci_set_consistent_dma_mask()
>> with 0xFF00 does not provides any benefit, but again, I'm not sure).
>
> I believe that calling *_set_*_dma_mask() is how it's supposed to be
> done. If this isn't working, then that's a bug elsewhere. IMHO drivers
> should be able to say "we need a DMA address like *this*" and it's the
> PCI / DMA code's responsibility to either provide a compatible one or
> fail. Drivers shouldn't be working around bugs in the services they
> use.
>

I didn't meant it didn't worked.. I never thought *_set_*_dma_mask()
to be buggy.. (and Indeed I think I never saw a unaligned DMA alloc
either with or without it).

Well, to make it short: IIRC, I used it in my very first version of
the driver, but it has been changed in the rewritten version that is
in-kernel right now. At that time IIRC I ended up in thinking that
*_set_*_dma_mask() was just meant (due to its semantic, no bug..) only
for the purpose of restricting allocations to lower memory (for boards
that cannot address full memory size), while it wouldn't care about
LSBs. I don't remember if I was told about this, or if I looked into
the kernel code (maybe I did some mistake). BTW if you know that it is
intended to works as you said (and that indeed seems absolutely
reasonable to me, given that it takes a "mask" parameter), then it's
obviously the way to go.

After a quick grep in the kernel, it seems that there is at least one
driver that actually specifies a "weird" mask like ours..

>> Either way, If we do that, or if we can trust that it does never really
>> happen, then we can drop the check (or maybe just change it in a BUG_ON()
>> just to be paranoid).
>
> A WARN_ON() and failing gracefully would be the ideal way to do this
> IMHO, however it really shouldn't be necessary.
>
>> To address your question - if we let this check stay there - then of course
>> we need to take care of freeing the memory whenever the allocator succeeds
>> but that check fails.
>
> I'll craft a followup patch to add a WARN_ON(), free the memory and
> fail in this case.

Ok, thank you.

>>> I've had a quick scout around and this check seems to be particular to
>>> realtek drivers.
>>
>> The HW needs DMA rings to be 256-byte aligned. I never tried to see what
>> happens if we break the rule, but I suspect that the HW will attempt DMAs to
>> bad addresses (actually masked 

[PATCH v3] brcmfmac: Decrease 8021x_cnt for dropped packets

[per . forlin]

From: Per Forlin 

This patch resolves an issue where pend_8021x_cnt was not decreased
on txfinalize. This caused brcmf_netdev_wait_pend8021x to timeout
because the counter indicated pending packets.

WARNING: at .../brcmfmac/core.c:1289 brcmf_netdev_wait_pend8021x
  (warn_slowpath_common)
  (warn_slowpath_null)
  (brcmf_netdev_wait_pend8021x [brcmfmac])
  (send_key_to_dongle [brcmfmac])
  (brcmf_cfg80211_del_key [brcmfmac])
  (nl80211_del_key [cfg80211])
  (genl_rcv_msg)
  (netlink_rcv_skb)
  (genl_rcv)
  (netlink_unicast)
  (netlink_sendmsg)
  (sock_sendmsg)
  (___sys_sendmsg)
  (__sys_sendmsg)
  (SyS_sendmsg)

The solution is to pull back the header offset in case
of an error in txdata(), which may happen in case of
packet overload in brcmf_sdio_bus_txdata.

Overloading an WLAN interface is not an unlikely scenario.
In case of packet overload the error print "out of bus->txq"
is very verbose. To reduce SPAM degrade it to a debug print.

Signed-off-by: Per Forlin 
---
Change log:
 v2 - Add variable to know whether the counter is increased or not
 v3 - txfinalize should decrease the counter. Adjust skb header offset

 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 6 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
index 6af658e..508b287 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
@@ -329,8 +329,12 @@ static int
 brcmf_proto_bcdc_txdata(struct brcmf_pub *drvr, int ifidx, u8 offset,
struct sk_buff *pktbuf)
 {
+   int res;
brcmf_proto_bcdc_hdrpush(drvr, ifidx, offset, pktbuf);
-   return brcmf_bus_txdata(drvr->bus_if, pktbuf);
+   res = brcmf_bus_txdata(drvr->bus_if, pktbuf);
+   if (res < 0)
+   brcmf_proto_bcdc_hdrpull(drvr, false, , pktbuf);
+   return res;
 }
 
 static void
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index a14d9d9d..485e2ad 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -2721,7 +2721,7 @@ static int brcmf_sdio_bus_txdata(struct device *dev, 
struct sk_buff *pkt)
*(u16 *)(pkt->cb) = 0;
if (!brcmf_sdio_prec_enq(>txq, pkt, prec)) {
skb_pull(pkt, bus->tx_hdrlen);
-   brcmf_err("out of bus->txq !!!\n");
+   brcmf_dbg(INFO, "out of bus->txq !!!\n");
ret = -ENOSR;
} else {
ret = 0;
-- 
2.1.4

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

Re: [PATCH] cfg80211: remove enum ieee80211_band

[Arend van Spriel]

On 12-04-16 21:58, Johannes Berg wrote:
> On Tue, 2016-04-12 at 21:53 +0200, Arend van Spriel wrote:
>>
>> On 12-04-16 15:58, Johannes Berg wrote:
>>>
>>> From: Johannes Berg 
>>>
>>> This enum is already perfectly aliased to enum nl80211_band, and
>>> the only reason for it is that we get IEEE80211_NUM_BANDS out of
>>> it. There's no really good reason to not declare the number of
>>> bands in nl80211 though, so do that and remove the cfg80211 one.
>> So what if a band is added. That would change the value of
>> IEEE80211_NUM_BANDS in nl80211. Is it not ABI?
> 
> Well, it can't be ABI really since the value is never used. Arguably it
> becomes API, but clearly we have the same with NL80211_CMD_MAX and many
> others like it, so I see no point in treating the bands here specially.
> I even added a comment :)

Ah. Clearly I only read the commit message :-p Sorry for the noise.

Gr. AvS

> johannes
> 
--
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] cfg80211: remove enum ieee80211_band

[Johannes Berg]

On Tue, 2016-04-12 at 21:53 +0200, Arend van Spriel wrote:
> 
> On 12-04-16 15:58, Johannes Berg wrote:
> > 
> > From: Johannes Berg 
> > 
> > This enum is already perfectly aliased to enum nl80211_band, and
> > the only reason for it is that we get IEEE80211_NUM_BANDS out of
> > it. There's no really good reason to not declare the number of
> > bands in nl80211 though, so do that and remove the cfg80211 one.
> So what if a band is added. That would change the value of
> IEEE80211_NUM_BANDS in nl80211. Is it not ABI?

Well, it can't be ABI really since the value is never used. Arguably it
becomes API, but clearly we have the same with NL80211_CMD_MAX and many
others like it, so I see no point in treating the bands here specially.
I even added a comment :)

johannes
--
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] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Lukas Wunner]

Hi Andrew,

thank you for the extensive testing.

On Sun, Apr 10, 2016 at 08:09:29PM +1000, Andrew Worsley wrote:
> Further testing Broadcom 4331 reset quirk to prevent IRQ storm patch
> testing reveals that:
>   1. quirk is run on initial boot up and this time appears to have
> vastly reduced the interrupts (only 81 this time):
> cat /proc/interrupts| grep 17
>  17: 81  0  0  0  0  0
>  0  0   IO-APIC-fasteoi   snd_hda_intel

Something in the ballpark of 81 interrupt requests is fine.

The kernel will print the error message about spurious interrupts and
switch to polling at 10 requests. But even 2 is way too much.
This just means that b43 loaded quickly enough to stop the interrupts
before the kernel limit of 10 was reached, but the wireless card
wasn't reset early on as it should have been.

It looks like the patch didn't work at all on your machine for some
reason. Do you see a message "cannot iomap device, IRQ storm ahead"
in dmesg?

Included below is a slightly different patch which is based on the
3.16.7-ckt tree (so it should apply cleanly to your kernel version).
This version prints a message when the wireless card is reset. Please
verify that you see the message "b43 quirk: resetting controller" in
dmesg with this patch. This version of the patch also resets the card
a bit earlier in the boot process than the previous version did.
Please let me know if this improves the situation on your machine.

You might also want to try a newer kernel version, 3.16 is very old
and I'm not sure if there have been any changes since which might
negatively impact proper functioning of the patch. There are also
official 4.4 kernels available for Jessie. Canonical ends support
for the 3.16.y-ckt series anyway this month.


> Presently I have a grub work around for black screen as described here:
>   
> http://askubuntu.com/questions/264247/proprietary-nvidia-drivers-with-efi-on-mac-to-prevent-overheating/613573#613573
> 
> which basically involves adding a grub scriptlet to enable PCI-E bus
> mastering on graphics cards:
> 
> In /etc/grub.d/01_enable_vga.conf:
> 
> setpci -s "00:01.0" 3e.b=8
> setpci -s "01:00.0" 04.b=7

I think you need to upgrade to a newer version of the Nvidia driver,
I have just verified that 352.63 will set the busmaster bit if it's
cleared.


> Can we do some similar magic setpci commands to disable 04:00.0
> which is my BCM4331

I think grub is also able to write to mmio space of a PCI device,
which is what's necessary to reset the wireless card, so theoretically
yes, but the right place to fix this is in the kernel since not
everyone is using grub.

Best regards,

Lukas

-- >8 --
Subject: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
on boot until they are reset, causing spurious interrupts if the IRQ is
shared. Apparently the EFI bootloader enables the device and does not
disable it before passing control to the OS. The bootloader contains a
driver for the wireless card which allows it to phone home to Cupertino.
This is used for Internet Recovery (download and install OS X images)
and probably also for Back to My Mac (remote access, RFC 6281) and to
discover stolen hardware.

The issue is most pronounced on 2011 and 2012 MacBook Pros where the IRQ
is shared with 3 other devices (Light Ridge Thunderbolt controller, SDXC
reader, HDA card on discrete GPU). As soon as an interrupt handler is
installed for one of these devices, the ensuing storm of spurious IRQs
causes the kernel to disable the IRQ and switch to polling. This lasts
until the b43 driver loads and resets the device.

Loading the b43 driver first is not always an option, in particular with
the Light Ridge Thunderbolt controller: The PCI hotplug IRQ handler gets
installed early on because it is built in, unlike b43 which is usually
a module.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632
Cc: 
Tested-by: Lukas Wunner  [MacBookPro9,1]
Signed-off-by: Lukas Wunner 
Acked-by: Rafał Miłecki 
---
 drivers/bcma/bcma_private.h |  2 --
 drivers/pci/quirks.c| 28 
 include/linux/bcma/bcma.h   |  1 +
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index 09b632a..7ded994 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
@@ -8,8 +8,6 @@
 #include 
 #include 
 
-#define BCMA_CORE_SIZE 0x1000
-
 #define bcma_err(bus, fmt, ...) \
pr_err("bus%d: " fmt, (bus)->num, ##__VA_ARGS__)
 #define bcma_warn(bus, fmt, ...) \
diff --git a/drivers/pci/quirks.c 

[PATCH] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation

[Oleksij Rempel]

by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
mask_m & mask_p initialisation. This coused a performance regression
on ar9281.

Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common 
code in ar9002_hw_spur_mitigate.")
Reported-by: Gustav Frederiksen 
Tested-by: Gustav Frederiksen 
Signed-off-by: Oleksij Rempel 
---
 drivers/net/wireless/ath/ath9k/ar5008_phy.c | 8 +++-
 drivers/net/wireless/ath/ath9k/ar9002_phy.c | 5 -
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c 
b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index 8f87930..1b271b9 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -274,6 +274,9 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
};
static const int inc[4] = { 0, 100, 0, 0 };
 
+   memset(_m, 0, sizeof(int8_t) * 123);
+   memset(_p, 0, sizeof(int8_t) * 123);
+
cur_bin = -6000;
upper = bin + 100;
lower = bin - 100;
@@ -424,14 +427,9 @@ static void ar5008_hw_spur_mitigate(struct ath_hw *ah,
int tmp, new;
int i;
 
-   int8_t mask_m[123];
-   int8_t mask_p[123];
int cur_bb_spur;
bool is2GHz = IS_CHAN_2GHZ(chan);
 
-   memset(_m, 0, sizeof(int8_t) * 123);
-   memset(_p, 0, sizeof(int8_t) * 123);
-
for (i = 0; i < AR_EEPROM_MODAL_SPURS; i++) {
cur_bb_spur = ah->eep_ops->get_spur_channel(ah, i, is2GHz);
if (AR_NO_SPUR == cur_bb_spur)
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.c 
b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
index db66245..53d7445 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -178,14 +178,9 @@ static void ar9002_hw_spur_mitigate(struct ath_hw *ah,
int i;
struct chan_centers centers;
 
-   int8_t mask_m[123];
-   int8_t mask_p[123];
int cur_bb_spur;
bool is2GHz = IS_CHAN_2GHZ(chan);
 
-   memset(_m, 0, sizeof(int8_t) * 123);
-   memset(_p, 0, sizeof(int8_t) * 123);
-
ath9k_hw_get_channel_centers(ah, chan, );
freq = centers.synth_center;
 
-- 
2.5.0

--
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] ath10k: add dynamic tx mode switch config support for qca4019

[c_traja]

From: Raja Mani 

push-pull mode needs certain amount the host driver involvement for
managing queues in the host memory and packet delivery to firmware.
qca4019 wifi firmware has an option to stay in push mode for less
number of active traffic flow and then switch to push-pull mode when
the active traffic flow goes beyond the certain limit.

The advantage of staying in push mode for less active traffic is, the
host cpu consumption is reduced. qca4019 firmware supports this
flexibility of the mode switch. It takes the host driver interest
(LOW_PERF/HIGH_PERF) via WMI_EXT_RESOURCE_CFG_CMDID,

 LOW_PERF  - fw would stay in push mode and switch to push-pull
   based on demand.
 HIGH_PERF - fw would stay in push-pull mode from the boot.

To make this configuration generic, new WMI services
WMI_SERVICE_TX_MODE_PUSH_ONLY, WMI_SERVICE_TX_MODE_PUSH_PULL,
WMI_SERVICE_TX_MODE_DYNAMIC are introduced to take dynamic tx mode
switch support availability in firmware.
Based on WMI_SERVICE_TX_MODE_DYNAMIC, LOW_PERF or HIGHT_PERF is
configured to the firmware.

Signed-off-by: Raja Mani 
Signed-off-by: Tamizh chelvam 
---
 drivers/net/wireless/ath/ath10k/core.c |  3 +--
 drivers/net/wireless/ath/ath10k/mac.c  | 20 
 drivers/net/wireless/ath/ath10k/mac.h  |  1 +
 drivers/net/wireless/ath/ath10k/wmi.h  | 15 +++
 4 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index b2c7fe3..1c4106b 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1787,8 +1787,7 @@ int ath10k_core_start(struct ath10k *ar, enum 
ath10k_firmware_mode mode)
if (ath10k_peer_stats_enabled(ar))
val = WMI_10_4_PEER_STATS;
 
-   status = ath10k_wmi_ext_resource_config(ar,
-   
WMI_HOST_PLATFORM_HIGH_PERF, val);
+   status = ath10k_mac_ext_resource_config(ar, val);
if (status) {
ath10k_err(ar,
   "failed to send ext resource cfg command : 
%d\n",
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index b0e613b..de6d1a8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -157,6 +157,26 @@ ath10k_mac_max_vht_nss(const u16 
vht_mcs_mask[NL80211_VHT_NSS_MAX])
return 1;
 }
 
+int ath10k_mac_ext_resource_config(struct ath10k *ar, u32 val)
+{
+   enum wmi_host_platform_type platform_type;
+   int ret;
+
+   if (test_bit(WMI_SERVICE_TX_MODE_DYNAMIC, ar->wmi.svc_map))
+   platform_type = WMI_HOST_PLATFORM_LOW_PERF;
+   else
+   platform_type = WMI_HOST_PLATFORM_HIGH_PERF;
+
+   ret = ath10k_wmi_ext_resource_config(ar, platform_type, val);
+
+   if (ret && ret != -EOPNOTSUPP) {
+   ath10k_warn(ar, "failed to configure ext resource: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 /**/
 /* Crypto */
 /**/
diff --git a/drivers/net/wireless/ath/ath10k/mac.h 
b/drivers/net/wireless/ath/ath10k/mac.h
index 2c3327b..1bd29ec 100644
--- a/drivers/net/wireless/ath/ath10k/mac.h
+++ b/drivers/net/wireless/ath/ath10k/mac.h
@@ -81,6 +81,7 @@ int ath10k_mac_tx_push_txq(struct ieee80211_hw *hw,
 struct ieee80211_txq *ath10k_mac_txq_lookup(struct ath10k *ar,
u16 peer_id,
u8 tid);
+int ath10k_mac_ext_resource_config(struct ath10k *ar, u32 val);
 
 static inline struct ath10k_vif *ath10k_vif_to_arvif(struct ieee80211_vif *vif)
 {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index feebd19..a3f1534 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -180,6 +180,9 @@ enum wmi_service {
WMI_SERVICE_MESH_NON_11S,
WMI_SERVICE_PEER_STATS,
WMI_SERVICE_RESTRT_CHNL_SUPPORT,
+   WMI_SERVICE_TX_MODE_PUSH_ONLY,
+   WMI_SERVICE_TX_MODE_PUSH_PULL,
+   WMI_SERVICE_TX_MODE_DYNAMIC,
 
/* keep last */
WMI_SERVICE_MAX,
@@ -302,6 +305,9 @@ enum wmi_10_4_service {
WMI_10_4_SERVICE_RESTRT_CHNL_SUPPORT,
WMI_10_4_SERVICE_PEER_STATS,
WMI_10_4_SERVICE_MESH_11S,
+   WMI_10_4_SERVICE_TX_MODE_PUSH_ONLY,
+   WMI_10_4_SERVICE_TX_MODE_PUSH_PULL,
+   WMI_10_4_SERVICE_TX_MODE_DYNAMIC,
 };
 
 static inline char *wmi_service_name(int service_id)
@@ -396,6 +402,9 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_MESH_NON_11S);
SVCSTR(WMI_SERVICE_PEER_STATS);
SVCSTR(WMI_SERVICE_RESTRT_CHNL_SUPPORT);
+   SVCSTR(WMI_SERVICE_TX_MODE_PUSH_ONLY);
+   

Re: [PATCH] mwifiex: fix possible NULL dereference

[Andy Shevchenko]

On Mon, Apr 11, 2016 at 6:27 PM, Sudip Mukherjee
 wrote:
> From: Sudip Mukherjee 
>
> We have a check for card just after dereferencing it. So if it is NULL
> we have already dereferenced it before its check. Lets dereference it
> after checking card for NULL.

IIUC the code does nothing with dereference.

I would have told NAK if I would have been maintainer.

>
> Signed-off-by: Sudip Mukherjee 
> ---
>  drivers/net/wireless/marvell/mwifiex/pcie.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
> b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index edf8b07..84562d0 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -2884,10 +2884,11 @@ static void mwifiex_unregister_dev(struct 
> mwifiex_adapter *adapter)
>  {
> struct pcie_service_card *card = adapter->card;

Let's say it's 0.

> const struct mwifiex_pcie_card_reg *reg;
> -   struct pci_dev *pdev = card->dev;

This would be equal to offset of dev member in pcie_service_card struct.

Nothing wrong here.

> +   struct pci_dev *pdev;
> int i;
>
> if (card) {
> +   pdev = card->dev;
> if (card->msix_enable) {
> for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
> synchronize_irq(card->msix_entries[i].vector);
> --
> 1.9.1
>



-- 
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

Re: [PATCH v2] mwifiex: fix possible NULL dereference

[Sudip Mukherjee]

On Tuesday 12 April 2016 05:20 PM, Arend van Spriel wrote:



On 12-04-16 13:46, Sudip Mukherjee wrote:

From: Sudip Mukherjee 

We have a check for card just after dereferencing it. So if it is NULL
we have already dereferenced it before its check. Lets dereference it
after checking card for NULL.


And you are changing the scope of the pdev variable.


yes, and since all usage of pdev is inside the "if" block so it should 
not matter.


regards
sudip



Regards,
Arend


Signed-off-by: Sudip Mukherjee 
---
  drivers/net/wireless/marvell/mwifiex/pcie.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index edf8b07..d4db9db 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2884,10 +2884,11 @@ static void mwifiex_unregister_dev(struct 
mwifiex_adapter *adapter)
  {
struct pcie_service_card *card = adapter->card;
const struct mwifiex_pcie_card_reg *reg;
-   struct pci_dev *pdev = card->dev;
int i;

if (card) {
+   struct pci_dev *pdev = card->dev;
+
if (card->msix_enable) {
for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
synchronize_irq(card->msix_entries[i].vector);



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

Re: [PATCH v2] mwifiex: fix possible NULL dereference

[Arend van Spriel]

On 12-04-16 13:46, Sudip Mukherjee wrote:
> From: Sudip Mukherjee 
> 
> We have a check for card just after dereferencing it. So if it is NULL
> we have already dereferenced it before its check. Lets dereference it
> after checking card for NULL.

And you are changing the scope of the pdev variable.

Regards,
Arend

> Signed-off-by: Sudip Mukherjee 
> ---
>  drivers/net/wireless/marvell/mwifiex/pcie.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
> b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index edf8b07..d4db9db 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -2884,10 +2884,11 @@ static void mwifiex_unregister_dev(struct 
> mwifiex_adapter *adapter)
>  {
>   struct pcie_service_card *card = adapter->card;
>   const struct mwifiex_pcie_card_reg *reg;
> - struct pci_dev *pdev = card->dev;
>   int i;
>  
>   if (card) {
> + struct pci_dev *pdev = card->dev;
> +
>   if (card->msix_enable) {
>   for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
>   synchronize_irq(card->msix_entries[i].vector);
> 
--
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 0/8] brcmfmac: event handling and other fixes

[Julian Calaby]

Hi Arend,

On Tue, Apr 12, 2016 at 6:55 PM, Arend van Spriel
 wrote:
> On 11-04-16 13:20, Rafał Miłecki wrote:
>> On 11 April 2016 at 11:35, Arend van Spriel  wrote:
>>> This series provides the following:
>>>
>>> * avoid unexpected firmware events.
>>> * allow passing events explicitly for PCIe and SDIO devices.
>>> * fix issue with boardrev entry in nvram.
>>> * fix for wowl.
>>> * fix possible null pointer access upon aborting p2p scan.
>>>
>>> The series is intended for v4.7 kernel and applies to the master
>>> branch of the wireless-drivers-next repository.
>>
>> Hey Arend,
>>
>> Unfortunately I'm finding all your recent messages in spam :( It seems
>> GMail doesn't like something about the Broadcom server:
>> "Why is this message in Spam? It has a from address in broadcom.com
>> but has failed broadcom.com's required tests for authentication. Learn
>> more"
>> Quoted "Learn more" text links to the:
>> https://support.google.com/mail/answer/1366858?hl=en-GB=5
>>
>> Do you think you can point it to sb at Broadcom?
>
> sb? Help me understand this and I may have an appropriate answer :-p
>
> Broadcom actually moved to Google Apps. I am still using my old email
> address and smtp server for submitting patches. Maybe that is the issue
> here.

That's the issue. IIRC this happens because the emails are missing
some header that authenticates them as actually being from
broadcom.com. (I get this all the time when sending Debian bug reports
through my personal SMTP server.)

Thanks,

-- 
Julian Calaby

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

[PATCH v2] mwifiex: fix possible NULL dereference

[Sudip Mukherjee]

From: Sudip Mukherjee 

We have a check for card just after dereferencing it. So if it is NULL
we have already dereferenced it before its check. Lets dereference it
after checking card for NULL.

Signed-off-by: Sudip Mukherjee 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index edf8b07..d4db9db 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2884,10 +2884,11 @@ static void mwifiex_unregister_dev(struct 
mwifiex_adapter *adapter)
 {
struct pcie_service_card *card = adapter->card;
const struct mwifiex_pcie_card_reg *reg;
-   struct pci_dev *pdev = card->dev;
int i;
 
if (card) {
+   struct pci_dev *pdev = card->dev;
+
if (card->msix_enable) {
for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
synchronize_irq(card->msix_entries[i].vector);
-- 
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 1/3] cfg80211: Add option to report the bss entry in connect result

[Kanchanapally, Vidyullatha]

Hi Arend,

The bss table entry in kernel will have the channel indicated in the 
beacon/probe response itself.

But here we are addressing a case where the AP is changing its channel (not 
through CSA but is disconnecting clients on old channel and is coming up on a 
new channel).
In such a scenario, because of the kernel's scan timeout logic, there is a 
small amount of time where the bss table entry is present for the AP on both 
the old and new channel.

If a connect happens with in this time, the kernel might map the 
"wdev->current_bss" to a wrong bss entry, which is obtained in
" __cfg80211_connect_result" through "cfg80211_get_bss(wdev->wiphy, NULL, 
...)". The channel pointer passed here is NULL.
The "wdev->current_bss" is held by the kernel through the connection and the 
bss entry shall not get flushed until a disconnect, although the AP is not seen 
any more in scan results.
The kernel for such a connection will report a wrong channel as associated 
channel.

The current cfg80211 connect indication "cfg80211_connect_result" does not have 
a provision to indicate either the channel or the bss entry.
Hence we are introducing a new cfg80211 api called "cfg80211_connect_bss" which 
includes a bss entry.

Thanks
Vidyullatha

-Original Message-
From: Arend van Spriel [mailto:arend.vanspr...@broadcom.com] 
Sent: Tuesday, April 12, 2016 2:22 PM
To: Kanchanapally, Vidyullatha ; 
johan...@sipsolutions.net
Cc: linux-wireless@vger.kernel.org; Malinen, Jouni ; 
Undekari, Sunil Dutt ; Hullur Subramanyam, Amarnath 

Subject: Re: [PATCH 1/3] cfg80211: Add option to report the bss entry in 
connect result



On 11-04-16 11:46, Kanchanapally, Vidyullatha wrote:
> From: "Kanchanapally, Vidyullatha" 
> 
> Since cfg80211 maintains separate BSS table entries for APs if the 
> same BSSID, SSID pair is seen on multiple channels, it is possible 
> that it can map the current_bss to a BSS entry on the wrong channel. 
> This current_bss will not get flushed unless disconnected and cfg80211 
> reports a wrong channel as the associated channel.
> 
> Fix this by introducing a new cfg80211_connect_bss() function which is 
> similar to cfg80211_connect_result(), but it includes an additional
> parameter: the bss the STA is connected to. This allows drivers to 
> provide the exact bss entry that matches the BSS to which the 
> connection was completed.

How does this work? Is the bss table entry filed with channel it sees the bss 
during scan or does it use the channel indicated in the beacon/probe reponse. I 
would expect the latter. Is the AP beaconing on multiple channels using the 
same BSSID?

It would help understand this change with a driver patch.

Regards,
Arend

> Reviewed-by: Jouni Malinen 
> Signed-off-by: Vidyullatha Kanchanapally 
> Signed-off-by: Sunil Dutt 
> ---
>  include/net/cfg80211.h | 39 +++
>  net/wireless/core.h|  1 +
>  net/wireless/sme.c | 28 ++--
>  net/wireless/util.c|  2 +-
>  4 files changed, 59 insertions(+), 11 deletions(-)
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 
> 858a97ec..51f177c 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -4648,6 +4648,32 @@ static inline void 
> cfg80211_testmode_event(struct sk_buff *skb, gfp_t gfp)  #endif
>  
>  /**
> + * cfg80211_connect_bss - notify cfg80211 of connection result
> + *
> + * @dev: network device
> + * @bssid: the BSSID of the AP
> + * @bss: entry of bss to which STA got connected to, can be obtained
> + *   through cfg80211_get_bss (may be %NULL)
> + * @req_ie: association request IEs (maybe be %NULL)
> + * @req_ie_len: association request IEs length
> + * @resp_ie: association response IEs (may be %NULL)
> + * @resp_ie_len: assoc response IEs length
> + * @status: status code, 0 for successful connection, use
> + *  %WLAN_STATUS_UNSPECIFIED_FAILURE if your device cannot give you
> + *  the real status code for failures.
> + * @gfp: allocation flags
> + *
> + * It should be called by the underlying driver whenever connect() 
> +has
> + * succeeded. This is similar to cfg80211_connect_result(), but with 
> +the
> + * option of identifying the exact bss entry for the connection. Only 
> +one of
> + * these functions should be called.
> + */
> +void cfg80211_connect_bss(struct net_device *dev, const u8 *bssid,
> +   struct cfg80211_bss *bss, const u8 *req_ie,
> +   size_t req_ie_len, const u8 *resp_ie,
> +   size_t resp_ie_len, u16 status, gfp_t gfp);
> +
> +/**
>   * cfg80211_connect_result - notify cfg80211 of connection result
>   *
>   * @dev: network device
> @@ -4664,10 +4690,15 @@ static inline void cfg80211_testmode_event(struct 
> sk_buff 

Re: pull request: iwlwifi 2016-04-12

[Grumbach, Emmanuel]

On Tue, 2016-04-12 at 11:14 +0300, Emmanuel Grumbach wrote:
> Hi Kalle,
> 
> I have here a pull request for 4.6. There is patch in this pull
> request
> that has been sent to -next already but should really have been
> included in the current cycle. Sorry for the mess.
> 
> The commit appears in -next as:
> 
> commit a0b09f13036cedfd67c9cb4b9d05138e7022723d
> Author: Ayala Beker 
> Date:   Wed Feb 3 15:36:52 2016 +0200
> 
> iwlwifi: mvm: update GSCAN capabilities
> 
> Gscan capabilities were updated with new capabilities supported
> by the device. Update GSCAN capabilities TLV.
> 
> I modified the commit message to better emphasis the need to have it
> in
> the current release. You'll see it in this pull request as:
> 
> commit cd49727e1a2bccc4ff008dde24c2f8430dd9e368
> Author: Ayala Beker 
> Date:   Wed Feb 3 15:36:52 2016 +0200
> 
> iwlwifi: mvm: avoid to WARN about gscan capabilities
> 
> Gscan capabilities were updated with new capabilities supported
> by the device. Update GSCAN capabilities TLV and avoid to WARN
> if the firmware does not have the new capabilities.
> 
> Besides this, all is fairly normal.
> Please pull, thanks!
> 
> 
> The following changes since commit
> 7fdf9663261cc77a516396fec82cee8a8ea07e76:
> 
>   iwlwifi: mvm: fix memory leak in paging (2016-03-20 23:01:54 +0200)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fix
> es.git tags/iwlwifi-for-kalle-2016-04-12
> 
> for you to fetch changes up to
> 2d25fb8b3a138706b63bd26ad72a95c58029954a:
> 
>   iwlwifi: mvm: fix accessing Null pointer during fw dump collection
> (2016-04-12 10:03:17 +0300)
> 

Sara found an embarrassing last minute issue.
New tag is iwlwifi-for-kalle-2016-04-12_2.
 
Here is the diff:
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-8000.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
index cf48122..b5c57ee 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
@@ -93,7 +93,7 @@
 #define IWL8260_SMEM_OFFSET0x40
 #define IWL8260_SMEM_LEN   0x68000
 
-#define IWL8000_FW_PRE "iwlwifi-8000C"
+#define IWL8000_FW_PRE "iwlwifi-8000C-"
 #define IWL8000_MODULE_FIRMWARE(api) \
IWL8000_FW_PRE "-" __stringify(api) ".ucode"
 

> 
> * add new device IDs for 8265
> * fix a NULL pointer dereference when paging firmware asserts
> * remove a WARNING on gscan capabilities
> * fix MODULE_FIRMWARE for 8260
> 
> 
> Ayala Beker (1):
>   iwlwifi: mvm: avoid to WARN about gscan capabilities
> 
> Matti Gottlieb (1):
>   iwlwifi: mvm: fix accessing Null pointer during fw dump
> collection
> 
> Oren Givon (1):
>   iwlwifi: add device IDs for the 8265 device
> 
> Sara Sharon (1):
>   iwlwifi: 8000: fix MODULE_FIRMWARE input
> 
>  drivers/net/wireless/intel/iwlwifi/iwl-8000.c   |  2 +-
>  drivers/net/wireless/intel/iwlwifi/iwl-drv.c| 26 ++-
> ---
>  drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c |  6 --
>  drivers/net/wireless/intel/iwlwifi/mvm/fw.c |  2 ++
>  drivers/net/wireless/intel/iwlwifi/pcie/drv.c   | 10 ++
>  5 files changed, 27 insertions(+), 19 deletions(-)

Re: [PATCH 0/8] brcmfmac: event handling and other fixes

[Arend van Spriel]

On 11-04-16 13:20, Rafał Miłecki wrote:
> On 11 April 2016 at 11:35, Arend van Spriel  wrote:
>> This series provides the following:
>>
>> * avoid unexpected firmware events.
>> * allow passing events explicitly for PCIe and SDIO devices.
>> * fix issue with boardrev entry in nvram.
>> * fix for wowl.
>> * fix possible null pointer access upon aborting p2p scan.
>>
>> The series is intended for v4.7 kernel and applies to the master
>> branch of the wireless-drivers-next repository.
> 
> Hey Arend,
> 
> Unfortunately I'm finding all your recent messages in spam :( It seems
> GMail doesn't like something about the Broadcom server:
> "Why is this message in Spam? It has a from address in broadcom.com
> but has failed broadcom.com's required tests for authentication. Learn
> more"
> Quoted "Learn more" text links to the:
> https://support.google.com/mail/answer/1366858?hl=en-GB=5
> 
> Do you think you can point it to sb at Broadcom?

sb? Help me understand this and I may have an appropriate answer :-p

Broadcom actually moved to Google Apps. I am still using my old email
address and smtp server for submitting patches. Maybe that is the issue
here.

Regards,
Arend
--
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 1/3] cfg80211: Add option to report the bss entry in connect result

[Arend van Spriel]

On 11-04-16 11:46, Kanchanapally, Vidyullatha wrote:
> From: "Kanchanapally, Vidyullatha" 
> 
> Since cfg80211 maintains separate BSS table entries for APs if the same
> BSSID, SSID pair is seen on multiple channels, it is possible that it
> can map the current_bss to a BSS entry on the wrong channel. This
> current_bss will not get flushed unless disconnected and cfg80211
> reports a wrong channel as the associated channel.
> 
> Fix this by introducing a new cfg80211_connect_bss() function which is
> similar to cfg80211_connect_result(), but it includes an additional
> parameter: the bss the STA is connected to. This allows drivers to
> provide the exact bss entry that matches the BSS to which the connection
> was completed.

How does this work? Is the bss table entry filed with channel it sees
the bss during scan or does it use the channel indicated in the
beacon/probe reponse. I would expect the latter. Is the AP beaconing on
multiple channels using the same BSSID?

It would help understand this change with a driver patch.

Regards,
Arend

> Reviewed-by: Jouni Malinen 
> Signed-off-by: Vidyullatha Kanchanapally 
> Signed-off-by: Sunil Dutt 
> ---
>  include/net/cfg80211.h | 39 +++
>  net/wireless/core.h|  1 +
>  net/wireless/sme.c | 28 ++--
>  net/wireless/util.c|  2 +-
>  4 files changed, 59 insertions(+), 11 deletions(-)
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 858a97ec..51f177c 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -4648,6 +4648,32 @@ static inline void cfg80211_testmode_event(struct 
> sk_buff *skb, gfp_t gfp)
>  #endif
>  
>  /**
> + * cfg80211_connect_bss - notify cfg80211 of connection result
> + *
> + * @dev: network device
> + * @bssid: the BSSID of the AP
> + * @bss: entry of bss to which STA got connected to, can be obtained
> + *   through cfg80211_get_bss (may be %NULL)
> + * @req_ie: association request IEs (maybe be %NULL)
> + * @req_ie_len: association request IEs length
> + * @resp_ie: association response IEs (may be %NULL)
> + * @resp_ie_len: assoc response IEs length
> + * @status: status code, 0 for successful connection, use
> + *  %WLAN_STATUS_UNSPECIFIED_FAILURE if your device cannot give you
> + *  the real status code for failures.
> + * @gfp: allocation flags
> + *
> + * It should be called by the underlying driver whenever connect() has
> + * succeeded. This is similar to cfg80211_connect_result(), but with the
> + * option of identifying the exact bss entry for the connection. Only one of
> + * these functions should be called.
> + */
> +void cfg80211_connect_bss(struct net_device *dev, const u8 *bssid,
> +   struct cfg80211_bss *bss, const u8 *req_ie,
> +   size_t req_ie_len, const u8 *resp_ie,
> +   size_t resp_ie_len, u16 status, gfp_t gfp);
> +
> +/**
>   * cfg80211_connect_result - notify cfg80211 of connection result
>   *
>   * @dev: network device
> @@ -4664,10 +4690,15 @@ static inline void cfg80211_testmode_event(struct 
> sk_buff *skb, gfp_t gfp)
>   * It should be called by the underlying driver whenever connect() has
>   * succeeded.
>   */
> -void cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
> -  const u8 *req_ie, size_t req_ie_len,
> -  const u8 *resp_ie, size_t resp_ie_len,
> -  u16 status, gfp_t gfp);
> +static inline void
> +cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
> + const u8 *req_ie, size_t req_ie_len,
> + const u8 *resp_ie, size_t resp_ie_len,
> + u16 status, gfp_t gfp)
> +{
> + cfg80211_connect_bss(dev, bssid, NULL, req_ie, req_ie_len, resp_ie,
> +  resp_ie_len, status, gfp);
> +}
>  
>  /**
>   * cfg80211_roamed - notify cfg80211 of roaming
> diff --git a/net/wireless/core.h b/net/wireless/core.h
> index 64c70e4..f3b0a07 100644
> --- a/net/wireless/core.h
> +++ b/net/wireless/core.h
> @@ -214,6 +214,7 @@ struct cfg80211_event {
>   const u8 *resp_ie;
>   size_t req_ie_len;
>   size_t resp_ie_len;
> + struct cfg80211_bss *bss;
>   u16 status;
>   } cr;
>   struct {
> diff --git a/net/wireless/sme.c b/net/wireless/sme.c
> index 1fba416..da97424d 100644
> --- a/net/wireless/sme.c
> +++ b/net/wireless/sme.c
> @@ -753,19 +753,32 @@ void __cfg80211_connect_result(struct net_device *dev, 
> const u8 *bssid,
>   kfree(country_ie);
>  }
>  
> -void cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
> -  const u8 *req_ie, size_t req_ie_len,
> -  const u8 *resp_ie, 

[PATCH 2/4] iwlwifi: mvm: avoid to WARN about gscan capabilities

[Emmanuel Grumbach]

From: Ayala Beker 

Gscan capabilities were updated with new capabilities supported
by the device. Update GSCAN capabilities TLV and avoid to WARN
if the firmware does not have the new capabilities.

Signed-off-by: Ayala Beker 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index f899666..33d0d51 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -1060,11 +1060,18 @@ static int iwl_parse_tlv_firmware(struct iwl_drv *drv,
return -EINVAL;
}
 
-   if (WARN(fw_has_capa(capa, IWL_UCODE_TLV_CAPA_GSCAN_SUPPORT) &&
-!gscan_capa,
-"GSCAN is supported but capabilities TLV is unavailable\n"))
+   /*
+* If ucode advertises that it supports GSCAN but GSCAN
+* capabilities TLV is not present, or if it has an old format,
+* warn and continue without GSCAN.
+*/
+   if (fw_has_capa(capa, IWL_UCODE_TLV_CAPA_GSCAN_SUPPORT) &&
+   !gscan_capa) {
+   IWL_DEBUG_INFO(drv,
+  "GSCAN is supported but capabilities TLV is 
unavailable\n");
__clear_bit((__force long)IWL_UCODE_TLV_CAPA_GSCAN_SUPPORT,
capa->_capa);
+   }
 
return 0;
 
-- 
2.5.0

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

[PATCH 3/4] iwlwifi: 8000: fix MODULE_FIRMWARE input

[Emmanuel Grumbach]

From: Sara Sharon 

The firwmare name for 8000 is iwlwifi-8000C. The C is
appended based on a value read from a register. This
allows to load different firwmare versions based on
the hardware step during development. Now that the
hardware development is completed, we can hard code
the 'C' and along the way, fix the input to
MODULE_FIRMWARE.

This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=116041

Signed-off-by: Sara Sharon 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/intel/iwlwifi/iwl-8000.c |  2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c  | 13 -
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-8000.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
index 97be104..cf48122 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
@@ -93,7 +93,7 @@
 #define IWL8260_SMEM_OFFSET0x40
 #define IWL8260_SMEM_LEN   0x68000
 
-#define IWL8000_FW_PRE "iwlwifi-8000"
+#define IWL8000_FW_PRE "iwlwifi-8000C"
 #define IWL8000_MODULE_FIRMWARE(api) \
IWL8000_FW_PRE "-" __stringify(api) ".ucode"
 
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index 33d0d51..9e45bf9 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -238,19 +238,6 @@ static int iwl_request_firmware(struct iwl_drv *drv, bool 
first)
snprintf(drv->firmware_name, sizeof(drv->firmware_name), "%s%s.ucode",
 name_pre, tag);
 
-   /*
-* Starting 8000B - FW name format has changed. This overwrites the
-* previous name and uses the new format.
-*/
-   if (drv->trans->cfg->device_family == IWL_DEVICE_FAMILY_8000) {
-   char rev_step = 'A' + CSR_HW_REV_STEP(drv->trans->hw_rev);
-
-   if (rev_step != 'A')
-   snprintf(drv->firmware_name,
-sizeof(drv->firmware_name), "%s%c-%s.ucode",
-name_pre, rev_step, tag);
-   }
-
IWL_DEBUG_INFO(drv, "attempting to load firmware %s'%s'\n",
   (drv->fw_index == UCODE_EXPERIMENTAL_INDEX)
? "EXPERIMENTAL " : "",
-- 
2.5.0

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

[PATCH 4/4] iwlwifi: mvm: fix accessing Null pointer during fw dump collection

[Emmanuel Grumbach]

From: Matti Gottlieb 

The firwmare file can come with data that is relevant for paging. This
data is availablet to the firmware upon request, but it stored in the
host's memory. During the firmware init flow, the driver configures the
firmware so that the firwmare knows where is the data.
When paging is used, the variable paging_mem_size is the number of bytes
that are available through paging. This variable is not zeror-ed if the
driver fails to configure the paging in the firmware, but the memory is
freed which is inconsistent.
This inconsistency led to a NULL pointer dereference in the code that
collects the debug data.

Fix this by zero-ing the paging_mem_size variable and NULLify the
relevant pointers, so that the code that collects the debug data will
know that the paging data is not available.

Signed-off-by: Matti Gottlieb 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 6 --
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
index 4856eac..6938cd3 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
@@ -526,7 +526,8 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
file_len += sizeof(*dump_data) + sizeof(*dump_mem) + sram2_len;
 
/* Make room for fw's virtual image pages, if it exists */
-   if (mvm->fw->img[mvm->cur_ucode].paging_mem_size)
+   if (mvm->fw->img[mvm->cur_ucode].paging_mem_size &&
+   mvm->fw_paging_db[0].fw_paging_block)
file_len += mvm->num_of_paging_blk *
(sizeof(*dump_data) +
 sizeof(struct iwl_fw_error_dump_paging) +
@@ -643,7 +644,8 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
}
 
/* Dump fw's virtual image */
-   if (mvm->fw->img[mvm->cur_ucode].paging_mem_size) {
+   if (mvm->fw->img[mvm->cur_ucode].paging_mem_size &&
+   mvm->fw_paging_db[0].fw_paging_block) {
for (i = 1; i < mvm->num_of_paging_blk + 1; i++) {
struct iwl_fw_error_dump_paging *paging;
struct page *pages =
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index 594cd0d..09d895f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -144,9 +144,11 @@ void iwl_free_fw_paging(struct iwl_mvm *mvm)
 
__free_pages(mvm->fw_paging_db[i].fw_paging_block,
 get_order(mvm->fw_paging_db[i].fw_paging_size));
+   mvm->fw_paging_db[i].fw_paging_block = NULL;
}
kfree(mvm->trans->paging_download_buf);
mvm->trans->paging_download_buf = NULL;
+   mvm->trans->paging_db = NULL;
 
memset(mvm->fw_paging_db, 0, sizeof(mvm->fw_paging_db));
 }
-- 
2.5.0

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

[PATCH 1/4] iwlwifi: add device IDs for the 8265 device

[Emmanuel Grumbach]

From: Oren Givon 

Add new 8265 series PCI IDs.

Signed-off-by: Oren Givon 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 05b9685..79d7cd7 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -479,8 +479,18 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0x24F3, 0x0930, iwl8260_2ac_cfg)},
{IWL_PCI_DEVICE(0x24F3, 0x, iwl8265_2ac_cfg)},
{IWL_PCI_DEVICE(0x24FD, 0x0010, iwl8265_2ac_cfg)},
+   {IWL_PCI_DEVICE(0x24FD, 0x0110, iwl8265_2ac_cfg)},
+   {IWL_PCI_DEVICE(0x24FD, 0x1110, iwl8265_2ac_cfg)},
+   {IWL_PCI_DEVICE(0x24FD, 0x1010, iwl8265_2ac_cfg)},
+   {IWL_PCI_DEVICE(0x24FD, 0x0050, iwl8265_2ac_cfg)},
+   {IWL_PCI_DEVICE(0x24FD, 0x0150, iwl8265_2ac_cfg)},
+   {IWL_PCI_DEVICE(0x24FD, 0x9010, iwl8265_2ac_cfg)},
+   {IWL_PCI_DEVICE(0x24FD, 0x8110, iwl8265_2ac_cfg)},
+   {IWL_PCI_DEVICE(0x24FD, 0x8050, iwl8265_2ac_cfg)},
{IWL_PCI_DEVICE(0x24FD, 0x8010, iwl8265_2ac_cfg)},
{IWL_PCI_DEVICE(0x24FD, 0x0810, iwl8265_2ac_cfg)},
+   {IWL_PCI_DEVICE(0x24FD, 0x9110, iwl8265_2ac_cfg)},
+   {IWL_PCI_DEVICE(0x24FD, 0x8130, iwl8265_2ac_cfg)},
 
 /* 9000 Series */
{IWL_PCI_DEVICE(0x9DF0, 0x2A10, iwl5165_2ac_cfg)},
-- 
2.5.0

--
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

pull request: iwlwifi 2016-04-12

[Grumbach, Emmanuel]

Hi Kalle,

I have here a pull request for 4.6. There is patch in this pull request
that has been sent to -next already but should really have been
included in the current cycle. Sorry for the mess.

The commit appears in -next as:

commit a0b09f13036cedfd67c9cb4b9d05138e7022723d
Author: Ayala Beker 
Date:   Wed Feb 3 15:36:52 2016 +0200

iwlwifi: mvm: update GSCAN capabilities

Gscan capabilities were updated with new capabilities supported
by the device. Update GSCAN capabilities TLV.

I modified the commit message to better emphasis the need to have it in
the current release. You'll see it in this pull request as:

commit cd49727e1a2bccc4ff008dde24c2f8430dd9e368
Author: Ayala Beker 
Date:   Wed Feb 3 15:36:52 2016 +0200

iwlwifi: mvm: avoid to WARN about gscan capabilities

Gscan capabilities were updated with new capabilities supported
by the device. Update GSCAN capabilities TLV and avoid to WARN
if the firmware does not have the new capabilities.

Besides this, all is fairly normal.
Please pull, thanks!


The following changes since commit 7fdf9663261cc77a516396fec82cee8a8ea07e76:

  iwlwifi: mvm: fix memory leak in paging (2016-03-20 23:01:54 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2016-04-12

for you to fetch changes up to 2d25fb8b3a138706b63bd26ad72a95c58029954a:

  iwlwifi: mvm: fix accessing Null pointer during fw dump collection 
(2016-04-12 10:03:17 +0300)


* add new device IDs for 8265
* fix a NULL pointer dereference when paging firmware asserts
* remove a WARNING on gscan capabilities
* fix MODULE_FIRMWARE for 8260


Ayala Beker (1):
  iwlwifi: mvm: avoid to WARN about gscan capabilities

Matti Gottlieb (1):
  iwlwifi: mvm: fix accessing Null pointer during fw dump collection

Oren Givon (1):
  iwlwifi: add device IDs for the 8265 device

Sara Sharon (1):
  iwlwifi: 8000: fix MODULE_FIRMWARE input

 drivers/net/wireless/intel/iwlwifi/iwl-8000.c   |  2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c| 26 ++
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c |  6 --
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c |  2 ++
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c   | 10 ++
 5 files changed, 27 insertions(+), 19 deletions(-)

RE: [PATCH 1/7] wil6210: add function name to wil log macros

[Haim, Maya]

On 4/7/2016 6:41 PM, Kalle Valo wrote:
> "Haim, Maya"  writes:
>
>> On 4/6/2016 10:19 AM, Joe Perches wrote:
>>> On Tue, 2016-04-05 at 14:24 +0300, Maya Erez wrote:
 Add __func__ to all wil log macros for easier debugging.
>>> I think this is unnecessary and merely bloats code size.
>>> For all the _dbg calls, dynamic debug can add function names if 
>>> desired.
>>>
>>> If really desired, I suggest changing the logging functions to use 
>>> "%ps and __builtin_return_address(0)
>> I implemented it with __builtin_return_address(0) at first but found 
>> its format less readable (e.g. wil_start_xmit+0x58/0x7e8).
> Will that work with inline functions and with functions which the 
> compiler has optimised out?
>
That's a good point. I did a quick check and it doesn't work for inline or 
static functions - for such functions, the name of the calling function is 
printed.
We can either (1) use my initial implementation (2) add __func__ only to the 
wil_dbg_... macros or (3) revert this patch completely.
I find the addition of the function names very useful and since most of the 
code doesn't include it, it makes the analysis of issues  less efficient.
Kalle - what is your say on that?


--
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: hardware restart on Intel 7260

[Johann Haarhoff]

> Meh... So what happens here is that the firmware is stuck while
> transmitting. The driver detects this and as a workaround, resets the
> firmware. The detection takes 10 seconds.
> The only way to understand what is going on here is to take the
> firmware from [1] and to run the steps to collect firmware debug data
> from [2]. I recommend you open a bug on bugzilla.
> Out of curiosity, did you try to work in DC mode (on battery, not
> connected to the power)? A user reported that it helped [3].

I followed the steps you suggested, and am now tracking the bug here:

https://bugzilla.kernel.org/show_bug.cgi?id=116191



--
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: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Grumbach, Emmanuel]

> On Sun, Apr 10, 2016 at 1:28 PM, Grumbach, Emmanuel
>  wrote:
> >> > On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote:
> >> Is the iwlwifi driver capable of capturing data frames when the
> >> channel bonding is set to 80Mhz?
> >
> > dev  set freq  [20|40|80|80+80|160] [ > freq 1>] []
> >
> > You can take center_freq1 from the output of iw dev on a device that is
> associated to the same AP.
> 
> Thanks a lot, Emmanuel. My iw binary that came default with my Ubuntu
> distribution was very old (3.4) and it didn't have support for channel bonding
> larger than 40Mhz.
> I compiled the latest iw version from sources then I took the
> center_freq1 from the beacon advertised by the AP. That's because the iw
> dev on a device associated to the same AP gave me the control frequency.
> After that, I was able to capture the data frames.
> 
> One more question that I promise to be the last one:
> - I am trying to capture the Wi-Fi Direct traffic between two
> smartphones: iw shows me that the p2p interface from one of the
> smartphones uses 2.4Ghz, channel 1 so I set the monitor interface on 2.4,
> channel 1. The problem is that, again, I can't see the data frames. Instead, I
> can see the Association/Authentication Request, RTS/CTS, Block ACK (I
> attached the Wireshark capture at [1]).
> 

   ...1 = HT LDPC coding capability: Transmitter supports receiving 
LDPC coded packets

This means that both sides use a coding algo that 7260 doesn't understand. 7260 
talks Viterbi.
The only way to go here is to get a 7265 module (or later) instead.

> Analyzing the capture, I noticed that the HT capabilities advertised in the
> beacon frames indicates 802.11n D1.10. Does this trigger any indication for
> you on how to setup the monitor interface?
> 
> [1]
> https://drive.google.com/file/d/0B5SBH08PU_ChNllaVHRienBSVlE/view?usp
> =sharing
> 
> Regards,
> Doru