Re: pull-request: iwlwifi 2017-11-19

2017-11-28 Thread Sedat Dilek 
On Tue, Nov 21, 2017 at 11:10 AM, Luca Coelho  wrote:
> On Tue, 2017-11-21 at 10:30 +0100, Sedat Dilek wrote:
>> On Mon, Nov 20, 2017 at 12:02 PM, Luca Coelho  wrote:
>> [..]
>> > 
>> > iwlwifi: first set of fixes for 4.15
>> >
>> > * Support new FW API version of scan cmd (used in FW version 34);
>>
>> While seeing this...
>> I have here a iwlwifi-8265 hardware and have seen a recently uploaded
>> FW-version 34 in iwlwifi-firmware Git.
>> Can you explain the dependence of iwlwifi firmware-version / Linux
>> kernel-release and especially probing?
>> Currently, I am using Linux v4.14 from Debian/experimental.
>
> Mostly for backwards-compatibility, the driver is able to work with a
> range of firmware versions.  It only uses one of them at a time (i.e.
> the highest supported version it finds).
>
> The driver in v4.14 support version 34 and below.  So it starts looking
> for that one and, if not found, falls back to the next lower version
> (i.e. 33) and so on, until it finds one.
>

Isn't Linux v4.14.3 (here: -rc1) minimum to completely support new
features in v34 firmware?

"iwlwifi: mvm: support version 7 of the SCAN_REQ_UMAC FW command"
commit dac4df1c5f2c34903f61b1bc4fc722e31b4199e7 upstream.

- Sedat -

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-4.14.y=930929379cc8f92275675fb27e572c4d539f6b8a

RE: [PATCH] ath10k: handling qos at STA side based on AP WMM enable/disable

2017-11-28 Thread Balaji Pothunoori 
Hi Sebastian,

If I am not wrong you are seeing the issue with WRT3200ACM (Marvell 88W8964) as 
client + QCA9984 (FW : 10.4-3.5.3-00038) as AP with below change you are seeing 
the crash while running traffic between the WRT3200ACM + QCA9984 ?
Do you used  any other client in place of WRT3200ACM ?
Can you share the more details on firmware crash ?

Regards,
Balaji.

-Original Message-
From: Sebastian Gottschall [mailto:s.gottsch...@dd-wrt.com] 
Sent: Wednesday, November 29, 2017 8:28 AM
To: Balaji Pothunoori ; ath...@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] ath10k: handling qos at STA side based on AP WMM 
enable/disable

did you notice  that Marvell 88W8964 based clients will crash 10.4-3.5.3 
firmwares?  (tested with 9984 and 10.4-3.5.3-00038) client device was a linksys 
wrt3200acm running dd-wrt for testing

Am 28.11.2017 um 11:07 schrieb bpoth...@qti.qualcomm.com:
> From: Balaji Pothunoori 
>
> Data packets are not sent by STA in case of STA joined to non QOS AP 
> (WMM disabled AP). This is happening because of STA is sending data 
> packets to firmware from host with qos enabled along with non qos 
> queue value(TID = 16).
> Due to qos enabled, firmware is discarding the packet.
>
> This patch fixes this issue by updating the qos based on station WME 
> capability field if WMM is disabled in AP.
>
> This patch is required by 10.4 family chipsets like 
> QCA4019/QCA9888/QCA9884/QCA99X0.
> Firmware Versoin : 10.4-3.5.1-00018.
>
> For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch has 
> no effect.
>
> Signed-off-by: Balaji Pothunoori 
> ---
>   drivers/net/wireless/ath/ath10k/mac.c |2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 0a947ee..2616b99 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
>   }
>   break;
>   case WMI_VDEV_TYPE_STA:
> - if (vif->bss_conf.qos)
> + if (sta->wme)
>   arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
>   break;
>   case WMI_VDEV_TYPE_IBSS:


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH] ath10k: handling qos at STA side based on AP WMM enable/disable

2017-11-28 Thread Sebastian Gottschall 
did you notice  that Marvell 88W8964 based clients will crash 10.4-3.5.3 
firmwares?  (tested with 9984 and 10.4-3.5.3-00038)

client device was a linksys wrt3200acm running dd-wrt for testing

Am 28.11.2017 um 11:07 schrieb bpoth...@qti.qualcomm.com:

From: Balaji Pothunoori 

Data packets are not sent by STA in case of STA joined to
non QOS AP (WMM disabled AP). This is happening because of STA
is sending data packets to firmware from host with qos enabled
along with non qos queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.

This patch fixes this issue by updating the qos based on station
WME capability field if WMM is disabled in AP.

This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.

For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
has no effect.

Signed-off-by: Balaji Pothunoori 
---
  drivers/net/wireless/ath/ath10k/mac.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947ee..2616b99 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
}
break;
case WMI_VDEV_TYPE_STA:
-   if (vif->bss_conf.qos)
+   if (sta->wme)
arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
break;
case WMI_VDEV_TYPE_IBSS:



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c: Odd array size

2017-11-28 Thread Joe Perches 
(adding the original submitter: Andrea Merello)

On Tue, 2017-11-28 at 14:39 -0600, Larry Finger wrote:
> On 11/28/2017 10:49 AM, Joe Perches wrote:
> > 61 entries in this table:
> > 
> > static const u8 OFDM_CONFIG[] = {
> > 0x10, 0x0F, 0x0A, 0x0C, 0x14, 0xFA, 0xFF, 0x50,
> > 0x00, 0x50, 0x00, 0x00, 0x00, 0x5C, 0x00, 0x00,
> > 0x40, 0x00, 0x40, 0x00, 0x00, 0x00, 0xA8, 0x26,
> > 0x32, 0x33, 0x06, 0xA5, 0x6F, 0x55, 0xC8, 0xBB,
> > 0x0A, 0xE1, 0x2C, 0x4A, 0x86, 0x83, 0x34, 0x00,
> > 0x4F, 0x24, 0x6F, 0xC2, 0x03, 0x40, 0x80, 0x00,
> > 0xC0, 0xC1, 0x58, 0xF1, 0x00, 0xC4, 0x90, 0x3e,
> > 0xD8, 0x3C, 0x7B, 0x10, 0x10
> > };
> > 
> > but only 60 written?
> > 
> > static void rtl8187se_write_ofdm_config(struct ieee80211_hw *dev)
> > {
> > /* write OFDM_CONFIG table */
> > int i;
> > 
> > for (i = 0; i < 60; i++)
> > rtl8225se_write_phy_ofdm(dev, i, OFDM_CONFIG[i]);
> > 
> > }
> > 
> > This is the only use of OFDM_CONFIG.
> > 
> > What is the defect here?
> > 
> > Should 60 be ARRAY_SIZE(OFDM_CONFIG) or should the array be shortened?
> > 
> > One too many entries or one too few a write?
> > My guess would be one too few a write.
> 
> Joe,
> 
> You are probably right; however, as I do not have this device and cannot 
> test, 
> the safer thing would be to crop the array back to 60 entries. That way the 
> driver's behavior does not change.

I'd guess the safest change would be adding a comment
and not making a code change at all.

cheers, Joe

Re: drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c: Odd array size

2017-11-28 Thread Larry Finger 

On 11/28/2017 10:49 AM, Joe Perches wrote:

61 entries in this table:

static const u8 OFDM_CONFIG[] = {
0x10, 0x0F, 0x0A, 0x0C, 0x14, 0xFA, 0xFF, 0x50,
0x00, 0x50, 0x00, 0x00, 0x00, 0x5C, 0x00, 0x00,
0x40, 0x00, 0x40, 0x00, 0x00, 0x00, 0xA8, 0x26,
0x32, 0x33, 0x06, 0xA5, 0x6F, 0x55, 0xC8, 0xBB,
0x0A, 0xE1, 0x2C, 0x4A, 0x86, 0x83, 0x34, 0x00,
0x4F, 0x24, 0x6F, 0xC2, 0x03, 0x40, 0x80, 0x00,
0xC0, 0xC1, 0x58, 0xF1, 0x00, 0xC4, 0x90, 0x3e,
0xD8, 0x3C, 0x7B, 0x10, 0x10
};

but only 60 written?

static void rtl8187se_write_ofdm_config(struct ieee80211_hw *dev)
{
/* write OFDM_CONFIG table */
int i;

for (i = 0; i < 60; i++)
rtl8225se_write_phy_ofdm(dev, i, OFDM_CONFIG[i]);

}

This is the only use of OFDM_CONFIG.

What is the defect here?

Should 60 be ARRAY_SIZE(OFDM_CONFIG) or should the array be shortened?

One too many entries or one too few a write?
My guess would be one too few a write.


Joe,

You are probably right; however, as I do not have this device and cannot test, 
the safer thing would be to crop the array back to 60 entries. That way the 
driver's behavior does not change.


I looked to see if rtl8187 had a similar construct, but it does not.

Larry

Re: Slow connection with rtl8xxxu and 8192eu chipset

2017-11-28 Thread Jes Sorensen 
On 11/28/2017 11:49 AM, Nikolay Borisov wrote:
> 
> 
> On 28.11.2017 18:35, Jes Sorensen wrote:
>> On 11/28/2017 11:26 AM, Nikolay Borisov wrote:
>>>
>>>
>>> On 28.11.2017 18:16, Jes Sorensen wrote:
 On 11/14/2017 05:39 AM, Nikolay Borisov wrote:
>
>
> I just tested with verbatim 4.14 and even though the wireless works, 
> iwconfig reports something strange: 
>
> iwconfig wifi1
> wifi1 no wireless extensions.
>
> However, my device works as expected (albeit still slow): 
>
> wifi1 Link encap:Ethernet  HWaddr 18:d6:c7:0d:47:3c  
>   inet addr:10.20.1.175  Bcast:10.20.1.255  Mask:255.255.255.0
>   inet6 addr: fe80::281d:5f27:eb1b:8ded/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:38903 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:24689 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:51524413 (51.5 MB)  TX bytes:5503039 (5.5 MB)

 iwconfig has been deprecated for a decade, but maybe you could elaborate
 on what you feel is strange in this output?
>>>
>>> Well there are 2 things:
>>>
>>> 1. The low bitrate - which I've confirmed doing actual data test, ie,
>>> not just the number but the fact that the speeds are low.
>>>
>>> 2. The worse signal level/link quality.
>>
>> I don't see either of those in the iwconfig output
>>
>> The low TX bitrate is a known issue. Somehow the firmware rate handling
>> doesn't seem to work (or it works differently than I assumed) similar to
>> for the 8188eu. It's something I need to figure out when I have some time.
>>
>> As for link quality is this something you measured or read out of 'iw' ?
> 
> Well there is:
> 
> Link Quality=26/70  Signal level=-84 dBm < - with rtl8xxxu driver
> 
> Link Quality=81/100  Signal level=100/100  Noise level=0/100 <-- with
> vendor's driver. Another vector was the icon of network manager had only
> 2 bars with the in-tree driver and had full bars with out (yeah, this is
> a bit subjective metric but it's the best i've got).

OK, the link reporting from rtl8xxxu isn't complete, so I wouldn't put
too much into this.

Cheers,
Jes

drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c: Odd array size

2017-11-28 Thread Joe Perches 
61 entries in this table:

static const u8 OFDM_CONFIG[] = {
0x10, 0x0F, 0x0A, 0x0C, 0x14, 0xFA, 0xFF, 0x50,
0x00, 0x50, 0x00, 0x00, 0x00, 0x5C, 0x00, 0x00,
0x40, 0x00, 0x40, 0x00, 0x00, 0x00, 0xA8, 0x26,
0x32, 0x33, 0x06, 0xA5, 0x6F, 0x55, 0xC8, 0xBB,
0x0A, 0xE1, 0x2C, 0x4A, 0x86, 0x83, 0x34, 0x00,
0x4F, 0x24, 0x6F, 0xC2, 0x03, 0x40, 0x80, 0x00,
0xC0, 0xC1, 0x58, 0xF1, 0x00, 0xC4, 0x90, 0x3e,
0xD8, 0x3C, 0x7B, 0x10, 0x10
};

but only 60 written?

static void rtl8187se_write_ofdm_config(struct ieee80211_hw *dev)
{
/* write OFDM_CONFIG table */
int i;

for (i = 0; i < 60; i++)
rtl8225se_write_phy_ofdm(dev, i, OFDM_CONFIG[i]);

}

This is the only use of OFDM_CONFIG.

What is the defect here?

Should 60 be ARRAY_SIZE(OFDM_CONFIG) or should the array be shortened?

One too many entries or one too few a write?
My guess would be one too few a write.

Re: Slow connection with rtl8xxxu and 8192eu chipset

2017-11-28 Thread Nikolay Borisov 


On 28.11.2017 18:35, Jes Sorensen wrote:
> On 11/28/2017 11:26 AM, Nikolay Borisov wrote:
>>
>>
>> On 28.11.2017 18:16, Jes Sorensen wrote:
>>> On 11/14/2017 05:39 AM, Nikolay Borisov wrote:


 On 14.11.2017 11:26, Nikolay Borisov wrote:
> (Please CC as I'm not subscribed)
>
> Hello,
>
> I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as
>
> Bus 001 Device 003: ID 2357:0108
>
> Unfortunately with the in-kernel rtl8xxxu driver I don't get very good
> results:
>
> wifi1 IEEE 802.11  ESSID:"HOME"
>   Mode:Managed  Frequency:2.462 GHz  Access Point:
> 30:B5:C2:75:A4:CD
>   Bit Rate=1 Mb/s   Tx-Power=20 dBm
>   Retry short limit:7   RTS thr=2347 B   Fragment thr:off
>   Power Management:off
>   Link Quality=26/70  Signal level=-84 dBm
>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>   Tx excessive retries:0  Invalid misc:165   Missed beacon:0
>
>
> At the same time if I use an out of tree driver acquired from github:
> https://github.com/Mange/rtl8192eu-linux-driver I get the following:
>
> wifi1 IEEE 802.11bgn  ESSID:"HOME"  Nickname:""
>   Mode:Managed  Frequency:2.462 GHz  Access Point:
> 30:B5:C2:75:A4:CD
>   Bit Rate:144.4 Mb/s   Sensitivity:0/0
>   Retry:off   RTS thr:off   Fragment thr:off
>   Power Management:off
>   Link Quality=81/100  Signal level=100/100  Noise level=0/100
>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>   Tx excessive retries:0  Invalid misc:0   Missed beacon:0
>
> Clearly this is a software problem of the in-kernel driver. I'm using
> v4.10.17 with commit c14239f23adb ("rtl8xxxu: Add another 8192eu device
> to the USB list") so that my device is recognised. Latest commit for
> that driver in my kernel is: c59f13bbead4 ("rtl8xxxu: Work around issue
> with 8192eu and 8723bu devices not reconnecting").
>
> Any ideas what I can do to further debug this, I'd really like to use
> the in-kernel driver ?

 I just tested with verbatim 4.14 and even though the wireless works, 
 iwconfig reports something strange: 

 iwconfig wifi1
 wifi1 no wireless extensions.

 However, my device works as expected (albeit still slow): 

 wifi1 Link encap:Ethernet  HWaddr 18:d6:c7:0d:47:3c  
   inet addr:10.20.1.175  Bcast:10.20.1.255  Mask:255.255.255.0
   inet6 addr: fe80::281d:5f27:eb1b:8ded/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:38903 errors:0 dropped:0 overruns:0 frame:0
   TX packets:24689 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000 
   RX bytes:51524413 (51.5 MB)  TX bytes:5503039 (5.5 MB)
>>>
>>> iwconfig has been deprecated for a decade, but maybe you could elaborate
>>> on what you feel is strange in this output?
>>
>> Well there are 2 things:
>>
>> 1. The low bitrate - which I've confirmed doing actual data test, ie,
>> not just the number but the fact that the speeds are low.
>>
>> 2. The worse signal level/link quality.
> 
> I don't see either of those in the iwconfig output
> 
> The low TX bitrate is a known issue. Somehow the firmware rate handling
> doesn't seem to work (or it works differently than I assumed) similar to
> for the 8188eu. It's something I need to figure out when I have some time.
> 
> As for link quality is this something you measured or read out of 'iw' ?

Well there is:

Link Quality=26/70  Signal level=-84 dBm < - with rtl8xxxu driver

Link Quality=81/100  Signal level=100/100  Noise level=0/100 <-- with
vendor's driver. Another vector was the icon of network manager had only
2 bars with the in-tree driver and had full bars with out (yeah, this is
a bit subjective metric but it's the best i've got).

> 
> Thanks,
> Jes
>

Re: Slow connection with rtl8xxxu and 8192eu chipset

2017-11-28 Thread Jes Sorensen 
On 11/28/2017 11:26 AM, Nikolay Borisov wrote:
> 
> 
> On 28.11.2017 18:16, Jes Sorensen wrote:
>> On 11/14/2017 05:39 AM, Nikolay Borisov wrote:
>>>
>>>
>>> On 14.11.2017 11:26, Nikolay Borisov wrote:
 (Please CC as I'm not subscribed)

 Hello,

 I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as

 Bus 001 Device 003: ID 2357:0108

 Unfortunately with the in-kernel rtl8xxxu driver I don't get very good
 results:

 wifi1 IEEE 802.11  ESSID:"HOME"
   Mode:Managed  Frequency:2.462 GHz  Access Point:
 30:B5:C2:75:A4:CD
   Bit Rate=1 Mb/s   Tx-Power=20 dBm
   Retry short limit:7   RTS thr=2347 B   Fragment thr:off
   Power Management:off
   Link Quality=26/70  Signal level=-84 dBm
   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
   Tx excessive retries:0  Invalid misc:165   Missed beacon:0


 At the same time if I use an out of tree driver acquired from github:
 https://github.com/Mange/rtl8192eu-linux-driver I get the following:

 wifi1 IEEE 802.11bgn  ESSID:"HOME"  Nickname:""
   Mode:Managed  Frequency:2.462 GHz  Access Point:
 30:B5:C2:75:A4:CD
   Bit Rate:144.4 Mb/s   Sensitivity:0/0
   Retry:off   RTS thr:off   Fragment thr:off
   Power Management:off
   Link Quality=81/100  Signal level=100/100  Noise level=0/100
   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
   Tx excessive retries:0  Invalid misc:0   Missed beacon:0

 Clearly this is a software problem of the in-kernel driver. I'm using
 v4.10.17 with commit c14239f23adb ("rtl8xxxu: Add another 8192eu device
 to the USB list") so that my device is recognised. Latest commit for
 that driver in my kernel is: c59f13bbead4 ("rtl8xxxu: Work around issue
 with 8192eu and 8723bu devices not reconnecting").

 Any ideas what I can do to further debug this, I'd really like to use
 the in-kernel driver ?
>>>
>>> I just tested with verbatim 4.14 and even though the wireless works, 
>>> iwconfig reports something strange: 
>>>
>>> iwconfig wifi1
>>> wifi1 no wireless extensions.
>>>
>>> However, my device works as expected (albeit still slow): 
>>>
>>> wifi1 Link encap:Ethernet  HWaddr 18:d6:c7:0d:47:3c  
>>>   inet addr:10.20.1.175  Bcast:10.20.1.255  Mask:255.255.255.0
>>>   inet6 addr: fe80::281d:5f27:eb1b:8ded/64 Scope:Link
>>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>   RX packets:38903 errors:0 dropped:0 overruns:0 frame:0
>>>   TX packets:24689 errors:0 dropped:0 overruns:0 carrier:0
>>>   collisions:0 txqueuelen:1000 
>>>   RX bytes:51524413 (51.5 MB)  TX bytes:5503039 (5.5 MB)
>>
>> iwconfig has been deprecated for a decade, but maybe you could elaborate
>> on what you feel is strange in this output?
> 
> Well there are 2 things:
> 
> 1. The low bitrate - which I've confirmed doing actual data test, ie,
> not just the number but the fact that the speeds are low.
> 
> 2. The worse signal level/link quality.

I don't see either of those in the iwconfig output

The low TX bitrate is a known issue. Somehow the firmware rate handling
doesn't seem to work (or it works differently than I assumed) similar to
for the 8188eu. It's something I need to figure out when I have some time.

As for link quality is this something you measured or read out of 'iw' ?

Thanks,
Jes

Re: Slow connection with rtl8xxxu and 8192eu chipset

2017-11-28 Thread Nikolay Borisov 


On 28.11.2017 18:16, Jes Sorensen wrote:
> On 11/14/2017 05:39 AM, Nikolay Borisov wrote:
>>
>>
>> On 14.11.2017 11:26, Nikolay Borisov wrote:
>>> (Please CC as I'm not subscribed)
>>>
>>> Hello,
>>>
>>> I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as
>>>
>>> Bus 001 Device 003: ID 2357:0108
>>>
>>> Unfortunately with the in-kernel rtl8xxxu driver I don't get very good
>>> results:
>>>
>>> wifi1 IEEE 802.11  ESSID:"HOME"
>>>   Mode:Managed  Frequency:2.462 GHz  Access Point:
>>> 30:B5:C2:75:A4:CD
>>>   Bit Rate=1 Mb/s   Tx-Power=20 dBm
>>>   Retry short limit:7   RTS thr=2347 B   Fragment thr:off
>>>   Power Management:off
>>>   Link Quality=26/70  Signal level=-84 dBm
>>>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>>>   Tx excessive retries:0  Invalid misc:165   Missed beacon:0
>>>
>>>
>>> At the same time if I use an out of tree driver acquired from github:
>>> https://github.com/Mange/rtl8192eu-linux-driver I get the following:
>>>
>>> wifi1 IEEE 802.11bgn  ESSID:"HOME"  Nickname:""
>>>   Mode:Managed  Frequency:2.462 GHz  Access Point:
>>> 30:B5:C2:75:A4:CD
>>>   Bit Rate:144.4 Mb/s   Sensitivity:0/0
>>>   Retry:off   RTS thr:off   Fragment thr:off
>>>   Power Management:off
>>>   Link Quality=81/100  Signal level=100/100  Noise level=0/100
>>>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>>>   Tx excessive retries:0  Invalid misc:0   Missed beacon:0
>>>
>>> Clearly this is a software problem of the in-kernel driver. I'm using
>>> v4.10.17 with commit c14239f23adb ("rtl8xxxu: Add another 8192eu device
>>> to the USB list") so that my device is recognised. Latest commit for
>>> that driver in my kernel is: c59f13bbead4 ("rtl8xxxu: Work around issue
>>> with 8192eu and 8723bu devices not reconnecting").
>>>
>>> Any ideas what I can do to further debug this, I'd really like to use
>>> the in-kernel driver ?
>>
>> I just tested with verbatim 4.14 and even though the wireless works, 
>> iwconfig reports something strange: 
>>
>> iwconfig wifi1
>> wifi1 no wireless extensions.
>>
>> However, my device works as expected (albeit still slow): 
>>
>> wifi1 Link encap:Ethernet  HWaddr 18:d6:c7:0d:47:3c  
>>   inet addr:10.20.1.175  Bcast:10.20.1.255  Mask:255.255.255.0
>>   inet6 addr: fe80::281d:5f27:eb1b:8ded/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:38903 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:24689 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000 
>>   RX bytes:51524413 (51.5 MB)  TX bytes:5503039 (5.5 MB)
> 
> iwconfig has been deprecated for a decade, but maybe you could elaborate
> on what you feel is strange in this output?

Well there are 2 things:

1. The low bitrate - which I've confirmed doing actual data test, ie,
not just the number but the fact that the speeds are low.

2. The worse signal level/link quality.

> 
> The 8192eu driver has some issues, it looks like firmware rate support
> isn't working and it therefore transmits everything at low rates. I have
> to find some time to look into this.>
> Jes
>

Re: Slow connection with rtl8xxxu and 8192eu chipset

2017-11-28 Thread Jes Sorensen 
On 11/14/2017 05:39 AM, Nikolay Borisov wrote:
> 
> 
> On 14.11.2017 11:26, Nikolay Borisov wrote:
>> (Please CC as I'm not subscribed)
>>
>> Hello,
>>
>> I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as
>>
>> Bus 001 Device 003: ID 2357:0108
>>
>> Unfortunately with the in-kernel rtl8xxxu driver I don't get very good
>> results:
>>
>> wifi1 IEEE 802.11  ESSID:"HOME"
>>   Mode:Managed  Frequency:2.462 GHz  Access Point:
>> 30:B5:C2:75:A4:CD
>>   Bit Rate=1 Mb/s   Tx-Power=20 dBm
>>   Retry short limit:7   RTS thr=2347 B   Fragment thr:off
>>   Power Management:off
>>   Link Quality=26/70  Signal level=-84 dBm
>>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>>   Tx excessive retries:0  Invalid misc:165   Missed beacon:0
>>
>>
>> At the same time if I use an out of tree driver acquired from github:
>> https://github.com/Mange/rtl8192eu-linux-driver I get the following:
>>
>> wifi1 IEEE 802.11bgn  ESSID:"HOME"  Nickname:""
>>   Mode:Managed  Frequency:2.462 GHz  Access Point:
>> 30:B5:C2:75:A4:CD
>>   Bit Rate:144.4 Mb/s   Sensitivity:0/0
>>   Retry:off   RTS thr:off   Fragment thr:off
>>   Power Management:off
>>   Link Quality=81/100  Signal level=100/100  Noise level=0/100
>>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>>   Tx excessive retries:0  Invalid misc:0   Missed beacon:0
>>
>> Clearly this is a software problem of the in-kernel driver. I'm using
>> v4.10.17 with commit c14239f23adb ("rtl8xxxu: Add another 8192eu device
>> to the USB list") so that my device is recognised. Latest commit for
>> that driver in my kernel is: c59f13bbead4 ("rtl8xxxu: Work around issue
>> with 8192eu and 8723bu devices not reconnecting").
>>
>> Any ideas what I can do to further debug this, I'd really like to use
>> the in-kernel driver ?
> 
> I just tested with verbatim 4.14 and even though the wireless works, 
> iwconfig reports something strange: 
> 
> iwconfig wifi1
> wifi1 no wireless extensions.
> 
> However, my device works as expected (albeit still slow): 
> 
> wifi1 Link encap:Ethernet  HWaddr 18:d6:c7:0d:47:3c  
>   inet addr:10.20.1.175  Bcast:10.20.1.255  Mask:255.255.255.0
>   inet6 addr: fe80::281d:5f27:eb1b:8ded/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:38903 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:24689 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:51524413 (51.5 MB)  TX bytes:5503039 (5.5 MB)

iwconfig has been deprecated for a decade, but maybe you could elaborate
on what you feel is strange in this output?

The 8192eu driver has some issues, it looks like firmware rate support
isn't working and it therefore transmits everything at low rates. I have
to find some time to look into this.

Jes

Re: Wifi RTL8723bu driver test: failed to scan

2017-11-28 Thread Jes Sorensen 
On 11/22/2017 04:51 AM, Mylene JOSSERAND wrote:
> Hello Jes Sorensen,
> 
> I am currently testing a LM811 Wifi/BT USB dongle [1] on a Sinlinx
> SinA33 Allwinner SoC board [2]. I saw that I should use the realtek
> driver RTL8723BU for this USB dongle.
> 
> Currently, I am only testing the Wifi and the mainline driver (kernel
> 4.14-rc7) does not seem to work. At least, the scanning does not output
> anything.
> 
> I tested the driver recommended by LM Technologies [3] and it works
> fine (scan, connect and ping are ok). Before investigating on the
> differences between these two drivers, do you have any idea about this
> issue?
> 
> Here are the commands and output I got with mainline's driver:

I have not looked at the driver these LM Technologies people are
referring to, but I am guessing it's the vendor code.

8723bu is a little dicey because it has BT in the chip and if you enable
that the two drivers need to interact, which rtl8xxxu currently doesn't
know about. Check your dmesg output to make sure you don't have some BT
thing loaded hijacking the chip.

Jes

Re: [PATCH v3] bcma:Adjust block comments

2017-11-28 Thread Himanshu Jha 
Hi Ashish,

On Tue, Nov 28, 2017 at 09:24:58PM +0530, Ashish Kalra wrote:
> use * for block comments in multiple lines according to kernel coding
> style
> 
> Reported by: checkpatch.pl
> 
> Signed-off-by: Ashish Kalra 
> ---

Looks good now!
FWIW,

Reviewed-by: Himanshu Jha 


> Change log:
> -v3: Improvement on  commit message as per review from Morgan Freeman 
> 

BTW, this  is my secondary email subscibed
to linux-wirless as I don't want my primary email to be flooded with
frequent emails, and my upstream mail is himanshujha199...@gmail.com !



Thanks
Himanshu Jha

[PATCH v3] bcma:Adjust block comments

2017-11-28 Thread Ashish Kalra 
use * for block comments in multiple lines according to kernel coding
style

Reported by: checkpatch.pl

Signed-off-by: Ashish Kalra 
---
Change log:
-v3: Improvement on  commit message as per review from Morgan Freeman 

-v2: Improvement on  commit message as per review from Morgan Freeman 
(https://lkml.org/lkml/2017/11/27/1259)
-v1: https://lkml.org/lkml/2017/11/26/85

 drivers/bcma/driver_pcie2.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bcma/driver_pcie2.c b/drivers/bcma/driver_pcie2.c
index b1a6e327cb23..cf889fc62ac7 100644
--- a/drivers/bcma/driver_pcie2.c
+++ b/drivers/bcma/driver_pcie2.c
@@ -83,7 +83,8 @@ static void bcma_core_pcie2_hw_ltr_war(struct bcma_drv_pcie2 
*pcie2)
bcma_core_pcie2_set_ltr_vals(pcie2);
 
/* TODO:
-   si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); */
+*si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0);
+*/
 
/* enable the LTR */
devstsctr2 |= PCIE2_CAP_DEVSTSCTRL2_LTRENAB;
-- 
2.14.1

Re: [PATCH 08/11] iwlwifi: mvm: Add debugfs support for FTM initiator fields

2017-11-28 Thread Luciano Coelho 
On Tue, 2017-11-28 at 21:34 +0800, kbuild test robot wrote:
> Hi Adiel,
> 
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on wireless-drivers-next/master]
> [also build test ERROR on v4.15-rc1 next-20171128]
> [if your patch is applied to the wrong git tree, please drop us a
> note to help improve the system]
> 
> url:https://github.com/0day-ci/linux/commits/Luca-Coelho/iwlwifi-
> updates-intended-for-v4-16-2017-11-25/20171128-205312
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireles
> s-drivers-next.git master
> config: x86_64-randconfig-x011-201748 (attached as .config)
> compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All error/warnings (new ones prefixed by >>):
> 
>drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c: In function
> 'iwl_dbgfs_tof_range_request_write':
> > > drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:957:27:
> > > error: 'struct iwl_tof_range_req_cmd' has no member named
> > > 'common_calib'
> 
>mvm->tof_data.range_req.common_calib =

Ouch, for some reason I didn't have debugfs enabled in my .config and
missed this.

This patch depends on some code that is not upstream yet, so I'll just
remove it for now.

--
Cheers,
Luca.

Re: [PATCH 08/11] iwlwifi: mvm: Add debugfs support for FTM initiator fields

2017-11-28 Thread kbuild test robot 
Hi Adiel,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Luca-Coelho/iwlwifi-updates-intended-for-v4-16-2017-11-25/20171128-205312
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: x86_64-randconfig-x011-201748 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c: In function 
'iwl_dbgfs_tof_range_request_write':
>> drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:957:27: error: 'struct 
>> iwl_tof_range_req_cmd' has no member named 'common_calib'
   mvm->tof_data.range_req.common_calib =
  ^
>> drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:966:27: error: 'struct 
>> iwl_tof_range_req_cmd' has no member named 'specific_calib'
   mvm->tof_data.range_req.specific_calib =
  ^
   In file included from include/linux/byteorder/little_endian.h:5:0,
from arch/x86/include/uapi/asm/byteorder.h:5,
from include/asm-generic/bitops/le.h:6,
from arch/x86/include/asm/bitops.h:518,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:71,
from 
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:67:
   drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c: In function 
'iwl_dbgfs_tof_range_request_read':
   drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:1055:20: error: 'struct 
iwl_tof_range_req_cmd' has no member named 'common_calib'
le16_to_cpu(cmd->common_calib));
   ^
   include/uapi/linux/byteorder/little_endian.h:36:51: note: in definition of 
macro '__le16_to_cpu'
#define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
  ^
>> drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:1055:5: note: in 
>> expansion of macro 'le16_to_cpu'
le16_to_cpu(cmd->common_calib));
^~~
   drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:1057:20: error: 'struct 
iwl_tof_range_req_cmd' has no member named 'specific_calib'
le16_to_cpu(cmd->specific_calib));
   ^
   include/uapi/linux/byteorder/little_endian.h:36:51: note: in definition of 
macro '__le16_to_cpu'
#define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
  ^
   drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:1057:5: note: in 
expansion of macro 'le16_to_cpu'
le16_to_cpu(cmd->specific_calib));
^~~

vim +957 drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c

   860  
   861  static ssize_t iwl_dbgfs_tof_range_request_write(struct ieee80211_vif 
*vif,
   862   char *buf, size_t 
count,
   863   loff_t *ppos)
   864  {
   865  struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
   866  struct iwl_mvm *mvm = mvmvif->mvm;
   867  u32 value;
   868  int ret = 0;
   869  char *data;
   870  
   871  mutex_lock(>mutex);
   872  
   873  data = iwl_dbgfs_is_match("request_id=", buf);
   874  if (data) {
   875  ret = kstrtou32(data, 10, );
   876  if (ret == 0)
   877  mvm->tof_data.range_req.request_id = value;
   878  goto out;
   879  }
   880  
   881  data = iwl_dbgfs_is_match("initiator=", buf);
   882  if (data) {
   883  ret = kstrtou32(data, 10, );
   884  if (ret == 0)
   885  mvm->tof_data.range_req.initiator = value;
   886  goto out;
   887  }
   888  
   889  data = iwl_dbgfs_is_match("one_sided_los_disable=", buf);
   890  if (data) {
   891  ret = kstrtou32(data, 10, );
   892  if (ret == 0)
   893  mvm->tof_data.range_req.one_sided_los_disable = 
value;
   894  goto out;
   895  }
   896  
   897  data = iwl_dbgfs_is_match("req_timeout=", buf);
   898  if (data) {
   899  ret = kstrtou32(data, 10, );
   900

pull-request: iwlwifi 2017-11-28

2017-11-28 Thread Luca Coelho 
Hi Kalle,

Here is my second set of fixes for 4.15.  More details in the tag
description.

I have sent this out before and kbuildbot didn't find any issues. 
Please let me know if there are any issues.

Cheers,
Luca.


The following changes since commit ed59b7d53c95548d83d4e7e1bc5edafcdcad09c9:

  Merge ath-current from 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2017-11-21 
11:52:18 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2017-11-28

for you to fetch changes up to 0232d2cd7aa8e1b810fe84fb4059a0bd1eabe2ba:

  iwlwifi: fix access to prph when transport is stopped (2017-11-25 17:12:56 
+0200)


Second batch of fixes intended for 4.15.

* One fix in rate-scaling;
* One fix for the TX queue hang detection for AP/GO modes;
* Fix the TX queue hang timeout used in monitor interfaces;
* Fix packet injection;
* Remove a wrong error message when dumping PCI registers;
* Fix race condition with RF-kill;


Emmanuel Grumbach (3):
  iwlwifi: mvm: don't use transmit queue hang detection when it is not 
possible
  iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type
  iwlwifi: mvm: fix packet injection

Sara Sharon (2):
  iwlwifi: pcie: fix erroneous "Read failed message"
  iwlwifi: fix access to prph when transport is stopped

Shaul Triebitz (1):
  iwlwifi: mvm: set correct chains in Rx status

 drivers/net/wireless/intel/iwlwifi/fw/api/txq.h  |  4 
 drivers/net/wireless/intel/iwlwifi/fw/dbg.h  |  2 --
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c|  2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h |  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c |  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c|  4 +++-
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 53 
-
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c  |  3 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/utils.c   | 13 -
 drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c |  6 ++
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c  | 10 ++

signature.asc
Description: This is a digitally signed message part

Re: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2

2017-11-28 Thread Johannes Berg 
On Tue, 2017-11-28 at 09:09 -0300, Cristian wrote:
> Hello,
> 
> Linux version 4.15.0-041500rc1-generic
> 
> Report in:
> https://bugzilla.kernel.org/show_bug.cgi?id=198013
> 
> dmesg:
> [5.663292] platform regulatory.0: Direct firmware load for
> regulatory.db failed with error -2

Yeah, nothing to worry about.

Seth will publish the file, and then people can get it, but until then
it's not actually needed.

johannes

platform regulatory.0: Direct firmware load for regulatory.db failed with error -2

2017-11-28 Thread Cristian 
Hello,

Linux version 4.15.0-041500rc1-generic

Report in:
https://bugzilla.kernel.org/show_bug.cgi?id=198013

dmesg:
[5.663292] platform regulatory.0: Direct firmware load for
regulatory.db failed with error -2

Regards,
-- 
Cristian

[RFC v2] cfg80211: Implement Multiple BSSID capability in scanning

2017-11-28 Thread Jouni Malinen 
From: Peng Xu 

This extends cfg80211 BSS table processing to be able to parse Multiple
BSSID element from Beacon and Probe Response frames and to update the
BSS profiles in internal database for non-transmitted BSSs.

Signed-off-by: Peng Xu 
Signed-off-by: Jouni Malinen 
---
 net/wireless/core.h |   1 +
 net/wireless/scan.c | 450 ++--
 2 files changed, 437 insertions(+), 14 deletions(-)

v2:
- address number of comments from Johannes on the first version
- fix number of issues that came up during additional testing
- some additional cleanup on the implementation

diff --git a/net/wireless/core.h b/net/wireless/core.h
index 35165f4..3b4a566 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -139,6 +139,7 @@ extern int cfg80211_rdev_list_generation;
 struct cfg80211_internal_bss {
struct list_head list;
struct list_head hidden_list;
+   struct list_head nontrans_list;
struct rb_node rbn;
u64 ts_boottime;
unsigned long ts;
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 9f0901f..4be56b1 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -149,6 +149,7 @@ static bool __cfg80211_unlink_bss(struct 
cfg80211_registered_device *rdev,
}
 
list_del_init(>list);
+   list_del_init(>nontrans_list);
rb_erase(>rbn, >bss_tree);
rdev->bss_entries--;
WARN_ONCE((rdev->bss_entries == 0) ^ list_empty(>bss_list),
@@ -1005,6 +1006,7 @@ cfg80211_bss_update(struct cfg80211_registered_device 
*rdev,
memcpy(new, tmp, sizeof(*new));
new->refcount = 1;
INIT_LIST_HEAD(>hidden_list);
+   INIT_LIST_HEAD(>nontrans_list);
 
if (rcu_access_pointer(tmp->pub.proberesp_ies)) {
hidden = rb_find_bss(rdev, tmp, BSS_CMP_HIDE_ZLEN);
@@ -1086,18 +1088,157 @@ cfg80211_get_bss_channel(struct wiphy *wiphy, const u8 
*ie, size_t ielen,
return channel;
 }
 
+static void gen_new_bssid(const u8 *bssid, u8 max_bssid, u8 mbssid_index,
+ u8 *new_bssid_addr)
+{
+   u64 bssid_tmp, new_bssid = 0;
+   u64 lsb_n;
+
+   bssid_tmp = ether_addr_to_u64(bssid);
+
+   lsb_n = bssid_tmp & ((1 << max_bssid) - 1);
+   new_bssid = bssid_tmp;
+   new_bssid &= ~((1 << max_bssid) - 1);
+   new_bssid |= (lsb_n + mbssid_index) % (1 << max_bssid);
+
+   u64_to_ether_addr(new_bssid, new_bssid_addr);
+}
+
+static size_t gen_new_ie(const u8 *ie, size_t ielen, const u8 *subelement,
+size_t subie_len, u8 *new_ie, gfp_t gfp)
+{
+   u8 *pos, *tmp;
+   const u8 *tmp_old, *tmp_new;
+   u8 *sub_copy;
+
+   /* copy subelement as we need to change its content to
+* mark an ie after it is processed.
+*/
+   sub_copy = kmalloc(subie_len, gfp);
+   if (!sub_copy)
+   return 0;
+   memcpy(sub_copy, subelement, subie_len);
+
+   pos = _ie[0];
+
+   /* set new ssid */
+   tmp_new = cfg80211_find_ie(WLAN_EID_SSID, sub_copy, subie_len);
+   if (tmp_new) {
+   memcpy(pos, tmp_new, tmp_new[1] + 2);
+   pos += (tmp_new[1] + 2);
+   }
+
+   /* go through IEs in ie (skip SSID) and subelement,
+* merge them into new_ie
+*/
+   tmp_old = cfg80211_find_ie(WLAN_EID_SSID, ie, ielen);
+   tmp_old = (tmp_old) ? tmp_old + tmp_old[1] + 2 : ie;
+
+   while (tmp_old + tmp_old[1] + 2 - ie <= ielen) {
+   if (tmp_old[0] == 0) {
+   tmp_old++;
+   continue;
+   }
+
+   tmp = (u8 *)cfg80211_find_ie(tmp_old[0], sub_copy, subie_len);
+   if (!tmp) {
+   /* ie in old ie but not in subelement */
+   if (tmp_old[0] != WLAN_EID_MULTIPLE_BSSID) {
+   memcpy(pos, tmp_old, tmp_old[1] + 2);
+   pos += tmp_old[1] + 2;
+   }
+   } else {
+   /* ie in transmitting ie also in subelement,
+* copy from subelement and flag the ie in subelement
+* as copied (by setting eid field to 0xff). For
+* vendor ie, compare OUI + type + subType to
+* determine if they are the same ie.
+*/
+   if (tmp_old[0] == WLAN_EID_VENDOR_SPECIFIC) {
+   if (!memcmp(tmp_old + 2, tmp + 2, 5)) {
+   /* same vendor ie, copy from
+* subelement
+*/
+   memcpy(pos, tmp, tmp[1] + 2);
+   pos += tmp[1] + 2;
+

[PATCH] ath10k: handling qos at STA side based on AP WMM enable/disable

2017-11-28 Thread bpothuno 
From: Balaji Pothunoori 

Data packets are not sent by STA in case of STA joined to
non QOS AP (WMM disabled AP). This is happening because of STA
is sending data packets to firmware from host with qos enabled
along with non qos queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.

This patch fixes this issue by updating the qos based on station
WME capability field if WMM is disabled in AP.

This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.

For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
has no effect.

Signed-off-by: Balaji Pothunoori 
---
 drivers/net/wireless/ath/ath10k/mac.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947ee..2616b99 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
}
break;
case WMI_VDEV_TYPE_STA:
-   if (vif->bss_conf.qos)
+   if (sta->wme)
arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
break;
case WMI_VDEV_TYPE_IBSS:
-- 
1.7.9.5

Re: [PATCH v2] drivers: bcma: driver_pcie2.c: Comment format correction & moving trailing */ to a separate line as per checkpatch

2017-11-28 Thread Morgan Freeman 
Hi Ashish,

On Tue, Nov 28, 2017 at 07:41:42AM +0530, Ashish Kalra wrote:
> This patch fixes the checkpatch.pl warning:

Write in _imperative_mood_ as I said before.
Like "Use this..." or "Make this..."


> WARNING: Block comments use * on subsequent lines
> + /* TODO:
> + si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); */
> 
> WARNING: Block comments use a trailing */ on a separate line
> + si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); */
> 
> total: 0 errors, 2 warnings, 200 lines checked

No need to mention all of this!

> Signed-off-by: Ashish Kalra 
> ---
> changes from v1 (https://lkml.org/lkml/2017/11/26/85)
> v2: Improved commit message as per review from Morgan Freeman 
> 

Your patch subject is again *wrong* here.

Look here: https://pastebin.com/X7x89Q4v

Please take a look at this :
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Also, don't send me the patch directly, instead to the relevant maintainer and
CC me.


Thanks
Himanshu Jha

[PATCH] wlcore: allow elp during wowlan suspend

2017-11-28 Thread Reizer, Eyal 
when enabling wowlan and entering suspend the last write to the firmware
allowing it to go into elp mode was not completing before suspend, leaving
the firmware running in full active mode consuming high power.
Use an immediate call instead of a work queue for this last access
allowing the firmware to go into power save during wowlan uspend.

Signed-off-by: Eyal Reizer 
---
 drivers/net/wireless/ti/wlcore/main.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index 792cb91..1c31555 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -42,6 +42,7 @@
 #include "sysfs.h"
 
 #define WL1271_BOOT_RETRIES 3
+#define WL1271_SUSPEND_SLEEP 100
 
 static char *fwlog_param;
 static int fwlog_mem_blocks = -1;
@@ -979,6 +980,24 @@ static int wlcore_fw_wakeup(struct wl1271 *wl)
return wlcore_raw_write32(wl, HW_ACCESS_ELP_CTRL_REG, ELPCTRL_WAKE_UP);
 }
 
+static int wlcore_fw_sleep(struct wl1271 *wl)
+{
+   int ret;
+
+   mutex_lock(>mutex);
+   ret = wlcore_raw_write32(wl, HW_ACCESS_ELP_CTRL_REG, ELPCTRL_SLEEP);
+   if (ret < 0) {
+   wl12xx_queue_recovery_work(wl);
+   goto out;
+   }
+   set_bit(WL1271_FLAG_IN_ELP, >flags);
+out:
+   mutex_unlock(>mutex);
+   mdelay(WL1271_SUSPEND_SLEEP);
+
+   return 0;
+}
+
 static int wl1271_setup(struct wl1271 *wl)
 {
wl->raw_fw_status = kzalloc(wl->fw_status_len, GFP_KERNEL);
@@ -1750,7 +1769,6 @@ static int wl1271_op_suspend(struct ieee80211_hw *hw,
goto out_sleep;
 
 out_sleep:
-   wl1271_ps_elp_sleep(wl);
mutex_unlock(>mutex);
 
if (ret < 0) {
@@ -1783,6 +1801,15 @@ static int wl1271_op_suspend(struct ieee80211_hw *hw,
 */
cancel_delayed_work(>tx_watchdog_work);
 
+   /*
+* Use an immediate call for allowing the firmware to go into power
+* save during suspend.
+* Using a workque for this last write was only hapenning on resume
+* leaving the firmware with power save disabled during suspend,
+* while consuming full power during wowlan suspend.
+*/
+   wlcore_fw_sleep(wl);
+
return 0;
 }
 
-- 
2.7.4