Re: ath10k: What will happens when radar is detected ?

[Michal Kazior]

On 23 March 2015 at 16:16, Cedric VONCKEN  wrote:
> In 802.11ac standard, it is possible to dynamically reduce the channel
> width used.
> My question is:
> If I use a channel with 80 or 40 MHz width, what will happen if
> I detect radar?
> The ath10k card/driver reduces automatically the channel
> width.

Currently entire chandef occupied will be marked as unavailable and AP
will stop/switch to a different non-overlapping chandef via CSA.

I guess it should be possible to implement what you suggest, i.e.
change only chandef width when radar is narrow and located at a
suitable part of the chandef. This would require hw to be capable of
detecting radar center freq and width accurately. I'm not sure if
QCA988X is capable of that although firmware interface seems to be
able to carry this kind of information already.

I wonder why would you want this behaviour in the first place?
Wouldn't this actually end up with having less bandwidth and lower
throughput (which is already penalized when radar detection is
active)?


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

pull-request: wireless-drivers 2015-03-24

[Kalle Valo]

Hi Dave,

here are few more fixes I would like to still get to 4.0 if possible,
detailed info in the tag below. Please let me know if there are any
problems.

Kalle

The following changes since commit 3f1615340acea54e21f4b9d4d65921540dca84b2:

  brcmfmac: Perform bound checking on vendor command buffer (2015-03-07 
10:52:30 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2015-03-24

for you to fetch changes up to 6ae4ccfee09efe5baa3951d1c1d27050a46a1469:

  Merge tag 'iwlwifi-for-kalle-2014-03-22' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes 
(2015-03-23 06:43:43 +0200)



iwlwifi:

* avoid panic with lots of IBSS stations
* Fix dvm's behavior after suspend resume
* Allow to keep connection after CSA failure
* Remove a noisy by harmless WARN_ON
* New device IDs

rtlwifi:

* fix IOMMU mapping leak in AP mode

brcmfmac:

* disable MBSS feature for BCM43362 to get AP mode working again

ath9k:

* disable Transmit Power Control (TPC) again due to regressions

* fix beaconing issue with AP+STA setup


Arend van Spriel (1):
  brcmfmac: disable MBSS feature for BCM43362

Emmanuel Grumbach (2):
  iwlwifi: dvm: drop VO packets when mac80211 tells us to
  iwlwifi: dvm: run INIT firmware again upon .start()

Felix Fietkau (2):
  ath9k: fix tracking of enabled AP beacons
  ath9k: disable TPC support again (for now)

Johannes Berg (3):
  iwlwifi: mvm: disconnect if CSA time event fails scheduling
  iwlwifi: mvm: protect rate scaling against non-mvm IBSS stations
  iwlwifi: mvm: remove WARN_ON for invalid BA notification

Kalle Valo (1):
  Merge tag 'iwlwifi-for-kalle-2014-03-22' of 
https://git.kernel.org/.../iwlwifi/iwlwifi-fixes

Larry Finger (1):
  rtlwifi: Fix IOMMU mapping leak in AP mode

Oren Givon (1):
  iwlwifi: add new 3165 series PCI IDs

 drivers/net/wireless/ath/ath9k/beacon.c   |   20 ++---
 drivers/net/wireless/ath/ath9k/common.h   |2 +-
 drivers/net/wireless/ath/ath9k/hw.c   |2 +-
 drivers/net/wireless/brcm80211/brcmfmac/feature.c |3 ++-
 drivers/net/wireless/iwlwifi/dvm/dev.h|1 -
 drivers/net/wireless/iwlwifi/dvm/mac80211.c   |   17 ---
 drivers/net/wireless/iwlwifi/dvm/ucode.c  |5 -
 drivers/net/wireless/iwlwifi/mvm/rs.c |   24 +++--
 drivers/net/wireless/iwlwifi/mvm/time-event.c |2 ++
 drivers/net/wireless/iwlwifi/mvm/tx.c |6 --
 drivers/net/wireless/iwlwifi/pcie/drv.c   |6 --
 drivers/net/wireless/rtlwifi/pci.c|   12 ++-
 12 files changed, 68 insertions(+), 32 deletions(-)
--
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 1/1] New driver: rtl8723au (mac80211)

[Jes Sorensen]

Joe Perches  writes:
> On Mon, 2015-03-23 at 16:25 -0400, jes.soren...@redhat.com wrote:
>> From: Jes Sorensen 
>> 
>> This is an alternate driver for the Realtek 8723AU (rtl8723au) written
>> from scratch utilizing the mac80211 stack.
>
> trivia:
>
>> diff --git a/drivers/net/wireless/rtl8xxxu.c 
>> b/drivers/net/wireless/rtl8xxxu.c
> [
>> +#define USB_VENDER_ID_REALTEK   0x0BDA
>
> realtek can't spell.  VENDOR

Rather minor, but sure, I'll fix that up.

>> +/* Minimum IEEE80211_MAX_FRAME_LEN */
>> +#define RTL_RX_BUFFER_SIZE  IEEE80211_MAX_FRAME_LEN
>> +
>> +static struct usb_device_id dev_table[] = {
>
> const
>
>> +{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_REALTEK, 0x8724,
>> +   0xff, 0xff, 0xff)},
>> +{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_REALTEK, 0x1724,
>> +   0xff, 0xff, 0xff)},
>> +{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_REALTEK, 0x0724,
>> +   0xff, 0xff, 0xff)},
>> +{ }
>> +};
>
>> +static int rtl8xxxu_read_efuse(struct rtl8xxxu_priv *priv)
>> +{
>
> []
>
>> +while (efuse_addr < EFUSE_REAL_CONTENT_LEN_8723A) {
>> +ret = rtl8xxxu_read_efuse8(priv, efuse_addr++, &header);
>> +if (ret || header == 0xff)
>> +goto exit;
>
> break and no exit label would be more common
>
> []
>
>> +exit:
>> +rtl8723au_write8(priv, REG_EFUSE_ACCESS, EFUSE_ACCESS_DISABLE);
>> +
>> +if (priv->efuse_wifi.efuse.rtl_id != cpu_to_le16(0x8129))
>> +ret = EINVAL;
>
> -EINVAL

This needs to be fixed, however the return code isn't actually checked
at present, which is a bigger issue. It's a highly unlikely error
condition, so it can easily be fixed in a follow-on patch.

>> +static bool rtl8xxxu_simularity_compare(struct rtl8xxxu_priv *priv,
>> +int result[][8], int c1, int c2)
>
> Looking through git history, simularity seems to be used
> because realtek can't spell.

It might be the case, but until I see some actual evidence of this, I am
not going to spend cycles on it. It's hardly something justifying the
patch noise in the first place.

Jes
--
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] rtlwifi: rtl8192cu: Add new USB ID

[Larry Finger]

USB ID 2001:330d is used for a D-Link DWA-131.

Signed-off-by: Larry Finger 
Cc: Stable 
---
 drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c 
b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
index 90a714c..6fde250 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -377,6 +377,7 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
{RTL_USB_DEVICE(0x2001, 0x3307, rtl92cu_hal_cfg)}, /*D-Link-Cameo*/
{RTL_USB_DEVICE(0x2001, 0x3309, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/
{RTL_USB_DEVICE(0x2001, 0x330a, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/
+   {RTL_USB_DEVICE(0x2001, 0x330d, rtl92cu_hal_cfg)}, /*D-Link DWA-131 */
{RTL_USB_DEVICE(0x2019, 0xab2b, rtl92cu_hal_cfg)}, /*Planex -Abocom*/
{RTL_USB_DEVICE(0x20f4, 0x624d, rtl92cu_hal_cfg)}, /*TRENDNet*/
{RTL_USB_DEVICE(0x2357, 0x0100, rtl92cu_hal_cfg)}, /*TP-Link WN8200ND*/
-- 
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

Re: [PATCH 1/1] New driver: rtl8723au (mac80211)

[Joe Perches]

On Mon, 2015-03-23 at 16:25 -0400, jes.soren...@redhat.com wrote:
> From: Jes Sorensen 
> 
> This is an alternate driver for the Realtek 8723AU (rtl8723au) written
> from scratch utilizing the mac80211 stack.

trivia:

> diff --git a/drivers/net/wireless/rtl8xxxu.c b/drivers/net/wireless/rtl8xxxu.c
[
> +#define USB_VENDER_ID_REALTEK0x0BDA

realtek can't spell.  VENDOR

> +/* Minimum IEEE80211_MAX_FRAME_LEN */
> +#define RTL_RX_BUFFER_SIZE   IEEE80211_MAX_FRAME_LEN
> +
> +static struct usb_device_id dev_table[] = {

const

> + {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_REALTEK, 0x8724,
> +0xff, 0xff, 0xff)},
> + {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_REALTEK, 0x1724,
> +0xff, 0xff, 0xff)},
> + {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_REALTEK, 0x0724,
> +0xff, 0xff, 0xff)},
> + { }
> +};

> +static int rtl8xxxu_read_efuse(struct rtl8xxxu_priv *priv)
> +{

[]

> + while (efuse_addr < EFUSE_REAL_CONTENT_LEN_8723A) {
> + ret = rtl8xxxu_read_efuse8(priv, efuse_addr++, &header);
> + if (ret || header == 0xff)
> + goto exit;

break and no exit label would be more common

[]

> +exit:
> + rtl8723au_write8(priv, REG_EFUSE_ACCESS, EFUSE_ACCESS_DISABLE);
> +
> + if (priv->efuse_wifi.efuse.rtl_id != cpu_to_le16(0x8129))
> + ret = EINVAL;

-EINVAL

> +static bool rtl8xxxu_simularity_compare(struct rtl8xxxu_priv *priv,
> + int result[][8], int c1, int c2)

Looking through git history, simularity seems to be used
because realtek can't spell.


--
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 1/2] hs20-ca: Update key generation scripts and files.

[Julian Calaby]

Hi Ben,

On Tue, Mar 24, 2015 at 9:31 AM, Ben Greear  wrote:
> On 03/23/2015 03:16 PM, Julian Calaby wrote:
>> Hi Ben,
>>
>> On Tue, Mar 24, 2015 at 5:03 AM,   wrote:
>>> From: Ben Greear 
>>>
>>> This lets us properly over-ride the default w1.fi
>>> related strings in order to properly generate keys
>>> that can be used by the OCSP process.
>>>
>>> Signed-off-by: Ben Greear 
>>> ---
>>>  hs20/server/ca/openssl.cnf | 12 ++--
>>>  hs20/server/ca/setup.sh| 42 ++
>>>  2 files changed, 36 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/hs20/server/ca/openssl.cnf b/hs20/server/ca/openssl.cnf
>>> index e29e737..c614479 100644
>>> --- a/hs20/server/ca/openssl.cnf
>>> +++ b/hs20/server/ca/openssl.cnf
>>> @@ -117,10 +117,10 @@ subjectKeyIdentifier=hash
>>>  authorityKeyIdentifier=keyid:always,issuer
>>>  basicConstraints = critical, CA:true, pathlen:0
>>>  keyUsage = critical, cRLSign, keyCertSign
>>> -authorityInfoAccess = OCSP;URI:http://osu.w1.fi:/
>>> +authorityInfoAccess = OCSP;URI:@OCSP_URI@
>>>  # For SP intermediate CA
>>>  
>>> #subjectAltName=critical,otherName:1.3.6.1.4.1.40808.1.1.1;UTF8String:engExample
>>>  OSU
>>> -#nameConstraints=permitted;DNS:.w1.fi
>>> +#nameConstraints=permitted;DNS:.@DOMAIN@
>>>  #1.3.6.1.5.5.7.1.12=ASN1:SEQUENCE:LogotypeExtn
>>>
>>>  [ v3_osu_server ]
>>> @@ -184,7 +184,7 @@ extendedKeyUsage = OCSPSigning
>>>  basicConstraints=CA:FALSE
>>>  subjectKeyIdentifier=hash
>>>  authorityKeyIdentifier=keyid,issuer
>>> -authorityInfoAccess = OCSP;URI:http://osu.w1.fi:/
>>> +authorityInfoAccess = OCSP;@OCSP_URI@
>>
>> Are you sure this change is correct? You drop the "URI:" part here but
>> not above or below.
>
> You are correct, this is a bug.  I've fixed it locally,
> but not posted a new patch yet.  And, I'll post it to the hostapd
> mailing list instead of linux-wireless next time since that seems more
> appropriate.
>
> Thanks for the review!

I had no idea what the patch was for, but little inconsistencies like
that tend to jump out at me.

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: [PATCH 1/2] hs20-ca: Update key generation scripts and files.

[Ben Greear]

On 03/23/2015 03:16 PM, Julian Calaby wrote:
> Hi Ben,
> 
> On Tue, Mar 24, 2015 at 5:03 AM,   wrote:
>> From: Ben Greear 
>>
>> This lets us properly over-ride the default w1.fi
>> related strings in order to properly generate keys
>> that can be used by the OCSP process.
>>
>> Signed-off-by: Ben Greear 
>> ---
>>  hs20/server/ca/openssl.cnf | 12 ++--
>>  hs20/server/ca/setup.sh| 42 ++
>>  2 files changed, 36 insertions(+), 18 deletions(-)
>>
>> diff --git a/hs20/server/ca/openssl.cnf b/hs20/server/ca/openssl.cnf
>> index e29e737..c614479 100644
>> --- a/hs20/server/ca/openssl.cnf
>> +++ b/hs20/server/ca/openssl.cnf
>> @@ -117,10 +117,10 @@ subjectKeyIdentifier=hash
>>  authorityKeyIdentifier=keyid:always,issuer
>>  basicConstraints = critical, CA:true, pathlen:0
>>  keyUsage = critical, cRLSign, keyCertSign
>> -authorityInfoAccess = OCSP;URI:http://osu.w1.fi:/
>> +authorityInfoAccess = OCSP;URI:@OCSP_URI@
>>  # For SP intermediate CA
>>  
>> #subjectAltName=critical,otherName:1.3.6.1.4.1.40808.1.1.1;UTF8String:engExample
>>  OSU
>> -#nameConstraints=permitted;DNS:.w1.fi
>> +#nameConstraints=permitted;DNS:.@DOMAIN@
>>  #1.3.6.1.5.5.7.1.12=ASN1:SEQUENCE:LogotypeExtn
>>
>>  [ v3_osu_server ]
>> @@ -184,7 +184,7 @@ extendedKeyUsage = OCSPSigning
>>  basicConstraints=CA:FALSE
>>  subjectKeyIdentifier=hash
>>  authorityKeyIdentifier=keyid,issuer
>> -authorityInfoAccess = OCSP;URI:http://osu.w1.fi:/
>> +authorityInfoAccess = OCSP;@OCSP_URI@
> 
> Are you sure this change is correct? You drop the "URI:" part here but
> not above or below.

You are correct, this is a bug.  I've fixed it locally,
but not posted a new patch yet.  And, I'll post it to the hostapd
mailing list instead of linux-wireless next time since that seems more
appropriate.

Thanks for the review!

Ben

-- 
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
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 1/2] hs20-ca: Update key generation scripts and files.

[Julian Calaby]

Hi Ben,

On Tue, Mar 24, 2015 at 5:03 AM,   wrote:
> From: Ben Greear 
>
> This lets us properly over-ride the default w1.fi
> related strings in order to properly generate keys
> that can be used by the OCSP process.
>
> Signed-off-by: Ben Greear 
> ---
>  hs20/server/ca/openssl.cnf | 12 ++--
>  hs20/server/ca/setup.sh| 42 ++
>  2 files changed, 36 insertions(+), 18 deletions(-)
>
> diff --git a/hs20/server/ca/openssl.cnf b/hs20/server/ca/openssl.cnf
> index e29e737..c614479 100644
> --- a/hs20/server/ca/openssl.cnf
> +++ b/hs20/server/ca/openssl.cnf
> @@ -117,10 +117,10 @@ subjectKeyIdentifier=hash
>  authorityKeyIdentifier=keyid:always,issuer
>  basicConstraints = critical, CA:true, pathlen:0
>  keyUsage = critical, cRLSign, keyCertSign
> -authorityInfoAccess = OCSP;URI:http://osu.w1.fi:/
> +authorityInfoAccess = OCSP;URI:@OCSP_URI@
>  # For SP intermediate CA
>  
> #subjectAltName=critical,otherName:1.3.6.1.4.1.40808.1.1.1;UTF8String:engExample
>  OSU
> -#nameConstraints=permitted;DNS:.w1.fi
> +#nameConstraints=permitted;DNS:.@DOMAIN@
>  #1.3.6.1.5.5.7.1.12=ASN1:SEQUENCE:LogotypeExtn
>
>  [ v3_osu_server ]
> @@ -184,7 +184,7 @@ extendedKeyUsage = OCSPSigning
>  basicConstraints=CA:FALSE
>  subjectKeyIdentifier=hash
>  authorityKeyIdentifier=keyid,issuer
> -authorityInfoAccess = OCSP;URI:http://osu.w1.fi:/
> +authorityInfoAccess = OCSP;@OCSP_URI@

Are you sure this change is correct? You drop the "URI:" part here but
not above or below.

>  #@ALTNAME@
>  extendedKeyUsage = clientAuth
>
> @@ -194,7 +194,7 @@ extendedKeyUsage = clientAuth
>  basicConstraints=critical, CA:FALSE
>  subjectKeyIdentifier=hash
>  authorityKeyIdentifier=keyid,issuer
> -authorityInfoAccess = OCSP;URI:http://osu.w1.fi:/
> +authorityInfoAccess = OCSP;URI:@OCSP_URI@
>  #@ALTNAME@
>  extendedKeyUsage = critical, serverAuth
>  keyUsage = critical, keyEncipherment

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: broadcast ssid in scheduled scan

[Arend van Spriel]

On 03/23/15 19:38, Arend van Spriel wrote:

Johannes, Jouni,

I have noticed that under some circumstances wpa_supplicant initiates a
scheduled scan with broadcast ssid. This is something our firmware can
not do so could this be avoided? Maybe by adding a feature flag for it.
I will look into it some more to understand the scenarios in which
broadcast ssid is used in scheduled scan request. If you know about this
feel free to let me know.


From the code in wpa_supplicant_req_sched_scan() it seems the wildcard 
ssid (referred to as broadcast ssid) is added if one or more networks 
are configured without 'scan_ssid=1'. So if none of the networks have 
this option only the broadcast ssid ends up in the request.


Regards,
Arend


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


--
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: Broadcom 43340

[Arend van Spriel]

On 03/23/15 21:09, Jürgen Bausa wrote:

Arend van Spriel  writes:


I now got it working. Just put 'sleeep 20' before the commands and now it
works perfectly.


Holding the boot for 20s is steep, but I guess a working device trumps a
fast boot



Systemd runs even rc.local in parallel. So it doesn't hold the boot process.


You make me feel old ;-)

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

[PATCH v3 0/1] New driver: rtl8723au (mac80211)

[Jes . Sorensen]

From: Jes Sorensen 

This is a new driver for the rtl8723au which was written from scratch,
to utilize the Linux mac80211 stack.

This has been a pet project for me for some time I finally feel it
is stable enough to submit. I have used it for a while without any
serious issues.

I started working on cleaning up the vendor provided driver in
staging/rtl8723au over a year ago. After spending 6 months on it, it
became obvious to me that it was a rather hopeless task, and I started
writing this driver from scratch. I do not have any specs for the
chip, so everything is based on knowledge I obtained from dissecting
the vendor driver.

Special thanks to Larry Finger for help with the original rtl8723au
driver, and Johannes Berg for answering all my silly questions about
802.11 innards and the mac80211 stack. Had I known then what I know
today about 802.11, I probably would never have so mad as to start
this project in the first place!

v2 fixes an endian problem reported by Joe Perches, and adds a module
debug parameter so one doesn't have to recompile the driver to change
the debug mask (I was convinced I had that as a module parameter
already). The latter was suggested by Larry Finger.

v3 resolves the issues and suggestions provided by Johannes Berg to
the v2 patch. Discussing with Johannes we agreed it was cleaner to
keep the flow folling the BSS_CHANGED events rather than sticking it
into sta_state(). In addition I fixed cleaned up a couple of other
parts of the code.

There are still some debug portions and code that is #if 0'ed out. I
prefer to keep this in place for now as some of it is meant to be
enabled later, and other portions I use to match up tables and code to
the vendor driver when trying to trace issues when debugging.

The code is still work in progress, in particular I want to get AMPDU
for TX going, but it will be a little while before I get time to
address that.

Cheers,
Jes


Jes Sorensen (1):
  New driver: rtl8723au (mac80211)

 MAINTAINERS  |8 +
 drivers/net/wireless/Kconfig |   19 +
 drivers/net/wireless/Makefile|2 +
 drivers/net/wireless/rtl8xxxu.c  | 4500 ++
 drivers/net/wireless/rtl8xxxu.h  |  497 
 drivers/net/wireless/rtl8xxxu_regs.h |  941 +++
 6 files changed, 5967 insertions(+)
 create mode 100644 drivers/net/wireless/rtl8xxxu.c
 create mode 100644 drivers/net/wireless/rtl8xxxu.h
 create mode 100644 drivers/net/wireless/rtl8xxxu_regs.h

-- 
2.1.0

--
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: Broadcom 43340

[Jürgen Bausa]

Arend van Spriel  writes:

> > I now got it working. Just put 'sleeep 20' before the commands and now it
> > works perfectly.
> 
> Holding the boot for 20s is steep, but I guess a working device trumps a 
> fast boot 
> 

Systemd runs even rc.local in parallel. So it doesn't hold the boot process.

Juergen

--
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] iwlwifi: Fix memory leak in iwl_req_fw_callback()

[Larry Finger]

In this routine, kzalloc allocates a memory block. This allocation is
freed in the error paths, but not in the normal exit, thus the allocation
is leaked.

The kmemleak facility was used to find the leak.

Signed-off-by: Larry Finger 
Cc: Johannes Berg 
Cc: Emmanuel Grumbach 
Cc: Intel Linux Wireless 
---
 drivers/net/wireless/iwlwifi/iwl-drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/iwlwifi/iwl-drv.c
index 66ca000..aefdd9b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/iwlwifi/iwl-drv.c
@@ -1319,6 +1319,7 @@ static void iwl_req_fw_callback(const struct firmware 
*ucode_raw, void *context)
op->name, err);
 #endif
}
+   kfree(pieces);
return;
 
  try_again:
-- 
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

broadcast ssid in scheduled scan

[Arend van Spriel]

Johannes, Jouni,

I have noticed that under some circumstances wpa_supplicant initiates a 
scheduled scan with broadcast ssid. This is something our firmware can 
not do so could this be avoided? Maybe by adding a feature flag for it. 
I will look into it some more to understand the scenarios in which 
broadcast ssid is used in scheduled scan request. If you know about this 
feel free to let me know.


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 1/2] hs20-ca: Update key generation scripts and files.

[Ben Greear]

Sorry, this should have gone elsewherewill re-send to the appropriate 
location.

Thanks,
Ben

-- 
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
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] hs20-ca: Update key generation scripts and files.

[greearb]

From: Ben Greear 

This lets us properly over-ride the default w1.fi
related strings in order to properly generate keys
that can be used by the OCSP process.

Signed-off-by: Ben Greear 
---
 hs20/server/ca/openssl.cnf | 12 ++--
 hs20/server/ca/setup.sh| 42 ++
 2 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/hs20/server/ca/openssl.cnf b/hs20/server/ca/openssl.cnf
index e29e737..c614479 100644
--- a/hs20/server/ca/openssl.cnf
+++ b/hs20/server/ca/openssl.cnf
@@ -95,7 +95,7 @@ localityName  = Locality Name (eg, city)
 localityName_default   = Tuusula
 
 0.organizationName = Organization Name (eg, company)
-0.organizationName_default = w1.fi
+0.organizationName_default = @DOMAIN@
 
 ##organizationalUnitName   = Organizational Unit Name (eg, section)
 #organizationalUnitName_default=
@@ -117,10 +117,10 @@ subjectKeyIdentifier=hash
 authorityKeyIdentifier=keyid:always,issuer
 basicConstraints = critical, CA:true, pathlen:0
 keyUsage = critical, cRLSign, keyCertSign
-authorityInfoAccess = OCSP;URI:http://osu.w1.fi:/
+authorityInfoAccess = OCSP;URI:@OCSP_URI@
 # For SP intermediate CA
 
#subjectAltName=critical,otherName:1.3.6.1.4.1.40808.1.1.1;UTF8String:engExample
 OSU
-#nameConstraints=permitted;DNS:.w1.fi
+#nameConstraints=permitted;DNS:.@DOMAIN@
 #1.3.6.1.5.5.7.1.12=ASN1:SEQUENCE:LogotypeExtn
 
 [ v3_osu_server ]
@@ -159,7 +159,7 @@ algorithm=OID:sha256
 [sha1_alg]
 algorithm=OID:sha1
 [URI]
-uri=IA5STRING:http://osu.w1.fi/w1fi_logo.png
+uri=IA5STRING:@LOGO_URI@
 [LogotypeImageInfo]
 # default value color(1), component optional
 #type=IMP:0,INTEGER:1
@@ -184,7 +184,7 @@ extendedKeyUsage = OCSPSigning
 basicConstraints=CA:FALSE
 subjectKeyIdentifier=hash
 authorityKeyIdentifier=keyid,issuer
-authorityInfoAccess = OCSP;URI:http://osu.w1.fi:/
+authorityInfoAccess = OCSP;@OCSP_URI@
 #@ALTNAME@
 extendedKeyUsage = clientAuth
 
@@ -194,7 +194,7 @@ extendedKeyUsage = clientAuth
 basicConstraints=critical, CA:FALSE
 subjectKeyIdentifier=hash
 authorityKeyIdentifier=keyid,issuer
-authorityInfoAccess = OCSP;URI:http://osu.w1.fi:/
+authorityInfoAccess = OCSP;URI:@OCSP_URI@
 #@ALTNAME@
 extendedKeyUsage = critical, serverAuth
 keyUsage = critical, keyEncipherment
diff --git a/hs20/server/ca/setup.sh b/hs20/server/ca/setup.sh
index fcf24ad..35d32b1 100755
--- a/hs20/server/ca/setup.sh
+++ b/hs20/server/ca/setup.sh
@@ -5,41 +5,52 @@ if [ -z "$OPENSSL" ]; then
 fi
 export OPENSSL_CONF=$PWD/openssl.cnf
 PASS=whatever
-CNI="w1.fi Hotspot 2.0 Intermediate CA"
+if [ -z "$DOMAIN" ]; then
+DOMAIN=w1.fi
+fi
+CNI="$DOMAIN Hotspot 2.0 Intermediate CA"
 CNR="Hotspot 2.0 Trust Root CA - 99"
-CNO="ocsp.w1.fi"
-CNV="osu-revoked.w1.fi"
-CNOC="osu-client.w1.fi"
-SERVERNAME="osu.w1.fi"
+CNO="ocsp.$DOMAIN"
+CNV="osu-revoked.$DOMAIN"
+CNOC="osu-client.$DOMAIN"
+SERVERNAME="osu.$DOMAIN"
 DNS=$SERVERNAME
 DEBUG=0
+OCSP_URI="http://$CNO:/";
+LOGO_URI="http://osu.w1.fi/w1fi_logo.png";
 
 # Command line over-rides
 USAGE=$( cat < openssl-root.cnf.tmp
+# Set the password and some other common config accordingly.
+cat openssl-root.cnf | sed "s/@PASSWORD@/$PASS/" \
+ > openssl-root.cnf.tmp
 mv openssl-root.cnf.tmp openssl-root.cnf
-cat openssl.cnf | sed "s/@PASSWORD@/$PASS/" > openssl.cnf.tmp
+
+set -x
+cat openssl.cnf | sed "s/@PASSWORD@/$PASS/" |
+sed "s,@OCSP_URI@,$OCSP_URI," |
+sed "s,@LOGO_URI@,$LOGO_URI," |
+sed "s/@DOMAIN@/$DOMAIN/" \
+ > openssl.cnf.tmp
 mv openssl.cnf.tmp openssl.cnf
 
 
@@ -155,8 +173,8 @@ echo "---[ Server 
]---"
 echo
 
 ALT="DNS:$DNS"
-ALT="$ALT,otherName:1.3.6.1.4.1.40808.1.1.1;UTF8String:engw1.fi TESTING USE"
-ALT="$ALT,otherName:1.3.6.1.4.1.40808.1.1.1;UTF8String:finw1.fi TESTIK??YTT??"
+ALT="$ALT,otherName:1.3.6.1.4.1.40808.1.1.1;UTF8String:eng$DOMAIN TESTING USE"
+ALT="$ALT,otherName:1.3.6.1.4.1.40808.1.1.1;UTF8String:fin$DOMAIN 
TESTIK??YTT??"
 
 cat openssl.cnf |
sed "s/#@CN@/commonName_default = $SERVERNAME/" |
-- 
1.9.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 2/2] hs20: Update hs20 server notes file.

[greearb]

From: Ben Greear 

Include example hostapd-radius config file for the OSEN radius
server.  Show example of how to use the ca/setup.sh script to
generate keys.

Show how to start OCSP responder and generate the ocsp cache
file.

Signed-off-by: Ben Greear 
---
 hs20/server/hs20-osu-server.txt | 53 +
 1 file changed, 53 insertions(+)

diff --git a/hs20/server/hs20-osu-server.txt b/hs20/server/hs20-osu-server.txt
index 80985f7..1557248 100644
--- a/hs20/server/hs20-osu-server.txt
+++ b/hs20/server/hs20-osu-server.txt
@@ -100,6 +100,19 @@ sqlite3 /home/user/hs20-server/AS/DB/eap_user.db < 
sql-example.txt
 # the examples as-is for initial testing).
 cp -r www /home/user/hs20-server
 
+# Build local keys and certs
+cd ca
+# Display help options.
+./setup.sh -h
+
+# Remove old keys, fill in appropriate values, and generate your keys.  For 
instance:
+./clean.sh
+rm -fr rootCA"
+old_hostname=myserver.local
+./setup.sh -C "Hotspot 2.0 Trust Root CA - CT" -d $old_hostname \
+   -I "Hotspot 2.0 Intermediate CA - CT" -o $old_hostname-osu-client \
+   -O $old_hostname-oscp -p lanforge -S $old_hostname -V 
$old_hostname-osu-revoked \
+   -m local -u http://$old_hostname:/
 
 # Configure subscription policies
 mkdir -p /home/user/hs20-server/spp/policy
@@ -128,6 +141,7 @@ EOF
 # Configure RADIUS authentication service
 # Note: Change the URL to match the setup
 # Note: Install AAA server key/certificate and root CA in Key directory
+# NOTE: ca.pem is a copy of the hs20-server/ca/ca.pem file
 
 cat > /home/user/hs20-server/AS/as-sql.conf 

Re: [PATCH 1/2] ath10k: share board file loading code across FW APIs

[Kalle Valo]

Michal Kazior  writes:

> There's no need to implement the same thing twice.
> Reduce code duplication.
>
> Signed-off-by: Michal Kazior 

[...]

> @@ -730,6 +716,12 @@ static int ath10k_core_fetch_firmware_files(struct 
> ath10k *ar)
>   /* calibration file is optional, don't check for any errors */
>   ath10k_fetch_cal_file(ar);
>  
> + ret = ath10k_core_fetch_board_file(ar);
> + if (ret) {
> + ath10k_err(ar, "failed to fetch board file: %d\n", ret);
> + return ret;
> + }
> +
>   ar->fw_api = 4;
>   ath10k_dbg(ar, ATH10K_DBG_BOOT, "trying fw api %d\n", ar->fw_api);

There was a conflict here, please check the resolution in the pending
branch.

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

Re: [PATCH v4 5/6] ath10k: add wmi support for tdls

[Kalle Valo]

Marek Puzyniak  writes:

> As a part of tdls implementation introduce
> tdls related wmi data structures, constant
> values and functions.
>
> Signed-off-by: Marek Puzyniak 

This patch had non-trivial conflicts, please check carefully my
resolution in the pending branch.

  CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/wmi.h
  CONFLICT (content): Merge conflict in 
drivers/net/wireless/ath/ath10k/wmi-tlv.h
  CONFLICT (content): Merge conflict in 
drivers/net/wireless/ath/ath10k/wmi-tlv.c
  CONFLICT (content): Merge conflict in 
drivers/net/wireless/ath/ath10k/wmi-ops.h

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

Re: [PATCH v4 0/7] ath10k: add multi-channel support

[Kalle Valo]

Michal Kazior  writes:

> New qca6174 with wmi-tlv firmware supports
> multi-channel operation. To make use of it
> ath10k needs a few changes: implement mac80211's
> chanctx API and rework tx queue control a bit.

3-way merge fails:

Applying: ath10k: allow empty ssid vdev config
Applying: ath10k: implement chanctx API
error: short SHA1 7b3e6ca is ambiguous.
fatal: sha1 information is lacking or useless 
(drivers/net/wireless/ath/ath10k/wmi.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0002 ath10k: implement chanctx API

And no wonder, 7 chars is just too short SHA1 abbreviation. Is there any
way to make that longer?

Anyway, can you please rebase?

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

Re: [PATCH v2 1/2] ath10k: enable Adaptive Noise Immunity (ANI) by default

[Kalle Valo]

Ashok Raj Nagarajan  writes:

> ANI helps to improve connectvity and performance in a noisy environment.
> Enabling this feature would help the user experience a better and stable
> wireless connection in a noisy environmnet. This feature is currently not
> enabled for ath10k. Enable this feature by default.
>
> Signed-off-by: Ashok Raj Nagarajan 

Thanks, both patches applied.

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

Re: [PATCH] ath10k: enable channel 144 on 5GHz band

[Kalle Valo]

Peter Oh  writes:

> Enable channel 144 on 5GHz band since 802.11ac introduced it.
>
> Signed-off-by: Peter Oh 

Thanks, applied.

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

Re: [PATCH 0/6] ath10k: thermal mitigation fixes

[Kalle Valo]

Rajkumar Manoharan  writes:

> Here are few enhancements in thermal throttling that allows
> user to control throttling state and quiet period. Also enables
> throttling for station mode. These patches are rebased on latest TOT.
>
> Rajkumar Manoharan (6):
>   ath10k: add debugfs entry to configure quiet period
>   ath10k: Fix interpretation of cooling device state
>   ath10k: configure thermal throttle while powering up
>   ath10k: do not restrict thermal throttling to ap mode
>   ath10k: cache throttle state when device is down
>   ath10k: move driver state check before setting throttle

Thanks, applied.

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

ath10k: What will happens when radar is detected ?

[Cedric VONCKEN]

In 802.11ac standard, it is possible to dynamically reduce the channel
width used.
My question is:
If I use a channel with 80 or 40 MHz width, what will happen if
I detect radar? 
The ath10k card/driver reduces automatically the channel
width.

Cedric Voncken.
--
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/2] ath10k: fix rts profile for second rate series

[Kalle Valo]

Rajkumar Manoharan  writes:

> By default rts protection is enabled in firmware for the second
> rateset. Currently ath10k selects RTS profile (only for software
> retries), when legacy stations are associated or asked by mac80211.
> On congested environment, when AP is running in HT/VHT mode and
> there are no legacy clients associated, this will impact the
> robustness. Also enabling RTS protection only for second rateset will
> not impact performance on clear environment. Fix that.
>
> Signed-off-by: Rajkumar Manoharan 

Thanks, both patches applied.

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

Re: [PATCH 2/4] ath10k: add WOW disconnect/magic-packet support

[Kalle Valo]

Janusz Dziedzic  writes:

> Add support for WOW disconnect and magic-packet.
>
> Signed-off-by: Janusz Dziedzic 

[...]

> +#ifdef CONFIG_PM
> +int ath10k_wow_init(struct ieee80211_hw *hw);

[...]

> +#else
> +static inline int ath10k_wow_init(struct ieee80211_hw *hw)
> +{
> + return 0;
> +}

In pending branch I changed these to:

int ath10k_wow_init(struct ath10k *ar);

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

Re: mac80111: Add BIP-GMAC-128 and BIP-GMAC-256 ciphers

[Dan Carpenter]

On Mon, Mar 23, 2015 at 03:24:09PM +0200, Jouni Malinen wrote:
> > This function should be a list of commands in a row with tiny detours
> > for exceptions and error handling.  It messes everyone up if the success
> > path is hidden somewhere in the middle and it leads to bugs like this.
> 
> I'm not sure that would be behind this specific bug, 

It is though.

1) The code here:

err = crypto_aead_setkey(tfm, key, key_len);
if (!err)
return tfm;

   That looks like normal error handling code so your mind glosses over
   it.  Reviewers are human and this is a blind spot.

2) If you do it in normal kernel style then the return would have been
   at level 1 indent so the static checkers would have complained about
   the unreachable code.  This was caught with a static checker anyway,
   I suppose, but that static check has a lot more false positives so
   I'm not sure I can release it.

3) This code is just confusing.  The error and the success paths are
   twisted together.  After the first allocation then the exclusive
   parts of the success path move from indent level 1 to indent level 2.
   Confusing code is more likely to have bugs.

regards,
dan carpenter

--
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] mac80111: aes_ccm: cleanup ieee80211_aes_key_setup_encrypt()

[Dan Carpenter]

This code is written using an anti-pattern called "success handling"
which makes it hard to read, especially if you are used to normal kernel
style.  It should instead be written as a list of directives in a row
with branches for error handling.

Signed-off-by: Dan Carpenter 

diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 7869bb40..208df7c 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -85,11 +85,15 @@ struct crypto_aead *ieee80211_aes_key_setup_encrypt(const 
u8 key[],
return tfm;
 
err = crypto_aead_setkey(tfm, key, key_len);
-   if (!err)
-   err = crypto_aead_setauthsize(tfm, mic_len);
-   if (!err)
-   return tfm;
+   if (err)
+   goto free_aead;
+   err = crypto_aead_setauthsize(tfm, mic_len);
+   if (err)
+   goto free_aead;
+
+   return tfm;
 
+free_aead:
crypto_free_aead(tfm);
return ERR_PTR(err);
 }
--
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] mac80211: Fix misplaced return in AES-GMAC key setup

[Jouni Malinen]

Commit 8ade538bf39b ("mac80111: Add BIP-GMAC-128 and BIP-GMAC-256
ciphers") had the success return in incorrect place before the
crypto_aead_setauthsize() call which practically ended up skipping that
call unconditionally.

The missing call did not actually change any functionality since
GMAC_MIC_LEN (16) is identical to the maxauthsize in gcm(aes) and as
such, the default value used for the authsize parameter.

Reported-by: Dan Carpenter 
Signed-off-by: Jouni Malinen 
---
 net/mac80211/aes_gmac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/aes_gmac.c b/net/mac80211/aes_gmac.c
index 1c72edc..f1321b7 100644
--- a/net/mac80211/aes_gmac.c
+++ b/net/mac80211/aes_gmac.c
@@ -69,10 +69,10 @@ struct crypto_aead *ieee80211_aes_gmac_key_setup(const u8 
key[],
return tfm;
 
err = crypto_aead_setkey(tfm, key, key_len);
-   if (!err)
-   return tfm;
if (!err)
err = crypto_aead_setauthsize(tfm, GMAC_MIC_LEN);
+   if (!err)
+   return tfm;
 
crypto_free_aead(tfm);
return ERR_PTR(err);
-- 
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: mac80111: Add BIP-GMAC-128 and BIP-GMAC-256 ciphers

[Jouni Malinen]

On Thu, Mar 19, 2015 at 03:53:14PM +0300, Dan Carpenter wrote:
> The patch 8ade538bf39b: "mac80111: Add BIP-GMAC-128 and BIP-GMAC-256
> ciphers" from Jan 24, 2015, leads to the following static checker
> warning:

> net/mac80211/aes_gmac.c
> 61  struct crypto_aead *ieee80211_aes_gmac_key_setup(const u8 key[],

> 71  err = crypto_aead_setkey(tfm, key, key_len);
> 72  if (!err)
> 
> This is success handling.  In the kernel, everyone expects error
> hanlding like "if (err) " so this makes the code hard to read if you
> have a job and need to read code quickly.  At first I missed the "!"
> character, and then I thought,  "What??  Is err a pointer?"

This follows the style used in net/mac80211/aes_ccm.c for an equivalent
key_setup function. I have no issues in someone cleaning that up as long
as it is done consistently through all net/mac80211 key_setup functions.

> 73  return tfm;
> 74  if (!err)
> 75  err = crypto_aead_setauthsize(tfm, GMAC_MIC_LEN);
> 
> This is dead code.

That's interesting.. This must be some kind of rebasing issue since this
obviously makes no sense. Lines 72-73 were supposed to be after this
line 75 just like this is done in aes_gcm.c and aes_ccm.c. Thanks for
reporting this, I'll fix it.

> 77  crypto_free_aead(tfm);
> 78  return ERR_PTR(err);
> 
> This function should be a list of commands in a row with tiny detours
> for exceptions and error handling.  It messes everyone up if the success
> path is hidden somewhere in the middle and it leads to bugs like this.

I'm not sure that would be behind this specific bug, but like noted
above, no objection to someone cleaning this up consistently.

-- 
Jouni MalinenPGP id EFC895FA
--
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 0/2] ath10k: load device specific board files

[Michal Kazior]

Until now it was okay to use a very generic board
data since OTP was supposed to fill in the blanks
(except some cases in which a complete cal data is
provided via cal-pci-xxx or device tree).

However since qca6174 this has changed. It is now
necessary to load specific board file for
different designs in driver. The OTP must still be
run.

Some devices with different subsystem
vendor/device ids may share the same board file.
Driver could maintain a subsystem vendor/device
id to design id however I prefer to just leave
this to userspace (e.g. symlinks). Thoughts?


Michal Kazior (2):
  ath10k: share board file loading code across FW APIs
  ath10k: allow loading device specific board files

 drivers/net/wireless/ath/ath10k/core.c  | 109 +---
 drivers/net/wireless/ath/ath10k/core.h  |   3 +
 drivers/net/wireless/ath/ath10k/debug.c |   6 +-
 drivers/net/wireless/ath/ath10k/pci.c   |   5 ++
 4 files changed, 84 insertions(+), 39 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

[PATCH 2/2] ath10k: allow loading device specific board files

[Michal Kazior]

Some devices differ slightly and require different
board files. These devices can be differentiated
by looking at PCI subsystem device id. That is the
case for qca6174 devices at least.

Use that and load subsystem id specific board
files if possible. Otherwise fall back to use the
(old) generic board file path.

Using wrong board data may cause device crashes or
invalid behaviour (wrong tx power, garbled RF
signal).

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/core.c  | 55 -
 drivers/net/wireless/ath/ath10k/core.h  |  3 ++
 drivers/net/wireless/ath/ath10k/debug.c |  6 +++-
 drivers/net/wireless/ath/ath10k/pci.c   |  5 +++
 4 files changed, 61 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 1785e0e..12da7fa 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -482,10 +482,26 @@ static int ath10k_fetch_cal_file(struct ath10k *ar)
return 0;
 }
 
-static int ath10k_core_fetch_board_file(struct ath10k *ar)
+static int ath10k_core_fetch_spec_board_file(struct ath10k *ar)
 {
-   int ret;
+   char filename[100];
 
+   scnprintf(filename, sizeof(filename), "board-%s-%s.bin",
+ ath10k_bus_str(ar->hif.bus), ar->spec_board_id);
+
+   ar->board = ath10k_fetch_fw_file(ar, ar->hw_params.fw.dir, filename);
+   if (IS_ERR(ar->board))
+   return PTR_ERR(ar->board);
+
+   ar->board_data = ar->board->data;
+   ar->board_len = ar->board->size;
+   ar->spec_board_loaded = true;
+
+   return 0;
+}
+
+static int ath10k_core_fetch_generic_board_file(struct ath10k *ar)
+{
if (!ar->hw_params.fw.board) {
ath10k_err(ar, "failed to find board file fw entry\n");
return -EINVAL;
@@ -494,14 +510,39 @@ static int ath10k_core_fetch_board_file(struct ath10k *ar)
ar->board = ath10k_fetch_fw_file(ar,
 ar->hw_params.fw.dir,
 ar->hw_params.fw.board);
-   if (IS_ERR(ar->board)) {
-   ret = PTR_ERR(ar->board);
-   ath10k_err(ar, "failed to fetch board data: %d\n", ret);
-   return ret;
-   }
+   if (IS_ERR(ar->board))
+   return PTR_ERR(ar->board);
 
ar->board_data = ar->board->data;
ar->board_len = ar->board->size;
+   ar->spec_board_loaded = false;
+
+   return 0;
+}
+
+static int ath10k_core_fetch_board_file(struct ath10k *ar)
+{
+   int ret;
+
+   if (strlen(ar->spec_board_id) > 0) {
+   ret = ath10k_core_fetch_spec_board_file(ar);
+   if (ret) {
+   ath10k_info(ar, "failed to load spec board file, 
falling back to generic: %d\n",
+   ret);
+   goto generic;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_BOOT, "found specific board file for 
%s\n",
+  ar->spec_board_id);
+   return 0;
+   }
+
+generic:
+   ret = ath10k_core_fetch_generic_board_file(ar);
+   if (ret) {
+   ath10k_err(ar, "failed to fetch generic board data: %d\n", ret);
+   return ret;
+   }
 
return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index c1f43b0..90b5b10 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -568,6 +568,9 @@ struct ath10k {
 
const struct firmware *cal_file;
 
+   char spec_board_id[100];
+   bool spec_board_loaded;
+
int fw_api;
enum ath10k_cal_mode cal_mode;
 
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index 301081d..9c824e2 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -124,10 +124,14 @@ EXPORT_SYMBOL(ath10k_info);
 
 void ath10k_print_driver_info(struct ath10k *ar)
 {
-   ath10k_info(ar, "%s (0x%08x, 0x%08x) fw %s api %d htt %d.%d wmi %d cal 
%s max_sta %d\n",
+   ath10k_info(ar, "%s (0x%08x, 0x%08x%s%s%s) fw %s api %d htt %d.%d wmi 
%d cal %s max_sta %d\n",
ar->hw_params.name,
ar->target_version,
ar->chip_id,
+   (strlen(ar->spec_board_id) > 0 ? ", " : ""),
+   ar->spec_board_id,
+   (strlen(ar->spec_board_id) > 0 && !ar->spec_board_loaded
+? " fallback" : ""),
ar->hw->wiphy->fw_version,
ar->fw_api,
ar->htt.target_version_major,
diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index b4aacfa..1e528bc 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2627,6 +2627,11 

[PATCH 1/2] ath10k: share board file loading code across FW APIs

[Michal Kazior]

There's no need to implement the same thing twice.
Reduce code duplication.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/core.c | 68 +++---
 1 file changed, 30 insertions(+), 38 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index c0e454b..1785e0e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -482,6 +482,30 @@ static int ath10k_fetch_cal_file(struct ath10k *ar)
return 0;
 }
 
+static int ath10k_core_fetch_board_file(struct ath10k *ar)
+{
+   int ret;
+
+   if (!ar->hw_params.fw.board) {
+   ath10k_err(ar, "failed to find board file fw entry\n");
+   return -EINVAL;
+   }
+
+   ar->board = ath10k_fetch_fw_file(ar,
+ar->hw_params.fw.dir,
+ar->hw_params.fw.board);
+   if (IS_ERR(ar->board)) {
+   ret = PTR_ERR(ar->board);
+   ath10k_err(ar, "failed to fetch board data: %d\n", ret);
+   return ret;
+   }
+
+   ar->board_data = ar->board->data;
+   ar->board_len = ar->board->size;
+
+   return 0;
+}
+
 static int ath10k_core_fetch_firmware_api_1(struct ath10k *ar)
 {
int ret = 0;
@@ -491,23 +515,6 @@ static int ath10k_core_fetch_firmware_api_1(struct ath10k 
*ar)
return -EINVAL;
}
 
-   if (ar->hw_params.fw.board == NULL) {
-   ath10k_err(ar, "board data file not defined");
-   return -EINVAL;
-   }
-
-   ar->board = ath10k_fetch_fw_file(ar,
-ar->hw_params.fw.dir,
-ar->hw_params.fw.board);
-   if (IS_ERR(ar->board)) {
-   ret = PTR_ERR(ar->board);
-   ath10k_err(ar, "could not fetch board data (%d)\n", ret);
-   goto err;
-   }
-
-   ar->board_data = ar->board->data;
-   ar->board_len = ar->board->size;
-
ar->firmware = ath10k_fetch_fw_file(ar,
ar->hw_params.fw.dir,
ar->hw_params.fw.fw);
@@ -695,27 +702,6 @@ static int ath10k_core_fetch_firmware_api_n(struct ath10k 
*ar, const char *name)
goto err;
}
 
-   /* now fetch the board file */
-   if (ar->hw_params.fw.board == NULL) {
-   ath10k_err(ar, "board data file not defined");
-   ret = -EINVAL;
-   goto err;
-   }
-
-   ar->board = ath10k_fetch_fw_file(ar,
-ar->hw_params.fw.dir,
-ar->hw_params.fw.board);
-   if (IS_ERR(ar->board)) {
-   ret = PTR_ERR(ar->board);
-   ath10k_err(ar, "could not fetch board data '%s/%s' (%d)\n",
-  ar->hw_params.fw.dir, ar->hw_params.fw.board,
-  ret);
-   goto err;
-   }
-
-   ar->board_data = ar->board->data;
-   ar->board_len = ar->board->size;
-
return 0;
 
 err:
@@ -730,6 +716,12 @@ static int ath10k_core_fetch_firmware_files(struct ath10k 
*ar)
/* calibration file is optional, don't check for any errors */
ath10k_fetch_cal_file(ar);
 
+   ret = ath10k_core_fetch_board_file(ar);
+   if (ret) {
+   ath10k_err(ar, "failed to fetch board file: %d\n", ret);
+   return ret;
+   }
+
ar->fw_api = 4;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "trying fw api %d\n", ar->fw_api);
 
-- 
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

Re: informations about Linux wifi driver's architecture today

[Stefano Cappa]

Oh thank you.
Yes. This can be very useful.


Da: Arend van Spriel 
Inviato: lunedì 23 marzo 2015 11.03.59
A: Stefano Cappa
Cc: linux-wireless@vger.kernel.org
Oggetto: Re: informations about Linux wifi driver's architecture today

On 03/22/15 22:21, Stefano Cappa wrote:
> Hi
> I prefer a generic version, without specific things, like this one: 
> h**p://postimg.org/image/hfkpjt3ux/ created by Johannes Berg.
>
> And, if available something for the broadcom chip bcm4339.

Hi Stefano,

The bcm4339 is supported by the brcmfmac driver and is a cfg8211-based
driver aka fullmac device where the 802.11 stack runs on the device. I
did write up some stuff about the driver internally, but we can consider
putting it on wireless.kernel.org under creative commons license.

Regards,
Arend

> Thank you.
>
> 
> Da: Kathy Giori
> Inviato: domenica 22 marzo 2015 19.35
> A: Stefano Cappa
> Cc: linux-wireless@vger.kernel.org
> Oggetto: Re: informations about Linux wifi driver's architecture today
>
> On Sun, Mar 22, 2015 at 11:19 AM, Stefano Cappa
>   wrote:
>> Hi!
>> some months ago, i saw the presentation of Johannes Berg in PDF, but now it 
>> isn't available, probably because it's very old.
>>
>> This slides will be updated to a new release?
>>
>> I have this slide and in page 5/35 (2009-02-26) there is the "Architecture - 
>> planned". This is the actual architecture or there are some differences in 
>> 2015? If yes, where i can find the new version of this page, with a little 
>> diagram?
>
> Ciao Stefano,
>
> Perhaps Johannes can post a current overview diagram on the Linux
> wireless wiki (if you share with him which diagram you want to be
> updated).
>
> In terms of vendor-specific architecture, and how it fits in, Kalle
> Valo posted a high-level diagram for ath10k:
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/architecture
>
> Are you mainly interested in the architecture of vendor-agnostic upper
> layers or a description of a specific vendor driver?
> kg--
> 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

--
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 2/2] mwifiex: recover from skb allocation failures during RX

[James Cameron]

On 24/03/2015, at 1:20 AM, Avinash Patil wrote:

> From: Zhaoyang Liu 
> 
> This patch adds recovery mechanism for SDIO RX during SKB allocation
> failures.
> For allocation failures during multiport aggregation, we skip and drop RX
> packets.
> For single port read case, we will use preallocated card->mpa_rx.buf to
> complete cmd53 read.

Thanks.

Dropping RX data packets is considered safe, as the peer will retry; but does 
your patch drop events or command responses?  

Last year, I tried something similar, and I found that the driver would be 
confused if command responses were dropped.

--
James Cameron

--
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] mwifiex: remove an unneede NULL check in mwifiex_init_adapter()

[Amitkumar Karwar]

Hi Dan,

Thanks for the patch.

> Subject: [patch] mwifiex: remove an unneede NULL check in
> mwifiex_init_adapter()
> 
> "adapter->sleep_cfm" is always non-NULL at this point.  Static checkers
> complain that we already dereference it at the start of the function
> when we do:
> 
>   skb_put(adapter->sleep_cfm, sizeof(struct
> mwifiex_opt_sleep_confirm));
> 
> Signed-off-by: Dan Carpenter 
> 

Acked-by: Amitkumar Karwar 

Regards,
Amit
--
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: informations about Linux wifi driver's architecture today

[Arend van Spriel]

On 03/22/15 22:21, Stefano Cappa wrote:

Hi
I prefer a generic version, without specific things, like this one: 
h**p://postimg.org/image/hfkpjt3ux/ created by Johannes Berg.

And, if available something for the broadcom chip bcm4339.


Hi Stefano,

The bcm4339 is supported by the brcmfmac driver and is a cfg8211-based 
driver aka fullmac device where the 802.11 stack runs on the device. I 
did write up some stuff about the driver internally, but we can consider 
putting it on wireless.kernel.org under creative commons license.


Regards,
Arend


Thank you.


Da: Kathy Giori
Inviato: domenica 22 marzo 2015 19.35
A: Stefano Cappa
Cc: linux-wireless@vger.kernel.org
Oggetto: Re: informations about Linux wifi driver's architecture today

On Sun, Mar 22, 2015 at 11:19 AM, Stefano Cappa
  wrote:

Hi!
some months ago, i saw the presentation of Johannes Berg in PDF, but now it 
isn't available, probably because it's very old.

This slides will be updated to a new release?

I have this slide and in page 5/35 (2009-02-26) there is the "Architecture - 
planned". This is the actual architecture or there are some differences in 2015? If 
yes, where i can find the new version of this page, with a little diagram?


Ciao Stefano,

Perhaps Johannes can post a current overview diagram on the Linux
wireless wiki (if you share with him which diagram you want to be
updated).

In terms of vendor-specific architecture, and how it fits in, Kalle
Valo posted a high-level diagram for ath10k:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/architecture

Are you mainly interested in the architecture of vendor-agnostic upper
layers or a description of a specific vendor driver?
kg--
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


--
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] ath10k: fix aid setup in station mode

[Michal Kazior]

While debugging something else I noticed AID was
set to 0. This could lead to powersave issues in
station mode. Maybe this isn't really necessary
but set it properly just to be sure.

Signed-off-by: Michal Kazior 
---
 drivers/net/wireless/ath/ath10k/mac.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 506e886..f2b4a49 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1605,12 +1605,18 @@ static void ath10k_peer_assoc_h_basic(struct ath10k *ar,
  struct wmi_peer_assoc_complete_arg *arg)
 {
struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+   u32 aid;
 
lockdep_assert_held(&ar->conf_mutex);
 
+   if (vif->type == NL80211_IFTYPE_STATION)
+   aid = vif->bss_conf.aid;
+   else
+   aid = sta->aid;
+
ether_addr_copy(arg->addr, sta->addr);
arg->vdev_id = arvif->vdev_id;
-   arg->peer_aid = sta->aid;
+   arg->peer_aid = aid;
arg->peer_flags |= WMI_PEER_AUTH;
arg->peer_listen_intval = ath10k_peer_assoc_h_listen_intval(ar, vif);
arg->peer_num_spatial_streams = 1;
-- 
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

Re: Broadcom 43340

[Arend van Spriel]

On 03/22/15 21:14, Jürgen Bausa wrote:

Arend van Spriel  writes:



On 03/21/15 21:38, Jürgen Bausa wrote:

1. the nvram file under /sys/firmware/efi/efivars/ has a wrong MAC address.
I changed it to the correct one. However, I am not sure if this is really
necassary.


That MAC address is only used for device that do have mac address in the
device so you can ignore that one.


You are right, found it out mayself in the meantime. There is no need to
change the MAC address.




2. Found the following on the web:


rmmod brcmfmac
rmmod brcmutil
echo on>   /sys/bus/platform/drivers/sdhci-acpi/INT33BB\:00/power/control
modprobe brcmfmac


After this, I can connect to wlan!


Ah, I was wondering what type of sdio host controller was used. When
sdio host controller uses runtime-pm it affect communication with wlan
device. I recently posted a patch for that [1].


So, do I understand correctly, that with your patch the above workaround
will no longer be needed? In which kernel will your patch be included? As
wifi is working now, I would avoid installing the patch and instead wait for
the next kernel.


Indeed. The patch basically does the same thing as the workaround. It is 
applied to wireless-drivers-next tree so it will be in 4.1 kernel. So it 
will take a while before that gets released by Linus. 4.1-rc1 will 
probably take approx. 6-7 wks.





Does this give you enough information to find out, what the problem is? Or
do you still need DBG output from the driver? if so, just tell me and I will
try to compile and install the kernel with DBG turnded on. Its not a big
deal but I stopped working on it as I found this workaround.

At the momment I am trying to put these commands to rc,local. With limited
success until now, But this may be caused by the fact, that they are
executed too early. Will add some sleep.


Might be the driver is already loaded before root file system is loaded
(from initramfs).


I now got it working. Just put 'sleeep 20' before the commands and now it
works perfectly.


Holding the boot for 20s is steep, but I guess a working device trumps a 
fast boot ;-)





Another thing I found out is, that the system sometimes comes up without
wlan0. It seems I have it only on every second boot. However, this could be
just by incident and it is not exactly every second boot but about 50 % of
all boots.


Is that after reboot or really after powerup. Curious whether there is a
difference between the two regarding this issue.



It was after reboot and at cold boot.

However, this problem seems to be gone. wlan0 is up on every boot. In the
meantime i upgraded to rc4. Could this be the reason?


Nothing in brcmfmac is changed that would explain this. Maybe something 
was fixed in sdio host controller, but it is all speculation.



Do you still need some dbg information from my machine? If so, just tell me
and I will install a kernel with the needed options. Otherwise, I will stay
with the current situation.


If you are happy and the issue seems resolved there is no need. Thanks.


Ok, thanks. Will the driver also enable bluetooth? As I read, the
bcm43341 also has Bluetooth capabilities.


It has, but no clue what host interface is used. Anyway, it will have
a separate driver.


Do you now, if there is some development going on for the bluetooth driver?
Who could I conact?


I am not sure what host-interface is used to bt part. Is it usb or uart? 
I know there are plans to mainline the bt uart driver, but not sure when 
that will make its way into the kernel. If it is usb you should be able 
to use btusb driver, but you need firmware. They added support for 
handling firmware in btusb recently.


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 v4 5/6] ath10k: add wmi support for tdls

[Arik Nemtsov]

On Mon, Mar 23, 2015 at 10:59 AM, Marek Puzyniak
 wrote:
> On 23 March 2015 at 09:09, Michal Kazior  wrote:
>> On 22 March 2015 at 08:49, Arik Nemtsov  wrote:
>>> On Fri, Mar 20, 2015 at 1:02 PM, Marek Puzyniak
>>>  wrote:
 As a part of tdls implementation introduce
 tdls related wmi data structures, constant
 values and functions.

 Signed-off-by: Marek Puzyniak 
 ---
  drivers/net/wireless/ath/ath10k/wmi-ops.h |  42 
  drivers/net/wireless/ath/ath10k/wmi-tlv.c | 153 
 ++
  drivers/net/wireless/ath/ath10k/wmi-tlv.h |  53 +++
  drivers/net/wireless/ath/ath10k/wmi.h |  37 
  4 files changed, 285 insertions(+)
>>> [...]
 +
 +   cmd = (void *)tlv->value;
 +   cmd->vdev_id = __cpu_to_le32(vdev_id);
 +   cmd->state = __cpu_to_le32(state);
 +   cmd->notification_interval_ms = __cpu_to_le32(5000);
 +   cmd->tx_discovery_threshold = __cpu_to_le32(100);
 +   cmd->tx_teardown_threshold = __cpu_to_le32(5);
 +   cmd->rssi_teardown_threshold = __cpu_to_le32(-75);
 +   cmd->rssi_delta = __cpu_to_le32(-20);
 +   cmd->tdls_options = __cpu_to_le32(options);
 +   cmd->tdls_peer_traffic_ind_window = __cpu_to_le32(2);
 +   cmd->tdls_peer_traffic_response_timeout_ms = __cpu_to_le32(5000);
 +   cmd->tdls_puapsd_mask = __cpu_to_le32(0xf);
 +   cmd->tdls_puapsd_inactivity_time_ms = __cpu_to_le32(0);
 +   cmd->tdls_puapsd_rx_frame_threshold = __cpu_to_le32(10);
>>>
>>> Do the above lines assume all TDLS peers support TDLS buffer-sta
>>> (which is required for peer UAPSD)? Especially the value of
>>> tdls_puapsd_mask.
>
> No. The function you reffer to configures device itself not TDLS
> peers. Currently tdls peer uapsd buffer sta is not implemented as
> Michał wrote.

If the device configures UAPSD queues for itself, then it requires
buffer-sta support from its peer, not from itself.
But you've reassured me you don't require this from the peer, as it
would hurt ath10k vs. ath10k TDLS connections.

Arik
--
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: remove an unneede NULL check in mwifiex_init_adapter()

[Dan Carpenter]

"adapter->sleep_cfm" is always non-NULL at this point.  Static checkers
complain that we already dereference it at the start of the function
when we do:

skb_put(adapter->sleep_cfm, sizeof(struct mwifiex_opt_sleep_confirm));

Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/wireless/mwifiex/init.c 
b/drivers/net/wireless/mwifiex/init.c
index 6936de8..e12192f 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -266,18 +266,15 @@ static void mwifiex_init_adapter(struct mwifiex_adapter 
*adapter)
 
mwifiex_wmm_init(adapter);
 
-   if (adapter->sleep_cfm) {
-   sleep_cfm_buf = (struct mwifiex_opt_sleep_confirm *)
-   adapter->sleep_cfm->data;
-   memset(sleep_cfm_buf, 0, adapter->sleep_cfm->len);
-   sleep_cfm_buf->command =
-   cpu_to_le16(HostCmd_CMD_802_11_PS_MODE_ENH);
-   sleep_cfm_buf->size =
-   cpu_to_le16(adapter->sleep_cfm->len);
-   sleep_cfm_buf->result = 0;
-   sleep_cfm_buf->action = cpu_to_le16(SLEEP_CONFIRM);
-   sleep_cfm_buf->resp_ctrl = cpu_to_le16(RESP_NEEDED);
-   }
+   sleep_cfm_buf = (struct mwifiex_opt_sleep_confirm *)
+   adapter->sleep_cfm->data;
+   memset(sleep_cfm_buf, 0, adapter->sleep_cfm->len);
+   sleep_cfm_buf->command = cpu_to_le16(HostCmd_CMD_802_11_PS_MODE_ENH);
+   sleep_cfm_buf->size = cpu_to_le16(adapter->sleep_cfm->len);
+   sleep_cfm_buf->result = 0;
+   sleep_cfm_buf->action = cpu_to_le16(SLEEP_CONFIRM);
+   sleep_cfm_buf->resp_ctrl = cpu_to_le16(RESP_NEEDED);
+
memset(&adapter->sleep_params, 0, sizeof(adapter->sleep_params));
memset(&adapter->sleep_period, 0, sizeof(adapter->sleep_period));
adapter->tx_lock_flag = false;
--
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 v4 5/6] ath10k: add wmi support for tdls

[Marek Puzyniak]

On 23 March 2015 at 09:09, Michal Kazior  wrote:
> On 22 March 2015 at 08:49, Arik Nemtsov  wrote:
>> On Fri, Mar 20, 2015 at 1:02 PM, Marek Puzyniak
>>  wrote:
>>> As a part of tdls implementation introduce
>>> tdls related wmi data structures, constant
>>> values and functions.
>>>
>>> Signed-off-by: Marek Puzyniak 
>>> ---
>>>  drivers/net/wireless/ath/ath10k/wmi-ops.h |  42 
>>>  drivers/net/wireless/ath/ath10k/wmi-tlv.c | 153 
>>> ++
>>>  drivers/net/wireless/ath/ath10k/wmi-tlv.h |  53 +++
>>>  drivers/net/wireless/ath/ath10k/wmi.h |  37 
>>>  4 files changed, 285 insertions(+)
>> [...]
>>> +
>>> +   cmd = (void *)tlv->value;
>>> +   cmd->vdev_id = __cpu_to_le32(vdev_id);
>>> +   cmd->state = __cpu_to_le32(state);
>>> +   cmd->notification_interval_ms = __cpu_to_le32(5000);
>>> +   cmd->tx_discovery_threshold = __cpu_to_le32(100);
>>> +   cmd->tx_teardown_threshold = __cpu_to_le32(5);
>>> +   cmd->rssi_teardown_threshold = __cpu_to_le32(-75);
>>> +   cmd->rssi_delta = __cpu_to_le32(-20);
>>> +   cmd->tdls_options = __cpu_to_le32(options);
>>> +   cmd->tdls_peer_traffic_ind_window = __cpu_to_le32(2);
>>> +   cmd->tdls_peer_traffic_response_timeout_ms = __cpu_to_le32(5000);
>>> +   cmd->tdls_puapsd_mask = __cpu_to_le32(0xf);
>>> +   cmd->tdls_puapsd_inactivity_time_ms = __cpu_to_le32(0);
>>> +   cmd->tdls_puapsd_rx_frame_threshold = __cpu_to_le32(10);
>>
>> Do the above lines assume all TDLS peers support TDLS buffer-sta
>> (which is required for peer UAPSD)? Especially the value of
>> tdls_puapsd_mask.

No. The function you reffer to configures device itself not TDLS
peers. Currently tdls peer uapsd buffer sta is not implemented as
Michał wrote.

>> I can assure you not all peers support this :) For instance iwlwifi
>> does not (for now).
>>
>> But I might be misinterpreting this - perhaps there some other code in
>> the driver/FW that checks the peer's extended-capabilities IE for
>> buffer-sta support (bit 28)?
>> That would be the best option.

Currently ath10k tdls device also has this bit not set. During tdls
setup phase ath10k creates data structures for tdls peer sta but also
there support for tdls peer sta power save is disabled. I think there
is no information about tdls peer sta power save from mac80211 that's
why ath10k assumes no power save support by tdls peer sta. So bit 28
in extended capabilities IE is even not checked.

>
> ath10k doesn't support buffer-sta as well. Firmware requires
> additional tdls_options flags (WMI_TLV_TDLS_BUFFER_STA_EN and
> WMI_TLV_TDLS_SLEEP_STA_EN) to be set before it considers these values.
>
>
> Michał

Marek
--
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] mwifiex: stop command path in suspend handler

[Avinash Patil]

Cancel all pending commands including scan commands and stop CAC
during cfg80211 suspend handler.

Signed-off-by: Avinash Patil 
---
 drivers/net/wireless/mwifiex/cfg80211.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/cfg80211.c 
b/drivers/net/wireless/mwifiex/cfg80211.c
index fc3bbe7..eab110b 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -2942,15 +2942,23 @@ static int mwifiex_cfg80211_suspend(struct wiphy *wiphy,
 {
struct mwifiex_adapter *adapter = mwifiex_cfg80211_get_adapter(wiphy);
struct mwifiex_ds_hs_cfg hs_cfg;
-   int ret = 0;
-   struct mwifiex_private *priv =
-   mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA);
+   int i, ret = 0;
+   struct mwifiex_private *priv;
+
+   for (i = 0; i < adapter->priv_num; i++) {
+   priv = adapter->priv[i];
+   mwifiex_abort_cac(priv);
+   }
+
+   mwifiex_cancel_all_pending_cmd(adapter);
 
if (!wowlan) {
dev_warn(adapter->dev, "None of the WOWLAN triggers enabled\n");
return 0;
}
 
+   priv = mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA);
+
if (!priv->media_connected) {
dev_warn(adapter->dev,
 "Can not configure WOWLAN in disconnected state\n");
-- 
1.8.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

[PATCH 2/2] mwifiex: recover from skb allocation failures during RX

[Avinash Patil]

From: Zhaoyang Liu 

This patch adds recovery mechanism for SDIO RX during SKB allocation
failures.
For allocation failures during multiport aggregation, we skip and drop RX
packets.
For single port read case, we will use preallocated card->mpa_rx.buf to
complete cmd53 read.
Now we terminate SDIO operations only upon cmd53 failures.

CC: James Cameron 
Signed-off-by: Zhaoyang Liu 
Signed-off-by: Avinash Patil 
---
 drivers/net/wireless/mwifiex/sdio.c | 42 +
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/sdio.c 
b/drivers/net/wireless/mwifiex/sdio.c
index 6af7a082..d10320f 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -1317,10 +1317,14 @@ static int mwifiex_sdio_card_to_host_mp_aggr(struct 
mwifiex_adapter *adapter,
skb_deaggr = mwifiex_alloc_dma_align_buf(len_arr[pind],
 GFP_KERNEL |
 GFP_DMA);
-   if (!skb_deaggr)
-   goto error;
+   if (!skb_deaggr) {
+   dev_err(adapter->dev, "skb allocation failure 
drop pkt len=%d type=%d\n",
+   pkt_len, pkt_type);
+   curr_ptr += len_arr[pind];
+   continue;
+   }
+
skb_put(skb_deaggr, len_arr[pind]);
-   card->mpa_rx.skb_arr[pind] = skb_deaggr;
 
if ((pkt_type == MWIFIEX_TYPE_DATA ||
 (pkt_type == MWIFIEX_TYPE_AGGR_DATA &&
@@ -1335,7 +1339,7 @@ static int mwifiex_sdio_card_to_host_mp_aggr(struct 
mwifiex_adapter *adapter,
mwifiex_decode_rx_packet(adapter, skb_deaggr,
 pkt_type);
} else {
-   dev_err(adapter->dev, "wrong aggr pkt:\t"
+   dev_err(adapter->dev, " drop wrong aggr pkt:\t"
"sdio_single_port_rx_aggr=%d\t"
"type=%d len=%d max_len=%d\n",
adapter->sdio_rx_aggr_enable,
@@ -1352,9 +1356,18 @@ rx_curr_single:
if (f_do_rx_cur) {
dev_dbg(adapter->dev, "info: RX: port: %d, rx_len: %d\n",
port, rx_len);
+
skb = mwifiex_alloc_dma_align_buf(rx_len, GFP_KERNEL | GFP_DMA);
-   if (!skb)
-   goto error;
+   if (!skb) {
+   dev_err(adapter->dev, "single skb allocated fail,\t"
+   "drop pkt port=%d len=%d\n", port, rx_len);
+   if (mwifiex_sdio_card_to_host(adapter, &pkt_type,
+ card->mpa_rx.buf, rx_len,
+ adapter->ioport + port))
+   goto error;
+   return 0;
+   }
+
skb_put(skb, rx_len);
 
if (mwifiex_sdio_card_to_host(adapter, &pkt_type,
@@ -1363,10 +1376,11 @@ rx_curr_single:
goto error;
if (!adapter->sdio_rx_aggr_enable &&
pkt_type == MWIFIEX_TYPE_AGGR_DATA) {
-   dev_err(adapter->dev, "Wrong pkt type %d\t"
-   "Current SDIO RX Aggr not enabled\n",
+   dev_err(adapter->dev, "drop wrong pkt type %d\t"
+   "current SDIO RX Aggr not enabled\n",
pkt_type);
-   goto error;
+   dev_kfree_skb_any(skb);
+   return 0;
}
 
mwifiex_decode_rx_packet(adapter, skb, pkt_type);
@@ -1379,16 +1393,8 @@ rx_curr_single:
 
return 0;
 error:
-   if (MP_RX_AGGR_IN_PROGRESS(card)) {
-   /* Multiport-aggregation transfer failed - cleanup */
-   for (pind = 0; pind < card->mpa_rx.pkt_cnt; pind++) {
-   /* copy pkt to deaggr buf */
-   skb_deaggr = card->mpa_rx.skb_arr[pind];
-   if (skb_deaggr)
-   dev_kfree_skb_any(skb_deaggr);
-   }
+   if (MP_RX_AGGR_IN_PROGRESS(card))
MP_RX_AGGR_BUF_RESET(card);
-   }
 
if (f_do_rx_cur && skb)
/* Single transfer pending. Free curr buff also */
-- 
1.8.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

Re: [PATCH v7 6/6] wlcore: remove wl12xx_platform_data

[Sekhar Nori]

On Monday 23 March 2015 01:57 PM, Eliad Peller wrote:
>> I was applying the whole series, but over v4.0-rc1 :) Its best to
>> mention the baseline in cover-letter itself.
>>
> check out again the cover-letter. you probably overlooked it :)

I see it now :)

Thanks,
Sekhar
--
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 v7 6/6] wlcore: remove wl12xx_platform_data

[Eliad Peller]

On Mon, Mar 23, 2015 at 10:21 AM, Sekhar Nori  wrote:
>>> On Wednesday 18 March 2015 10:08 PM, Eliad Peller wrote:
 Now that we have wlcore device-tree bindings in place
 (for both wl12xx and wl18xx), remove the legacy
 wl12xx_platform_data struct, and move its members
 into the platform device data (that is passed to wlcore)

 Davinci 850 is the only platform that still set
 the platform data in the legacy way (and doesn't
 have DT bindings), so remove the relevant
 code/Kconfig option from the board file (as suggested
 by Sekhar Nori)

 Since no one currently uses wlcore_spi, simply remove its
 platform data support (DT bindings will have to be added
 if someone actually needs it)

 Signed-off-by: Luciano Coelho 
 Signed-off-by: Eliad Peller 
 ---
 v7:
 * fix spi compilation (Tony)
 * remove irq/irq_trigger from wlcore_platdev_data (they are
   being passed separately)

  arch/arm/mach-davinci/Kconfig  |  11 ---
  arch/arm/mach-davinci/board-da850-evm.c| 113 
 -
  drivers/net/wireless/ti/wilink_platform_data.c |  25 --
  drivers/net/wireless/ti/wl12xx/main.c  |  19 ++---
  drivers/net/wireless/ti/wlcore/boot.c  |   1 -
  drivers/net/wireless/ti/wlcore/main.c  |   4 +-
  drivers/net/wireless/ti/wlcore/sdio.c  |  76 +
  drivers/net/wireless/ti/wlcore/spi.c   |   6 +-
  drivers/net/wireless/ti/wlcore/wlcore_i.h  |   6 +-
  include/linux/wl12xx.h |  25 --
  10 files changed, 35 insertions(+), 251 deletions(-)
>>>
>>> The patch looks good to me, but it will be nice to know to which base it
>>> applies cleanly. I tried applying to v4.0-rc1 and linux-next and both
>>> failed.
>>>
>> The patchset was rebased on top of v4.0-rc4.
>> (Note that you'll have to apply the whole series, as this patch relies
>> on some intermediate changes done by the previous patches in the
>> patchset)
>
> I was applying the whole series, but over v4.0-rc1 :) Its best to
> mention the baseline in cover-letter itself.
>
check out again the cover-letter. you probably overlooked it :)

> The DA850 related changes in the patch look good to me.
>
> Acked-by: Sekhar Nori 
>
thanks,
Eliad.
--
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 v7 6/6] wlcore: remove wl12xx_platform_data

[Sekhar Nori]

On Monday 23 March 2015 01:36 PM, Eliad Peller wrote:
> hi Sekhar,
> 
> On Mon, Mar 23, 2015 at 9:51 AM, Sekhar Nori  wrote:
>> + Ido
>>
>> On Wednesday 18 March 2015 10:08 PM, Eliad Peller wrote:
>>> Now that we have wlcore device-tree bindings in place
>>> (for both wl12xx and wl18xx), remove the legacy
>>> wl12xx_platform_data struct, and move its members
>>> into the platform device data (that is passed to wlcore)
>>>
>>> Davinci 850 is the only platform that still set
>>> the platform data in the legacy way (and doesn't
>>> have DT bindings), so remove the relevant
>>> code/Kconfig option from the board file (as suggested
>>> by Sekhar Nori)
>>>
>>> Since no one currently uses wlcore_spi, simply remove its
>>> platform data support (DT bindings will have to be added
>>> if someone actually needs it)
>>>
>>> Signed-off-by: Luciano Coelho 
>>> Signed-off-by: Eliad Peller 
>>> ---
>>> v7:
>>> * fix spi compilation (Tony)
>>> * remove irq/irq_trigger from wlcore_platdev_data (they are
>>>   being passed separately)
>>>
>>>  arch/arm/mach-davinci/Kconfig  |  11 ---
>>>  arch/arm/mach-davinci/board-da850-evm.c| 113 
>>> -
>>>  drivers/net/wireless/ti/wilink_platform_data.c |  25 --
>>>  drivers/net/wireless/ti/wl12xx/main.c  |  19 ++---
>>>  drivers/net/wireless/ti/wlcore/boot.c  |   1 -
>>>  drivers/net/wireless/ti/wlcore/main.c  |   4 +-
>>>  drivers/net/wireless/ti/wlcore/sdio.c  |  76 +
>>>  drivers/net/wireless/ti/wlcore/spi.c   |   6 +-
>>>  drivers/net/wireless/ti/wlcore/wlcore_i.h  |   6 +-
>>>  include/linux/wl12xx.h |  25 --
>>>  10 files changed, 35 insertions(+), 251 deletions(-)
>>
>> The patch looks good to me, but it will be nice to know to which base it
>> applies cleanly. I tried applying to v4.0-rc1 and linux-next and both
>> failed.
>>
> The patchset was rebased on top of v4.0-rc4.
> (Note that you'll have to apply the whole series, as this patch relies
> on some intermediate changes done by the previous patches in the
> patchset)

I was applying the whole series, but over v4.0-rc1 :) Its best to
mention the baseline in cover-letter itself.

The DA850 related changes in the patch look good to me.

Acked-by: Sekhar Nori 

Thanks,
Sekhar

--
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 v4 5/6] ath10k: add wmi support for tdls

[Michal Kazior]

On 22 March 2015 at 08:49, Arik Nemtsov  wrote:
> On Fri, Mar 20, 2015 at 1:02 PM, Marek Puzyniak
>  wrote:
>> As a part of tdls implementation introduce
>> tdls related wmi data structures, constant
>> values and functions.
>>
>> Signed-off-by: Marek Puzyniak 
>> ---
>>  drivers/net/wireless/ath/ath10k/wmi-ops.h |  42 
>>  drivers/net/wireless/ath/ath10k/wmi-tlv.c | 153 
>> ++
>>  drivers/net/wireless/ath/ath10k/wmi-tlv.h |  53 +++
>>  drivers/net/wireless/ath/ath10k/wmi.h |  37 
>>  4 files changed, 285 insertions(+)
> [...]
>> +
>> +   cmd = (void *)tlv->value;
>> +   cmd->vdev_id = __cpu_to_le32(vdev_id);
>> +   cmd->state = __cpu_to_le32(state);
>> +   cmd->notification_interval_ms = __cpu_to_le32(5000);
>> +   cmd->tx_discovery_threshold = __cpu_to_le32(100);
>> +   cmd->tx_teardown_threshold = __cpu_to_le32(5);
>> +   cmd->rssi_teardown_threshold = __cpu_to_le32(-75);
>> +   cmd->rssi_delta = __cpu_to_le32(-20);
>> +   cmd->tdls_options = __cpu_to_le32(options);
>> +   cmd->tdls_peer_traffic_ind_window = __cpu_to_le32(2);
>> +   cmd->tdls_peer_traffic_response_timeout_ms = __cpu_to_le32(5000);
>> +   cmd->tdls_puapsd_mask = __cpu_to_le32(0xf);
>> +   cmd->tdls_puapsd_inactivity_time_ms = __cpu_to_le32(0);
>> +   cmd->tdls_puapsd_rx_frame_threshold = __cpu_to_le32(10);
>
> Do the above lines assume all TDLS peers support TDLS buffer-sta
> (which is required for peer UAPSD)? Especially the value of
> tdls_puapsd_mask.
> I can assure you not all peers support this :) For instance iwlwifi
> does not (for now).
>
> But I might be misinterpreting this - perhaps there some other code in
> the driver/FW that checks the peer's extended-capabilities IE for
> buffer-sta support (bit 28)?
> That would be the best option.

ath10k doesn't support buffer-sta as well. Firmware requires
additional tdls_options flags (WMI_TLV_TDLS_BUFFER_STA_EN and
WMI_TLV_TDLS_SLEEP_STA_EN) to be set before it considers these values.


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

Re: [PATCH v7 6/6] wlcore: remove wl12xx_platform_data

[Eliad Peller]

hi Sekhar,

On Mon, Mar 23, 2015 at 9:51 AM, Sekhar Nori  wrote:
> + Ido
>
> On Wednesday 18 March 2015 10:08 PM, Eliad Peller wrote:
>> Now that we have wlcore device-tree bindings in place
>> (for both wl12xx and wl18xx), remove the legacy
>> wl12xx_platform_data struct, and move its members
>> into the platform device data (that is passed to wlcore)
>>
>> Davinci 850 is the only platform that still set
>> the platform data in the legacy way (and doesn't
>> have DT bindings), so remove the relevant
>> code/Kconfig option from the board file (as suggested
>> by Sekhar Nori)
>>
>> Since no one currently uses wlcore_spi, simply remove its
>> platform data support (DT bindings will have to be added
>> if someone actually needs it)
>>
>> Signed-off-by: Luciano Coelho 
>> Signed-off-by: Eliad Peller 
>> ---
>> v7:
>> * fix spi compilation (Tony)
>> * remove irq/irq_trigger from wlcore_platdev_data (they are
>>   being passed separately)
>>
>>  arch/arm/mach-davinci/Kconfig  |  11 ---
>>  arch/arm/mach-davinci/board-da850-evm.c| 113 
>> -
>>  drivers/net/wireless/ti/wilink_platform_data.c |  25 --
>>  drivers/net/wireless/ti/wl12xx/main.c  |  19 ++---
>>  drivers/net/wireless/ti/wlcore/boot.c  |   1 -
>>  drivers/net/wireless/ti/wlcore/main.c  |   4 +-
>>  drivers/net/wireless/ti/wlcore/sdio.c  |  76 +
>>  drivers/net/wireless/ti/wlcore/spi.c   |   6 +-
>>  drivers/net/wireless/ti/wlcore/wlcore_i.h  |   6 +-
>>  include/linux/wl12xx.h |  25 --
>>  10 files changed, 35 insertions(+), 251 deletions(-)
>
> The patch looks good to me, but it will be nice to know to which base it
> applies cleanly. I tried applying to v4.0-rc1 and linux-next and both
> failed.
>
The patchset was rebased on top of v4.0-rc4.
(Note that you'll have to apply the whole series, as this patch relies
on some intermediate changes done by the previous patches in the
patchset)

Eliad.
--
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 v7 6/6] wlcore: remove wl12xx_platform_data

[Sekhar Nori]

+ Ido

On Wednesday 18 March 2015 10:08 PM, Eliad Peller wrote:
> Now that we have wlcore device-tree bindings in place
> (for both wl12xx and wl18xx), remove the legacy
> wl12xx_platform_data struct, and move its members
> into the platform device data (that is passed to wlcore)
> 
> Davinci 850 is the only platform that still set
> the platform data in the legacy way (and doesn't
> have DT bindings), so remove the relevant
> code/Kconfig option from the board file (as suggested
> by Sekhar Nori)
> 
> Since no one currently uses wlcore_spi, simply remove its
> platform data support (DT bindings will have to be added
> if someone actually needs it)
> 
> Signed-off-by: Luciano Coelho 
> Signed-off-by: Eliad Peller 
> ---
> v7:
> * fix spi compilation (Tony)
> * remove irq/irq_trigger from wlcore_platdev_data (they are
>   being passed separately)
> 
>  arch/arm/mach-davinci/Kconfig  |  11 ---
>  arch/arm/mach-davinci/board-da850-evm.c| 113 
> -
>  drivers/net/wireless/ti/wilink_platform_data.c |  25 --
>  drivers/net/wireless/ti/wl12xx/main.c  |  19 ++---
>  drivers/net/wireless/ti/wlcore/boot.c  |   1 -
>  drivers/net/wireless/ti/wlcore/main.c  |   4 +-
>  drivers/net/wireless/ti/wlcore/sdio.c  |  76 +
>  drivers/net/wireless/ti/wlcore/spi.c   |   6 +-
>  drivers/net/wireless/ti/wlcore/wlcore_i.h  |   6 +-
>  include/linux/wl12xx.h |  25 --
>  10 files changed, 35 insertions(+), 251 deletions(-)

The patch looks good to me, but it will be nice to know to which base it
applies cleanly. I tried applying to v4.0-rc1 and linux-next and both
failed.

Thanks,
Sekhar
--
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 2/2] ath10k: allow user to toggle ani_enable via debugfs

[Ashok Raj Nagarajan]

On Fri, Mar 20, 2015 at 10:28:06AM +0100, Jose Antonio Delgado Alfonso wrote:
> Hi Ashok,
> 
> Just a quick question, is it supported by all firmware versions?
> 
Yes Jose. It is supported by all firmware versions.

Thanks,
Ashok
> Thanks,
> Jose A. Delgado
> 
> On 19/03/15 12:08, Ashok Raj Nagarajan wrote:
> > Now that ANI is enabled by default, allow user to disable or enable ANI 
> > feature
> > from debugfs
> >
> > echo 0|1 > /sys/kernel/debug/ieee80211/phyX/ath10k/ani_enable
> >
> > Signed-off-by: Ashok Raj Nagarajan 
> > ---
> > v2:
> > Updated commit log
> > Lock ar->ani_enabled (Kalle Valo)
> > remove reduntant debug message (Kalle Valo)
> >
> >  drivers/net/wireless/ath/ath10k/core.h  |  2 ++
> >  drivers/net/wireless/ath/ath10k/debug.c | 58 
> > +
> >  drivers/net/wireless/ath/ath10k/mac.c   |  2 ++
> >  3 files changed, 62 insertions(+)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.h 
> > b/drivers/net/wireless/ath/ath10k/core.h
> > index 7cba781..29e0a8b 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.h
> > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > @@ -510,6 +510,8 @@ struct ath10k {
> > u32 ht_cap_info;
> > u32 vht_cap_info;
> > u32 num_rf_chains;
> > +   /* protected by conf_mutex */
> > +   bool ani_enabled;
> >  
> > DECLARE_BITMAP(fw_features, ATH10K_FW_FEATURE_COUNT);
> >  
> > diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
> > b/drivers/net/wireless/ath/ath10k/debug.c
> > index 301081d..481e1cc 100644
> > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > @@ -1708,6 +1708,61 @@ static int ath10k_debug_cal_data_release(struct 
> > inode *inode,
> > return 0;
> >  }
> >  
> > +static ssize_t ath10k_write_ani_enable(struct file *file,
> > +  const char __user *user_buf,
> > +  size_t count, loff_t *ppos)
> > +{
> > +   struct ath10k *ar = file->private_data;
> > +   int ret;
> > +   u8 enable;
> > +
> > +   if (kstrtou8_from_user(user_buf, count, 0, &enable))
> > +   return -EINVAL;
> > +
> > +   mutex_lock(&ar->conf_mutex);
> > +
> > +   if (ar->ani_enabled == enable) {
> > +   ret = count;
> > +   goto exit;
> > +   }
> > +
> > +   ret = ath10k_wmi_pdev_set_param(ar, ar->wmi.pdev_param->ani_enable,
> > +   enable);
> > +   if (ret) {
> > +   ath10k_warn(ar, "ani_enable failed from debugfs: %d\n", ret);
> > +   goto exit;
> > +   }
> > +   ar->ani_enabled = enable;
> > +
> > +   ret = count;
> > +
> > +exit:
> > +   mutex_unlock(&ar->conf_mutex);
> > +
> > +   return ret;
> > +}
> > +
> > +static ssize_t ath10k_read_ani_enable(struct file *file, char __user 
> > *user_buf,
> > + size_t count, loff_t *ppos)
> > +{
> > +   struct ath10k *ar = file->private_data;
> > +   int len = 0;
> > +   char buf[32];
> > +
> > +   len = scnprintf(buf, sizeof(buf) - len, "%d\n",
> > +   ar->ani_enabled);
> > +
> > +   return simple_read_from_buffer(user_buf, count, ppos, buf, len);
> > +}
> > +
> > +static const struct file_operations fops_ani_enable = {
> > +   .read = ath10k_read_ani_enable,
> > +   .write = ath10k_write_ani_enable,
> > +   .open = simple_open,
> > +   .owner = THIS_MODULE,
> > +   .llseek = default_llseek,
> > +};
> > +
> >  static const struct file_operations fops_cal_data = {
> > .open = ath10k_debug_cal_data_open,
> > .read = ath10k_debug_cal_data_read,
> > @@ -2068,6 +2123,9 @@ int ath10k_debug_register(struct ath10k *ar)
> > debugfs_create_file("cal_data", S_IRUSR, ar->debug.debugfs_phy,
> > ar, &fops_cal_data);
> >  
> > +   debugfs_create_file("ani_enable", S_IRUSR | S_IWUSR,
> > +   ar->debug.debugfs_phy, ar, &fops_ani_enable);
> > +
> > debugfs_create_file("nf_cal_period", S_IRUSR | S_IWUSR,
> > ar->debug.debugfs_phy, ar, &fops_nf_cal_period);
> >  
> > diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> > b/drivers/net/wireless/ath/ath10k/mac.c
> > index 380d4b1..366c96f 100644
> > --- a/drivers/net/wireless/ath/ath10k/mac.c
> > +++ b/drivers/net/wireless/ath/ath10k/mac.c
> > @@ -2904,6 +2904,8 @@ static int ath10k_start(struct ieee80211_hw *hw)
> > goto err_core_stop;
> > }
> >  
> > +   ar->ani_enabled = true;
> > +
> > ar->num_started_vdevs = 0;
> > ath10k_regd_update(ar);
> >  
> 
> 
> -- 
> 
> 
> Jose Antonio Delgado Alfonso
> Chief Technology Officer
> 
> Calle Itálica 1, 1ª Planta
> 41900 Camas (Sevilla)
> 
> Email: jose.delg...@aoifes.com 
> Tel: (+34) 955 228 533
> Tel2: (+34) 651 695 494
> Skype: jdelgadoalfonso
> Web: www.aoifes.com 
> 
> 
> La inform