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

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

[PATCH v2] ath10k: fix debugfs pktlog_filter write

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:

Re: pull request: iwlwifi -21.ucode firmware

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 -

Re: pull request: iwlwifi -21.ucode firmware

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

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

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

Re: Linux-firmware: pull-request TI wireless firmware update

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

Re: pull request: iwlwifi -21.ucode firmware

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

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

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

Re: [PATCH] b43: fix memory leak

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

Re: [PATCH-v2 1/2] mac80211: Take bitrates into account when building IEs.

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

Re: [PATCH] ath10k: fix debugfs pktlog_filter write

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

Re: [PATCH 054/113] rtl8xxxu: Implement 8723bu power on sequence

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

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

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 > > [...] > >> ---

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

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

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

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.

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

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

Re: New firmware for RT2870

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,

Re: [PATCH 054/113] rtl8xxxu: Implement 8723bu power on sequence

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

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

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

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

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

Re: New firmware for RT2870

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 >

Re: [v2] mwifiex: Empty Tx queue during suspend

> 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

Re: brcmfmac: Remove waitqueue_active check

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

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

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

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

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

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

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

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

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

[PATCH 0/3] ath10k: add calibration data download support for qca4019

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

[PATCH] ath10k: fix debugfs pktlog_filter write

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:

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

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

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

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

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

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

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

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

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

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

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

"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

[PATCH v2 0/7] mwifiex: cleanups

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:

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

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

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

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