RE: Problems with mwifiex_pcie firmware activation

[Amitkumar Karwar]

Hi Stanislaw,

> From: Stanislaw Gruszka [mailto:sgrus...@redhat.com]
> Sent: Monday, November 14, 2016 3:46 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; linux-wireless@vger.kernel.org
> Subject: Re: Problems with mwifiex_pcie firmware activation
> 
> On Thu, Aug 25, 2016 at 05:06:26PM +0200, Stanislaw Gruszka wrote:
> > On Fri, Aug 12, 2016 at 10:13:43AM +0200, Stanislaw Gruszka wrote:
> > > On Fri, Aug 12, 2016 at 07:17:38AM +, Amitkumar Karwar wrote:
> > > > The problem looks strange. The patch just splits
> mwifiex_check_fw_status() and increases poll count. It should not have
> any side-effects.
> > > > Our code used to check winner status before this patch also.
> > >
> > > Ok, I misread the patch. Anyway checking "winner status" seems does
> > > not work well on some condition and prevent loading firmware into
> > > device.
> >
> > I debug this a bit more on latest wireless-testing-next tree + 3
> > patches I just posted and debug_mask=0x70ff.
> >
> > On broken system, we do not download FW to device when system is
> > rebooted, due to PCI-E is not the winner. However if system is
> powered
> > OFF and then powered ON, we do FW downloading. Hence download the new
> > FW into device does not make it work as was my theory.
> >
> > In attachments are full dmesgs of good/bad and reboot/power-off-on
> > cases.
> >
> > The difference is that on broken system FW (or HW) do not create new
> > USB Bluetooth device (1286:2046) and do not report
> > FIRMWARE_READY_PCIE. Additionally on reboot case there are errors
> from
> > USB xhci.
> 
> It was discovered that not working device require pcie8897_uapsta.bin
> firmware from ubuntu package to work:

What's the difference between working and non-working device?

> https://launchpad.net/~snappy-dev/+archive/ubuntu/snappy-
> devices/+sourcepub/5936055/+listing-archive-extra
> 
> Device initialize like this then:
> 
> [   15.374630] mwifiex_pcie :02:00.0: info: FW download over, size
> 689624 bytes
> [   16.101214] mwifiex_pcie :02:00.0: WLAN FW is active
> [   16.242825] mwifiex_pcie :02:00.0: info: MWIFIEX VERSION:
> mwifiex 1.0 (15.150.13.p21)
> [   16.251231] mwifiex_pcie :02:00.0: driver_version = mwifiex 1.0
> (15.150.13.p21)
> 
> I'm not sure where ubuntu get this 15.150.13.p21 version of firmware as
> it seems it's not present nor in upstream linux-firmware repo not in
> http://git.marvell.com/?p=mwifiex-firmware.git;a=summary
> 
> Anyway could you modify firmware to support this device or modify
> driver to load 15.150.13.p21 if required and push this F/W image
> upstream ?
> 

Last released firmware is 15.68.7.p77
http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=05e2f3a4acf4174ec507a3464a374ecb1b4ec011
Could you try with it?
If it doesn't work, we need to investigate what is missing in this compared to 
15.150.13.p21 and create new 15.68.7.pXX.

Regards,
Amitkumar

Re: Bayesian rate control

[Adrian Chadd]

On 15 November 2016 at 01:34, Johannes Berg  wrote:
>
>> But there is a per-descriptor TX rate table entry in the driver.
>> FreeBSD uses it to implement its rate control for the intel drivers.
>>
>> What am I missing? :)
>
> Not sure. But there isn't a per-descriptor table in the driver. There's
> a per-station table, that *can* be used in similar ways, but at least
> in Linux none of the APIs are hooked up to the general implementation,
> it's all driver/device-specific code, so it'd be very painful to try to
> experiment with.

Ok. well, we do that. :)

I'll let you know how well it works when I'm doing 11ac with the 7260 driver.



-adrian

crda not triggering kernel udev event

[Matthew Stanger]

Hi,

I'm trying to troubleshoot not being able to set the Regulator Domain
on a custom Yocto 3.14 kernel with a Marvell 88W8887/at91_mci driver
on ARM. Running 'udevadm monitor --environment kernel'  there are no
kernel udev events being triggered. I've checked the following common
items, crda is installed in '/usr/sbin' (version 3.18), wireless-regdb
is installed at '/usr/lib/crda/regulatory.bin',
'/etc/modeprobe.d/cfg80211.conf' has 'options cfg80211
ieee80211_regdom=US' & I have udev rules pointing to '/usr/sbin/crda'
in both '/etc/udev/rules.d/' & '/lib/udev/rules.d/'. I have
'COUNTRY=US' set and when I run crda I get 'Failed to set regulatory
domain: -7' and with no kernel udev events in the background and no
cfg80211 messages in dmesg. Oddly if I use wpa_supplicant to connect
to an AP and then stop the wpa_sup service then cfg80211 shows up and
kenel udev messages fire and I'm able to set the reg domain via 'iw
reg set'.  Any idea's on what may be going on here or what I could
check would be most appreciated.

Thanks,
Matt

Re: [PATCH v4 3/3] mwifiex: Enable WoWLAN for both sdio and pcie

[Brian Norris]

On Tue, Nov 15, 2016 at 09:35:07AM -0800, Dmitry Torokhov wrote:
> On Tue, Nov 15, 2016 at 07:06:04PM +0530, Amitkumar Karwar wrote:
> > --- a/drivers/net/wireless/marvell/mwifiex/main.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> > @@ -1552,14 +1552,55 @@ void mwifiex_do_flr(struct mwifiex_adapter 
> > *adapter, bool prepare)
> >  }
> >  EXPORT_SYMBOL_GPL(mwifiex_do_flr);
> >  
> > +static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
> > +{
> > +   struct mwifiex_adapter *adapter = priv;
> > +
> > +   if (adapter->irq_wakeup >= 0) {
> > +   dev_dbg(adapter->dev, "%s: wake by wifi", __func__);
> > +   adapter->wake_by_wifi = true;
> > +   disable_irq_nosync(irq);
> > +   }
> > +
> > +   /* Notify PM core we are wakeup source */
> > +   pm_wakeup_event(adapter->dev, 0);
> > +
> > +   return IRQ_HANDLED;
> > +}
> > +
> >  static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
> >  {
> > +   int ret;
> > struct device *dev = adapter->dev;
> >  
> > if (!dev->of_node)
> > return;
> >  
> > adapter->dt_node = dev->of_node;
> > +   adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
> > +   if (!adapter->irq_wakeup) {
> > +   dev_info(dev, "fail to parse irq_wakeup from device tree\n");
> > +   return;
> > +   }
> 
> I'd rather we used of_irq_get() here, because ti allows handling
> deferrals. of_irq_get_byname() would be even better, but I guess we
> already have bindings in the wild...

This function doesn't handle errors very gracefully at all; we just try,
and if we fail, we just skip the rest...

This could be an argument for rewriting the error handling to stop just
returning -1 in mwifiex_add_card() and use real Linux error codes.
Perhaps that can be a later cleanup?

> > +
> > +   ret = devm_request_irq(dev, adapter->irq_wakeup,
> > +  mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
> 
> irq_of_parse_and_map() (and of_irq_get()) will set trigger flags,
> why do we override them?
> 
> > +  "wifi_wake", adapter);
> > +   if (ret) {
> > +   dev_err(dev, "Failed to request irq_wakeup %d (%d)\n",
> > +   adapter->irq_wakeup, ret);
> > +   goto err_exit;
> > +   }
> > +
> > +   disable_irq(adapter->irq_wakeup);
> > +   if (device_init_wakeup(dev, true)) {
> > +   dev_err(dev, "fail to init wakeup for mwifiex\n");
> > +   goto err_exit;
> 
> Leaking interrupt (not forever, but if we are not using wakeup irq there
> is no need to have it claimed).
> 
> > +   }
> > +   return;
> > +
> > +err_exit:
> > +   adapter->irq_wakeup = 0;
> >  }
> 
> I also do not see anyone actually calling mwifiex_probe_of() in this
> patch?

It was added to mwifiex_add_card() in the previous patch, so all users
with a proper ->dt_node would call it.

> >  
> >  /*

Brian

RE: [OpenWrt-Devel] ATH10K VLAN firmware issue

[voncken]

Hi Ben, 

Do you plan to release a candelatech firmware with this fix?

Regards.

Cedric Voncken.
> -Message d'origine-
> De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
> ow...@vger.kernel.org] De la part de Ben Greear
> Envoyé : samedi 5 novembre 2016 15:35
> À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
> Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
> Development List; ath...@lists.infradead.org
> Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
> 
> Looks to me like 10.4 defaults to the right value, but possibly there
> are other issues with it.  I tested my CT 10.4 and it worked OK with
> vlans for me.
> 
> Thanks,
> Ben
> 
> On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:
> > would be good if qca can fix this bug finally in all available
> > firmwares. its a very annoying issue since a long time
> >
> > Sebastian
> >
> >
> > Am 04.11.2016 um 23:23 schrieb Ben Greear:
> >> The bug appears that vlan-tx-stripping is unconditionally enabled in
> >> at least my firmware.  I have re-compiled w/out that flag set, and
> it
> >> appears to work for me.
> >>
> >> Please download this firmware, rename it firmware-2.bin, make sure
> >> you remove/rename any firmware-5.bin (etc) so mine will load, and
> see if that fixes your problem.
> >>
> >> Please note that it is very likely you will have to use same MAC
> >> address for the VLAN devices that the underlying station uses in
> order for this to work.
> >>
> >> https://www.candelatech.com/downloads/tmp/firmware-2-full-
> community.b
> >> in
> >>
> >>
> >> Thanks,
> >> Ben
> >>
> >>
> >> On 11/04/2016 02:50 PM, Ben Greear wrote:
> >>> I can reproduce this in my CT firmware. I'll see if I can fix it,
> >>> but for stock firmware, it might be that changing the driver to use
> >>> Ethernet packet type of native-wifi would make .1q vlans work.
> >>>
> >>> Thanks,
> >>> Ben
> >>>
> >>> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
>  I met the same problem before,
>  if i modify the 1q header to other value (0xaa00) before go into
> firmware.
>  I can capture the packet in the air I think the vlan packet is
>  dropped in firmware.
> 
>  2016-11-04 22:41 GMT+08:00 Bruno Antunes :
> > On 4 November 2016 at 14:18, Mauro Mozzarelli
>  wrote:
> >> Since the capability is implemented in software you might be
> >> testing the limit of your router's CPU i/o speed.
> >
> > By loading the module in rawmode?
> >
> > The AP is an APU and Sta is an APU2.
> >
> >>
> >>
> >>
> >> On 04/11/16 14:13, Bruno Antunes wrote:
> >>>
> >>> Hi all,
> >>>
> >>> Old thread but I think the issue is still present.
> >>>
> >>> I'm running a setup with VLANs with WDS and ath10k cards.
> >>>
> >>> To make it work both cards must be loaded in rawmode, AP and
> >>> Sta, and with no security.
> >>>
> >>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
> >>> 10.2.4.70.58, from Kalle ath10k firmware tree.
> >>>
> >>> Although it works the throughput is very bad.
> >>> Are there any alternatives to improve the throughput.
> >>>
> >>> Best Regards,
> >>> Bruno
> >>>
> >>> On 9 December 2015 at 17:24, voncken 
> wrote:
> 
> 
> > -Message d'origine-
> > De : Ben Greear [mailto:gree...@candelatech.com] Envoyé :
> > mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
> > ath...@lists.infradead.org; linux-wireless Objet : Re: ATH10K
> > VLAN firmware issue
> >
> > This only happens when you use STA  + WDS, or is .1q broken
> > for you in other cases as well?
> 
>  No, this issue occurs in all modes (STA, STA + WDS, AP).
> 
>  Thanks
> 
>  Cedric.
> 
> > Thanks,
> > Ben
> >
> > On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
> >>
> >>  I'm testing to transmit frame with 802.1q tag (VLAN).
> >>
> >>  My client is set in STA + WDS and the netdev is bridged
> with eth0.
> >>  I have a computer with vlan configuration set connected
> >> to the STA eth0.
> >>
> >>  If I try to transmit frames with 802.1q tag, the frames
> >> are not
> 
>  sent.
> >>
> >>  I checked with wireless sniffer, and I don't see the
> >> frame with VLAN tag (the frames without VLAN tag are sent).
> >>
> >>  I tested with firmware 10.2.4.70.14-2 from kale github,
> >> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
> >> from openwrt, and in all cases I have the same issue.
> >>
> >>  Thanks for your help.
> >>
> >>
> >> --
> >> To 

[PATCH] ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success

[Matthias Schiffer]

Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and
SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs,
changing the return on success from 1 to BIT(gpio). This broke some callers
like ath_is_rfkill_set().

Instead of fixing all callers, change ath9k_hw_gpio_get() back to only
return 0 or 1.

Fixes: b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC")
Cc:  # v4.7+
Signed-off-by: Matthias Schiffer 
---
 drivers/net/wireless/ath/ath9k/hw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 14b13f0..a35f78b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2792,7 +2792,7 @@ u32 ath9k_hw_gpio_get(struct ath_hw *ah, u32 gpio)
WARN_ON(1);
}
 
-   return val;
+   return !!val;
 }
 EXPORT_SYMBOL(ath9k_hw_gpio_get);
 
-- 
2.10.2

Re: [PATCH v4 3/3] mwifiex: Enable WoWLAN for both sdio and pcie

[Dmitry Torokhov]

On Tue, Nov 15, 2016 at 07:06:04PM +0530, Amitkumar Karwar wrote:
> From: Rajat Jain 
> 
> Commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt
> support") added WoWLAN feature only for sdio. This patch moves that
> code to the common module so that all the interface drivers can use
> it for free. It enables pcie and sdio for its use currently.
> 
> Signed-off-by: Rajat Jain 
> ---
> v2: v1 doesn't apply smoothly on latest code due to recently merged
> patch "mwifiex: report error to PCIe for suspend failure". Minor
> conflict is resolved in v2
> v4: Same as v2, v3
> ---
>  drivers/net/wireless/marvell/mwifiex/main.c | 41 
>  drivers/net/wireless/marvell/mwifiex/main.h | 25 ++
>  drivers/net/wireless/marvell/mwifiex/pcie.c |  2 +
>  drivers/net/wireless/marvell/mwifiex/sdio.c | 72 
> ++---
>  drivers/net/wireless/marvell/mwifiex/sdio.h |  8 
>  5 files changed, 73 insertions(+), 75 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
> b/drivers/net/wireless/marvell/mwifiex/main.c
> index 835d330..948f5c2 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.c
> +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> @@ -1552,14 +1552,55 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, 
> bool prepare)
>  }
>  EXPORT_SYMBOL_GPL(mwifiex_do_flr);
>  
> +static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
> +{
> + struct mwifiex_adapter *adapter = priv;
> +
> + if (adapter->irq_wakeup >= 0) {
> + dev_dbg(adapter->dev, "%s: wake by wifi", __func__);
> + adapter->wake_by_wifi = true;
> + disable_irq_nosync(irq);
> + }
> +
> + /* Notify PM core we are wakeup source */
> + pm_wakeup_event(adapter->dev, 0);
> +
> + return IRQ_HANDLED;
> +}
> +
>  static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
>  {
> + int ret;
>   struct device *dev = adapter->dev;
>  
>   if (!dev->of_node)
>   return;
>  
>   adapter->dt_node = dev->of_node;
> + adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
> + if (!adapter->irq_wakeup) {
> + dev_info(dev, "fail to parse irq_wakeup from device tree\n");
> + return;
> + }

I'd rather we used of_irq_get() here, because ti allows handling
deferrals. of_irq_get_byname() would be even better, but I guess we
already have bindings in the wild...

> +
> + ret = devm_request_irq(dev, adapter->irq_wakeup,
> +mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,

irq_of_parse_and_map() (and of_irq_get()) will set trigger flags,
why do we override them?

> +"wifi_wake", adapter);
> + if (ret) {
> + dev_err(dev, "Failed to request irq_wakeup %d (%d)\n",
> + adapter->irq_wakeup, ret);
> + goto err_exit;
> + }
> +
> + disable_irq(adapter->irq_wakeup);
> + if (device_init_wakeup(dev, true)) {
> + dev_err(dev, "fail to init wakeup for mwifiex\n");
> + goto err_exit;

Leaking interrupt (not forever, but if we are not using wakeup irq there
is no need to have it claimed).

> + }
> + return;
> +
> +err_exit:
> + adapter->irq_wakeup = 0;
>  }

I also do not see anyone actually calling mwifiex_probe_of() in this
patch?

>  
>  /*
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
> b/drivers/net/wireless/marvell/mwifiex/main.h
> index 549e1ba..ae5afe5 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.h
> +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> @@ -1011,6 +1011,10 @@ struct mwifiex_adapter {
>   bool usb_mc_setup;
>   struct cfg80211_wowlan_nd_info *nd_info;
>   struct ieee80211_regdomain *regd;
> +
> + /* Wake-on-WLAN (WoWLAN) */
> + int irq_wakeup;
> + bool wake_by_wifi;
>  };
>  
>  void mwifiex_process_tx_queue(struct mwifiex_adapter *adapter);
> @@ -1410,6 +1414,27 @@ static inline u8 mwifiex_is_tdls_link_setup(u8 status)
>   return false;
>  }
>  
> +/* Disable platform specific wakeup interrupt */
> +static inline void mwifiex_disable_wake(struct mwifiex_adapter *adapter)
> +{
> + if (adapter->irq_wakeup >= 0) {
> + disable_irq_wake(adapter->irq_wakeup);
> + if (!adapter->wake_by_wifi)
> + disable_irq(adapter->irq_wakeup);
> + }
> +}
> +
> +/* Enable platform specific wakeup interrupt */
> +static inline void mwifiex_enable_wake(struct mwifiex_adapter *adapter)
> +{
> + /* Enable platform specific wakeup interrupt */
> + if (adapter->irq_wakeup >= 0) {
> + adapter->wake_by_wifi = false;
> + enable_irq(adapter->irq_wakeup);
> + enable_irq_wake(adapter->irq_wakeup);
> + }
> +}
> +
>  int mwifiex_init_shutdown_fw(struct mwifiex_private *priv,
>u32 func_init_shutdown);
>  int 

Re: [RFC 02/12] ath10k: htc: rx trailer lookahead support

[Erik Stromdahl]

On 11/15/2016 10:57 AM, Michal Kazior wrote:
> On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
>> The RX trailer parsing is now capable of parsing lookahead reports.
>> This is needed by SDIO/mbox.
> 
> It'd be useful to know what exactly lookahead will be used for. What
> payload does it carry.
> 
It carries the 4 first bytes of the next RX message, i.e. the first 4
bytes of an HTC header.

It is used by the sdio interrupt handler to know if the next packet is a
part of an RX bundle, which endpoint it belongs to and how long it is
(so we know how many bytes to allocate).

> 
>> Signed-off-by: Erik Stromdahl 
>> ---
>>  drivers/net/wireless/ath/ath10k/htc.c |   91 
>> -
>>  drivers/net/wireless/ath/ath10k/htc.h |   30 +--
>>  2 files changed, 116 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/htc.c 
>> b/drivers/net/wireless/ath/ath10k/htc.c
>> index 26b1e15..e3f7bf4 100644
>> --- a/drivers/net/wireless/ath/ath10k/htc.c
>> +++ b/drivers/net/wireless/ath/ath10k/htc.c
>> @@ -228,10 +228,74 @@ void ath10k_htc_tx_completion_handler(struct ath10k 
>> *ar, struct sk_buff *skb)
>> spin_unlock_bh(>tx_lock);
>>  }
>>
>> +static int
>> +ath10k_htc_process_lookahead(struct ath10k_htc *htc,
>> +const struct ath10k_htc_lookahead_report 
>> *report,
>> +int len,
>> +enum ath10k_htc_ep_id eid,
>> +u32 *next_lk_ahds,
> 
> next_lk_ahds should be u8 or void. From what I understand by glancing
> through the code it is an agnostic buffer that carries payload which
> is later interpreted either as eid or htc header, right? void is
> probably most suitable in this case for passing around and u8 for
> inline-based storage.
> 
Sounds reasonable, I'll change to void pointer.

> I'd also avoid silly abbreviations. Probably "lookahead" alone is enough.
> 
Ok, this abbreviation was actually taken from the ath6kl code. I think
the intention was to reduce line lengths.

>> +int *next_lk_ahds_len)
>> +{
>> +   struct ath10k *ar = htc->ar;
>> +
>> +   if (report->pre_valid != ((~report->post_valid) & 0xFF))
>> +   /* Invalid lookahead flags are actually transmitted by
>> +* the target in the HTC control message.
>> +* Since this will happen at every boot we silently ignore
>> +* the lookahead in this case
>> +*/
> 
> I'd put this comment before the if().

Ok
> 
> 
>> +   return 0;
>> +
>> +   if (next_lk_ahds && next_lk_ahds_len) {
>> +   ath10k_dbg(ar, ATH10K_DBG_HTC,
>> +  "htc rx lk_ahd found pre_valid 0x%x post_valid 
>> 0x%x\n",
>> +  report->pre_valid, report->post_valid);
>> +
>> +   /* look ahead bytes are valid, copy them over */
>> +   memcpy((u8 *)_lk_ahds[0], report->lk_ahd, 4);
>> +
>> +   *next_lk_ahds_len = 1;
>> +   }
>> +
>> +   return 0;
>> +}
>> +
>> +static int
>> +ath10k_htc_process_lookahead_bundle(struct ath10k_htc *htc,
>> +   const struct 
>> ath10k_htc_lookahead_report_bundle *report,
>> +   int len,
>> +   enum ath10k_htc_ep_id eid,
>> +   u32 *next_lk_ahds,
> 
> Ditto. void.
> 
> 
>> +   int *next_lk_ahds_len)
>> +{
>> +   int bundle_cnt = len / sizeof(*report);
>> +
>> +   if (!bundle_cnt || (bundle_cnt > HTC_HOST_MAX_MSG_PER_BUNDLE)) {
>> +   WARN_ON(1);
> 
> This should be ath10k_warn() instead. This isn't internal driver flow
> assertion. It is possible firmware bug or revision misalignment
> instead.
> 
Ok

> 
>> +   return -EINVAL;
>> +   }
>> +
>> +   if (next_lk_ahds && next_lk_ahds_len) {
>> +   int i;
>> +
>> +   for (i = 0; i < bundle_cnt; i++) {
>> +   memcpy((u8 *)_lk_ahds[i], report->lk_ahd,
>> +  sizeof(u32));
> 
> You'll need to re-adjust the [i] to maintain proper offset with void 
> pointer.
> 
> 
> Michał
> 

Re: [RFC 03/12] ath10k: htc: Changed order of wait target and ep connect

[Erik Stromdahl]

On 11/15/2016 11:13 AM, Michal Kazior wrote:
> On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
>> This patch changes the order in which the driver waits for the
>> target to become ready and the service connect of the HTC
>> control service.
>>
>> The HTC control service is connected before the driver starts
>> waiting for the HTC ready control message.
>>
>> The reason for this is that the HTC ready control message is
>> transmitted on EP 0 and that sdio/mbox based systems will ignore
>> messages received on unconnected endpoints.
>>
>> Signed-off-by: Erik Stromdahl 
>> ---
>>  drivers/net/wireless/ath/ath10k/htc.c |   32 
>> 
>>  1 file changed, 16 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/htc.c 
>> b/drivers/net/wireless/ath/ath10k/htc.c
>> index e3f7bf4..7257366 100644
>> --- a/drivers/net/wireless/ath/ath10k/htc.c
>> +++ b/drivers/net/wireless/ath/ath10k/htc.c
>> @@ -606,6 +606,22 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
>> u16 credit_count;
>> u16 credit_size;
>>
>> +   /* setup our pseudo HTC control endpoint connection */
>> +   memset(_req, 0, sizeof(conn_req));
>> +   memset(_resp, 0, sizeof(conn_resp));
>> +   conn_req.ep_ops.ep_tx_complete = ath10k_htc_control_tx_complete;
>> +   conn_req.ep_ops.ep_rx_complete = ath10k_htc_control_rx_complete;
>> +   conn_req.max_send_queue_depth = ATH10K_NUM_CONTROL_TX_BUFFERS;
>> +   conn_req.service_id = ATH10K_HTC_SVC_ID_RSVD_CTRL;
>> +
>> +   /* connect fake service */
>> +   status = ath10k_htc_connect_service(htc, _req, _resp);
>> +   if (status) {
>> +   ath10k_err(ar, "could not connect to htc service (%d)\n",
>> +  status);
>> +   return status;
>> +   }
>> +
> 
> How is this supposed to work? ath10k_htc_connect_service() requires
> htc->target_credit_size to compute tx_credits_per_max_message. Or am I
> missing something? Applying this patch alone results in:
> 
> [6.680101] divide error:  [#1] SMP
> [6.681342] Modules linked in: ath10k_pci(O) ath10k_core(O) ath
> mac80211 cfg80211
> [6.684876] CPU: 3 PID: 823 Comm: kworker/u8:2 Tainted: GW
> O4.9.0-rc4-wt-ath+ #79
> [6.688051] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
> [6.691644] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
> [6.694309] task: 88000a19 task.stack: c96d4000
> [6.695458] RIP: 0010:[]  []
> ath10k_htc_connect_service+0x21b/0x420 [ath10k_core]
> 
> 
> Michał
> 

You're right. I have totally missed this. What is strange is that my
compiler (ARM linaro) seems to optimize the code in a way that removes
the tx_credits_per_max_message value.

If I add a printk in ath10k_htc_connect_service (printing the value) I
get a similar oops.

I think it has to do with the fact the this value isn't really used at
all. grepping the code reveals that tx_credits_per_max_message is only
used inside ath10k_htc_connect_service (only written, never read).

Removing it doesn't seem to break anything, so perhaps it should be removed?

Or is there something I have missed?

/Erik

Re: [RFC 06/12] ath10k: bmi: Added SOC reg read/write functions

[Erik Stromdahl]

On 11/15/2016 11:28 AM, Michal Kazior wrote:
> On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
>> Added functions implementing the following BMI commands:
>>
>> BMI_READ_SOC_REGISTER
>> BMI_WRITE_SOC_REGISTER
>>
>> Reading and writing BMI registers is sometimes needed for
>> SDIO chipsets.
> 
> I didn't see ath10k_bmi_write_soc_reg nor ath10k_bmi_read_soc_reg
> being used in your Patch 12. Is this patch really necessary?
> 
> 

You are right, these functions are not used in patch 12. They are used
in some other patches that was not included in this series (needs more
cleanup before I can publish). I will remove them from the series.

> [...]
>> diff --git a/drivers/net/wireless/ath/ath10k/bmi.c 
>> b/drivers/net/wireless/ath/ath10k/bmi.c
>> index 2872d34..1c378a2 100644
>> --- a/drivers/net/wireless/ath/ath10k/bmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/bmi.c
>> @@ -97,7 +97,8 @@ int ath10k_bmi_read_memory(struct ath10k *ar,
>> u32 rxlen;
>> int ret;
>>
>> -   ath10k_dbg(ar, ATH10K_DBG_BMI, "bmi read address 0x%x length %d\n",
>> +   ath10k_dbg(ar, ATH10K_DBG_BMI,
>> +  "bmi read memory address 0x%x length %d\n",
>>address, length);
>>
>> if (ar->bmi.done_sent) {
>> @@ -137,7 +138,8 @@ int ath10k_bmi_write_memory(struct ath10k *ar,
>> u32 txlen;
>> int ret;
>>
>> -   ath10k_dbg(ar, ATH10K_DBG_BMI, "bmi write address 0x%x length %d\n",
>> +   ath10k_dbg(ar, ATH10K_DBG_BMI,
>> +  "bmi write memory address 0x%x length %d\n",
>>address, length);
>>
> 
> These 2 hunks shouldn't be modified in this patch. If you want to do a
> clean up this warrants a separate patch :)
> 
> 
> Michał
> 

Ok

/Erik

[PATCHv3 2/2] ath10k: add support for per sta tx bitrate

[akolli]

From: Anilkumar Kolli 

Per STA tx bitrate info is filled from peer stats.
Export per sta txrate info to cfg80211/nl80211

Signed-off-by: Anilkumar Kolli 
---
v2:
 * address Kalle's comments

 drivers/net/wireless/ath/ath10k/debugfs_sta.c |   13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c 
b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 9955fea0802a..fce6f8137d33 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -77,6 +77,19 @@ void ath10k_sta_statistics(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
 
sinfo->rx_duration = arsta->rx_duration;
sinfo->filled |= 1ULL << NL80211_STA_INFO_RX_DURATION;
+
+   if (!arsta->txrate.legacy && !arsta->txrate.nss)
+   return;
+
+   if (arsta->txrate.legacy) {
+   sinfo->txrate.legacy = arsta->txrate.legacy;
+   } else {
+   sinfo->txrate.mcs = arsta->txrate.mcs;
+   sinfo->txrate.nss = arsta->txrate.nss;
+   sinfo->txrate.bw = arsta->txrate.bw;
+   }
+   sinfo->txrate.flags = arsta->txrate.flags;
+   sinfo->filled |= 1ULL << NL80211_STA_INFO_TX_BITRATE;
 }
 
 static ssize_t ath10k_dbg_sta_read_aggr_mode(struct file *file,
-- 
1.7.9.5

[PATCHv3 1/2] ath10k: add per peer htt tx stats support for 10.4

[akolli]

From: Anilkumar Kolli 

Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
event, Firmware sends one HTT event for every four PPDUs.
HTT payload has success pkts/bytes, failed pkts/bytes, retry
pkts/bytes and rate info per ppdu.
Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
which are nowadays enabled by default.

Parse peer stats and update the tx rate information per STA.

tx rate, Peer stats are tested on QCA4019 with Firmware version
10.4-3.2.1-00028.

Signed-off-by: Anilkumar Kolli 
---
v2:
 * address Kalle's comments
 * fix compilation warnings
v3:
 * fix compilation warnings (kvalo)

 drivers/net/wireless/ath/ath10k/core.h   |   17 
 drivers/net/wireless/ath/ath10k/htt.c|2 +
 drivers/net/wireless/ath/ath10k/htt.h|   25 ++
 drivers/net/wireless/ath/ath10k/htt_rx.c |  125 ++
 drivers/net/wireless/ath/ath10k/wmi.h|   10 ++-
 5 files changed, 178 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index e8decfaba5b6..2f324a115b18 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -337,6 +337,7 @@ struct ath10k_sta {
u32 nss;
u32 smps;
u16 peer_id;
+   struct rate_info txrate;
 
struct work_struct update_wk;
 
@@ -693,6 +694,21 @@ struct ath10k_fw_components {
struct ath10k_fw_file fw_file;
 };
 
+struct ath10k_per_peer_tx_stats {
+   u32 succ_bytes;
+   u32 retry_bytes;
+   u32 failed_bytes;
+   u8  ratecode;
+   u8  flags;
+   u16 peer_id;
+   u16 succ_pkts;
+   u16 retry_pkts;
+   u16 failed_pkts;
+   u16 duration;
+   u32 reserved1;
+   u32 reserved2;
+};
+
 struct ath10k {
struct ath_common ath_common;
struct ieee80211_hw *hw;
@@ -906,6 +922,7 @@ struct ath10k {
 
struct ath10k_thermal thermal;
struct ath10k_wow wow;
+   struct ath10k_per_peer_tx_stats peer_tx_stats;
 
/* NAPI */
struct net_device napi_dev;
diff --git a/drivers/net/wireless/ath/ath10k/htt.c 
b/drivers/net/wireless/ath/ath10k/htt.c
index 130cd9502021..cd160b16db1e 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -137,6 +137,8 @@
HTT_T2H_MSG_TYPE_STATS_NOUPLOAD,
[HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND] =
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+   [HTT_10_4_T2H_MSG_TYPE_PEER_STATS] =
+   HTT_T2H_MSG_TYPE_PEER_STATS,
 };
 
 int ath10k_htt_connect(struct ath10k_htt *htt)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h 
b/drivers/net/wireless/ath/ath10k/htt.h
index 0d2ed09f202b..164eb3a10566 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -419,6 +419,7 @@ enum htt_10_4_t2h_msg_type {
HTT_10_4_T2H_MSG_TYPE_STATS_NOUPLOAD = 0x18,
/* 0x19 to 0x2f are reserved */
HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND = 0x30,
+   HTT_10_4_T2H_MSG_TYPE_PEER_STATS = 0x31,
/* keep this last */
HTT_10_4_T2H_NUM_MSGS
 };
@@ -453,6 +454,7 @@ enum htt_t2h_msg_type {
HTT_T2H_MSG_TYPE_TX_FETCH_IND,
HTT_T2H_MSG_TYPE_TX_FETCH_CONFIRM,
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+   HTT_T2H_MSG_TYPE_PEER_STATS,
/* keep this last */
HTT_T2H_NUM_MSGS
 };
@@ -1470,6 +1472,28 @@ struct htt_channel_change {
__le32 phymode;
 } __packed;
 
+struct htt_per_peer_tx_stats_ind {
+   __le32  succ_bytes;
+   __le32  retry_bytes;
+   __le32  failed_bytes;
+   u8  ratecode;
+   u8  flags;
+   __le16  peer_id;
+   __le16  succ_pkts;
+   __le16  retry_pkts;
+   __le16  failed_pkts;
+   __le16  tx_duration;
+   __le32  reserved1;
+   __le32  reserved2;
+} __packed;
+
+struct htt_peer_tx_stats {
+   u8 num_ppdu;
+   u8 ppdu_len;
+   u8 version;
+   u8 payload[0];
+} __packed;
+
 union htt_rx_pn_t {
/* WEP: 24-bit PN */
u32 pn24;
@@ -1521,6 +1545,7 @@ struct htt_resp {
struct htt_tx_fetch_confirm tx_fetch_confirm;
struct htt_tx_mode_switch_ind tx_mode_switch_ind;
struct htt_channel_change chan_change;
+   struct htt_peer_tx_stats peer_tx_stats;
};
 } __packed;
 
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 285b235268d7..86d082cf4eef 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2194,6 +2194,128 @@ void ath10k_htt_htc_t2h_msg_handler(struct ath10k *ar, 
struct sk_buff *skb)
dev_kfree_skb_any(skb);
 }
 
+static inline bool is_valid_legacy_rate(u8 rate)
+{
+  

Re: [v3,1/2] ath10k: clean up HTT tx buffer allocation and free

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> cleanup 'ath10k_htt_tx_alloc' by introducing the API's
> 'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
> re-use them whereever needed
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

2 patches applied to ath-next branch of ath.git, thanks.

19f338c6eb0c ath10k: clean up HTT tx buffer allocation and free
f004e532a80a ath10k: remove extraneous error message in tx alloc

-- 
https://patchwork.kernel.org/patch/9373055/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: Avery's notes from LPC2016 wireless track (Santa Fe)

[Jes Sorensen]

Avery Pennarun  writes:
> On Thu, Nov 3, 2016 at 5:55 PM, Barry Day  wrote:
>> Thanks for that. Can I take this as meaning there won't be any videos?
>> I would like to have seen Jes Sorensen's talk on rtl8xxxu
>
> As far as I know, no talks at this LPC were recorded.

They weren't but my slides should be available from the Plumbers site.

https://www.linuxplumbersconf.org/2016/ocw/proposals/4089

Cheers,
Jes

Re: [1/1] ath10k: use the right length of "background"

[Kalle Valo]

Nicolas Iooss  wrote:
> The word "background" contains 10 characters so the third argument of
> strncmp() need to be 10 in order to match this prefix correctly.
> 
> Signed-off-by: Nicolas Iooss 
> Fixes: 855aed1220d2 ("ath10k: add spectral scan feature")

Patch applied to ath-next branch of ath.git, thanks.

31b239824ece ath10k: use the right length of "background"

-- 
https://patchwork.kernel.org/patch/9403561/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC

[Jes Sorensen]

Barry Day  writes:
> On Mon, Oct 31, 2016 at 06:41:30PM -0400, Jes Sorensen wrote:
>> Barry Day  writes:
>> > On Mon, Oct 31, 2016 at 05:25:12PM -0400, Jes Sorensen wrote:
>> >> As mentioned previously, if this is to be changed here, it has to be
>> >> matched in the _stop section too. It also has to be investigated exactly
>> >> why this matters for 8723bu. It is possible this matters for other
>> >> devices, but we need to find out exactly what causes this not moving a
>> >> major block of init code around like this.
>> >
>> > I've tested this on the 8192e and 8192c. The same problems occurs with the
>> > 8192e but not the 8192c. Stopping and restarting wpa_supplicant had
>> > no affect on the 8192c ability to connect to an AP.
>> 
>> Which version of the driver? I did push in some changes for 8192eu
>> recently that fixed the issue with 8192eu driver reloading, and I would
>> be interested in knowing if this didn't fix the problem for you?
>> 
>> Second, could we please keep this on the linux-wireless list where it
>> belongs. Everybody else doesn't necessarily want to receive a copy via
>> netdev and linux-kernel
>
> The tests were done with the latest version of rtl8xxxu-devel. I haven't
> noticed any occurence of the previous issue with the 8192eu.

OK, I am back from my trip, but still burried alive catching up on
things. This is very much on the list of things I want to investigate.

Jes

Re: [OpenWrt-Devel] ATH10K VLAN firmware issue

[Ben Greear]

On 11/15/2016 07:00 AM, Bruno Antunes wrote:

On 15 November 2016 at 14:55, Ben Greear  wrote:

The beta-18 release on my web page has the fix and should work fine.

Probably soon I will promote the beta-18 to final release
status.  Any help in testing and verifying the beta works well
is welcome.


I will also do testing with that version.

For clarity can I refer you and your firmware releases in the bug report?


It is fine by me.  It is a one-line patch to fix the firmware...QCA
can ask me as well if they don't figure it out on their own.

Thanks,
Ben



Thanks,
Bruno


Thanks,
Ben

On 11/15/2016 06:37 AM, voncken wrote:


 Hi Ben,

 Do you plan to release a candelatech firmware with this fix?

 Regards.

Cedric Voncken.


-Message d'origine-
De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
ow...@vger.kernel.org] De la part de Ben Greear
Envoyé : samedi 5 novembre 2016 15:35
À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
Development List; ath...@lists.infradead.org
Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue


Looks to me like 10.4 defaults to the right value, but possibly there
are other issues with it.  I tested my CT 10.4 and it worked OK with
vlans for me.

Thanks,
Ben

On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:


would be good if qca can fix this bug finally in all available
firmwares. its a very annoying issue since a long time

Sebastian


Am 04.11.2016 um 23:23 schrieb Ben Greear:


The bug appears that vlan-tx-stripping is unconditionally enabled in
at least my firmware.  I have re-compiled w/out that flag set, and


it


appears to work for me.

Please download this firmware, rename it firmware-2.bin, make sure
you remove/rename any firmware-5.bin (etc) so mine will load, and


see if that fixes your problem.



Please note that it is very likely you will have to use same MAC
address for the VLAN devices that the underlying station uses in


order for this to work.



https://www.candelatech.com/downloads/tmp/firmware-2-full-


community.b


in


Thanks,
Ben


On 11/04/2016 02:50 PM, Ben Greear wrote:


I can reproduce this in my CT firmware. I'll see if I can fix it,
but for stock firmware, it might be that changing the driver to use
Ethernet packet type of native-wifi would make .1q vlans work.

Thanks,
Ben

On 11/04/2016 10:28 AM, yu-chieh kung wrote:


I met the same problem before,
if i modify the 1q header to other value (0xaa00) before go into


firmware.


I can capture the packet in the air I think the vlan packet is
dropped in firmware.

2016-11-04 22:41 GMT+08:00 Bruno Antunes :


On 4 November 2016 at 14:18, Mauro Mozzarelli


 wrote:


Since the capability is implemented in software you might be
testing the limit of your router's CPU i/o speed.



By loading the module in rawmode?

The AP is an APU and Sta is an APU2.





On 04/11/16 14:13, Bruno Antunes wrote:



Hi all,

Old thread but I think the issue is still present.

I'm running a setup with VLANs with WDS and ath10k cards.

To make it work both cards must be loaded in rawmode, AP and
Sta, and with no security.

I'm using a OpenWrt trunk r49941 and the most recent firmware,
10.2.4.70.58, from Kalle ath10k firmware tree.

Although it works the throughput is very bad.
Are there any alternatives to improve the throughput.

Best Regards,
Bruno

On 9 December 2015 at 17:24, voncken 


wrote:





-Message d'origine-
De : Ben Greear [mailto:gree...@candelatech.com] Envoyé :
mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
ath...@lists.infradead.org; linux-wireless Objet : Re: ATH10K
VLAN firmware issue

This only happens when you use STA  + WDS, or is .1q broken
for you in other cases as well?



No, this issue occurs in all modes (STA, STA + WDS, AP).

Thanks

Cedric.


Thanks,
Ben

On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:



   I'm testing to transmit frame with 802.1q tag (VLAN).

   My client is set in STA + WDS and the netdev is bridged


with eth0.


   I have a computer with vlan configuration set connected
to the STA eth0.

   If I try to transmit frames with 802.1q tag, the frames
are not



sent.



   I checked with wireless sniffer, and I don't see the
frame with VLAN tag (the frames without VLAN tag are sent).

   I tested with firmware 10.2.4.70.14-2 from kale github,
10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
from openwrt, and in all cases I have the same issue.

   Thanks for your help.


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


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



--
To unsubscribe from this list: send the 

Re: ath10k: Fix failure to send NULL func frame for 10.4

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> This partially reverts 'commit 2cdce425aa33
> ("ath10k: Fix broken NULL func data frame status for 10.4")'
> Unfortunately this breaks sending NULL func and the existing
> issue of obtaining proper tx status for NULL function will be
> fixed. Also update the comments for feature flag added to be
> useless and not working
> 
> Fixes: 2cdce425aa33 "ath10k: Fix broken NULL func data frame status for
> 10.4"
> Signed-off-by: Mohammed Shafi Shajakhan 

Patch applied to ath-next branch of ath.git, thanks.

fcf7cf1551ca ath10k: fix failure to send NULL func frame for 10.4

-- 
https://patchwork.kernel.org/patch/9372171/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v6] ath9k: Switch to using mac80211 intermediate software queues.

[Kalle Valo]

Toke Høiland-Jørgensen wrote:
> This switches ath9k over to using the mac80211 intermediate software
> queueing mechanism for data packets. It removes the queueing inside the
> driver, except for the retry queue, and instead pulls from mac80211 when
> a packet is needed. The retry queue is used to store a packet that was
> pulled but can't be sent immediately.
> 
> The old code path in ath_tx_start that would queue packets has been
> removed completely, as has the qlen limit tunables (since there's no
> longer a queue in the driver to limit).
> 
> The mac80211 intermediate software queues offer significant latency
> reductions, and this patch allows ath9k to realise them. The exact gains
> from this varies with the test scenario, but in an access point scenario
> we have seen latency reductions ranging from 1/3 to as much as an order
> of magnitude. We also achieve slightly better aggregation.
> 
> Median latency (ping) figures with this patch applied at the access point,
> with two high-rate stations and one low-rate station (HT20 5Ghz), running
> a Flent rtt_fair_var_up test with one TCP flow and one ping flow going to
> each station:
> 
>  Fast stationSlow station
> Default pfifo_fast qdisc:430.4 ms638.7 ms
> fq_codel qdisc on iface:  35.5 ms211.8 ms
> This patch set:   22.4 ms 38.2 ms
> 
> Median aggregation sizes over the same test:
> 
> Default pfifo_fast qdisc:9.5 pkts1.9 pkts
> fq_codel qdisc on iface:11.2 pkts1.9 pkts
> This patch set: 13.9 pkts1.9 pkts
> 
> This patch is based on Tim's original patch set, but reworked quite
> thoroughly.
> 
> Cc: Tim Shepard 
> Cc: Felix Fietkau 
> Signed-off-by: Toke Høiland-Jørgensen 

Patch applied to ath-next branch of ath.git, thanks.

50f08edf9809 ath9k: Switch to using mac80211 intermediate software queues.

-- 
https://patchwork.kernel.org/patch/9419029/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [OpenWrt-Devel] ATH10K VLAN firmware issue

[Bruno Antunes]

On 15 November 2016 at 14:55, Ben Greear  wrote:
> The beta-18 release on my web page has the fix and should work fine.
>
> Probably soon I will promote the beta-18 to final release
> status.  Any help in testing and verifying the beta works well
> is welcome.

I will also do testing with that version.

For clarity can I refer you and your firmware releases in the bug report?

Thanks,
Bruno
>
> Thanks,
> Ben
>
> On 11/15/2016 06:37 AM, voncken wrote:
>>
>> Hi Ben,
>>
>> Do you plan to release a candelatech firmware with this fix?
>>
>> Regards.
>>
>> Cedric Voncken.
>>>
>>> -Message d'origine-
>>> De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
>>> ow...@vger.kernel.org] De la part de Ben Greear
>>> Envoyé : samedi 5 novembre 2016 15:35
>>> À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
>>> Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
>>> Development List; ath...@lists.infradead.org
>>> Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
>>>
>>>
>>> Looks to me like 10.4 defaults to the right value, but possibly there
>>> are other issues with it.  I tested my CT 10.4 and it worked OK with
>>> vlans for me.
>>>
>>> Thanks,
>>> Ben
>>>
>>> On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:

 would be good if qca can fix this bug finally in all available
 firmwares. its a very annoying issue since a long time

 Sebastian


 Am 04.11.2016 um 23:23 schrieb Ben Greear:
>
> The bug appears that vlan-tx-stripping is unconditionally enabled in
> at least my firmware.  I have re-compiled w/out that flag set, and
>>>
>>> it
>
> appears to work for me.
>
> Please download this firmware, rename it firmware-2.bin, make sure
> you remove/rename any firmware-5.bin (etc) so mine will load, and
>>>
>>> see if that fixes your problem.
>
>
> Please note that it is very likely you will have to use same MAC
> address for the VLAN devices that the underlying station uses in
>>>
>>> order for this to work.
>
>
> https://www.candelatech.com/downloads/tmp/firmware-2-full-
>>>
>>> community.b
>
> in
>
>
> Thanks,
> Ben
>
>
> On 11/04/2016 02:50 PM, Ben Greear wrote:
>>
>> I can reproduce this in my CT firmware. I'll see if I can fix it,
>> but for stock firmware, it might be that changing the driver to use
>> Ethernet packet type of native-wifi would make .1q vlans work.
>>
>> Thanks,
>> Ben
>>
>> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
>>>
>>> I met the same problem before,
>>> if i modify the 1q header to other value (0xaa00) before go into
>>>
>>> firmware.
>>>
>>> I can capture the packet in the air I think the vlan packet is
>>> dropped in firmware.
>>>
>>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes :

 On 4 November 2016 at 14:18, Mauro Mozzarelli
>>>
>>>  wrote:
>
> Since the capability is implemented in software you might be
> testing the limit of your router's CPU i/o speed.


 By loading the module in rawmode?

 The AP is an APU and Sta is an APU2.

>
>
>
> On 04/11/16 14:13, Bruno Antunes wrote:
>>
>>
>> Hi all,
>>
>> Old thread but I think the issue is still present.
>>
>> I'm running a setup with VLANs with WDS and ath10k cards.
>>
>> To make it work both cards must be loaded in rawmode, AP and
>> Sta, and with no security.
>>
>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>
>> Although it works the throughput is very bad.
>> Are there any alternatives to improve the throughput.
>>
>> Best Regards,
>> Bruno
>>
>> On 9 December 2015 at 17:24, voncken 
>>>
>>> wrote:
>>>
>>>
>>>
 -Message d'origine-
 De : Ben Greear [mailto:gree...@candelatech.com] Envoyé :
 mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
 ath...@lists.infradead.org; linux-wireless Objet : Re: ATH10K
 VLAN firmware issue

 This only happens when you use STA  + WDS, or is .1q broken
 for you in other cases as well?
>>>
>>>
>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>
>>> Thanks
>>>
>>> Cedric.
>>>
 Thanks,
 Ben

 On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>
>
>   I'm testing to transmit frame with 802.1q tag (VLAN).
>

Re: ath9k_htc: fix minor mistakes in dev_err messages

[Kalle Valo]

Colin Ian King  wrote:
> From: Colin Ian King 
> 
> Add missing space in a dev_err message and join wrapped text so
> it does not span multiple lines.  Fix spelling mistake on "unknown".
> 
> Signed-off-by: Colin Ian King 

Patch applied to ath-next branch of ath.git, thanks.

14acebc33e6d ath9k_htc: fix minor mistakes in dev_err messages

-- 
https://patchwork.kernel.org/patch/9405663/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v8, 1/3] Documentation: dt: net: add ath9k wireless device binding

[Kalle Valo]

Martin Blumenstingl  wrote:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
> 
> Signed-off-by: Martin Blumenstingl 
> Acked-by: Rob Herring 

3 patches applied to ath-next branch of ath.git, thanks.

fc383ffdb91a Documentation: dt: net: add ath9k wireless device binding
b40ded2ad75c ath9k: add a helper to get the string representation of 
ath_bus_type
138b41253d9c ath9k: parse the device configuration from an OF node

-- 
https://patchwork.kernel.org/patch/9378317/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [OpenWrt-Devel] ATH10K VLAN firmware issue

[Ben Greear]

The beta-18 release on my web page has the fix and should work fine.

Probably soon I will promote the beta-18 to final release
status.  Any help in testing and verifying the beta works well
is welcome.

Thanks,
Ben

On 11/15/2016 06:37 AM, voncken wrote:

Hi Ben,

Do you plan to release a candelatech firmware with this fix?

Regards.

Cedric Voncken.

-Message d'origine-
De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
ow...@vger.kernel.org] De la part de Ben Greear
Envoyé : samedi 5 novembre 2016 15:35
À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
Development List; ath...@lists.infradead.org
Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue

Looks to me like 10.4 defaults to the right value, but possibly there
are other issues with it.  I tested my CT 10.4 and it worked OK with
vlans for me.

Thanks,
Ben

On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:

would be good if qca can fix this bug finally in all available
firmwares. its a very annoying issue since a long time

Sebastian


Am 04.11.2016 um 23:23 schrieb Ben Greear:

The bug appears that vlan-tx-stripping is unconditionally enabled in
at least my firmware.  I have re-compiled w/out that flag set, and

it

appears to work for me.

Please download this firmware, rename it firmware-2.bin, make sure
you remove/rename any firmware-5.bin (etc) so mine will load, and

see if that fixes your problem.


Please note that it is very likely you will have to use same MAC
address for the VLAN devices that the underlying station uses in

order for this to work.


https://www.candelatech.com/downloads/tmp/firmware-2-full-

community.b

in


Thanks,
Ben


On 11/04/2016 02:50 PM, Ben Greear wrote:

I can reproduce this in my CT firmware. I'll see if I can fix it,
but for stock firmware, it might be that changing the driver to use
Ethernet packet type of native-wifi would make .1q vlans work.

Thanks,
Ben

On 11/04/2016 10:28 AM, yu-chieh kung wrote:

I met the same problem before,
if i modify the 1q header to other value (0xaa00) before go into

firmware.

I can capture the packet in the air I think the vlan packet is
dropped in firmware.

2016-11-04 22:41 GMT+08:00 Bruno Antunes :

On 4 November 2016 at 14:18, Mauro Mozzarelli

 wrote:

Since the capability is implemented in software you might be
testing the limit of your router's CPU i/o speed.


By loading the module in rawmode?

The AP is an APU and Sta is an APU2.





On 04/11/16 14:13, Bruno Antunes wrote:


Hi all,

Old thread but I think the issue is still present.

I'm running a setup with VLANs with WDS and ath10k cards.

To make it work both cards must be loaded in rawmode, AP and
Sta, and with no security.

I'm using a OpenWrt trunk r49941 and the most recent firmware,
10.2.4.70.58, from Kalle ath10k firmware tree.

Although it works the throughput is very bad.
Are there any alternatives to improve the throughput.

Best Regards,
Bruno

On 9 December 2015 at 17:24, voncken 

wrote:




-Message d'origine-
De : Ben Greear [mailto:gree...@candelatech.com] Envoyé :
mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
ath...@lists.infradead.org; linux-wireless Objet : Re: ATH10K
VLAN firmware issue

This only happens when you use STA  + WDS, or is .1q broken
for you in other cases as well?


No, this issue occurs in all modes (STA, STA + WDS, AP).

Thanks

Cedric.


Thanks,
Ben

On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:


  I'm testing to transmit frame with 802.1q tag (VLAN).

  My client is set in STA + WDS and the netdev is bridged

with eth0.

  I have a computer with vlan configuration set connected
to the STA eth0.

  If I try to transmit frames with 802.1q tag, the frames
are not


sent.


  I checked with wireless sniffer, and I don't see the
frame with VLAN tag (the frames without VLAN tag are sent).

  I tested with firmware 10.2.4.70.14-2 from kale github,
10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
from openwrt, and in all cases I have the same issue.

  Thanks for your help.


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


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


___
openwrt-devel mailing list
openwrt-de...@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-

devel


___
openwrt-devel mailing list
openwrt-de...@lists.openwrt.org

Re: ath9k: Move generic entries below specific ones in ath_pci_id_table.

[Kalle Valo]

"Vittorio Gambaletta \(VittGam\)"  wrote:
> If generic entries are positioned above specific ones, then the
> former will be matched first and used instead of the latter.
> 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Signed-off-by: Vittorio Gambaletta 
> Signed-off-by: Vittorio Gambaletta 
> Signed-off-by: Kalle Valo 
> Signed-off-by: Vittorio Gambaletta 
> Signed-off-by: Kalle Valo 
> 
> --- a/drivers/net/wireless/ath/ath9k/pci.c
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -26,7 +26,6 @@
>   { PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI   */
>   { PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
>   { PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI   */
> - { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI   */
>  
>  #ifdef CONFIG_ATH9K_PCOEM
>   /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
> @@ -37,7 +36,7 @@
> .driver_data = ATH9K_PCI_LED_ACT_HI },
>  #endif
>  
> - { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
> + { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI   */
>  
>  #ifdef CONFIG_ATH9K_PCOEM
>   { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
> @@ -85,7 +84,11 @@
>0x10CF, /* Fujitsu */
>0x1536),
> .driver_data = ATH9K_PCI_D3_L1_WAR },
> +#endif
>  
> + { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
> +
> +#ifdef CONFIG_ATH9K_PCOEM
>   /* AR9285 card for Asus */
>   { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
>0x002B,

Patch applied to ath-next branch of ath.git, thanks.

79e57dd113d3 ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.

-- 
https://patchwork.kernel.org/patch/9360361/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [OpenWrt-Devel] ATH10K VLAN firmware issue

[Bruno Antunes]

On 15 November 2016 at 13:43, Valo, Kalle  wrote:
> Bruno Antunes  writes:
>
>> On 7 November 2016 at 18:06, Valo, Kalle  wrote:
>>> Bruno Antunes  writes:
>>>
 On 4 November 2016 at 21:17, Valo, Kalle  wrote:

> Can someone file a bug to bugzilla about this so that all the info is
> properly stored? The more comprehensive the report is the better.
>
> https://bugzilla.kernel.org/

 I will file a bug report.
>>>
>>> Thanks, it's good to store all in one place so that it's easier to find
>>> the relevant info.
>>
>> Just file the bug with the ID 187241 - VLAN support in ATH10k Feel
>> free to ask for adicional info. I did not mention any names in the bug
>> report fell free to take credit if wanted.
>
> Thanks. I'll report it to the firmware team, let's see what happens. If
> there's more information which might help to fix this feel free to
> update that to the bug report.

I'm finishing my tests and will update the bug report ASAP.

Turns out the bad throughput was the result of a failure in the switch port.

With Ben's firmware the VLAN support is working fine with security.

Thanks,
Bruno
>
> https://bugzilla.kernel.org/show_bug.cgi?id=187241
>
> --
> Kalle Valo

Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.

[Valo, Kalle]

"Vittorio Gambaletta (VittGam)"  writes:

> Hello,
>
> On 12/10/2016 17:01:08 CEST, Valo, Kalle wrote:
>
>> So to tell the full story I'll change the commit log to something like
>> below. Does it look ok to you?
>
> Yes; but I'd change "So" to "This turned out to be wrong", and add a note
> about changing the order for 0x002A too:
>
> --
> ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.
>
> The active_high LED of my Wistron DNMA-92 is still being recognized as
> active_low on 4.7.6 mainline. When I was preparing my former commit
> 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92
> cards.") to fix that I must have somehow messed up with testing, because
> I tested the final version of that patch before sending it, and it was
> apparently working; but now it is not working on 4.7.6 mainline.
>
> I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the
> PCI_VDEVICE section for 0x0029; but then I moved the former below the
> latter after seeing how 0x002A sections were sorted in the file.
>
> This turned out to be wrong: if a generic PCI_VDEVICE entry (that has
> both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more
> specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will
> match first and will be used.
>
> With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.
>
> While I'm at it, let's fix 0x002A too by also moving its generic definition
> below its specific ones.
>
> Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 
> cards.")
> Cc:  #4.7+
> Signed-off-by: Vittorio Gambaletta 
> [kv...@qca.qualcomm.com: improve the commit log based on email discussions]
> Signed-off-by: Kalle Valo 
> --

Thanks, I updated the commit with your changes.

-- 
Kalle Valo

Re: [PATCHv2,1/2] ath10k: add per peer htt tx stats support for 10.4

[Kalle Valo]

ako...@qti.qualcomm.com wrote:
> From: Anilkumar Kolli 
> 
> Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
> event, Firmware sends one HTT event for every four PPDUs.
> HTT payload has success pkts/bytes, failed pkts/bytes, retry
> pkts/bytes and rate info per ppdu.
> Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
> which are nowadays enabled by default.
> 
> Parse peer stats and update the tx rate information per STA.
> 
> tx rate, Peer stats are tested on QCA4019 with Firmware version
> 10.4-3.2.1-00028.
> 
> Signed-off-by: Anilkumar Kolli 

I see a new sparse warning:

drivers/net/wireless/ath/ath10k/htt_rx.c:2290:17: warning: incorrect type in 
assignment (different base types)
drivers/net/wireless/ath/ath10k/htt_rx.c:2290:17:expected int [signed] 
peer_id
drivers/net/wireless/ath/ath10k/htt_rx.c:2290:17:got restricted __le16 
[usertype] peer_id

2 patches set to Changes Requested.

9381691 [PATCHv2,1/2] ath10k: add per peer htt tx stats support for 10.4
9381693 [PATCHv2,2/2] ath10k: add support for per sta tx bitrate

-- 
https://patchwork.kernel.org/patch/9381691/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Kalle Valo]

Gianfranco Costamagna  writes:

>> Signed-off-by: Nicola Smaldone 
>
>> Signed-off-by: Arlone Marco 
>
>>Please note that you cannot add Signed-off-by for other people without
>>their explicit approval (see Documentation/SubmittingPatches). I don't
>>know if they did it in this case or not, but wanted to point out this
>>anyway.
>
>
> The first signoff is myself, with the company email, the other two signoffs
> are from: the author, and Nicola, who did work with me to test it
> (even if a typo fix is not "testable").
>
> Nicola, Marco, is it ok to add your two names in the signoff part?
> (that was a verbal talk, I don't have anything written)

Good, so we got now approvals from both of them. Thanks.

-- 
Kalle Valo

Re: [OpenWrt-Devel] ATH10K VLAN firmware issue

[Valo, Kalle]

Bruno Antunes  writes:

> On 7 November 2016 at 18:06, Valo, Kalle  wrote:
>> Bruno Antunes  writes:
>>
>>> On 4 November 2016 at 21:17, Valo, Kalle  wrote:
>>>
 Can someone file a bug to bugzilla about this so that all the info is
 properly stored? The more comprehensive the report is the better.

 https://bugzilla.kernel.org/
>>>
>>> I will file a bug report.
>>
>> Thanks, it's good to store all in one place so that it's easier to find
>> the relevant info.
>
> Just file the bug with the ID 187241 - VLAN support in ATH10k Feel
> free to ask for adicional info. I did not mention any names in the bug
> report fell free to take credit if wanted.

Thanks. I'll report it to the firmware team, let's see what happens. If
there's more information which might help to fix this feel free to
update that to the bug report.

https://bugzilla.kernel.org/show_bug.cgi?id=187241

-- 
Kalle Valo

Re: [PATCH] fixed hwsim beacon delta calculation

[Johannes Berg]

On Fri, 2016-11-11 at 17:37 +0100, Benjamin Beichler wrote:
> Due to the cast from uint32_t to int64_t, a wrong next beacon timing
> is
> calculated and effectively the beacon timer stops to work. This is
> especially bad for 802.11s mesh networks, because discovery breaks
> without beacons.
> 
Applied. Please note how I changed the commit subject, and use that
scheme in the future.

johannes

Re: [PATCH 3/4] dt: bindings: add new dt entry for BTCOEX feature in qcom, ath10k.txt

[Valo, Kalle]

(Adding devicetree list)

 writes:

> From: Tamizh chelvam 
>
> There two things done in this patch.
>
> 1) 'btcoex_support' flag for BTCOEX feature support by the hardware.
> 2) 'wlan_btcoex_gpio' is used to fill wlan priority pin number for
>BTCOEX priority feature support.
>
> Signed-off-by: Tamizh chelvam 
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt  |4 
>  1 file changed, 4 insertions(+)

As this changes the device tree bindings you need to CC the device tree
list. Please resend the whole patchset (and mark it as v2).

-- 
Kalle Valo

Re: [PATCH 1/3] mac80211: update A-MPDU flag on tx dequeue

[Johannes Berg]

All three applied, thanks.

johannes

[PATCH v4 3/3] mwifiex: Enable WoWLAN for both sdio and pcie

[Amitkumar Karwar]

From: Rajat Jain 

Commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt
support") added WoWLAN feature only for sdio. This patch moves that
code to the common module so that all the interface drivers can use
it for free. It enables pcie and sdio for its use currently.

Signed-off-by: Rajat Jain 
---
v2: v1 doesn't apply smoothly on latest code due to recently merged
patch "mwifiex: report error to PCIe for suspend failure". Minor
conflict is resolved in v2
v4: Same as v2, v3
---
 drivers/net/wireless/marvell/mwifiex/main.c | 41 
 drivers/net/wireless/marvell/mwifiex/main.h | 25 ++
 drivers/net/wireless/marvell/mwifiex/pcie.c |  2 +
 drivers/net/wireless/marvell/mwifiex/sdio.c | 72 ++---
 drivers/net/wireless/marvell/mwifiex/sdio.h |  8 
 5 files changed, 73 insertions(+), 75 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 835d330..948f5c2 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1552,14 +1552,55 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, 
bool prepare)
 }
 EXPORT_SYMBOL_GPL(mwifiex_do_flr);
 
+static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
+{
+   struct mwifiex_adapter *adapter = priv;
+
+   if (adapter->irq_wakeup >= 0) {
+   dev_dbg(adapter->dev, "%s: wake by wifi", __func__);
+   adapter->wake_by_wifi = true;
+   disable_irq_nosync(irq);
+   }
+
+   /* Notify PM core we are wakeup source */
+   pm_wakeup_event(adapter->dev, 0);
+
+   return IRQ_HANDLED;
+}
+
 static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
 {
+   int ret;
struct device *dev = adapter->dev;
 
if (!dev->of_node)
return;
 
adapter->dt_node = dev->of_node;
+   adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
+   if (!adapter->irq_wakeup) {
+   dev_info(dev, "fail to parse irq_wakeup from device tree\n");
+   return;
+   }
+
+   ret = devm_request_irq(dev, adapter->irq_wakeup,
+  mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
+  "wifi_wake", adapter);
+   if (ret) {
+   dev_err(dev, "Failed to request irq_wakeup %d (%d)\n",
+   adapter->irq_wakeup, ret);
+   goto err_exit;
+   }
+
+   disable_irq(adapter->irq_wakeup);
+   if (device_init_wakeup(dev, true)) {
+   dev_err(dev, "fail to init wakeup for mwifiex\n");
+   goto err_exit;
+   }
+   return;
+
+err_exit:
+   adapter->irq_wakeup = 0;
 }
 
 /*
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 549e1ba..ae5afe5 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1011,6 +1011,10 @@ struct mwifiex_adapter {
bool usb_mc_setup;
struct cfg80211_wowlan_nd_info *nd_info;
struct ieee80211_regdomain *regd;
+
+   /* Wake-on-WLAN (WoWLAN) */
+   int irq_wakeup;
+   bool wake_by_wifi;
 };
 
 void mwifiex_process_tx_queue(struct mwifiex_adapter *adapter);
@@ -1410,6 +1414,27 @@ static inline u8 mwifiex_is_tdls_link_setup(u8 status)
return false;
 }
 
+/* Disable platform specific wakeup interrupt */
+static inline void mwifiex_disable_wake(struct mwifiex_adapter *adapter)
+{
+   if (adapter->irq_wakeup >= 0) {
+   disable_irq_wake(adapter->irq_wakeup);
+   if (!adapter->wake_by_wifi)
+   disable_irq(adapter->irq_wakeup);
+   }
+}
+
+/* Enable platform specific wakeup interrupt */
+static inline void mwifiex_enable_wake(struct mwifiex_adapter *adapter)
+{
+   /* Enable platform specific wakeup interrupt */
+   if (adapter->irq_wakeup >= 0) {
+   adapter->wake_by_wifi = false;
+   enable_irq(adapter->irq_wakeup);
+   enable_irq_wake(adapter->irq_wakeup);
+   }
+}
+
 int mwifiex_init_shutdown_fw(struct mwifiex_private *priv,
 u32 func_init_shutdown);
 int mwifiex_add_card(void *card, struct semaphore *sem,
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 745ecd6..e8f4f90 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -131,6 +131,7 @@ static int mwifiex_pcie_suspend(struct device *dev)
}
 
adapter = card->adapter;
+   mwifiex_enable_wake(adapter);
 
/* Enable the Host Sleep */
if (!mwifiex_enable_hs(adapter)) {
@@ -186,6 +187,7 @@ static int mwifiex_pcie_resume(struct device *dev)
 
mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
 

[PATCH v4 1/3] mwifiex: Allow mwifiex early access to device structure

[Amitkumar Karwar]

From: Rajat Jain 

Today all the interface drivers (usb/pcie/sdio) assign the
adapter->dev in the register_dev() callback, although they
have this piece of info well before hand.

This patch makes the device structure available for mwifiex
right at the beginning, so that it can be used for early
initialization if needed.

This is needed for subsequent patches in this patchset that
intend to unify and consolidate some of the code that would
otherwise have to be duplicated among the interface drivers
(sdio, pcie, usb).

Signed-off-by: Rajat Jain 
Signed-off-by: Amitkumar Karwar 
---
v2: Same as v1
v3: Fixed checkpatch warnings
WARNING: function definition argument 'void *' should also have an identifier 
name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,

WARNING: function definition argument 'struct semaphore *' should also have an 
identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,

WARNING: function definition argument 'struct mwifiex_if_ops *' should also 
have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,

WARNING: function definition argument 'u8' should also have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,

WARNING: function definition argument 'struct device *' should also have an 
identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,
v4: Rebase v3 on top of "[v7] mwifiex: parse device tree node for PCIe"
---
 drivers/net/wireless/marvell/mwifiex/main.c | 4 +++-
 drivers/net/wireless/marvell/mwifiex/main.h | 4 +++-
 drivers/net/wireless/marvell/mwifiex/pcie.c | 4 +---
 drivers/net/wireless/marvell/mwifiex/sdio.c | 5 +
 drivers/net/wireless/marvell/mwifiex/usb.c  | 3 +--
 5 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 2478ccd..dcceab2 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1567,7 +1567,8 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool 
prepare)
  */
 int
 mwifiex_add_card(void *card, struct semaphore *sem,
-struct mwifiex_if_ops *if_ops, u8 iface_type)
+struct mwifiex_if_ops *if_ops, u8 iface_type,
+struct device *dev)
 {
struct mwifiex_adapter *adapter;
 
@@ -1579,6 +1580,7 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool 
prepare)
goto err_init_sw;
}
 
+   adapter->dev = dev;
adapter->iface_type = iface_type;
adapter->card_sem = sem;
 
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index d61fe3a..549e1ba 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1412,7 +1412,9 @@ static inline u8 mwifiex_is_tdls_link_setup(u8 status)
 
 int mwifiex_init_shutdown_fw(struct mwifiex_private *priv,
 u32 func_init_shutdown);
-int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8);
+int mwifiex_add_card(void *card, struct semaphore *sem,
+struct mwifiex_if_ops *if_ops, u8 iface_type,
+struct device *dev);
 int mwifiex_remove_card(struct mwifiex_adapter *, struct semaphore *);
 
 void mwifiex_get_version(struct mwifiex_adapter *adapter, char *version,
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 83a41b5..745ecd6 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -231,7 +231,7 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
}
 
if (mwifiex_add_card(card, _remove_card_sem, _ops,
-MWIFIEX_PCIE)) {
+MWIFIEX_PCIE, >dev)) {
pr_err("%s failed\n", __func__);
return -1;
}
@@ -2995,11 +2995,9 @@ static void mwifiex_pcie_get_fw_name(struct 
mwifiex_adapter *adapter)
 static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
 {
struct pcie_service_card *card = adapter->card;
-   struct pci_dev *pdev = card->dev;
 
/* save adapter pointer in card */
card->adapter = adapter;
-   adapter->dev = >dev;
 
if (mwifiex_pcie_request_irq(adapter))
return -1;
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 

[PATCH v4 2/3] mwifiex: Introduce mwifiex_probe_of() to parse common properties

[Amitkumar Karwar]

From: Rajat Jain 

Introduce function mwifiex_probe_of() to parse common properties.
Interface drivers get to decide whether or not the device tree node
was a valid one (depending on the compatible property),
Lets fill "adapter->dt_node" in mwifiex_add_card().

The function mwifiex_probe_of() is currently only a place holder with
the next patch adding content to it.

Signed-off-by: Rajat Jain 
Signed-off-by: Amitkumar Karwar 
---
v2: Same as v1
v3: Redundant flag "of_node_valid" is removed (Brian)
v4: Same as v3
---
 drivers/net/wireless/marvell/mwifiex/main.c| 12 
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c |  5 +
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index dcceab2..835d330 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1552,6 +1552,16 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, 
bool prepare)
 }
 EXPORT_SYMBOL_GPL(mwifiex_do_flr);
 
+static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
+{
+   struct device *dev = adapter->dev;
+
+   if (!dev->of_node)
+   return;
+
+   adapter->dt_node = dev->of_node;
+}
+
 /*
  * This function adds the card.
  *
@@ -1581,6 +1591,8 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool 
prepare)
}
 
adapter->dev = dev;
+   mwifiex_probe_of(adapter);
+
adapter->iface_type = iface_type;
adapter->card_sem = sem;
 
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index b697b61..bcd6408 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2235,10 +2235,7 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, 
u8 first_sta, bool init)
 * The cal-data can be read from device tree and/or
 * a configuration file and downloaded to firmware.
 */
-   if ((priv->adapter->iface_type == MWIFIEX_SDIO ||
-   priv->adapter->iface_type == MWIFIEX_PCIE) &&
-   adapter->dev->of_node) {
-   adapter->dt_node = adapter->dev->of_node;
+   if (adapter->dt_node) {
if (of_property_read_u32(adapter->dt_node,
 "marvell,wakeup-pin",
 ) == 0) {
-- 
1.9.1

R: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Arlone Marco]

No problem for me, also.

Marco Arlone

-Messaggio originale-
Da: Nicola Smaldone [mailto:nsmald...@tierratelematics.com] 
Inviato: martedì 15 novembre 2016 14:18
A: Gianfranco Costamagna; Kalle Valo
Cc: Arend Van Spriel; brcm80211-dev-l...@broadcom.com; 
linux-wireless@vger.kernel.org; Arlone Marco
Oggetto: RE: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad 
regulatory domain frequency value

No problem for me, thanks.

Nicola SMALDONE
www.tierratelematics.com

-Original Message-
From: Gianfranco Costamagna [mailto:locutusofb...@debian.org]
Sent: martedì 15 novembre 2016 14:14
To: Kalle Valo 
Cc: Arend Van Spriel ; 
brcm80211-dev-l...@broadcom.com; linux-wireless@vger.kernel.org; Nicola 
Smaldone ; marco.arl...@roj.com
Subject: Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad 
regulatory domain frequency value

Hi,


> Signed-off-by: Nicola Smaldone 

> Signed-off-by: Arlone Marco 

>Please note that you cannot add Signed-off-by for other people without 
>their explicit approval (see Documentation/SubmittingPatches). I don't 
>know if they did it in this case or not, but wanted to point out this 
>anyway.


The first signoff is myself, with the company email, the other two signoffs are 
from: the author, and Nicola, who did work with me to test it (even if a typo 
fix is not "testable").

Nicola, Marco, is it ok to add your two names in the signoff part?
(that was a verbal talk, I don't have anything written)

Gianfranco

Confidentiality Notice: This message (including attachments) is a private 
communication solely for use of the intended recipient(s). If you are not the 
intended recipient(s) or believe you received this message in error, notify the 
sender immediately and then delete this message. Any other use, retention, 
dissemination or copying is prohibited and may be a violation of law, including 
the Electronic Communication Privacy Act of 1986.

Follow us on YouTube: https://www.youtube.com/channel/UC9nTKjeq8UdxExKnCNXDPmA

Prima di stampare, pensa all'ambiente ** Think about the environment before 
printing


ROJ S.r.l. - Biella - Italy  (www.roj.com) 
Tel: +39.015.8480111   Fax: +39.015.405815/8480209

This e-mail and any files transmitted with it is confidential and intended only 
for the stated addressee(s). Any unauthorised disclosure, use or dissemination, 
either whole or partial, by person or entities other than the addressee(s) is 
prohibited. Please notify the sender immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. 
Please note that any views or opinions presented in this e-mail are solely 
those of the author and are not necessarily endorsed by the company. Although 
the company has taken reasonable precautions to ensure no viruses are present 
in this e-mail, the company cannot accept responsibility for any loss or damage 
arising from the use of this e-mail or attachments. 

RE: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Nicola Smaldone]

No problem for me, thanks.

Nicola SMALDONE
www.tierratelematics.com

-Original Message-
From: Gianfranco Costamagna [mailto:locutusofb...@debian.org] 
Sent: martedì 15 novembre 2016 14:14
To: Kalle Valo 
Cc: Arend Van Spriel ; 
brcm80211-dev-l...@broadcom.com; linux-wireless@vger.kernel.org; Nicola 
Smaldone ; marco.arl...@roj.com
Subject: Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad 
regulatory domain frequency value

Hi,


> Signed-off-by: Nicola Smaldone 

> Signed-off-by: Arlone Marco 

>Please note that you cannot add Signed-off-by for other people without 
>their explicit approval (see Documentation/SubmittingPatches). I don't 
>know if they did it in this case or not, but wanted to point out this 
>anyway.


The first signoff is myself, with the company email, the other two signoffs are 
from: the author, and Nicola, who did work with me to test it (even if a typo 
fix is not "testable").

Nicola, Marco, is it ok to add your two names in the signoff part?
(that was a verbal talk, I don't have anything written)

Gianfranco

Confidentiality Notice: This message (including attachments) is a private 
communication solely
for use of the intended recipient(s). If you are not the intended recipient(s) 
or believe you
received this message in error, notify the sender immediately and then delete 
this message. Any
other use, retention, dissemination or copying is prohibited and may be a 
violation of law,
including the Electronic Communication Privacy Act of 1986.

Re: [PATCH RESEND v2] cfg80211: add bitrate for 20MHz MCS 9

[Johannes Berg]

On Mon, 2016-10-31 at 11:28 -0700, Thomas Pedersen wrote:
> Some drivers (ath10k) report MCS 9 @ 20MHz, which
> technically isn't defined. To get more meaningful value
> than 0 out of this however, just extrapolate a bitrate
> from ratio of MCS 7 and 9 in channels where it is allowed.
> 
applied.

johannes

Re: [PATCH] Revert "mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE"

[Johannes Berg]

On Thu, 2016-11-03 at 12:12 +0100, Felix Fietkau wrote:
> This reverts commit c68df2e7be0c1238ea3c281fd744a204ef3b15a0.
> 
> __sta_info_recalc_tim turns into a no-op if local->ops->set_tim is
> not
> set. This prevents the beacon TIM bit from being set for all drivers
> that do not implement this op (almost all of them), thus thoroughly
> essential AP mode powersave functionality.
> 
Applied.

johannes

Re: [PATCH V2] mac80211: Ignore VHT IE from peer with wrong rx_mcs_map

[Johannes Berg]

On Wed, 2016-11-02 at 10:04 +0100, Filip Matusiak wrote:
> This is a workaround for VHT-enabled STAs which break the spec
> and have the VHT-MCS Rx map filled in with value 3 for all eight
> spacial streams, an example is AR9462 in AP mode.
> 
> As per spec, in section 22.1.1 Introduction to the VHT PHY
> A VHT STA shall support at least single spactial stream VHT-MCSs
> 0 to 7 (transmit and receive) in all supported channel widths.
> 
> Some devices in STA mode will get firmware assert when trying to
> associate, examples are QCA9377 & QCA6174.
> 
> Packet example of broken VHT Cap IE of AR9462:
> 
> [...]

Applied, thanks.

johannes

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Gianfranco Costamagna]

Hi,


> Signed-off-by: Nicola Smaldone 

> Signed-off-by: Arlone Marco 

>Please note that you cannot add Signed-off-by for other people without
>their explicit approval (see Documentation/SubmittingPatches). I don't
>know if they did it in this case or not, but wanted to point out this
>anyway.


The first signoff is myself, with the company email, the other two signoffs
are from: the author, and Nicola, who did work with me to test it
(even if a typo fix is not "testable").

Nicola, Marco, is it ok to add your two names in the signoff part?
(that was a verbal talk, I don't have anything written)

Gianfranco

[PATCH v7] mwifiex: parse device tree node for PCIe

[Amitkumar Karwar]

From: Xinming Hu 

This patch derives device tree node from pcie bus layer framework.
Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
marvell-8xxx.txt) to accommodate PCIe changes.

Signed-off-by: Xinming Hu 
Signed-off-by: Rajat Jain 
Reviewed-by: Brian Norris 
Signed-off-by: Amitkumar Karwar 
---
v2: Included vendor and product IDs in compatible strings for PCIe
chipsets(Rob Herring)
v3: Patch is created using -M option so that it will only include diff of
original and renamed files(Rob Herring)
Resend v3: Resending the patch because I missed to include device tree mailing
while sending v3.
v4: Fix error handling, also move-on even if no device tree node is present.
v5: Update commit log to include memory leak, return -EINVAL instead of -1.
v6: Remove an unnecessary error print, fix typo in commit log
v7: a) Earlier versions of this patch claims to have a change which fixes 
"memory
   leak". But it actually introduces double-free problem. That change is 
removed
   here(Brian Norris)
b) Cosmetic change in bindings documentation(Rob Herring)
s/marvell/Marvell/
s/sdio\/pcie/SDIO\/PCIE/
---
 .../{marvell-sd8xxx.txt => marvell-8xxx.txt}   |  8 +---
 drivers/net/wireless/marvell/mwifiex/pcie.c| 24 ++
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c |  3 ++-
 3 files changed, 31 insertions(+), 4 deletions(-)
 rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => 
marvell-8xxx.txt} (91%)

diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt 
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
similarity index 91%
rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index c421aba..980b16df 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,8 +1,8 @@
-Marvell 8897/8997 (sd8897/sd8997) SDIO devices
+Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
 --
 
-This node provides properties for controlling the marvell sdio wireless device.
-The node is expected to be specified as a child node to the SDIO controller 
that
+This node provides properties for controlling the Marvell SDIO/PCIE wireless 
device.
+The node is expected to be specified as a child node to the SDIO/PCIE 
controller that
 connects the device to the system.
 
 Required properties:
@@ -10,6 +10,8 @@ Required properties:
   - compatible : should be one of the following:
* "marvell,sd8897"
* "marvell,sd8997"
+   * "pci11ab,2b42"
+   * "pci1b4b,2b42"
 
 Optional properties:
 
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 063c707..83a41b5 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -37,6 +37,22 @@
 
 static struct semaphore add_remove_card_sem;
 
+static const struct of_device_id mwifiex_pcie_of_match_table[] = {
+   { .compatible = "pci11ab,2b42" },
+   { .compatible = "pci1b4b,2b42" },
+   { }
+};
+
+static int mwifiex_pcie_probe_of(struct device *dev)
+{
+   if (!of_match_node(mwifiex_pcie_of_match_table, dev->of_node)) {
+   dev_err(dev, "required compatible string missing\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int
 mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
   size_t size, int flags)
@@ -185,6 +201,7 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
 {
struct pcie_service_card *card;
+   int ret;
 
pr_debug("info: vendor=0x%4.04X device=0x%4.04X rev=%d\n",
 pdev->vendor, pdev->device, pdev->revision);
@@ -206,6 +223,13 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
card->pcie.can_ext_scan = data->can_ext_scan;
}
 
+   /* device tree node parsing and platform specific configuration*/
+   if (pdev->dev.of_node) {
+   ret = mwifiex_pcie_probe_of(>dev);
+   if (ret)
+   return ret;
+   }
+
if (mwifiex_add_card(card, _remove_card_sem, _ops,
 MWIFIEX_PCIE)) {
pr_err("%s failed\n", __func__);
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 0a54e21..b697b61 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2235,7 +2235,8 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 
first_sta, bool init)
 * The cal-data can be 

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

[Kalle Valo]

Gianfranco Costamagna  writes:

>> Well, not before you pointed it out ;-). You are welcome to send a patch
>> fixing it. Otherwise, I will take care of it.
>
> attaching a format-patch like version.
> I don't think we need a Tested-by or whatever, because it is just a typo in a 
> comment.
> (this is my first contribution, feel free to rebase or change whatever you 
> prefer
> to make it in line with other styles)
>
> (I gave authorship to Marco, the first one who discovered such typo)

[...]

> Signed-off-by: Gianfranco Costamagna 
> Signed-off-by: Nicola Smaldone 
> Signed-off-by: Arlone Marco 

Please note that you cannot add Signed-off-by for other people without
their explicit approval (see Documentation/SubmittingPatches). I don't
know if they did it in this case or not, but wanted to point out this
anyway.

-- 
Kalle Valo

[PATCH] cfg80211: limit scan results cache size

[Johannes Berg]

From: Johannes Berg 

It's possible to make scanning consume almost arbitrary amounts
of memory, e.g. by sending beacon frames with random BSSIDs at
high rates while somebody is scanning.

Limit the number of BSS table entries we're willing to cache to
1000, limiting maximum memory usage to maybe 4-5MB, but lower
in practice - that would be the case for having both full-sized
beacon and probe response frames for each entry; this seems not
possible in practice, so a limit of 1000 entries will likely be
closer to 0.5 MB.

Cc: sta...@vger.kernel.org
Signed-off-by: Johannes Berg 
---
 net/wireless/core.h |  1 +
 net/wireless/scan.c | 69 +
 2 files changed, 70 insertions(+)

diff --git a/net/wireless/core.h b/net/wireless/core.h
index 08d2e948c9ad..f0c0c8a48c92 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -71,6 +71,7 @@ struct cfg80211_registered_device {
struct list_head bss_list;
struct rb_root bss_tree;
u32 bss_generation;
+   u32 bss_entries;
struct cfg80211_scan_request *scan_req; /* protected by RTNL */
struct sk_buff *scan_msg;
struct cfg80211_sched_scan_request __rcu *sched_scan_req;
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index b5bd58d0f731..35ad69fd0838 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -57,6 +57,19 @@
  * also linked into the probe response struct.
  */
 
+/*
+ * Limit the number of BSS entries stored in mac80211. Each one is
+ * a bit over 4k at most, so this limits to roughly 4-5M of memory.
+ * If somebody wants to really attack this though, they'd likely
+ * use small beacons, and only one type of frame, limiting each of
+ * the entries to a much smaller size (in order to generate more
+ * entries in total, so overhead is bigger.)
+ */
+static int bss_entries_limit = 1000;
+module_param(bss_entries_limit, int, 0644);
+MODULE_PARM_DESC(bss_entries_limit,
+ "limit to number of scan BSS entries (per wiphy, default 
1000)");
+
 #define IEEE80211_SCAN_RESULT_EXPIRE   (30 * HZ)
 
 static void bss_free(struct cfg80211_internal_bss *bss)
@@ -137,6 +150,10 @@ static bool __cfg80211_unlink_bss(struct 
cfg80211_registered_device *rdev,
 
list_del_init(>list);
rb_erase(>rbn, >bss_tree);
+   rdev->bss_entries--;
+   WARN_ONCE((rdev->bss_entries == 0) ^ list_empty(>bss_list),
+ "rdev bss entries[%d]/list[empty:%d] corruption\n",
+ rdev->bss_entries, list_empty(>bss_list));
bss_ref_put(rdev, bss);
return true;
 }
@@ -163,6 +180,40 @@ static void __cfg80211_bss_expire(struct 
cfg80211_registered_device *rdev,
rdev->bss_generation++;
 }
 
+static bool cfg80211_bss_expire_oldest(struct cfg80211_registered_device *rdev)
+{
+   struct cfg80211_internal_bss *bss, *oldest = NULL;
+   bool ret;
+
+   lockdep_assert_held(>bss_lock);
+
+   list_for_each_entry(bss, >bss_list, list) {
+   if (atomic_read(>hold))
+   continue;
+
+   if (!list_empty(>hidden_list) &&
+   !bss->pub.hidden_beacon_bss)
+   continue;
+
+   if (oldest && time_before(oldest->ts, bss->ts))
+   continue;
+   oldest = bss;
+   }
+
+   if (WARN_ON(!oldest))
+   return false;
+
+   /*
+* The callers make sure to increase rdev->bss_generation if anything
+* gets removed (and a new entry added), so there's no need to also do
+* it here.
+*/
+
+   ret = __cfg80211_unlink_bss(rdev, oldest);
+   WARN_ON(!ret);
+   return ret;
+}
+
 void ___cfg80211_scan_done(struct cfg80211_registered_device *rdev,
   bool send_message)
 {
@@ -689,6 +740,7 @@ static bool cfg80211_combine_bsses(struct 
cfg80211_registered_device *rdev,
const u8 *ie;
int i, ssidlen;
u8 fold = 0;
+   u32 n_entries = 0;
 
ies = rcu_access_pointer(new->pub.beacon_ies);
if (WARN_ON(!ies))
@@ -712,6 +764,12 @@ static bool cfg80211_combine_bsses(struct 
cfg80211_registered_device *rdev,
/* This is the bad part ... */
 
list_for_each_entry(bss, >bss_list, list) {
+   /*
+* we're iterating all the entries anyway, so take the
+* opportunity to validate the list length accounting
+*/
+   n_entries++;
+
if (!ether_addr_equal(bss->pub.bssid, new->pub.bssid))
continue;
if (bss->pub.channel != new->pub.channel)
@@ -740,6 +798,10 @@ static bool cfg80211_combine_bsses(struct 
cfg80211_registered_device *rdev,
   new->pub.beacon_ies);
}
 
+   WARN_ONCE(n_entries != rdev->bss_entries,
+ "rdev bss entries[%d]/list[len:%d] 

Re: [RFC 10/12] ath10k: Added QCA65XX hw definition

[Valo, Kalle]

Michal Kazior  writes:

> On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
>> Signed-off-by: Erik Stromdahl 
>> ---
>>  drivers/net/wireless/ath/ath10k/hw.h |1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
>> b/drivers/net/wireless/ath/ath10k/hw.h
>> index 46142e9..ef45ecf 100644
>> --- a/drivers/net/wireless/ath/ath10k/hw.h
>> +++ b/drivers/net/wireless/ath/ath10k/hw.h
>> @@ -224,6 +224,7 @@ enum ath10k_hw_rev {
>> ATH10K_HW_QCA9377,
>> ATH10K_HW_QCA4019,
>> ATH10K_HW_QCA9887,
>> +   ATH10K_HW_QCA65XX,
>
> Are you 100% positive that you're supporting all QCA65XX chips? The
> rule of thumb is to avoid Xs as much as possible unless totally
> perfectly completely sure.

But the thing is that nobody can't be absolutely sure as we never know
what marketing comes up within few years again. So I would say that XX
in chip names should be completely avoided to avoid any confusion. We
already suffer from this in ath10k with QCA988X and QCA9888 which are
different designs but the names overlap.

I haven't reviewed Erik's patches yet but I'm surprised why even a new
enum value is needed here. I was assuming we could use ATH10K_HW_QCA6174
because AFAIK they share the same design. Any particular reason for
this?

-- 
Kalle Valo

Re: [RFC 09/12] ath10k: Mailbox address definitions

[Valo, Kalle]

Michal Kazior  writes:

> On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
>> Address definitions for SDIO/mbox based chipsets.
>>
>> Signed-off-by: Erik Stromdahl 
>> ---
>>  drivers/net/wireless/ath/ath10k/hw.h |   53 
>> ++
>>  1 file changed, 53 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
>> b/drivers/net/wireless/ath/ath10k/hw.h
>> index 883547f..46142e9 100644
>> --- a/drivers/net/wireless/ath/ath10k/hw.h
>> +++ b/drivers/net/wireless/ath/ath10k/hw.h
>> @@ -814,6 +814,59 @@ struct ath10k_hw_ops {
>>  #define QCA9887_EEPROM_ADDR_LO_MASK0x00ff
>>  #define QCA9887_EEPROM_ADDR_LO_LSB 16
>>
>> +#define MBOX_RESET_CONTROL_ADDRESS 0x
>> +#define MBOX_HOST_INT_STATUS_ADDRESS   0x0800
>> +#define MBOX_HOST_INT_STATUS_ERROR_LSB 7
>> +#define MBOX_HOST_INT_STATUS_ERROR_MASK0x0080
>
> I would again suggest using Jakub's bitfield GET_FIELD stuff to get
> rid of MASK+LSB and just have single define per register field. Kalle,
> thoughts?

Same comment as with the other patch, very much preferred but not a hard
requirement.

-- 
Kalle Valo

Re: [RFC 05/12] ath10k: htc: Added ATH10K_HTC_FLAG_BUNDLE_LSB

[Valo, Kalle]

Michal Kazior  writes:

> On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
>> Signed-off-by: Erik Stromdahl 
>> ---
>>  drivers/net/wireless/ath/ath10k/htc.h |2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/htc.h 
>> b/drivers/net/wireless/ath/ath10k/htc.h
>> index 589800a..df16a04 100644
>> --- a/drivers/net/wireless/ath/ath10k/htc.h
>> +++ b/drivers/net/wireless/ath/ath10k/htc.h
>> @@ -62,6 +62,8 @@ enum ath10k_htc_rx_flags {
>> ATH10K_HTC_FLAG_BUNDLE_MASK = 0xF0
>>  };
>>
>> +#define ATH10K_HTC_FLAG_BUNDLE_LSB 4
>
> Just an idea - we could start using FIELD_GET() with
> ATH10K_HTC_FLAG_BUNDLE_MASK alone. I would love to see Jakub's
> bitfield stuff be used more. Kalle, thoughts?

Yeah, the bitfield macros are handy and we should definitely switch to
them (slowly). But definitely not a must for these SDIO patches, more
like a nice bonus.

-- 
Kalle Valo

Re: [RFC 10/12] ath10k: Added QCA65XX hw definition

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> Signed-off-by: Erik Stromdahl 
> ---
>  drivers/net/wireless/ath/ath10k/hw.h |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
> b/drivers/net/wireless/ath/ath10k/hw.h
> index 46142e9..ef45ecf 100644
> --- a/drivers/net/wireless/ath/ath10k/hw.h
> +++ b/drivers/net/wireless/ath/ath10k/hw.h
> @@ -224,6 +224,7 @@ enum ath10k_hw_rev {
> ATH10K_HW_QCA9377,
> ATH10K_HW_QCA4019,
> ATH10K_HW_QCA9887,
> +   ATH10K_HW_QCA65XX,

Are you 100% positive that you're supporting all QCA65XX chips? The
rule of thumb is to avoid Xs as much as possible unless totally
perfectly completely sure.


Michał

Re: [RFC 09/12] ath10k: Mailbox address definitions

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> Address definitions for SDIO/mbox based chipsets.
>
> Signed-off-by: Erik Stromdahl 
> ---
>  drivers/net/wireless/ath/ath10k/hw.h |   53 
> ++
>  1 file changed, 53 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
> b/drivers/net/wireless/ath/ath10k/hw.h
> index 883547f..46142e9 100644
> --- a/drivers/net/wireless/ath/ath10k/hw.h
> +++ b/drivers/net/wireless/ath/ath10k/hw.h
> @@ -814,6 +814,59 @@ struct ath10k_hw_ops {
>  #define QCA9887_EEPROM_ADDR_LO_MASK0x00ff
>  #define QCA9887_EEPROM_ADDR_LO_LSB 16
>
> +#define MBOX_RESET_CONTROL_ADDRESS 0x
> +#define MBOX_HOST_INT_STATUS_ADDRESS   0x0800
> +#define MBOX_HOST_INT_STATUS_ERROR_LSB 7
> +#define MBOX_HOST_INT_STATUS_ERROR_MASK0x0080

I would again suggest using Jakub's bitfield GET_FIELD stuff to get
rid of MASK+LSB and just have single define per register field. Kalle,
thoughts?


Michał

Re: [RFC 06/12] ath10k: bmi: Added SOC reg read/write functions

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> Added functions implementing the following BMI commands:
>
> BMI_READ_SOC_REGISTER
> BMI_WRITE_SOC_REGISTER
>
> Reading and writing BMI registers is sometimes needed for
> SDIO chipsets.

I didn't see ath10k_bmi_write_soc_reg nor ath10k_bmi_read_soc_reg
being used in your Patch 12. Is this patch really necessary?


[...]
> diff --git a/drivers/net/wireless/ath/ath10k/bmi.c 
> b/drivers/net/wireless/ath/ath10k/bmi.c
> index 2872d34..1c378a2 100644
> --- a/drivers/net/wireless/ath/ath10k/bmi.c
> +++ b/drivers/net/wireless/ath/ath10k/bmi.c
> @@ -97,7 +97,8 @@ int ath10k_bmi_read_memory(struct ath10k *ar,
> u32 rxlen;
> int ret;
>
> -   ath10k_dbg(ar, ATH10K_DBG_BMI, "bmi read address 0x%x length %d\n",
> +   ath10k_dbg(ar, ATH10K_DBG_BMI,
> +  "bmi read memory address 0x%x length %d\n",
>address, length);
>
> if (ar->bmi.done_sent) {
> @@ -137,7 +138,8 @@ int ath10k_bmi_write_memory(struct ath10k *ar,
> u32 txlen;
> int ret;
>
> -   ath10k_dbg(ar, ATH10K_DBG_BMI, "bmi write address 0x%x length %d\n",
> +   ath10k_dbg(ar, ATH10K_DBG_BMI,
> +  "bmi write memory address 0x%x length %d\n",
>address, length);
>

These 2 hunks shouldn't be modified in this patch. If you want to do a
clean up this warrants a separate patch :)


Michał

Re: [RFC 05/12] ath10k: htc: Added ATH10K_HTC_FLAG_BUNDLE_LSB

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> Signed-off-by: Erik Stromdahl 
> ---
>  drivers/net/wireless/ath/ath10k/htc.h |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/htc.h 
> b/drivers/net/wireless/ath/ath10k/htc.h
> index 589800a..df16a04 100644
> --- a/drivers/net/wireless/ath/ath10k/htc.h
> +++ b/drivers/net/wireless/ath/ath10k/htc.h
> @@ -62,6 +62,8 @@ enum ath10k_htc_rx_flags {
> ATH10K_HTC_FLAG_BUNDLE_MASK = 0xF0
>  };
>
> +#define ATH10K_HTC_FLAG_BUNDLE_LSB 4

Just an idea - we could start using FIELD_GET() with
ATH10K_HTC_FLAG_BUNDLE_MASK alone. I would love to see Jakub's
bitfield stuff be used more. Kalle, thoughts?


Michał

Re: [RFC 04/12] ath10k: htc: refactorization

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> Code refactorization:
>
> Moved the code for ep 0 in ath10k_htc_rx_completion_handler
> to ath10k_htc_control_rx_complete.
>
> This eases the implementation of SDIO/mbox significantly since
> the ep_rx_complete cb is invoked directly from the SDIO/mbox
> hif layer.
>
> Since the ath10k_htc_control_rx_complete already is present
> (only containing a warning message) there is no reason for not
> using it (instead of having a special case for ep 0 in
> ath10k_htc_rx_completion_handler).

This should be squashed with Patch 3 since it's inseparable part of
the same refactorization.


Michał

Re: [RFC 03/12] ath10k: htc: Changed order of wait target and ep connect

[Michal Kazior]

On 14 November 2016 at 17:33, Erik Stromdahl  wrote:
> This patch changes the order in which the driver waits for the
> target to become ready and the service connect of the HTC
> control service.
>
> The HTC control service is connected before the driver starts
> waiting for the HTC ready control message.
>
> The reason for this is that the HTC ready control message is
> transmitted on EP 0 and that sdio/mbox based systems will ignore
> messages received on unconnected endpoints.
>
> Signed-off-by: Erik Stromdahl 
> ---
>  drivers/net/wireless/ath/ath10k/htc.c |   32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/htc.c 
> b/drivers/net/wireless/ath/ath10k/htc.c
> index e3f7bf4..7257366 100644
> --- a/drivers/net/wireless/ath/ath10k/htc.c
> +++ b/drivers/net/wireless/ath/ath10k/htc.c
> @@ -606,6 +606,22 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
> u16 credit_count;
> u16 credit_size;
>
> +   /* setup our pseudo HTC control endpoint connection */
> +   memset(_req, 0, sizeof(conn_req));
> +   memset(_resp, 0, sizeof(conn_resp));
> +   conn_req.ep_ops.ep_tx_complete = ath10k_htc_control_tx_complete;
> +   conn_req.ep_ops.ep_rx_complete = ath10k_htc_control_rx_complete;
> +   conn_req.max_send_queue_depth = ATH10K_NUM_CONTROL_TX_BUFFERS;
> +   conn_req.service_id = ATH10K_HTC_SVC_ID_RSVD_CTRL;
> +
> +   /* connect fake service */
> +   status = ath10k_htc_connect_service(htc, _req, _resp);
> +   if (status) {
> +   ath10k_err(ar, "could not connect to htc service (%d)\n",
> +  status);
> +   return status;
> +   }
> +

How is this supposed to work? ath10k_htc_connect_service() requires
htc->target_credit_size to compute tx_credits_per_max_message. Or am I
missing something? Applying this patch alone results in:

[6.680101] divide error:  [#1] SMP
[6.681342] Modules linked in: ath10k_pci(O) ath10k_core(O) ath
mac80211 cfg80211
[6.684876] CPU: 3 PID: 823 Comm: kworker/u8:2 Tainted: GW
O4.9.0-rc4-wt-ath+ #79
[6.688051] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[6.691644] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
[6.694309] task: 88000a19 task.stack: c96d4000
[6.695458] RIP: 0010:[]  []
ath10k_htc_connect_service+0x21b/0x420 [ath10k_core]


Michał

[PATCH 4.9.0-rc5] AR9300 calibration problems with antenna selected

[Krzysztof Hałasa]

Hi,

I recently tried to select a single antenna on AR9300 and it works for
30 seconds only. The subsequent calibration makes the RX signal level to
drop from the usual -30/-40 dBm to -70/-80 dBm, and the transmission
practically stops.

With the attached patch it works, though selecting the antenna doesn't
seem to have any visible effect, at least with "iw wlanX station dump"
(perhaps it works for TX).

I'm using ad-hoc mode:

rmmod ath9k
modprobe ath9k
iw dev wlan0 set type ibss
iw phy phyX set antenna 2
ip link set up dev wlan0
iw dev wlan0 set bitrates legacy-2.4 18
iw dev wlan0 ibss join nameXXX freqYYY
ip addr add ZZZ broadcast + dev wlan0

The card in question is Mikrotik (Routerboard) R11e-2HPnD mPCIe adapter:
AR9580 Wireless Network Adapter (rev 01), ID 168c:0033, subsystem
19b6:d016.
ieee80211 phy0: Atheros AR9300 Rev:4 mem=0xc0f4, irq=334
https://routerboard.com/R11e-2HPnD

Linux 4.9.0-rc5.


Is there a better way?

Signed-off-by: Krzysztof Halasa 

diff --git a/drivers/net/wireless/ath/ath9k/main.c 
b/drivers/net/wireless/ath/ath9k/main.c
index e9f32b5..7f17e5d 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2245,7 +2245,7 @@ static int ath9k_set_antenna(struct ieee80211_hw *hw, u32 
tx_ant, u32 rx_ant)
return 0;
 
/* AR9100 runs into calibration issues if not all rx chains are enabled 
*/
-   if (AR_SREV_9100(ah))
+   if (AR_SREV_9100(ah) || AR_SREV_9300(ah))
ah->rxchainmask = 0x7;
else
ah->rxchainmask = fill_chainmask(ah->caps.rx_chainmask, rx_ant);


-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland