Re: Problem with brcmfmac removing extra interface

2016-05-06 Thread Rafał Miłecki 
On 23 March 2016 at 20:13, Rafał Miłecki  wrote:
> On 23 March 2016 at 11:44, Arend Van Spriel
>  wrote:
>> On 23-3-2016 9:47, Rafał Miłecki wrote:
>>> On 22 March 2016 at 21:24, Arend van Spriel
>>>  wrote:
 On 22-3-2016 7:36, Rafał Miłecki wrote:
> Hi, any ideas / help regarding this issue?

 Restarting hostapd obviously is a valid scenario. My guess is we would
 need to avoid interface removal in brcmf_notify_connect_status_ap. But
 first I would like to know in which state the firmware is upon
 brcmf_ap_add_vif. Can you provide a full log with FWCON debug level 
 enabled?
>>>
>>> Sure, hope it helps!
>>
>> Ah. Actually would like to see some driver logging as well so
>> 'debug=0x101410'.
>
> Sure, there you go.

Did this allow you to understand this problem any better? Do you have
any idea for a solution?

-- 
Rafał
--
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] ath10k: release pre_cal_file while unloading driver

2016-05-06 Thread Valo, Kalle 
Rajkumar Manoharan  writes:

> Failing to release pre_cal_file caldata on deinit causes memory leak.
>
> Fixes: b131129d9657 ("ath10k: fix calibration init sequence of qca99x0")
> Signed-off-by: Rajkumar Manoharan 

Applied, thanks.

-- 
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 v2 1/4] ath10k: add pdev bss channel info wmi definitions

2016-05-06 Thread Valo, Kalle 
Rajkumar Manoharan  writes:

> Add WMI definitions for pdev bss channel information request and
> event.
>
> Signed-off-by: Rajkumar Manoharan 

Applied, thanks.

-- 
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] ath10k: Move spectral related structures under ath10k debugfs

2016-05-06 Thread Valo, Kalle 
Mohammed Shafi Shajakhan  writes:

> From: Mohammed Shafi Shajakhan 
>
> Spectral related structures are accessed / modified only if ath10k
> debugfs is enabled, so it makes more sense to move them under
> ATH10K_DEBUGFS
>
> Signed-off-by: Mohammed Shafi Shajakhan 

Applied, thanks.

-- 
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 v2] ath10k: remove VHT capabilities from 2.4GHz

2016-05-06 Thread Valo, Kalle 
Kalle Valo  writes:

> From: Johannes Berg 
>
> According to the spec, VHT doesn't exist in 2.4GHz.
>
> There are vendor extensions to allow a subset of VHT to work
> (notably 256-QAM), but since mac80211 doesn't support those
> advertising VHT capability on 2.4GHz leads to the behaviour
> of reporting VHT capabilities but not being able to use any
> of them due to mac80211's code requiring 80 MHz support.
>
> Remove the VHT capabilities from 2.4GHz for now. If mac80211
> gets extended to use the (likely Broadcom) vendor IEs for it
> and handles the lack of 80 MHz support, it can be added back.
>
> Signed-off-by: Johannes Berg 
> Signed-off-by: Kalle Valo 

Applied, thanks.

-- 
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] ath10k: fix kernel panic, move arvifs list head init before htt init

2016-05-06 Thread Valo, Kalle 
 writes:

> From: Anilkumar Kolli 
>
> It is observed that while loading and unloading ath10k modules
> in an infinite loop, before ath10k_core_start() completion HTT
> rx frames are received, while processing these frames,
> dereferencing the arvifs list code is getting hit before
> initilizing the arvifs list, causing a kernel panic.
>
> This patch initilizes the arvifs list before initilizing htt.
>
> Fixes the below issue:
>  [] (ath10k_htt_rx_pktlog_completion_handler+0x278/0xd08 
> [ath10k_core])
>  [] (ath10k_htt_rx_pktlog_completion_handler [ath10k_core])
>  [] (ath10k_htt_txrx_compl_task+0x5f4/0xeb0 [ath10k_core])
>  [] (ath10k_htt_txrx_compl_task [ath10k_core])
>  [] (tasklet_action+0x8c/0xec)
>  [] (tasklet_action)
>  [] (__do_softirq+0xf8/0x228)
>  [] (__do_softirq)  [] (run_ksoftirqd+0x30/0x90)
>  Code: e5954ad8 e2899008 e1540009 0a0d (e5943008)
>  ---[ end trace 71de5c2e011dbf56 ]---
>  Kernel panic - not syncing: Fatal exception in interrupt
>
> Fixes: 500ff9f9389d ("ath10k: implement chanctx API")
> Cc: sta...@vger.kernel.org
>
> Signed-off-by: Anilkumar Kolli 

Applied, thanks.

-- 
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 v2] rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring

2016-05-06 Thread Alexander Duyck 
On Fri, May 6, 2016 at 11:01 AM, Larry Finger  wrote:
> On 05/06/2016 12:13 PM, Alexander Duyck wrote:
>>
>> On Fri, May 6, 2016 at 9:33 AM, Wang YanQing  wrote:
>>>
>>> We can't use kfree_skb in irq disable context, because spin_lock_irqsave
>>> make sure we are always in irq disable context, use dev_kfree_skb_irq
>>> instead of kfree_skb is better than dev_kfree_skb_any.
>>>
>>> This patch fix below kernel warning:
>>> [ 7612.095528] [ cut here ]
>>> [ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150
>>> __local_bh_enable_ip+0x58/0x80()
>>> [ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal
>>> btcoexist rtl_pci rtlwifi rtl8723_common
>>> [ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: GW
>>> 4.4.0+ #4
>>> [ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW
>>> (1.19 ) 08/27/2015
>>> [ 7612.095574]    da37fc70 c12ce7c5  da37fca0
>>> c104cc59 c19d4454
>>> [ 7612.095584]  0003 116c c19d4784 0096 c10508a8 c10508a8
>>> 0200 c1b42400
>>> [ 7612.095594]  f29be780 da37fcb0 c104ccad 0009  da37fcbc
>>> c10508a8 f21f08b8
>>> [ 7612.095604] Call Trace:
>>> [ 7612.095614]  [] dump_stack+0x41/0x5c
>>> [ 7612.095620]  [] warn_slowpath_common+0x89/0xc0
>>> [ 7612.095628]  [] ? __local_bh_enable_ip+0x58/0x80
>>> [ 7612.095634]  [] ? __local_bh_enable_ip+0x58/0x80
>>> [ 7612.095640]  [] warn_slowpath_null+0x1d/0x20
>>> [ 7612.095646]  [] __local_bh_enable_ip+0x58/0x80
>>> [ 7612.095653]  [] destroy_conntrack+0x64/0xa0
>>> [ 7612.095660]  [] nf_conntrack_destroy+0xf/0x20
>>> [ 7612.095665]  [] skb_release_head_state+0x55/0xa0
>>> [ 7612.095670]  [] skb_release_all+0xb/0x20
>>> [ 7612.095674]  [] __kfree_skb+0xb/0x60
>>> [ 7612.095679]  [] kfree_skb+0x30/0x70
>>> [ 7612.095686]  [] ? rtl_pci_reset_trx_ring+0x22d/0x370
>>> [rtl_pci]
>>> [ 7612.095692]  [] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
>>> [ 7612.095698]  [] rtl_pci_start+0x19/0x190 [rtl_pci]
>>> [ 7612.095705]  [] rtl_op_start+0x56/0x90 [rtlwifi]
>>> [ 7612.095712]  [] drv_start+0x36/0xc0
>>> [ 7612.095717]  [] ieee80211_do_open+0x2d3/0x890
>>> [ 7612.095725]  [] ? call_netdevice_notifiers_info+0x2e/0x60
>>> [ 7612.095730]  [] ieee80211_open+0x4d/0x50
>>> [ 7612.095736]  [] __dev_open+0xa3/0x130
>>> [ 7612.095742]  [] ? _raw_spin_unlock_bh+0x13/0x20
>>> [ 7612.095748]  [] __dev_change_flags+0x89/0x140
>>> [ 7612.095753]  [] ? selinux_capable+0xd/0x10
>>> [ 7612.095759]  [] dev_change_flags+0x29/0x60
>>> [ 7612.095765]  [] devinet_ioctl+0x553/0x670
>>> [ 7612.095772]  [] ? _copy_to_user+0x28/0x40
>>> [ 7612.095777]  [] inet_ioctl+0x85/0xb0
>>> [ 7612.095783]  [] sock_ioctl+0x67/0x260
>>> [ 7612.095788]  [] ? sock_fasync+0x80/0x80
>>> [ 7612.095795]  [] do_vfs_ioctl+0x6b/0x550
>>> [ 7612.095800]  [] ? selinux_file_ioctl+0x102/0x1e0
>>> [ 7612.095807]  [] ? timekeeping_suspend+0x294/0x320
>>> [ 7612.095813]  [] ? __hrtimer_run_queues+0x14a/0x210
>>> [ 7612.095820]  [] ? security_file_ioctl+0x34/0x50
>>> [ 7612.095827]  [] SyS_ioctl+0x70/0x80
>>> [ 7612.095832]  [] do_fast_syscall_32+0x84/0x120
>>> [ 7612.095839]  [] sysenter_past_esp+0x36/0x55
>>> [ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---
>>>
>>> Signed-off-by: Wang YanQing 
>>> Cc: Stable 
>>> ---
>>>   Changes:
>>>   v1-v2:
>>>   1: add a Cc to stable.
>>>
>>>   drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c
>>> b/drivers/net/wireless/realtek/rtlwifi/pci.c
>>> index 1ac41b8..99a3a03 100644
>>> --- a/drivers/net/wireless/realtek/rtlwifi/pci.c
>>> +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
>>> @@ -1572,7 +1572,7 @@ int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw)
>>>   true,
>>>
>>> HW_DESC_TXBUFF_ADDR),
>>>   skb->len,
>>> PCI_DMA_TODEVICE);
>>> -   kfree_skb(skb);
>>> +   dev_kfree_skb_irq(skb);
>>>  ring->idx = (ring->idx + 1) %
>>> ring->entries;
>>>  }
>>>  ring->idx = 0;
>>
>>
>> Is this always called in IRQ context?  You might be better off using
>> dev_kfree_skb_any instead if this is something that can be called from
>> net_device_ops since that way you avoid having to call into the Tx
>> softirq cleanup routine to free the buffers later unless you really
>> need it.
>>
>> - Alex
>>
>
> Alex,
>
> Six lines below the change is a spin_unlock_irqrestore(), which is always
> called. I believe that the patch is correct.

Okay.  That works then.

Thanks.

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

Re: [PATCH v2] rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring

2016-05-06 Thread Larry Finger 

On 05/06/2016 12:13 PM, Alexander Duyck wrote:

On Fri, May 6, 2016 at 9:33 AM, Wang YanQing  wrote:

We can't use kfree_skb in irq disable context, because spin_lock_irqsave
make sure we are always in irq disable context, use dev_kfree_skb_irq
instead of kfree_skb is better than dev_kfree_skb_any.

This patch fix below kernel warning:
[ 7612.095528] [ cut here ]
[ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 
__local_bh_enable_ip+0x58/0x80()
[ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist 
rtl_pci rtlwifi rtl8723_common
[ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: GW   4.4.0+ 
#4
[ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 
) 08/27/2015
[ 7612.095574]    da37fc70 c12ce7c5  da37fca0 c104cc59 
c19d4454
[ 7612.095584]  0003 116c c19d4784 0096 c10508a8 c10508a8 0200 
c1b42400
[ 7612.095594]  f29be780 da37fcb0 c104ccad 0009  da37fcbc c10508a8 
f21f08b8
[ 7612.095604] Call Trace:
[ 7612.095614]  [] dump_stack+0x41/0x5c
[ 7612.095620]  [] warn_slowpath_common+0x89/0xc0
[ 7612.095628]  [] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095634]  [] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095640]  [] warn_slowpath_null+0x1d/0x20
[ 7612.095646]  [] __local_bh_enable_ip+0x58/0x80
[ 7612.095653]  [] destroy_conntrack+0x64/0xa0
[ 7612.095660]  [] nf_conntrack_destroy+0xf/0x20
[ 7612.095665]  [] skb_release_head_state+0x55/0xa0
[ 7612.095670]  [] skb_release_all+0xb/0x20
[ 7612.095674]  [] __kfree_skb+0xb/0x60
[ 7612.095679]  [] kfree_skb+0x30/0x70
[ 7612.095686]  [] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095692]  [] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095698]  [] rtl_pci_start+0x19/0x190 [rtl_pci]
[ 7612.095705]  [] rtl_op_start+0x56/0x90 [rtlwifi]
[ 7612.095712]  [] drv_start+0x36/0xc0
[ 7612.095717]  [] ieee80211_do_open+0x2d3/0x890
[ 7612.095725]  [] ? call_netdevice_notifiers_info+0x2e/0x60
[ 7612.095730]  [] ieee80211_open+0x4d/0x50
[ 7612.095736]  [] __dev_open+0xa3/0x130
[ 7612.095742]  [] ? _raw_spin_unlock_bh+0x13/0x20
[ 7612.095748]  [] __dev_change_flags+0x89/0x140
[ 7612.095753]  [] ? selinux_capable+0xd/0x10
[ 7612.095759]  [] dev_change_flags+0x29/0x60
[ 7612.095765]  [] devinet_ioctl+0x553/0x670
[ 7612.095772]  [] ? _copy_to_user+0x28/0x40
[ 7612.095777]  [] inet_ioctl+0x85/0xb0
[ 7612.095783]  [] sock_ioctl+0x67/0x260
[ 7612.095788]  [] ? sock_fasync+0x80/0x80
[ 7612.095795]  [] do_vfs_ioctl+0x6b/0x550
[ 7612.095800]  [] ? selinux_file_ioctl+0x102/0x1e0
[ 7612.095807]  [] ? timekeeping_suspend+0x294/0x320
[ 7612.095813]  [] ? __hrtimer_run_queues+0x14a/0x210
[ 7612.095820]  [] ? security_file_ioctl+0x34/0x50
[ 7612.095827]  [] SyS_ioctl+0x70/0x80
[ 7612.095832]  [] do_fast_syscall_32+0x84/0x120
[ 7612.095839]  [] sysenter_past_esp+0x36/0x55
[ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---

Signed-off-by: Wang YanQing 
Cc: Stable 
---
  Changes:
  v1-v2:
  1: add a Cc to stable.

  drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 1ac41b8..99a3a03 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1572,7 +1572,7 @@ int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw)
  true,
  HW_DESC_TXBUFF_ADDR),
  skb->len, PCI_DMA_TODEVICE);
-   kfree_skb(skb);
+   dev_kfree_skb_irq(skb);
 ring->idx = (ring->idx + 1) % ring->entries;
 }
 ring->idx = 0;


Is this always called in IRQ context?  You might be better off using
dev_kfree_skb_any instead if this is something that can be called from
net_device_ops since that way you avoid having to call into the Tx
softirq cleanup routine to free the buffers later unless you really
need it.

- Alex



Alex,

Six lines below the change is a spin_unlock_irqrestore(), which is always 
called. I believe that the patch is correct.


Larry

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

Limiting bit rate on BCM43438

2016-05-06 Thread Tom Harada 

Hi,

On a Raspberry Pi 3 running Raspbian, I'm finding it impossible to 
maintain a stable WiFi connection with 802.11n access points using the 
internal BCM43438 chip. The association is lost quite frequently (as 
often as twice a minute) and often fails to be recovered. I've tried the 
usual fixes recommended by the RPi forum (disabling power management, 
setting the regulatory domain, updating the kernel) without success. 
However, the problem seems to be less severe with 802.11g access points. 
Is there a way to limit the BCM43438's bit rate and force it to connect 
as a "g" device? iw/iwconfig don't allow this, returning "Operation not 
supported." I'm willing to modify the kernel/drivers if that's what it 
takes. Of course, other suggestions are appreciated as well.


Thanks in advance.

--
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] rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring

2016-05-06 Thread Alexander Duyck 
On Fri, May 6, 2016 at 9:33 AM, Wang YanQing  wrote:
> We can't use kfree_skb in irq disable context, because spin_lock_irqsave
> make sure we are always in irq disable context, use dev_kfree_skb_irq
> instead of kfree_skb is better than dev_kfree_skb_any.
>
> This patch fix below kernel warning:
> [ 7612.095528] [ cut here ]
> [ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 
> __local_bh_enable_ip+0x58/0x80()
> [ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist 
> rtl_pci rtlwifi rtl8723_common
> [ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: GW   
> 4.4.0+ #4
> [ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW 
> (1.19 ) 08/27/2015
> [ 7612.095574]    da37fc70 c12ce7c5  da37fca0 
> c104cc59 c19d4454
> [ 7612.095584]  0003 116c c19d4784 0096 c10508a8 c10508a8 
> 0200 c1b42400
> [ 7612.095594]  f29be780 da37fcb0 c104ccad 0009  da37fcbc 
> c10508a8 f21f08b8
> [ 7612.095604] Call Trace:
> [ 7612.095614]  [] dump_stack+0x41/0x5c
> [ 7612.095620]  [] warn_slowpath_common+0x89/0xc0
> [ 7612.095628]  [] ? __local_bh_enable_ip+0x58/0x80
> [ 7612.095634]  [] ? __local_bh_enable_ip+0x58/0x80
> [ 7612.095640]  [] warn_slowpath_null+0x1d/0x20
> [ 7612.095646]  [] __local_bh_enable_ip+0x58/0x80
> [ 7612.095653]  [] destroy_conntrack+0x64/0xa0
> [ 7612.095660]  [] nf_conntrack_destroy+0xf/0x20
> [ 7612.095665]  [] skb_release_head_state+0x55/0xa0
> [ 7612.095670]  [] skb_release_all+0xb/0x20
> [ 7612.095674]  [] __kfree_skb+0xb/0x60
> [ 7612.095679]  [] kfree_skb+0x30/0x70
> [ 7612.095686]  [] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
> [ 7612.095692]  [] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
> [ 7612.095698]  [] rtl_pci_start+0x19/0x190 [rtl_pci]
> [ 7612.095705]  [] rtl_op_start+0x56/0x90 [rtlwifi]
> [ 7612.095712]  [] drv_start+0x36/0xc0
> [ 7612.095717]  [] ieee80211_do_open+0x2d3/0x890
> [ 7612.095725]  [] ? call_netdevice_notifiers_info+0x2e/0x60
> [ 7612.095730]  [] ieee80211_open+0x4d/0x50
> [ 7612.095736]  [] __dev_open+0xa3/0x130
> [ 7612.095742]  [] ? _raw_spin_unlock_bh+0x13/0x20
> [ 7612.095748]  [] __dev_change_flags+0x89/0x140
> [ 7612.095753]  [] ? selinux_capable+0xd/0x10
> [ 7612.095759]  [] dev_change_flags+0x29/0x60
> [ 7612.095765]  [] devinet_ioctl+0x553/0x670
> [ 7612.095772]  [] ? _copy_to_user+0x28/0x40
> [ 7612.095777]  [] inet_ioctl+0x85/0xb0
> [ 7612.095783]  [] sock_ioctl+0x67/0x260
> [ 7612.095788]  [] ? sock_fasync+0x80/0x80
> [ 7612.095795]  [] do_vfs_ioctl+0x6b/0x550
> [ 7612.095800]  [] ? selinux_file_ioctl+0x102/0x1e0
> [ 7612.095807]  [] ? timekeeping_suspend+0x294/0x320
> [ 7612.095813]  [] ? __hrtimer_run_queues+0x14a/0x210
> [ 7612.095820]  [] ? security_file_ioctl+0x34/0x50
> [ 7612.095827]  [] SyS_ioctl+0x70/0x80
> [ 7612.095832]  [] do_fast_syscall_32+0x84/0x120
> [ 7612.095839]  [] sysenter_past_esp+0x36/0x55
> [ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---
>
> Signed-off-by: Wang YanQing 
> Cc: Stable 
> ---
>  Changes:
>  v1-v2:
>  1: add a Cc to stable.
>
>  drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
> b/drivers/net/wireless/realtek/rtlwifi/pci.c
> index 1ac41b8..99a3a03 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/pci.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
> @@ -1572,7 +1572,7 @@ int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw)
>  true,
>  HW_DESC_TXBUFF_ADDR),
>  skb->len, PCI_DMA_TODEVICE);
> -   kfree_skb(skb);
> +   dev_kfree_skb_irq(skb);
> ring->idx = (ring->idx + 1) % ring->entries;
> }
> ring->idx = 0;

Is this always called in IRQ context?  You might be better off using
dev_kfree_skb_any instead if this is something that can be called from
net_device_ops since that way you avoid having to call into the Tx
softirq cleanup routine to free the buffers later unless you really
need it.

- Alex
--
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] rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring

2016-05-06 Thread Larry Finger 

On 05/06/2016 11:33 AM, Wang YanQing wrote:

We can't use kfree_skb in irq disable context, because spin_lock_irqsave
make sure we are always in irq disable context, use dev_kfree_skb_irq
instead of kfree_skb is better than dev_kfree_skb_any.

This patch fix below kernel warning:
[ 7612.095528] [ cut here ]
[ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 
__local_bh_enable_ip+0x58/0x80()
[ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist 
rtl_pci rtlwifi rtl8723_common
[ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: GW   4.4.0+ 
#4
[ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 
) 08/27/2015
[ 7612.095574]    da37fc70 c12ce7c5  da37fca0 c104cc59 
c19d4454
[ 7612.095584]  0003 116c c19d4784 0096 c10508a8 c10508a8 0200 
c1b42400
[ 7612.095594]  f29be780 da37fcb0 c104ccad 0009  da37fcbc c10508a8 
f21f08b8
[ 7612.095604] Call Trace:
[ 7612.095614]  [] dump_stack+0x41/0x5c
[ 7612.095620]  [] warn_slowpath_common+0x89/0xc0
[ 7612.095628]  [] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095634]  [] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095640]  [] warn_slowpath_null+0x1d/0x20
[ 7612.095646]  [] __local_bh_enable_ip+0x58/0x80
[ 7612.095653]  [] destroy_conntrack+0x64/0xa0
[ 7612.095660]  [] nf_conntrack_destroy+0xf/0x20
[ 7612.095665]  [] skb_release_head_state+0x55/0xa0
[ 7612.095670]  [] skb_release_all+0xb/0x20
[ 7612.095674]  [] __kfree_skb+0xb/0x60
[ 7612.095679]  [] kfree_skb+0x30/0x70
[ 7612.095686]  [] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095692]  [] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095698]  [] rtl_pci_start+0x19/0x190 [rtl_pci]
[ 7612.095705]  [] rtl_op_start+0x56/0x90 [rtlwifi]
[ 7612.095712]  [] drv_start+0x36/0xc0
[ 7612.095717]  [] ieee80211_do_open+0x2d3/0x890
[ 7612.095725]  [] ? call_netdevice_notifiers_info+0x2e/0x60
[ 7612.095730]  [] ieee80211_open+0x4d/0x50
[ 7612.095736]  [] __dev_open+0xa3/0x130
[ 7612.095742]  [] ? _raw_spin_unlock_bh+0x13/0x20
[ 7612.095748]  [] __dev_change_flags+0x89/0x140
[ 7612.095753]  [] ? selinux_capable+0xd/0x10
[ 7612.095759]  [] dev_change_flags+0x29/0x60
[ 7612.095765]  [] devinet_ioctl+0x553/0x670
[ 7612.095772]  [] ? _copy_to_user+0x28/0x40
[ 7612.095777]  [] inet_ioctl+0x85/0xb0
[ 7612.095783]  [] sock_ioctl+0x67/0x260
[ 7612.095788]  [] ? sock_fasync+0x80/0x80
[ 7612.095795]  [] do_vfs_ioctl+0x6b/0x550
[ 7612.095800]  [] ? selinux_file_ioctl+0x102/0x1e0
[ 7612.095807]  [] ? timekeeping_suspend+0x294/0x320
[ 7612.095813]  [] ? __hrtimer_run_queues+0x14a/0x210
[ 7612.095820]  [] ? security_file_ioctl+0x34/0x50
[ 7612.095827]  [] SyS_ioctl+0x70/0x80
[ 7612.095832]  [] do_fast_syscall_32+0x84/0x120
[ 7612.095839]  [] sysenter_past_esp+0x36/0x55
[ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---

Signed-off-by: Wang YanQing 
Cc: Stable 
---
  Changes:
  v1-v2:
  1: add a Cc to stable.

  drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 1ac41b8..99a3a03 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1572,7 +1572,7 @@ int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw)
 true,
 HW_DESC_TXBUFF_ADDR),
 skb->len, PCI_DMA_TODEVICE);
-   kfree_skb(skb);
+   dev_kfree_skb_irq(skb);
ring->idx = (ring->idx + 1) % ring->entries;
}
ring->idx = 0;


Acked-by: Larry Finger 

Thanks,

Larry

--
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] rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring

2016-05-06 Thread Wang YanQing 
We can't use kfree_skb in irq disable context, because spin_lock_irqsave
make sure we are always in irq disable context, use dev_kfree_skb_irq
instead of kfree_skb is better than dev_kfree_skb_any.

This patch fix below kernel warning:
[ 7612.095528] [ cut here ]
[ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 
__local_bh_enable_ip+0x58/0x80()
[ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist 
rtl_pci rtlwifi rtl8723_common
[ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: GW   4.4.0+ 
#4
[ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 
) 08/27/2015
[ 7612.095574]    da37fc70 c12ce7c5  da37fca0 c104cc59 
c19d4454
[ 7612.095584]  0003 116c c19d4784 0096 c10508a8 c10508a8 0200 
c1b42400
[ 7612.095594]  f29be780 da37fcb0 c104ccad 0009  da37fcbc c10508a8 
f21f08b8
[ 7612.095604] Call Trace:
[ 7612.095614]  [] dump_stack+0x41/0x5c
[ 7612.095620]  [] warn_slowpath_common+0x89/0xc0
[ 7612.095628]  [] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095634]  [] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095640]  [] warn_slowpath_null+0x1d/0x20
[ 7612.095646]  [] __local_bh_enable_ip+0x58/0x80
[ 7612.095653]  [] destroy_conntrack+0x64/0xa0
[ 7612.095660]  [] nf_conntrack_destroy+0xf/0x20
[ 7612.095665]  [] skb_release_head_state+0x55/0xa0
[ 7612.095670]  [] skb_release_all+0xb/0x20
[ 7612.095674]  [] __kfree_skb+0xb/0x60
[ 7612.095679]  [] kfree_skb+0x30/0x70
[ 7612.095686]  [] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095692]  [] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095698]  [] rtl_pci_start+0x19/0x190 [rtl_pci]
[ 7612.095705]  [] rtl_op_start+0x56/0x90 [rtlwifi]
[ 7612.095712]  [] drv_start+0x36/0xc0
[ 7612.095717]  [] ieee80211_do_open+0x2d3/0x890
[ 7612.095725]  [] ? call_netdevice_notifiers_info+0x2e/0x60
[ 7612.095730]  [] ieee80211_open+0x4d/0x50
[ 7612.095736]  [] __dev_open+0xa3/0x130
[ 7612.095742]  [] ? _raw_spin_unlock_bh+0x13/0x20
[ 7612.095748]  [] __dev_change_flags+0x89/0x140
[ 7612.095753]  [] ? selinux_capable+0xd/0x10
[ 7612.095759]  [] dev_change_flags+0x29/0x60
[ 7612.095765]  [] devinet_ioctl+0x553/0x670
[ 7612.095772]  [] ? _copy_to_user+0x28/0x40
[ 7612.095777]  [] inet_ioctl+0x85/0xb0
[ 7612.095783]  [] sock_ioctl+0x67/0x260
[ 7612.095788]  [] ? sock_fasync+0x80/0x80
[ 7612.095795]  [] do_vfs_ioctl+0x6b/0x550
[ 7612.095800]  [] ? selinux_file_ioctl+0x102/0x1e0
[ 7612.095807]  [] ? timekeeping_suspend+0x294/0x320
[ 7612.095813]  [] ? __hrtimer_run_queues+0x14a/0x210
[ 7612.095820]  [] ? security_file_ioctl+0x34/0x50
[ 7612.095827]  [] SyS_ioctl+0x70/0x80
[ 7612.095832]  [] do_fast_syscall_32+0x84/0x120
[ 7612.095839]  [] sysenter_past_esp+0x36/0x55
[ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---

Signed-off-by: Wang YanQing 
Cc: Stable 
---
 Changes:
 v1-v2:
 1: add a Cc to stable.

 drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 1ac41b8..99a3a03 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1572,7 +1572,7 @@ int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw)
 true,
 HW_DESC_TXBUFF_ADDR),
 skb->len, PCI_DMA_TODEVICE);
-   kfree_skb(skb);
+   dev_kfree_skb_irq(skb);
ring->idx = (ring->idx + 1) % ring->entries;
}
ring->idx = 0;
-- 
1.8.5.6.2.g3d8a54e.dirty
--
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] Fix kernel oops in failed chip_attach

2016-05-06 Thread Kalle Valo 
Christian Daudt  writes:

> On Fri, May 6, 2016 at 4:53 AM, Kalle Valo  wrote:
>> Christian Daudt  writes:
>>
>>> When chip attach fails, brcmf_sdiod_intr_unregister is being called
>>> but that is too early as sdiodev->settings has not been set yet
>>> nor has brcmf_sdiod_intr_register been called.
>>> Change to use oob_irq_requested + newly created sd_irq_requested
>>> to decide on what to unregister at intr_unregister time.
>>>
>>> Steps to reproduce problem:
>>> - modprobe brcmfmac using buggy FW
>>> - rmmod brcmfmac
>>> - modprobe brcmfmac again.
>>>
>>> If done with a buggy firmware, brcm_chip_attach will fail on the
>>> 2nd modprobe triggering the call to intr_unregister and the
>>> kernel oops when attempting to de-reference sdiodev->settings->bus.sdio
>>> which has not yet been set.
>>>
>>> Signed-off-by: Christian Daudt 
>>
>> Please use prefix "brcmfmac: " in the title.
>>
> I'll resubmit with that mod after getting round 1 feedback. I was a
> bit rusty on patch submissions and forgot about that part on the first
> one.

No worries, that's why we do review :)

-- 
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] Fix kernel oops in failed chip_attach

2016-05-06 Thread Christian Daudt 
On Fri, May 6, 2016 at 4:53 AM, Kalle Valo  wrote:
> Christian Daudt  writes:
>
>> When chip attach fails, brcmf_sdiod_intr_unregister is being called
>> but that is too early as sdiodev->settings has not been set yet
>> nor has brcmf_sdiod_intr_register been called.
>> Change to use oob_irq_requested + newly created sd_irq_requested
>> to decide on what to unregister at intr_unregister time.
>>
>> Steps to reproduce problem:
>> - modprobe brcmfmac using buggy FW
>> - rmmod brcmfmac
>> - modprobe brcmfmac again.
>>
>> If done with a buggy firmware, brcm_chip_attach will fail on the
>> 2nd modprobe triggering the call to intr_unregister and the
>> kernel oops when attempting to de-reference sdiodev->settings->bus.sdio
>> which has not yet been set.
>>
>> Signed-off-by: Christian Daudt 
>
> Please use prefix "brcmfmac: " in the title.
>
I'll resubmit with that mod after getting round 1 feedback. I was a
bit rusty on patch submissions and forgot about that part on the first
one.
 Thanks,
   csd
--
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] rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring

2016-05-06 Thread Larry Finger 

On 05/05/2016 12:19 PM, Wang YanQing wrote:

We can't use kfree_skb in irq disable context, because spin_lock_irqsave
make sure we are always in irq disable context, use dev_kfree_skb_irq
instead of kfree_skb is better than dev_kfree_skb_any.

This patch fix below kernel warning:
[ 7612.095528] [ cut here ]
[ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 
__local_bh_enable_ip+0x58/0x80()
[ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist 
rtl_pci rtlwifi rtl8723_common
[ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: GW   4.4.0+ 
#4
[ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 
) 08/27/2015
[ 7612.095574]    da37fc70 c12ce7c5  da37fca0 c104cc59 
c19d4454
[ 7612.095584]  0003 116c c19d4784 0096 c10508a8 c10508a8 0200 
c1b42400
[ 7612.095594]  f29be780 da37fcb0 c104ccad 0009  da37fcbc c10508a8 
f21f08b8
[ 7612.095604] Call Trace:
[ 7612.095614]  [] dump_stack+0x41/0x5c
[ 7612.095620]  [] warn_slowpath_common+0x89/0xc0
[ 7612.095628]  [] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095634]  [] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095640]  [] warn_slowpath_null+0x1d/0x20
[ 7612.095646]  [] __local_bh_enable_ip+0x58/0x80
[ 7612.095653]  [] destroy_conntrack+0x64/0xa0
[ 7612.095660]  [] nf_conntrack_destroy+0xf/0x20
[ 7612.095665]  [] skb_release_head_state+0x55/0xa0
[ 7612.095670]  [] skb_release_all+0xb/0x20
[ 7612.095674]  [] __kfree_skb+0xb/0x60
[ 7612.095679]  [] kfree_skb+0x30/0x70
[ 7612.095686]  [] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095692]  [] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095698]  [] rtl_pci_start+0x19/0x190 [rtl_pci]
[ 7612.095705]  [] rtl_op_start+0x56/0x90 [rtlwifi]
[ 7612.095712]  [] drv_start+0x36/0xc0
[ 7612.095717]  [] ieee80211_do_open+0x2d3/0x890
[ 7612.095725]  [] ? call_netdevice_notifiers_info+0x2e/0x60
[ 7612.095730]  [] ieee80211_open+0x4d/0x50
[ 7612.095736]  [] __dev_open+0xa3/0x130
[ 7612.095742]  [] ? _raw_spin_unlock_bh+0x13/0x20
[ 7612.095748]  [] __dev_change_flags+0x89/0x140
[ 7612.095753]  [] ? selinux_capable+0xd/0x10
[ 7612.095759]  [] dev_change_flags+0x29/0x60
[ 7612.095765]  [] devinet_ioctl+0x553/0x670
[ 7612.095772]  [] ? _copy_to_user+0x28/0x40
[ 7612.095777]  [] inet_ioctl+0x85/0xb0
[ 7612.095783]  [] sock_ioctl+0x67/0x260
[ 7612.095788]  [] ? sock_fasync+0x80/0x80
[ 7612.095795]  [] do_vfs_ioctl+0x6b/0x550
[ 7612.095800]  [] ? selinux_file_ioctl+0x102/0x1e0
[ 7612.095807]  [] ? timekeeping_suspend+0x294/0x320
[ 7612.095813]  [] ? __hrtimer_run_queues+0x14a/0x210
[ 7612.095820]  [] ? security_file_ioctl+0x34/0x50
[ 7612.095827]  [] SyS_ioctl+0x70/0x80
[ 7612.095832]  [] do_fast_syscall_32+0x84/0x120
[ 7612.095839]  [] sysenter_past_esp+0x36/0x55
[ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---

Signed-off-by: Wang YanQing 
---
  drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 1ac41b8..99a3a03 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1572,7 +1572,7 @@ int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw)
 true,
 HW_DESC_TXBUFF_ADDR),
 skb->len, PCI_DMA_TODEVICE);
-   kfree_skb(skb);
+   dev_kfree_skb_irq(skb);
ring->idx = (ring->idx + 1) % ring->entries;
}
ring->idx = 0;


After testing, this patch is OK other than needing a Cc to stable. Please fix 
that and resubmit V2.


Larry


--
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] Fix regression in Android due to rework .get_station() callback

2016-05-06 Thread Kalle Valo 
Jaap Jan Meijer  writes:

> 2016-05-06 16:12 GMT+01:00 Kalle Valo :
>> Jaap Jan Meijer  writes:
>>
>>> Hi Kalle,
>>>
>>> Op vr 6 mei 2016 12:52 schreef Kalle Valo :
>>>
>>>
>>> This has multiple issues:
>>>
>>> o Use your full name.
>>> o Use prefix "brcmfmac: " in the title.
>>>
>>> o I can't find commit f654d13, is the commit id really correct?
>>> o Also check from SubmittingPatches how you should reference commit ids.
>>>
>>>
>>>
>>> Thank you for the feedback, I will send a reworked patch as soon as I get 
>>> home
>>> next week. Also I did this against v4.4.8 so I'll have to rebase it as well.
>>>
>>> I'm not sure what went wrong with the commit hash, its actually this commit:
>>> 1f0dc59a6de93586fcfc04696a61946408ffc56a.
>>
>> That commit id looks to be valid.
>>
>>> I see you did this commit, maybe you can check if this actually is the root
>>> cause? I'm sure you have a lot more insight into this issue than I do.

I just commited the patch. Broadcom folks (CCed) should be able to
answer better, most likely they missed this patch as the title didn't
have "brcmfmac".

-- 
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] Fix regression in Android due to rework .get_station() callback

2016-05-06 Thread Jaap Jan Meijer 
2016-05-06 16:12 GMT+01:00 Kalle Valo :
> Jaap Jan Meijer  writes:
>
>> Hi Kalle,
>>
>> Op vr 6 mei 2016 12:52 schreef Kalle Valo :
>>
>>
>> This has multiple issues:
>>
>> o Use your full name.
>> o Use prefix "brcmfmac: " in the title.
>>
>> o I can't find commit f654d13, is the commit id really correct?
>> o Also check from SubmittingPatches how you should reference commit ids.
>>
>>
>>
>> Thank you for the feedback, I will send a reworked patch as soon as I get 
>> home
>> next week. Also I did this against v4.4.8 so I'll have to rebase it as well.
>>
>> I'm not sure what went wrong with the commit hash, its actually this commit:
>> 1f0dc59a6de93586fcfc04696a61946408ffc56a.
>
> That commit id looks to be valid.
>
>> I see you did this commit, maybe you can check if this actually is the root
>> cause? I'm sure you have a lot more insight into this issue than I do.
>
> Please CC the list so that everyone can join the discussion.
>
> --
> Kalle Valo

Sorry, I shouldn't do this on a mobile device.
--
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 2/2] ath10k: Fix survey reporting with QCA4019

2016-05-06 Thread Vasanthakumar Thiagarajan 
In QCA4019, cycle counter wraparound in same fashion
as QCA988X. When the cycle counter wraparound it
resets to 0x7fff. Set has_shifted_cc_wraparound to
true for QCA4019 to enable the code path to handle cycle
counter wraparound for consistent survey report.

Signed-off-by: Vasanthakumar Thiagarajan 
---
 drivers/net/wireless/ath/ath10k/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index e94cb87..f6018be 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -202,6 +202,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.name = "qca4019 hw1.0",
.patch_load_addr = QCA4019_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
+   .has_shifted_cc_wraparound = true,
.otp_exe_param = 0x001,
.continuous_frag_desc = true,
.channel_counters_freq_hz = 125000,
-- 
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

[PATCH 1/2] ath10k: suppress warnings when getting wmi peer_rate_code_list event

2016-05-06 Thread Vasanthakumar Thiagarajan 
In 10.4, fw sends WMI PEER_RATECODE_LIST_EVENTID after successful
peer_assoc cmd. As of now this event is not of much use and not
implemented. Change the debug level and messsage as appropriate
to suppress "Unknown eventid: 36898".

Signed-off-by: Vasanthakumar Thiagarajan 
---
 drivers/net/wireless/ath/ath10k/wmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 39a54a5..2a14b16 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5213,6 +5213,7 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, 
struct sk_buff *skb)
ath10k_wmi_event_vdev_stopped(ar, skb);
break;
case WMI_10_4_WOW_WAKEUP_HOST_EVENTID:
+   case WMI_10_4_PEER_RATECODE_LIST_EVENTID:
ath10k_dbg(ar, ATH10K_DBG_WMI,
   "received event id %d not implemented\n", id);
break;
-- 
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] Fix kernel oops in failed chip_attach

2016-05-06 Thread Kalle Valo 
Christian Daudt  writes:

> When chip attach fails, brcmf_sdiod_intr_unregister is being called
> but that is too early as sdiodev->settings has not been set yet
> nor has brcmf_sdiod_intr_register been called.
> Change to use oob_irq_requested + newly created sd_irq_requested
> to decide on what to unregister at intr_unregister time.
>
> Steps to reproduce problem:
> - modprobe brcmfmac using buggy FW
> - rmmod brcmfmac
> - modprobe brcmfmac again.
>
> If done with a buggy firmware, brcm_chip_attach will fail on the
> 2nd modprobe triggering the call to intr_unregister and the
> kernel oops when attempting to de-reference sdiodev->settings->bus.sdio
> which has not yet been set.
>
> Signed-off-by: Christian Daudt 

Please use prefix "brcmfmac: " in the title.

-- 
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] Fix regression in Android due to rework .get_station() callback

2016-05-06 Thread Kalle Valo 
meijjaa  writes:

> After f654d13 Android is not able to get station signal strength.
> To much was removed, this patch brings back the needed functionality.
>
> Signed-off-by: meijjaa 

This has multiple issues:

o Use your full name.

o Use prefix "brcmfmac: " in the title.

o I can't find commit f654d13, is the commit id really correct?

o Also check from SubmittingPatches how you should reference commit ids.

-- 
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: pull request: iwlwifi 2016-05-04

2016-05-06 Thread Kalle Valo 
"Grumbach, Emmanuel"  writes:

> I know it is extremely late in the cycle, but this patch is intended
> for 4.6... It fixes a regression I introduced: a P2P specification
> violation as mentioned in the commit message.
> The patch is rather big in terms of number of lines changed, but the
> semantics is very simple. I have to copy the control block of the skb
> to the stack whereas we accessed we used to access it directly through
> a pointer.
> This obviously introduces a lot of line changes, but don't really
> change the behavior of the code (since most of the accesses are read
> only).
>
> Let me know how it goes.

[...]

> The following changes since commit f742aaf36edf0390c54d0614bc4d20fd4cd3762a:
>
>   iwlwifi: mvm: fix accessing Null pointer during fw dump collection 
> (2016-04-12 11:52:39 +0300)
>
> 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-05-04

Pulled, thanks. Let's see if this makes it to 4.6.

> I take this opportunity to inform you that I will be replaced by Luca
> for a few months at least. I will be working full steam on a side
> project that will not allow me to do the maintainer job in parallel.

Ok, have fun in your new project.

Luca, as we _finally_ got sun here in Finland we have to have a "kick
off meeting about the new organisation structure" by your grill ;)

-- 
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: Planned Support for BCM 43162 [14e4:43ae] rev 02 ?

2016-05-06 Thread Jan Sobotka 
>>You may try:
>>sudo su
>>rmmod bcma
>>echo "14e4 43ae" > /sys/bus/pci/drivers/brcmfmac/new_id
>>dmesg | grep brcmfmac

Output:
[14054.947644] usbcore: registered new interface driver brcmfmac

Full command history:
root@chobot-lenovo-laptop:~# lsmod | grep bcma
root@chobot-lenovo-laptop:~# rmmod bcma
rmmod: ERROR: Module bcma is not currently loaded
root@chobot-lenovo-laptop:~# echo "14e4 43ae" > 
/sys/bus/pci/drivers/brcmfmac/new_id
-bash: /sys/bus/pci/drivers/brcmfmac/new_id: No such file or directory
root@chobot-lenovo-laptop:~# modprobe brcmfmac
root@chobot-lenovo-laptop:~# lsmod | grep brcmfmac
brcmfmac  290816  0
brcmutil   16384  1 brcmfmac
cfg80211  565248  2 brcmfmac,mac80211
root@chobot-lenovo-laptop:~# echo "14e4 43ae" > 
/sys/bus/pci/drivers/brcmfmac/new_id
root@chobot-lenovo-laptop:~# dmesg | grep brcmfmac
[14054.947644] usbcore: registered new interface driver brcmfmac


-- Původní zpráva --
Od: Rafał Miłecki 
Komu: Jan Sobotka , brcm80211 development 
Datum: 6. 5. 2016 2:03:08
Předmět: Re: Planned Support for BCM 43162 [14e4:43ae] rev 02 ?

On 5 May 2016 at 18:22, Jan Sobotka  wrote:
> Great, now it works. Output:
>
> root@chobot-lenovo-laptop:/home/chobot# echo "14e4 43ae" > 
> /sys/bus/pci/drivers/bcma-pci-bridge/new_id
> root@chobot-lenovo-laptop:/home/chobot# dmesg | egrep "bcma|b43"
> [ 5295.114902] bcma: bus0: Found chip with id 0x4335, rev 0x02 and package 
> 0x01
> [ 5295.114950] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, 
> rev 0x2E, class 0x0)
> [ 5295.114974] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, 
> rev 0x2E, class 0x0)
> [ 5295.115026] bcma: bus0: Core 2 found: ARM CR4 (manuf 0x4BF, id 0x83E, rev 
> 0x04, class 0x0)
> [ 5295.115073] bcma: bus0: Core 3 found: PCIe Gen2 (manuf 0x4BF, id 0x83C, 
> rev 0x04, class 0x0)
> [ 5295.115096] bcma: bus0: Core 4 found: USB 2.0 Device (manuf 0x4BF, id 
> 0x81A, rev 0x14, class 0x0)
> [ 5295.115119] bcma: bus0: Core 5 found: SDIO Device (manuf 0x4BF, id 0x829, 
> rev 0x15, class 0x0)
> [ 5295.115170] bcma: bus0: Bridge found
> [ 5295.115221] bcma-pci-bridge: probe of :02:00.0 failed with error -84

So this is device with BCM4335 chipset which is a FullMAC one AFAIK.
It may be supported by brcmfmac. There is already support for BCM4335
in brcmfmac but it was developed for SDIO devices only. I don't think
we ever met BCM4335 on PCIe device.

However I think brcmfmac may need some extra changes to support
BCM4335 on PCIe. Lets also see if Broadcom team can help us with this.--
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: Realtek RTL8723BE wireless card drops connection

2016-05-06 Thread Hin-Tak Leung 
The MAINTAINERS file did mention that the appropriate mailing list to use is
the linux-wireless one. Using an appropriate list is preferable to e-mailing 
individuals. Added in the TO:.

That card uses the rtlwifi module, so that seems to be Larry's and Chaoming's 
to look at.


On Fri, 6/5/16, Federico Leva  wrote:
 
 Hello,
 I see in 
 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS

 
 that you maintain some RTL8* wireless driver. Sorry for the
 direct 
 emaill, but did you see the report 
 https://marc.info/?l=linux-wireless=143420832618489=2
 and is 
 anything else needed?
 
 There are hundreds of bug reports about this card on
 launchpad alone 
 (apparently it's shipped by HP, Lenovo and others with many
 laptops), 
 but the bug is still present: I've verified it in Fedora 23
 and Ubuntu 
 16.04 (Linux 4.4.0-21) and others found it in Linux 4.5.
 
 Example bug reports with useful information in launchpad for
 Ubuntu:
 * https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1459367
 * https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1461174
 * https://bugs.launchpad.net/hwe-next/+bug/1461174
 
 Thanks,
     Federico
--
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/nl80211: add wifi tx power mode switching support

2016-05-06 Thread Wei-Ning Huang 
On Fri, May 6, 2016 at 12:07 AM, Dan Williams  wrote:
>
> On Thu, 2016-05-05 at 14:44 +0800, Wei-Ning Huang wrote:
> > Recent new hardware has the ability to switch between tablet mode and
> > clamshell mode. To optimize WiFi performance, we want to be able to
> > use
> > different power table between modes. This patch adds a new netlink
> > message type and cfg80211_ops function to allow userspace to trigger
> > a
> > power mode switch for a given wireless interface.
> >
> > Signed-off-by: Wei-Ning Huang 
> > ---
> >  include/net/cfg80211.h   | 11 +++
> >  include/uapi/linux/nl80211.h | 21 +
> >  net/wireless/nl80211.c   | 16 
> >  net/wireless/rdev-ops.h  | 22 ++
> >  net/wireless/trace.h | 20 
> >  5 files changed, 90 insertions(+)
> >
> > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> > index 9e1b24c..aa77fa0 100644
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -2370,6 +2370,12 @@ struct cfg80211_qos_map {
> >   * @get_tx_power: store the current TX power into the dbm variable;
> >   *   return 0 if successful
> >   *
> > + * @set_tx_power_mode: set the transmit power mode. Some device have
> > the ability
> > + *   to transform between different mode such as clamshell and
> > tablet mode.
> > + *   set_tx_power_mode allows setting of different TX power
> > mode at runtime.
> > + * @get_tx_power_mode: store the current TX power mode into the mode
> > variable;
> > + *   return 0 if successful
> > + *
> >   * @set_wds_peer: set the WDS peer for a WDS interface
> >   *
> >   * @rfkill_poll: polls the hw rfkill line, use cfg80211 reporting
> > @@ -2631,6 +2637,11 @@ struct cfg80211_ops {
> >   int (*get_tx_power)(struct wiphy *wiphy, struct
> > wireless_dev *wdev,
> >   int *dbm);
> >
> > + int (*set_tx_power_mode)(struct wiphy *wiphy,
> > +  enum nl80211_tx_power_mode
> > mode);
> > + int (*get_tx_power_mode)(struct wiphy *wiphy,
> > +  enum nl80211_tx_power_mode
> > *mode);
> > +
> >   int (*set_wds_peer)(struct wiphy *wiphy, struct
> > net_device *dev,
> >   const u8 *addr);
> >
> > diff --git a/include/uapi/linux/nl80211.h
> > b/include/uapi/linux/nl80211.h
> > index 5a30a75..9b1888a 100644
> > --- a/include/uapi/linux/nl80211.h
> > +++ b/include/uapi/linux/nl80211.h
> > @@ -1796,6 +1796,9 @@ enum nl80211_commands {
> >   *   connecting to a PCP, and in %NL80211_CMD_START_AP to start
> >   *   a PCP instead of AP. Relevant for DMG networks only.
> >   *
> > + * @NL80211_ATTR_WIPHY_TX_POWER_MODE: Transmit power mode. See
> > + *   nl80211_tx_power_mode for possible values.
> > + *
> >   * @NUM_NL80211_ATTR: total number of nl80211_attrs available
> >   * @NL80211_ATTR_MAX: highest attribute number currently defined
> >   * @__NL80211_ATTR_AFTER_LAST: internal use
> > @@ -2172,6 +2175,8 @@ enum nl80211_attrs {
> >
> >   NL80211_ATTR_PBSS,
> >
> > + NL80211_ATTR_WIPHY_TX_POWER_MODE,
> > +
> >   /* add attributes here, update the policy in nl80211.c */
> >
> >   __NL80211_ATTR_AFTER_LAST,
> > @@ -3703,6 +3708,22 @@ enum nl80211_tx_power_setting {
> >  };
> >
> >  /**
> > + * enum nl80211_tx_power_mode - TX power mode setting
> > + * @NL80211_TX_POWER_LOW: general low TX power mode
> > + * @NL80211_TX_POWER_MEDIUM: general medium TX power mode
> > + * @NL80211_TX_POWER_HIGH: general high TX power mode
> > + * @NL80211_TX_POWER_CLAMSHELL: clamshell mode TX power mode
> > + * @NL80211_TX_POWER_TABLET: tablet mode TX power mode
> > + */
> > +enum nl80211_tx_power_mode {
> > + NL80211_TX_POWER_LOW,
> > + NL80211_TX_POWER_MEDIUM,
> > + NL80211_TX_POWER_HIGH,
> > + NL80211_TX_POWER_CLAMSHELL,
> > + NL80211_TX_POWER_TABLET,
>

> "clamshell" and "tablet" probably mean many different things to many
> different people with respect to whether or not they should do anything
> with power saving or wifi.  I feel like a more generic interface is
> needed here.
We could probably drop those two CLAMSHELL and TABLET constant or
describing what they mean
in more detail?

>
> Could this be already done by:
> @NL80211_ATTR_WIPHY_TX_POWER_SETTING = NL80211_TX_POWER_LIMITED
> @NL80211_ATTR_WIPHY_TX_POWER_LEVEL = 
>
> and then the device would be able to change its TX power as it saw fit
> up to that limit set by your application which figures out whether it's
> in clamshell or tablet mode?

We usually want different power settings in different band/channel.
For example, we can have three different power settings
in 2.4Ghz, channels 36-64 & channels 100+ on 5Ghz. In this case, we
can not simply set a fixed number to the power level.
A power table is required to map channel/band to actual power limit.
For most of the driver, changing power table requires

Re: [PATCHv4 5/5] mac80211: add debug knobs for codel

2016-05-06 Thread Dave Taht 
On Thu, May 5, 2016 at 11:33 PM, Michal Kazior  wrote:
> On 6 May 2016 at 07:51, Dave Taht  wrote:
>> On Thu, May 5, 2016 at 10:27 PM, Michal Kazior  
>> wrote:
>>> On 5 May 2016 at 17:21, Dave Taht  wrote:
 On Thu, May 5, 2016 at 4:00 AM, Michal Kazior  
 wrote:
> This adds a few debugfs entries to make it easier
> to test, debug and experiment.

 I might argue in favor of moving all these (inc the fq ones) into
 their own dir, maybe "aqm" or "sqm".

 The mixture of read only stats and configuration vars is a bit confusing.

 Also in my testing of the previous patch, actually seeing the stats
 get updated seemed to be highly async or inaccurate. For example, it
 was obvious from the captures themselves that codel_ce_mark-ing was
 happening, but the actual numbers out of wack with the mark seen or
 fq_backlog seen.  (I can go back to revisit this)
>>>
>>> That's kind of expected since all of these bits are exposed as
>>> separate debugfs entries/files. To avoid that it'd be necessary to
>>> provide a single debugfs entry/file whose contents are generated on
>>> open() while holding local->fq.lock. But then you could argue it
>>> should contain all per-sta-tid info as well (backlog, flows, drops) as
>>> well instead of having them in netdev*/stations/*/txqs.
>>> Hmm..
>>
>> I have not had time to write up todays results to any full extent, but
>> they were pretty spectacular.
>>
>> I have a comparison of the baseline ath10k driver vs your 3.5 patchset
>> here on the second plot:
>>
>> http://blog.cerowrt.org/post/predictive_codeling/
>>
>> The raw data is here:
>> https://github.com/dtaht/blog-cerowrt/tree/master/content/flent/qca-10.2-fqmac35-codel-5
>
> It's probably good to explicitly mention that you test(ed) ath10k with
> my RFC DQL patch applied. Without it the fqcodel benefits are a lot
> less significant.

Yes. I am trying to establish a baseline before and after, starting at
the max rate my ath9k (2x2) can take the ath10k (2x2) at a distance of
about 12 feet. Without moving anything.

https://github.com/dtaht/blog-cerowrt/tree/master/content/flent/stock-4.4.1-22
has the baseline stats from that ubuntu 16.04 kernel...
 but the comparison plots I'd generated there were against the ct-10.1
firmware and before I'd realized you'd used the smaller quantum. Life
is *even* better with using the bigger quantum in the
qca-10.2-fqmac35-codel-5 patchset.

>
> (oh, and the "3.5" is pre-PATCHv4 before fq/codel split work:
> https://github.com/kazikcz/linux/tree/fqmac-v3.5 )

I have insufficient time in life to track any but the most advanced
patchset, and I am catching up as fast as I can. First up was finding
the max ath9k performance, (5x reduction in latency, no reduction in
throughput at about 110mbit).

Then I'll try locking the bitrate at say 24mbit for another run. You
already showed the latency reduction at 6mbit at about 100x to 1, so I
don't plan to repeat that.

then I'll get another ath10k 3x3 up and wash, rinse, repeat.

I would not mind if your patch 4.1 had good stats generation (maybe
put all the relevant stats in a single file?) and defaulted to quantum
1514, since it seems likely I'll not get done this first test run
before monday.

Additional test suggestions wanted? I plan to add the tcp_square_wave
tests to the next run to show how much better the congestion control
is, and I'll add iperf3 floods too.

I am not sure how avery is planning to test each individual piece.

>
>>
>> ...
>>
>> a note: quantum of the mtu (typically 1514) is a saner default than 300,
>>
>> (the older patch I had, set it to 300, dunno what your default is now).
>
> I still use 300.
>
>
>> and quantum 1514, codel target 5ms rather than 20ms for this test
>> series was *just fine* (but more testing of the lower target is
>> needed)
>
> I would keep 20ms for now until we get more test data. I'm mostly
> concerned about MU performance on ath10k which requires significant
> amount of buffering.

ok.

>
>> However:
>>
>> quantum "300" only makes sense for very, very low bandwidths (say <
>> 6mbits), in other scenarios it just eats extra cpu (5 passes through
>> the loop to send a big packet) and disables
>> the "new/old" queue feature which helps "push" new flows to flow
>> balance. I'd default it to the larger value.
>
> Perhaps this could be dynamically adjusted to match the slowest
> station known to rate control in the future?

Meh. We've done a lot of fiddling with the quantum to not much avail.
300 was a good number at really low rates. The rest of the time, the
larger number is vastly easier on cpu AND on flow balance.

https://dev.openwrt.org/ticket/21326

> Oh, and there's
> multicast..

Multicast is it's own queue in the per-station queueing model.

>
>
> Michał



-- 
Dave Täht
Let's go make home routers and wifi faster! With better

Re: [PATCHv4 5/5] mac80211: add debug knobs for codel

2016-05-06 Thread Michal Kazior 
On 6 May 2016 at 07:51, Dave Taht  wrote:
> On Thu, May 5, 2016 at 10:27 PM, Michal Kazior  
> wrote:
>> On 5 May 2016 at 17:21, Dave Taht  wrote:
>>> On Thu, May 5, 2016 at 4:00 AM, Michal Kazior  
>>> wrote:
 This adds a few debugfs entries to make it easier
 to test, debug and experiment.
>>>
>>> I might argue in favor of moving all these (inc the fq ones) into
>>> their own dir, maybe "aqm" or "sqm".
>>>
>>> The mixture of read only stats and configuration vars is a bit confusing.
>>>
>>> Also in my testing of the previous patch, actually seeing the stats
>>> get updated seemed to be highly async or inaccurate. For example, it
>>> was obvious from the captures themselves that codel_ce_mark-ing was
>>> happening, but the actual numbers out of wack with the mark seen or
>>> fq_backlog seen.  (I can go back to revisit this)
>>
>> That's kind of expected since all of these bits are exposed as
>> separate debugfs entries/files. To avoid that it'd be necessary to
>> provide a single debugfs entry/file whose contents are generated on
>> open() while holding local->fq.lock. But then you could argue it
>> should contain all per-sta-tid info as well (backlog, flows, drops) as
>> well instead of having them in netdev*/stations/*/txqs.
>> Hmm..
>
> I have not had time to write up todays results to any full extent, but
> they were pretty spectacular.
>
> I have a comparison of the baseline ath10k driver vs your 3.5 patchset
> here on the second plot:
>
> http://blog.cerowrt.org/post/predictive_codeling/
>
> The raw data is here:
> https://github.com/dtaht/blog-cerowrt/tree/master/content/flent/qca-10.2-fqmac35-codel-5

It's probably good to explicitly mention that you test(ed) ath10k with
my RFC DQL patch applied. Without it the fqcodel benefits are a lot
less significant.

(oh, and the "3.5" is pre-PATCHv4 before fq/codel split work:
https://github.com/kazikcz/linux/tree/fqmac-v3.5 )


>
> ...
>
> a note: quantum of the mtu (typically 1514) is a saner default than 300,
>
> (the older patch I had, set it to 300, dunno what your default is now).

I still use 300.


> and quantum 1514, codel target 5ms rather than 20ms for this test
> series was *just fine* (but more testing of the lower target is
> needed)

I would keep 20ms for now until we get more test data. I'm mostly
concerned about MU performance on ath10k which requires significant
amount of buffering.


> However:
>
> quantum "300" only makes sense for very, very low bandwidths (say <
> 6mbits), in other scenarios it just eats extra cpu (5 passes through
> the loop to send a big packet) and disables
> the "new/old" queue feature which helps "push" new flows to flow
> balance. I'd default it to the larger value.

Perhaps this could be dynamically adjusted to match the slowest
station known to rate control in the future? Oh, and there's
multicast..


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