Re: 8712U driver for CentOS 6.6

2015-08-20 Thread Larry Finger

On 08/20/2015 10:40 PM, Lee Maou Sheng wrote:

Hi sir,

I am from Singapore and currently our company is trying to install Prolink
WN2001 wireless adapter into Dell PowerEdge T20 with Centos 6.6 installed. I
am using https://github.com/chunkeey/rtl8192su for the driver.

The information I have as below:

uname -a
Linux ts41 2.6.32-573.3.1.el6.x86_64 #1 SMP Thu Aug 13 22:55:16 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux

lsusb
Bus 001 Device 003: ID 07b8:8179 AboCom Systems Inc

make
[root@ts41 rtl8192su]# make
make -C /lib/modules/2.6.32-573.3.1.el6.x86_64/build
M=/var/tmp/rtl8192su/rtlwifi CONFIG_RTL_CARDS=y CONFIG_RTLWIFI=m
CONFIG_RTLWIFI_DEBUG=y CONFIG_RTLWIFI_DEBUGFS=y CONFIG_RTLWIFI_USB=m
CONFIG_RTLWIFI_PCI=m CONFIG_RTL8192SU=m CONFIG_RTL8192SE=m
CONFIG_RTL8192S_COMMON=m CONFIG_RTL8192CU=n CONFIG_RTL8192DE=n
CONFIG_RTL8192CE=n CONFIG_RTL8192C_COMMON=n CONFIG_RTL8723AE=n
CONFIG_RTL8188EE=n  EXTRA_CFLAGS="-DDEBUG -DCONFIG_RTLWIFI_DEBUGFS=m"
make[1]: Entering directory `/usr/src/kernels/2.6.32-573.3.1.el6.x86_64'
   CC [M]  /var/tmp/rtl8192su/rtlwifi/usb.o
/var/tmp/rtl8192su/rtlwifi/usb.c: In function '_rtl_prep_rx_urb':
/var/tmp/rtl8192su/rtlwifi/usb.c:437: error: implicit declaration of
function 'usb_alloc_coherent'
/var/tmp/rtl8192su/rtlwifi/usb.c:438: warning: assignment makes pointer from
integer without a cast
/var/tmp/rtl8192su/rtlwifi/usb.c: In function '_rtl_usb_cleanup_rx':
/var/tmp/rtl8192su/rtlwifi/usb.c:688: error: implicit declaration of
function 'usb_free_coherent'
make[2]: *** [/var/tmp/rtl8192su/rtlwifi/usb.o] Error 1
make[1]: *** [_module_/var/tmp/rtl8192su/rtlwifi] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.32-573.3.1.el6.x86_64'
make: *** [all] Error 2


That device is not an RTL8192SU. It is an RTL8188EU, which has a driver at 
http://github.com/lwfinger/rtl8188eu.git; however, that version probably will 
not build on a kernel as old as 2.6.32. I try to allow a build for kernels as 
old as 3.0, but yours is quite a bit older.


Is there any reason that you cannot upgrade to a newer kernel? The driver you 
need was added to the kernel in 3.19.


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: mac80211: When adding a new station, notify driver before adding to hash

2015-08-20 Thread Michal Kazior
On 20 August 2015 at 23:39, Marty Faltesek  wrote:
> We are seeing reports of the following panic with ath10k, running
> backports 3.19-rc1 code:
>
> [196113.641] [ cut here ]
> [196113.641] kernel BUG at kernel/workqueue.c:1040!
> [196113.641] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
> [196113.656] Modules linked in: ctr ccm nf_conntrack_netlink
> auto_bridge(O) fci(O) nfnetlink pktgen ath9k_htc(O) mwifiex_usb(O)
> mwifiex(O) ath10k_pci(O) ath10k_core(O) arc4 ath9k(O) mac80211(O)
> ath9k_common(O) ath9k_hw(O) ath(O) cfg80211(O) compat(O) bmoc
> a(O) xt_connmark ip6table_mangle xt_CLASSIFY iptable_mangle xt_helper
> ip6t_REJECT ip6t_LOG nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter
> ip6_tables nf_nat_rtsp nf_conntrack_rtsp nf_nat_h323 nf_conntrack_h323
> nf_nat_irc nf_conntrack_irc nf_nat_pptp nf_c
> onntrack_pptp nf_conntrack_proto_gre nf_nat_proto_gre nf_nat_sip
> nf_conntrack_sip nf_nat_tftp nf_conntrack_tftp nf_nat_ftp
> nf_conntrack_ftp ipt_MASQUERADE ipt_REJECT ipt_LOG xt_limit xt_pkttype
> xt_conntrack xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 n
> f_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables pfe(O)
> [196113.734] CPU: 0Tainted: G   O  (3.2.26 #1)
> [196113.734] PC is at __queue_work+0x20e/0x310
> [196113.750] LR is at __queue_work+0x1c7/0x310
> [196113.750] pc : [<840383ea>]lr : [<840383a3>]psr: 000101b3
> [196113.750] sp : b8cd5730  ip :   fp : 00010113
> [196113.766] r10: 89de13cc  r9 : 8446b6e4  r8 : 84472e40
> [196113.766] r7 :   r6 : bc797a00  r5 : bc79bd20  r4 : 89de1424
> [196113.766] r3 : 89de1428  r2 :   r1 : bc79bd20  r0 : bc797a00
> [196113.781] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA Thumb
> Segment user
> [196113.781] Control: 50c53c7d  Table: 3577404a  DAC: 0015
> [196113.797] Process hostapd (pid: 3817, stack limit = 0xb8cd42f0)
> [196113.797] Stack: (0xb8cd5730 to 0xb8cd6000)
> ...
> [196114.391] [<840383ea>] (__queue_work+0x20e/0x310) from [<84038509>]
> (queue_work_on+0x1d/0x24)
> [196114.406] [<84038509>] (queue_work_on+0x1d/0x24) from [<8403852d>]
> (queue_work+0x1d/0x34)
> [196114.406] [<8403852d>] (queue_work+0x1d/0x34) from [<83883a05>]
> (ieee80211_queue_work+0x14/0x18 [mac80211])
> [196114.422] [<83883a05>] (ieee80211_queue_work+0x14/0x18 [mac80211])
> from [<838fa15f>] (ath10k_sta_rc_update+0xbe/0x1b4 [ath10k_core])
> [196114.438] [<838fa15f>] (ath10k_sta_rc_update+0xbe/0x1b4
> [ath10k_core]) from [<8387ddd3>]
> (ieee80211_sta_ps_transition+0x1456/0x25a4 [mac80211])
> [196114.438] [<8387ddd3>] (ieee80211_sta_ps_transition+0x1456/0x25a4
> [mac80211]) from [<8387ee81>]
> (ieee80211_sta_ps_transition+0x2504/0x25a4 [mac80211])
> [196114.453] [<8387ee81>] (ieee80211_sta_ps_transition+0x2504/0x25a4
> [mac80211]) from [<8387f407>] (ieee80211_rx+0x4e6/0x580 [mac80211])
> [196114.469] [<8387f407>] (ieee80211_rx+0x4e6/0x580 [mac80211]) from
> [<8390659f>] (ath10k_wmi_htc_tx_complete+0xf72/0x160c [ath10k_core])
> [196114.484] [<8390659f>] (ath10k_wmi_htc_tx_complete+0xf72/0x160c
> [ath10k_core]) from [<83908f29>] (ath10k_wmi_process_rx+0x3e0/0x5c0
> [ath10k_core])
> [196114.500] [<83908f29>] (ath10k_wmi_process_rx+0x3e0/0x5c0
> [ath10k_core]) from [<8390261f>]
> (ath10k_htc_rx_completion_handler+0x2be/0x304 [ath10k_core])
> [196114.516] [<8390261f>]
> (ath10k_htc_rx_completion_handler+0x2be/0x304 [ath10k_core]) from
> [<83920f51>] (ath10k_pci_ce_recv_data+0x120/0x190 [ath10k_pci])
> [196114.516] FW:IN=wan0.2 OUT=br0
> MAC=
> SRC=
> DST= LEN=60 TC=0 HOPLIMIT=52
> FLOWLBL=0 PROTO=TCP SPT=5228 DPT=61497 WINDOW=0 RES=0x00 RST URGP=0
> [196114.547] [<83920f51>] (ath10k_pci_ce_recv_data+0x120/0x190
> [ath10k_pci]) from [<8392257b>]
> (ath10k_ce_per_engine_service+0x4a/0x74 [ath10k_pci])
> [196114.562] [<8392257b>] (ath10k_ce_per_engine_service+0x4a/0x74
> [ath10k_pci]) from [<839225d1>]
> (ath10k_ce_per_engine_service_any+0x2c/0x48 [ath10k_pci])
> [196114.578] [<839225d1>] (ath10k_ce_per_engine_service_any+0x2c/0x48
> [ath10k_pci]) from [<8392209f>] (ath10k_pci_tasklet+0x26/0x40
> [ath10k_pci])
> [196114.578] [<8392209f>] (ath10k_pci_tasklet+0x26/0x40 [ath10k_pci])
> from [<8402b96f>] (tasklet_action+0x6f/0x104)
> [196114.594] [<8402b96f>] (tasklet_action+0x6f/0x104) from
> [<8402bc9d>] (__do_softirq+0xc5/0x190)
> [196114.594] [<8402bc9d>] (__do_softirq+0xc5/0x190) from [<8402c067>]
> (irq_exit+0x37/0x6c)
> [196114.609] [<8402c067>] (irq_exit+0x37/0x6c) from [<8400d3d7>]
> (handle_IRQ+0xdf/0xf4)
> [196114.609] [<8400d3d7>] (handle_IRQ+0xdf/0xf4) from [<8400c553>]
> (__irq_svc+0x33/0xb8)
> [196114.625] [<8400c553>] (__irq_svc+0x33/0xb8) from [<838695a4>]
> (sta_info_recalc_tim+0x573/0x9a4 [mac80211])
> [196114.641] [<838695a4>] (sta_info_recalc_tim+0x573/0x9a4 [mac80211])
> from [<83869a4d>] (sta_info_insert_rcu+0x78/0x84 [mac80211])
> [196114.641] [<83869a4d>] (sta_info_insert_rcu+0x78/0x84 [mac80211])
> from [<8387afe5>] (ieee80211_add_station+0x184/0x1e8 [mac80

8712U driver for CentOS 6.6

2015-08-20 Thread Lee Maou Sheng
Hi sir,

I am from Singapore and currently our company is trying to install Prolink
WN2001 wireless adapter into Dell PowerEdge T20 with Centos 6.6 installed. I
am using https://github.com/chunkeey/rtl8192su for the driver.

The information I have as below:

uname -a
Linux ts41 2.6.32-573.3.1.el6.x86_64 #1 SMP Thu Aug 13 22:55:16 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux

lsusb
Bus 001 Device 003: ID 07b8:8179 AboCom Systems Inc

make
[root@ts41 rtl8192su]# make
make -C /lib/modules/2.6.32-573.3.1.el6.x86_64/build
M=/var/tmp/rtl8192su/rtlwifi CONFIG_RTL_CARDS=y CONFIG_RTLWIFI=m
CONFIG_RTLWIFI_DEBUG=y CONFIG_RTLWIFI_DEBUGFS=y CONFIG_RTLWIFI_USB=m
CONFIG_RTLWIFI_PCI=m CONFIG_RTL8192SU=m CONFIG_RTL8192SE=m
CONFIG_RTL8192S_COMMON=m CONFIG_RTL8192CU=n CONFIG_RTL8192DE=n
CONFIG_RTL8192CE=n CONFIG_RTL8192C_COMMON=n CONFIG_RTL8723AE=n
CONFIG_RTL8188EE=n  EXTRA_CFLAGS="-DDEBUG -DCONFIG_RTLWIFI_DEBUGFS=m"
make[1]: Entering directory `/usr/src/kernels/2.6.32-573.3.1.el6.x86_64'
  CC [M]  /var/tmp/rtl8192su/rtlwifi/usb.o
/var/tmp/rtl8192su/rtlwifi/usb.c: In function '_rtl_prep_rx_urb':
/var/tmp/rtl8192su/rtlwifi/usb.c:437: error: implicit declaration of
function 'usb_alloc_coherent'
/var/tmp/rtl8192su/rtlwifi/usb.c:438: warning: assignment makes pointer from
integer without a cast
/var/tmp/rtl8192su/rtlwifi/usb.c: In function '_rtl_usb_cleanup_rx':
/var/tmp/rtl8192su/rtlwifi/usb.c:688: error: implicit declaration of
function 'usb_free_coherent'
make[2]: *** [/var/tmp/rtl8192su/rtlwifi/usb.o] Error 1
make[1]: *** [_module_/var/tmp/rtl8192su/rtlwifi] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.32-573.3.1.el6.x86_64'
make: *** [all] Error 2


Wish I can get some guidance from you.

Thank you!

Best Regards,

Lee Maou Sheng
Software Engineer
Archer Logic (S) Pte. Ltd.

6 Ubi Road 1, Wintech Centre
#05-01, Singapore 408726
Tel: (65) 6785 9007 ext. 109

--
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 00/18] Export SPI and OF module aliases in missing drivers

2015-08-20 Thread Javier Martinez Canillas
Hello Brian,

On 08/20/2015 11:11 PM, Brian Norris wrote:
> On Thu, Aug 20, 2015 at 09:07:13AM +0200, Javier Martinez Canillas wrote:
>> Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches
> 
> ^^^ I'm dying to know how this sentence ends :)
>

Sigh, I did some last minute restructuring of the cover letter and
seems I missed a sentence. I meant to said:

"and patches #9 to #17 solves c)."
 
>> Patch #18 changes the logic of spi_uevent() to report an OF modalias if
>> the device was registered using OF. But this patch is included in the
>> series only as an RFC for illustration purposes since changing that
>> without first applying all the other patches in this series, will break
>> module autoloading for the drivers of devices registered using OF but
>> that lacks an of_match_table. I'll repost patch #18 once all the patches
>> in this series have landed.
> 
> On a more productive note, the patches I've looked at look good to me.
> The missing aliases are a problem enough that should be fixed (i.e.,
> part (b)). I'll leave the SPI framework changes to others to comment on.
>

Great, thanks a lot for your feedback.
 
> Brian
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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


mac80211: When adding a new station, notify driver before adding to hash

2015-08-20 Thread Marty Faltesek
We are seeing reports of the following panic with ath10k, running
backports 3.19-rc1 code:

[196113.641] [ cut here ]
[196113.641] kernel BUG at kernel/workqueue.c:1040!
[196113.641] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
[196113.656] Modules linked in: ctr ccm nf_conntrack_netlink
auto_bridge(O) fci(O) nfnetlink pktgen ath9k_htc(O) mwifiex_usb(O)
mwifiex(O) ath10k_pci(O) ath10k_core(O) arc4 ath9k(O) mac80211(O)
ath9k_common(O) ath9k_hw(O) ath(O) cfg80211(O) compat(O) bmoc
a(O) xt_connmark ip6table_mangle xt_CLASSIFY iptable_mangle xt_helper
ip6t_REJECT ip6t_LOG nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter
ip6_tables nf_nat_rtsp nf_conntrack_rtsp nf_nat_h323 nf_conntrack_h323
nf_nat_irc nf_conntrack_irc nf_nat_pptp nf_c
onntrack_pptp nf_conntrack_proto_gre nf_nat_proto_gre nf_nat_sip
nf_conntrack_sip nf_nat_tftp nf_conntrack_tftp nf_nat_ftp
nf_conntrack_ftp ipt_MASQUERADE ipt_REJECT ipt_LOG xt_limit xt_pkttype
xt_conntrack xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 n
f_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables pfe(O)
[196113.734] CPU: 0Tainted: G   O  (3.2.26 #1)
[196113.734] PC is at __queue_work+0x20e/0x310
[196113.750] LR is at __queue_work+0x1c7/0x310
[196113.750] pc : [<840383ea>]lr : [<840383a3>]psr: 000101b3
[196113.750] sp : b8cd5730  ip :   fp : 00010113
[196113.766] r10: 89de13cc  r9 : 8446b6e4  r8 : 84472e40
[196113.766] r7 :   r6 : bc797a00  r5 : bc79bd20  r4 : 89de1424
[196113.766] r3 : 89de1428  r2 :   r1 : bc79bd20  r0 : bc797a00
[196113.781] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA Thumb
Segment user
[196113.781] Control: 50c53c7d  Table: 3577404a  DAC: 0015
[196113.797] Process hostapd (pid: 3817, stack limit = 0xb8cd42f0)
[196113.797] Stack: (0xb8cd5730 to 0xb8cd6000)
...
[196114.391] [<840383ea>] (__queue_work+0x20e/0x310) from [<84038509>]
(queue_work_on+0x1d/0x24)
[196114.406] [<84038509>] (queue_work_on+0x1d/0x24) from [<8403852d>]
(queue_work+0x1d/0x34)
[196114.406] [<8403852d>] (queue_work+0x1d/0x34) from [<83883a05>]
(ieee80211_queue_work+0x14/0x18 [mac80211])
[196114.422] [<83883a05>] (ieee80211_queue_work+0x14/0x18 [mac80211])
from [<838fa15f>] (ath10k_sta_rc_update+0xbe/0x1b4 [ath10k_core])
[196114.438] [<838fa15f>] (ath10k_sta_rc_update+0xbe/0x1b4
[ath10k_core]) from [<8387ddd3>]
(ieee80211_sta_ps_transition+0x1456/0x25a4 [mac80211])
[196114.438] [<8387ddd3>] (ieee80211_sta_ps_transition+0x1456/0x25a4
[mac80211]) from [<8387ee81>]
(ieee80211_sta_ps_transition+0x2504/0x25a4 [mac80211])
[196114.453] [<8387ee81>] (ieee80211_sta_ps_transition+0x2504/0x25a4
[mac80211]) from [<8387f407>] (ieee80211_rx+0x4e6/0x580 [mac80211])
[196114.469] [<8387f407>] (ieee80211_rx+0x4e6/0x580 [mac80211]) from
[<8390659f>] (ath10k_wmi_htc_tx_complete+0xf72/0x160c [ath10k_core])
[196114.484] [<8390659f>] (ath10k_wmi_htc_tx_complete+0xf72/0x160c
[ath10k_core]) from [<83908f29>] (ath10k_wmi_process_rx+0x3e0/0x5c0
[ath10k_core])
[196114.500] [<83908f29>] (ath10k_wmi_process_rx+0x3e0/0x5c0
[ath10k_core]) from [<8390261f>]
(ath10k_htc_rx_completion_handler+0x2be/0x304 [ath10k_core])
[196114.516] [<8390261f>]
(ath10k_htc_rx_completion_handler+0x2be/0x304 [ath10k_core]) from
[<83920f51>] (ath10k_pci_ce_recv_data+0x120/0x190 [ath10k_pci])
[196114.516] FW:IN=wan0.2 OUT=br0
MAC=
SRC=
DST= LEN=60 TC=0 HOPLIMIT=52
FLOWLBL=0 PROTO=TCP SPT=5228 DPT=61497 WINDOW=0 RES=0x00 RST URGP=0
[196114.547] [<83920f51>] (ath10k_pci_ce_recv_data+0x120/0x190
[ath10k_pci]) from [<8392257b>]
(ath10k_ce_per_engine_service+0x4a/0x74 [ath10k_pci])
[196114.562] [<8392257b>] (ath10k_ce_per_engine_service+0x4a/0x74
[ath10k_pci]) from [<839225d1>]
(ath10k_ce_per_engine_service_any+0x2c/0x48 [ath10k_pci])
[196114.578] [<839225d1>] (ath10k_ce_per_engine_service_any+0x2c/0x48
[ath10k_pci]) from [<8392209f>] (ath10k_pci_tasklet+0x26/0x40
[ath10k_pci])
[196114.578] [<8392209f>] (ath10k_pci_tasklet+0x26/0x40 [ath10k_pci])
from [<8402b96f>] (tasklet_action+0x6f/0x104)
[196114.594] [<8402b96f>] (tasklet_action+0x6f/0x104) from
[<8402bc9d>] (__do_softirq+0xc5/0x190)
[196114.594] [<8402bc9d>] (__do_softirq+0xc5/0x190) from [<8402c067>]
(irq_exit+0x37/0x6c)
[196114.609] [<8402c067>] (irq_exit+0x37/0x6c) from [<8400d3d7>]
(handle_IRQ+0xdf/0xf4)
[196114.609] [<8400d3d7>] (handle_IRQ+0xdf/0xf4) from [<8400c553>]
(__irq_svc+0x33/0xb8)
[196114.625] [<8400c553>] (__irq_svc+0x33/0xb8) from [<838695a4>]
(sta_info_recalc_tim+0x573/0x9a4 [mac80211])
[196114.641] [<838695a4>] (sta_info_recalc_tim+0x573/0x9a4 [mac80211])
from [<83869a4d>] (sta_info_insert_rcu+0x78/0x84 [mac80211])
[196114.641] [<83869a4d>] (sta_info_insert_rcu+0x78/0x84 [mac80211])
from [<8387afe5>] (ieee80211_add_station+0x184/0x1e8 [mac80211])
[196114.656] [<8387afe5>] (ieee80211_add_station+0x184/0x1e8
[mac80211]) from [<837a4721>] (nl80211_new_station+0x214/0x2d8
[cfg80211])
[196114.672] [<837a4721>] (nl80211_new_station+0x214/0x2d8 [cfg80211])
from [<842436a1>]

Re: [PATCH V3 0/6] brcmfmac: nvram loading and code rework

2015-08-20 Thread Rafał Miłecki
On 20 August 2015 at 23:23, Arend van Spriel  wrote:
> On 08/20/2015 11:20 PM, Rafał Miłecki wrote:
>>
>> On 20 August 2015 at 22:06, Arend van Spriel  wrote:
>>>
>>> This series comprises of following changes:
>>> - support NVRAM loading for bcm47xx platform.
>>> - revise announced interface combinations and validate against it.
>>> - new debugfs entry for msgbuf protocol layer used with PCIe devices.
>>> - PCIe fix for handling queue overflow.
>>> - support more firmware events (for bcm4339 firmware).
>>>
>>> The series is intended for v4.3 kernel and applies to the master branch
>>> of the wireless-drivers-next repository. Removed patch from this series
>>> that reportedly has issue on OpenWrt platform.
>>
>>
>> Tested-by: Rafał Miłecki 
>>
>> No regression with this version, getting platform NVRAM works.
>
>
> Thanks, Rafał

Thanks for your work! :)


> Kalle,
>
> Will you add the "Tested-by:" or should I?

If you won't, I won't mind. I know patchwork still doesn't like my name ;)


One note: this patchset should be applied after:
[PATCH] brcmfmac: check all combinations when setting wiphy's addresses
Otherwise /sys/class/ieee80211/phy0/addresses may start reporting only
2 MACs (despite BCM43602 hardware & firmware supporting 4 AP
interfaces).

-- 
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 V3 0/6] brcmfmac: nvram loading and code rework

2015-08-20 Thread Arend van Spriel

On 08/20/2015 11:20 PM, Rafał Miłecki wrote:

On 20 August 2015 at 22:06, Arend van Spriel  wrote:

This series comprises of following changes:
- support NVRAM loading for bcm47xx platform.
- revise announced interface combinations and validate against it.
- new debugfs entry for msgbuf protocol layer used with PCIe devices.
- PCIe fix for handling queue overflow.
- support more firmware events (for bcm4339 firmware).

The series is intended for v4.3 kernel and applies to the master branch
of the wireless-drivers-next repository. Removed patch from this series
that reportedly has issue on OpenWrt platform.


Tested-by: Rafał Miłecki 

No regression with this version, getting platform NVRAM works.


Thanks, Rafał

Kalle,

Will you add the "Tested-by:" or should I?

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 V3 0/6] brcmfmac: nvram loading and code rework

2015-08-20 Thread Rafał Miłecki
On 20 August 2015 at 22:06, Arend van Spriel  wrote:
> This series comprises of following changes:
> - support NVRAM loading for bcm47xx platform.
> - revise announced interface combinations and validate against it.
> - new debugfs entry for msgbuf protocol layer used with PCIe devices.
> - PCIe fix for handling queue overflow.
> - support more firmware events (for bcm4339 firmware).
>
> The series is intended for v4.3 kernel and applies to the master branch
> of the wireless-drivers-next repository. Removed patch from this series
> that reportedly has issue on OpenWrt platform.

Tested-by: Rafał Miłecki 

No regression with this version, getting platform NVRAM works.
--
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: wireless-drivers-next 2015-08-19

2015-08-20 Thread David Miller
From: Kalle Valo 
Date: Wed, 19 Aug 2015 14:03:56 +0300

> here's one more pull request for 4.3. More info in the signed tag below.
> 
> This time I had to merge mac80211-next.git due to some iwlwifi
> dependencies and apparently that broke git-request-pull's diffstat
> again, it was showing changes which were not really coming from my tree.
> I think that's just a bug in my old git and really should update the
> tool. This time I just fixed the diffstat manually.
> 
> But please be extra careful with this pull request and please let me
> know if you have any problems.
> 
> The following changes since commit 8f9c98df949333f08b74e5df1caacf7e2c5e8552:
> 
>   mac80211: fix BIT position for TDLS WIDE extended cap (2015-08-14 17:49:53 
> +0200)
> 
> are available in the git repository at:
> 
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
> tags/wireless-drivers-next-for-davem-2015-08-19

Pulled, thanks.  I'll double check what I got to make sure it isn't
unexpected.
--
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 00/18] Export SPI and OF module aliases in missing drivers

2015-08-20 Thread Brian Norris
On Thu, Aug 20, 2015 at 09:07:13AM +0200, Javier Martinez Canillas wrote:
> Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches

^^^ I'm dying to know how this sentence ends :)

> Patch #18 changes the logic of spi_uevent() to report an OF modalias if
> the device was registered using OF. But this patch is included in the
> series only as an RFC for illustration purposes since changing that
> without first applying all the other patches in this series, will break
> module autoloading for the drivers of devices registered using OF but
> that lacks an of_match_table. I'll repost patch #18 once all the patches
> in this series have landed.

On a more productive note, the patches I've looked at look good to me.
The missing aliases are a problem enough that should be fixed (i.e.,
part (b)). I'll leave the SPI framework changes to others to comment on.

Brian
--
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/4] average: convert users to inline implementation

2015-08-20 Thread David Miller
From: Johannes Berg 
Date: Wed, 19 Aug 2015 09:46:18 +0200

> Since there's very little benefit of the out-of-line implementation
> (a single byte of .text in one driver as far as I've seen), convert
> all drivers to the inline implementation, saving memory, and remove
> the out-of-line implementation.
> 
> Perhaps the easiest would be for Dave to take all of these patches?

Ok, I'll applied this series to net-next, thanks.
--
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 V3 2/6] brcmfmac: add debugfs entry for msgbuf statistics

2015-08-20 Thread Arend van Spriel
From: Franky Lin 

Expose ring buffer read/write pointers and other useful statistics
through debugfs.

Reviewed-by: Arend Van Spriel 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c | 56 
 1 file changed, 56 insertions(+)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c 
b/drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c
index 898c380..7b2136c 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c
@@ -1360,6 +1360,60 @@ void brcmf_msgbuf_delete_flowring(struct brcmf_pub 
*drvr, u8 flowid)
}
 }
 
+#ifdef DEBUG
+static int brcmf_msgbuf_stats_read(struct seq_file *seq, void *data)
+{
+   struct brcmf_bus *bus_if = dev_get_drvdata(seq->private);
+   struct brcmf_pub *drvr = bus_if->drvr;
+   struct brcmf_msgbuf *msgbuf = (struct brcmf_msgbuf *)drvr->proto->pd;
+   struct brcmf_commonring *commonring;
+   u16 i;
+   struct brcmf_flowring_ring *ring;
+   struct brcmf_flowring_hash *hash;
+
+   commonring = msgbuf->commonrings[BRCMF_H2D_MSGRING_CONTROL_SUBMIT];
+   seq_printf(seq, "h2d_ctl_submit: rp %4u, wp %4u, depth %4u\n",
+  commonring->r_ptr, commonring->w_ptr, commonring->depth);
+   commonring = msgbuf->commonrings[BRCMF_H2D_MSGRING_RXPOST_SUBMIT];
+   seq_printf(seq, "h2d_rx_submit:  rp %4u, wp %4u, depth %4u\n",
+  commonring->r_ptr, commonring->w_ptr, commonring->depth);
+   commonring = msgbuf->commonrings[BRCMF_D2H_MSGRING_CONTROL_COMPLETE];
+   seq_printf(seq, "d2h_ctl_cmplt:  rp %4u, wp %4u, depth %4u\n",
+  commonring->r_ptr, commonring->w_ptr, commonring->depth);
+   commonring = msgbuf->commonrings[BRCMF_D2H_MSGRING_TX_COMPLETE];
+   seq_printf(seq, "d2h_tx_cmplt:   rp %4u, wp %4u, depth %4u\n",
+  commonring->r_ptr, commonring->w_ptr, commonring->depth);
+   commonring = msgbuf->commonrings[BRCMF_D2H_MSGRING_RX_COMPLETE];
+   seq_printf(seq, "d2h_rx_cmplt:   rp %4u, wp %4u, depth %4u\n",
+  commonring->r_ptr, commonring->w_ptr, commonring->depth);
+
+   seq_printf(seq, "\nh2d_flowrings: depth %u\n",
+  BRCMF_H2D_TXFLOWRING_MAX_ITEM);
+   seq_puts(seq, "Active flowrings:\n");
+   hash = msgbuf->flow->hash;
+   for (i = 0; i < msgbuf->flow->nrofrings; i++) {
+   if (!msgbuf->flow->rings[i])
+   continue;
+   ring = msgbuf->flow->rings[i];
+   if (ring->status != RING_OPEN)
+   continue;
+   commonring = msgbuf->flowrings[i];
+   hash = &msgbuf->flow->hash[ring->hash_id];
+   seq_printf(seq, "id %3u: rp %4u, wp %4u, qlen %4u, blocked %u\n"
+   "ifidx %u, fifo %u, da %pM\n",
+   i, commonring->r_ptr, commonring->w_ptr,
+   skb_queue_len(&ring->skblist), ring->blocked,
+   hash->ifidx, hash->fifo, hash->mac);
+   }
+
+   return 0;
+}
+#else
+static int brcmf_msgbuf_stats_read(struct seq_file *seq, void *data)
+{
+   return 0;
+}
+#endif
 
 int brcmf_proto_msgbuf_attach(struct brcmf_pub *drvr)
 {
@@ -1460,6 +1514,8 @@ int brcmf_proto_msgbuf_attach(struct brcmf_pub *drvr)
spin_lock_init(&msgbuf->flowring_work_lock);
INIT_LIST_HEAD(&msgbuf->work_queue);
 
+   brcmf_debugfs_add_entry(drvr, "msgbuf_stats", brcmf_msgbuf_stats_read);
+
return 0;
 
 fail:
-- 
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 V3 1/6] brcmfmac: correct interface combination info

2015-08-20 Thread Arend van Spriel
The interface combination provided by brcmfmac did not truly reflect
the combinations supported by driver and/or firmware.

Reviewed-by: Hante Meuleman 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Pontus Fuchs 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 151 +++--
 1 file changed, 112 insertions(+), 39 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
index ffe5260..17cf1bc 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
@@ -5695,63 +5695,132 @@ brcmf_txrx_stypes[NUM_NL80211_IFTYPES] = {
}
 };
 
+/**
+ * brcmf_setup_ifmodes() - determine interface modes and combinations.
+ *
+ * @wiphy: wiphy object.
+ * @ifp: interface object needed for feat module api.
+ *
+ * The interface modes and combinations are determined dynamically here
+ * based on firmware functionality.
+ *
+ * no p2p and no mbss:
+ *
+ * #STA <= 1, #AP <= 1, channels = 1, 2 total
+ *
+ * no p2p and mbss:
+ *
+ * #STA <= 1, #AP <= 1, channels = 1, 2 total
+ * #AP <= 4, matching BI, channels = 1, 4 total
+ *
+ * p2p, no mchan, and mbss:
+ *
+ * #STA <= 1, #P2P-DEV <= 1, #{P2P-CL, P2P-GO} <= 1, channels = 1, 3 total
+ * #STA <= 1, #P2P-DEV <= 1, #AP <= 1, #P2P-CL <= 1, channels = 1, 4 total
+ * #AP <= 4, matching BI, channels = 1, 4 total
+ *
+ * p2p, mchan, and mbss:
+ *
+ * #STA <= 1, #P2P-DEV <= 1, #{P2P-CL, P2P-GO} <= 1, channels = 2, 3 total
+ * #STA <= 1, #P2P-DEV <= 1, #AP <= 1, #P2P-CL <= 1, channels = 1, 4 total
+ * #AP <= 4, matching BI, channels = 1, 4 total
+ */
 static int brcmf_setup_ifmodes(struct wiphy *wiphy, struct brcmf_if *ifp)
 {
struct ieee80211_iface_combination *combo = NULL;
-   struct ieee80211_iface_limit *limits = NULL;
-   int i = 0, max_iface_cnt;
+   struct ieee80211_iface_limit *c0_limits = NULL;
+   struct ieee80211_iface_limit *p2p_limits = NULL;
+   struct ieee80211_iface_limit *mbss_limits = NULL;
+   bool mbss, p2p;
+   int i, c, n_combos;
+
+   mbss = brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS);
+   p2p = brcmf_feat_is_enabled(ifp, BRCMF_FEAT_P2P);
 
-   combo = kzalloc(sizeof(*combo), GFP_KERNEL);
+   n_combos = 1 + !!p2p + !!mbss;
+   combo = kcalloc(n_combos, sizeof(*combo), GFP_KERNEL);
if (!combo)
goto err;
 
-   limits = kzalloc(sizeof(*limits) * 4, GFP_KERNEL);
-   if (!limits)
+   c0_limits = kcalloc(p2p ? 3 : 2, sizeof(*c0_limits), GFP_KERNEL);
+   if (!c0_limits)
goto err;
 
+   if (p2p) {
+   p2p_limits = kcalloc(4, sizeof(*p2p_limits), GFP_KERNEL);
+   if (!p2p_limits)
+   goto err;
+   }
+
+   if (mbss) {
+   mbss_limits = kcalloc(1, sizeof(*mbss_limits), GFP_KERNEL);
+   if (!mbss_limits)
+   goto err;
+   }
+
wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
 BIT(NL80211_IFTYPE_ADHOC) |
 BIT(NL80211_IFTYPE_AP);
 
-   if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MCHAN))
-   combo->num_different_channels = 2;
-   else
-   combo->num_different_channels = 1;
-
-   if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS)) {
-   limits[i].max = 1;
-   limits[i++].types = BIT(NL80211_IFTYPE_STATION);
-   limits[i].max = 4;
-   limits[i++].types = BIT(NL80211_IFTYPE_AP);
-   max_iface_cnt = 5;
-   } else {
-   limits[i].max = 2;
-   limits[i++].types = BIT(NL80211_IFTYPE_STATION) |
-   BIT(NL80211_IFTYPE_AP);
-   max_iface_cnt = 2;
-   }
-
-   if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_P2P)) {
+   c = 0;
+   i = 0;
+   combo[c].num_different_channels = 1;
+   c0_limits[i].max = 1;
+   c0_limits[i++].types = BIT(NL80211_IFTYPE_STATION);
+   if (p2p) {
+   if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MCHAN))
+   combo[c].num_different_channels = 2;
wiphy->interface_modes |= BIT(NL80211_IFTYPE_P2P_CLIENT) |
  BIT(NL80211_IFTYPE_P2P_GO) |
  BIT(NL80211_IFTYPE_P2P_DEVICE);
-   limits[i].max = 1;
-   limits[i++].types = BIT(NL80211_IFTYPE_P2P_CLIENT) |
-   BIT(NL80211_IFTYPE_P2P_GO);
-   limits[i].max = 1;
-   limits[i++].types = BIT(NL80211_IFTYPE_P2P_DEVICE);
-   max_iface_cnt += 2;
-   }
-   combo->max_interfaces = max_iface_cnt;
-   combo->limits = limits;
-   combo->n_limits = i;
-
+   c0_limits

[PATCH V3 0/6] brcmfmac: nvram loading and code rework

2015-08-20 Thread Arend van Spriel
This series comprises of following changes:
- support NVRAM loading for bcm47xx platform.
- revise announced interface combinations and validate against it.
- new debugfs entry for msgbuf protocol layer used with PCIe devices.
- PCIe fix for handling queue overflow.
- support more firmware events (for bcm4339 firmware).

The series is intended for v4.3 kernel and applies to the master branch
of the wireless-drivers-next repository. Removed patch from this series
that reportedly has issue on OpenWrt platform.

Arend van Spriel (3):
  brcmfmac: correct interface combination info
  brcmfmac: make use of cfg80211_check_combinations()
  brcmfmac: bump highest event number for 4339 firmware

Franky Lin (2):
  brcmfmac: add debugfs entry for msgbuf statistics
  brcmfmac: block the correct flowring when backup queue overflow

Hante Meuleman (1):
  brcmfmac: Add support for host platform NVRAM loading.

 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 195 -
 drivers/net/wireless/brcm80211/brcmfmac/firmware.c |  39 +++--
 drivers/net/wireless/brcm80211/brcmfmac/flowring.c |  10 +-
 drivers/net/wireless/brcm80211/brcmfmac/fweh.h |  10 +-
 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c   |  56 ++
 5 files changed, 247 insertions(+), 63 deletions(-)

-- 
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 V3 5/6] brcmfmac: bump highest event number for 4339 firmware

2015-08-20 Thread Arend van Spriel
The event mask length is determined by the highest event number
that is specified in the driver. When this length is shorter than
firmware expects setting event mask will fail and device becomes
pretty useless. This issue was reported with bcm4339 firmware that
was recently released.

Reported-by: Pontus Fuchs 
Reviewed-by: Hante Meuleman 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Pontus Fuchs 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/brcm80211/brcmfmac/fweh.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/fweh.h 
b/drivers/net/wireless/brcm80211/brcmfmac/fweh.h
index cbf033f..1326898 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/fweh.h
+++ b/drivers/net/wireless/brcm80211/brcmfmac/fweh.h
@@ -85,7 +85,6 @@ struct brcmf_event;
BRCMF_ENUM_DEF(IF, 54) \
BRCMF_ENUM_DEF(P2P_DISC_LISTEN_COMPLETE, 55) \
BRCMF_ENUM_DEF(RSSI, 56) \
-   BRCMF_ENUM_DEF(PFN_SCAN_COMPLETE, 57) \
BRCMF_ENUM_DEF(EXTLOG_MSG, 58) \
BRCMF_ENUM_DEF(ACTION_FRAME, 59) \
BRCMF_ENUM_DEF(ACTION_FRAME_COMPLETE, 60) \
@@ -103,8 +102,7 @@ struct brcmf_event;
BRCMF_ENUM_DEF(FIFO_CREDIT_MAP, 74) \
BRCMF_ENUM_DEF(ACTION_FRAME_RX, 75) \
BRCMF_ENUM_DEF(TDLS_PEER_EVENT, 92) \
-   BRCMF_ENUM_DEF(BCMC_CREDIT_SUPPORT, 127) \
-   BRCMF_ENUM_DEF(PSTA_PRIMARY_INTF_IND, 128)
+   BRCMF_ENUM_DEF(BCMC_CREDIT_SUPPORT, 127)
 
 #define BRCMF_ENUM_DEF(id, val) \
BRCMF_E_##id = (val),
@@ -112,7 +110,11 @@ struct brcmf_event;
 /* firmware event codes sent by the dongle */
 enum brcmf_fweh_event_code {
BRCMF_FWEH_EVENT_ENUM_DEFLIST
-   BRCMF_E_LAST
+   /* this determines event mask length which must match
+* minimum length check in device firmware so it is
+* hard-coded here.
+*/
+   BRCMF_E_LAST = 139
 };
 #undef BRCMF_ENUM_DEF
 
-- 
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 V3 4/6] brcmfmac: block the correct flowring when backup queue overflow

2015-08-20 Thread Arend van Spriel
From: Franky Lin 

brcmf_flowring_block blocks the last active flowring under the same
interface instead of the one provided by caller. This could lead to a
dead lock of netif stop if there are more than one flowring under the
interface and the traffic is high enough so brcmf_flowring_enqueue can
not unblock the ring right away.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Hante Meuleman 
Signed-off-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/brcm80211/brcmfmac/flowring.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/flowring.c 
b/drivers/net/wireless/brcm80211/brcmfmac/flowring.c
index 5944063..8d1ab4a 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/flowring.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/flowring.c
@@ -194,11 +194,15 @@ static void brcmf_flowring_block(struct brcmf_flowring 
*flow, u8 flowid,
spin_lock_irqsave(&flow->block_lock, flags);
 
ring = flow->rings[flowid];
+   if (ring->blocked == blocked) {
+   spin_unlock_irqrestore(&flow->block_lock, flags);
+   return;
+   }
ifidx = brcmf_flowring_ifidx_get(flow, flowid);
 
currently_blocked = false;
for (i = 0; i < flow->nrofrings; i++) {
-   if (flow->rings[i]) {
+   if ((flow->rings[i]) && (i != flowid)) {
ring = flow->rings[i];
if ((ring->status == RING_OPEN) &&
(brcmf_flowring_ifidx_get(flow, i) == ifidx)) {
@@ -209,8 +213,8 @@ static void brcmf_flowring_block(struct brcmf_flowring 
*flow, u8 flowid,
}
}
}
-   ring->blocked = blocked;
-   if (currently_blocked == blocked) {
+   flow->rings[flowid]->blocked = blocked;
+   if (currently_blocked) {
spin_unlock_irqrestore(&flow->block_lock, flags);
return;
}
-- 
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 V3 3/6] brcmfmac: make use of cfg80211_check_combinations()

2015-08-20 Thread Arend van Spriel
Use cfg80211_check_combinations() so we can bail out early when an
interface add or change results in an invalid combination.

Reviewed-by: Hante Meuleman 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 44 +-
 1 file changed, 42 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
index 17cf1bc..9c7c061 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
@@ -469,6 +469,36 @@ brcmf_find_wpsie(const u8 *parse, u32 len)
return NULL;
 }
 
+static int brcmf_vif_change_validate(struct brcmf_cfg80211_info *cfg,
+struct brcmf_cfg80211_vif *vif,
+enum nl80211_iftype new_type)
+{
+   int iftype_num[NUM_NL80211_IFTYPES];
+   struct brcmf_cfg80211_vif *pos;
+
+   memset(&iftype_num[0], 0, sizeof(iftype_num));
+   list_for_each_entry(pos, &cfg->vif_list, list)
+   if (pos == vif)
+   iftype_num[new_type]++;
+   else
+   iftype_num[pos->wdev.iftype]++;
+
+   return cfg80211_check_combinations(cfg->wiphy, 1, 0, iftype_num);
+}
+
+static int brcmf_vif_add_validate(struct brcmf_cfg80211_info *cfg,
+ enum nl80211_iftype new_type)
+{
+   int iftype_num[NUM_NL80211_IFTYPES];
+   struct brcmf_cfg80211_vif *pos;
+
+   memset(&iftype_num[0], 0, sizeof(iftype_num));
+   list_for_each_entry(pos, &cfg->vif_list, list)
+   iftype_num[pos->wdev.iftype]++;
+
+   iftype_num[new_type]++;
+   return cfg80211_check_combinations(cfg->wiphy, 1, 0, iftype_num);
+}
 
 static void convert_key_from_CPU(struct brcmf_wsec_key *key,
 struct brcmf_wsec_key_le *key_le)
@@ -663,8 +693,14 @@ static struct wireless_dev 
*brcmf_cfg80211_add_iface(struct wiphy *wiphy,
 struct vif_params *params)
 {
struct wireless_dev *wdev;
+   int err;
 
brcmf_dbg(TRACE, "enter: %s type %d\n", name, type);
+   err = brcmf_vif_add_validate(wiphy_to_cfg(wiphy), type);
+   if (err) {
+   brcmf_err("iface validation failed: err=%d\n", err);
+   return ERR_PTR(err);
+   }
switch (type) {
case NL80211_IFTYPE_ADHOC:
case NL80211_IFTYPE_STATION:
@@ -823,8 +859,12 @@ brcmf_cfg80211_change_iface(struct wiphy *wiphy, struct 
net_device *ndev,
s32 ap = 0;
s32 err = 0;
 
-   brcmf_dbg(TRACE, "Enter, ndev=%p, type=%d\n", ndev, type);
-
+   brcmf_dbg(TRACE, "Enter, idx=%d, type=%d\n", ifp->bssidx, type);
+   err = brcmf_vif_change_validate(wiphy_to_cfg(wiphy), vif, type);
+   if (err) {
+   brcmf_err("iface validation failed: err=%d\n", err);
+   return err;
+   }
switch (type) {
case NL80211_IFTYPE_MONITOR:
case NL80211_IFTYPE_WDS:
-- 
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 V3 6/6] brcmfmac: Add support for host platform NVRAM loading.

2015-08-20 Thread Arend van Spriel
From: Hante Meuleman 

Host platforms such as routers supported by OpenWRT can
support NVRAM reading directly from internal NVRAM store.
With this patch the nvram load routines will fall back to
this method when there is no nvram file and support is
available in the kernel.

Reviewed-by: Arend Van Spriel 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Daniel (Deognyoun) Kim 
Signed-off-by: Hante Meuleman 
Signed-off-by: Arend van Spriel 
---
V2:
 - addressed comments from Rafał.
V3:
 - remove redundant braces.
 - move bcm47xx_release_contents() call.
---
 drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 39 +-
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
index 743f16b..971920f 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "debug.h"
 #include "firmware.h"
@@ -426,18 +427,32 @@ static void brcmf_fw_request_nvram_done(const struct 
firmware *fw, void *ctx)
struct brcmf_fw *fwctx = ctx;
u32 nvram_length = 0;
void *nvram = NULL;
+   u8 *data = NULL;
+   size_t data_len;
+   bool raw_nvram;
 
brcmf_dbg(TRACE, "enter: dev=%s\n", dev_name(fwctx->dev));
-   if (!fw && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
-   goto fail;
+   if (fw && fw->data) {
+   data = (u8 *)fw->data;
+   data_len = fw->size;
+   raw_nvram = false;
+   } else {
+   data = bcm47xx_nvram_get_contents(&data_len);
+   if (!data && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
+   goto fail;
+   raw_nvram = true;
+   }
 
-   if (fw) {
-   nvram = brcmf_fw_nvram_strip(fw->data, fw->size, &nvram_length,
+   if (data)
+   nvram = brcmf_fw_nvram_strip(data, data_len, &nvram_length,
 fwctx->domain_nr, fwctx->bus_nr);
+
+   if (raw_nvram)
+   bcm47xx_nvram_release_contents(data);
+   if (fw)
release_firmware(fw);
-   if (!nvram && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
-   goto fail;
-   }
+   if (!nvram && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
+   goto fail;
 
fwctx->done(fwctx->dev, fwctx->code, nvram, nvram_length);
kfree(fwctx);
@@ -473,15 +488,9 @@ static void brcmf_fw_request_code_done(const struct 
firmware *fw, void *ctx)
if (!ret)
return;
 
-   /* when nvram is optional call .done() callback here */
-   if (fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL) {
-   fwctx->done(fwctx->dev, fw, NULL, 0);
-   kfree(fwctx);
-   return;
-   }
+   brcmf_fw_request_nvram_done(NULL, fwctx);
+   return;
 
-   /* failed nvram request */
-   release_firmware(fw);
 fail:
brcmf_dbg(TRACE, "failed: dev=%s\n", dev_name(fwctx->dev));
device_release_driver(fwctx->dev);
-- 
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: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

2015-08-20 Thread Eric Dumazet
On Thu, 2015-08-20 at 19:34 +, Grumbach, Emmanuel wrote:

> 
> Err... no :( It won't work for me because the MSS impacts the number of
> segments which in turns impact the number of time the headers have to be
> copied which impacts... the A-MSDU maximal size which must be bigger
> than gso_max_size. So basically, a connection parameter (MSS) impacts a
> device parameter (gso_max_size). Now, of course, I could give up on
> small MSS connections and skb_gso_segment() skbs whose MSS is smaller
> than the default. This means that I give up on LSO in certain cases...
> 

We also have dev->gso_max_segs for this kind of problems.

Really, you should take closer look.

And _if_ some LSO packets must be segmented using skb_gso_segment()
in some rare cases, who cares ?

> I will get back to the drawing board and check what I can do to use /
> enhance the core infra... But it will be hard to lose functionality /
> efficiency just to use the core infra...

Please take your time. Pushing hard some local hacks is not sustainable.


--
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 0/3] nfc: Add driver for Samsung S3FWRN5 NFC Chip

2015-08-20 Thread Samuel Ortiz
Hi Robert,

On Thu, Aug 20, 2015 at 05:25:59PM +0200, Robert Baldyga wrote:
> Hello,
> 
> This patchset adds driver for NFC chip Samsung S3FWRN5. First two patches
> are touching NCI core due to some non-standard chip behaviour.
> 
> The first one adds post_setup() handler, which is called after NCI_CORE_INIT
> request. It's because we need to read current firmware version from 
> ndev->manufact_specific_info.
> 
> The second one adds nci_core_reset() and nci_core_init() functions which
> are needed to reinit NCI core after updating firmware in pose_setup()
> callback.
> 
> Best regards,
> Robert Baldyga
> 
> Changelog:
> 
> v3:
> - Addressed comments from Samuel Ortiz:
>   - Used nci_prop_cmd and nci_prop_ops to handle proprietary requests
>   - Refactorized s3fwrn5_i2c_nci_read and s3fwrn5_i2c_fw_read
>   - Miscellaneous minor fixes
> - Added patch "NFC: nci: Add post_setup handler"
> - Added patch "NFC: nci: export nci_core_reset and nci_core_init"
> 
> v2: http://www.spinics.net/lists/linux-wireless/msg139241.html
> - Addressed comments from Paul Bolle
> 
> v1: http://www.spinics.net/lists/kernel/msg2044290.html
> 
> Robert Baldyga (3):
>   NFC: nci: Add post_setup handler
>   NFC: nci: export nci_core_reset and nci_core_init
>   nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip
All 3 patches applied, thanks.

Cheers,
Samuel.
--
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/7] brcmfmac: Add support for host platform NVRAM loading.

2015-08-20 Thread Arend van Spriel

On 08/19/2015 10:55 PM, Arend van Spriel wrote:

On 08/19/2015 06:38 PM, Rafał Miłecki wrote:

On 16 August 2015 at 08:55, Arend van Spriel  wrote:

From: Hante Meuleman 

Host platforms such as routers supported by OpenWRT can
support NVRAM reading directly from internal NVRAM store.
With this patch the nvram load routines will fall back to
this method when there is no nvram file and support is
available in the kernel.

Cc: Rafał Miłecki 
Reviewed-by: Arend Van Spriel 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Daniel (Deognyoun) Kim 
Signed-off-by: Hante Meuleman 
Signed-off-by: Arend van Spriel 
---
V2:
- addressed comments from Rafał.


Well, you dropped unneeded change to the brcmf_nvram_handle_value
function, but you ignored the rest of my comments. Take a look at them
again please:
https://patchwork.kernel.org/patch/6767961/


Kalle,

Can you remove this patch from the series and apply the rest. Just
verified over here the remaining patches apply cleanly on
wireless-drivers-next.


Hi Kalle,

Just drop this series. I will send a V3 shortly.

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 0/7] brcmfmac: nvram loading and code rework

2015-08-20 Thread Arend van Spriel

On 08/20/2015 05:51 PM, Rafał Miłecki wrote:

On 20 August 2015 at 12:23, Arend van Spriel  wrote:

On 08/20/2015 01:06 AM, Rafał Miłecki wrote:


On 12 August 2015 at 10:58, Arend van Spriel  wrote:


You did a warm reboot of the device, right? There seems to be an issue
because on OpenWrt the brcmfmac is not unloaded upon warm reboot, which
makes the device unaccessible. Because on OpenWrt the firmware request is
synchronous (OpenWrt patch on top of upstream brcmfmac) it results in
probe
failing on invalid access making the issue OpenWrt specific. Hante
created a
fix for the warm reboot issue.



Hante could you share your fix?



Hi Rafał,

Just sent you the patch privately.


Seems to be working nice, thanks! I hope you'll be able to publish it soon :)


Not before monday and I suspect a merge window coming up, but I might be 
just paranoid ;-)


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: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

2015-08-20 Thread Grumbach, Emmanuel


On 08/20/2015 04:53 PM, Grumbach, Emmanuel wrote:
> 
> 
> On 08/20/2015 04:11 PM, Eric Dumazet wrote:
>> On Thu, 2015-08-20 at 06:21 +, Grumbach, Emmanuel wrote:
>>>
>>> On 08/19/2015 11:39 PM, Eric Dumazet wrote:
 On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote:

> Hm.. how would net/core/tso.c avoid this?

 Because a driver using these helpers keep around the original LSO packet
 and frees it normally at TX completion time.

>>>
>>> Which is why I can't really use it. The complexity is that I have to
>>> (ieee802.11 specification) split an LSO is several 802.11 packets. The
>>> maximal 802.11 packet I can send under ideal condition is 11K long or
>>> so. So I *must* generate several 802.11 frames from one single LSO
>>> packet. OTOH, I can have more than MSS bytes in a 802.11 A-MSDU.
>>>
>>
>> Who said you had to free original packet ? Just keep it around.
>>
>> TCP will work better ( check skb_still_in_host_queue() helper if you
>> want to know why)
> 
> I do keep the original skb: it becomes the first 802.11 packet generated
> from that LSO skb. Thing is that it will be freed first and I wanted the
> *last packet* to release the pressure on the socket.
> So I guess that skb_still_in_host_queue will still find it and avoid
> retransmissions at least until the first skb of the LSO is freed.
> But unless you are fine with releasing the pressing on the socket as
> soon as the *first* 802.11 skb is freed, I need that code.
> 
> I'll try to look at dev->gso_max_size that you mentioned below. This can
> really be a game changer for me.
> 


Err... no :( It won't work for me because the MSS impacts the number of
segments which in turns impact the number of time the headers have to be
copied which impacts... the A-MSDU maximal size which must be bigger
than gso_max_size. So basically, a connection parameter (MSS) impacts a
device parameter (gso_max_size). Now, of course, I could give up on
small MSS connections and skb_gso_segment() skbs whose MSS is smaller
than the default. This means that I give up on LSO in certain cases...

I will get back to the drawing board and check what I can do to use /
enhance the core infra... But it will be hard to lose functionality /
efficiency just to use the core infra...
--
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 3/7] brcmfmac: Increase nr of supported flowrings.

2015-08-20 Thread Arend van Spriel

On 08/20/2015 06:16 PM, Rafał Miłecki wrote:

On 16 August 2015 at 08:55, Arend van Spriel  wrote:

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/flowring.h 
b/drivers/net/wireless/brcm80211/brcmfmac/flowring.h
index 5551861..3a7d9c2 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/flowring.h
+++ b/drivers/net/wireless/brcm80211/brcmfmac/flowring.h
@@ -16,7 +16,7 @@
  #define BRCMFMAC_FLOWRING_H


-#define BRCMF_FLOWRING_HASHSIZE256
+#define BRCMF_FLOWRING_HASHSIZE512 /* has to be 
2^x */
  #define BRCMF_FLOWRING_INVALID_ID  0x


Applying patch *and* switching back to 256 let brcmfmac work again
with my BCM43602. Not sure if it helps to understand the problem much.


Not to me. Maybe Hante gets some ideas, but he is ooo till monday.

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 v2 1/7] brcmfmac: Add support for host platform NVRAM loading.

2015-08-20 Thread Rafał Miłecki
On 20 August 2015 at 18:06, Arend van Spriel  wrote:
> On 08/20/2015 05:53 PM, Rafał Miłecki wrote:
>>
>> On 19 August 2015 at 23:43, Arend van Spriel  wrote:
>>>
>>> On 08/19/2015 11:21 PM, Arend van Spriel wrote:


 subject changed to v2. So let's go over your beef.

 On 07/11/2015 07:09 PM, Rafał Miłecki wrote:
>
>
> On 10 July 2015 at 20:31, Arend van Spriel  wrote:
>>
>>
>> @@ -146,7 +147,7 @@ brcmf_nvram_handle_value(struct nvram_parser *nvp)
>>   u32 cplen;
>>
>>   c = nvp->data[nvp->pos];
>> -   if (!is_nvram_char(c)) {
>> +   if (!is_nvram_char(c) && (c != ' ')) {
>
>
>
> This is redundant, please drop this change.
> See fc23e81eb8f4 ("brcmfmac: allow NVRAM values to contain spaces")



 done

>> @@ -426,19 +428,34 @@ static void brcmf_fw_request_nvram_done(const
>> struct firmware *fw, void *ctx)
>>   struct brcmf_fw *fwctx = ctx;
>>   u32 nvram_length = 0;
>>   void *nvram = NULL;
>> +   u8 *data = NULL;
>
>
>
> This can be const.



 done
>>>
>>>
>>>
>>> Actually this is not done, but either way will require a cast because
>>> bcm47xx_nvram_release_contents expects char* so there is nothing gained.
>>> Unless someone will change bcm47xx_nvram_get/release_contents api to
>>> const
>>> char*.
>>
>>
>> Passing non-const pointer to function taking const one is OK. You
>> don't need casting, compiler won't complain about this.
>
>
> bcm47xx_nvram_release_contents expect a non-const pointer so the const data
> pointer needs to be cast to non-const. Which you claim is hacky.
> Here is what happens when I make data pointer const:
>
>   CC [M]  drivers/net/wireless/brcm80211/brcmfmac/firmware.o
> drivers/net/wireless/brcm80211/brcmfmac/firmware.c: In function
> ���brcmf_fw_request_nvram_done���:
> drivers/net/wireless/brcm80211/brcmfmac/firmware.c:450:4: warning: passing
> argument 1 of ���bcm47xx_nvram_release_contents��� discards ���const���
> qualifier from pointer target type [enabled by default]
> bcm47xx_nvram_release_contents(data);
> ^
> In file included from
> drivers/net/wireless/brcm80211/brcmfmac/firmware.c:22:0:
> include/linux/bcm47xx_nvram.h:44:20: note: expected ���char *��� but
> argument is of type ���const u8 *���
>  static inline void bcm47xx_nvram_release_contents(char *nvram)
> ^
>>
>> On the other hand casing const pointer to the non-const one is hacky
>> and I believe you should avoid that.
>
>
> Either way you have to do a cast from const to non-const.
>
> u8 *data => data = (u8 *)fw->data;
> const u8 *data => bcm47xx_nvram_release_contents((char *)data);

Oh, I feel silly. Yeah, you're right. In OpenWrt I was using two
separated variables and it was what basically let it work. Just ignore
that noise from me :|

-- 
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 3/7] brcmfmac: Increase nr of supported flowrings.

2015-08-20 Thread Rafał Miłecki
On 16 August 2015 at 08:55, Arend van Spriel  wrote:
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/flowring.h 
> b/drivers/net/wireless/brcm80211/brcmfmac/flowring.h
> index 5551861..3a7d9c2 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/flowring.h
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/flowring.h
> @@ -16,7 +16,7 @@
>  #define BRCMFMAC_FLOWRING_H
>
>
> -#define BRCMF_FLOWRING_HASHSIZE256
> +#define BRCMF_FLOWRING_HASHSIZE512 /* has to be 
> 2^x */
>  #define BRCMF_FLOWRING_INVALID_ID  0x

Applying patch *and* switching back to 256 let brcmfmac work again
with my BCM43602. Not sure if it helps to understand the problem much.
--
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/7] brcmfmac: Add support for host platform NVRAM loading.

2015-08-20 Thread Arend van Spriel

On 08/20/2015 05:59 PM, Rafał Miłecki wrote:

On 19 August 2015 at 23:21, Arend van Spriel  wrote:

subject changed to v2. So let's go over your beef.


I really hope none of my comment was mean or anything :)



On 07/11/2015 07:09 PM, Rafał Miłecki wrote:


On 10 July 2015 at 20:31, Arend van Spriel  wrote:

+   data_len = fw->size;
+   raw_nvram = false;
+   } else {
+   data = bcm47xx_nvram_get_contents(&data_len);
+   if (!data && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
+   goto fail;
+   raw_nvram = true;
+   }

-   if (fw) {
-   nvram = brcmf_fw_nvram_strip(fw->data, fw->size,
&nvram_length,
+   if (data) {
+   nvram = brcmf_fw_nvram_strip(data, data_len,
&nvram_length,
   fwctx->domain_nr,
fwctx->bus_nr);
-   release_firmware(fw);
-   if (!nvram && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
-   goto fail;
+   if (raw_nvram)
+   bcm47xx_nvram_release_contents(data);



This is cosmetical but maybe you could move above 2 lines next to the
release_firmware? So we have all freeing code at one please? Do you
think it would improve readability?
Nothing important thought. Feel free to ignore me here.



confused! The release_firmware call is removed here, right?


Yes, you removed it from the "if (data) {" condition body but also
re-added right after it. AFAIR I got an impression it may make more
sense to have something like:
if (raw_nvram)
 bcm47xx_nvram_release_contents(data);


I did not check whether bcm47xx_nvram_release_contents deals with data 
being NULL pointer. If so, I can change it.


Regards,
Arend


if (fw)
 release_firmware(fw);
but you can just ignore it if it doesn't sound clear.



--
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/7] brcmfmac: Add support for host platform NVRAM loading.

2015-08-20 Thread Arend van Spriel

On 08/20/2015 05:53 PM, Rafał Miłecki wrote:

On 19 August 2015 at 23:43, Arend van Spriel  wrote:

On 08/19/2015 11:21 PM, Arend van Spriel wrote:


subject changed to v2. So let's go over your beef.

On 07/11/2015 07:09 PM, Rafał Miłecki wrote:


On 10 July 2015 at 20:31, Arend van Spriel  wrote:


@@ -146,7 +147,7 @@ brcmf_nvram_handle_value(struct nvram_parser *nvp)
  u32 cplen;

  c = nvp->data[nvp->pos];
-   if (!is_nvram_char(c)) {
+   if (!is_nvram_char(c) && (c != ' ')) {



This is redundant, please drop this change.
See fc23e81eb8f4 ("brcmfmac: allow NVRAM values to contain spaces")



done


@@ -426,19 +428,34 @@ static void brcmf_fw_request_nvram_done(const
struct firmware *fw, void *ctx)
  struct brcmf_fw *fwctx = ctx;
  u32 nvram_length = 0;
  void *nvram = NULL;
+   u8 *data = NULL;



This can be const.



done



Actually this is not done, but either way will require a cast because
bcm47xx_nvram_release_contents expects char* so there is nothing gained.
Unless someone will change bcm47xx_nvram_get/release_contents api to const
char*.


Passing non-const pointer to function taking const one is OK. You
don't need casting, compiler won't complain about this.


bcm47xx_nvram_release_contents expect a non-const pointer so the const 
data pointer needs to be cast to non-const. Which you claim is hacky.

Here is what happens when I make data pointer const:

  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/firmware.o
drivers/net/wireless/brcm80211/brcmfmac/firmware.c: In function 
���brcmf_fw_request_nvram_done���:
drivers/net/wireless/brcm80211/brcmfmac/firmware.c:450:4: warning: 
passing argument 1 of ���bcm47xx_nvram_release_contents��� discards 
���const��� qualifier from pointer target type [enabled by default]

bcm47xx_nvram_release_contents(data);
^
In file included from 
drivers/net/wireless/brcm80211/brcmfmac/firmware.c:22:0:
include/linux/bcm47xx_nvram.h:44:20: note: expected ���char *��� but 
argument is of type ���const u8 *���

 static inline void bcm47xx_nvram_release_contents(char *nvram)
^

On the other hand casing const pointer to the non-const one is hacky
and I believe you should avoid that.


Either way you have to do a cast from const to non-const.

u8 *data => data = (u8 *)fw->data;
const u8 *data => bcm47xx_nvram_release_contents((char *)data);

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 v2 1/7] brcmfmac: Add support for host platform NVRAM loading.

2015-08-20 Thread Rafał Miłecki
On 19 August 2015 at 23:21, Arend van Spriel  wrote:
> subject changed to v2. So let's go over your beef.

I really hope none of my comment was mean or anything :)


> On 07/11/2015 07:09 PM, Rafał Miłecki wrote:
>>
>> On 10 July 2015 at 20:31, Arend van Spriel  wrote:
>>> +   data_len = fw->size;
>>> +   raw_nvram = false;
>>> +   } else {
>>> +   data = bcm47xx_nvram_get_contents(&data_len);
>>> +   if (!data && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
>>> +   goto fail;
>>> +   raw_nvram = true;
>>> +   }
>>>
>>> -   if (fw) {
>>> -   nvram = brcmf_fw_nvram_strip(fw->data, fw->size,
>>> &nvram_length,
>>> +   if (data) {
>>> +   nvram = brcmf_fw_nvram_strip(data, data_len,
>>> &nvram_length,
>>>   fwctx->domain_nr,
>>> fwctx->bus_nr);
>>> -   release_firmware(fw);
>>> -   if (!nvram && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
>>> -   goto fail;
>>> +   if (raw_nvram)
>>> +   bcm47xx_nvram_release_contents(data);
>>
>>
>> This is cosmetical but maybe you could move above 2 lines next to the
>> release_firmware? So we have all freeing code at one please? Do you
>> think it would improve readability?
>> Nothing important thought. Feel free to ignore me here.
>
>
> confused! The release_firmware call is removed here, right?

Yes, you removed it from the "if (data) {" condition body but also
re-added right after it. AFAIR I got an impression it may make more
sense to have something like:
if (raw_nvram)
bcm47xx_nvram_release_contents(data);
if (fw)
release_firmware(fw);
but you can just ignore it if it doesn't sound clear.
--
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/7] brcmfmac: Add support for host platform NVRAM loading.

2015-08-20 Thread Rafał Miłecki
On 19 August 2015 at 23:43, Arend van Spriel  wrote:
> On 08/19/2015 11:21 PM, Arend van Spriel wrote:
>>
>> subject changed to v2. So let's go over your beef.
>>
>> On 07/11/2015 07:09 PM, Rafał Miłecki wrote:
>>>
>>> On 10 July 2015 at 20:31, Arend van Spriel  wrote:

 @@ -146,7 +147,7 @@ brcmf_nvram_handle_value(struct nvram_parser *nvp)
  u32 cplen;

  c = nvp->data[nvp->pos];
 -   if (!is_nvram_char(c)) {
 +   if (!is_nvram_char(c) && (c != ' ')) {
>>>
>>>
>>> This is redundant, please drop this change.
>>> See fc23e81eb8f4 ("brcmfmac: allow NVRAM values to contain spaces")
>>
>>
>> done
>>
 @@ -426,19 +428,34 @@ static void brcmf_fw_request_nvram_done(const
 struct firmware *fw, void *ctx)
  struct brcmf_fw *fwctx = ctx;
  u32 nvram_length = 0;
  void *nvram = NULL;
 +   u8 *data = NULL;
>>>
>>>
>>> This can be const.
>>
>>
>> done
>
>
> Actually this is not done, but either way will require a cast because
> bcm47xx_nvram_release_contents expects char* so there is nothing gained.
> Unless someone will change bcm47xx_nvram_get/release_contents api to const
> char*.

Passing non-const pointer to function taking const one is OK. You
don't need casting, compiler won't complain about this.

On the other hand casing const pointer to the non-const one is hacky
and I believe you should avoid 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: [PATCH 0/7] brcmfmac: nvram loading and code rework

2015-08-20 Thread Rafał Miłecki
On 20 August 2015 at 12:23, Arend van Spriel  wrote:
> On 08/20/2015 01:06 AM, Rafał Miłecki wrote:
>>
>> On 12 August 2015 at 10:58, Arend van Spriel  wrote:
>>>
>>> You did a warm reboot of the device, right? There seems to be an issue
>>> because on OpenWrt the brcmfmac is not unloaded upon warm reboot, which
>>> makes the device unaccessible. Because on OpenWrt the firmware request is
>>> synchronous (OpenWrt patch on top of upstream brcmfmac) it results in
>>> probe
>>> failing on invalid access making the issue OpenWrt specific. Hante
>>> created a
>>> fix for the warm reboot issue.
>>
>>
>> Hante could you share your fix?
>
>
> Hi Rafał,
>
> Just sent you the patch privately.

Seems to be working nice, thanks! I hope you'll be able to publish it soon :)

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


[PATCH v3 0/3] nfc: Add driver for Samsung S3FWRN5 NFC Chip

2015-08-20 Thread Robert Baldyga
Hello,

This patchset adds driver for NFC chip Samsung S3FWRN5. First two patches
are touching NCI core due to some non-standard chip behaviour.

The first one adds post_setup() handler, which is called after NCI_CORE_INIT
request. It's because we need to read current firmware version from 
ndev->manufact_specific_info.

The second one adds nci_core_reset() and nci_core_init() functions which
are needed to reinit NCI core after updating firmware in pose_setup()
callback.

Best regards,
Robert Baldyga

Changelog:

v3:
- Addressed comments from Samuel Ortiz:
  - Used nci_prop_cmd and nci_prop_ops to handle proprietary requests
  - Refactorized s3fwrn5_i2c_nci_read and s3fwrn5_i2c_fw_read
  - Miscellaneous minor fixes
- Added patch "NFC: nci: Add post_setup handler"
- Added patch "NFC: nci: export nci_core_reset and nci_core_init"

v2: http://www.spinics.net/lists/linux-wireless/msg139241.html
- Addressed comments from Paul Bolle

v1: http://www.spinics.net/lists/kernel/msg2044290.html

Robert Baldyga (3):
  NFC: nci: Add post_setup handler
  NFC: nci: export nci_core_reset and nci_core_init
  nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip

 .../devicetree/bindings/net/nfc/s3fwrn5.txt|  27 ++
 MAINTAINERS|   6 +
 drivers/nfc/Kconfig|   1 +
 drivers/nfc/Makefile   |   1 +
 drivers/nfc/s3fwrn5/Kconfig|  19 +
 drivers/nfc/s3fwrn5/Makefile   |  11 +
 drivers/nfc/s3fwrn5/core.c | 219 +
 drivers/nfc/s3fwrn5/firmware.c | 511 +
 drivers/nfc/s3fwrn5/firmware.h | 111 +
 drivers/nfc/s3fwrn5/i2c.c  | 306 
 drivers/nfc/s3fwrn5/nci.c  | 165 +++
 drivers/nfc/s3fwrn5/nci.h  |  89 
 drivers/nfc/s3fwrn5/s3fwrn5.h  |  99 
 include/net/nfc/nci_core.h |   3 +
 net/nfc/nci/core.c |  18 +
 15 files changed, 1586 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/nfc/s3fwrn5.txt
 create mode 100644 drivers/nfc/s3fwrn5/Kconfig
 create mode 100644 drivers/nfc/s3fwrn5/Makefile
 create mode 100644 drivers/nfc/s3fwrn5/core.c
 create mode 100644 drivers/nfc/s3fwrn5/firmware.c
 create mode 100644 drivers/nfc/s3fwrn5/firmware.h
 create mode 100644 drivers/nfc/s3fwrn5/i2c.c
 create mode 100644 drivers/nfc/s3fwrn5/nci.c
 create mode 100644 drivers/nfc/s3fwrn5/nci.h
 create mode 100644 drivers/nfc/s3fwrn5/s3fwrn5.h

-- 
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 v3 1/3] NFC: nci: Add post_setup handler

2015-08-20 Thread Robert Baldyga
Some drivers require non-standard configuration after NCI_CORE_INIT
request, because they need to know ndev->manufact_specific_info or
ndev->manufact_id. This patch adds post_setup handler allowing to do
such custom configuration.

Signed-off-by: Robert Baldyga 
---
 include/net/nfc/nci_core.h | 1 +
 net/nfc/nci/core.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 01fc8c5..1bdaa5f 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -79,6 +79,7 @@ struct nci_ops {
int   (*close)(struct nci_dev *ndev);
int   (*send)(struct nci_dev *ndev, struct sk_buff *skb);
int   (*setup)(struct nci_dev *ndev);
+   int   (*post_setup)(struct nci_dev *ndev);
int   (*fw_download)(struct nci_dev *ndev, const char *firmware_name);
__u32 (*get_rfprotocol)(struct nci_dev *ndev, __u8 rf_protocol);
int   (*discover_se)(struct nci_dev *ndev);
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 95af2d2..d9045ec 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -388,6 +388,10 @@ static int nci_open_device(struct nci_dev *ndev)
   msecs_to_jiffies(NCI_INIT_TIMEOUT));
}
 
+   if (ndev->ops->post_setup) {
+   rc = ndev->ops->post_setup(ndev);
+   }
+
if (!rc) {
rc = __nci_request(ndev, nci_init_complete_req, 0,
   msecs_to_jiffies(NCI_INIT_TIMEOUT));
-- 
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 v3 3/3] nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip

2015-08-20 Thread Robert Baldyga
Add driver for Samsung S3FWRN5 NFC controller.
S3FWRN5 is using NCI protocol and I2C communication interface.

Signed-off-by: Robert Baldyga 
---
 .../devicetree/bindings/net/nfc/s3fwrn5.txt|  27 ++
 MAINTAINERS|   6 +
 drivers/nfc/Kconfig|   1 +
 drivers/nfc/Makefile   |   1 +
 drivers/nfc/s3fwrn5/Kconfig|  19 +
 drivers/nfc/s3fwrn5/Makefile   |  11 +
 drivers/nfc/s3fwrn5/core.c | 219 +
 drivers/nfc/s3fwrn5/firmware.c | 511 +
 drivers/nfc/s3fwrn5/firmware.h | 111 +
 drivers/nfc/s3fwrn5/i2c.c  | 306 
 drivers/nfc/s3fwrn5/nci.c  | 165 +++
 drivers/nfc/s3fwrn5/nci.h  |  89 
 drivers/nfc/s3fwrn5/s3fwrn5.h  |  99 
 13 files changed, 1565 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/nfc/s3fwrn5.txt
 create mode 100644 drivers/nfc/s3fwrn5/Kconfig
 create mode 100644 drivers/nfc/s3fwrn5/Makefile
 create mode 100644 drivers/nfc/s3fwrn5/core.c
 create mode 100644 drivers/nfc/s3fwrn5/firmware.c
 create mode 100644 drivers/nfc/s3fwrn5/firmware.h
 create mode 100644 drivers/nfc/s3fwrn5/i2c.c
 create mode 100644 drivers/nfc/s3fwrn5/nci.c
 create mode 100644 drivers/nfc/s3fwrn5/nci.h
 create mode 100644 drivers/nfc/s3fwrn5/s3fwrn5.h

diff --git a/Documentation/devicetree/bindings/net/nfc/s3fwrn5.txt 
b/Documentation/devicetree/bindings/net/nfc/s3fwrn5.txt
new file mode 100644
index 000..fb1e75f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nfc/s3fwrn5.txt
@@ -0,0 +1,27 @@
+* Samsung S3FWRN5 NCI NFC Controller
+
+Required properties:
+- compatible: Should be "samsung,s3fwrn5-i2c".
+- reg: address on the bus
+- interrupt-parent: phandle for the interrupt gpio controller
+- interrupts: GPIO interrupt to which the chip is connected
+- s3fwrn5,en-gpios: Output GPIO pin used for enabling/disabling the chip
+- s3fwrn5,fw-gpios: Output GPIO pin used to enter firmware mode and
+  sleep/wakeup control
+
+Example:
+
+&hsi2c_4 {
+   status = "okay";
+   s3fwrn5@27 {
+   compatible = "samsung,s3fwrn5-i2c";
+
+   reg = <0x27>;
+
+   interrupt-parent = <&gpa1>;
+   interrupts = <3 0 0>;
+
+   s3fwrn5,en-gpios = <&gpf1 4 0>;
+   s3fwrn5,fw-gpios = <&gpj0 2 0>;
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index ca51eba..7a3b1b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8871,6 +8871,12 @@ L:   linux-me...@vger.kernel.org
 S: Supported
 F: drivers/media/i2c/s5k5baf.c
 
+SAMSUNG S3FWRN5 NFC DRIVER
+M: Robert Baldyga 
+L: linux-...@lists.01.org (moderated for non-subscribers)
+S: Supported
+F: drivers/nfc/s3fwrn5
+
 SAMSUNG SOC CLOCK DRIVERS
 M: Sylwester Nawrocki 
 M: Tomasz Figa 
diff --git a/drivers/nfc/Kconfig b/drivers/nfc/Kconfig
index 722673c..6639cd1 100644
--- a/drivers/nfc/Kconfig
+++ b/drivers/nfc/Kconfig
@@ -74,4 +74,5 @@ source "drivers/nfc/nfcmrvl/Kconfig"
 source "drivers/nfc/st21nfca/Kconfig"
 source "drivers/nfc/st-nci/Kconfig"
 source "drivers/nfc/nxp-nci/Kconfig"
+source "drivers/nfc/s3fwrn5/Kconfig"
 endmenu
diff --git a/drivers/nfc/Makefile b/drivers/nfc/Makefile
index 368b6df..2757fe1 100644
--- a/drivers/nfc/Makefile
+++ b/drivers/nfc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_NFC_TRF7970A)+= trf7970a.o
 obj-$(CONFIG_NFC_ST21NFCA) += st21nfca/
 obj-$(CONFIG_NFC_ST_NCI)   += st-nci/
 obj-$(CONFIG_NFC_NXP_NCI)  += nxp-nci/
+obj-$(CONFIG_NFC_S3FWRN5)  += s3fwrn5/
diff --git a/drivers/nfc/s3fwrn5/Kconfig b/drivers/nfc/s3fwrn5/Kconfig
new file mode 100644
index 000..7e3b255
--- /dev/null
+++ b/drivers/nfc/s3fwrn5/Kconfig
@@ -0,0 +1,19 @@
+config NFC_S3FWRN5
+   tristate
+   ---help---
+ Core driver for Samsung S3FWRN5 NFC chip. Contains core utilities
+ of chip. It's intended to be used by PHYs to avoid duplicating lots
+ of common code.
+
+config NFC_S3FWRN5_I2C
+   tristate "Samsung S3FWRN5 I2C support"
+   depends on NFC_NCI && I2C
+   select NFC_S3FWRN5
+   default n
+   ---help---
+ This module adds support for an I2C interface to the S3FWRN5 chip.
+ Select this if your platform is using the I2C bus.
+
+ To compile this driver as a module, choose m here. The module will
+ be called s3fwrn5_i2c.ko.
+ Say N if unsure.
diff --git a/drivers/nfc/s3fwrn5/Makefile b/drivers/nfc/s3fwrn5/Makefile
new file mode 100644
index 000..3381c34
--- /dev/null
+++ b/drivers/nfc/s3fwrn5/Makefile
@@ -0,0 +1,11 @@
+#
+# Makefile for Samsung S3FWRN5 NFC driver
+#
+
+s3fwrn5-objs = core.o firmware.o nci.o
+s3fwrn5_i2c-objs = i2c.o
+
+obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5.o
+obj-$(CONFIG_NFC_S3FWRN5_I2C

[PATCH v3 2/3] NFC: nci: export nci_core_reset and nci_core_init

2015-08-20 Thread Robert Baldyga
Some drivers needs to have ability to reinit NCI core, for example after
updating firmware in setup() of post_setup() callback. This patch makes
nci_core_reset() and nci_core_init() functions public, to make it possible.

Signed-off-by: Robert Baldyga 
---
 include/net/nfc/nci_core.h |  2 ++
 net/nfc/nci/core.c | 14 ++
 2 files changed, 16 insertions(+)

diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 1bdaa5f..d0d0f1e 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -278,6 +278,8 @@ int nci_request(struct nci_dev *ndev,
unsigned long opt),
unsigned long opt, __u32 timeout);
 int nci_prop_cmd(struct nci_dev *ndev, __u8 oid, size_t len, __u8 *payload);
+int nci_core_reset(struct nci_dev *ndev);
+int nci_core_init(struct nci_dev *ndev);
 
 int nci_recv_frame(struct nci_dev *ndev, struct sk_buff *skb);
 int nci_set_config(struct nci_dev *ndev, __u8 id, size_t len, __u8 *val);
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index d9045ec..943889b 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -351,6 +351,20 @@ int nci_prop_cmd(struct nci_dev *ndev, __u8 oid, size_t 
len, __u8 *payload)
 }
 EXPORT_SYMBOL(nci_prop_cmd);
 
+int nci_core_reset(struct nci_dev *ndev)
+{
+   return __nci_request(ndev, nci_reset_req, 0,
+msecs_to_jiffies(NCI_RESET_TIMEOUT));
+}
+EXPORT_SYMBOL(nci_core_reset);
+
+int nci_core_init(struct nci_dev *ndev)
+{
+   return __nci_request(ndev, nci_init_req, 0,
+msecs_to_jiffies(NCI_INIT_TIMEOUT));
+}
+EXPORT_SYMBOL(nci_core_init);
+
 static int nci_open_device(struct nci_dev *ndev)
 {
int rc = 0;
-- 
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: Using ath5k/ath9k radio for constant-tx noise source.

2015-08-20 Thread Zefir Kurtisi
On 08/19/2015 09:07 PM, Ben Greear wrote:
> I have a commercial AP that is using a CM9 ath5k radio (evidently, I could be 
> wrong)
> and it has the ability to do a constant transmit of raw noise (RF probe shows
> noise, but a monitor-port sniffer does not see any frames from the CM9).
> 
> I don't know the low-level details of how it is doing this, but I suspect
> it is using something like madwifi for a driver.
> 
> Does anyone know how this can be done with modern software and
> ath5k or ath9k NICs?
> 
> Thanks,
> Ben
> 

Maybe slightly related: some years ago when DFS became a topic and it was hard 
to
get hands on radar pattern generators, Christian Lamparter wrote a variant of 
the
carl9170 fw [1] which can generate radar pulses to test ath9k and other DFS 
radar
detectors. Pulses are generated by enabling txout at defined sampling intervals.

It should be doable to mimic what you are looking for by generating a _very_ 
long
pulse.


Good Luck,
Zefir


[1] https://github.com/chunkeey/carl9170fw/tree/radar
--
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: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

2015-08-20 Thread Eric Dumazet
On Thu, 2015-08-20 at 13:53 +, Grumbach, Emmanuel wrote:

> I do keep the original skb: it becomes the first 802.11 packet generated
> from that LSO skb. Thing is that it will be freed first and I wanted the
> *last packet* to release the pressure on the socket.

Just change this to free it last. It is that simple.

> So I guess that skb_still_in_host_queue will still find it and avoid
> retransmissions at least until the first skb of the LSO is freed.
> But unless you are fine with releasing the pressing on the socket as
> soon as the *first* 802.11 skb is freed, I need that code.
> 
> I'll try to look at dev->gso_max_size that you mentioned below. This can
> really be a game changer for me.

Honestly, if your TSO patches do not use existing infra, I will NACK
them.

If existing infra is not good enough, you have the power to change it.

Fully re-implementing TSO (or GRO) in a device driver is a non starter.


--
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: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

2015-08-20 Thread Grumbach, Emmanuel


On 08/20/2015 04:11 PM, Eric Dumazet wrote:
> On Thu, 2015-08-20 at 06:21 +, Grumbach, Emmanuel wrote:
>>
>> On 08/19/2015 11:39 PM, Eric Dumazet wrote:
>>> On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote:
>>>
 Hm.. how would net/core/tso.c avoid this?
>>>
>>> Because a driver using these helpers keep around the original LSO packet
>>> and frees it normally at TX completion time.
>>>
>>
>> Which is why I can't really use it. The complexity is that I have to
>> (ieee802.11 specification) split an LSO is several 802.11 packets. The
>> maximal 802.11 packet I can send under ideal condition is 11K long or
>> so. So I *must* generate several 802.11 frames from one single LSO
>> packet. OTOH, I can have more than MSS bytes in a 802.11 A-MSDU.
>>
> 
> Who said you had to free original packet ? Just keep it around.
> 
> TCP will work better ( check skb_still_in_host_queue() helper if you
> want to know why)

I do keep the original skb: it becomes the first 802.11 packet generated
from that LSO skb. Thing is that it will be freed first and I wanted the
*last packet* to release the pressure on the socket.
So I guess that skb_still_in_host_queue will still find it and avoid
retransmissions at least until the first skb of the LSO is freed.
But unless you are fine with releasing the pressing on the socket as
soon as the *first* 802.11 skb is freed, I need that code.

I'll try to look at dev->gso_max_size that you mentioned below. This can
really be a game changer for me.

> 
>> Maybe what would help would be to be able to dynamically change the
>> maximal size of an LSO packet. That would allow the wifi driver to
>> ensure that the LSO can fit in a single 802.11 packet. Note that since
>> the maximal length of the A-MSDU can vary based on link conditions
>> (since there is only one CRC for the whole A-MSDU, you don't want long
>> A-MSDUs in bad link conditions) the driver would need to be able to tell
>> the TCP stack to modify the length of an LSO packet.
>> To me, this sounds to be ... an overkill?
> 
> It is already doable. Check dev->gso_max_size ( and
> netif_set_gso_max_size())
> 
> Make sure you do not reinvent the wheel ;)
> 
> 
> 
--
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: [RFC v3 1/3] iwlwifi: mvm: add real TSO implementation

2015-08-20 Thread Grumbach, Emmanuel


On 08/20/2015 04:13 PM, Eric Dumazet wrote:
> On Thu, 2015-08-20 at 11:15 +0300, Emmanuel Grumbach wrote:
>> The segmentation is done completely in software. The
>> driver creates several MPDUs out of a single large send.
>> Each MPDU is a newly allocated SKB.
>> A page is allocated to create the headers that need to be
>> duplicated (SNAP / IP / TCP). The WiFi header is in the
>> header of the newly created SKBs.
>>
>> type=feature
>>
>> Change-Id: I238ffa79cacc5bbdacdfbf3e9673c8d4f02b462a
>> Signed-off-by: Emmanuel Grumbach 
>> ---
>>  drivers/net/wireless/iwlwifi/mvm/tx.c | 513 
>> +++---
>>  1 file changed, 481 insertions(+), 32 deletions(-)
> 
> 
> Ouch again.
> 
> This will be a NACK. Sorry.
> 
> 

To be honest, I don't see why. No matter how you look at it, you need to
add headers. And these headers need to sit on some memory that is not
yet allocated. skb_gso_segment allocates new skb which is a memory
allocation.

I looked at ethernet/marvell/mvneta.c (which uses net/core/tso.c) and
they pre-allocate DMA coherent memory for the additional headers they
create. I can have pre-allocated pages if you want.
--
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/RFT 0/2] ath10k: add qca6164 support

2015-08-20 Thread Arnd Bergmann
On Tuesday 18 August 2015 11:52:45 Oscar Rydberg wrote:
> I can confirm this patch did it for my Lenovo Yoga 3 14 with QCA6164, the
> WLAN interface is now alive, up and running perfectly fine!
> (After running modprobe -r ideapad-laptop that is, should anyone have
> trouble enabling it)
> 
> I had tried all the board.bin files from the windows drivers before, so the
> added sanity check seems to be what finally solved it.

I hope to test it in my Yoga 3 11 (1170) in the next days. Meanwhile, what is
the problem you see with the ideapad-laptop driver? I have recently submitted
a couple of bug fixes for the Yoga 1170, can you try if the patch below
fixes this for you?

Arnd

commit 9d6d311add697014bdccb18d625db7e38676adbf
Author: Arnd Bergmann 
Date:   Sat Jun 13 15:13:11 2015 +0200

ideapad: add rfkill whitelist entry for Yoga 3 1170

This adds one more entry to the whitelist of machines that do not have
a physical rfkill switch. Unfortunately, the Yoga 3 generation seems
to use upper-case letters for the YOGA 3 Pro-1370, while it uses normal
capitalization for its Yoga 3 1170 sibling.

In order to catch all variants of the Yoga 3, I'm now using both strings
as wildcards here, which should also cover the 1470 model, and possible
changes in the string that could happen in firmware updates.

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c
index cb7cd8d79329..8e455c1429ee 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -855,7 +855,14 @@ static const struct dmi_system_id no_hw_rfkill_list[] = {
.ident = "Lenovo Yoga 3 Pro 1370",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo YOGA 3 
Pro-1370"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo YOGA 3"),
+   },
+   },
+   {
+   .ident = "Lenovo Yoga 3 1170 / 1470",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo Yoga 3"),
},
},
{}

--
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: [RFC v3 1/3] iwlwifi: mvm: add real TSO implementation

2015-08-20 Thread Eric Dumazet
On Thu, 2015-08-20 at 11:15 +0300, Emmanuel Grumbach wrote:
> The segmentation is done completely in software. The
> driver creates several MPDUs out of a single large send.
> Each MPDU is a newly allocated SKB.
> A page is allocated to create the headers that need to be
> duplicated (SNAP / IP / TCP). The WiFi header is in the
> header of the newly created SKBs.
> 
> type=feature
> 
> Change-Id: I238ffa79cacc5bbdacdfbf3e9673c8d4f02b462a
> Signed-off-by: Emmanuel Grumbach 
> ---
>  drivers/net/wireless/iwlwifi/mvm/tx.c | 513 
> +++---
>  1 file changed, 481 insertions(+), 32 deletions(-)


Ouch again.

This will be a NACK. Sorry.


--
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: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

2015-08-20 Thread Eric Dumazet
On Thu, 2015-08-20 at 06:21 +, Grumbach, Emmanuel wrote:
> 
> On 08/19/2015 11:39 PM, Eric Dumazet wrote:
> > On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote:
> > 
> >> Hm.. how would net/core/tso.c avoid this?
> > 
> > Because a driver using these helpers keep around the original LSO packet
> > and frees it normally at TX completion time.
> > 
> 
> Which is why I can't really use it. The complexity is that I have to
> (ieee802.11 specification) split an LSO is several 802.11 packets. The
> maximal 802.11 packet I can send under ideal condition is 11K long or
> so. So I *must* generate several 802.11 frames from one single LSO
> packet. OTOH, I can have more than MSS bytes in a 802.11 A-MSDU.
> 

Who said you had to free original packet ? Just keep it around.

TCP will work better ( check skb_still_in_host_queue() helper if you
want to know why)

> Maybe what would help would be to be able to dynamically change the
> maximal size of an LSO packet. That would allow the wifi driver to
> ensure that the LSO can fit in a single 802.11 packet. Note that since
> the maximal length of the A-MSDU can vary based on link conditions
> (since there is only one CRC for the whole A-MSDU, you don't want long
> A-MSDUs in bad link conditions) the driver would need to be able to tell
> the TCP stack to modify the length of an LSO packet.
> To me, this sounds to be ... an overkill?

It is already doable. Check dev->gso_max_size ( and
netif_set_gso_max_size())

Make sure you do not reinvent the wheel ;)


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


[patch] mwifiex: fix mwifiex_rdeeprom_read()

2015-08-20 Thread Dan Carpenter
There were several bugs here.

1)  The done label was in the wrong place so we didn't copy any
information out when there was no command given.

2)  We were using PAGE_SIZE as the size of the buffer instead of
"PAGE_SIZE - pos".

3)  snprintf() returns the number of characters that would have been
printed if there were enough space.  If there was not enough space
(and we had fixed the memory corruption bug #2) then it would result
in an information leak when we do simple_read_from_buffer().  I've
changed it to use scnprintf() instead.

I also removed the initialization at the start of the function, because
I thought it made the code a little more clear.

Fixes: 5e6e3a92b9a4 ('wireless: mwifiex: initial commit for Marvell mwifiex 
driver')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/wireless/mwifiex/debugfs.c 
b/drivers/net/wireless/mwifiex/debugfs.c
index 5a0636d4..bd2f5d2 100644
--- a/drivers/net/wireless/mwifiex/debugfs.c
+++ b/drivers/net/wireless/mwifiex/debugfs.c
@@ -731,7 +731,7 @@ mwifiex_rdeeprom_read(struct file *file, char __user *ubuf,
(struct mwifiex_private *) file->private_data;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *) addr;
-   int pos = 0, ret = 0, i;
+   int pos, ret, i;
u8 value[MAX_EEPROM_DATA];
 
if (!buf)
@@ -739,7 +739,7 @@ mwifiex_rdeeprom_read(struct file *file, char __user *ubuf,
 
if (saved_offset == -1) {
/* No command has been given */
-   pos += snprintf(buf, PAGE_SIZE, "0");
+   pos = snprintf(buf, PAGE_SIZE, "0");
goto done;
}
 
@@ -751,14 +751,14 @@ mwifiex_rdeeprom_read(struct file *file, char __user 
*ubuf,
goto done;
}
 
-   pos += snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes);
+   pos = snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes);
 
for (i = 0; i < saved_bytes; i++)
-   pos += snprintf(buf + strlen(buf), PAGE_SIZE, "%d ", value[i]);
+   pos += scnprintf(buf + pos, PAGE_SIZE - pos, "%d ", value[i]);
 
+done:
ret = simple_read_from_buffer(ubuf, count, ppos, buf, pos);
 
-done:
free_page(addr);
return ret;
 }
--
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/7] brcmfmac: nvram loading and code rework

2015-08-20 Thread Arend van Spriel

On 08/20/2015 01:06 AM, Rafał Miłecki wrote:

On 12 August 2015 at 10:58, Arend van Spriel  wrote:

You did a warm reboot of the device, right? There seems to be an issue
because on OpenWrt the brcmfmac is not unloaded upon warm reboot, which
makes the device unaccessible. Because on OpenWrt the firmware request is
synchronous (OpenWrt patch on top of upstream brcmfmac) it results in probe
failing on invalid access making the issue OpenWrt specific. Hante created a
fix for the warm reboot issue.


Hante could you share your fix?


Hi Rafał,

Just sent you the patch privately.

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


[RFC v3 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

2015-08-20 Thread Emmanuel Grumbach
This allows to release the backpressure on the socket only
when the last segment is released.
Now the truesize looks like this:
if the truesize of the original skb is 65420, all the
segments will have a truesize of 704 (skb itself) and the
last one will have 65420.

Change-Id: I3c894cf2afc0aedfe7b2a5b992ba41653ff79c0e
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/tx.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/tx.c 
b/drivers/net/wireless/iwlwifi/mvm/tx.c
index 5046833..2aeb5fd 100644
--- a/drivers/net/wireless/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/mvm/tx.c
@@ -764,7 +764,7 @@ static int iwl_mvm_tx_tso(struct iwl_mvm *mvm, struct 
sk_buff *skb_gso,
bool ipv6 = skb_shinfo(skb_gso)->gso_type & SKB_GSO_TCPV6;
struct iwl_lso_splitter s = {};
struct page *hdr_page;
-   unsigned int mpdu_sz;
+   unsigned int mpdu_sz, sum_truesize = 0;
u8 *hdr_page_pos, *qc, tid;
int i, ret;
 
@@ -898,6 +898,7 @@ static int iwl_mvm_tx_tso(struct iwl_mvm *mvm, struct 
sk_buff *skb_gso,
mpdu_sz, tcp_hdrlen(skb_gso));
 
__skb_queue_tail(mpdus_skb, skb_gso);
+   sum_truesize += skb_gso->truesize;
 
/* mss bytes have been consumed from the data */
s.gso_payload_pos = s.mss;
@@ -1034,6 +1035,20 @@ static int iwl_mvm_tx_tso(struct iwl_mvm *mvm, struct 
sk_buff *skb_gso,
}
 
__skb_queue_tail(mpdus_skb, skb);
+   sum_truesize += skb->truesize;
+   }
+
+   /* Release the backpressure on the socket only when
+* the last segment is released.
+*/
+   if (skb_gso->destructor) {
+   struct sk_buff *tail = mpdus_skb->prev;
+
+   swap(tail->truesize, skb_gso->truesize);
+   swap(tail->destructor, skb_gso->destructor);
+   swap(tail->sk, skb_gso->sk);
+   atomic_add(sum_truesize - skb_gso->truesize,
+  &skb_gso->sk->sk_wmem_alloc);
}
 
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


[RFC v3 0/3] add TSO / A-MSDU TX for iwlwifi

2015-08-20 Thread Emmanuel Grumbach
An A-MSDU is a 802.11 frame that comprises several L3
segments:
Each subframe has a ETH / SNAP / IP / TCP header (in case 
TCP is used of course). Each subframe has no 802.11
limitation on its length (only the MSS limitation), but
the whole A-MSDU has a size limit both in number of
subframes, and in bytes. In the best conditions, the
A-MSDU is unlimited in number of subframes, and can be up
to 11K byte long. An A-MSDU has only one WiFi MAC address,
and hence, each A-MSDU can be sent to only one WiFi peer.

There a 2 ways to get A-MSDU:
 * xmit_more
 * LSO
 * LSO + skb_gso_segment

The problem with xmit_more is that in AP mode, the Qdisc
can have packets for several L2 clients which makes is
harder to use since as stated above, an A-MSDU can be sent
to one single WiFi peer.

The problem with LSO is that the LSO packet is very likely
to be way bigger than the maximal A-MSDU length. This means
that a single LSO packet will generate several WiFi packets.
>From an arch point of view, having different WiFi packets
sitting in one single skb is a problem, so we need to create
several skbs out of one single LSO packet. This makes the
usage of currently existing helpers (net/core/tso.c) very
hard.

Using LSO and skb_gso_segment is a bit wasteful since we
don't need an skb for each MSS, so that we would have to
reassemble the segs into one single packet. This is
sub-efficient.

Out of the two aforementioned ways, I chose to work with
LSO and implemented the segmentation in the driver itself.
While this code can technically be made driver agnostic,
the trend in the industry seems to show that more and more
vendors split the buffers in the firmware, so that I don't
expect to see any new devices coming up with the same
behavior as ours. I did take a look on currently existing
drivers and they already do the work in firmware.
If someone in linux-wireless thinks that this code can
serve his purposes, please speak up. All you'd need is to
support TX_CSUM and SG.

The additional headers needed (SNAP / IP / TCP) are copied
and updated on a page which is allocated in xmit. This is
supposed to very cheap. I add skb frags from that page to 
add the skb. Since I can have several 802.11 packets from a
single LSO packet, I allocated skb's on the way if needed.

I am quite a newbie in skb handling, so I guess that this
code can be improved. I have tested it decently using iperf,
but this doesn't mean that there are no issues using other
applications. We are enabling pktgen on TCP (using patches
that were sent a year ago or so) to test the different
layouts of the skb (payload partition amongst the header
and the different frags).

Changes since v2:
*
   + I fixed the whitespace problem spotted by Sergei.
   + I changed the D'tor check for truesize accounting.
 Since the D'tor seems to be set to tcp_wfree if it
 exists, I just the D'tor not being NULL.

Emmanuel Grumbach (3):
  iwlwifi: mvm: add real TSO implementation
  iwlwifi: mvm: allow to create A-MSDUs from a large send
  iwlwifi: mvm: transfer the truesize to the last TSO segment

 drivers/net/wireless/iwlwifi/mvm/mac80211.c |   3 +-
 drivers/net/wireless/iwlwifi/mvm/sta.c  |   4 +-
 drivers/net/wireless/iwlwifi/mvm/sta.h  |   6 +-
 drivers/net/wireless/iwlwifi/mvm/tx.c   | 669 ++--
 4 files changed, 647 insertions(+), 35 deletions(-)

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


[RFC v3 1/3] iwlwifi: mvm: add real TSO implementation

2015-08-20 Thread Emmanuel Grumbach
The segmentation is done completely in software. The
driver creates several MPDUs out of a single large send.
Each MPDU is a newly allocated SKB.
A page is allocated to create the headers that need to be
duplicated (SNAP / IP / TCP). The WiFi header is in the
header of the newly created SKBs.

type=feature

Change-Id: I238ffa79cacc5bbdacdfbf3e9673c8d4f02b462a
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/tx.c | 513 +++---
 1 file changed, 481 insertions(+), 32 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/tx.c 
b/drivers/net/wireless/iwlwifi/mvm/tx.c
index 90f0ea1..a63686c 100644
--- a/drivers/net/wireless/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/mvm/tx.c
@@ -65,6 +65,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "iwl-trans.h"
 #include "iwl-eeprom-parse.h"
@@ -435,32 +436,471 @@ int iwl_mvm_tx_skb_non_sta(struct iwl_mvm *mvm, struct 
sk_buff *skb)
return 0;
 }
 
+/*
+ * Update the IP / TCP headers and recompute the IP header CSUM +
+ * pseudo header CSUM.
+ */
+static void iwl_update_ip_tcph(void *iph, struct tcphdr *tcph, bool ipv6,
+  unsigned int len, unsigned int tcp_seq_offset,
+  u16 num_segment)
+{
+   be32_add_cpu(&tcph->seq, tcp_seq_offset);
+
+   if (ipv6) {
+   struct ipv6hdr *iphv6 = iph;
+
+   iphv6->payload_len = cpu_to_be16(len + tcph->doff * 4);
+
+   /* Compute CSUM on the the pseudo-header */
+   tcph->check = ~csum_ipv6_magic(&iphv6->saddr, &iphv6->daddr,
+  len + tcph->doff * 4,
+  IPPROTO_TCP, 0);
+   } else {
+   struct iphdr *iphv4 = iph;
+
+   iphv4->tot_len =
+   cpu_to_be16(len + tcph->doff * 4 + iphv4->ihl * 4);
+   be16_add_cpu(&iphv4->id, num_segment);
+   ip_send_check(iphv4);
+
+   /* Compute CSUM on the the pseudo-header */
+   tcph->check = ~csum_tcpudp_magic(iphv4->saddr, iphv4->daddr,
+len + tcph->doff * 4,
+IPPROTO_TCP, 0);
+   }
+}
+
+/**
+ * struct iwl_lso_splitter - state of the split.
+ * @linear_payload_len: The length of the payload inside the header of the
+ * original GSO skb.
+ * @gso_frag_num: The fragment number from which to take the data in the
+ * original GSO skb.
+ * @gso_payload_len: The length of the payload in the original GSO skb.
+ * @gso_payload_pos: The incrementing position in the payload of the original
+ * GSO skb.
+ * @gso_offset_in_page: The offset in the page of &gso_frag_num.
+ * @gso_current_frag_size: The size of &gso_frag_num.
+ * @gso_offset_in_frag: The offset in the &gso_frag_num.
+ * @frag_in_mpdu: The index of the frag inside the new (split) MPDU.
+ * @mss: The maximal segment size.
+ * @si: Points to the the shared info of the original GSO skb.
+ * @ieee80211_hdr *hdr: Points to the WiFi header.
+ * @gso_nr_frags: The number of frags in the original GSO skb.
+ * @wifi_hdr_iv_len: The length of the WiFi header including IV.
+ * @tcp_fin: True if TCP_FIN is set in the original GSO skb.
+ * @tcp_push: True if TCP_PSH is set in the original GSO skb.
+ */
+struct iwl_lso_splitter {
+   unsigned int linear_payload_len;
+   unsigned int gso_frag_num;
+   unsigned int gso_payload_len;
+   unsigned int gso_payload_pos;
+   unsigned int gso_offset_in_page;
+   unsigned int gso_current_frag_size;
+   unsigned int gso_offset_in_frag;
+   unsigned int frag_in_mpdu;
+   unsigned int mss;
+   struct skb_shared_info *si;
+   struct ieee80211_hdr *hdr;
+   u8 gso_nr_frags;
+   u8 wifi_hdr_iv_len;
+   bool tcp_fin;
+   bool tcp_push;
+};
+
+/*
+ * Adds a TCP segment from skb_gso to skb. All the state is taken from
+ * and fed back to p. This function takes care about the payload only.
+ * This MSDU might already have msdu_sz bytes of payload that come from
+ * the original GSO skb's header.
+ */
+static unsigned int
+iwl_add_tcp_segment(struct iwl_mvm *mvm, struct sk_buff *skb_gso,
+   struct sk_buff *skb, struct iwl_lso_splitter *p,
+   unsigned int msdu_sz)
+{
+   while (msdu_sz < p->mss) {
+   unsigned int frag_sz =
+   min_t(unsigned int, p->gso_current_frag_size,
+ p->mss - msdu_sz);
+
+   if (p->frag_in_mpdu >= mvm->trans->max_skb_frags)
+   return msdu_sz;
+
+   skb_add_rx_frag(skb, p->frag_in_mpdu,
+   skb_frag_page(&p->si->frags[p->gso_frag_num]),
+   p->gso_offset_in_page, frag_sz, 0);
+
+   /* We just added one frag to the mpdu ... */
+   p->frag_in_mpdu++;
+
+   

[RFC v3 2/3] iwlwifi: mvm: allow to create A-MSDUs from a large send

2015-08-20 Thread Emmanuel Grumbach
Now that we can get a big chunk of data from the network
stack, we can create an A-MSDU out of it. The purpose is to
get a throughput improvement since sending one single A-MSDU
is more efficient than sending several MSDUs at least under
ideal link conditions.

type=feature

Change-Id: I5ea1b1132a57542187cd4c34c5299dbf44fe8b01
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/mac80211.c |   3 +-
 drivers/net/wireless/iwlwifi/mvm/sta.c  |   4 +-
 drivers/net/wireless/iwlwifi/mvm/sta.h  |   6 +-
 drivers/net/wireless/iwlwifi/mvm/tx.c   | 159 ++--
 4 files changed, 160 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 3dd4e97..dd15e04 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -925,7 +925,8 @@ static int iwl_mvm_mac_ampdu_action(struct ieee80211_hw *hw,
ret = iwl_mvm_sta_tx_agg_flush(mvm, vif, sta, tid);
break;
case IEEE80211_AMPDU_TX_OPERATIONAL:
-   ret = iwl_mvm_sta_tx_agg_oper(mvm, vif, sta, tid, buf_size);
+   ret = iwl_mvm_sta_tx_agg_oper(mvm, vif, sta, tid,
+ buf_size, amsdu);
break;
default:
WARN_ON_ONCE(1);
diff --git a/drivers/net/wireless/iwlwifi/mvm/sta.c 
b/drivers/net/wireless/iwlwifi/mvm/sta.c
index df216cd..606fc09 100644
--- a/drivers/net/wireless/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/iwlwifi/mvm/sta.c
@@ -976,7 +976,8 @@ int iwl_mvm_sta_tx_agg_start(struct iwl_mvm *mvm, struct 
ieee80211_vif *vif,
 }
 
 int iwl_mvm_sta_tx_agg_oper(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
-   struct ieee80211_sta *sta, u16 tid, u8 buf_size)
+   struct ieee80211_sta *sta, u16 tid, u8 buf_size,
+   bool amsdu)
 {
struct iwl_mvm_sta *mvmsta = iwl_mvm_sta_from_mac80211(sta);
struct iwl_mvm_tid_data *tid_data = &mvmsta->tid_data[tid];
@@ -995,6 +996,7 @@ int iwl_mvm_sta_tx_agg_oper(struct iwl_mvm *mvm, struct 
ieee80211_vif *vif,
queue = tid_data->txq_id;
tid_data->state = IWL_AGG_ON;
mvmsta->agg_tids |= BIT(tid);
+   tid_data->amsdu_in_ampdu_allowed = amsdu;
tid_data->ssn = 0x;
spin_unlock_bh(&mvmsta->lock);
 
diff --git a/drivers/net/wireless/iwlwifi/mvm/sta.h 
b/drivers/net/wireless/iwlwifi/mvm/sta.h
index eedb215..26d1e31 100644
--- a/drivers/net/wireless/iwlwifi/mvm/sta.h
+++ b/drivers/net/wireless/iwlwifi/mvm/sta.h
@@ -258,6 +258,8 @@ enum iwl_mvm_agg_state {
  * Tx response (TX_CMD), and the block ack notification (COMPRESSED_BA).
  * @reduced_tpc: Reduced tx power. Holds the data between the
  * Tx response (TX_CMD), and the block ack notification (COMPRESSED_BA).
+ * @amsdu_in_ampdu_allowed: true if A-MSDU in A-MPDU is allowed. Relevant only
+ * if &state is %IWL_AGG_ON.
  * @state: state of the BA agreement establishment / tear down.
  * @txq_id: Tx queue used by the BA session
  * @ssn: the first packet to be sent in AGG HW queue in Tx AGG start flow, or
@@ -272,6 +274,7 @@ struct iwl_mvm_tid_data {
/* The rest is Tx AGG related */
u32 rate_n_flags;
u8 reduced_tpc;
+   bool amsdu_in_ampdu_allowed;
enum iwl_mvm_agg_state state;
u16 txq_id;
u16 ssn;
@@ -387,7 +390,8 @@ int iwl_mvm_sta_rx_agg(struct iwl_mvm *mvm, struct 
ieee80211_sta *sta,
 int iwl_mvm_sta_tx_agg_start(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
struct ieee80211_sta *sta, u16 tid, u16 *ssn);
 int iwl_mvm_sta_tx_agg_oper(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
-   struct ieee80211_sta *sta, u16 tid, u8 buf_size);
+   struct ieee80211_sta *sta, u16 tid, u8 buf_size,
+   bool amsdu);
 int iwl_mvm_sta_tx_agg_stop(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
struct ieee80211_sta *sta, u16 tid);
 int iwl_mvm_sta_tx_agg_flush(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
diff --git a/drivers/net/wireless/iwlwifi/mvm/tx.c 
b/drivers/net/wireless/iwlwifi/mvm/tx.c
index a63686c..5046833 100644
--- a/drivers/net/wireless/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/mvm/tx.c
@@ -488,8 +488,10 @@ static void iwl_update_ip_tcph(void *iph, struct tcphdr 
*tcph, bool ipv6,
  * @ieee80211_hdr *hdr: Points to the WiFi header.
  * @gso_nr_frags: The number of frags in the original GSO skb.
  * @wifi_hdr_iv_len: The length of the WiFi header including IV.
+ * @amsdu_pad: Number of bytes for the A-MSDU subframe
  * @tcp_fin: True if TCP_FIN is set in the original GSO skb.
  * @tcp_push: True if TCP_PSH is set in the original GSO skb.
+ * @amsdu: True if we are building an A-MSDU
  */
 struct iwl_lso_splitter {
unsigned int linear_payload_len;

Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

2015-08-20 Thread Grumbach, Emmanuel


On 08/20/2015 10:21 AM, Grumbach, Emmanuel wrote:
> 
> 
> On 08/19/2015 11:39 PM, Eric Dumazet wrote:
>> On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote:
>>
>>> Hm.. how would net/core/tso.c avoid this?
>>
>> Because a driver using these helpers keep around the original LSO packet
>> and frees it normally at TX completion time.
>>
>>> I can't see anything related to truesize there.
>>> Note that this work since it is guaranteed that we release the skbs in
>>> order.
>>>

 (BTW TCP packets do not have sock_wfree as destructor but tcp_wfree(),
 yet we want backpressure mostly for TCP stack (TCP Small Queues))


>>>
>>> I am not sure I follow here.
>>> You want me to test:
>>> if (skb_gso->destructor == tcp_wfree) ?
>>
>>
>> Yes.
>>
>> Look for example at tcp_gso_segment() (called from skb_gso_segment())
>>
>> copy_destructor = gso_skb->destructor == tcp_wfree;
>> ...
>> /* Following permits TCP Small Queues to work well with GSO :
>>  * The callback to TCP stack will be called at the time last frag
>>  * is freed at TX completion, and not right now when gso_skb
>>  * is freed by GSO engine
>>  */
>> if (copy_destructor) {
>> swap(gso_skb->sk, skb->sk);
>> swap(gso_skb->destructor, skb->destructor);
>> sum_truesize += skb->truesize;
>> atomic_add(sum_truesize - gso_skb->truesize,
>>&skb->sk->sk_wmem_alloc);
>> }
>>
>>
>>>
>>> I checked that code using iperf and saw that I don't get into this if,
>>> but I (probably wrongly) assumed that other applications would set a
>>> flag on the socket (forgive my ignorance) that would make this if be taken.
>>
>> If you do not see skb->destructor == tcp_wfree, then something is
>> definitely wrong on your setup.
>>
> 
> tcp_wfree isn't exported. I can change that. It will be a challenge for
> backport though. Hm
> 

But you seem to say that gso_skb->destructor *should* point to
tcp_wfree, so maybe testing gso_skb->destructor isn't NULL is good enough?
--
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] ath9k: fix AR_RX_FILTER for ar9462/ar9565 when rx stopped

2015-08-20 Thread miaoqing
From: Miaoqing Pan 

When rx stopped, AR_RX_FILTER should be cleared, but in
ath9k_hw_setrxfilter(), ATH9K_RX_FILTER_CONTROL_WRAPPER will always
be set for ar9462/ar9565.

Fix this by moving the code in ath9k_hw_setrxfilter() to
ath_calcrxfilter().

Signed-off-by: Miaoqing Pan 
---
 drivers/net/wireless/ath/ath9k/hw.c   | 3 ---
 drivers/net/wireless/ath/ath9k/recv.c | 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index a31a680..0e2b28c 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2760,9 +2760,6 @@ void ath9k_hw_setrxfilter(struct ath_hw *ah, u32 bits)
 
ENABLE_REGWRITE_BUFFER(ah);
 
-   if (AR_SREV_9462(ah) || AR_SREV_9565(ah))
-   bits |= ATH9K_RX_FILTER_CONTROL_WRAPPER;
-
REG_WRITE(ah, AR_RX_FILTER, bits);
 
phybits = 0;
diff --git a/drivers/net/wireless/ath/ath9k/recv.c 
b/drivers/net/wireless/ath/ath9k/recv.c
index d3189da..0689f6b 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -424,6 +424,9 @@ u32 ath_calcrxfilter(struct ath_softc *sc)
AR_SREV_9561(sc->sc_ah))
rfilt |= ATH9K_RX_FILTER_4ADDRESS;
 
+   if (AR_SREV_9462(sc->sc_ah) || AR_SREV_9565(sc->sc_ah))
+   rfilt |= ATH9K_RX_FILTER_CONTROL_WRAPPER;
+
if (ath9k_is_chanctx_enabled() &&
test_bit(ATH_OP_SCANNING, &common->op_flags))
rfilt |= ATH9K_RX_FILTER_BEACON;
-- 
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 4/5] staging: wilc1000: change address to fixed value

2015-08-20 Thread Tony Cho
From: Johnny Kim 

The linux_wlan_init_test_config() is called once when net driver is loaded.
And because the pointer type of the pstrWFIDrv is changed with the interger
type, this patch replaces it with designated value instead of pointer.

Signed-off-by: Johnny Kim 
Signed-off-by: Tony Cho 
---
 drivers/staging/wilc1000/linux_wlan.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index b3cc9f5..4b2cba7 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1052,7 +1052,7 @@ static int linux_wlan_init_test_config(struct net_device 
*dev, linux_wlan_t *p_n
goto _fail_;
}
 
-   *(int *)c_val = (u32)pstrWFIDrv;
+   *(int *)c_val = 1;
 
if (!g_linux_wlan->oup.wlan_cfg_set(1, WID_SET_DRV_HANDLER, c_val, 4, 
0, 0))
goto _fail_;
@@ -1291,7 +1291,7 @@ static int linux_wlan_init_test_config(struct net_device 
*dev, linux_wlan_t *p_n
goto _fail_;
 
c_val[0] = 1; /* Enable N with immediate block ack. */
-   if (!g_linux_wlan->oup.wlan_cfg_set(0, WID_11N_IMMEDIATE_BA_ENABLED, 
c_val, 1, 1, (u32)pstrWFIDrv))
+   if (!g_linux_wlan->oup.wlan_cfg_set(0, WID_11N_IMMEDIATE_BA_ENABLED, 
c_val, 1, 1, 1))
goto _fail_;
 
return 0;
-- 
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/5] staging: wilc1000: use the real data type

2015-08-20 Thread Tony Cho
From: Johnny Kim 

This patch changes the type of gu8FlushedJoinReqDrvHandler with his real
data type becasue typecasting is not necessary. In result, typecasting
which is not necessary and some building warnings is removed.

Signed-off-by: Johnny Kim 
Signed-off-by: Tony Cho 
---
 drivers/staging/wilc1000/host_interface.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 66fa677..0913d18 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -578,7 +578,7 @@ u8 gu8Flushed11iMode;
 u8 gu8FlushedAuthType;
 u32 gu32FlushedJoinReqSize;
 u32 gu32FlushedInfoElemAsocSize;
-u32 gu8FlushedJoinReqDrvHandler;
+tstrWILC_WFIDrv *gu8FlushedJoinReqDrvHandler;
 #define REAL_JOIN_REQ 0
 #define FLUSHED_JOIN_REQ 1
 #define FLUSHED_BYTE_POS 79 /* Position the byte indicating flushing in 
the flushed request */
@@ -1940,7 +1940,7 @@ static s32 Handle_Connect(tstrWILC_WFIDrv *drvHandler, 
tstrHostIFconnectAttr *ps
/*BugID_5137*/
if (memcmp("DIRECT-", pstrHostIFconnectAttr->pu8ssid, 7)) {
memcpy(gu8FlushedJoinReq, pu8CurrByte, gu32FlushedJoinReqSize);
-   gu8FlushedJoinReqDrvHandler = (u32)pstrWFIDrv;
+   gu8FlushedJoinReqDrvHandler = pstrWFIDrv;
}
 
PRINT_D(GENERIC_DBG, "send HOST_IF_WAITING_CONN_RESP\n");
@@ -2191,11 +2191,11 @@ static s32 Handle_ConnectTimeout(tstrWILC_WFIDrv 
*drvHandler)
memset(u8ConnectedSSID, 0, ETH_ALEN);
/*BugID_5213*/
/*Freeing flushed join request params on connect timeout*/
-   if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == 
(u32)drvHandler) {
+   if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == 
drvHandler) {
kfree(gu8FlushedJoinReq);
gu8FlushedJoinReq = NULL;
}
-   if (gu8FlushedInfoElemAsoc != NULL && gu8FlushedJoinReqDrvHandler == 
(u32)drvHandler) {
+   if (gu8FlushedInfoElemAsoc != NULL && gu8FlushedJoinReqDrvHandler == 
drvHandler) {
kfree(gu8FlushedInfoElemAsoc);
gu8FlushedInfoElemAsoc = NULL;
}
@@ -2617,11 +2617,11 @@ static s32 Handle_RcvdGnrlAsyncInfo(tstrWILC_WFIDrv 
*drvHandler, tstrRcvdGnrlAsy
/*BugID_5213*/
/*Freeing flushed join request params on receiving*/
/*MAC_DISCONNECTED while connected*/
-   if (gu8FlushedJoinReq != NULL && 
gu8FlushedJoinReqDrvHandler == (u32)drvHandler) {
+   if (gu8FlushedJoinReq != NULL && 
gu8FlushedJoinReqDrvHandler == drvHandler) {
kfree(gu8FlushedJoinReq);
gu8FlushedJoinReq = NULL;
}
-   if (gu8FlushedInfoElemAsoc != NULL && 
gu8FlushedJoinReqDrvHandler == (u32)drvHandler) {
+   if (gu8FlushedInfoElemAsoc != NULL && 
gu8FlushedJoinReqDrvHandler == drvHandler) {
kfree(gu8FlushedInfoElemAsoc);
gu8FlushedInfoElemAsoc = NULL;
}
@@ -3117,11 +3117,11 @@ static void Handle_Disconnect(tstrWILC_WFIDrv 
*drvHandler)
 
 
/*BugID_5137*/
-   if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == 
(u32)drvHandler) {
+   if (gu8FlushedJoinReq != NULL && gu8FlushedJoinReqDrvHandler == 
drvHandler) {
kfree(gu8FlushedJoinReq);
gu8FlushedJoinReq = NULL;
}
-   if (gu8FlushedInfoElemAsoc != NULL && 
gu8FlushedJoinReqDrvHandler == (u32)drvHandler) {
+   if (gu8FlushedInfoElemAsoc != NULL && 
gu8FlushedJoinReqDrvHandler == drvHandler) {
kfree(gu8FlushedInfoElemAsoc);
gu8FlushedInfoElemAsoc = NULL;
}
-- 
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 2/5] staging: wilc1000: add an argument for Handle_SetWfiDrvHandler

2015-08-20 Thread Tony Cho
From: Johnny Kim 

Similar to functions of same layer, this patch add an argument for
Handle_SetWfiDrvHandler function. As a result, the redundant typecasting is
removed.

Signed-off-by: Johnny Kim 
Signed-off-by: Tony Cho 
---
 drivers/staging/wilc1000/host_interface.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 0913d18..47e43cc 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -637,12 +637,13 @@ static s32 Handle_SetChannel(tstrWILC_WFIDrv *drvHandler, 
tstrHostIFSetChan *pst
  *  @date
  *  @version   1.0
  */
-static s32 Handle_SetWfiDrvHandler(tstrHostIfSetDrvHandler 
*pstrHostIfSetDrvHandler)
+static s32 Handle_SetWfiDrvHandler(tstrWILC_WFIDrv *drvHandler,
+  tstrHostIfSetDrvHandler 
*pstrHostIfSetDrvHandler)
 {
 
s32 s32Error = WILC_SUCCESS;
tstrWID strWID;
-   tstrWILC_WFIDrv *pstrWFIDrv = (tstrWILC_WFIDrv 
*)((pstrHostIfSetDrvHandler->u32Address));
+   tstrWILC_WFIDrv *pstrWFIDrv = drvHandler;
 
 
/*prepare configuration packet*/
@@ -656,7 +657,7 @@ static s32 Handle_SetWfiDrvHandler(tstrHostIfSetDrvHandler 
*pstrHostIfSetDrvHand
s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv);
 
 
-   if ((pstrHostIfSetDrvHandler->u32Address) == (u32)NULL)
+   if (pstrWFIDrv == NULL)
up(&hSemDeinitDrvHandle);
 
 
@@ -4474,7 +4475,8 @@ static int hostIFthread(void *pvArg)
break;
 
case HOST_IF_MSG_SET_WFIDRV_HANDLER:
-   
Handle_SetWfiDrvHandler(&strHostIFmsg.uniHostIFmsgBody.strHostIfSetDrvHandler);
+   Handle_SetWfiDrvHandler(strHostIFmsg.drvHandler,
+   
&strHostIFmsg.uniHostIFmsgBody.strHostIfSetDrvHandler);
break;
 
case HOST_IF_MSG_SET_OPERATION_MODE:
@@ -5819,7 +5821,7 @@ s32 host_int_set_wfi_drv_handler(tstrWILC_WFIDrv 
*u32address)
memset(&strHostIFmsg, 0, sizeof(tstrHostIFmsg));
strHostIFmsg.u16MsgId = HOST_IF_MSG_SET_WFIDRV_HANDLER;
strHostIFmsg.uniHostIFmsgBody.strHostIfSetDrvHandler.u32Address = 
u32address;
-   /* strHostIFmsg.drvHandler=hWFIDrv; */
+   strHostIFmsg.drvHandler = u32address;
 
s32Error = WILC_MsgQueueSend(&gMsgQHostIF, &strHostIFmsg, 
sizeof(tstrHostIFmsg));
if (s32Error)
-- 
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 5/5] staging: wilc1000: define undefined operation mode

2015-08-20 Thread Tony Cho
From: Johnny Kim 

This patch adds new define, IDLE_MODE to change comparison statement which
is wrong due to typecasting to null.

Signed-off-by: Johnny Kim 
Signed-off-by: Tony Cho 
---
 drivers/staging/wilc1000/host_interface.c | 2 +-
 drivers/staging/wilc1000/host_interface.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 4b5e62a..17ecad2 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -754,7 +754,7 @@ static s32 Handle_SetOperationMode(tstrWILC_WFIDrv 
*drvHandler, tstrHostIfSetOpe
 get_id_from_handler(pstrWFIDrv));
 
 
-   if ((pstrHostIfSetOperationMode->u32Mode) == (u32)NULL)
+   if ((pstrHostIfSetOperationMode->u32Mode) == IDLE_MODE)
up(&hSemDeinitDrvHandle);
 
 
diff --git a/drivers/staging/wilc1000/host_interface.h 
b/drivers/staging/wilc1000/host_interface.h
index 349d5f5..a107377 100644
--- a/drivers/staging/wilc1000/host_interface.h
+++ b/drivers/staging/wilc1000/host_interface.h
@@ -23,6 +23,7 @@
 #define BIT1((u32)(1 << 1))
 #define BIT0((u32)(1 << 0))
 
+#define IDLE_MODE  0x00
 #define AP_MODE0x01
 #define STATION_MODE   0x02
 #define GO_MODE0x03
-- 
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 3/5] staging: wilc1000: use id value as argument

2015-08-20 Thread Tony Cho
From: Johnny Kim 

The driver communicates with the chipset via the address of handlers
to distinguish async data frame. The SendConfigPkt function gets the
pointer address indicating the handlers as the last argument, but this
requires redundant typecasting and does not support the 64 bit machine.

This patch adds the function which assigns ID values instead of pointer
representing the driver handler to the address and then uses the ID
instead of pointer as the last argument of SendConfigPkt. The driver
also gets the handler's address from the ID in the data frame when it
receives them.

Signed-off-by: Johnny Kim 
Signed-off-by: Tony Cho 
---
 drivers/staging/wilc1000/host_interface.c | 241 +++---
 drivers/staging/wilc1000/host_interface.h |   1 +
 drivers/staging/wilc1000/wilc_wfi_netdevice.h |   1 -
 3 files changed, 176 insertions(+), 67 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 47e43cc..4b5e62a 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -531,8 +531,8 @@ typedef enum {
 /* Global Variabls 
 */
 /* 
 */
 /*/
-
-
+/* Zero is not used, because a zero ID means termination */
+static tstrWILC_WFIDrv *wfidrv_list[NUM_CONCURRENT_IFC + 1];
 tstrWILC_WFIDrv *terminated_handle;
 tstrWILC_WFIDrv *gWFiDrvHandle;
 #ifdef DISABLE_PWRSAVE_AND_SCAN_DURING_IP
@@ -592,6 +592,56 @@ static void *host_int_ParseJoinBssParam(tstrNetworkInfo 
*ptstrNetworkInfo);
 extern void chip_sleep_manually(u32 u32SleepTime);
 extern int linux_wlan_get_num_conn_ifcs(void);
 
+static int add_handler_in_list(tstrWILC_WFIDrv *handler)
+{
+   int i;
+
+   for (i = 1; i < ARRAY_SIZE(wfidrv_list); i++) {
+   if (!wfidrv_list[i]) {
+   wfidrv_list[i] = handler;
+   return 0;
+   }
+   }
+
+   return -ENOBUFS;
+}
+
+static int remove_handler_in_list(tstrWILC_WFIDrv *handler)
+{
+   int i;
+
+   for (i = 1; i < ARRAY_SIZE(wfidrv_list); i++) {
+   if (wfidrv_list[i] == handler) {
+   wfidrv_list[i] = NULL;
+   return 0;
+   }
+   }
+
+   return -EINVAL;
+}
+
+static int get_id_from_handler(tstrWILC_WFIDrv *handler)
+{
+   int i;
+
+   if (!handler)
+   return 0;
+
+   for (i = 1; i < ARRAY_SIZE(wfidrv_list); i++) {
+   if (wfidrv_list[i] == handler)
+   return i;
+   }
+
+   return 0;
+}
+
+static tstrWILC_WFIDrv *get_handler_from_id(int id)
+{
+   if (id <= 0 || id > ARRAY_SIZE(wfidrv_list))
+   return NULL;
+   return wfidrv_list[id];
+}
+
 /**
  *  @brief Handle_SetChannel
  *  @detailsSending config packet to firmware to set channel
@@ -616,7 +666,8 @@ static s32 Handle_SetChannel(tstrWILC_WFIDrv *drvHandler, 
tstrHostIFSetChan *pst
 
PRINT_D(HOSTINF_DBG, "Setting channel\n");
/*Sending Cfg*/
-   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv);
+   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true,
+get_id_from_handler(pstrWFIDrv));
if (s32Error) {
PRINT_ER("Failed to set channel\n");
WILC_ERRORREPORT(s32Error, WILC_INVALID_STATE);
@@ -654,8 +705,8 @@ static s32 Handle_SetWfiDrvHandler(tstrWILC_WFIDrv 
*drvHandler,
 
/*Sending Cfg*/
 
-   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv);
-
+   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true,
+pstrHostIfSetDrvHandler->u32Address);
 
if (pstrWFIDrv == NULL)
up(&hSemDeinitDrvHandle);
@@ -699,7 +750,8 @@ static s32 Handle_SetOperationMode(tstrWILC_WFIDrv 
*drvHandler, tstrHostIfSetOpe
/*Sending Cfg*/
PRINT_INFO(HOSTINF_DBG, "pstrWFIDrv= %p\n", pstrWFIDrv);
 
-   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv);
+   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true,
+get_id_from_handler(pstrWFIDrv));
 
 
if ((pstrHostIfSetOperationMode->u32Mode) == (u32)NULL)
@@ -748,8 +800,8 @@ s32 Handle_set_IPAddress(tstrWILC_WFIDrv *drvHandler, u8 
*pu8IPAddr, u8 idx)
strWID.ps8WidVal = (u8 *)pu8IPAddr;
strWID.s32ValueSize = IP_ALEN;
 
-   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true, (u32)pstrWFIDrv);
-
+   s32Error = SendConfigPkt(SET_CFG, &strWID, 1, true,
+get_id_from_handler(pstrWFIDrv));
 
 
host_int_ge

[PATCH 0/5] staging: wilc1000: support 64bit machine and remove warnings

2015-08-20 Thread Tony Cho
This includes the remaining patches for 64bits. The driver uses the redundant
typecasting to communicate with the chipset, which causes several compile
warnings.

However, this patch uses the real data type and removes unnecessary typecasting.
Also, the driver allocates the ID value to the pointer address representing
the handlers and adds it into the data frames instead of the pointer address.
In results, the driver sends and gets the data frame to/from the chipset
together with ID value instead of pointer address as a handler. The ID value is
vaild from 0 to NUM_CONCURRENT_IFC. Only 0 value is the reserved value to
terminate a handler and to inform it to chipset.

This series of patch removes the warnings which 64 bit issue and the redundant
typecasting cause as well.

Johnny Kim (5):
  staging: wilc1000: use the real data type
  staging: wilc1000: add an argument for Handle_SetWfiDrvHandler
  staging: wilc1000: use id value as argument
  staging: wilc1000: change address to fixed value
  staging: wilc1000: define undefined operation mode

 drivers/staging/wilc1000/host_interface.c | 271 ++
 drivers/staging/wilc1000/host_interface.h |   2 +
 drivers/staging/wilc1000/linux_wlan.c |   4 +-
 drivers/staging/wilc1000/wilc_wfi_netdevice.h |   1 -
 4 files changed, 195 insertions(+), 83 deletions(-)

-- 
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: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

2015-08-20 Thread Grumbach, Emmanuel


On 08/19/2015 11:39 PM, Eric Dumazet wrote:
> On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote:
> 
>> Hm.. how would net/core/tso.c avoid this?
> 
> Because a driver using these helpers keep around the original LSO packet
> and frees it normally at TX completion time.
> 
>> I can't see anything related to truesize there.
>> Note that this work since it is guaranteed that we release the skbs in
>> order.
>>
>>>
>>> (BTW TCP packets do not have sock_wfree as destructor but tcp_wfree(),
>>> yet we want backpressure mostly for TCP stack (TCP Small Queues))
>>>
>>>
>>
>> I am not sure I follow here.
>> You want me to test:
>> if (skb_gso->destructor == tcp_wfree) ?
> 
> 
> Yes.
> 
> Look for example at tcp_gso_segment() (called from skb_gso_segment())
> 
> copy_destructor = gso_skb->destructor == tcp_wfree;
> ...
> /* Following permits TCP Small Queues to work well with GSO :
>  * The callback to TCP stack will be called at the time last frag
>  * is freed at TX completion, and not right now when gso_skb
>  * is freed by GSO engine
>  */
> if (copy_destructor) {
> swap(gso_skb->sk, skb->sk);
> swap(gso_skb->destructor, skb->destructor);
> sum_truesize += skb->truesize;
> atomic_add(sum_truesize - gso_skb->truesize,
>&skb->sk->sk_wmem_alloc);
> }
> 
> 
>>
>> I checked that code using iperf and saw that I don't get into this if,
>> but I (probably wrongly) assumed that other applications would set a
>> flag on the socket (forgive my ignorance) that would make this if be taken.
> 
> If you do not see skb->destructor == tcp_wfree, then something is
> definitely wrong on your setup.
> 

tcp_wfree isn't exported. I can change that. It will be a challenge for
backport though. Hm
--
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 17/18] NFC: trf7970a: Add OF match table

2015-08-20 Thread Javier Martinez Canillas
The Documentation/devicetree/bindings/net/nfc/trf7970a.txt DT binding doc
lists "ti,trf7970a" as a compatible string but the corresponding driver
does not have an OF match table. Add the table to the driver so the SPI
core can do an OF style match.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/nfc/trf7970a.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 85b4d86772d8..2021f2135445 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -2209,6 +2209,12 @@ static const struct dev_pm_ops trf7970a_pm_ops = {
trf7970a_pm_runtime_resume, NULL)
 };
 
+static const struct of_device_id trf7970a_of_match[] = {
+   { .compatible = "ti,trf7970a", },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, trf7970a_of_match);
+
 static const struct spi_device_id trf7970a_id_table[] = {
{ "trf7970a", 0 },
{ }
@@ -2221,6 +2227,7 @@ static struct spi_driver trf7970a_spi_driver = {
.id_table   = trf7970a_id_table,
.driver = {
.name   = "trf7970a",
+   .of_match_table = of_match_ptr(trf7970a_of_match),
.owner  = THIS_MODULE,
.pm = &trf7970a_pm_ops,
},
-- 
2.4.3

--
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 00/18] Export SPI and OF module aliases in missing drivers

2015-08-20 Thread Javier Martinez Canillas
Hello,

Short version:

This patch series is the SPI equivalent of the I2C one posted before [0].

This series add the missing MODULE_DEVICE_TABLE() for OF and SPI tables
to export that information so modules have the correct aliases built-in
and autoloading works correctly.

Longer version:

The SPI core always reports the MODALIAS uevent as "spi:"
regardless of the mechanism that was used to register the device (i.e:
OF or board code) and the table that is used later to match the driver
with the device (i.e: SPI id table or OF match table).

But this means that OF-only drivers needs to have both OF and SPI id
tables that have to be kept in sync and also the device node's compatible
manufacturer prefix is stripped when reporting the MODALIAS. Which can
lead to issues if two vendors use the same SPI device name for example.

Also, there are many SPI drivers whose module auto-loading is not working
because of this fact that the SPI core always reports the MODALIAS as
spi: and many developers didn't expect this since is not how
other subsystems behave.

I've identified SPI drivers with 3 types of different issues:

a) Those that have an spi_table but are not exported. The match works
   if the driver is built-in but since the ID table is not exported,
   module auto-load won't work.

b) Those that have a of_table but are not exported. This is currently
   not an issue since even when the of_table is used to match the dev
   with the driver, an OF modalias is not reported by the SPI core.
   But if the SPI core is changed to report the MODALIAS of the form
   of:N*T*C as it's made by other subsystems, then module auto-load
   will break for these drivers.

c) Those that don't have an of_table but should since are OF drivers
   with DT bindings doc for them. Since the SPI core does not report
   a OF modalias and since spi_match_device() fallbacks to match the
   device part of the compatible string with the SPI device ID table,
   many OF drivers don't have an of_table to match. After all having
   a SPI device ID table is mandatory so it works without a of_table.

So, in order to not make mandatory to have a SPI device ID table, all
these three kind of issues have to be addressed. This series does that.

I split the changes so the patches in this series are independent and
can be picked individually by subsystem maintainers.

Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches

Patch #18 changes the logic of spi_uevent() to report an OF modalias if
the device was registered using OF. But this patch is included in the
series only as an RFC for illustration purposes since changing that
without first applying all the other patches in this series, will break
module autoloading for the drivers of devices registered using OF but
that lacks an of_match_table. I'll repost patch #18 once all the patches
in this series have landed.

[0]: https://lkml.org/lkml/2015/7/30/519

Best regards,
Javier


Javier Martinez Canillas (18):
  iio: Export SPI module alias information in missing drivers
  staging: iio: hmc5843: Export missing SPI module alias information
  mtd: dataflash: Export OF module alias information
  OMAPDSS: panel-sony-acx565akm: Export OF module alias information
  mmc: mmc_spi: Export OF module alias information
  staging: mt29f_spinand: Export OF module alias information
  net: ks8851: Export OF module alias information
  [media] s5c73m3: Export OF module alias information
  mfd: cros_ec: spi: Add OF match table
  iio: dac: ad7303: Add OF match table
  iio: adc: max1027: Set struct spi_driver .of_match_table
  mfd: stmpe: Add OF match table
  iio: adc: mcp320x: Set struct spi_driver .of_match_table
  iio: as3935: Add OF match table
  iio: adc128s052: Add OF match table
  iio: frequency: adf4350: Add OF match table
  NFC: trf7970a: Add OF match table
  spi: (RFC, don't apply) report OF style modalias when probing using DT

 drivers/iio/adc/max1027.c   |  1 +
 drivers/iio/adc/mcp320x.c   |  1 +
 drivers/iio/adc/ti-adc128s052.c |  8 
 drivers/iio/amplifiers/ad8366.c |  1 +
 drivers/iio/dac/ad7303.c|  7 +++
 drivers/iio/frequency/adf4350.c |  9 +
 drivers/iio/proximity/as3935.c  |  7 +++
 drivers/media/i2c/s5c73m3/s5c73m3-spi.c |  1 +
 drivers/mfd/cros_ec_spi.c   |  7 +++
 drivers/mfd/stmpe-spi.c | 13 +
 drivers/mmc/host/mmc_spi.c  |  1 +
 drivers/mtd/devices/mtd_dataflash.c |  1 +
 drivers/net/ethernet/micrel/ks8851.c|  1 +
 drivers/nfc/trf7970a.c  |  7 +++
 drivers/spi/spi.c   |  8 
 drivers/s

RE: [PATCH v2 2/2] ath9k: fix incorrect calibration initial for ar9561

2015-08-20 Thread Pan, Miaoqing
Thanks Sujith.  You mentioned this before,  so need more investigation,  and 
this patch will be discarded. 

Miaoqing

-Original Message-
From: Sujith Manoharan [mailto:suj...@msujith.org] 
Sent: Thursday, August 20, 2015 11:47 AM
To: Pan, Miaoqing
Cc: linvi...@tuxdriver.com; linux-wireless@vger.kernel.org; ath9k-devel; Valo, 
Kalle
Subject: Re: [PATCH v2 2/2] ath9k: fix incorrect calibration initial for ar9561

miaoq...@qti.qualcomm.com wrote:
> - if (AR_SREV_9485(ah) || AR_SREV_9462(ah) || AR_SREV_9565(ah))
> + if (AR_SREV_9485(ah) || AR_SREV_9462(ah) || AR_SREV_9565(ah) ||
> + AR_SREV_9561(ah))
>   priv_ops->init_cal = ar9003_hw_init_cal_pcoem;
>   else
>   priv_ops->init_cal = ar9003_hw_init_cal_soc;

Are you sure about this ? AR9561 is not a PCOEM chip, IIRC.
Maybe the SoC routine is missing some code changes for AR956x ?

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