Re: [PATCH v2 01/15] wcn36xx: Clean up wcn36xx_smd_send_beacon

[Bjorn Andersson]

On Sun 03 Apr 15:16 PDT 2016, Bjorn Andersson wrote:

> From: Pontus Fuchs 
> 
> Needed for coming improvements. No functional changes.
> 

Kalle, Eugene,

Have you picked up these patches yet?

As I was debugging a firmware crash when trying to start hostap on the
DragonBoard410c I found an issue with this patch, would like to know if
I should send an incremental patch or resend this one.

> Signed-off-by: Pontus Fuchs 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/net/wireless/ath/wcn36xx/hal.h |  7 +--
>  drivers/net/wireless/ath/wcn36xx/smd.c | 12 +---
>  2 files changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h 
> b/drivers/net/wireless/ath/wcn36xx/hal.h
> index b947de0fb2e5..4fd77ccc2287 100644
> --- a/drivers/net/wireless/ath/wcn36xx/hal.h
> +++ b/drivers/net/wireless/ath/wcn36xx/hal.h
> @@ -51,8 +51,8 @@
>  #define WALN_HAL_STA_INVALID_IDX 0xFF
>  #define WCN36XX_HAL_BSS_INVALID_IDX 0xFF
>  
> -/* Default Beacon template size */
> -#define BEACON_TEMPLATE_SIZE 0x180
> +/* Default Beacon template size. */
> +#define BEACON_TEMPLATE_SIZE 0x17C

This affects the wcn36xx_hal_send_probe_resp_req_msg as well, making the
firmware on DB410c crash upon receiving the UPDATE_PROBE_RSP_TEMPLATE_REQ.

I think we should keep it at 0x180 and subtract sizeof(u32) from the
template size in send_beacon_req_msg, because the second length is
really part of the buffer.

>  
>  /* Param Change Bitmap sent to HAL */
>  #define PARAM_BCN_INTERVAL_CHANGED  (1 << 0)
> @@ -2884,6 +2884,9 @@ struct update_beacon_rsp_msg {
>  struct wcn36xx_hal_send_beacon_req_msg {
>   struct wcn36xx_hal_msg_header header;
>  
> + /* length of the template + 6. Only qcom knows why */
> + u32 beacon_length6;
> +
>   /* length of the template. */
>   u32 beacon_length;
>  
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
> b/drivers/net/wireless/ath/wcn36xx/smd.c
> index 74f56a81ad9a..ff3ed2461a69 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -1380,19 +1380,17 @@ int wcn36xx_smd_send_beacon(struct wcn36xx *wcn, 
> struct ieee80211_vif *vif,
>   mutex_lock(>hal_mutex);
>   INIT_HAL_MSG(msg_body, WCN36XX_HAL_SEND_BEACON_REQ);
>  
> - /* TODO need to find out why this is needed? */
> - msg_body.beacon_length = skb_beacon->len + 6;
> + msg_body.beacon_length = skb_beacon->len;
> + /* TODO need to find out why + 6 is needed */
> + msg_body.beacon_length6 = msg_body.beacon_length + 6;

As far as I can tell from the prima code and SMD dumps this should be 4,
as in sizeof(u32). This looks like a mishap in the layering of prima.

>  
> - if (BEACON_TEMPLATE_SIZE > msg_body.beacon_length) {
> - memcpy(_body.beacon, _beacon->len, sizeof(u32));
> - memcpy(&(msg_body.beacon[4]), skb_beacon->data,
> -skb_beacon->len);
> - } else {
> + if (msg_body.beacon_length > BEACON_TEMPLATE_SIZE) {
>   wcn36xx_err("Beacon is to big: beacon size=%d\n",
> msg_body.beacon_length);
>   ret = -ENOMEM;
>   goto out;
>   }
> + memcpy(msg_body.beacon, skb_beacon->data, skb_beacon->len);
>   memcpy(msg_body.bssid, vif->addr, ETH_ALEN);
>  
>   /* TODO need to find out why this is needed? */

PS. I confirmed that the update_beacon_rsp_msg does not come with the
prepended length...for some reason.

Regards,
Bjorn
--
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: mac80211-next 2016-04-13

[David Miller]

From: Johannes Berg 
Date: Wed, 13 Apr 2016 21:36:31 +0200

> For a while now I've wanted to remove enum ieee80211_band, and in
> order to synchronize more easily with Kalle that's (apart from a
> documentation change I already had pending) all in this pull.
> 
> Let me know if there's any problem.

Pulled, thanks Johannes.
--
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: wireless-drivers 2016-04-13

[David Miller]

From: Kalle Valo 
Date: Wed, 13 Apr 2016 21:23:21 +0300

> few very small fixes for 4.6. All but one are either build fixes or
> memory leaks. More info in the signed tag below.
> 
> Please let me know if there are any problems.

Pulled, thanks.
--
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] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Andrew Worsley]

Thank-you very much for your comments in your reply.

Actually the patch did work - I confirmed it was run and the iomap
call was successful by adding a pr_info() after the pci_iomap()
success branch.

The only time I am getting the IRQ 17 nobody cared message is on
suspend / resume. A fresh boot always had below the 100k interrupt
threshold level.

I tried your new patch and the number is even lower < 30,000 over two boots.

BUT on suspend resume again 126856.

Have you any insights on fixing suspend to disk  / resume paths which
presumably face the same issue of being passed live hardware on boot
up?


On 13 April 2016 at 04:32, Lukas Wunner  wrote:
> Hi Andrew,
>
> thank you for the extensive testing.
>
> On Sun, Apr 10, 2016 at 08:09:29PM +1000, Andrew Worsley wrote:
>> Further testing Broadcom 4331 reset quirk to prevent IRQ storm patch
>> testing reveals that:
>>   1. quirk is run on initial boot up and this time appears to have
>> vastly reduced the interrupts (only 81 this time):
>> cat /proc/interrupts| grep 17
>>  17: 81  0  0  0  0  0
>>  0  0   IO-APIC-fasteoi   snd_hda_intel
>
> Something in the ballpark of 81 interrupt requests is fine.
>
> The kernel will print the error message about spurious interrupts and
> switch to polling at 10 requests. But even 2 is way too much.
> This just means that b43 loaded quickly enough to stop the interrupts
> before the kernel limit of 10 was reached, but the wireless card
> wasn't reset early on as it should have been.
>
> It looks like the patch didn't work at all on your machine for some
> reason. Do you see a message "cannot iomap device, IRQ storm ahead"
> in dmesg?

Result from two reboots with my 3.16 kernel and your new patch

Three full boots (all below 30k interrupts):
 17:  23978  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel
 17:  30088  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel
 17:  26853  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel


dmesg output showing quirk running
dmesg | grep -C 5 quirk
[3.270315] pci :00:1c.0: PCI bridge to [bus 03]
[3.270323] pci :00:1c.0:   bridge window [mem 0xc1a0-0xc1af]
[3.270331] pci :00:1c.0:   bridge window [mem
0xc180-0xc18f 64bit pref]
[3.270463] pci :04:00.0: [14e4:4331] type 00 class 0x028000
[3.270495] pci :04:00.0: reg 0x10: [mem 0xc190-0xc1903fff 64bit]
[3.270574] pci :04:00.0: b43 quirk: resetting controller
[3.270711] pci :04:00.0: supports D1 D2
[3.270712] pci :04:00.0: PME# supported from D0 D3hot D3cold
[3.270759] pci :04:00.0: System wakeup disabled by ACPI
[3.278239] pci :00:1c.1: PCI bridge to [bus 04]
[3.278251] pci :00:1c.1:   bridge window [mem 0xc190-0xc19f]

Output after resume.  Note: Some times it looks it can happen on the
suspend to disk? But a new one is always present after the resume.

 17: 126856  0  0  0  0  0
 0  0   IO-APIC-fasteoi   snd_hda_intel
[   53.404157] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 88045d495540
[   53.468249] irq 17: nobody cared (try booting with the "irqpoll" option)
[   53.468253] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C O
3.16.7-ckt25-3.16-bcm4331-patch2 #7
[   53.468254] Hardware name: Apple Inc.
MacBookPro10,1/Mac-C3EC7CD22292981F, BIOS
MBP101.88Z.00EE.B00.1205101839 05/10/2012
[   53.468259]   81520370 88045a8a8c00
88045a8a8cc4
[   53.468262]  810bfe7d 88045a8a8c00 
0011
[   53.468264]  810c022f  0011

[   53.468265] Call Trace:
[   53.468275][] ? dump_stack+0x5d/0x78
[   53.468282]  [] ? __report_bad_irq+0x2d/0xd0
[   53.468286]  [] ? note_interrupt+0x25f/0x2b0
[   53.468290]  [] ? handle_irq_event_percpu+0x121/0x190
[   53.468294]  [] ? handle_irq_event+0x38/0x50
[   53.468296]  [] ? handle_fasteoi_irq+0x7f/0x150
[   53.468302]  [] ? handle_irq+0x1d/0x30
[   53.468307]  [] ? do_IRQ+0x48/0xe0
[   53.468311]  [] ? common_interrupt+0x6d/0x6d
[   53.468317][] ? cpuidle_enter_state+0x4c/0xc0
[   53.468320]  [] ? cpuidle_enter_state+0x42/0xc0
[   53.468323]  [] ? cpu_startup_entry+0x33a/0x460
[   53.468326]  [] ? start_kernel+0x473/0x47b
[   53.468331]  [] ? early_idt_handler_array+0x120/0x120
[   53.468335]  [] ? x86_64_start_kernel+0x14d/0x15c
[   53.468336] handlers:
[   53.468367] [] azx_interrupt [snd_hda_controller]
[   53.468368] Disabling IRQ #17
[   53.513740] usb 3-1: reset high-speed USB device number 2 using xhci_hcd
[   53.633633] usb 1-1.1: reset high-speed USB device number 3 using ehci-pci
[   

Re: General VHT rate-ctrl question

[Krishna Chaitanya]

On Wed, Apr 13, 2016 at 10:31 PM, Dave Taht  wrote:
>
> On Wed, Apr 13, 2016 at 6:18 AM, Ben Greear  wrote:
> >
> >
> > On 04/13/2016 01:01 AM, Johannes Berg wrote:
> >>
> >> On Tue, 2016-04-12 at 16:48 -0700, Ben Greear wrote:
> >>>
> >>> If a station and it's peer can both do VHT, is there ever a good
> >>> reason to even try HT rates?
> >>>
> >>
> >> Not really; perhaps if you could do HT greenfield preamble (which VHT
> >> doesn't have) you could get something out of it, beyond that I don't
> >> see a reason to try.
> >>
> >> Unless, for some strange reason, it supports only single stream VHT and
> >> dual-stream HT or something really weird?
> >
> >
> > I was wondering if there was ever a reason that, say 450Mbps HT
> > would work better than MCS-1 for VHT.  Or, maybe a mid-rate HT MCS would
> > have more range than VHT, or something like that.
I dont think so. basically if you remove 256 QAM out of picture,
it just boils down to choosing a modulation scheme which would
be same for VHT and HT. (assuming same BW)

Only advantage is as Johannes pointed, VHT doesn't have greenfield,
so using HT greenfield preamble might be marginally good. Similarly we can
use RIFS for HT(not recommended), But again who uses RIFS/greenfield?
--
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: mac80211-next 2016-04-13

[Johannes Berg]

Hi Dave,

For a while now I've wanted to remove enum ieee80211_band, and in
order to synchronize more easily with Kalle that's (apart from a
documentation change I already had pending) all in this pull.

Let me know if there's any problem.

Thanks,
johannes



The following changes since commit bddf59046d804638d998f9015246d4990f1cab09:

  Merge tag 'wireless-drivers-next-for-davem-2016-04-11' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next 
(2016-04-11 11:58:12 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
tags/mac80211-next-for-davem-2016-04-13

for you to fetch changes up to 57fbcce37be7c1d2622b56587c10ade00e96afa3:

  cfg80211: remove enum ieee80211_band (2016-04-12 15:56:15 +0200)


To synchronize with Kalle, here's just a big change that affects
all drivers - removing the duplicated enum ieee80211_band and
replacing it by enum nl80211_band. On top of that, just a small
documentation update.


Johannes Berg (1):
  cfg80211: remove enum ieee80211_band

Jouni Malinen (1):
  cfg80211: Improve Connect/Associate command documentation

 Documentation/DocBook/80211.tmpl   |   1 -
 drivers/net/wireless/admtek/adm8211.c  |   4 +-
 drivers/net/wireless/ath/ar5523/ar5523.c   |   4 +-
 drivers/net/wireless/ath/ath.h |   2 +-
 drivers/net/wireless/ath/ath10k/core.h |   2 +-
 drivers/net/wireless/ath/ath10k/htt_rx.c   |   8 +-
 drivers/net/wireless/ath/ath10k/mac.c  |  68 
 drivers/net/wireless/ath/ath10k/wmi.c  |   8 +-
 drivers/net/wireless/ath/ath5k/ani.c   |   2 +-
 drivers/net/wireless/ath/ath5k/ath5k.h |  10 +-
 drivers/net/wireless/ath/ath5k/attach.c|   8 +-
 drivers/net/wireless/ath/ath5k/base.c  |  32 ++--
 drivers/net/wireless/ath/ath5k/debug.c |   6 +-
 drivers/net/wireless/ath/ath5k/pcu.c   |   6 +-
 drivers/net/wireless/ath/ath5k/phy.c   |  30 ++--
 drivers/net/wireless/ath/ath5k/qcu.c   |   8 +-
 drivers/net/wireless/ath/ath5k/reset.c |   6 +-
 drivers/net/wireless/ath/ath6kl/cfg80211.c |  22 +--
 drivers/net/wireless/ath/ath6kl/core.h |   2 +-
 drivers/net/wireless/ath/ath6kl/wmi.c  |  22 +--
 drivers/net/wireless/ath/ath6kl/wmi.h  |   2 +-
 drivers/net/wireless/ath/ath9k/calib.c |   6 +-
 drivers/net/wireless/ath/ath9k/channel.c   |   8 +-
 drivers/net/wireless/ath/ath9k/common-init.c   |  28 ++--
 drivers/net/wireless/ath/ath9k/common.c|   4 +-
 drivers/net/wireless/ath/ath9k/debug_sta.c |   6 +-
 drivers/net/wireless/ath/ath9k/dynack.c|   2 +-
 drivers/net/wireless/ath/ath9k/htc_drv_init.c  |   8 +-
 drivers/net/wireless/ath/ath9k/htc_drv_main.c  |  12 +-
 drivers/net/wireless/ath/ath9k/htc_drv_txrx.c  |   2 +-
 drivers/net/wireless/ath/ath9k/init.c  |  12 +-
 drivers/net/wireless/ath/ath9k/main.c  |   4 +-
 drivers/net/wireless/ath/ath9k/xmit.c  |   4 +-
 drivers/net/wireless/ath/carl9170/mac.c|  12 +-
 drivers/net/wireless/ath/carl9170/main.c   |   6 +-
 drivers/net/wireless/ath/carl9170/phy.c|  18 +--
 drivers/net/wireless/ath/carl9170/rx.c |   2 +-
 drivers/net/wireless/ath/carl9170/tx.c |   8 +-
 drivers/net/wireless/ath/regd.c|  16 +-
 drivers/net/wireless/ath/regd.h|   2 +-
 drivers/net/wireless/ath/wcn36xx/main.c|  12 +-
 drivers/net/wireless/ath/wcn36xx/smd.c |   4 +-
 drivers/net/wireless/ath/wcn36xx/txrx.c|   2 +-
 drivers/net/wireless/ath/wil6210/cfg80211.c|   4 +-
 drivers/net/wireless/ath/wil6210/netdev.c  |   2 +-
 drivers/net/wireless/ath/wil6210/wmi.c |   2 +-
 drivers/net/wireless/atmel/at76c50x-usb.c  |   6 +-
 drivers/net/wireless/atmel/atmel.c |   2 +-
 drivers/net/wireless/broadcom/b43/b43.h|   4 +-
 drivers/net/wireless/broadcom/b43/main.c   |  34 ++--
 drivers/net/wireless/broadcom/b43/phy_ac.c |   2 +-
 drivers/net/wireless/broadcom/b43/phy_common.c |   2 +-
 drivers/net/wireless/broadcom/b43/phy_ht.c |  16 +-
 drivers/net/wireless/broadcom/b43/phy_lcn.c|  10 +-
 drivers/net/wireless/broadcom/b43/phy_lp.c |  30 ++--
 drivers/net/wireless/broadcom/b43/phy_n.c  | 176 ++---
 drivers/net/wireless/broadcom/b43/tables_lpphy.c   |  14 +-
 drivers/net/wireless/broadcom/b43/tables_nphy.c|  16 +-
 drivers/net/wireless/broadcom/b43/tables_phy_lcn.c |   2 +-
 drivers/net/wireless/broadcom/b43/xmit.c   |   8 +-
 

Google Summer of Code 2016 - We got 11 slots

[Till Kamppeter]

Hi,

now we got our slots and I ask you to accept the best applications quickly.

We have 16 applications where someone of us wants to mentor the student, 
but we have only 11 slots. Org admins can accept applications (mentors 
perhaps too? I do not know). We have to be quick as if a student applied 
at more than one organization and one of the other organizations is 
quicker in accepting him, it goes to there. We can ask the other org 
whether they would pass the student to us, but they are not obliged to 
do so. With this mechanism there is also no de-duplication meeting any 
more this year. So act quickly.


If you are an org admin, go onto the page of your desired student's 
application, confirm the mentors and backup mentors, and accept. Do not 
worry to be too quick with that, you can unaccept if you change your mind.


If you are a mentor and not org admin, contact one or more org admins to 
ask for accepting students for you. Please tell which students.


If you are not a mentor and want to see the applications (and perhaps 
help us on the decisions, or even help us mentoring), tell me your name 
and e-mail address so that I can invite you as mentor.


Now we have 11 slots for 16 students. As I do all the organization work 
I have already taken 3 slots for OpenPrinting, so there remain 8 slots 
for 13 students. Please discuss and tell me, and/or Jan-Simon (CCed) who 
are the lucky students getting the slots.


Yes, we did not get many slots this time, but it seems that there were 
very many great student applications (passing the first step of a mentor 
within the org stepping up) for which the orgs requested slots, many 
more than the slots offered by Google.


   Till

--
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 2016-04-13

[Kalle Valo]

Hi Dave,

few very small fixes for 4.6. All but one are either build fixes or
memory leaks. More info in the signed tag below.

Please let me know if there are any problems.

Kalle

The following changes since commit 9a3492194eca6253ae7ba93c7a402cecad7f1c94:

  Merge branch 'AF_VSOCK-missed-wakeups' (2016-03-22 16:18:42 -0400)

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-2016-04-13

for you to fetch changes up to 15da5d11040c636cddf85bd93fd4abe85f02fc9f:

  Merge tag 'iwlwifi-for-kalle-2016-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes 
(2016-04-02 17:59:57 +0300)



wireless-drivers fixes for 4.6

b43

* fix memory leaks when removing the device

bcma

* fix building without OF_IRQ

rtlwifi

* fix gcc-6 indentation warning

iwlwifi

* lower the debug level of a benign print
* fix a memory leak


Arnd Bergmann (2):
  bcma: fix building without OF_IRQ
  rtlwifi: fix gcc-6 indentation warning

Emmanuel Grumbach (1):
  iwlwifi: pcie: lower the debug level for RSA semaphore access

Jia-Ju Bai (1):
  b43: Fix memory leaks in b43_bus_dev_ssb_init and b43_bus_dev_bcma_init

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

Matti Gottlieb (1):
  iwlwifi: mvm: fix memory leak in paging

 drivers/bcma/main.c|   17 -
 drivers/net/wireless/broadcom/b43/main.c   |6 --
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |2 ++
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c   |2 --
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c|4 ++--
 .../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c|6 +++---
 6 files changed, 15 insertions(+), 22 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 v2] qcom: ipq4019: add wifi nodes to ipq4019 SoC device tree

[Stephen Boyd]

On 04/11/2016 09:18 PM, tamizhchel...@codeaurora.org wrote:
> + qcom,msi_addr = <0x0b006040>;
> + qcom,msi_base = <0x50>;

Are these properties used? I couldn't find any usage in the driver but I
may have missed it.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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: General VHT rate-ctrl question

[Dave Taht]

On Wed, Apr 13, 2016 at 6:18 AM, Ben Greear  wrote:
>
>
> On 04/13/2016 01:01 AM, Johannes Berg wrote:
>>
>> On Tue, 2016-04-12 at 16:48 -0700, Ben Greear wrote:
>>>
>>> If a station and it's peer can both do VHT, is there ever a good
>>> reason to even try HT rates?
>>>
>>
>> Not really; perhaps if you could do HT greenfield preamble (which VHT
>> doesn't have) you could get something out of it, beyond that I don't
>> see a reason to try.
>>
>> Unless, for some strange reason, it supports only single stream VHT and
>> dual-stream HT or something really weird?
>
>
> I was wondering if there was ever a reason that, say 450Mbps HT
> would work better than MCS-1 for VHT.  Or, maybe a mid-rate HT MCS would
> have more range than VHT, or something like that.
>
> After fighting with the firmware's rate-ctrl all day, I am even more
> interested
> in trying to make it use mistrel_ht.

I just put up Andrew's old paper on minstrel, if that helps any.

http://blog.cerowrt.org/post/minstrel/

>
> 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
--
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] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation

[Oleksij Rempel]

Am 13.04.2016 um 11:45 schrieb Kalle Valo:
> Kalle Valo  writes:
> 
>> Oleksij Rempel  writes:
>>
>>> by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
>>> mask_m & mask_p initialisation. This coused a performance regression
>>> on ar9281.
>>>
>>> Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common 
>>> code in ar9002_hw_spur_mitigate.")
>>> Reported-by: Gustav Frederiksen 
>>> Tested-by: Gustav Frederiksen 
>>> Signed-off-by: Oleksij Rempel 
>>
>> If no objections I'm planning to send this to 4.6.
> 
> Should we also CC stable (4.2+)? I can add that before I commit the
> patch.
> 

Yes, please.
Thank you.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: General VHT rate-ctrl question

[Ben Greear]

On 04/13/2016 01:01 AM, Johannes Berg wrote:

On Tue, 2016-04-12 at 16:48 -0700, Ben Greear wrote:

If a station and it's peer can both do VHT, is there ever a good
reason to even try HT rates?



Not really; perhaps if you could do HT greenfield preamble (which VHT
doesn't have) you could get something out of it, beyond that I don't
see a reason to try.

Unless, for some strange reason, it supports only single stream VHT and
dual-stream HT or something really weird?


I was wondering if there was ever a reason that, say 450Mbps HT
would work better than MCS-1 for VHT.  Or, maybe a mid-rate HT MCS would
have more range than VHT, or something like that.

After fighting with the firmware's rate-ctrl all day, I am even more interested
in trying to make it use mistrel_ht.

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 v3] brcmfmac: Decrease 8021x_cnt for dropped packets

[per . forlin]

From: Per Forlin 

This patch resolves an issue where pend_8021x_cnt was not decreased
on txfinalize. This caused brcmf_netdev_wait_pend8021x to timeout
because the counter indicated pending packets.

WARNING: at .../brcmfmac/core.c:1289 brcmf_netdev_wait_pend8021x
  (warn_slowpath_common)
  (warn_slowpath_null)
  (brcmf_netdev_wait_pend8021x [brcmfmac])
  (send_key_to_dongle [brcmfmac])
  (brcmf_cfg80211_del_key [brcmfmac])
  (nl80211_del_key [cfg80211])
  (genl_rcv_msg)
  (netlink_rcv_skb)
  (genl_rcv)
  (netlink_unicast)
  (netlink_sendmsg)
  (sock_sendmsg)
  (___sys_sendmsg)
  (__sys_sendmsg)
  (SyS_sendmsg)

The solution is to pull back the header offset in case
of an error in txdata(), which may happen in case of
packet overload in brcmf_sdio_bus_txdata.

Overloading a WLAN interface is not an unlikely scenario.
In case of packet overload the error print "out of bus->txq"
is very verbose. To reduce SPAM degrade it to a debug print.

Signed-off-by: Per Forlin 
---
Change log:
 v2 - Add variable to know whether the counter is increased or not
 v3 - txfinalize should decrease the counter. Fix skb header offset

drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 5 +++--
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
index 67401ca..2c1bc0d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
@@ -332,8 +332,9 @@ brcmf_proto_bcdc_txdata(struct brcmf_pub *drvr, int ifidx, 
u8 offset,
int res;
brcmf_proto_bcdc_hdrpush(drvr, ifidx, offset, pktbuf);
res = brcmf_bus_txdata(drvr->bus_if, pktbuf);
-   if (res < 0)
-   brcmf_proto_bcdc_hdrpull(drvr, ifidx, offset, pktbuf);
+   if (res < 0) {
+   brcmf_proto_bcdc_hdrpull(drvr, false, , pktbuf);
+   }
return res;
 }
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index a14d9d9d..485e2ad 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -2721,7 +2721,7 @@ static int brcmf_sdio_bus_txdata(struct device *dev, 
struct sk_buff *pkt)
*(u16 *)(pkt->cb) = 0;
if (!brcmf_sdio_prec_enq(>txq, pkt, prec)) {
skb_pull(pkt, bus->tx_hdrlen);
-   brcmf_err("out of bus->txq !!!\n");
+   brcmf_dbg(INFO, "out of bus->txq !!!\n");
ret = -ENOSR;
} else {
ret = 0;
-- 
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 v2 5/5] ath10k: fix parenthesis alignment

[Kalle Valo]

Found by checkpatch:

drivers/net/wireless/ath/ath10k/mac.c:6800: Alignment should match open parent

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

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 9c848eb09d2e..59ed30cab681 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6797,7 +6797,7 @@ static u64 ath10k_get_tsf(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif)
 }
 
 static void ath10k_set_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
-   u64 tsf)
+  u64 tsf)
 {
struct ath10k *ar = hw->priv;
struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);

--
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/5] ath10k: prefer kernel type 'u64' over 'u_int64_t'

[Kalle Valo]

Fixes checkpatch warnings:

drivers/net/wireless/ath/ath10k/htt.h:1477: Prefer kernel type 'u64' over 
'u_int64_t'
drivers/net/wireless/ath/ath10k/htt.h:1480: Prefer kernel type 'u64' over 
'u_int64_t'

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/htt.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt.h 
b/drivers/net/wireless/ath/ath10k/htt.h
index 60bd9fe4b2d9..ee7c8f8f8073 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1475,10 +1475,10 @@ union htt_rx_pn_t {
u32 pn24;
 
/* TKIP or CCMP: 48-bit PN */
-   u_int64_t pn48;
+   u64 pn48;
 
/* WAPI: 128-bit PN */
-   u_int64_t pn128[2];
+   u64 pn128[2];
 };
 
 struct htt_cmd {

--
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/5] ath10k: fix checkpatch warnings related to spaces

[Kalle Valo]

Fix checkpatch warnings about use of spaces with operators:

spaces preferred around that '*' (ctx:VxV)

This has been recently added to checkpatch.

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/ce.c|6 +++---
 drivers/net/wireless/ath/ath10k/ce.h|2 +-
 drivers/net/wireless/ath/ath10k/core.h  |6 +++---
 drivers/net/wireless/ath/ath10k/debug.h |2 +-
 drivers/net/wireless/ath/ath10k/htc.h   |4 ++--
 drivers/net/wireless/ath/ath10k/htt.c   |2 +-
 drivers/net/wireless/ath/ath10k/mac.c   |8 
 drivers/net/wireless/ath/ath10k/targaddrs.h |2 +-
 drivers/net/wireless/ath/ath10k/thermal.h   |2 +-
 drivers/net/wireless/ath/ath10k/txrx.c  |2 +-
 drivers/net/wireless/ath/ath10k/wmi-tlv.h   |4 ++--
 drivers/net/wireless/ath/ath10k/wmi.c   |2 +-
 drivers/net/wireless/ath/ath10k/wmi.h   |   18 +-
 13 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c 
b/drivers/net/wireless/ath/ath10k/ce.c
index 7212802eb327..9fb8d7472d18 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1050,11 +1050,11 @@ int ath10k_ce_alloc_pipe(struct ath10k *ar, int ce_id,
 *
 * For the lack of a better place do the check here.
 */
-   BUILD_BUG_ON(2*TARGET_NUM_MSDU_DESC >
+   BUILD_BUG_ON(2 * TARGET_NUM_MSDU_DESC >
 (CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
-   BUILD_BUG_ON(2*TARGET_10X_NUM_MSDU_DESC >
+   BUILD_BUG_ON(2 * TARGET_10X_NUM_MSDU_DESC >
 (CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
-   BUILD_BUG_ON(2*TARGET_TLV_NUM_MSDU_DESC >
+   BUILD_BUG_ON(2 * TARGET_TLV_NUM_MSDU_DESC >
 (CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
 
ce_state->ar = ar;
diff --git a/drivers/net/wireless/ath/ath10k/ce.h 
b/drivers/net/wireless/ath/ath10k/ce.h
index 25cafcfd6b12..dfc098606bee 100644
--- a/drivers/net/wireless/ath/ath10k/ce.h
+++ b/drivers/net/wireless/ath/ath10k/ce.h
@@ -408,7 +408,7 @@ static inline u32 ath10k_ce_base_address(struct ath10k *ar, 
unsigned int ce_id)
 
 /* Ring arithmetic (modulus number of entries in ring, which is a pwr of 2). */
 #define CE_RING_DELTA(nentries_mask, fromidx, toidx) \
-   (((int)(toidx)-(int)(fromidx)) & (nentries_mask))
+   (((int)(toidx) - (int)(fromidx)) & (nentries_mask))
 
 #define CE_RING_IDX_INCR(nentries_mask, idx) (((idx) + 1) & (nentries_mask))
 #define CE_RING_IDX_ADD(nentries_mask, idx, num) \
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 362bbed8f0e9..ccc3d639b077 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -44,8 +44,8 @@
 
 #define ATH10K_SCAN_ID 0
 #define WMI_READY_TIMEOUT (5 * HZ)
-#define ATH10K_FLUSH_TIMEOUT_HZ (5*HZ)
-#define ATH10K_CONNECTION_LOSS_HZ (3*HZ)
+#define ATH10K_FLUSH_TIMEOUT_HZ (5 * HZ)
+#define ATH10K_CONNECTION_LOSS_HZ (3 * HZ)
 #define ATH10K_NUM_CHANS 39
 
 /* Antenna noise floor */
@@ -334,7 +334,7 @@ struct ath10k_sta {
 #endif
 };
 
-#define ATH10K_VDEV_SETUP_TIMEOUT_HZ (5*HZ)
+#define ATH10K_VDEV_SETUP_TIMEOUT_HZ (5 * HZ)
 
 enum ath10k_beacon_state {
ATH10K_BEACON_SCHEDULED = 0,
diff --git a/drivers/net/wireless/ath/ath10k/debug.h 
b/drivers/net/wireless/ath/ath10k/debug.h
index 6206edd7c49f..75c89e3625ef 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -57,7 +57,7 @@ enum ath10k_dbg_aggr_mode {
 };
 
 /* FIXME: How to calculate the buffer size sanely? */
-#define ATH10K_FW_STATS_BUF_SIZE (1024*1024)
+#define ATH10K_FW_STATS_BUF_SIZE (1024 * 1024)
 
 extern unsigned int ath10k_debug_mask;
 
diff --git a/drivers/net/wireless/ath/ath10k/htc.h 
b/drivers/net/wireless/ath/ath10k/htc.h
index e70aa38e6e05..cc827185d3e9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -297,10 +297,10 @@ struct ath10k_htc_svc_conn_resp {
 #define ATH10K_NUM_CONTROL_TX_BUFFERS 2
 #define ATH10K_HTC_MAX_LEN 4096
 #define ATH10K_HTC_MAX_CTRL_MSG_LEN 256
-#define ATH10K_HTC_WAIT_TIMEOUT_HZ (1*HZ)
+#define ATH10K_HTC_WAIT_TIMEOUT_HZ (1 * HZ)
 #define ATH10K_HTC_CONTROL_BUFFER_SIZE (ATH10K_HTC_MAX_CTRL_MSG_LEN + \
sizeof(struct ath10k_htc_hdr))
-#define ATH10K_HTC_CONN_SVC_TIMEOUT_HZ (1*HZ)
+#define ATH10K_HTC_CONN_SVC_TIMEOUT_HZ (1 * HZ)
 
 struct ath10k_htc_ep {
struct ath10k_htc *htc;
diff --git a/drivers/net/wireless/ath/ath10k/htt.c 
b/drivers/net/wireless/ath/ath10k/htt.c
index 17a3008d9ab1..ee79512b1fcc 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -208,7 +208,7 @@ int ath10k_htt_init(struct ath10k *ar)
return 0;
 }
 
-#define HTT_TARGET_VERSION_TIMEOUT_HZ (3*HZ)
+#define HTT_TARGET_VERSION_TIMEOUT_HZ (3 * HZ)
 
 static int 

[PATCH v2 3/5] ath10k: prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp()

[Kalle Valo]

Fixes checkpatch warnings:

drivers/net/wireless/ath/ath10k/mac.c:452: Prefer ether_addr_equal() or 
ether_addr_equal_unaligned() over memcmp()
drivers/net/wireless/ath/ath10k/mac.c:455: Prefer ether_addr_equal() or 
ether_addr_equal_unaligned() over memcmp()
drivers/net/wireless/ath/ath10k/txrx.c:133: Prefer ether_addr_equal() or 
ether_addr_equal_unaligned() over memcmp()

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/mac.c  |4 ++--
 drivers/net/wireless/ath/ath10k/txrx.c |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 045bfc7e0279..9c848eb09d2e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -449,10 +449,10 @@ static int ath10k_mac_vif_update_wep_key(struct 
ath10k_vif *arvif,
lockdep_assert_held(>conf_mutex);
 
list_for_each_entry(peer, >peers, list) {
-   if (!memcmp(peer->addr, arvif->vif->addr, ETH_ALEN))
+   if (ether_addr_equal(peer->addr, arvif->vif->addr))
continue;
 
-   if (!memcmp(peer->addr, arvif->bssid, ETH_ALEN))
+   if (ether_addr_equal(peer->addr, arvif->bssid))
continue;
 
if (peer->keys[key->keyidx] == key)
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c 
b/drivers/net/wireless/ath/ath10k/txrx.c
index c503ff601a54..8c7086989a71 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -130,7 +130,7 @@ struct ath10k_peer *ath10k_peer_find(struct ath10k *ar, int 
vdev_id,
list_for_each_entry(peer, >peers, list) {
if (peer->vdev_id != vdev_id)
continue;
-   if (memcmp(peer->addr, addr, ETH_ALEN))
+   if (!ether_addr_equal(peer->addr, addr))
continue;
 
return peer;

--
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/5] ath10k: prefer ether_addr_copy() over memcpy()

[Kalle Valo]

Fixes checkpatch warning:

drivers/net/wireless/ath/ath10k/wmi.c:5800: Prefer ether_addr_copy() over 
memcpy() if the Ethernet addresses are __aligned(2)

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/wmi.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index e92ac26865ff..adb31e188ebd 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5827,9 +5827,8 @@ ath10k_wmi_put_start_scan_tlvs(struct wmi_start_scan_tlvs 
*tlvs,
bssids->num_bssid = __cpu_to_le32(arg->n_bssids);
 
for (i = 0; i < arg->n_bssids; i++)
-   memcpy(>bssid_list[i],
-  arg->bssids[i].bssid,
-  ETH_ALEN);
+   ether_addr_copy(bssids->bssid_list[i].addr,
+   arg->bssids[i].bssid);
 
ptr += sizeof(*bssids);
ptr += sizeof(struct wmi_mac_addr) * arg->n_bssids;

--
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/5] ath10k: fix recent checkpatch warnings

[Kalle Valo]

I updated checkpatch and noticed that there are few new warnings.

v2:

* fix tests in patch 3
* add patch 5 to fix a new warning in mac.c

---

Kalle Valo (5):
  ath10k: fix checkpatch warnings related to spaces
  ath10k: prefer kernel type 'u64' over 'u_int64_t'
  ath10k: prefer ether_addr_equal() or ether_addr_equal_unaligned() over 
memcmp()
  ath10k: prefer ether_addr_copy() over memcpy()
  ath10k: fix parenthesis alignment


 drivers/net/wireless/ath/ath10k/ce.c|6 +++---
 drivers/net/wireless/ath/ath10k/ce.h|2 +-
 drivers/net/wireless/ath/ath10k/core.h  |6 +++---
 drivers/net/wireless/ath/ath10k/debug.h |2 +-
 drivers/net/wireless/ath/ath10k/htc.h   |4 ++--
 drivers/net/wireless/ath/ath10k/htt.c   |2 +-
 drivers/net/wireless/ath/ath10k/htt.h   |4 ++--
 drivers/net/wireless/ath/ath10k/mac.c   |   14 +++---
 drivers/net/wireless/ath/ath10k/targaddrs.h |2 +-
 drivers/net/wireless/ath/ath10k/thermal.h   |2 +-
 drivers/net/wireless/ath/ath10k/txrx.c  |4 ++--
 drivers/net/wireless/ath/ath10k/wmi-tlv.h   |4 ++--
 drivers/net/wireless/ath/ath10k/wmi.c   |7 +++
 drivers/net/wireless/ath/ath10k/wmi.h   |   18 +-
 14 files changed, 38 insertions(+), 39 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 v3] prism54: isl_38xx: Replace 'struct timeval'

[Arend Van Spriel]

On 13-4-2016 10:38, Johannes Berg wrote:
> 
>> The patch was build-tested / debugged by removing the
>> "if VERBOSE > SHOW_ERROR_MESSAGES" guards.
> 
> Stands to reason that we should just remove the (more or less) dead
> code, since I don't think anyone really ever touches this driver any
> more or will ever again ...

It does bring back memories from my Intersil/Globespan/Conexant day(s),
but not sentimental enough to touch the prism54 driver.

Gr. AvS

> johannes
> --
> 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] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation

[Kalle Valo]

Kalle Valo  writes:

> Oleksij Rempel  writes:
>
>> by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
>> mask_m & mask_p initialisation. This coused a performance regression
>> on ar9281.
>>
>> Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common 
>> code in ar9002_hw_spur_mitigate.")
>> Reported-by: Gustav Frederiksen 
>> Tested-by: Gustav Frederiksen 
>> Signed-off-by: Oleksij Rempel 
>
> If no objections I'm planning to send this to 4.6.

Should we also CC stable (4.2+)? I can add that before I commit the
patch.

-- 
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] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation

[Kalle Valo]

Oleksij Rempel  writes:

> by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
> mask_m & mask_p initialisation. This coused a performance regression
> on ar9281.
>
> Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common 
> code in ar9002_hw_spur_mitigate.")
> Reported-by: Gustav Frederiksen 
> Tested-by: Gustav Frederiksen 
> Signed-off-by: Oleksij Rempel 

If no objections I'm planning to send this to 4.6.

-- 
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] ath10k: remove MSI range support

[Valo, Kalle]

Rajkumar Manoharan  writes:

> MSI-X is never well-tested, might contain bugs and generally isn't
> really all that useful to maintain. Also ath10k is mainly used with
> shared/singly-MSI interrupt systems. Hence removing MSI range support.
> This change will be useful for further cleanup in copy engine lock
> and to add NAPI support.
>
> Signed-off-by: Rajkumar Manoharan 

Applied, thanks.

-- 
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/3] ath10k: add a support of set_tsf on vdev interface

[Valo, Kalle]

Peter Oh  writes:

> 10.2.4 and 10.4 firmware has introduced new function to
> set TSF via vdev parameter.
> set_tsf function can be used to shift TBTT that will help
> avoid its clockdrift which happens when beacons are collided.
>
> Peter Oh (3):
>   ath10k: add a support of set_tsf on vdev interface
>   ath10k: update 10.4 WMI vdev parameters
>   ath10k: enable set_tsf vdev command to WMI 10.4

Series applied, thanks.

-- 
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 v3] prism54: isl_38xx: Replace 'struct timeval'

[Johannes Berg]

> The patch was build-tested / debugged by removing the
> "if VERBOSE > SHOW_ERROR_MESSAGES" guards.

Stands to reason that we should just remove the (more or less) dead
code, since I don't think anyone really ever touches this driver any
more or will ever again ...

johannes
--
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] prism54: isl_38xx: Replace 'struct timeval'

[Tina Ruchandani]

'struct timeval' uses a 32-bit seconds field which will overflow in
year 2038 and beyond. This patch is part of a larger effort to remove
all instances of 'struct timeval' from the kernel and replace them
with 64-bit timekeeping variables.
The patch also fixes the debug printf specifier to avoid the
seconds value being truncated.
The patch was build-tested / debugged by removing the
"if VERBOSE > SHOW_ERROR_MESSAGES" guards.

Signed-off-by: Tina Ruchandani 
Suggested-by: Arnd Bergmann 
--
Changes in v3:
 Fix commit message
Changes in v2:
 Changed printf specifier as suggested by Arnd Bergmann to
avoid truncation.
---
 drivers/net/wireless/intersil/prism54/isl_38xx.c | 35 
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/net/wireless/intersil/prism54/isl_38xx.c 
b/drivers/net/wireless/intersil/prism54/isl_38xx.c
index 333c1a2..6700387 100644
--- a/drivers/net/wireless/intersil/prism54/isl_38xx.c
+++ b/drivers/net/wireless/intersil/prism54/isl_38xx.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -113,7 +114,7 @@ isl38xx_trigger_device(int asleep, void __iomem 
*device_base)

 #if VERBOSE > SHOW_ERROR_MESSAGES
u32 counter = 0;
-   struct timeval current_time;
+   struct timespec64 current_ts64;
DEBUG(SHOW_FUNCTION_CALLS, "isl38xx trigger device\n");
 #endif

@@ -121,22 +122,22 @@ isl38xx_trigger_device(int asleep, void __iomem 
*device_base)
if (asleep) {
/* device is in powersave, trigger the device for wakeup */
 #if VERBOSE > SHOW_ERROR_MESSAGES
-   do_gettimeofday(_time);
-   DEBUG(SHOW_TRACING, "%08li.%08li Device wakeup triggered\n",
- current_time.tv_sec, (long)current_time.tv_usec);
+   ktime_get_real_ts64(_ts64);
+   DEBUG(SHOW_TRACING, "%lld.%09ld Device wakeup triggered\n",
+ (s64)current_ts64.tv_sec, current_ts64.tv_nsec);

-   DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n",
- current_time.tv_sec, (long)current_time.tv_usec,
+   DEBUG(SHOW_TRACING, "%lld.%09ld Device register read %08x\n",
+ (s64)current_ts64.tv_sec, current_ts64.tv_nsec,
  readl(device_base + ISL38XX_CTRL_STAT_REG));
 #endif

reg = readl(device_base + ISL38XX_INT_IDENT_REG);
if (reg == 0xabadface) {
 #if VERBOSE > SHOW_ERROR_MESSAGES
-   do_gettimeofday(_time);
+   ktime_get_real_ts64(_ts64);
DEBUG(SHOW_TRACING,
- "%08li.%08li Device register abadface\n",
- current_time.tv_sec, (long)current_time.tv_usec);
+ "%lld.%09ld Device register abadface\n",
+ (s64)current_ts64.tv_sec, current_ts64.tv_nsec);
 #endif
/* read the Device Status Register until Sleepmode bit 
is set */
while (reg = readl(device_base + ISL38XX_CTRL_STAT_REG),
@@ -149,13 +150,13 @@ isl38xx_trigger_device(int asleep, void __iomem 
*device_base)

 #if VERBOSE > SHOW_ERROR_MESSAGES
DEBUG(SHOW_TRACING,
- "%08li.%08li Device register read %08x\n",
- current_time.tv_sec, (long)current_time.tv_usec,
+ "%lld.%09ld Device register read %08x\n",
+ (s64)current_ts64.tv_sec, current_ts64.tv_nsec,
  readl(device_base + ISL38XX_CTRL_STAT_REG));
-   do_gettimeofday(_time);
+   ktime_get_real_ts64(_ts64);
DEBUG(SHOW_TRACING,
- "%08li.%08li Device asleep counter %i\n",
- current_time.tv_sec, (long)current_time.tv_usec,
+ "%lld.%09ld Device asleep counter %i\n",
+ (s64)current_ts64.tv_sec, current_ts64.tv_nsec,
  counter);
 #endif
}
@@ -168,9 +169,9 @@ isl38xx_trigger_device(int asleep, void __iomem 
*device_base)

/* perform another read on the Device Status Register */
reg = readl(device_base + ISL38XX_CTRL_STAT_REG);
-   do_gettimeofday(_time);
-   DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n",
- current_time.tv_sec, (long)current_time.tv_usec, reg);
+   ktime_get_real_ts64(_ts64);
+   DEBUG(SHOW_TRACING, "%lld.%00ld Device register read %08x\n",
+ (s64)current_ts64.tv_sec, current_ts64.tv_nsec, reg);
 #endif
} else {
/* device is (still) awake  */
--
2.8.0.rc3.226.g39d4020

--
To unsubscribe from this list: send the line 

Re: General VHT rate-ctrl question

[Johannes Berg]

On Tue, 2016-04-12 at 16:48 -0700, Ben Greear wrote:
> If a station and it's peer can both do VHT, is there ever a good
> reason to even try HT rates?
> 

Not really; perhaps if you could do HT greenfield preamble (which VHT
doesn't have) you could get something out of it, beyond that I don't
see a reason to try.

Unless, for some strange reason, it supports only single stream VHT and
dual-stream HT or something really weird?

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