Re: pull-request: wireless-drivers-next 2016-05-13

2016-05-16 Thread Kalle Valo
Hi Dave, Kalle Valo writes: > Kalle Valo writes: > >> Kalle Valo writes: >> >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git >>> tags/wireless-drivers-next-for-davem-2016-05-13 >> >> Please don't pull this yet, there might be something wrong now with >>

Re: rt2800 maximum clients in access point mode

2016-05-16 Thread Kalle Valo
Craig McQueen writes: > What is the maximum number of clients that an rt2800 device can > support simultaneously while in access point mode? > > I've had a look through the Linux kernel code and searched online, but > haven't been able to find an answer so far. If you find the answer, please sub

rt2800 maximum clients in access point mode

2016-05-16 Thread Craig McQueen
What is the maximum number of clients that an rt2800 device can support simultaneously while in access point mode? I've had a look through the Linux kernel code and searched online, but haven't been able to find an answer so far. -- Craig McQueen -- To unsubscribe from this list: send the lin

Re: [PATCH] [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM.

2016-05-16 Thread Kalle Valo
Adrian Chadd writes: > Check the current PHY operating mode (gmode) to see if we should > fall back from 6MB OFDM to 11MB CCK. For 5GHz operation this isn't > allowed. > > Note, the fallback lookup is only done for RTS rates; normal fallback > rates are done via mac80211 and aren't affected by t

[PATCH] [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM.

2016-05-16 Thread Adrian Chadd
Check the current PHY operating mode (gmode) to see if we should fall back from 6MB OFDM to 11MB CCK. For 5GHz operation this isn't allowed. Note, the fallback lookup is only done for RTS rates; normal fallback rates are done via mac80211 and aren't affected by this change. Signed-off-by

[PATCH] b43: don't fall back to CCK rates on 5GHz OFDM for RTS frames

2016-05-16 Thread Adrian Chadd
This fixes a small issue with selecting fallback rates for RTS frames. For OFDM PHY rates in 5GHz mode we shouldn't fall back to CCK. Adrian Chadd (1): [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM. drivers/net/wireless/broadcom/b43/xmit.c | 13 ++--- 1 file cha

[PATCH 2/6] wil6210: guarantee safe access to rx descriptors shared memory

2016-05-16 Thread Maya Erez
add memory barrier after allocating new rx descriptors, before updating the hwtail. This will guarantee that all writes to descriptors (shared memory) are done before committing them to HW. Signed-off-by: Maya Erez --- drivers/net/wireless/ath/wil6210/txrx.c | 6 ++ 1 file changed, 6 inserti

[PATCH 4/6] wil6210: fix dma mapping error cleanup in __wil_tx_vring_tso

2016-05-16 Thread Maya Erez
In case we fail to map one of the TSO SKB fragments, we need to clear all the mapped descriptors, from swhead to swhead+descs_used-1. Change the desc index calculation to i = (swhead + descs_used - 1) % vring->size; to prevent unmpping of (swhead + descs_used) descriptor that wasn't mapped. Signe

[PATCH 5/6] wil6210: add pm_notify handling

2016-05-16 Thread Maya Erez
Adding pm_notify to allow the following: 1. Check if suspend is allowed in an earlier stage to prevent starting the suspend procedure in case it is not allowed 2. Notify the platform driver on the suspend request Signed-off-by: Maya Erez --- drivers/net/wireless/ath/wil6210/pcie_bus.c | 68 +

[PATCH 3/6] wil6210: protect wil_vring_fini_tx in parallel to tx completions

2016-05-16 Thread Maya Erez
napi_synchronize is called before releasing the vring, with the assumption that setting txdata->enabled to 0 will prevent handling of this vring in the next scheduled napi. To guarantee this assumption, a memory barrier is added after disabling the txdata. In addition, as the ctx is zeroed in wil_t

[PATCH 0/6] wil6210 patches

2016-05-16 Thread Maya Erez
The below set of patches includes: - Various wil6210 fixes for multi core environment - Addition of pm_notify handling for early reject / approval of the suspend Maya Erez (6): wil6210: fix race conditions between TX send and completion wil6210: guarantee safe access to rx descriptors shared m

[PATCH 1/6] wil6210: fix race conditions between TX send and completion

2016-05-16 Thread Maya Erez
There are 2 possible race conditions, both are solved by addition of memory barrier: 1. wil_tx_complete reads the swhead to determine if the vring is empty. In case the swhead was updated before the descriptor update was performed in __wil_tx_vring/__wil_tx_vring_tso, the completion loop will not e

[PATCH 6/6] wil6210: align wil log functions to wil_dbg_ratelimited implementation

2016-05-16 Thread Maya Erez
Change the implementation of wil log functions for consistency with __wil_dbg_ratelimited. Signed-off-by: Maya Erez --- drivers/net/wireless/ath/wil6210/debug.c | 46 ++-- 1 file changed, 20 insertions(+), 26 deletions(-) diff --git a/drivers/net/wireless/ath/wil6210

Re: [PATCH 1/2] linux-firmware: update rt2860.bin, rt2800pci driver

2016-05-16 Thread Kyle McMartin
On Wed, May 04, 2016 at 04:59:59PM +0200, Xose Vazquez Perez wrote: > rt2860.bin: from 34 to 0.40 > applied 1 & 2. thanks, --Kyle -- 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

Re: [ANNOUNCE] Netdev 1.2 conference

2016-05-16 Thread Stephen Hemminger
On Tue, 17 May 2016 00:36:58 +0900 Hajime Tazaki wrote: > Following the last successful Netdev 0.1 in Ottawa, Canada and > 1.1 in Seville, Spain. We are happy to announce the third Netdev conference: > Netdev 1.2 (year 1, conference 2) from 5th to 7th October 2016 in Tokyo, > Japan (http://netdev

Re: iwlwifi: mvm: add reorder buffer per queue

2016-05-16 Thread Dave Taht
I can't even describe how much I hate the concept of the reorder buffer in general. Ordering is the endpoints problem. Someday, after we get fq_codeled, short queues again, I'll be able to show why. On Mon, May 16, 2016 at 4:41 AM, Luca Coelho wrote: > On Fri, 2016-05-13 at 11:54 +0300, Dan Carp

Re: pull-request: wireless-drivers-next 2016-05-13

2016-05-16 Thread Coelho, Luciano
On Mon, 2016-05-16 at 17:08 +0300, Kalle Valo wrote: > Kalle Valo writes: > > > > > Kalle Valo writes: > > > > > > > > The following changes since commit > > > ede00a5ceb4d903a8c137a52bb77d574baaef8bd: > > > > > >   Merge tag 'wireless-drivers-next-for-davem-2016-05-02' of > > > git://git.ke

[ANNOUNCE] Netdev 1.2 conference

2016-05-16 Thread Hajime Tazaki
Following the last successful Netdev 0.1 in Ottawa, Canada and 1.1 in Seville, Spain. We are happy to announce the third Netdev conference: Netdev 1.2 (year 1, conference 2) from 5th to 7th October 2016 in Tokyo, Japan (http://netdevconf.org/1.2/). Netdev 1.2 is a community-driven conference gear

Re: linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

2016-05-16 Thread David Miller
From: Kalle Valo Date: Mon, 16 May 2016 16:10:27 +0300 > I wasn't expecting that skb_info variable is removed. Do we now have > merge damage somewhere? Luca, what do you think? It's possible I got the net --> net-next merge wrong the other day, feel free to send me an appropriate fixup. Thanks.

Re: pull-request: wireless-drivers-next 2016-05-13

2016-05-16 Thread Kalle Valo
Kalle Valo writes: > Kalle Valo writes: > >> The following changes since commit ede00a5ceb4d903a8c137a52bb77d574baaef8bd: >> >> Merge tag 'wireless-drivers-next-for-davem-2016-05-02' of >> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next >> (2016-05-03 00:35:16 -0400

Re: linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

2016-05-16 Thread Kalle Valo
"Coelho, Luciano" writes: (dropping damaged diffs etc, adding Emmanuel as the author of 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the AMSDU len")) >> I wasn't expecting that skb_info variable is removed. Do we now have >> merge damage somewhere? Luca, what do you think? > > As we

Re: linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

2016-05-16 Thread Coelho, Luciano
Hi Kalle, On Mon, 2016-05-16 at 16:10 +0300, Kalle Valo wrote: > (Adding Luca and linux-wireless) > > Stephen Rothwell writes: > > > > > Today's linux-next merge of the wireless-drivers-next tree got a > > conflict in: > > > >   drivers/net/wireless/intel/iwlwifi/mvm/tx.c > > > > between com

Re: pull-request: wireless-drivers-next 2016-05-13

2016-05-16 Thread Kalle Valo
Hi Dave, Kalle Valo writes: > this is the last pull request to net-next for 4.7. Nothing really out of > ordinary, the signed tag below contains more info. Please let me know if > there are any issues. > > Kalle > > > The following changes since commit ede00a5ceb4d903a8c137a52bb77d574baaef8bd: >

Re: linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

2016-05-16 Thread Kalle Valo
(Adding Luca and linux-wireless) Stephen Rothwell writes: > Today's linux-next merge of the wireless-drivers-next tree got a > conflict in: > > drivers/net/wireless/intel/iwlwifi/mvm/tx.c > > between commit: > > 909b27f70643 ("Merge > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net"

Re: wifi driver crashes openwrt device

2016-05-16 Thread Kalle Valo
Bob Copeland writes: > On Tue, May 10, 2016 at 03:17:25PM +, andy wrote: >> hello, every body. >> I developed an openwrt device based on git clone >> git://git.openwrt.org/15.05/openwrt.git. >> I found that my device rebooted during wifi initializing sometimes, maybe >> one in twenty.

Re: iwlwifi: mvm: add reorder buffer per queue

2016-05-16 Thread Luca Coelho
On Fri, 2016-05-13 at 11:54 +0300, Dan Carpenter wrote: > Hello Sara Sharon, > > The patch b915c10174fb: "iwlwifi: mvm: add reorder buffer per queue" > from Mar 23, 2016, leads to the following static checker warnings: > > drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:912 > iwl_mvm_rx_mpdu_

Re: [b43] don't unconditionally fall back to CCK if the rate is 6MB OFDM.

2016-05-16 Thread Kalle Valo
Michael Büsch writes: > In the final submission please send this to Kalle Valo and add [PATCH] > to the subject, so tools can pick this up. And remember to CC linux-wireless so that patchwork sees the patch. I skip the patches sent via email and only follow patchwork: https://patchwork.kernel.o