Re: [PATCH] netlink: don't send NETLINK_URELEASE for unbound sockets

[David Miller]

From: Johannes Berg 
Date: Thu,  7 Apr 2016 09:31:38 +0200

> From: Dmitry Ivanov 
> 
> All existing users of NETLINK_URELEASE use it to clean up resources that
> were previously allocated to a socket via some command. As a result, no
> users require getting this notification for unbound sockets.
> 
> Sending it for unbound sockets, however, is a problem because any user
> (including unprivileged users) can create a socket that uses the same ID
> as an existing socket. Binding this new socket will fail, but if the
> NETLINK_URELEASE notification is generated for such sockets, the users
> thereof will be tricked into thinking the socket that they allocated the
> resources for is closed.
> 
> In the nl80211 case, this will cause destruction of virtual interfaces
> that still belong to an existing hostapd process; this is the case that
> Dmitry noticed. In the NFC case, it will cause a poll abort. In the case
> of netlink log/queue it will cause them to stop reporting events, as if
> NFULNL_CFG_CMD_UNBIND/NFQNL_CFG_CMD_UNBIND had been called.
> 
> Fix this problem by checking that the socket is bound before generating
> the NETLINK_URELEASE notification.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Ivanov 
> Signed-off-by: Johannes Berg 

Applied and queued up for -stable, thanks everyone.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ath9k: Add a module parameter to invert LED polarity.

[Vittorio Gambaletta (VittGam)]

The LED can be active high instead of active low on some hardware.

Add the led_active_high module parameter. It defaults to -1 to obey
platform data as before.

Setting the parameter to 1 or 0 will force the LED respectively
active high or active low.

Cc: 
Cc: 
Cc: 
Cc: 
Signed-off-by: Vittorio Gambaletta 
---

--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -49,6 +49,10 @@ int ath9k_led_blink;
 module_param_named(blink, ath9k_led_blink, int, 0444);
 MODULE_PARM_DESC(blink, "Enable LED blink on activity");
 
+static int ath9k_led_active_high = -1;
+module_param_named(led_active_high, ath9k_led_active_high, int, 0444);
+MODULE_PARM_DESC(led_active_high, "Invert LED polarity");
+
 static int ath9k_btcoex_enable;
 module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
 MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence");
@@ -600,6 +604,9 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
if (ret)
return ret;
 
+   if (ath9k_led_active_high != -1)
+   ah->config.led_active_high = ath9k_led_active_high == 1;
+
/*
 * Enable WLAN/BT RX Antenna diversity only when:
 *

--
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] Revert regression in ath9k on AR9281

[Gustav Frederiksen]

Hi,
thank you for taking the time to answer my previous email and for 
providing those useful tips.


All the points you made are valid.
Especially, the same output of "iwconfig" was indeed pasted twice by 
mistake.


Please find a new and hopefully correct report below this message.



The following commit introduced what looks like a regression on AR9281 
and supposedly other wireless chipsets using the AR9002 part of the 
ath9k driver.
After this commit the network interface's "Bit Rate" as shown in "iw" 
drops from the usual 65Mbps in N mode to 11Mbps also in N mode.
Throughput tests confirm the slowdown. Applying and removing the commit 
toggles the problem.


Changes contained in ar9002_hw_spur_mitigate() appear responsible for 
the "Bit Rate" drop.
The provided patch reverts the change made by commit "f911085ffa88" to 
ar9002_hw_spur_mitigate() while leaving other changes unmodified.


The patch was obtained as such: "git diff origin/master f911085ffa88~1 
drivers/net/wireless/ath/ath9k/ar9002_phy.c"


Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse 
common code in ar9002_hw_spur_mitigate.") Behavior of 
ar5008_hw_cmn_spur_mitigate() differs from previous implementation in 
ar9002_hw_spur_mitigate(). Reverted changes.


Signed-off-by: Gustav Frederiksen 

---
bisection.log

Bisecting: 0 revisions left to test after this (roughly 0 steps)

[f911085ffa8863c62344876e0ab6073e4258c246] ath9k: split 
ar5008_hw_spur_mitigate and reuse common code in 
ar9002_hw_spur_mitigate.


f911085ffa8863c62344876e0ab6073e4258c246 is the first bad commit
commit f911085ffa8863c62344876e0ab6073e4258c246
Author: Oleksij Rempel 
Date: Sun May 17 21:49:19 2015 +0200

ath9k: split ar5008_hw_spur_mitigate and reuse common code in 
ar9002_hw_spur_mitigate.



[ar5008 and ar9002]_hw_spur_mitigate have big portion of identical code.

This patch will move common part of ar5008_hw_spur_mitigate to
ar5008_hw_cmn_spur_mitigate and reuse it in ar9002_hw_spur_mitigate.

As noticed by Joe Perches I reuse ar9002_hw_spur_mitigate (const) 
version of


declarations for pilot_mask_reg and chan_mask_reg.

There should be no other difference with original code.

Signed-off-by: Oleksij Rempel 
Signed-off-by: Kalle Valo 
---

---
WITH commit: 11Mbps.

root@laptop:~# uname -a
Linux laptop 4.2.0-35-generic #40~14.04.1-Ubuntu SMP Fri Mar 18 16:37:35 
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux


root@laptop:~# iw dev wlan0 link
Connected to a4:c7:**:**:**:** (on wlan0)
SSID: TEST_AP
freq: 2462
RX: 87746 bytes (518 packets)
TX: 46813 bytes (246 packets)
signal: -47 dBm
tx bitrate: 11.0 MBit/s

bss flags:  short-preamble short-slot-time
dtim period:1
beacon int: 400

root@laptop:~# wget "http://proof.ovh.net/files/1Gio.dat; -O /dev/null
--2016-04-11 02:38:10--  http://proof.ovh.net/files/1Gio.dat
Resolving proof.ovh.net (proof.ovh.net)... 188.165.12.106, 
2001:41d0:2:876a::1
Connecting to proof.ovh.net (proof.ovh.net)|188.165.12.106|:80... 
connected.

HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1.0G) [application/octet-stream]
Saving to: '/dev/null'

 3% [=>  
   ] 39 762 450   778KB/s  eta 23m 15s^C


root@laptop:~# iw phy0 info
Wiphy phy0
Band 1:
Capabilities: 0x11ce
HT20/HT40
SM Power Save disabled
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT RX MCS rate indexes supported: 0-15
TX unequal modulation not supported
HT TX Max spatial streams: 1
HT TX MCS rate indexes supported may differ
Frequencies:
* 2412 MHz [1] (27.0 dBm)
* 2417 MHz [2] (27.0 dBm)
* 2422 MHz [3] (27.0 dBm)
* 2427 MHz [4] (27.0 dBm)
* 2432 MHz [5] (27.0 dBm)
* 2437 MHz [6] (27.0 dBm)
* 2442 MHz [7] (27.0 dBm)
* 2447 MHz [8] (27.0 dBm)
* 2452 MHz [9] (27.0 dBm)
* 2457 MHz [10] (27.0 dBm)
* 2462 MHz [11] (27.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short 

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

[Julian Calaby]

Hi Andrea,

On Sat, Apr 9, 2016 at 4:56 AM, Andrea Merello  wrote:
>
> On Fri, Mar 18, 2016 at 3:27 AM, Julian Calaby 
> wrote:
>> From: Jia-Ju Bai 
>>
>> When dev_alloc_skb or pci_dma_mapping_error in rtl8180_init_rx_ring fails,
>> the memory allocated by pci_zalloc_consistent is not freed.
>>
>> This patch fixes the bug by adding pci_free_consistent
>> in error handling code.
>>
>> Signed-off-by: Jia-Ju Bai 
>> Signed-off-by: Julian Calaby 
>>
>> ---
>>
>> Could someone else please review this?
>
> This patch does address one leak, but the piece of code it changes is
> totally leaky and IMHO it probably needs to be reworked more deeply, maybe
> in a single shot. This is why I didn't acked the patch.

Ugh.

I can't work on this as I don't have hardware to test it with, could
you (or someone who does) please have a good look at this section of
the Realtek drivers (I see a lot of this pattern repeated in them) and
craft (a) patch(es) to fix this properly?

> BTW if you feel that this could be better than nothing, please feel free to
> apply it :).

IMHO this patch makes things better in that there's less options for a
leak, however I marked this as "morework" as it clearly doesn't solve
the _entire_ problem.

I feel it should be applied as it does make it better, however this
isn't my driver and I'd appreciate a nod of approval from someone who
knows it better than I do.

>> In particular, immediately after the call to pci_zalloc_coherent(), it
>> fails if the result is null or if '(unsigned long)result & 0xFF'.
>>
>> Is the second arm of the or statement possible, and if so, should we be
>> pci_free_coherent()ing the result there too?
>
> I honestly don't know if the coherent allocator is supposed to always return
> page-aligned memory areas (I'm assuming a page wouldn't be smaller than 256
> bytes); AFAIK no one ever hit that.
>
> If there are cases/archs where it can  really happen, then allocating an
> oversized memory area, and providing to the HW an aligned pointer inside
> that area, may be the way to go (IIRC calling pci_set_consistent_dma_mask()
> with 0xFF00 does not provides any benefit, but again, I'm not sure).

I believe that calling *_set_*_dma_mask() is how it's supposed to be
done. If this isn't working, then that's a bug elsewhere. IMHO drivers
should be able to say "we need a DMA address like *this*" and it's the
PCI / DMA code's responsibility to either provide a compatible one or
fail. Drivers shouldn't be working around bugs in the services they
use.

> Either way, If we do that, or if we can trust that it does never really
> happen, then we can drop the check (or maybe just change it in a BUG_ON()
> just to be paranoid).

A WARN_ON() and failing gracefully would be the ideal way to do this
IMHO, however it really shouldn't be necessary.

> To address your question - if we let this check stay there - then of course
> we need to take care of freeing the memory whenever the allocator succeeds
> but that check fails.

I'll craft a followup patch to add a WARN_ON(), free the memory and
fail in this case.

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

I guess if we got an address like 0x.048 then we could arguably
just tell the hardware we start at 0x.100, however that's a
terrible solution. This really needs to be addressed at the "source"
i.e. informing the allocator what our requirements are and if it
doesn't produce correct results, fixing it, not working around it in
the driver.

Thanks,

-- 
Julian Calaby

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

RE: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Grumbach, Emmanuel]

> On Tue, Apr 5, 2016 at 4:34 PM, Grumbach, Emmanuel
>  wrote:
> > On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote:
> >> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
> >>  wrote:
> >> > >
> >> > > Hello,
> >> > >
> >> > > I am trying to capture packets that are exchanged between an AP
> >> > > and a smartphone on the 5Ghz frequency. For generating traffic, I
> >> > > upload UDP traffic from a laptop PC towards the smartphone using
> >> > > iperf.
> >> > >
> >> > > The problem is that I can see _only_ the control frames like
> >> > > RTS/CTS, Block ACK, while the data packets are not captured. I
> >> > > uploaded the Wireshark capture files at [1] (located inside the
> >> > > folders whose name starts with 5Ghz).
> >> >
> >> > Most likely the packets on A band have a VHT preamble and your SKU
> >> > is 11N only.
> >>
> >> My card, Intel 7260 [1]  supports 802.11 ac. So it should also
> >> support VHT, right? Is there any interface in user-space for checking
> >> after VHT?
> >
> > 7260 has several flavors. The one you have doesn't support VHT:
> >> iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless N 7260
> >
> > Dual Band means you have support for 5.2GHz, but Wireless N, means no
> > VHT.
> 
> One of my colleagues had an Intel 7260 AC card so I repeated the
> experiments:
> - if I set the channel width to 20Mhz from the AP and the monitor interface
> using the command iw wlan0 set freq 5240 HT20+ I can see data frames and
> the Block ACKs for these frames;
> - if I set the channel width to 40Mhz from the AP and the monitor interface
> using the command iw wlan0 set freq 5240 HT40- I can see data frames and
> the Block ACKs for these frames;
> - If I set the channel width to 80Mhz from the AP I don't how to set up the
> monitor interface. I tried with iw wlan0 set freq 5240 HT40+ but it tells me
> that the argument is invalid.
> 
> Is the iwlwifi driver capable of capturing data frames when the channel
> bonding is set to 80Mhz?

dev  set freq  [20|40|80|80+80|160] [] 
[]

You can take center_freq1 from the output of iw dev on a device that is 
associated to the same AP.

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Andrew Worsley]

Further testing Broadcom 4331 reset quirk to prevent IRQ storm patch
testing reveals that:
  1. quirk is run on initial boot up and this time appears to have
vastly reduced the interrupts (only 81 this time):
cat /proc/interrupts| grep 17
 17: 81  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel

 2. But it is apparently *NOT* run after a suspend/resume and we get
the problem:
 17: 100084  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel

Rebooting a further nine times shows the low number (below 100) only
happens around 1/3 of the times:
boot #2
 17:  38706  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel
boot #3
 17: 87  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel
LOC:   2494   2031   2094   1831   1157   1171
  1573   1271   Local timer interrupts
boot #4
 17:  50616  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel
boot#5
 17:  26454  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel
boot#6
 17:  34440  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel
boot#7
 17: 79  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel
boot#8
 17: 84  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel
boot#9
 17:  37054  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel
boot#10
 17:  24648  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel

 Is there an easy setpci command to stop this we can add to grub?

Presently I have a grub work around for black screen as described here:
  
http://askubuntu.com/questions/264247/proprietary-nvidia-drivers-with-efi-on-mac-to-prevent-overheating/613573#613573

which basically involves adding a grub scriptlet to enable PCI-E bus
mastering on graphics cards:

In /etc/grub.d/01_enable_vga.conf:

setpci -s "00:01.0" 3e.b=8
setpci -s "01:00.0" 04.b=7

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

  lspci | grep 4331
04:00.0 Network controller: Broadcom Corporation BCM4331 802.11a/b/g/n (rev 02)



On 7 April 2016 at 22:04, Andrew Worsley  wrote:
> Sorry but testing the patch shows no difference.
>
> I have just compiled debian jessie kernel 3.16.7-ckt25 and booted it
> and hibernated it twice, then did the same with your patch applied.
> There appeared to be no difference
>


Thanks for any suggestions

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

Re: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Gucea Doru]

On Tue, Apr 5, 2016 at 4:34 PM, Grumbach, Emmanuel
 wrote:
> On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote:
>> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
>>  wrote:
>> > >
>> > > Hello,
>> > >
>> > > I am trying to capture packets that are exchanged between an AP
>> > > and a
>> > > smartphone on the 5Ghz frequency. For generating traffic, I
>> > > upload UDP
>> > > traffic from a laptop PC towards the smartphone using iperf.
>> > >
>> > > The problem is that I can see _only_ the control frames like
>> > > RTS/CTS, Block
>> > > ACK, while the data packets are not captured. I uploaded the
>> > > Wireshark
>> > > capture files at [1] (located inside the folders whose name
>> > > starts with 5Ghz).
>> >
>> > Most likely the packets on A band have a VHT preamble and your SKU
>> > is 11N only.
>>
>> My card, Intel 7260 [1]  supports 802.11 ac. So it should also
>> support
>> VHT, right? Is there any interface in user-space for checking after
>> VHT?
>
> 7260 has several flavors. The one you have doesn't support VHT:
>> iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless N 7260
>
> Dual Band means you have support for 5.2GHz, but Wireless N, means no
> VHT.

One of my colleagues had an Intel 7260 AC card so I repeated the experiments:
- if I set the channel width to 20Mhz from the AP and the monitor
interface using the command iw wlan0 set freq 5240 HT20+ I can see
data frames and the Block ACKs for these frames;
- if I set the channel width to 40Mhz from the AP and the monitor
interface using the command iw wlan0 set freq 5240 HT40- I can see
data frames and the Block ACKs for these frames;
- If I set the channel width to 80Mhz from the AP I don't how to set
up the monitor interface. I tried with iw wlan0 set freq 5240 HT40+
but it tells me that the argument is invalid.

Is the iwlwifi driver capable of capturing data frames when the
channel bonding is set to 80Mhz?

>
>>
>> However, I noticed a "failure" message in dmesg:
>> [4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
>> [4.030570] iwlwifi :04:00.0: irq 37 for MSI/MSI-X
>> [4.030760] iwlwifi :04:00.0: Direct firmware load for
>> iwlwifi-7260-10.ucode failed with error -2
>> [4.035509] iwlwifi :04:00.0: loaded firmware version
>> 25.228.9.0 op_mode iwlmvm
>> [4.454772] iwlwifi :04:00.0: Detected Intel(R) Dual Band
>> Wireless N 7260, REV=0x144
>> [4.454825] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>> [4.455055] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>> [   15.049933] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>> [   15.050269] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
>>
>> Also, the maximum bit rate reported by iwconfig is 150 Mb/s, so my
>> assumption is that the card can't enter into the 802.11 ac mode, it
>> just stays into 802.11n.
>>
>> doru@doru-N551JK:~$ iwconfig wlan0
>> wlan0 IEEE 802.11abgn  ESSID:"5_mptcp"
>>   Mode:Managed  Frequency:5.24 GHz  Access Point:
>> C4:6E:1F:4B:10:A2
>>   Bit Rate=150 Mb/s   Tx-Power=22 dBm
>>   Retry short limit:7   RTS thr:off   Fragment thr:off
>>   Power Management:on
>>   Link Quality=70/70  Signal level=-36 dBm
>>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>>   Tx excessive retries:0  Invalid misc:22   Missed beacon:0
>>
>>
>> [1] http://www.intel.com/content/www/us/en/wireless-products/dual-ban
>> d-wireless-ac-7260-bluetooth-brief.html
>>
>> > Another option is that the traffic uses LDPC encoding and this
>> > device doesn't support it.
>> >
>> >
>> > >
>> > > If I use the 2.4 frequency, all the frames are captured. I also
>> > > uploaded the
>> > > Wireshark packet traces for 2.4Ghz at [1] (located inside the
>> > > folders whose
>> > > name starts with 2.4 Ghz).
>> > >
>> > > Is this a known bug or am I doing something wrong?
>> > >
>> > > Additional details:
>> > > Wi-Fi card:  iwlwifi :04:00.0: Detected Intel(R) Dual Band
>> > > Wireless N 7260,
>> > > REV=0x144 Firmware version: iwlwifi :04:00.0: loaded firmware
>> > > version
>> > > 25.228.9.0 op_mode iwlmvm
>> > > Traffic encryption: WPA & WPA2 Personal
>> > > Setting up the card in wireless mode:
>> > > ip link set dev wlan0 down
>> > > iw wlan0 set type monitor
>> > > ip link set dev wlan0 up
>> > > iw wlan0 set freq 5240
>> > >
>> > > [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
>> > >
>> > > Thank you, Doru
--
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

[PATCHv2] wlcore: spi: add wl18xx support

[Reizer, Eyal]

Add support for using with both wl12xx and wl18xx.

- all wilink family needs special init command for entering wspi mode.
  extra clock cycles should be sent after the spi init command while the
  cs pin is high.
- switch to controling the cs pin from the spi driver for achieveing the
  above.
- the selected cs gpio is read from the spi device-tree node using the
  cs-gpios field and setup as a gpio.
- See the example below for specifying the cs gpio using the cs-gpios entry
   {
...
cs-gpios = < 5 0>;
...
wlcore: wlcore@0 {
compatible = "ti,wl1835";
...
...
};
};

Signed-off-by: Eyal Reizer 
---
v1 -> v2: update device tree bindings documentation

 .../bindings/net/wireless/ti,wlcore,spi.txt|   50 +-
 drivers/net/wireless/ti/wlcore/spi.c   |  176 +---
 2 files changed, 200 insertions(+), 26 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..912ab0c 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,31 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
 
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
 document describes the binding for the SPI connected chip.
 
 Required properties:
-- compatible :  Should be "ti,wl1271"
+- compatible :  Should be one of the following:
+* "ti,wl1271"
+* "ti,wl1273"
+* "ti,wl1281"
+* "ti,wl1283"
+* "ti,wl1801"
+* "ti,wl1805"
+* "ti,wl1807"
+* "ti,wl1831"
+* "ti,wl1835"
+* "ti,wl1837"
 - reg : Chip select address of device
 - spi-max-frequency :   Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
 - interrupt-parent, interrupts :
 Should contain parameters for 1 interrupt line.
 Interrupt parameters: parent, line number, type.
-- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+- vwlan-supply :Point the node of the regulator that powers/enable the
+wl12xx/wl18xx chip
+- cs-gpios :GPIO pin used as the spi chip select
 
 Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
 - clock-xtal :  boolean, clock is generated from XTAL
 
 - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,10 +33,16 @@ Optional properties:
 
 Examples:
 
+For wl12xx family:
  {
-   wl1271@1 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   cs-gpios = < 5 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@0 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <4800>;
clock-xtal;
@@ -34,3 +52,21 @@ Examples:
vwlan-supply = <_fixed>;
};
 };
+
+For wl18xx family:
+  {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   cs-gpios = < 5 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@0 {
+   compatible = "ti,wl1835";
+   vwlan-supply = <_en_reg>;
+   spi-max-frequency = <4800>;
+   reg = <0>;
+   interrupt-parent = <>;
+   interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+   };
+};
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index 020ac1a..fb48a0d 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "wlcore.h"
 #include "wl12xx_80211.h"
@@ -70,16 +71,30 @@
 #define WSPI_MAX_CHUNK_SIZE4092
 
 /*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
  */
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
 
 /* Maximum number of SPI write chunks */
 #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
 
 
+struct wilink_familiy_data {
+   char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+   .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+   .name = "wl12xx",
+};
+
 struct wl12xx_spi_glue {
struct device