date:20160310

Re: carl1970: stops working at random periods on Ubuntu 15.05

2016-03-10 Thread alexander nekrasov

Thanks for an answer, Christian! Adapter is getting hot sometimes
indeed. Also my adapter is usb2.0 but it was on extender with another
usb1.1 device. I plugged it into motherboards port directly but issue
still continue to happens. I  also tried reload host controller but it
did not help. However I discovered strange behavior. Here is my
scenario:
1. boot system
2. check device is displayed by 'lsusb' and 'lsusb -t'
3. unbind and bind root hub where device is plugged into
4. this time 'lsusb' does list device and 'lsusb -t' does not

Is it ok?

After unbind/bind device definitely is not working - there is led
indicator and it is off. Should I 'enable' device after binding root
hub with another command?

On 28 February 2016 at 23:33, alexander nekrasov  wrote:
> Thanks for an answer, Christian! Adapter is getting hot sometimes
> indeed. I will try reload host controller next time it happens, but
> I'm afraid Im to newbie to do the 'usb data stream debugging' =) I'm
> also reading link maybe it'll help me. Thanks again
>
> On 28 February 2016 at 14:27, Christian Lamparter
>  wrote:
>> Hello,
>>
>> On Sunday, February 28, 2016 03:06:35 AM alexander nekrasov wrote:
>>> I'm using TP-LINK TL-WN821N and encountering very annoying behaviour -
>>> adapter 'hangs' at random period of time - sometimes it is 1 hour,
>>> sometimes 2. After it hangs Network manager does not see any wireless
>>> networks and the only way to make it work is to reboot system (also
>>> tried unplugging/plugging adapter and removing/adding module but it
>>> did not work)
>> Did it get hot? Or Have you tried unloading/reloading the ohci/ehci/xhci?
>> The used USB-PHY FUSB200 (in the AR9170) is known to misbehave. If you
>> want to read more about the implications and possible solution, you can
>> visit the ath9k_htc firmware community. They have written a wiki entry
>> which describes the issues in detail [0].
>>
>>> Heres lsusb -v:
>>> Bus 004 Device 004: ID 0cf3:1002 Atheros Communications, Inc. TP-Link
>>> TL-WN821N v2 / TL-WN822N v1 802.11n [Atheros AR9170]
>>>
>>> And here what i have in syslog right before the hang:
>>> Following messages are also relevant to adapter failure but i guess it
>>> will be to long to post it here.
>>>
>>> Feb 28 01:46:53 evren kernel: [ 4978.753087] usb 4-1.4: no command
>>> feedback received (-90).
>>> Feb 28 01:46:53 evren kernel: [ 4978.753098] usb 4-1.4: restart device (6)
>>> Feb 28 01:46:54 evren kernel: [ 4979.891093] usb 4-1.4: device
>>> restarted successfully.
>>> Feb 28 01:46:54 evren kernel: [ 4979.899273] ieee80211 phy1: Hardware
>>> restart was requested
>> Commands are issued on the devices end point #4 And the response the
>> driver is waiting for doesn't get through. If you want to debug this,
>> you'll need to look at the usb data stream and check which party (host
>> controller (ehci/ohci), device (AR9170) or cable?) is at fault.
>>
>> Regards,
>> Christian
>>
>> [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

[PATCH v2] ath10k: fix debugfs pktlog_filter write

2016-03-10 Thread akolli

From: Anilkumar Kolli 

It is observed that, we are disabling the packet log if we write same
value to the pktlog_filter for the second time. Always enable pktlogs
on non zero filter.

Fixes: 90174455ae05 ("ath10k: add support to configure pktlog filter")
Cc: sta...@vger.kernel.org
Signed-off-by: Anilkumar Kolli 
---
v2:
 * added sta...@vger.kernel.org

 drivers/net/wireless/ath/ath10k/debug.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index 076d29b53ddf..0f834646e6a7 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2019,7 +2019,12 @@ static ssize_t ath10k_write_pktlog_filter(struct file 
*file,
goto out;
}
 
-   if (filter && (filter != ar->debug.pktlog_filter)) {
+   if (filter == ar->debug.pktlog_filter) {
+   ret = count;
+   goto out;
+   }
+
+   if (filter) {
ret = ath10k_wmi_pdev_pktlog_enable(ar, filter);
if (ret) {
ath10k_warn(ar, "failed to enable pktlog filter %x: 
%d\n",
-- 
1.7.9.5

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

Re: pull request: iwlwifi -21.ucode firmware

2016-03-10 Thread Kyle McMartin

On Thu, Mar 10, 2016 at 07:15:31PM +, Grumbach, Emmanuel wrote:
> > Pulled, can you follow this up and update WHENCE? I'd do it, but there's
> > a lack of consistency between Version: and some of the past commit
> > messages, so I'm not sure what the right value would be.
> > 
> 
> Ooops - sorry:
> 

no worries, gotcha.

--kyle

> e6dedba0a09221a755ae4573d70b86c804a14be2 in the same tree.
> 
> diff --git a/WHENCE b/WHENCE
> index e249c49..a9c5e98 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -897,12 +897,24 @@ Version: 25.30.13.0
>  File: iwlwifi-7265D-16.ucode
>  Version 16.242414.0
> 
> +File: iwlwifi-7265D-21.ucode
> +Version 21.302800.0
> +
> +File: iwlwifi-3168-21.ucode
> +Version 21.302800.0
> +
>  File: iwlwifi-8000C-13.ucode
>  Version: 25.30.13.0
> 
>  File: iwlwifi-8000C-16.ucode
>  Version 16.242414.0
> 
> +File: iwlwifi-8000C-21.ucode
> +Version 21.302800.0
> +
> +File: iwlwifi-8265-21.ucode
> +Version 21.302800.0
> +
>  Licence: Redistributable. See LICENCE.iwlwifi_firmware for details
> 
>  Also available from
> http://wireless.kernel.org/en/users/Drivers/iwlwifi#Firmware
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: iwlwifi -21.ucode firmware

2016-03-10 Thread Grumbach, Emmanuel



On 03/10/2016 08:50 PM, Kyle McMartin wrote:
> On Thu, Mar 10, 2016 at 07:29:15AM +, Grumbach, Emmanuel wrote:
>> Hi Kyle,
>>
>> This is a pull request to include our latest available firmware into
>> mainline linux-firmware.git.
>>
>> It includes -21.ucode for various devices including devices for which
>> this is the first supported firmware (3168 and 8265).
>> This firmware is supported starting kernel 4.6.
>>
>> Please pull!
>>
> 
> Pulled, can you follow this up and update WHENCE? I'd do it, but there's
> a lack of consistency between Version: and some of the past commit
> messages, so I'm not sure what the right value would be.
> 

Ooops - sorry:

e6dedba0a09221a755ae4573d70b86c804a14be2 in the same tree.

diff --git a/WHENCE b/WHENCE
index e249c49..a9c5e98 100644
--- a/WHENCE
+++ b/WHENCE
@@ -897,12 +897,24 @@ Version: 25.30.13.0
 File: iwlwifi-7265D-16.ucode
 Version 16.242414.0

+File: iwlwifi-7265D-21.ucode
+Version 21.302800.0
+
+File: iwlwifi-3168-21.ucode
+Version 21.302800.0
+
 File: iwlwifi-8000C-13.ucode
 Version: 25.30.13.0

 File: iwlwifi-8000C-16.ucode
 Version 16.242414.0

+File: iwlwifi-8000C-21.ucode
+Version 21.302800.0
+
+File: iwlwifi-8265-21.ucode
+Version 21.302800.0
+
 Licence: Redistributable. See LICENCE.iwlwifi_firmware for details

 Also available from
http://wireless.kernel.org/en/users/Drivers/iwlwifi#Firmware

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

2016-03-10 Thread Dave Taht

>> regular fq_codel uses 1024 and there has not been much reason to
>> change it. In the case of an AP which has more limited memory, 256 or
>> 1024 would be a good setting, per station. I'd stick to 1024 for now.
>
> Do note that the 4096 is shared _across_ station-tid queues. It is not
> per-station. If you have 10 stations you still have 4096 flows
> (actually 4096 + 16*10, because each tid - and there are 16 - has it's
> own fallback flow in case of hash collision on the global flowmap to
> maintain per-sta-tid queuing).

I have to admit I didn't parse this well - still haven't, I think I
need to draw. (got a picture?)

Where is this part happening in the code (or firmware?)

" because each tid - and there are 16 - has it's
 own fallback flow in case of hash collision on the global flowmap to
 maintain per-sta-tid queuing"

"fallback flow - hash collision on global flowmap" - huh?

> With that in mind do you still think 1024 is enough?

Can't answer that question without understanding what you said above.

I assembled a few of the patches to date (your fq_codel patch, avery's
and tims ath9k stuff) and tested them, to no measurable effect,
against linus's tree a day or two back. I also acquired an ath10k card
- would one of these suit?

http://www.amazon.com/gp/product/B011SIMFR8?psc=1=true_=oh_aui_detailpage_o08_s00
--
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: Linux-firmware: pull-request TI wireless firmware update

2016-03-10 Thread Kyle McMartin

On Thu, Mar 10, 2016 at 02:28:54PM +, Machani, Yaniv wrote:
> are available in the git repository at:
> 
>   g...@git.ti.com:wilink8-wlan/linux-firmware.git master
> 

master@linux-firmware:.% git pull
g...@git.ti.com:wilink8-wlan/linux-firmware.git master
(jkkm@dreadnought:~/src/linux-firmware)
The authenticity of host 'git.ti.com (198.47.29.151)' can't be
established.
ECDSA key fingerprint is
SHA256:eC4088VaGt0FKcYPwd6Cc71hNNnJ9qiPLPLQiER/Sr8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'git.ti.com,198.47.29.151' (ECDSA) to the
list of known hosts.
g...@git.ti.com's password: 

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

Re: pull request: iwlwifi -21.ucode firmware

2016-03-10 Thread Kyle McMartin

On Thu, Mar 10, 2016 at 07:29:15AM +, Grumbach, Emmanuel wrote:
> Hi Kyle,
> 
> This is a pull request to include our latest available firmware into
> mainline linux-firmware.git.
> 
> It includes -21.ucode for various devices including devices for which
> this is the first supported firmware (3168 and 8265).
> This firmware is supported starting kernel 4.6.
> 
> Please pull!
> 

Pulled, can you follow this up and update WHENCE? I'd do it, but there's
a lack of consistency between Version: and some of the past commit
messages, so I'm not sure what the right value would be.

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

[PATCH-v2] mac80211: Let VHT work on 2.4Ghz

2016-03-10 Thread greearb

From: Ben Greear 

ath10k supports VHT on 2.4Ghz band.
If supplicant and hostapd and radio think
VHT should be allowed, then kernel should let them
try, as long as at least one band can do 80Mhz.

If no bands can do 80Mhz, then that is an indication that
VHT is not enabled in this regulatory domain.

Signed-off-by: Ben Greear 
---
v2:  Only allow VHT on 2.4 if 80Mhz is available on at least one band.

 net/mac80211/ieee80211_i.h |  1 +
 net/mac80211/mlme.c| 15 +--
 net/mac80211/util.c| 33 +++--
 net/mac80211/vht.c | 15 ++-
 4 files changed, 27 insertions(+), 37 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 19de36f..c0dc0e2 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1800,6 +1800,7 @@ static inline int __ieee80211_resume(struct ieee80211_hw 
*hw)
 }
 
 /* utility functions/constants */
+bool ieee80211_any_band_supports_80mhz(struct ieee80211_local *local);
 extern const void *const mac80211_wiphy_privid; /* for wiphy privid */
 int ieee80211_frame_duration(enum ieee80211_band band, size_t len,
 int rate, int erp, int short_preamble,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index b63cd7d..d6e9bdc 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -4228,8 +4228,6 @@ static int ieee80211_prep_channel(struct 
ieee80211_sub_if_data *sdata,
struct ieee80211_supported_band *sband;
struct cfg80211_chan_def chandef;
int ret;
-   u32 i;
-   bool have_80mhz;
 
sband = local->hw.wiphy->bands[cbss->channel->band];
 
@@ -4280,18 +4278,7 @@ static int ieee80211_prep_channel(struct 
ieee80211_sub_if_data *sdata,
}
}
 
-   /* Allow VHT if at least one channel on the sband supports 80 MHz */
-   have_80mhz = false;
-   for (i = 0; i < sband->n_channels; i++) {
-   if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED |
-   IEEE80211_CHAN_NO_80MHZ))
-   continue;
-
-   have_80mhz = true;
-   break;
-   }
-
-   if (!have_80mhz)
+   if (!ieee80211_any_band_supports_80mhz(local))
ifmgd->flags |= IEEE80211_STA_DISABLE_VHT;
 
ifmgd->flags |= ieee80211_determine_chantype(sdata, sband,
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 56b2c27..ae90c4f 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -762,6 +762,27 @@ void ieee80211_queue_delayed_work(struct ieee80211_hw *hw,
 }
 EXPORT_SYMBOL(ieee80211_queue_delayed_work);
 
+bool ieee80211_any_band_supports_80mhz(struct ieee80211_local *local)
+{
+   int i;
+   struct ieee80211_supported_band *sband;
+
+   for (i = 0; i < IEEE80211_NUM_BANDS; i++) {
+   int q;
+   sband = local->hw.wiphy->bands[i];
+   if (!sband)
+   continue;
+   for (q = 0; q < sband->n_channels; q++) {
+   if (sband->channels[q].flags &
+   (IEEE80211_CHAN_DISABLED | IEEE80211_CHAN_NO_80MHZ))
+   continue;
+
+   return true;
+   }
+   }
+   return false;
+}
+
 u32 ieee802_11_parse_elems_crc(const u8 *start, size_t len, bool action,
   struct ieee802_11_elems *elems,
   u64 filter, u32 crc)
@@ -1375,7 +1396,7 @@ static int ieee80211_build_preq_ies_band(struct 
ieee80211_local *local,
int ext_rates_len;
int shift;
u32 rate_flags;
-   bool have_80mhz = false;
+   bool have_80mhz;
 
*offset = 0;
 
@@ -1504,15 +1525,7 @@ static int ieee80211_build_preq_ies_band(struct 
ieee80211_local *local,
*offset = noffset;
}
 
-   /* Check if any channel in this sband supports at least 80 MHz */
-   for (i = 0; i < sband->n_channels; i++) {
-   if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED |
-   IEEE80211_CHAN_NO_80MHZ))
-   continue;
-
-   have_80mhz = true;
-   break;
-   }
+   have_80mhz = ieee80211_any_band_supports_80mhz(local);
 
if (sband->vht_cap.vht_supported && have_80mhz) {
if (end - pos < 2 + sizeof(struct ieee80211_vht_cap))
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index c38b2f0..a08a77f 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -120,7 +120,7 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct 
ieee80211_sub_if_data *sdata,
struct ieee80211_sta_vht_cap *vht_cap = >sta.vht_cap;
struct ieee80211_sta_vht_cap own_cap;
u32 cap_info, i;
-   bool have_80mhz;
+   struct ieee80211_local *local = sdata->local;

Re: [PATCH] b43: fix memory leak

2016-03-10 Thread Sudip Mukherjee


On Thursday 10 March 2016 11:13 PM, Michael Büsch wrote:

On Fri, 19 Feb 2016 20:37:18 +0530
Sudip Mukherjee  wrote:


https://patchwork.kernel.org/patch/8049041/


I have an old laptop running on 800Mhz CPU. It has "Broadcom BCM4311
[14e4:4311] (rev 01)".
I will try to test it on this weekend.


Any news on this one?


No. Sorry. I was trying to install ubuntu 14.04 in it, but for some 
reason the usb stick is not moving past the boot screen. Give me two 
more days and I will let you all know by this Saturday.


regards
sudip
--
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] mac80211: Take bitrates into account when building IEs.

2016-03-10 Thread Ben Greear


On 02/23/2016 03:06 AM, Johannes Berg wrote:

On Thu, 2016-02-18 at 13:54 -0800, Ben Greear wrote:


Yeah, it does, at least if you assume that the capabilities can
actually change. We assume they don't though, hostapd/wpa_s for
example will never re-query them after startup.


Restarting supplicant, even if it came to that, might be less
of an issue than having to re-create the vdev to have it grab
proper new settings from the wiphy...



Well, it would be easy enough to make a method that updated an
vdev/sdata->vht from wiphy, so could just call that as needed (ie,
when certain things set or are changed by wiphy).


Yeah, I think we'll just have to deal with this when it comes along.
This multi-antenna-sharing case (unfortunately I forgot who was talking
about it) is the only thing that comes to mind where we really may have
to deal with this.


I started looking at making these changes...and I have a few questions.

First, are you proposing that I make a copy of the entire  
local->hw.wiphy->bands array
and store it locally in sdata?

And then, I would provide some API to modify the bands[i]->bitrates and other
variables to properly select the advertised features?

I am a bit concerned about making copies (and then changing) the driver's
bitrates array.  Likely it will work with ath10k, but it seems fragile
at best.

Or, did I mis-understand your suggestion with regards to what data structures
should be copied to sdata in mac80211 and then made modifiable?

With regard to my original patch, are there any other things that I could do to
make it more acceptable without making copies of the driver data?

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

Re: [PATCH] ath10k: fix debugfs pktlog_filter write

2016-03-10 Thread Greg KH

On Thu, Mar 10, 2016 at 02:48:58PM +0530, ako...@qti.qualcomm.com wrote:
> From: Anilkumar Kolli 
> 
> It is observed that, we are disabling the packet log if we write same
> value to the pktlog_filter for the second time. Always enable pktlogs
> on non zero filter.
> 
> Fixes: 90174455ae05 ("ath10k: add support to configure pktlog filter")
> Signed-off-by: Anilkumar Kolli 
> ---
>  drivers/net/wireless/ath/ath10k/debug.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.


--
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 054/113] rtl8xxxu: Implement 8723bu power on sequence

2016-03-10 Thread Jes Sorensen

Kalle Valo  writes:
> jes.soren...@redhat.com writes:
>
>> From: Jes Sorensen 
>>
>> This implements the 8723bu specific power on sequence as it is
>> different from that of the 8723au chips.
>>
>> Signed-off-by: Jes Sorensen 
>
> [...]
>
>> @@ -140,7 +144,10 @@
>>  #define REG_MAC_PINMUX_CFG  0x0043
>>  #define REG_GPIO_PIN_CTRL   0x0044
>>  #define REG_GPIO_INTM   0x0048
>> +#define  GPIO_INTM_EDGE_TRIG_IRQBIT(9)
>> +
>>  #define REG_LEDCFG0 0x004c
>> +#define  LEDCFG0_DPDT_SELECTBIT(23)
>>  #define REG_LEDCFG1 0x004d
>>  #define REG_LEDCFG2 0x004e
>>  #define  LEDCFG2_DPDT_SELECTBIT(7)
>> @@ -154,9 +161,13 @@
>>  #define REG_GPIO_PIN_CTRL_2 0x0060
>>  /*  RTL8723 WIFI/BT/GPS Multi-Function GPIO Select. */
>>  #define REG_GPIO_IO_SEL_2   0x0062
>> +#define  GPIO_IO_SEL_2_GPIO09_INPUT BIT(1)
>> +#define  GPIO_IO_SEL_2_GPIO09_IRQ   BIT(9)
>>  
>>  /*  RTL8723B */
>>  #define REG_PAD_CTRL1   0x0064
>> +#define  PAD_CTRL1_SW_DPDT_SEL_DATA BIT(0)
>
> Why two spaces after define?

I use two spaces for bit defines, so it refers to the register
above. It's consistent throughout the code.

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

Re: [PATCH 107/113] rtl8xxxu: Use define for REG_PWR_DATA bits

2016-03-10 Thread Jes Sorensen

Kalle Valo  writes:
> jes.soren...@redhat.com writes:
>
>> From: Jes Sorensen 
>>
>> Use the bit define rather than hard code the value for REG_PWR_DATA bits.
>>
>> Signed-off-by: Jes Sorensen 
>
> [...]
>
>> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
>> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
>> @@ -135,7 +135,7 @@
>>  #define  EFUSE_ACCESS_DISABLE   0x00/* RTL8723 only */
>>  
>>  #define REG_PWR_DATA0x0038
>> -#define PWR_DATA_EEPRPAD_RFE_CTRL_ENBIT(11)
>> +#define  PWR_DATA_EEPRPAD_RFE_CTRL_EN   BIT(11)
>
> Again the two spaces. Is your editor adding them automatically or what?

As in the previous email, this is for bit defines, matching the
register. The above just made it consistent with the rest of the code.

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

Re: [PATCH 042/113] rtl8xxxu: Initial implementation of rtl8723bu_config_channel()

2016-03-10 Thread Jes Sorensen

Kalle Valo  writes:
> jes.soren...@redhat.com writes:
>
>> From: Jes Sorensen 
>>
>> This is a first stab of implementing rtl8723bu_config_channel(). For
>> now this will only do 20MHz channels.
>>
>> Signed-off-by: Jes Sorensen 
>
> [...]
>
>> +static void rtl8723bu_config_channel(struct ieee80211_hw *hw)
>> +{
>> +struct rtl8xxxu_priv *priv = hw->priv;
>> +u32 val32, rsr;
>> +u8 val8, opmode, subchannel;
>> +u16 rf_mode_bw;
>> +bool ht = true;
>> +int sec_ch_above, channel;
>> +int i;
>> +
>> +rf_mode_bw = rtl8xxxu_read16(priv, REG_WMAC_TRXPTCL_CTL);
>> +rf_mode_bw &= ~WMAC_TRXPTCL_CTL_BW_MASK;
>> +rsr = rtl8xxxu_read32(priv, REG_RESPONSE_RATE_SET);
>> +channel = hw->conf.chandef.chan->hw_value;
>> +
>> +/* Hack */
>
> Indentation.

I can send you a v2 of this with it indented.

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

Re: [PATCH 037/113] rtl8xxxu: First stab at adding IQK calibration for 8723bu parts

2016-03-10 Thread Jes Sorensen

Kalle Valo  writes:
> jes.soren...@redhat.com writes:
>
>> From: Jes Sorensen 
>>
>> The 8723bu also has it's own IQK calibration process. This is similar
>> in flow, but still different enough to warrent it's own
>> implementation, at least for now.
>>
>> Signed-off-by: Jes Sorensen 
>> ---
>>  drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c | 811
>> -
>>  drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h   |   1 +
>>  .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h  |  17 +
>>  3 files changed, 827 insertions(+), 2 deletions(-)
>>
>
> [...]
>
>> +#ifdef RTL8723BU_BT
>> +/* GNT_BT = 1 */
>> +rtl8xxxu_write32(priv, REG_BT_CONTROL_8723BU, 0x1800);
>> +#endif
>
> What's this about?
>
>> +#ifdef RTL8723BU_BT
>> +/* GNT_BT = 1 */
>> +rtl8xxxu_write32(priv, REG_BT_CONTROL_8723BU, 0x1800);
>> +#endif
>
> Same here.
>
>> +#ifdef RTL8723BU_PATH_B
>> +static int rtl8723bu_iqk_path_b(struct rtl8xxxu_priv *priv)
>
> And this?
>
>> +#if 0
>> +/* Page B init */
>> +rtl8xxxu_write32(priv, REG_CONFIG_ANT_A, 0x0f60);
>> +
>> +if (priv->tx_paths > 1)
>> +rtl8xxxu_write32(priv, REG_CONFIG_ANT_B, 0x0f60);
>> +#endif
>
> Like discussed before, "#if 0" is not really welcomed in upstream. Can't
> you just keep the unimplemented parts in a private branch and submit
> them once they are ready? That way upstream code is not cluttered with
> these.

This is removed in a follow-on patch, so it becomes a non-issue.
Rebasing this to remove it retroactively would create a mess.

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

Re: [PATCH 107/113] rtl8xxxu: Use define for REG_PWR_DATA bits

2016-03-10 Thread Kalle Valo

jes.soren...@redhat.com writes:

> From: Jes Sorensen 
>
> Use the bit define rather than hard code the value for REG_PWR_DATA bits.
>
> Signed-off-by: Jes Sorensen 

[...]

> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
> @@ -135,7 +135,7 @@
>  #define  EFUSE_ACCESS_DISABLE0x00/* RTL8723 only */
>  
>  #define REG_PWR_DATA 0x0038
> -#define PWR_DATA_EEPRPAD_RFE_CTRL_EN BIT(11)
> +#define  PWR_DATA_EEPRPAD_RFE_CTRL_ENBIT(11)

Again the two spaces. Is your editor adding them automatically or what?

-- 
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: New firmware for RT2870

2016-03-10 Thread Helmut Schaa

On Wed, Mar 9, 2016 at 9:22 PM, Larry Finger  wrote:
> In https://bugzilla.kernel.org/show_bug.cgi?id=114151, the OP reports
> improved stability and performance for an RT5370 using a newer firmware that
> came with the driver CD. The logs show this to be version 0.36, whereas the
> version now in linux-firmware is version 0.29.
>
> I downloaded the firmware from b.k.o. It had very little effect on my
> no-name adapter with ID 148f:3070. It still gets ping losses of 10-15%.
>
> Should this new version be submitted to linux-firmware? Its provenance seems
> to be sketchy, but submission would likely be legal.

Version 0.36 can also be found in the vendor tarball on [1] even though it
references a different chip ...

So, in my opinion this should be safe from a legal point of view.

Helmut

[1] http://www.mediatek.com/en/downloads1/downloads/mt7612u/
--
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 054/113] rtl8xxxu: Implement 8723bu power on sequence

2016-03-10 Thread Kalle Valo

jes.soren...@redhat.com writes:

> From: Jes Sorensen 
>
> This implements the 8723bu specific power on sequence as it is
> different from that of the 8723au chips.
>
> Signed-off-by: Jes Sorensen 

[...]

> @@ -140,7 +144,10 @@
>  #define REG_MAC_PINMUX_CFG   0x0043
>  #define REG_GPIO_PIN_CTRL0x0044
>  #define REG_GPIO_INTM0x0048
> +#define  GPIO_INTM_EDGE_TRIG_IRQ BIT(9)
> +
>  #define REG_LEDCFG0  0x004c
> +#define  LEDCFG0_DPDT_SELECT BIT(23)
>  #define REG_LEDCFG1  0x004d
>  #define REG_LEDCFG2  0x004e
>  #define  LEDCFG2_DPDT_SELECT BIT(7)
> @@ -154,9 +161,13 @@
>  #define REG_GPIO_PIN_CTRL_2  0x0060
>  /*  RTL8723 WIFI/BT/GPS Multi-Function GPIO Select. */
>  #define REG_GPIO_IO_SEL_20x0062
> +#define  GPIO_IO_SEL_2_GPIO09_INPUT  BIT(1)
> +#define  GPIO_IO_SEL_2_GPIO09_IRQBIT(9)
>  
>  /*  RTL8723B */
>  #define REG_PAD_CTRL10x0064
> +#define  PAD_CTRL1_SW_DPDT_SEL_DATA  BIT(0)

Why two spaces after define?

-- 
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 042/113] rtl8xxxu: Initial implementation of rtl8723bu_config_channel()

2016-03-10 Thread Kalle Valo

jes.soren...@redhat.com writes:

> From: Jes Sorensen 
>
> This is a first stab of implementing rtl8723bu_config_channel(). For
> now this will only do 20MHz channels.
>
> Signed-off-by: Jes Sorensen 

[...]

> +static void rtl8723bu_config_channel(struct ieee80211_hw *hw)
> +{
> + struct rtl8xxxu_priv *priv = hw->priv;
> + u32 val32, rsr;
> + u8 val8, opmode, subchannel;
> + u16 rf_mode_bw;
> + bool ht = true;
> + int sec_ch_above, channel;
> + int i;
> +
> + rf_mode_bw = rtl8xxxu_read16(priv, REG_WMAC_TRXPTCL_CTL);
> + rf_mode_bw &= ~WMAC_TRXPTCL_CTL_BW_MASK;
> + rsr = rtl8xxxu_read32(priv, REG_RESPONSE_RATE_SET);
> + channel = hw->conf.chandef.chan->hw_value;
> +
> +/* Hack */

Indentation.

-- 
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 037/113] rtl8xxxu: First stab at adding IQK calibration for 8723bu parts

2016-03-10 Thread Kalle Valo

jes.soren...@redhat.com writes:

> From: Jes Sorensen 
>
> The 8723bu also has it's own IQK calibration process. This is similar
> in flow, but still different enough to warrent it's own
> implementation, at least for now.
>
> Signed-off-by: Jes Sorensen 
> ---
>  drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c   | 811 
> -
>  drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h   |   1 +
>  .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h  |  17 +
>  3 files changed, 827 insertions(+), 2 deletions(-)
>

[...]

> +#ifdef RTL8723BU_BT
> + /* GNT_BT = 1 */
> + rtl8xxxu_write32(priv, REG_BT_CONTROL_8723BU, 0x1800);
> +#endif

What's this about?

> +#ifdef RTL8723BU_BT
> + /* GNT_BT = 1 */
> + rtl8xxxu_write32(priv, REG_BT_CONTROL_8723BU, 0x1800);
> +#endif

Same here.

> +#ifdef RTL8723BU_PATH_B
> +static int rtl8723bu_iqk_path_b(struct rtl8xxxu_priv *priv)

And this?

> +#if 0
> + /* Page B init */
> + rtl8xxxu_write32(priv, REG_CONFIG_ANT_A, 0x0f60);
> +
> + if (priv->tx_paths > 1)
> + rtl8xxxu_write32(priv, REG_CONFIG_ANT_B, 0x0f60);
> +#endif

Like discussed before, "#if 0" is not really welcomed in upstream. Can't
you just keep the unimplemented parts in a private branch and submit
them once they are ready? That way upstream code is not cluttered with
these.

-- 
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: New firmware for RT2870

2016-03-10 Thread Stanislaw Gruszka

On Wed, Mar 09, 2016 at 02:22:45PM -0600, Larry Finger wrote:
> In https://bugzilla.kernel.org/show_bug.cgi?id=114151, the OP reports
> improved stability and performance for an RT5370 using a newer firmware that
> came with the driver CD. The logs show this to be version 0.36, whereas the
> version now in linux-firmware is version 0.29.
> 
> I downloaded the firmware from b.k.o. It had very little effect on my
> no-name adapter with ID 148f:3070. It still gets ping losses of 10-15%.
> 
> Should this new version be submitted to linux-firmware? Its provenance seems
> to be sketchy, but submission would likely be legal.

I do not see any reason not to update ralink firmwares in linux-firmware
git tree, however IIRC linux-firmware maintainers prefer to firmware
submission was performed from vendor email addresses.

Stanislaw
--
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: [v2] mwifiex: Empty Tx queue during suspend

2016-03-10 Thread Kalle Valo


> In cfg80211 suspend handler, stop the netif queue and
> wait until all the Tx queues become empty. Start the
> queues in resume handler.
> 
> Signed-off-by: Amitkumar Karwar 

Thanks, applied to wireless-drivers-next.git.

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: brcmfmac: Remove waitqueue_active check

2016-03-10 Thread Kalle Valo


> We met a problem of pm_suspend  when repeated closing/opening the lid
> on a Lenovo laptop (1/20 reproduce rate), below is the log:
> 
> [ 199.735876] PM: Entering mem sleep
> [ 199.750516] e1000e: EEE TX LPI TIMER: 0011
> [ 199.856638] Trying to free nonexistent resource 
> 
> [ 201.753566] brcmfmac: brcmf_pcie_suspend: Timeout on response for entering 
> D3 substate
> [ 201.753581] pci_legacy_suspend(): brcmf_pcie_suspend+0x0/0x1f0 [brcmfmac] 
> returns -5
> [ 201.753585] dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -5
> [ 201.753589] PM: Device :04:00.0 failed to suspend async: error -5
> 
> Through debugging, we found when problem happens, it is not the device
> fails to enter D3, but the signal D3_ACK comes too early to pass the
> waitqueue_active() check.
> 
> Just like this:
> brcmf_pcie_send_mb_data(devinfo, BRCMF_H2D_HOST_D3_INFORM);
> // signal is triggered here
> wait_event_timeout(devinfo->mbdata_resp_wait, devinfo->mbdata_completed,
>  BRCMF_PCIE_MBDATA_TIMEOUT);
> 
> So far I think it is safe to remove waitqueue_active check since there
> is only one place to trigger this signal (sending
> BRCMF_H2D_HOST_D3_INFORM). And it is not a problem calling wake_up
> event earlier than calling wait_event.
> 
> Cc: Brett Rudley 
> Cc: Hante Meuleman 
> Cc: Franky (Zhenhui) Lin 
> Cc: Pieter-Paul Giesberts 
> Cc: Arend van Spriel 
> Signed-off-by: Hui Wang 

Thanks, applied to wireless-drivers-next.git.

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

[PATCH 2/3] ath10k: move cal data len to hw_params

2016-03-10 Thread Raja Mani

ath10k_download_cal_dt() compares obtained cal data content length
against QCA988X_CAL_DATA_LEN (2116 bytes). It was written by keeping
qca988x in mind. In fact, cal data length is more chip specific.
To make ath10k_download_cal_dt() more generic and reusable for other
chipsets (like qca4019), cal data length is moved to hw_params.

Signed-off-by: Raja Mani 
---
 drivers/net/wireless/ath/ath10k/core.c  | 11 ++-
 drivers/net/wireless/ath/ath10k/core.h  |  1 +
 drivers/net/wireless/ath/ath10k/debug.c |  7 ---
 drivers/net/wireless/ath/ath10k/hw.h|  2 --
 4 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 4ec4d72..2a901c6 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -60,6 +60,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
+   .cal_data_len = 2116,
.fw = {
.dir = QCA988X_HW_2_0_FW_DIR,
.fw = QCA988X_HW_2_0_FW_FILE,
@@ -78,6 +79,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
+   .cal_data_len = 8124,
.fw = {
.dir = QCA6174_HW_2_1_FW_DIR,
.fw = QCA6174_HW_2_1_FW_FILE,
@@ -97,6 +99,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
+   .cal_data_len = 8124,
.fw = {
.dir = QCA6174_HW_2_1_FW_DIR,
.fw = QCA6174_HW_2_1_FW_FILE,
@@ -116,6 +119,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
+   .cal_data_len = 8124,
.fw = {
.dir = QCA6174_HW_3_0_FW_DIR,
.fw = QCA6174_HW_3_0_FW_FILE,
@@ -135,6 +139,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
+   .cal_data_len = 8124,
.fw = {
/* uses same binaries as hw3.0 */
.dir = QCA6174_HW_3_0_FW_DIR,
@@ -159,6 +164,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.tx_chain_mask = 0xf,
.rx_chain_mask = 0xf,
.max_spatial_stream = 4,
+   .cal_data_len = 12064,
.fw = {
.dir = QCA99X0_HW_2_0_FW_DIR,
.fw = QCA99X0_HW_2_0_FW_FILE,
@@ -177,6 +183,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
+   .cal_data_len = 8124,
.fw = {
.dir = QCA9377_HW_1_0_FW_DIR,
.fw = QCA9377_HW_1_0_FW_FILE,
@@ -195,6 +202,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
+   .cal_data_len = 8124,
.fw = {
.dir = QCA9377_HW_1_0_FW_DIR,
.fw = QCA9377_HW_1_0_FW_FILE,
@@ -218,6 +226,7 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.tx_chain_mask = 0x3,
.rx_chain_mask = 0x3,
.max_spatial_stream = 2,
+   .cal_data_len = 12064,
.fw = {
.dir = QCA4019_HW_1_0_FW_DIR,
.fw = QCA4019_HW_1_0_FW_FILE,
@@ -503,7 +512,7 @@ static int ath10k_download_cal_dt(struct ath10k *ar, const 
char *dt_name)
return -ENOENT;
}
 
-   if (data_len != QCA988X_CAL_DATA_LEN) {
+   if (data_len != ar->hw_params.cal_data_len) {
ath10k_warn(ar, "invalid calibration data length in DT: %d\n",
data_len);
ret = -EMSGSIZE;
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 23ba03f..322a9eb 100644
---

[PATCH 1/3] ath10k: pass cal data location as an argument to ath10k_download_cal_{file|dt}

2016-03-10 Thread Raja Mani

Both ath10k_download_cal_file() and ath10k_download_cal_dt() uses
hard coded file pointer (ar->cal_file) and device tree entry
(qcom,ath10k-calibration-data) respectively to get calibration
data content.

There is a need to use those two functions in qca4019 calibration
download sequence with different file pointer and device tree entry name.
Modify those two functions to take cal data location as an argument.
So that it can serve the purpose for other file pointer and device
tree entry.

This is just preparation before adding actual qca4019 calibration
download sequence. No functional changes.

Signed-off-by: Raja Mani 
---
 drivers/net/wireless/ath/ath10k/core.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 2389c07..4ec4d72 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -462,18 +462,18 @@ exit:
return ret;
 }
 
-static int ath10k_download_cal_file(struct ath10k *ar)
+static int ath10k_download_cal_file(struct ath10k *ar,
+   const struct firmware *file)
 {
int ret;
 
-   if (!ar->cal_file)
+   if (!file)
return -ENOENT;
 
-   if (IS_ERR(ar->cal_file))
-   return PTR_ERR(ar->cal_file);
+   if (IS_ERR(file))
+   return PTR_ERR(file);
 
-   ret = ath10k_download_board_data(ar, ar->cal_file->data,
-ar->cal_file->size);
+   ret = ath10k_download_board_data(ar, file->data, file->size);
if (ret) {
ath10k_err(ar, "failed to download cal_file data: %d\n", ret);
return ret;
@@ -484,7 +484,7 @@ static int ath10k_download_cal_file(struct ath10k *ar)
return 0;
 }
 
-static int ath10k_download_cal_dt(struct ath10k *ar)
+static int ath10k_download_cal_dt(struct ath10k *ar, const char *dt_name)
 {
struct device_node *node;
int data_len;
@@ -498,8 +498,7 @@ static int ath10k_download_cal_dt(struct ath10k *ar)
 */
return -ENOENT;
 
-   if (!of_get_property(node, "qcom,ath10k-calibration-data",
-_len)) {
+   if (!of_get_property(node, dt_name, _len)) {
/* The calibration data node is optional */
return -ENOENT;
}
@@ -517,8 +516,7 @@ static int ath10k_download_cal_dt(struct ath10k *ar)
goto out;
}
 
-   ret = of_property_read_u8_array(node, "qcom,ath10k-calibration-data",
-   data, data_len);
+   ret = of_property_read_u8_array(node, dt_name, data, data_len);
if (ret) {
ath10k_warn(ar, "failed to read calibration data from DT: %d\n",
ret);
@@ -1258,7 +1256,7 @@ static int ath10k_download_cal_data(struct ath10k *ar)
 {
int ret;
 
-   ret = ath10k_download_cal_file(ar);
+   ret = ath10k_download_cal_file(ar, ar->cal_file);
if (ret == 0) {
ar->cal_mode = ATH10K_CAL_MODE_FILE;
goto done;
@@ -1268,7 +1266,7 @@ static int ath10k_download_cal_data(struct ath10k *ar)
   "boot did not find a calibration file, try DT next: %d\n",
   ret);
 
-   ret = ath10k_download_cal_dt(ar);
+   ret = ath10k_download_cal_dt(ar, "qcom,ath10k-calibration-data");
if (ret == 0) {
ar->cal_mode = ATH10K_CAL_MODE_DT;
goto done;
-- 
1.8.1.2

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

[PATCH 3/3] ath10k: incorporate qca4019 cal data download sequence

2016-03-10 Thread Raja Mani

qca4019 calibration data is stored in the host memory and it's mandatory
to download it even before reading board id and chip id from the target.
Also, there is a need to execute otp (download and run) twice, one after
cal data download and another one after board data download.

Existing cal data file name 'cal--.bin' and device tree entry
'qcom,ath10k-calibration-data' used in ath10k has assumption that it
carries other data (like board data) also along with the calibration data.
But, qca4019 cal data contains pure calibration data (doesn't include
any other info). So, using existing same cal file name and DT entry
in qca4019 case would alter the purpose of it. To avoid this, new cal
file name 'pre-cal--.bin' and new device tree entry name
'qcom,ath10k-pre-calibration-data are introduced.

Overall qca4019's firmware download sequence would look like,

   1) Download cal data (either from a file or device tree entry)
  at the address specified by target in the host interest area
  member "hi_board_data".

   2) Download otp and run with 0x10 (PARAM_GET_EEPROM_BOARD_ID)
  as a argument.

  At this point, otp will take back up of downloaded cal data
  content in another location in the target and return valid
  board id and chip id to the host.

   3) Download board data at the address specified by target
  in host interest area member "hi_board_data".

   4) Download otp and run with 0x1 (PARAM_FLASH_SECTION_ALL) as
  a argument.

  Now otp will apply cal data content from it's backup on top
  of board data download in step 3 and prepare final data base.

   5) Download code swap and athwlan binary content.

Above sequences are implemented (step 1 to step 4) in the name of
pre calibration configuration.

Signed-off-by: Raja Mani 
---
 drivers/net/wireless/ath/ath10k/core.c | 85 +-
 drivers/net/wireless/ath/ath10k/core.h | 11 -
 2 files changed, 94 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 2a901c6..3d05929 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -729,6 +729,14 @@ static int ath10k_fetch_cal_file(struct ath10k *ar)
 {
char filename[100];
 
+   /* pre-cal--.bin */
+   scnprintf(filename, sizeof(filename), "pre-cal-%s-%s.bin",
+ ath10k_bus_str(ar->hif.bus), dev_name(ar->dev));
+
+   ar->pre_cal_file = ath10k_fetch_fw_file(ar, ATH10K_FW_DIR, filename);
+   if (!IS_ERR(ar->pre_cal_file))
+   goto success;
+
/* cal--.bin */
scnprintf(filename, sizeof(filename), "cal-%s-%s.bin",
  ath10k_bus_str(ar->hif.bus), dev_name(ar->dev));
@@ -737,7 +745,7 @@ static int ath10k_fetch_cal_file(struct ath10k *ar)
if (IS_ERR(ar->cal_file))
/* calibration file is optional, don't print any warnings */
return PTR_ERR(ar->cal_file);
-
+success:
ath10k_dbg(ar, ATH10K_DBG_BOOT, "found calibration file %s/%s\n",
   ATH10K_FW_DIR, filename);
 
@@ -1261,10 +1269,76 @@ success:
return 0;
 }
 
+static int ath10k_core_pre_cal_download(struct ath10k *ar)
+{
+   int ret;
+
+   ret = ath10k_download_cal_file(ar, ar->pre_cal_file);
+   if (ret == 0) {
+   ar->cal_mode = ATH10K_PRE_CAL_MODE_FILE;
+   goto success;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "boot did not find a pre calibration file, try DT next: 
%d\n",
+  ret);
+
+   ret = ath10k_download_cal_dt(ar, "qcom,ath10k-pre-calibration-data");
+   if (ret) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "unable to load pre cal data from DT: %d\n", ret);
+   return ret;
+   }
+   ar->cal_mode = ATH10K_PRE_CAL_MODE_DT;
+
+success:
+   ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot using calibration mode %s\n",
+  ath10k_cal_mode_str(ar->cal_mode));
+
+   return 0;
+}
+
+static int ath10k_core_pre_cal_config(struct ath10k *ar)
+{
+   int ret;
+
+   ret = ath10k_core_pre_cal_download(ar);
+   if (ret) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "failed to load pre cal data: %d\n", ret);
+   return ret;
+   }
+
+   ret = ath10k_core_get_board_id_from_otp(ar);
+   if (ret) {
+   ath10k_err(ar, "failed to get board id: %d\n", ret);
+   return ret;
+   }
+
+   ret = ath10k_download_and_run_otp(ar);
+   if (ret) {
+   ath10k_err(ar, "failed to run otp: %d\n", ret);
+   return ret;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "pre cal configuration done successfully\n");
+
+   return 0;
+}
+
 static int ath10k_download_cal_data(struct ath10k *ar)
 {
int ret;
 
+   ret =

[PATCH] dt: bindings: add new dt entry for pre calibration in qcom,ath10k.txt

2016-03-10 Thread Raja Mani

There two things done in this patch,

1) Existing device tree entry 'qcom,ath10k-calibration-data' carries
   not only calibration data, it carries board specific data too.
   So, make appropriate update in doc.

2) ipq4019 wifi needs new devie tree entry to carry calibration
   data alone (called pre cal data, it doesn't include any other info).
   Using 'qcom,ath10k-calibration-data' for ipq4019 would alter
   the purpose of it. Hence, add new device tree entry called
   'qcom,ath10k-pre-calibration-data' to carry only pre calibration data.

Signed-off-by: Raja Mani 
---

Below patches covers the corresponding changes in the ath10k driver.
It's posted separately to ath10k and linux-wireless mailing list.

  1) ath10k: pass cal data location as an argument to 
ath10k_download_cal_{file|dt}
  2) ath10k: move cal data len to hw_params
  3) ath10k: incorporate qca4019 cal data download sequence

 .../bindings/net/wireless/qcom,ath10k.txt  | 23 +++---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index 96aae6b..74d7f0a 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -5,12 +5,18 @@ Required properties:
* "qcom,ath10k"
* "qcom,ipq4019-wifi"
 
-PCI based devices uses compatible string "qcom,ath10k" and takes only
-calibration data via "qcom,ath10k-calibration-data". Rest of the properties
-are not applicable for PCI based devices.
+PCI based devices uses compatible string "qcom,ath10k" and takes calibration
+data along with board specific data via "qcom,ath10k-calibration-data".
+Rest of the properties are not applicable for PCI based devices.
 
 AHB based devices (i.e. ipq4019) uses compatible string "qcom,ipq4019-wifi"
-and also uses most of the properties defined in this doc.
+and also uses most of the properties defined in this doc (except
+"qcom,ath10k-calibration-data"). It uses "qcom,ath10k-pre-calibration-data"
+to carry pre calibration data.
+
+In general, entry "qcom,ath10k-pre-calibration-data" and
+"qcom,ath10k-calibration-data" conflict with each other and only one
+can be provided per device.
 
 Optional properties:
 - reg: Address and length of the register set for the device.
@@ -35,8 +41,11 @@ Optional properties:
 - qcom,msi_addr: MSI interrupt address.
 - qcom,msi_base: Base value to add before writing MSI data into
MSI address register.
-- qcom,ath10k-calibration-data : calibration data as an array, the
-length can vary between hw versions
+- qcom,ath10k-calibration-data : calibration data + board specific data
+as an array, the length can vary between
+hw versions.
+- qcom,ath10k-pre-calibration-data : pre calibration data as an array,
+the length can vary between hw versions.
 
 Example (to supply the calibration data alone):
 
@@ -105,5 +114,5 @@ wifi0: wifi@a00 {
  "legacy";
qcom,msi_addr = <0x0b006040>;
qcom,msi_base = <0x40>;
-   qcom,ath10k-calibration-data = [ 01 02 03 ... ];
+   qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
 };
-- 
1.8.1.2

--
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/3] ath10k: add calibration data download support for qca4019

2016-03-10 Thread Raja Mani

The necessary update in dt binding doc
(Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt) is done
in below patch and it's posted separately,
  
  "dt: bindings: add new dt entry for pre calibration in qcom,ath10k.txt"

Raja Mani (3):
  ath10k: pass cal data location as an argument to
ath10k_download_cal_{file|dt}
  ath10k: move cal data len to hw_params
  ath10k: incorporate qca4019 cal data download sequence

 drivers/net/wireless/ath/ath10k/core.c  | 120 
 drivers/net/wireless/ath/ath10k/core.h  |  12 +++-
 drivers/net/wireless/ath/ath10k/debug.c |   7 +-
 drivers/net/wireless/ath/ath10k/hw.h|   2 -
 4 files changed, 120 insertions(+), 21 deletions(-)

-- 
1.8.1.2

--
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 debugfs pktlog_filter write

2016-03-10 Thread akolli

From: Anilkumar Kolli 

It is observed that, we are disabling the packet log if we write same
value to the pktlog_filter for the second time. Always enable pktlogs
on non zero filter.

Fixes: 90174455ae05 ("ath10k: add support to configure pktlog filter")
Signed-off-by: Anilkumar Kolli 
---
 drivers/net/wireless/ath/ath10k/debug.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index 076d29b53ddf..0f834646e6a7 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2019,7 +2019,12 @@ static ssize_t ath10k_write_pktlog_filter(struct file 
*file,
goto out;
}
 
-   if (filter && (filter != ar->debug.pktlog_filter)) {
+   if (filter == ar->debug.pktlog_filter) {
+   ret = count;
+   goto out;
+   }
+
+   if (filter) {
ret = ath10k_wmi_pdev_pktlog_enable(ar, filter);
if (ret) {
ath10k_warn(ar, "failed to enable pktlog filter %x: 
%d\n",
-- 
1.7.9.5

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

[PATCH v2 4/7] mwifiex: scan: factor out dbg_security_flags

2016-03-10 Thread Andreas Fenkart

merge copy/paste code

Signed-off-by: Andreas Fenkart 
---
 drivers/net/wireless/marvell/mwifiex/scan.c | 74 ++---
 1 file changed, 25 insertions(+), 49 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c 
b/drivers/net/wireless/marvell/mwifiex/scan.c
index f623834..c137fd8 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -76,6 +76,27 @@ static u8 mwifiex_rsn_oui[CIPHER_SUITE_MAX][4] = {
{ 0x00, 0x0f, 0xac, 0x04 }, /* AES  */
 };
 
+static void
+_dbg_security_flags(int log_level, const char *func, const char *desc,
+   struct mwifiex_private *priv,
+   struct mwifiex_bssdescriptor *bss_desc)
+{
+   _mwifiex_dbg(priv->adapter, log_level,
+"info: %s: %s:\twpa_ie=%#x wpa2_ie=%#x WEP=%s WPA=%s 
WPA2=%s\tEncMode=%#x privacy=%#x\n",
+func, desc,
+bss_desc->bcn_wpa_ie ?
+bss_desc->bcn_wpa_ie->vend_hdr.element_id : 0,
+bss_desc->bcn_rsn_ie ?
+bss_desc->bcn_rsn_ie->ieee_hdr.element_id : 0,
+priv->sec_info.wep_enabled ? "e" : "d",
+priv->sec_info.wpa_enabled ? "e" : "d",
+priv->sec_info.wpa2_enabled ? "e" : "d",
+priv->sec_info.encryption_mode,
+bss_desc->privacy);
+}
+#define dbg_security_flags(mask, desc, priv, bss_desc) \
+   _dbg_security_flags(MWIFIEX_DBG_##mask, desc, __func__, priv, bss_desc)
+
 static bool
 has_ieee_hdr(struct ieee_types_generic *ie, u8 key)
 {
@@ -243,19 +264,7 @@ mwifiex_is_bss_wpa(struct mwifiex_private *priv,
* LinkSys WRT54G && bss_desc->privacy
*/
 ) {
-   mwifiex_dbg(priv->adapter, INFO,
-   "info: %s: WPA:\t"
-   "wpa_ie=%#x wpa2_ie=%#x WEP=%s WPA=%s WPA2=%s\t"
-   "EncMode=%#x privacy=%#x\n", __func__,
-   bss_desc->bcn_wpa_ie ?
-   bss_desc->bcn_wpa_ie->vend_hdr.element_id : 0,
-   bss_desc->bcn_rsn_ie ?
-   bss_desc->bcn_rsn_ie->ieee_hdr.element_id : 0,
-   (priv->sec_info.wep_enabled) ? "e" : "d",
-   (priv->sec_info.wpa_enabled) ? "e" : "d",
-   (priv->sec_info.wpa2_enabled) ? "e" : "d",
-   priv->sec_info.encryption_mode,
-   bss_desc->privacy);
+   dbg_security_flags(INFO, "WPA", priv, bss_desc);
return true;
}
return false;
@@ -276,19 +285,7 @@ mwifiex_is_bss_wpa2(struct mwifiex_private *priv,
 * Privacy bit may NOT be set in some APs like
 * LinkSys WRT54G && bss_desc->privacy
 */
-   mwifiex_dbg(priv->adapter, INFO,
-   "info: %s: WPA2:\t"
-   "wpa_ie=%#x wpa2_ie=%#x WEP=%s WPA=%s WPA2=%s\t"
-   "EncMode=%#x privacy=%#x\n", __func__,
-   bss_desc->bcn_wpa_ie ?
-   bss_desc->bcn_wpa_ie->vend_hdr.element_id : 0,
-   bss_desc->bcn_rsn_ie ?
-   bss_desc->bcn_rsn_ie->ieee_hdr.element_id : 0,
-   (priv->sec_info.wep_enabled) ? "e" : "d",
-   (priv->sec_info.wpa_enabled) ? "e" : "d",
-   (priv->sec_info.wpa2_enabled) ? "e" : "d",
-   priv->sec_info.encryption_mode,
-   bss_desc->privacy);
+   dbg_security_flags(INFO, "WAP2", priv, bss_desc);
return true;
}
return false;
@@ -325,17 +322,7 @@ mwifiex_is_bss_dynamic_wep(struct mwifiex_private *priv,
!has_vendor_hdr(bss_desc->bcn_wpa_ie, WLAN_EID_VENDOR_SPECIFIC) &&
!has_ieee_hdr(bss_desc->bcn_rsn_ie, WLAN_EID_RSN) &&
priv->sec_info.encryption_mode && bss_desc->privacy) {
-   mwifiex_dbg(priv->adapter, INFO,
-   "info: %s: dynamic\t"
-   "WEP: wpa_ie=%#x wpa2_ie=%#x\t"
-   "EncMode=%#x privacy=%#x\n",
-   __func__,
-   bss_desc->bcn_wpa_ie ?
-   bss_desc->bcn_wpa_ie->vend_hdr.element_id : 0,
-   bss_desc->bcn_rsn_ie ?
-   bss_desc->bcn_rsn_ie->ieee_hdr.element_id : 0,
-   priv->sec_info.encryption_mode,
-   bss_desc->privacy);
+   dbg_security_flags(INFO, "dynamic", priv, bss_desc);
return true;
}
return false;
@@ -448,18 +435,7 @@

[PATCH v2 7/7] mwifiex: make mwifiex_insert_cmd_to_free_q local static

2016-03-10 Thread Andreas Fenkart

after factoring out mwifiex_cancel_pending_scan_cmd
the function is not called outside of cmdevt file
moved function to head of file to avoid forward declaration,
also moved mwifiex_recycle_cmd_node since they are very similar

Signed-off-by: Andreas Fenkart 
---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c | 82 +--
 drivers/net/wireless/marvell/mwifiex/main.h   |  2 -
 2 files changed, 41 insertions(+), 43 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 61426b3..3d7de4a 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -105,6 +105,47 @@ mwifiex_clean_cmd_node(struct mwifiex_adapter *adapter,
 }
 
 /*
+ * This function returns a command to the command free queue.
+ *
+ * The function also calls the completion callback if required, before
+ * cleaning the command node and re-inserting it into the free queue.
+ */
+static void
+mwifiex_insert_cmd_to_free_q(struct mwifiex_adapter *adapter,
+struct cmd_ctrl_node *cmd_node)
+{
+   unsigned long flags;
+
+   if (!cmd_node)
+   return;
+
+   if (cmd_node->wait_q_enabled)
+   mwifiex_complete_cmd(adapter, cmd_node);
+   /* Clean the node */
+   mwifiex_clean_cmd_node(adapter, cmd_node);
+
+   /* Insert node into cmd_free_q */
+   spin_lock_irqsave(>cmd_free_q_lock, flags);
+   list_add_tail(_node->list, >cmd_free_q);
+   spin_unlock_irqrestore(>cmd_free_q_lock, flags);
+}
+
+/* This function reuses a command node. */
+void mwifiex_recycle_cmd_node(struct mwifiex_adapter *adapter,
+ struct cmd_ctrl_node *cmd_node)
+{
+   struct host_cmd_ds_command *host_cmd = (void *)cmd_node->cmd_skb->data;
+
+   mwifiex_insert_cmd_to_free_q(adapter, cmd_node);
+
+   atomic_dec(>cmd_pending);
+   mwifiex_dbg(adapter, CMD,
+   "cmd: FREE_CMD: cmd=%#x, cmd_pending=%d\n",
+   le16_to_cpu(host_cmd->command),
+   atomic_read(>cmd_pending));
+}
+
+/*
  * This function sends a host command to the firmware.
  *
  * The function copies the host command into the driver command
@@ -614,47 +655,6 @@ int mwifiex_send_cmd(struct mwifiex_private *priv, u16 
cmd_no,
 }
 
 /*
- * This function returns a command to the command free queue.
- *
- * The function also calls the completion callback if required, before
- * cleaning the command node and re-inserting it into the free queue.
- */
-void
-mwifiex_insert_cmd_to_free_q(struct mwifiex_adapter *adapter,
-struct cmd_ctrl_node *cmd_node)
-{
-   unsigned long flags;
-
-   if (!cmd_node)
-   return;
-
-   if (cmd_node->wait_q_enabled)
-   mwifiex_complete_cmd(adapter, cmd_node);
-   /* Clean the node */
-   mwifiex_clean_cmd_node(adapter, cmd_node);
-
-   /* Insert node into cmd_free_q */
-   spin_lock_irqsave(>cmd_free_q_lock, flags);
-   list_add_tail(_node->list, >cmd_free_q);
-   spin_unlock_irqrestore(>cmd_free_q_lock, flags);
-}
-
-/* This function reuses a command node. */
-void mwifiex_recycle_cmd_node(struct mwifiex_adapter *adapter,
- struct cmd_ctrl_node *cmd_node)
-{
-   struct host_cmd_ds_command *host_cmd = (void *)cmd_node->cmd_skb->data;
-
-   mwifiex_insert_cmd_to_free_q(adapter, cmd_node);
-
-   atomic_dec(>cmd_pending);
-   mwifiex_dbg(adapter, CMD,
-   "cmd: FREE_CMD: cmd=%#x, cmd_pending=%d\n",
-   le16_to_cpu(host_cmd->command),
-   atomic_read(>cmd_pending));
-}
-
-/*
  * This function queues a command to the command pending queue.
  *
  * This in effect adds the command to the command list to be executed.
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index f71f894..840e5d4 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1045,8 +1045,6 @@ void mwifiex_cancel_all_pending_cmd(struct 
mwifiex_adapter *adapter);
 void mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter);
 void mwifiex_cancel_pending_scan_cmd(struct mwifiex_adapter *adapter);
 
-void mwifiex_insert_cmd_to_free_q(struct mwifiex_adapter *adapter,
- struct cmd_ctrl_node *cmd_node);
 void mwifiex_recycle_cmd_node(struct mwifiex_adapter *adapter,
  struct cmd_ctrl_node *cmd_node);
 
-- 
2.7.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

[PATCH v2 1/7] mwifiex: scan: simplify dereference of bss_desc fields

2016-03-10 Thread Andreas Fenkart

given this structure:
struct foo {
  struct bar {
 int baz;
  }
}

these accesses are equivalent:
(*(foo->bar)).baz
foo->bar->baz

Signed-off-by: Andreas Fenkart 
---
 drivers/net/wireless/marvell/mwifiex/scan.c | 98 ++---
 1 file changed, 46 insertions(+), 52 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c 
b/drivers/net/wireless/marvell/mwifiex/scan.c
index c20017c..a7bdde5 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -121,8 +121,8 @@ mwifiex_is_rsn_oui_present(struct mwifiex_bssdescriptor 
*bss_desc, u32 cipher)
struct ie_body *iebody;
u8 ret = MWIFIEX_OUI_NOT_PRESENT;
 
-   if (((bss_desc->bcn_rsn_ie) && ((*(bss_desc->bcn_rsn_ie)).
-   ieee_hdr.element_id == WLAN_EID_RSN))) {
+   if (bss_desc->bcn_rsn_ie &&
+   bss_desc->bcn_rsn_ie->ieee_hdr.element_id == WLAN_EID_RSN) {
iebody = (struct ie_body *)
 (((u8 *) bss_desc->bcn_rsn_ie->data) +
  RSN_GTK_OUI_OFFSET);
@@ -148,9 +148,9 @@ mwifiex_is_wpa_oui_present(struct mwifiex_bssdescriptor 
*bss_desc, u32 cipher)
struct ie_body *iebody;
u8 ret = MWIFIEX_OUI_NOT_PRESENT;
 
-   if (((bss_desc->bcn_wpa_ie) &&
-((*(bss_desc->bcn_wpa_ie)).vend_hdr.element_id ==
- WLAN_EID_VENDOR_SPECIFIC))) {
+   if (bss_desc->bcn_wpa_ie &&
+   bss_desc->bcn_wpa_ie->vend_hdr.element_id ==
+   WLAN_EID_VENDOR_SPECIFIC) {
iebody = (struct ie_body *) bss_desc->bcn_wpa_ie->data;
oui = _wpa_oui[cipher][0];
ret = mwifiex_search_oui_in_ie(iebody, oui);
@@ -181,8 +181,8 @@ mwifiex_is_bss_wapi(struct mwifiex_private *priv,
 {
if (priv->sec_info.wapi_enabled &&
(bss_desc->bcn_wapi_ie &&
-((*(bss_desc->bcn_wapi_ie)).ieee_hdr.element_id ==
-   WLAN_EID_BSS_AC_ACCESS_DELAY))) {
+bss_desc->bcn_wapi_ie->ieee_hdr.element_id ==
+WLAN_EID_BSS_AC_ACCESS_DELAY)) {
return true;
}
return false;
@@ -197,12 +197,12 @@ mwifiex_is_bss_no_sec(struct mwifiex_private *priv,
  struct mwifiex_bssdescriptor *bss_desc)
 {
if (!priv->sec_info.wep_enabled && !priv->sec_info.wpa_enabled &&
-   !priv->sec_info.wpa2_enabled && ((!bss_desc->bcn_wpa_ie) ||
-   ((*(bss_desc->bcn_wpa_ie)).vend_hdr.element_id !=
-WLAN_EID_VENDOR_SPECIFIC)) &&
-   ((!bss_desc->bcn_rsn_ie) ||
-   ((*(bss_desc->bcn_rsn_ie)).ieee_hdr.element_id !=
-WLAN_EID_RSN)) &&
+   !priv->sec_info.wpa2_enabled &&
+   (!bss_desc->bcn_wpa_ie ||
+bss_desc->bcn_wpa_ie->vend_hdr.element_id !=
+WLAN_EID_VENDOR_SPECIFIC) &&
+   (!bss_desc->bcn_rsn_ie ||
+bss_desc->bcn_rsn_ie->ieee_hdr.element_id != WLAN_EID_RSN) &&
!priv->sec_info.encryption_mode && !bss_desc->privacy) {
return true;
}
@@ -233,9 +233,10 @@ mwifiex_is_bss_wpa(struct mwifiex_private *priv,
   struct mwifiex_bssdescriptor *bss_desc)
 {
if (!priv->sec_info.wep_enabled && priv->sec_info.wpa_enabled &&
-   !priv->sec_info.wpa2_enabled && ((bss_desc->bcn_wpa_ie) &&
-   ((*(bss_desc->bcn_wpa_ie)).
-vend_hdr.element_id == WLAN_EID_VENDOR_SPECIFIC))
+   !priv->sec_info.wpa2_enabled &&
+   (bss_desc->bcn_wpa_ie &&
+bss_desc->bcn_wpa_ie->vend_hdr.element_id ==
+WLAN_EID_VENDOR_SPECIFIC)
   /*
* Privacy bit may NOT be set in some APs like
* LinkSys WRT54G && bss_desc->privacy
@@ -245,12 +246,10 @@ mwifiex_is_bss_wpa(struct mwifiex_private *priv,
"info: %s: WPA:\t"
"wpa_ie=%#x wpa2_ie=%#x WEP=%s WPA=%s WPA2=%s\t"
"EncMode=%#x privacy=%#x\n", __func__,
-   (bss_desc->bcn_wpa_ie) ?
-   (*bss_desc->bcn_wpa_ie).
-   vend_hdr.element_id : 0,
-   (bss_desc->bcn_rsn_ie) ?
-   (*bss_desc->bcn_rsn_ie).
-   ieee_hdr.element_id : 0,
+   bss_desc->bcn_wpa_ie ?
+   bss_desc->bcn_wpa_ie->vend_hdr.element_id : 0,
+   bss_desc->bcn_rsn_ie ?
+   bss_desc->bcn_rsn_ie->ieee_hdr.element_id : 0,
(priv->sec_info.wep_enabled) ? "e" : "d",
(priv->sec_info.wpa_enabled) ? "e" : "d",
(priv->sec_info.wpa2_enabled) ? "e" : "d",
@@ -269,11 +268,10 @@ static bool
 mwifiex_is_bss_wpa2(struct mwifiex_private *priv,
struct

[PATCH v2 5/7] mwifiex: scan: replace pointer arithmetic with array access

2016-03-10 Thread Andreas Fenkart

improves readability

Reviewed-by: Julian Calaby 
Signed-off-by: Andreas Fenkart 
---
 drivers/net/wireless/marvell/mwifiex/scan.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c 
b/drivers/net/wireless/marvell/mwifiex/scan.c
index c137fd8..327b4d8 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1000,27 +1000,24 @@ mwifiex_config_scan(struct mwifiex_private *priv,
 chan_idx++) {
 
channel = user_scan_in->chan_list[chan_idx].chan_number;
-   (scan_chan_list + chan_idx)->chan_number = channel;
+   scan_chan_list[chan_idx].chan_number = channel;
 
radio_type =
user_scan_in->chan_list[chan_idx].radio_type;
-   (scan_chan_list + chan_idx)->radio_type = radio_type;
+   scan_chan_list[chan_idx].radio_type = radio_type;
 
scan_type = user_scan_in->chan_list[chan_idx].scan_type;
 
if (scan_type == MWIFIEX_SCAN_TYPE_PASSIVE)
-   (scan_chan_list +
-chan_idx)->chan_scan_mode_bitmap
+   scan_chan_list[chan_idx].chan_scan_mode_bitmap
|= (MWIFIEX_PASSIVE_SCAN |
MWIFIEX_HIDDEN_SSID_REPORT);
else
-   (scan_chan_list +
-chan_idx)->chan_scan_mode_bitmap
+   scan_chan_list[chan_idx].chan_scan_mode_bitmap
&= ~MWIFIEX_PASSIVE_SCAN;
 
if (*filtered_scan)
-   (scan_chan_list +
-chan_idx)->chan_scan_mode_bitmap
+   scan_chan_list[chan_idx].chan_scan_mode_bitmap
|= MWIFIEX_DISABLE_CHAN_FILT;
 
if (user_scan_in->chan_list[chan_idx].scan_time) {
@@ -1035,9 +1032,9 @@ mwifiex_config_scan(struct mwifiex_private *priv,
scan_dur = adapter->active_scan_time;
}
 
-   (scan_chan_list + chan_idx)->min_scan_time =
+   scan_chan_list[chan_idx].min_scan_time =
cpu_to_le16(scan_dur);
-   (scan_chan_list + chan_idx)->max_scan_time =
+   scan_chan_list[chan_idx].max_scan_time =
cpu_to_le16(scan_dur);
}
 
-- 
2.7.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

[PATCH v2 2/7] mwifiex: scan: factor out has_ieee_hdr/has_vendor_hdr

2016-03-10 Thread Andreas Fenkart

Signed-off-by: Andreas Fenkart 
---
 drivers/net/wireless/marvell/mwifiex/scan.c | 52 +
 1 file changed, 23 insertions(+), 29 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c 
b/drivers/net/wireless/marvell/mwifiex/scan.c
index a7bdde5..ed886af 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -76,6 +76,18 @@ static u8 mwifiex_rsn_oui[CIPHER_SUITE_MAX][4] = {
{ 0x00, 0x0f, 0xac, 0x04 }, /* AES  */
 };
 
+static bool
+has_ieee_hdr(struct ieee_types_generic *ie, u8 key)
+{
+   return (ie && ie->ieee_hdr.element_id == key);
+}
+
+static bool
+has_vendor_hdr(struct ieee_types_vendor_specific *ie, u8 key)
+{
+   return (ie && ie->vend_hdr.element_id == key);
+}
+
 /*
  * This function parses a given IE for a given OUI.
  *
@@ -121,8 +133,7 @@ mwifiex_is_rsn_oui_present(struct mwifiex_bssdescriptor 
*bss_desc, u32 cipher)
struct ie_body *iebody;
u8 ret = MWIFIEX_OUI_NOT_PRESENT;
 
-   if (bss_desc->bcn_rsn_ie &&
-   bss_desc->bcn_rsn_ie->ieee_hdr.element_id == WLAN_EID_RSN) {
+   if (has_ieee_hdr(bss_desc->bcn_rsn_ie, WLAN_EID_RSN)) {
iebody = (struct ie_body *)
 (((u8 *) bss_desc->bcn_rsn_ie->data) +
  RSN_GTK_OUI_OFFSET);
@@ -148,9 +159,7 @@ mwifiex_is_wpa_oui_present(struct mwifiex_bssdescriptor 
*bss_desc, u32 cipher)
struct ie_body *iebody;
u8 ret = MWIFIEX_OUI_NOT_PRESENT;
 
-   if (bss_desc->bcn_wpa_ie &&
-   bss_desc->bcn_wpa_ie->vend_hdr.element_id ==
-   WLAN_EID_VENDOR_SPECIFIC) {
+   if (has_vendor_hdr(bss_desc->bcn_wpa_ie, WLAN_EID_VENDOR_SPECIFIC)) {
iebody = (struct ie_body *) bss_desc->bcn_wpa_ie->data;
oui = _wpa_oui[cipher][0];
ret = mwifiex_search_oui_in_ie(iebody, oui);
@@ -180,11 +189,8 @@ mwifiex_is_bss_wapi(struct mwifiex_private *priv,
struct mwifiex_bssdescriptor *bss_desc)
 {
if (priv->sec_info.wapi_enabled &&
-   (bss_desc->bcn_wapi_ie &&
-bss_desc->bcn_wapi_ie->ieee_hdr.element_id ==
-WLAN_EID_BSS_AC_ACCESS_DELAY)) {
+   has_ieee_hdr(bss_desc->bcn_wapi_ie, WLAN_EID_BSS_AC_ACCESS_DELAY))
return true;
-   }
return false;
 }
 
@@ -198,11 +204,8 @@ mwifiex_is_bss_no_sec(struct mwifiex_private *priv,
 {
if (!priv->sec_info.wep_enabled && !priv->sec_info.wpa_enabled &&
!priv->sec_info.wpa2_enabled &&
-   (!bss_desc->bcn_wpa_ie ||
-bss_desc->bcn_wpa_ie->vend_hdr.element_id !=
-WLAN_EID_VENDOR_SPECIFIC) &&
-   (!bss_desc->bcn_rsn_ie ||
-bss_desc->bcn_rsn_ie->ieee_hdr.element_id != WLAN_EID_RSN) &&
+   !has_vendor_hdr(bss_desc->bcn_wpa_ie, WLAN_EID_VENDOR_SPECIFIC) &&
+   !has_ieee_hdr(bss_desc->bcn_rsn_ie, WLAN_EID_RSN) &&
!priv->sec_info.encryption_mode && !bss_desc->privacy) {
return true;
}
@@ -234,9 +237,7 @@ mwifiex_is_bss_wpa(struct mwifiex_private *priv,
 {
if (!priv->sec_info.wep_enabled && priv->sec_info.wpa_enabled &&
!priv->sec_info.wpa2_enabled &&
-   (bss_desc->bcn_wpa_ie &&
-bss_desc->bcn_wpa_ie->vend_hdr.element_id ==
-WLAN_EID_VENDOR_SPECIFIC)
+   has_vendor_hdr(bss_desc->bcn_wpa_ie, WLAN_EID_VENDOR_SPECIFIC)
   /*
* Privacy bit may NOT be set in some APs like
* LinkSys WRT54G && bss_desc->privacy
@@ -270,8 +271,7 @@ mwifiex_is_bss_wpa2(struct mwifiex_private *priv,
 {
if (!priv->sec_info.wep_enabled && !priv->sec_info.wpa_enabled &&
priv->sec_info.wpa2_enabled &&
-   (bss_desc->bcn_rsn_ie &&
-bss_desc->bcn_rsn_ie->ieee_hdr.element_id == WLAN_EID_RSN)) {
+   has_ieee_hdr(bss_desc->bcn_rsn_ie, WLAN_EID_RSN)) {
/*
 * Privacy bit may NOT be set in some APs like
 * LinkSys WRT54G && bss_desc->privacy
@@ -304,11 +304,8 @@ mwifiex_is_bss_adhoc_aes(struct mwifiex_private *priv,
 {
if (!priv->sec_info.wep_enabled && !priv->sec_info.wpa_enabled &&
!priv->sec_info.wpa2_enabled &&
-   (!bss_desc->bcn_wpa_ie ||
-bss_desc->bcn_wpa_ie->vend_hdr.element_id !=
-WLAN_EID_VENDOR_SPECIFIC) &&
-   (!bss_desc->bcn_rsn_ie ||
-bss_desc->bcn_rsn_ie->ieee_hdr.element_id != WLAN_EID_RSN) &&
+   !has_vendor_hdr(bss_desc->bcn_wpa_ie, WLAN_EID_VENDOR_SPECIFIC) &&
+   !has_ieee_hdr(bss_desc->bcn_rsn_ie, WLAN_EID_RSN) &&
!priv->sec_info.encryption_mode && bss_desc->privacy) {
return true;
}
@@ -325,11 +322,8 @@ mwifiex_is_bss_dynamic_wep(struct mwifiex_private *priv,
 {
if (!priv->sec_info.wep_enabled && !priv->sec_info.wpa_enabled &&

[PATCH v2 3/7] mwifiex: scan: simplify ternary operators using gnu extension

2016-03-10 Thread Andreas Fenkart

"x ? x : y" can be simplified as "x ? : y"
https://gcc.gnu.org/onlinedocs/gcc/Conditionals.html#Conditionals

Reviewed-by: Julian Calaby 
Signed-off-by: Andreas Fenkart 
---
 drivers/net/wireless/marvell/mwifiex/scan.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c 
b/drivers/net/wireless/marvell/mwifiex/scan.c
index ed886af..f623834 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -845,14 +845,11 @@ mwifiex_config_scan(struct mwifiex_private *priv,
/* Set the BSS type scan filter, use Adapter setting if
   unset */
scan_cfg_out->bss_mode =
-   (user_scan_in->bss_mode ? (u8) user_scan_in->
-bss_mode : (u8) adapter->scan_mode);
+   (u8)(user_scan_in->bss_mode ?: adapter->scan_mode);
 
/* Set the number of probes to send, use Adapter setting
   if unset */
-   num_probes =
-   (user_scan_in->num_probes ? user_scan_in->
-num_probes : adapter->scan_probes);
+   num_probes = user_scan_in->num_probes ?: adapter->scan_probes;
 
/*
 * Set the BSSID filter to the incoming configuration,
-- 
2.7.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

[PATCH v2 0/7] mwifiex: cleanups

2016-03-10 Thread Andreas Fenkart

v2:
- addressed issues from review
- race-condition issue discussed in patch description

Andreas Fenkart (7):
  mwifiex: scan: simplify dereference of bss_desc fields
  mwifiex: scan: factor out has_ieee_hdr/has_vendor_hdr
  mwifiex: scan: simplify ternary operators using gnu extension
  mwifiex: scan: factor out dbg_security_flags
  mwifiex: scan: replace pointer arithmetic with array access
  mwifiex: factor out mwifiex_cancel_pending_scan_cmd
  mwifiex: make mwifiex_insert_cmd_to_free_q local static

 drivers/net/wireless/marvell/mwifiex/cmdevt.c  | 125 +++---
 drivers/net/wireless/marvell/mwifiex/main.h|   3 +-
 drivers/net/wireless/marvell/mwifiex/scan.c| 185 -
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c |  13 +-
 4 files changed, 128 insertions(+), 198 deletions(-)

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

[PATCH v2 6/7] mwifiex: factor out mwifiex_cancel_pending_scan_cmd

2016-03-10 Thread Andreas Fenkart

Releasing the scan_pending lock in mwifiex_check_next_scan_command
introduces a short window where pending scan commands can be removed
or added before removing them all in mwifiex_cancel_pending_scan_cmd.
I think this is safe, since the worst thing to happen is that a
pending scan cmd is removed by the command handler. Adding new scan
commands is not possible while one is pending, see scan_processing flag.
Since all commands are removed from the queue anyway, we don't care if
some commands are removed by a different code path earlier, the final
state remains the same.
I assume, that the critical section needed for the check has been
extended over clearing the pending scan queue out of convenience. The
lock was already held and releasing it and grab it again was just
more work. It doesn't seem to be necessary because of concurrency.

Signed-off-by: Andreas Fenkart 
---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c  | 43 ++
 drivers/net/wireless/marvell/mwifiex/main.h|  1 +
 drivers/net/wireless/marvell/mwifiex/scan.c| 23 +++-
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 13 +--
 4 files changed, 27 insertions(+), 53 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index cb25aa7..61426b3 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -991,6 +991,23 @@ mwifiex_cmd_timeout_func(unsigned long function_context)
adapter->if_ops.card_reset(adapter);
 }
 
+void
+mwifiex_cancel_pending_scan_cmd(struct mwifiex_adapter *adapter)
+{
+   struct cmd_ctrl_node *cmd_node = NULL, *tmp_node;
+   unsigned long flags;
+
+   /* Cancel all pending scan command */
+   spin_lock_irqsave(>scan_pending_q_lock, flags);
+   list_for_each_entry_safe(cmd_node, tmp_node,
+>scan_pending_q, list) {
+   list_del(_node->list);
+   cmd_node->wait_q_enabled = false;
+   mwifiex_insert_cmd_to_free_q(adapter, cmd_node);
+   }
+   spin_unlock_irqrestore(>scan_pending_q_lock, flags);
+}
+
 /*
  * This function cancels all the pending commands.
  *
@@ -1029,16 +1046,7 @@ mwifiex_cancel_all_pending_cmd(struct mwifiex_adapter 
*adapter)
spin_unlock_irqrestore(>cmd_pending_q_lock, flags);
spin_unlock_irqrestore(>mwifiex_cmd_lock, cmd_flags);
 
-   /* Cancel all pending scan command */
-   spin_lock_irqsave(>scan_pending_q_lock, flags);
-   list_for_each_entry_safe(cmd_node, tmp_node,
->scan_pending_q, list) {
-   list_del(_node->list);
-
-   cmd_node->wait_q_enabled = false;
-   mwifiex_insert_cmd_to_free_q(adapter, cmd_node);
-   }
-   spin_unlock_irqrestore(>scan_pending_q_lock, flags);
+   mwifiex_cancel_pending_scan_cmd(adapter);
 
if (adapter->scan_processing) {
spin_lock_irqsave(>mwifiex_cmd_lock, cmd_flags);
@@ -1070,9 +1078,8 @@ mwifiex_cancel_all_pending_cmd(struct mwifiex_adapter 
*adapter)
 void
 mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter)
 {
-   struct cmd_ctrl_node *cmd_node = NULL, *tmp_node = NULL;
+   struct cmd_ctrl_node *cmd_node = NULL;
unsigned long cmd_flags;
-   unsigned long scan_pending_q_flags;
struct mwifiex_private *priv;
int i;
 
@@ -1094,17 +1101,7 @@ mwifiex_cancel_pending_ioctl(struct mwifiex_adapter 
*adapter)
mwifiex_recycle_cmd_node(adapter, cmd_node);
}
 
-   /* Cancel all pending scan command */
-   spin_lock_irqsave(>scan_pending_q_lock,
- scan_pending_q_flags);
-   list_for_each_entry_safe(cmd_node, tmp_node,
->scan_pending_q, list) {
-   list_del(_node->list);
-   cmd_node->wait_q_enabled = false;
-   mwifiex_insert_cmd_to_free_q(adapter, cmd_node);
-   }
-   spin_unlock_irqrestore(>scan_pending_q_lock,
-  scan_pending_q_flags);
+   mwifiex_cancel_pending_scan_cmd(adapter);
 
if (adapter->scan_processing) {
spin_lock_irqsave(>mwifiex_cmd_lock, cmd_flags);
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 2f7f478..f71f894 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1043,6 +1043,7 @@ int mwifiex_alloc_cmd_buffer(struct mwifiex_adapter 
*adapter);
 int mwifiex_free_cmd_buffer(struct mwifiex_adapter *adapter);
 void mwifiex_cancel_all_pending_cmd(struct mwifiex_adapter *adapter);
 void mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter);
+void mwifiex_cancel_pending_scan_cmd(struct mwifiex_adapter *adapter);
 
 void mwifiex_insert_cmd_to_free_q(struct mwifiex_adapter *adapter,

Re: [PATCH 6/7] mwifiex: factor out mwifiex_cancel_pending_scan_cmd

2016-03-10 Thread Andreas Fenkart

Hi Julian,

thanks for your time!

2016-02-25 2:14 GMT+01:00 Julian Calaby :
> Hi Andreas,
>
> On Thu, Feb 25, 2016 at 11:08 AM, Andreas Fenkart  wrote:
>> releasing the scan_pending lock in mwifiex_check_next_scan_command
>> is valid, since the lock is taken again, and all nodes removed
>> from the scan_pending queue.
>>
>> Signed-off-by: Andreas Fenkart 
>> ---
>>  drivers/net/wireless/marvell/mwifiex/cmdevt.c  | 43 
>> ++
>>  drivers/net/wireless/marvell/mwifiex/main.h|  1 +
>>  drivers/net/wireless/marvell/mwifiex/scan.c| 23 +++-
>>  drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 13 +--
>>  4 files changed, 27 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c 
>> b/drivers/net/wireless/marvell/mwifiex/scan.c
>> index 6ddc98b..490d0d1 100644
>> --- a/drivers/net/wireless/marvell/mwifiex/scan.c
>> +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
>> @@ -1920,13 +1910,10 @@ static void mwifiex_check_next_scan_command(struct 
>> mwifiex_private *priv)
>> }
>> } else if ((priv->scan_aborting && !priv->scan_request) ||
>>priv->scan_block) {
>> -   list_for_each_entry_safe(cmd_node, tmp_node,
>> ->scan_pending_q, list) {
>> -   list_del(_node->list);
>> -   mwifiex_insert_cmd_to_free_q(adapter, cmd_node);
>> -   }
>> spin_unlock_irqrestore(>scan_pending_q_lock, flags);
>>
>> +   mwifiex_cancel_pending_scan_cmd(adapter);
>> +
>
> This is creating a "short" window where >scan_pending_q_lock
> is unlocked here. Is that safe?
>
> You might want to write mwifiex_cancel_pending_scan_cmd() as two
> functions, one which takes the spinlock and calls the other and one
> which does all the work so you can call the latter here without that
> window where ..._q_lock is unlocked.

I added this comment to the description of the updated patch, that I
will send out shortly:

Releasing the scan_pending lock in mwifiex_check_next_scan_command
introduces a short window where pending scan commands can be removed
or added before removing them all in mwifiex_cancel_pending_scan_cmd.
I think this is safe, since the worst thing to happen is that a
pending scan cmd is removed by the command handler. Adding new scan
commands is not possible while one is pending, see scan_processing.
Since all commands are removed from the queue anyway, we don't care if
some commands are removed by a different code path earlier, the final
state remains the same.
I assume, that the critical section needed for the check has been
extended over clearing the pending scan queue, out of convenience. The
lock was already held and releasing it first just to grab it again was
more work. It doesn't seem to be necessary because of concurrency.

Thanks,
Andi
--
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

38 matches

Mail list logo