Re: [RFC 3/4] mac80211: Apply per-peer NoAck tid bitmap configuration

[vthiagar]

On 2018-03-27 18:24, Johannes Berg wrote:

On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:


+u16 ieee80211_get_noack_map(struct ieee80211_sub_if_data *sdata, 
const u8 *mac)

+{
+   struct sta_info *sta;
+   u16 noack_map = 0;
+
+   /* Retrieve per-station noack_map config for the receiver, if any */
+
+   rcu_read_lock();
+
+   sta = sta_info_get(sdata, mac);
+   if (!sta) {
+   rcu_read_unlock();
+   return noack_map;
+   }
+
+   noack_map = sta->noack_map;
+
+   rcu_read_unlock();
+
+   if (!noack_map)
+   noack_map = sdata->noack_map;


So this has an interesting corner case - should it be possible to have 
a
default noack_map that's non-zero, but override it with 0 for a 
specific

peer? It seems that it should be, which makes this code wrong.


I think 0 as the Noack configuration from user can also be a valid one 
in the case
where user does not want any NoAck policy to be used for a particular 
station even
when a non-zero NoAck configuration is set for ndev level. In this case, 
the logic
may need to be modified so that the default non-zero configuration 
(something like -1)
could be used to determine that the station has been never configured 
with any NoAck

policy and use ndev level configuration. Does this sound reasonable?

Vasanth

Re: [RFC 1/4] mac80211: Add NoAck policy functionality offload infrastructure

[vthiagar]

On 2018-03-27 18:23, Johannes Berg wrote:

On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:


+ * @IEEE80211_HW_SUPPORTS_NOACK_POLICY: Hardware (or driver) manages 
noack

+ * policy handling. Hardware (or driver) takes care of setting
+ * noack policy in the qos header and does not wait for the ack based
+ *	on the noack TID map. Driver advertising this support must 
implement
+ *	callback @set_noack_tid_bitmap to receive the user configured 
noack TID

+ * bitmap.


Do you really need the ops method and the flag?


Ath10k would send NoAck policy configuration on control path 
configuration.
It seems a new ops might be appropriate. Perhaps the ops alone is 
sufficient

to know the capability?




+   int (*set_noack_tid_bitmap)(struct ieee80211_hw *hw,
+   struct ieee80211_vif *vif, u8 noack_map);


You'd safe some effort by reordering the nl80211 patch first, so you 
can

immediately introduce it with per-peer capability here.


Sure.




+++ b/net/mac80211/cfg.c
@@ -347,9 +347,15 @@ static int ieee80211_set_noack_map(struct wiphy 
*wiphy,


sdata->noack_map = noack_map;

-   ieee80211_check_fast_xmit_iface(sdata);
+   if (!ieee80211_hw_check(>local->hw, SUPPORTS_NOACK_POLICY)) {
+   ieee80211_check_fast_xmit_iface(sdata);
+   return 0;
+   }

-   return 0;
+   if (!ieee80211_sdata_running(sdata))
+   return 0;
+
+   return drv_set_noack_tid_bitmap(sdata->local, sdata, noack_map);


This doesn't seem right - you should do the fast xmit checks even if
calling the driver, no? And in fact, fast xmit should be permitted when
the noack is offloaded, so you shouldn't set sdata->noack_map in the
offloaded case at all.


--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -631,6 +631,10 @@ int ieee80211_do_open(struct wireless_dev *wdev, 
bool coming_up)

ieee80211_vif_type_p2p(>vif));
if (res)
goto err_del_interface;
+
+   if (sdata->noack_map)
+   drv_set_noack_tid_bitmap(local, sdata,
+sdata->noack_map);


Or maybe you do need to store it for this reason, but need to ignore it
for the purposes of fast-xmit if SUPPORTS_NOACK_POLICY is set.


+++ b/net/mac80211/tx.c
@@ -2817,7 +2817,8 @@ void ieee80211_check_fast_xmit(struct sta_info 
*sta)

test_sta_flag(sta, WLAN_STA_CLEAR_PS_FILT))
goto out;

-   if (sdata->noack_map)
+   if (sdata->noack_map &&
+   !ieee80211_hw_check(>hw, SUPPORTS_NOACK_POLICY))
goto out;


Ah, and you do :-)

And then maybe you're indeed right and don't need to call the fast xmit
check in that place since it wouldn't have any effect either way.


Right.

Vasanth

Re: [RFC 2/4] nl80211/mac80211: Extend NoAck policy command with peer MAC address

[vthiagar]

On 2018-03-27 18:17, Johannes Berg wrote:

On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:


- * @set_noack_map: Set the NoAck Map for the TIDs.
+ * @set_noack_map: Set the NoAck Map for the TIDs. When peer is not 
%NULL NoAck
+ *	map will be applied for that particular peer. When peer is %NULL 
NoAck
+ *	map will be applied for all the connected stations (except the 
ones

+ * which already have per-peer TID map configured) on the netdev.
+ * Driver should return -ENOSPC when the it does not have room for
+ * additional entries for per-peer NoAck map.


I guess it should also set the default for new stations when the peer 
is

not given? At least that's how mac80211 would behave now, afaict.


Sure. May be setting -1 as the default value when the per-peer NoAck 
policy is not

set would work.



The question is how that interacts with having enough space - are you
sure this is a concern?


This will not be an issue at lest for ath10k. This is mainly for a 
(new)driver
which implements the offload but has limitation in supporting more than 
certain
number of peers. Perhaps we can remove it now and add it when such 
driver is

available?



  * @NL80211_CMD_SET_NOACK_MAP: sets a bitmap for the individual TIDs 
whether

- *  No Acknowledgement Policy should be applied.
+ *	No Acknowledgement Policy should be applied. %NL80211_ATTR_MAC is 
used
+ *	to apply No Acknowledgement policy for a particular connected 
station.
+ *	Station specific NoAck policy configuration is valid only for 
STA's
+ *	current connection, i.e. the configuration will not be used when 
the

+ * station connects back after disconnection/roaming.
+ * When user-space does not include %NL80211_ATTR_MAC, the No
+ * Acknowledgement Policy setting should be treated as per-netdev
+ * configuration.


Here you describe different semantics - i.e. you didn't describe the
"previous per-station settings are kept" part. I'm not sure that part
makes much sense anyhow?


Not sure I got this comment right. As mentioned in the doc, the previous 
settings
would be reset upon reconnection of the station and any ndev wide 
configuration
will be used. As mentioned above, additionally default value will be set 
to the

station to mark no per-station configuration is given so far.

Vasanth

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

[Enrico Mioso]

Thank you all guys for your work on this issue, and patience.

I think implementing a watchdog is a good idea: and BTW I don't think the 
problem verifies so infrequently on a WL-330n3G
device, openwrt .config attached.
And, while on my MR200 MT7620A-based wi-fi card, the device is able to continue 
working again, on older devices like WL-330n3G,
this error seems fatal, even disassoc/reassoc can not help.

The last configuration I remember working fine was built around American 
Elections (more or less 7 nov 2012).

Thank you very much to all.

On a totally different side: any chance of MT7610 / MT7630 hardware support ?

Thanks.

Actual config:
#
# Automatically generated file; DO NOT EDIT.
# OpenWrt Configuration
#
CONFIG_MODULES=y
CONFIG_HAVE_DOT_CONFIG=y
# CONFIG_TARGET_sunxi is not set
# CONFIG_TARGET_apm821xx is not set
# CONFIG_TARGET_ath25 is not set
# CONFIG_TARGET_ar71xx is not set
# CONFIG_TARGET_brcm2708 is not set
# CONFIG_TARGET_bcm53xx is not set
# CONFIG_TARGET_brcm47xx is not set
# CONFIG_TARGET_brcm63xx is not set
# CONFIG_TARGET_cns3xxx is not set
# CONFIG_TARGET_octeon is not set
# CONFIG_TARGET_gemini is not set
# CONFIG_TARGET_mpc85xx is not set
# CONFIG_TARGET_imx6 is not set
# CONFIG_TARGET_mxs is not set
# CONFIG_TARGET_adm8668 is not set
# CONFIG_TARGET_adm5120 is not set
# CONFIG_TARGET_xburst is not set
# CONFIG_TARGET_ixp4xx is not set
# CONFIG_TARGET_lantiq is not set
# CONFIG_TARGET_malta is not set
# CONFIG_TARGET_pistachio is not set
# CONFIG_TARGET_mvebu is not set
# CONFIG_TARGET_kirkwood is not set
# CONFIG_TARGET_mediatek is not set
CONFIG_TARGET_ramips=y
# CONFIG_TARGET_at91 is not set
# CONFIG_TARGET_rb532 is not set
# CONFIG_TARGET_mcs814x is not set
# CONFIG_TARGET_layerscape is not set
# CONFIG_TARGET_oxnas is not set
# CONFIG_TARGET_armvirt is not set
# CONFIG_TARGET_ipq806x is not set
# CONFIG_TARGET_au1000 is not set
# CONFIG_TARGET_arc770 is not set
# CONFIG_TARGET_archs38 is not set
# CONFIG_TARGET_ar7 is not set
# CONFIG_TARGET_omap is not set
# CONFIG_TARGET_uml is not set
# CONFIG_TARGET_zynq is not set
# CONFIG_TARGET_x86 is not set
# CONFIG_TARGET_ramips_mt7620 is not set
# CONFIG_TARGET_ramips_mt7621 is not set
# CONFIG_TARGET_ramips_mt76x8 is not set
# CONFIG_TARGET_ramips_rt288x is not set
CONFIG_TARGET_ramips_rt305x=y
# CONFIG_TARGET_ramips_rt3883 is not set
# CONFIG_TARGET_MULTI_PROFILE is not set
# CONFIG_TARGET_ramips_rt305x_Default is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_px-4885-4M is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_px-4885-8M is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_carambola is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_a5-v11 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_w502u is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_freestation5 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_wr6202 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_mr-102n is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_air3gii is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_ALL02393G is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_all0256n-4M is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_all0256n-8M is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_all5002 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_all5003 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_asl26555-8M is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_asl26555-16M is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_atp-52b is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_awapn2403 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_awm002-evb-4M is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_awm002-evb-8M is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_rt-g32-b1 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_rt-n10-plus is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_rt-n13u is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_wl-330n is not set
CONFIG_TARGET_ramips_rt305x_DEVICE_wl-330n3g=y
# CONFIG_TARGET_ramips_rt305x_DEVICE_hw550-3g is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_f5d8235-v2 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_f7c027 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_WHRG300N is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_dap-1350 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_DCS930 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_DCS930LB1 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_dir-300-b1 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_dir-300-b7 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_dir-320-b1 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_dir-600-b1 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_dir-610-a1 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_dir-615-d is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_dir-615-h1 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_dir-620-a1 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_dir-620-d1 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_dwr-512-b is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_wizard8800 is not set
# CONFIG_TARGET_ramips_rt305x_DEVICE_3g-6200n is not set
# 

Re: Query on queues in mesh mode

[Phani Siriki]

Hi Thomas

I am able to see the correct values after I enable the wifi interface
and with the following changes.

Index: compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k/debug.c
===
--- compat-wireless-2015-03-09.orig/drivers/net/wireless/ath/ath9k/debug.c
+++ compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k/debug.c
@@ -624,8 +624,13 @@ static int read_file_xmit(struct seq_fil
 static void print_queue(struct ath_softc *sc, struct ath_txq *txq,
struct seq_file *file)
 {
+   seq_printf(file, "(%s): %d ", "cwmin",
sc->sc_ah->txq[txq->axq_qnum].tqi_cwmin);
+   seq_printf(file, "(%s): %d ", "cwmax",
sc->sc_ah->txq[txq->axq_qnum].tqi_cwmax);
+   seq_printf(file, "(%s): %d ", "aifs",
sc->sc_ah->txq[txq->axq_qnum].tqi_aifs);
+   seq_printf(file, "(%s): %d ", "burst",
sc->sc_ah->txq[txq->axq_qnum].tqi_burstTime);
ath_txq_lock(sc, txq);

+   seq_printf(file, "%s: %d ", "mac qnum", txq->mac80211_qnum);
seq_printf(file, "%s: %d ", "qnum", txq->axq_qnum);
seq_printf(file, "%s: %2d ", "qdepth", txq->axq_depth);
seq_printf(file, "%s: %2d ", "ampdu-depth", txq->axq_ampdu_depth);
@@ -639,6 +644,7 @@ static int read_file_queues(struct seq_f

Default values:
===

root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/queues
(VO):  (cwmin): 3 (cwmax): 7 (aifs): 2 (burst): 1504 mac qnum: 0 qnum:
3 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(VI):  (cwmin): 7 (cwmax): 15 (aifs): 2 (burst): 3008 mac qnum: 1
qnum: 2 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BE):  (cwmin): 15 (cwmax): 1023 (aifs): 3 (burst): 0 mac qnum: 2
qnum: 1 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BK):  (cwmin): 15 (cwmax): 1023 (aifs): 7 (burst): 0 mac qnum: 3
qnum: 0 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(CAB): (cwmin): -1 (cwmax): 1023 (aifs): 2 (burst): 0 mac qnum: -1
qnum: 8 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0

Modified Queue 0 values:
===

root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/queues
(VO):  (cwmin): 7 (cwmax): 63 (aifs): 7 (burst): 0 mac qnum: 0 qnum: 3
qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(VI):  (cwmin): 7 (cwmax): 15 (aifs): 2 (burst): 3008 mac qnum: 1
qnum: 2 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BE):  (cwmin): 15 (cwmax): 1023 (aifs): 3 (burst): 0 mac qnum: 2
qnum: 1 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BK):  (cwmin): 15 (cwmax): 1023 (aifs): 7 (burst): 0 mac qnum: 3
qnum: 0 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(CAB): (cwmin): -1 (cwmax): 1023 (aifs): 2 (burst): 0 mac qnum: -1
qnum: 8 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0


Best Regards
Phani



On Fri, Mar 23, 2018 at 10:39 PM, Phani Siriki  wrote:
> Hi Thomas
>
> I modified the code and tried to set the TXQ parameters for mesh
> interface. I didn't observe any error.
>
> However, I modified the ath9k driver code to verify default TXQ
> parameters. But I am observing same values for all the queues and the
> cwmin is looks different.
>
> To my understanding, the configured parameters using netlink library
> will get effect in driver queues..
>
> nl80211 - cfg80211 - mac80211 - ath9k
>
> Could you please let me know if I am doing something wrong.
>
>
> wifi@wifi-VirtualBox:~/chaos/get_txq_code/chaos_calmer-15.05.1/build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2015-03-09$
> quilt diff
> Index: compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k/debug.c
> ===
> --- compat-wireless-2015-03-09.orig/drivers/net/wireless/ath/ath9k/debug.c
> +++ compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k/debug.c
> @@ -639,6 +639,7 @@ static int read_file_queues(struct seq_f
>  {
> struct ieee80211_hw *hw = dev_get_drvdata(file->private);
> struct ath_softc *sc = hw->priv;
> +struct ath_hw *ah = sc->sc_ah;
> struct ath_txq *txq;
> int i;
> static const char *qname[4] = {
> @@ -648,6 +649,10 @@ static int read_file_queues(struct seq_f
> for (i = 0; i < IEEE80211_NUM_ACS; i++) {
> txq = sc->tx.txq_map[i];
> seq_printf(file, "(%s):  ", qname[i]);
> +   seq_printf(file, "(%s): %u ", "cwmin", ah->txq[i].tqi_cwmin);
> +   seq_printf(file, "(%s): %u ", "cwmax", ah->txq[i].tqi_cwmax);
> +   seq_printf(file, "(%s): %u ", "aifs", ah->txq[i].tqi_aifs);
> +   seq_printf(file, "(%s): %u ", "burst",
> ah->txq[i].tqi_burstTime);
> print_queue(sc, txq, file);
> }
>
> root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/queues
> (VO):  (cwmin): 4294967295 (cwmax): 1023 (aifs): 2 (burst): 0 qnum: 3
> qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
> (VI):  (cwmin): 4294967295 (cwmax): 1023 (aifs): 2 (burst): 

Re: [PATCH v7 00/11] EAPoL over NL80211

[Arend van Spriel]

On 3/27/2018 4:42 PM, Denis Kenzior wrote:

Hi Arend,

On 03/27/2018 03:03 AM, Arend van Spriel wrote:

On 3/26/2018 7:52 PM, Denis Kenzior wrote:

The proposed patchset has been tested in a mac80211_hwsim based
environment with
hostapd and iwd.


Hi Denis,

Looking pretty good. Do you also have hostapd and iwd patches
available somewhere. I would like to see if I can get brcmfmac using it.



There are some very raw iwd patches I have.  They're sitting in my
private tree.  I can send these to you privately or maybe setup a wiki
page somewhere for you to grab them.  They do not take the
NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211 feature bit into account,
so I still need to work on these.  Was holding off until Johannes merges
at least the high level API bits.


If they are not fit for posting feel free to send them to me.


I never modified hostapd.  iwd has a very rudimentary AP mode support.
Not fully useable but enough to run a 4-way handshake.  So with that in
mind I concentrated on two scenarios while testing:

1. modified iwd (STA) utiling EAPoL over NL80211 connecting to stock
hostapd.  In effect this was testing both the legacy and the new behavior.

2. modified iwd (STA) utilizing EAPoL over NL80211 connecting to stock
hostapd.  Then disconnecting and connecting to modified iwd (AP).

iwd doesn't (yet) have support for P2P, IBSS or Mesh.  So the bits
touching these features should be considered untested.


That's fine. Just wanted to get a feel about the feature. May provide 
some lessons to try it with a non-mac80211 driver and I wanted to have a 
spin with iwd as that is new to me.


Regards,
Arend

HI

[Lucy Boston]

-- 
Greeting, once again is me Lucy Boston this is twice am contacting you
please is very urgent respond to me for more details through my.
Email:

dr.lucybos...@gmail.com

GIFT FROM MRS ANAKI BENSON

[ANAKI BENSON]

GIFT FROM MRS ANAKI BENSON / I and my husband were from Kuwait, my
husband worked with Kuwait embassy here in Ivory Coast for nine years
before he died, he deposited the sum of US $2.5 million dollars in the
bank of africa, my Doctor told me that I would not last for the next
eight months due to cancer, I decided to donate this fund to a some
body that will use it in Gods work, help orphanages, widows, hospitals
and charity organization, this decision was because i don't have any
child that will inherit this money.

God bless you.
MRS ANAKI BENSON

[PATCH] ath10k: sdio: fix memory leak for probe allocations

[Marcus Folkesson]

These allocations are not freed upon release.
When on it; go for managed resources instead.

Signed-off-by: Marcus Folkesson 
---
 drivers/net/wireless/ath/ath10k/sdio.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/sdio.c 
b/drivers/net/wireless/ath/ath10k/sdio.c
index 07e183f8e57a..005934b8522c 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -1967,7 +1967,7 @@ static int ath10k_sdio_probe(struct sdio_func *func,
ar_sdio = ath10k_sdio_priv(ar);
 
ar_sdio->irq_data.irq_proc_reg =
-   kzalloc(sizeof(struct ath10k_sdio_irq_proc_regs),
+   devm_kzalloc(ar->dev, sizeof(struct ath10k_sdio_irq_proc_regs),
GFP_KERNEL);
if (!ar_sdio->irq_data.irq_proc_reg) {
ret = -ENOMEM;
@@ -1975,17 +1975,17 @@ static int ath10k_sdio_probe(struct sdio_func *func,
}
 
ar_sdio->irq_data.irq_en_reg =
-   kzalloc(sizeof(struct ath10k_sdio_irq_enable_regs),
+   devm_kzalloc(ar->dev, sizeof(struct 
ath10k_sdio_irq_enable_regs),
GFP_KERNEL);
if (!ar_sdio->irq_data.irq_en_reg) {
ret = -ENOMEM;
-   goto err_free_proc_reg;
+   goto err_core_destroy;
}
 
-   ar_sdio->bmi_buf = kzalloc(BMI_MAX_CMDBUF_SIZE, GFP_KERNEL);
+   ar_sdio->bmi_buf = devm_kzalloc(ar->dev, BMI_MAX_CMDBUF_SIZE, 
GFP_KERNEL);
if (!ar_sdio->bmi_buf) {
ret = -ENOMEM;
-   goto err_free_en_reg;
+   goto err_core_destroy;
}
 
ar_sdio->func = func;
@@ -2005,7 +2005,7 @@ static int ath10k_sdio_probe(struct sdio_func *func,
ar_sdio->workqueue = create_singlethread_workqueue("ath10k_sdio_wq");
if (!ar_sdio->workqueue) {
ret = -ENOMEM;
-   goto err_free_bmi_buf;
+   goto err_core_destroy;
}
 
for (i = 0; i < ATH10K_SDIO_BUS_REQUEST_MAX_NUM; i++)
@@ -2021,7 +2021,7 @@ static int ath10k_sdio_probe(struct sdio_func *func,
ret = -ENODEV;
ath10k_err(ar, "unsupported device id %u (0x%x)\n",
   dev_id_base, id->device);
-   goto err_free_bmi_buf;
+   goto err_core_destroy;
}
 
ar->id.vendor = id->vendor;
@@ -2050,12 +2050,6 @@ static int ath10k_sdio_probe(struct sdio_func *func,
 
 err_free_wq:
destroy_workqueue(ar_sdio->workqueue);
-err_free_bmi_buf:
-   kfree(ar_sdio->bmi_buf);
-err_free_en_reg:
-   kfree(ar_sdio->irq_data.irq_en_reg);
-err_free_proc_reg:
-   kfree(ar_sdio->irq_data.irq_proc_reg);
 err_core_destroy:
ath10k_core_destroy(ar);
 
-- 
2.16.2

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

[Daniel Golle]

Hi Stanislaw,

On Tue, Mar 27, 2018 at 07:18:16PM +0200, Stanislaw Gruszka wrote:
> On Tue, Mar 27, 2018 at 09:46:36AM +0200, Mathias Kresin wrote:
> > > Could you test just RX AMPDU patches, i.e.
> > > 
> > > rt2800_change_rx_ampdu_factor.patch
> > > rt2800_change_rx_ampdu_density.patch
> > > 
> > > I have somewhat positive results on RX performance on some devices
> > > with those. Perhaps you could confirm that :-)
> > 
> > This time I've done the test with HT20 only, to not annoy my neighbours.
> > 
> > The test setup is the following:
> > 
> > ath9k (STA) <=> (AP) o2 Box 6431 (RJ45) <=> desktop
> > 
> > With the patches applied the bandwidth is somewhat around 10 MBit/sec lower.
> > Even if I was able to reliable reproduce it, I'm not sure if it is within
> > the measuring tolerance.
> 
> Ok. I think when BBP/RF is correctly programmed patches will downgrade
> performance. For not well optimized devices patches might
> improve things , but this is not preferred solution. For 30+ client
> scenario I suggest to just disable HT (11n) in OpenWRT config.
> 
> Additionally since those errors do not happen frequently perhaps there
> is possibility to create watchdog and reset the device when problems
> start to happen.
> 
> FWIW: I'm running wt3020 (mt7620 device) as my home router for 3 weeks now
> and do not see any errors (I have 4 client devices). Performance measured
> by iperf is not good though - about 40 Mbit/s .

That's great news! Are you running OpenWrt or some self-baked
vanilla Linux with some of the OpenWrt patchery on top?
Also note that Tomislav Požega started porting more of the Rt6352
calibration routines, I'd be happy if you could review those as well
so they can go upstream right away:

https://github.com/openwrt/openwrt/pull/626

Just in case you are not aware of it, here is my staging tree with some
experimental changes for MT7620 including the fixes/work-arounds you
suggested as well as @psyborg55's patches:

https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=summary


Cheers


Daniel

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

[Stanislaw Gruszka]

On Tue, Mar 27, 2018 at 09:46:36AM +0200, Mathias Kresin wrote:
> > Could you test just RX AMPDU patches, i.e.
> > 
> > rt2800_change_rx_ampdu_factor.patch
> > rt2800_change_rx_ampdu_density.patch
> > 
> > I have somewhat positive results on RX performance on some devices
> > with those. Perhaps you could confirm that :-)
> 
> This time I've done the test with HT20 only, to not annoy my neighbours.
> 
> The test setup is the following:
> 
> ath9k (STA) <=> (AP) o2 Box 6431 (RJ45) <=> desktop
> 
> With the patches applied the bandwidth is somewhat around 10 MBit/sec lower.
> Even if I was able to reliable reproduce it, I'm not sure if it is within
> the measuring tolerance.

Ok. I think when BBP/RF is correctly programmed patches will downgrade
performance. For not well optimized devices patches might
improve things , but this is not preferred solution. For 30+ client
scenario I suggest to just disable HT (11n) in OpenWRT config.

Additionally since those errors do not happen frequently perhaps there
is possibility to create watchdog and reset the device when problems
start to happen.

FWIW: I'm running wt3020 (mt7620 device) as my home router for 3 weeks now
and do not see any errors (I have 4 client devices). Performance measured
by iperf is not good though - about 40 Mbit/s .

Regards
Stanislaw

Re: [PATCH 00/12] *** Add support for wifi QMI client driver ***

[govinds]

Hi Peter,

On 2018-03-27 01:51, Peter Oh wrote:

Add QMI client driver for Q6 integrated WLAN connectivity subsystem.

Can you give an example which chipset series is Q6 integrated WLAN ?

Thanks,
Peter


SDM845/MSM8998 series is using the same, where WLAN firmware is running 
on Q6 processor.



Thanks,
Govind

Compex WLE1216V2-20 (QCA9984) firmware is missing

[ojab //]

[please CC me since I'm not subscribed to the lists and terribly sorry
for HTML mails]

Oh hai!

I have Compex WLE1216V2-20 (based on QCA9984 chip) that isn't
supported by linux-firmware (git master), card init fails with

>[Mon Mar 26 17:18:47 2018] ath10k_pci :05:00.0: failed to fetch board data 
>for bus=pci,bmi-chip-id=0,bmi-board-id=30 from ath10k/QCA9984/hw1.0/board-2.bin

It works fine with board-2.bin from the compex website [1] (can be
downloaded directly from
https://bugzilla.kernel.org/attachment.cgi?id=274959).
What should be done to have it upstreamed?

[1] 
https://downloads.compex.com.sg/?dir=uploads/boardData/For_Building_New_Firmware

//wbr ojab

Re: [RFC 0/4] wireless: Per-sta NoAck and offload support

[Steve deRosier]

Hi Vasanthakumar,

On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
 wrote:
> Adds infrastructure for driver to offload NoAck functionality, driver
> like ath10k could make use of it. Also extends the current ndev wide

I'm not really much of a fan of adding a feature without some use of
the feature. Perhaps if drivers "like" ath10k could use it, maybe you
should add a patch(s) to the series where one of those drivers
actually uses the feature.  An API without an example of use is also
harder to evaluate effectively.

Additionally, if it's relevant, adding use of the feature to hwsim
would both serve the above comment as well as provide testing
capability.


> NoAck policy to per-station, with sta level NoAck policy configuration
> userspace could selectively turn off/on Noack based on various connection
> parameters of the station.
>

This is my own ignorance, perhaps from missing recent netdev
conferences - can you send a link to some documentation of what NoAck
is? Certain things in 802.11 use ack transmissions and
interoperability would be compromised if we didn't conform to spec. I
don't imagine that's what's going on here but I'd like to understand
what the heck NoAck is and I failed to bring up anything useful when I
Googled it.

- Steve

Re: [PATCH v7 00/11] EAPoL over NL80211

[Denis Kenzior]

Hi Arend,

On 03/27/2018 03:03 AM, Arend van Spriel wrote:

On 3/26/2018 7:52 PM, Denis Kenzior wrote:
The proposed patchset has been tested in a mac80211_hwsim based 
environment with

hostapd and iwd.


Hi Denis,

Looking pretty good. Do you also have hostapd and iwd patches available 
somewhere. I would like to see if I can get brcmfmac using it.




There are some very raw iwd patches I have.  They're sitting in my 
private tree.  I can send these to you privately or maybe setup a wiki 
page somewhere for you to grab them.  They do not take the 
NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211 feature bit into account, 
so I still need to work on these.  Was holding off until Johannes merges 
at least the high level API bits.


I never modified hostapd.  iwd has a very rudimentary AP mode support. 
Not fully useable but enough to run a 4-way handshake.  So with that in 
mind I concentrated on two scenarios while testing:


1. modified iwd (STA) utiling EAPoL over NL80211 connecting to stock 
hostapd.  In effect this was testing both the legacy and the new behavior.


2. modified iwd (STA) utilizing EAPoL over NL80211 connecting to stock 
hostapd.  Then disconnecting and connecting to modified iwd (AP).


iwd doesn't (yet) have support for P2P, IBSS or Mesh.  So the bits 
touching these features should be considered untested.


Regards,
-Denis

Re: [PATCH 01/10] rsi: add support for hardware scan offload

[Amitkumar Karwar]

Hi Kalle/Johannes,

On Tue, Mar 27, 2018 at 7:48 PM, Kalle Valo  wrote:
> Johannes Berg  writes:
>
>> On Fri, 2018-03-23 at 20:20 +0530, Amitkumar Karwar wrote:
>>
>>> > But maybe that's not really true at all? At least in one case it seems
>>> > you just kick off something called "bgscan".
>>>
>>> Yes. We have different scan implementations for device is connected
>>> and non-connected cases. In connected case, firmware will take care of
>>> timings when driver configures bgscan parameters due to power save and
>>> coex restrictions. In non-connected state, driver is taking care of
>>> it.
>>> I found hardware scan in mac80211 more suitable for our device.
>>
>> Yeah it's a bit odd though that you're still implementing software scan
>> :-)
>>
>> Perhaps we could make a special return code from the hwscan callback
>> that would tell mac80211 to fall back to software scanning, so you'd
>> only implement the connected case, and leave the rest up to mac80211?
>
> Hehe, this is exactly what I proposed during my review :)
>

Sounds good. I will prepare a patch with this approach.

Regards,
Amitkumar

Re: [PATCH 01/10] rsi: add support for hardware scan offload

[Kalle Valo]

Johannes Berg  writes:

> On Fri, 2018-03-23 at 20:20 +0530, Amitkumar Karwar wrote:
>
>> > But maybe that's not really true at all? At least in one case it seems
>> > you just kick off something called "bgscan".
>> 
>> Yes. We have different scan implementations for device is connected
>> and non-connected cases. In connected case, firmware will take care of
>> timings when driver configures bgscan parameters due to power save and
>> coex restrictions. In non-connected state, driver is taking care of
>> it.
>> I found hardware scan in mac80211 more suitable for our device.
>
> Yeah it's a bit odd though that you're still implementing software scan
> :-)
>
> Perhaps we could make a special return code from the hwscan callback
> that would tell mac80211 to fall back to software scanning, so you'd
> only implement the connected case, and leave the rest up to mac80211?

Hehe, this is exactly what I proposed during my review :)

-- 
Kalle Valo

Re: [PATCH 12/15] rtlwifi: btcoex: Add 8822b 1ant/2ant coex files

[Kalle Valo]

Pkshih  writes:

> On Tue, 2018-03-27 at 10:32 +0300, Kalle Valo wrote:
>>  writes:
>> 
>> > From: Ping-Ke Shih 
>> >
>> > There are two or three physical antenna in 8822be WiFi modules, so btcoex
>> > introduce two coex files to handle these two cases.
>> >
>> > Signed-off-by: Ping-Ke Shih 
>> > ---
>> >  .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.c| 5327 
>> >+++
>> >  .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.h|  413 ++
>> >  .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.c| 5370 
>> >
>> >  .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.h|  434 ++
>> >  4 files changed, 11544 insertions(+)
>> 
>> Huge patches like this are pain to review. I'm going to split this into
>> two sets, patches 1-11 and patches 12-15.
>> 
> Do I need to split the four files into four patches?

At least two patches would make it a bit less painful, like one patch
for halbtc8822b1ant.[c|h] and the other for halbtc8822b2ant.[c|h].

>> > +static struct coex_dm_8822b_1ant  glcoex_dm_8822b_1ant;
>> > +static struct coex_dm_8822b_1ant  *coex_dm = _dm_8822b_1ant;
>> > +static struct coex_sta_8822b_1ant glcoex_sta_8822b_1ant;
>> > +static struct coex_sta_8822b_1ant *coex_sta = _sta_8822b_1ant;
>> > +static struct rfe_type_8822b_1ant gl_rfe_type_8822b_1ant;
>> > +static struct rfe_type_8822b_1ant *rfe_type = _rfe_type_8822b_1ant;
>> > +
>> > +static const char *const glbt_info_src_8822b_1ant[] = {
>> > +  "BT Info[wifi fw]",
>> > +  "BT Info[bt rsp]",
>> > +  "BT Info[bt auto report]",
>> > +};
>> > +
>> > +static u32 glcoex_ver_date_8822b_1ant = 20180112;
>> > +static u32 glcoex_ver_8822b_1ant = 0x59;
>> > +static u32 glcoex_ver_btdesired_8822b_1ant = 0x56;
>> 
>> Having static variables like this means that this will not work if there
>> are two or more device per host, right? IIRC we discussed this before,
>> so what's the plan to solve that? 
>> 
>> In upstream drivers there should not be artificial limitations like one
>> device per host. Is that even checked anywhere or will it just be buggy
>> if there are more than one device?
>> 
>
> The variables coex_dm/coex_sta/rfe_type should move to struct btcoexist, but
> other btcoex files also use this style. So, my plan is to keep static 
> variables
> in this patch, and use another patch to remove all of them. Since this takes
> a little time to discuss with our btcoex guys, could I send patches
> 12-15 first?

That sounds like a good plan to me.

> The version related variables are used to display in debug message, so they
> work on multiple devices. 

Ok.

-- 
Kalle Valo

Re: [PATCH] iwlwifi: add device ID for Rivet Networks Killer Wireless-AC 1550

[Kalle Valo]

Izzy Kulbe  writes:

> On Tue, 2018-03-27 at 14:48 +0300, Kalle Valo wrote:
>> Izzy Kulbe  writes:
>> 
>> > nvm the last message, attached the wrong file using the 9270
>> > instead of the 9260 firmware, which obviously wouldn't work.
>> > Here's the working patch:
>> > 
>> > 
>> > Add support for Rivet Networks Killer Wireless-AC 1550 chipset, 
>> > which is using the Intel Wireless-AC 9260 chip
>> > 
>> > Signed-off-by: Izzy Kulbe 
>> > 
>> > ---
>> 
>> You should put the comment "nvm the last message..." under the "---"
>> line so that git-am can ignore it.
>
> Sorry, still new to the whole process. should i just resend 
> that message with the proper order? 

Luca already replied, so don't resend yet. But please do read the
documentation, it should help you with the basics and have pointers to
other docs:

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

-- 
Kalle Valo

[PATCH 3/3] mac80211: Use proper chan_width enum in sta opmode event

[Tamizh chelvam]

Bandwidth change value reported via nl80211 contains mac80211
specific enum value(ieee80211_sta_rx_bw) and which is not
understand by userspace application. Map the mac80211 specific
value to nl80211_chan_width enum value to avoid using wrong value
in the userspace application. And used station's ht/vht capability
to map IEEE80211_STA_RX_BW_20 and IEEE80211_STA_RX_BW_160 with
proper nl80211 value.

Signed-off-by: Tamizh chelvam 
---
 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/rx.c  |  3 ++-
 net/mac80211/vht.c | 32 +++-
 3 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 9237ffb..6c341d8 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1816,6 +1816,8 @@ void ieee80211_apply_vhtcap_overrides(struct 
ieee80211_sub_if_data *sdata,
  struct ieee80211_sta_vht_cap *vht_cap);
 void ieee80211_get_vht_mask_from_cap(__le16 vht_cap,
 u16 vht_mask[NL80211_VHT_NSS_MAX]);
+enum nl80211_chan_width
+ieee80211_sta_rx_bw_to_chan_width(struct sta_info *sta);
 
 /* Spectrum management */
 void ieee80211_process_measurement_req(struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index f8c69ac..3a9f0c0 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2922,7 +2922,8 @@ static void ieee80211_process_sa_query_req(struct 
ieee80211_sub_if_data *sdata,
 
rx->sta->sta.bandwidth = new_bw;
sband = rx->local->hw.wiphy->bands[status->band];
-   sta_opmode.bw = new_bw;
+   sta_opmode.bw =
+   ieee80211_sta_rx_bw_to_chan_width(rx->sta);
sta_opmode.changed = STA_OPMODE_MAX_BW_CHANGED;
 
rate_control_rate_update(local, sband, rx->sta,
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index 5714dee..259325c 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -358,6 +358,36 @@ enum nl80211_chan_width ieee80211_sta_cap_chan_bw(struct 
sta_info *sta)
return NL80211_CHAN_WIDTH_80;
 }
 
+enum nl80211_chan_width
+ieee80211_sta_rx_bw_to_chan_width(struct sta_info *sta)
+{
+   enum ieee80211_sta_rx_bandwidth cur_bw = sta->sta.bandwidth;
+   struct ieee80211_sta_vht_cap *vht_cap = >sta.vht_cap;
+   u32 cap_width;
+
+   switch (cur_bw) {
+   case IEEE80211_STA_RX_BW_20:
+   if (!sta->sta.ht_cap.ht_supported)
+   return NL80211_CHAN_WIDTH_20_NOHT;
+   else
+   return NL80211_CHAN_WIDTH_20;
+   case IEEE80211_STA_RX_BW_40:
+   return NL80211_CHAN_WIDTH_40;
+   case IEEE80211_STA_RX_BW_80:
+   return NL80211_CHAN_WIDTH_80;
+   case IEEE80211_STA_RX_BW_160:
+   cap_width =
+   vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
+
+   if (cap_width == IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ)
+   return NL80211_CHAN_WIDTH_160;
+
+   return NL80211_CHAN_WIDTH_80P80;
+   default:
+   return NL80211_CHAN_WIDTH_20;
+   }
+}
+
 enum ieee80211_sta_rx_bandwidth
 ieee80211_chan_width_to_rx_bw(enum nl80211_chan_width width)
 {
@@ -484,7 +514,7 @@ u32 __ieee80211_vht_handle_opmode(struct 
ieee80211_sub_if_data *sdata,
new_bw = ieee80211_sta_cur_vht_bw(sta);
if (new_bw != sta->sta.bandwidth) {
sta->sta.bandwidth = new_bw;
-   sta_opmode.bw = new_bw;
+   sta_opmode.bw = ieee80211_sta_rx_bw_to_chan_width(sta);
changed |= IEEE80211_RC_BW_CHANGED;
sta_opmode.changed |= STA_OPMODE_MAX_BW_CHANGED;
}
-- 
1.9.1

[PATCH 1/3] cfg80211: fix data type of sta_opmode_info parameter

[Tamizh chelvam]

Currently bw and smps_mode are u8 type value in sta_opmode_info
structure. This values filled in mac80211 from ieee80211_sta_rx_bandwidth
and ieee80211_smps_mode. These enum values are specific to mac80211 and
userspace/cfg80211 doesn't know about that. This will lead to incorrect
result/assumption by the user space application.
Change bw and smps_mode parameters to their respective enums in nl80211.

Signed-off-by: Tamizh chelvam 
---
 include/net/cfg80211.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index fc40843..4341508 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3572,15 +3572,15 @@ enum wiphy_opmode_flag {
 /**
  * struct sta_opmode_info - Station's ht/vht operation mode information
  * @changed: contains value from  wiphy_opmode_flag
- * @smps_mode: New SMPS mode of a station
- * @bw: new max bandwidth value of a station
+ * @smps_mode: New SMPS mode value from  nl80211_smps_mode of a station
+ * @bw: new max bandwidth value from  nl80211_chan_width of a station
  * @rx_nss: new rx_nss value of a station
  */
 
 struct sta_opmode_info {
u32 changed;
-   u8 smps_mode;
-   u8 bw;
+   enum nl80211_smps_mode smps_mode;
+   enum nl80211_chan_width bw;
u8 rx_nss;
 };
 
-- 
1.9.1

[PATCH 2/3] mac80211: Use proper smps_mode enum in sta opmode event

[Tamizh chelvam]

SMPS_MODE change value notified via nl80211 contains mac80211
specific value(ieee80211_smps_mode) and user space application
will not know those values. This patch add support to map
the mac80211 enum value to nl80211_smps_mode which will be
understood by the userspace application.

Signed-off-by: Tamizh chelvam 
---
 net/mac80211/ht.c  | 15 +++
 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/rx.c  |  3 ++-
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index d752353..c78036a 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -466,6 +466,21 @@ void ieee80211_process_delba(struct ieee80211_sub_if_data 
*sdata,
__ieee80211_stop_tx_ba_session(sta, tid, AGG_STOP_PEER_REQUEST);
 }
 
+enum nl80211_smps_mode
+ieee80211_smps_mode_to_smps_mode(enum ieee80211_smps_mode smps)
+{
+   switch (smps) {
+   case IEEE80211_SMPS_OFF:
+   return NL80211_SMPS_OFF;
+   case IEEE80211_SMPS_STATIC:
+   return NL80211_SMPS_STATIC;
+   case IEEE80211_SMPS_DYNAMIC:
+   return NL80211_SMPS_DYNAMIC;
+   default:
+   return NL80211_SMPS_OFF;
+   }
+}
+
 int ieee80211_send_smps_action(struct ieee80211_sub_if_data *sdata,
   enum ieee80211_smps_mode smps, const u8 *da,
   const u8 *bssid)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index ae9c33c..9237ffb 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1788,6 +1788,8 @@ void ieee80211_stop_tx_ba_cb(struct sta_info *sta, int 
tid,
 void ieee80211_release_reorder_timeout(struct sta_info *sta, int tid);
 
 u8 ieee80211_mcs_to_chains(const struct ieee80211_mcs_info *mcs);
+enum nl80211_smps_mode
+ieee80211_smps_mode_to_smps_mode(enum ieee80211_smps_mode smps);
 
 /* VHT */
 void
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 27bb1f0..f8c69ac 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2883,7 +2883,8 @@ static void ieee80211_process_sa_query_req(struct 
ieee80211_sub_if_data *sdata,
if (rx->sta->sta.smps_mode == smps_mode)
goto handled;
rx->sta->sta.smps_mode = smps_mode;
-   sta_opmode.smps_mode = smps_mode;
+   sta_opmode.smps_mode =
+   ieee80211_smps_mode_to_smps_mode(smps_mode);
sta_opmode.changed = STA_OPMODE_SMPS_MODE_CHANGED;
 
sband = rx->local->hw.wiphy->bands[status->band];
-- 
1.9.1

[PATCH 0/3] cfg80211/mac80211: Notify proper sta opmode change value

[Tamizh chelvam]

Currently bw and smps_mode are u8 type value in sta_opmode_info
structure. This values filled in mac80211 from ieee80211_sta_rx_bandwidth
and ieee80211_smps_mode. These enum values are specific to mac80211 and
userspace/cfg80211 doesn't know about that. This patchset change its
data type in the sta_opmode_info structure and mapping from mac80211
specific enum to nl80211 enum value.

Tamizh chelvam (3):
  cfg80211: fix data type of sta_opmode_info parameter
  mac80211: Use proper smps_mode enum in sta opmode event
  mac80211: Use proper chan_width enum in sta opmode event

 include/net/cfg80211.h |  8 
 net/mac80211/ht.c  | 15 +++
 net/mac80211/ieee80211_i.h |  4 
 net/mac80211/rx.c  |  6 --
 net/mac80211/vht.c | 32 +++-
 5 files changed, 58 insertions(+), 7 deletions(-)

-- 
1.9.1

Re: [PATCH 1/3] ieee80211: Replace bit shifts with the BIT() macro for WLAN_CAPABILITY_*.

[Johannes Berg]

On Sat, 2018-03-24 at 16:02 -0700, Quytelda Kahja wrote:
> The "document" refers to the file in which the changes were made
> ('include/linux/ieee80211.h').

You're the first person ever to do that, to my knowledge :)

Either way, I don't really want to merge this since it would break
staging, and I don't want to merge a staging fix either... so you'd have
to get that sorted out first.

johannes

Re: [PATCH 00/11] staging: wilc1000: fix for checkpatch and handled malloc memory properly

[Ajay Singh]

Hi Claudiu,

On Tue, 27 Mar 2018 11:55:52 +0300
Claudiu Beznea  wrote:

> On 27.03.2018 10:22, Ajay Singh wrote:
> > 
> > Please let me know, in case I have to rework and resubmit this patch
> > series to make them into staging branch.
> >   
> 
> As I suggested in patch 6, I prefer having the same format for
> wilc_wfi_cfg_tx_vendor_spec() and wilc_wfi_cfg_parse_rx_vendor_spec(). I
> think this could be achieved. To merge them I don't think would be feasible.
> 
> This series could go as is but I would like to see another future patch to
> treat the format of wilc_wfi_cfg_tx_vendor_spec().
> 

Sure, I had noted the review comments received for patch#6 & patch#1. I
will include the code modification in another future patches to handle it.


Regards,
Ajay

Re: [PATCH 01/10] rsi: add support for hardware scan offload

[Johannes Berg]

On Fri, 2018-03-23 at 20:20 +0530, Amitkumar Karwar wrote:

> > But maybe that's not really true at all? At least in one case it seems
> > you just kick off something called "bgscan".
> 
> Yes. We have different scan implementations for device is connected
> and non-connected cases. In connected case, firmware will take care of
> timings when driver configures bgscan parameters due to power save and
> coex restrictions. In non-connected state, driver is taking care of
> it.
> I found hardware scan in mac80211 more suitable for our device.

Yeah it's a bit odd though that you're still implementing software scan
:-)

Perhaps we could make a special return code from the hwscan callback
that would tell mac80211 to fall back to software scanning, so you'd
only implement the connected case, and leave the rest up to mac80211?

johannes

Re: [PATCH] mac80211: Fix wlan freezes under load at rekey

[Johannes Berg]

On Sat, 2018-03-24 at 11:29 +0100, Alexander Wetzel wrote:
> Rekeying a pairwise key with encryption offload and only keyid 0 has two
> potential races which can freeze the wlan conection till rekeyed again:
> 
>  1) For incomming packets:
> If the local STA installs the key prior to the remote STA we still
> have the old key active in the hardware for a short time after
> mac80211 switched to the new key.
> The card can still hand over packets decoded with the old key to
> mac80211, bumping the new PN (IV) value to an incorrect high number and
> tricking the local replay detection to drop all packets really sent
> with the new key.
> 
>  2) For outgoing packets:
> If mac80211 is providing the PN (IV) and hands over the cleartext
> packets for encryption to the hardware immediately prior to a key
> change the driver/card may process the queued packets after
> switching to the new key.
> This will immediatelly bump the PN (IV) value on the remote STA to
> an incorrect high number, also freezing the connection.

Correct for both, yes, this is a known issue.

> Both issues can be prevented by deleting the key from the hardware prior
> to switching to the new key in mac80211, falling back to software
> encryption/decryption till the switch to the new key is completed.

This, however, is not true in general. It only works if the queues are
flushed quickly enough between removing the key and setting a new one.
Otherwise, the same is still possible, e.g. on TX:

 * many packets are in the (HW) queue
 * enqueue packet with PN=0x1
 * turn off HW crypto
   [here I can actually see how you might now leak packets as
unencrypted that are already in the queue]
 * install a new key
 * turn on HW crypto for the new key
 * process packet with PN=0x1

Fundamentally, nothing stops this from happening, as we (still) don't
have any synchronization between transmission and key configuration.

Also, in this case it seems pretty obvious how you can leak packets
unencrypted, since the HW now no longer has a key. This might not even
be fixable if the NIC cannot reject packets that are supposed to be
encrypted to a key that's no longer valid in the HW.

I don't really see how the unencrypted leak happens with the current
code though, unless the driver somehow first invalidates the key and
then installs a new one, and there's a race with this?

Ultimately, I don't think this patch is good enough. We clearly have a
problem here with leaking unencrypted frames, if the device can't reject
them (and I can't really fault it for that), so in order to really fix
it we'd have to completely flush all software and hardware queues, and
then start again with a new key - and for that we don't even need to
disable HW crypto.


(FWIW, iwlwifi mostly avoids this problem on TX - at least for keys
other than GCMP-256 - by embedding the key material into the frame
itself, so we simply don't have such a race condition there)

johannes

Re: [RFC 0/3] cfg80211/mac80211: Notify proper sta opmode change value

[Tamizh chelvam]

On 2018-03-27 18:26, Johannes Berg wrote:

On Tue, 2018-03-27 at 12:18 +0530, Tamizh chelvam wrote:

Currently bw and smps_mode are u8 type value in sta_opmode_info
structure. This values filled in mac80211 from 
ieee80211_sta_rx_bandwidth
and ieee80211_smps_mode. These enum values are specific to mac80211 
and

userspace/cfg80211 doesn't know about that. This patchset change its
data type in the sta_opmode_info structure and mapping from mac80211
specific enum to nl80211 enum value.


Good catch.


Tamizh chelvam (3):
  cfg80211: fix data type of sta_opmode_info parameter
  mac80211: Use proper smps_mode enum in sta opmode event
  mac80211: Use proper chan_width enum in sta opmode event

Note :
  * Is this mac80211 approach sufficient ? or whether some more
complete cleanup would be preferred ?


Not sure what you mean? The patches look good to me.

I just wanted to confirm is this approach fine or not! I'll send a patch 
format

Re: [PATCH] iwlwifi: add device ID for Rivet Networks Killer Wireless-AC 1550

[Luciano Coelho]

On Tue, 2018-03-27 at 14:48 +0200, Izzy Kulbe wrote:
> On Tue, 2018-03-27 at 15:38 +0300, Luciano Coelho wrote:
> > On Tue, 2018-03-27 at 15:37 +0300, Luciano Coelho wrote:
> > > On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> > > Wait a bit.  This ID looks strange, someone else reported this
> > > already
> > > and it looked strange, with an incorrect subsystem vendor ID.
> > > 
> > > Can you run lspci like this and let us know the results?
> > > weird 
> > > lspci -nv -s 3b:00.0
> > 
> > Sorry, please substitute the 3b:00.0 with the correct PCI slot in
> > your
> > system.  If you're not sure, remove the '-s 3b:00.0' entirely so
> > we'll
> > get the results for all devices.
> > 
> > --
> > Luca.
> 
> The subsystem device in lspci itself reports "Bigfoot Networks, 
> Inc. Wireless-AC 9260" instead of when lookup is enabled. AFAIR this
> was a company that was bought by Qualcomm? So not Rivet/Killer. 
> 
> Here's the lspci output:
> 
> root@dokidoki $> # lspci-nv -s 04:00.0
> 04:00.0 0280: 8086:2526 (rev 29)
>   Subsystem: 1a56:1550
>   Flags: bus master, fast devsel, latency 0, IRQ 17
>   Memory at d3d0 (64-bit, non-prefetchable) [size=16K]
>   Capabilities: [c8] Power Management version 3
>   Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
>   Capabilities: [40] Express Endpoint, MSI 00
>   Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
>   Capabilities: [100] Advanced Error Reporting
>   Capabilities: [14c] Latency Tolerance Reporting
>   Capabilities: [154] L1 PM Substates
>   Kernel driver in use: iwlwifi
>   Kernel modules: iwlwifi

Thanks!

Yeah, this looks wrong and the same as someone else reported. :(

This value is coming from the OTP in the NIC and seems to be wrong.  I
have to contact our engineer who is responsible for the OTP data.  I'll
let you know once I get back some more information.

--
Cheers,
Luca.

Re: [PATCH] mac80211: Fix wlan freezes under load at rekey

[Johannes Berg]

On Mon, 2018-03-26 at 22:24 +0200, Alexander Wetzel wrote:

> There are quite many interesting things visible here, not the least one
> that ath9k leaks unencrypted frames for both patched and unpatched
> mac80211 which at least for my patched variant probably allow to
> calculate the TK key and encrypt all frames.

That's odd - any thoughts on how that might be happening?


johannes

Re: [RFC 0/3] cfg80211/mac80211: Notify proper sta opmode change value

[Johannes Berg]

On Tue, 2018-03-27 at 12:18 +0530, Tamizh chelvam wrote:
> Currently bw and smps_mode are u8 type value in sta_opmode_info
> structure. This values filled in mac80211 from ieee80211_sta_rx_bandwidth
> and ieee80211_smps_mode. These enum values are specific to mac80211 and
> userspace/cfg80211 doesn't know about that. This patchset change its
> data type in the sta_opmode_info structure and mapping from mac80211
> specific enum to nl80211 enum value.

Good catch.

> Tamizh chelvam (3):
>   cfg80211: fix data type of sta_opmode_info parameter
>   mac80211: Use proper smps_mode enum in sta opmode event
>   mac80211: Use proper chan_width enum in sta opmode event
> 
> Note :
>   * Is this mac80211 approach sufficient ? or whether some more
> complete cleanup would be preferred ?

Not sure what you mean? The patches look good to me.

johannes

Re: [RFC 3/4] mac80211: Apply per-peer NoAck tid bitmap configuration

[Johannes Berg]

On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
> 
> +u16 ieee80211_get_noack_map(struct ieee80211_sub_if_data *sdata, const u8 
> *mac)
> +{
> + struct sta_info *sta;
> + u16 noack_map = 0;
> +
> + /* Retrieve per-station noack_map config for the receiver, if any */
> +
> + rcu_read_lock();
> +
> + sta = sta_info_get(sdata, mac);
> + if (!sta) {
> + rcu_read_unlock();
> + return noack_map;
> + }
> +
> + noack_map = sta->noack_map;
> +
> + rcu_read_unlock();
> +
> + if (!noack_map)
> + noack_map = sdata->noack_map;

So this has an interesting corner case - should it be possible to have a
default noack_map that's non-zero, but override it with 0 for a specific
peer? It seems that it should be, which makes this code wrong.

johannes

Re: [RFC 1/4] mac80211: Add NoAck policy functionality offload infrastructure

[Johannes Berg]

On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
> 
> + * @IEEE80211_HW_SUPPORTS_NOACK_POLICY: Hardware (or driver) manages noack
> + *   policy handling. Hardware (or driver) takes care of setting
> + *   noack policy in the qos header and does not wait for the ack based
> + *   on the noack TID map. Driver advertising this support must implement
> + *   callback @set_noack_tid_bitmap to receive the user configured noack TID
> + *   bitmap.

Do you really need the ops method and the flag?

> + int (*set_noack_tid_bitmap)(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif, u8 noack_map);

You'd safe some effort by reordering the nl80211 patch first, so you can
immediately introduce it with per-peer capability here.

> +++ b/net/mac80211/cfg.c
> @@ -347,9 +347,15 @@ static int ieee80211_set_noack_map(struct wiphy *wiphy,
>  
>   sdata->noack_map = noack_map;
>  
> - ieee80211_check_fast_xmit_iface(sdata);
> + if (!ieee80211_hw_check(>local->hw, SUPPORTS_NOACK_POLICY)) {
> + ieee80211_check_fast_xmit_iface(sdata);
> + return 0;
> + }
>  
> - return 0;
> + if (!ieee80211_sdata_running(sdata))
> + return 0;
> +
> + return drv_set_noack_tid_bitmap(sdata->local, sdata, noack_map);

This doesn't seem right - you should do the fast xmit checks even if
calling the driver, no? And in fact, fast xmit should be permitted when
the noack is offloaded, so you shouldn't set sdata->noack_map in the
offloaded case at all.

> --- a/net/mac80211/iface.c
> +++ b/net/mac80211/iface.c
> @@ -631,6 +631,10 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool 
> coming_up)
>   ieee80211_vif_type_p2p(>vif));
>   if (res)
>   goto err_del_interface;
> +
> + if (sdata->noack_map)
> + drv_set_noack_tid_bitmap(local, sdata,
> +  sdata->noack_map);

Or maybe you do need to store it for this reason, but need to ignore it
for the purposes of fast-xmit if SUPPORTS_NOACK_POLICY is set.

> +++ b/net/mac80211/tx.c
> @@ -2817,7 +2817,8 @@ void ieee80211_check_fast_xmit(struct sta_info *sta)
>   test_sta_flag(sta, WLAN_STA_CLEAR_PS_FILT))
>   goto out;
>  
> - if (sdata->noack_map)
> + if (sdata->noack_map &&
> + !ieee80211_hw_check(>hw, SUPPORTS_NOACK_POLICY))
>   goto out;

Ah, and you do :-)

And then maybe you're indeed right and don't need to call the fast xmit
check in that place since it wouldn't have any effect either way.
 
johannes

Re: [PATCH] iwlwifi: add device ID for Rivet Networks Killer Wireless-AC 1550

[Izzy Kulbe]

On Tue, 2018-03-27 at 15:38 +0300, Luciano Coelho wrote:
> On Tue, 2018-03-27 at 15:37 +0300, Luciano Coelho wrote:
> > On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> > Wait a bit.  This ID looks strange, someone else reported this
> > already
> > and it looked strange, with an incorrect subsystem vendor ID.
> > 
> > Can you run lspci like this and let us know the results?
> > weird 
> > lspci -nv -s 3b:00.0
> 
> Sorry, please substitute the 3b:00.0 with the correct PCI slot in your
> system.  If you're not sure, remove the '-s 3b:00.0' entirely so we'll
> get the results for all devices.
> 
> --
> Luca.

The subsystem device in lspci itself reports "Bigfoot Networks, 
Inc. Wireless-AC 9260" instead of when lookup is enabled. AFAIR this
was a company that was bought by Qualcomm? So not Rivet/Killer. 

Here's the lspci output:

root@dokidoki $> # lspci-nv -s 04:00.0
04:00.0 0280: 8086:2526 (rev 29)
Subsystem: 1a56:1550
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at d3d0 (64-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [14c] Latency Tolerance Reporting
Capabilities: [154] L1 PM Substates
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

Re: [RFC 2/4] nl80211/mac80211: Extend NoAck policy command with peer MAC address

[Johannes Berg]

On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
> 
> - * @set_noack_map: Set the NoAck Map for the TIDs.
> + * @set_noack_map: Set the NoAck Map for the TIDs. When peer is not %NULL 
> NoAck
> + *   map will be applied for that particular peer. When peer is %NULL NoAck
> + *   map will be applied for all the connected stations (except the ones
> + *   which already have per-peer TID map configured) on the netdev.
> + *   Driver should return -ENOSPC when the it does not have room for
> + *   additional entries for per-peer NoAck map.

I guess it should also set the default for new stations when the peer is
not given? At least that's how mac80211 would behave now, afaict.

The question is how that interacts with having enough space - are you
sure this is a concern?

>   * @NL80211_CMD_SET_NOACK_MAP: sets a bitmap for the individual TIDs whether
> - *  No Acknowledgement Policy should be applied.
> + *   No Acknowledgement Policy should be applied. %NL80211_ATTR_MAC is used
> + *   to apply No Acknowledgement policy for a particular connected station.
> + *   Station specific NoAck policy configuration is valid only for STA's
> + *   current connection, i.e. the configuration will not be used when the
> + *   station connects back after disconnection/roaming.
> + *   When user-space does not include %NL80211_ATTR_MAC, the No
> + *   Acknowledgement Policy setting should be treated as per-netdev
> + *   configuration.

Here you describe different semantics - i.e. you didn't describe the
"previous per-station settings are kept" part. I'm not sure that part
makes much sense anyhow?

johannes

Re: [PATCH] iwlwifi: add device ID for Rivet Networks Killer Wireless-AC 1550

[Luciano Coelho]

On Tue, 2018-03-27 at 15:37 +0300, Luciano Coelho wrote:
> On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> > On Tue, 2018-03-27 at 14:48 +0300, Kalle Valo wrote:
> > > Izzy Kulbe  writes:
> > > 
> > > > nvm the last message, attached the wrong file using the 9270
> > > > instead of the 9260 firmware, which obviously wouldn't work.
> > > > Here's the working patch:
> > > > 
> > > > 
> > > > Add support for Rivet Networks Killer Wireless-AC 1550
> > > > chipset, 
> > > > which is using the Intel Wireless-AC 9260 chip
> > > > 
> > > > Signed-off-by: Izzy Kulbe 
> > > > 
> > > > ---
> > > 
> > > You should put the comment "nvm the last message..." under the "-
> > > --
> > > "
> > > line so that git-am can ignore it.
> > 
> > Sorry, still new to the whole process. should i just resend 
> > that message with the proper order? 
> 
> Wait a bit.  This ID looks strange, someone else reported this
> already
> and it looked strange, with an incorrect subsystem vendor ID.
> 
> Can you run lspci like this and let us know the results?
> 
> lspci -nv -s 3b:00.0

Sorry, please substitute the 3b:00.0 with the correct PCI slot in your
system.  If you're not sure, remove the '-s 3b:00.0' entirely so we'll
get the results for all devices.

--
Luca.

Re: [PATCH] iwlwifi: add device ID for Rivet Networks Killer Wireless-AC 1550

[Luciano Coelho]

On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> On Tue, 2018-03-27 at 14:48 +0300, Kalle Valo wrote:
> > Izzy Kulbe  writes:
> > 
> > > nvm the last message, attached the wrong file using the 9270
> > > instead of the 9260 firmware, which obviously wouldn't work.
> > > Here's the working patch:
> > > 
> > > 
> > > Add support for Rivet Networks Killer Wireless-AC 1550 chipset, 
> > > which is using the Intel Wireless-AC 9260 chip
> > > 
> > > Signed-off-by: Izzy Kulbe 
> > > 
> > > ---
> > 
> > You should put the comment "nvm the last message..." under the "---
> > "
> > line so that git-am can ignore it.
> 
> Sorry, still new to the whole process. should i just resend 
> that message with the proper order? 

Wait a bit.  This ID looks strange, someone else reported this already
and it looked strange, with an incorrect subsystem vendor ID.

Can you run lspci like this and let us know the results?

lspci -nv -s 3b:00.0

--
Cheers,
Luca.

Re: [PATCH] iwlwifi: add device ID for Rivet Networks Killer Wireless-AC 1550

[Izzy Kulbe]

On Tue, 2018-03-27 at 14:48 +0300, Kalle Valo wrote:
> Izzy Kulbe  writes:
> 
> > nvm the last message, attached the wrong file using the 9270 instead of the 
> > 9260 firmware, which obviously wouldn't work. Here's the working patch:
> > 
> > 
> > Add support for Rivet Networks Killer Wireless-AC 1550 chipset, 
> > which is using the Intel Wireless-AC 9260 chip
> > 
> > Signed-off-by: Izzy Kulbe 
> > 
> > ---
> 
> You should put the comment "nvm the last message..." under the "---"
> line so that git-am can ignore it.

Sorry, still new to the whole process. should i just resend 
that message with the proper order? 

Re: [PATCH] iwlwifi: add device ID for Rivet Networks Killer Wireless-AC 1550

[Kalle Valo]

Izzy Kulbe  writes:

> nvm the last message, attached the wrong file using the 9270 instead of the 
> 9260 firmware, which obviously wouldn't work. Here's the working patch:
>
>
> Add support for Rivet Networks Killer Wireless-AC 1550 chipset, 
> which is using the Intel Wireless-AC 9260 chip
>
> Signed-off-by: Izzy Kulbe 
>
> ---

You should put the comment "nvm the last message..." under the "---"
line so that git-am can ignore it.

-- 
Kalle Valo

Re: [PATCH] iwlwifi: add device ID for Rivet Networks Killer Wireless-AC 1550

[Izzy Kulbe]

nvm the last message, attached the wrong file using the 9270 instead of the 
9260 firmware, which obviously wouldn't work. Here's the working patch:


Add support for Rivet Networks Killer Wireless-AC 1550 chipset, 
which is using the Intel Wireless-AC 9260 chip

Signed-off-by: Izzy Kulbe 

---
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c 
/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -543,6 +543,7 @@ static const struct pci_device_id iwl_hw_card_ids[]
= {
{IWL_PCI_DEVICE(0x2526, 0x1210, iwl9260_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x1410, iwl9270_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x1420, iwl9460_2ac_cfg_soc)},
+   {IWL_PCI_DEVICE(0x2526, 0x1550, iwl9260_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x1610, iwl9270_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x4010, iwl9260_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x4030, iwl9560_2ac_cfg)},

[PATCH] iwlwifi: add device ID for Rivet Networks Killer Wireless-AC 1550

[Izzy Kulbe]

Add support for Rivet Networks Killer Wireless-AC 1550 chipset, 
which is using the Intel Wireless-AC 9260 chip

Signed-off-by: Izzy Kulbe 

---
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 56fc28750a41..62ab4790687c 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -543,6 +543,7 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0x2526, 0x1210, iwl9260_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x1410, iwl9270_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x1420, iwl9460_2ac_cfg_soc)},
+   {IWL_PCI_DEVICE(0x2526, 0x1550, iwl9270_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x1610, iwl9270_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x4010, iwl9260_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x4030, iwl9560_2ac_cfg)},
-- 
2.16.2

Re: [PATCH 12/15] rtlwifi: btcoex: Add 8822b 1ant/2ant coex files

[Pkshih]

On Tue, 2018-03-27 at 10:32 +0300, Kalle Valo wrote:
>  writes:
> 
> > From: Ping-Ke Shih 
> >
> > There are two or three physical antenna in 8822be WiFi modules, so btcoex
> > introduce two coex files to handle these two cases.
> >
> > Signed-off-by: Ping-Ke Shih 
> > ---
> >  .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.c| 5327 
> >+++
> >  .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.h|  413 ++
> >  .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.c| 5370 
> >
> >  .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.h|  434 ++
> >  4 files changed, 11544 insertions(+)
> 
> Huge patches like this are pain to review. I'm going to split this into
> two sets, patches 1-11 and patches 12-15.
> 
Do I need to split the four files into four patches?


> > +/* 
> > + * Description:
> > + *
> > + * This file is for RTL8822B Co-exist mechanism
> > + *
> > + * History
> > + * 2012/11/15 Cosa first check in.
> 
> The history feels useless to me.
> 
I'll delete it.

> > + *
> > + * */
> > +
> > +/* 
> > + * include files
> > + * */
> > +/*only for rf4ce*/
> > +#include "halbt_precomp.h"
> > +
> > +/* 
> > + * Global variables, these are static variables
> > + * */
> 
> Also extensive use of "**" lines is not really upstream style.
> 
They're not meaningful, so I'll delete them.

> > +static struct coex_dm_8822b_1ant   glcoex_dm_8822b_1ant;
> > +static struct coex_dm_8822b_1ant   *coex_dm = _dm_8822b_1ant;
> > +static struct coex_sta_8822b_1ant  glcoex_sta_8822b_1ant;
> > +static struct coex_sta_8822b_1ant  *coex_sta = _sta_8822b_1ant;
> > +static struct rfe_type_8822b_1ant  gl_rfe_type_8822b_1ant;
> > +static struct rfe_type_8822b_1ant  *rfe_type = _rfe_type_8822b_1ant;
> > +
> > +static const char *const glbt_info_src_8822b_1ant[] = {
> > +   "BT Info[wifi fw]",
> > +   "BT Info[bt rsp]",
> > +   "BT Info[bt auto report]",
> > +};
> > +
> > +static u32 glcoex_ver_date_8822b_1ant = 20180112;
> > +static u32 glcoex_ver_8822b_1ant = 0x59;
> > +static u32 glcoex_ver_btdesired_8822b_1ant = 0x56;
> 
> Having static variables like this means that this will not work if there
> are two or more device per host, right? IIRC we discussed this before,
> so what's the plan to solve that? 
> 
> In upstream drivers there should not be artificial limitations like one
> device per host. Is that even checked anywhere or will it just be buggy
> if there are more than one device?
> 

The variables coex_dm/coex_sta/rfe_type should move to struct btcoexist, but
other btcoex files also use this style. So, my plan is to keep static variables
in this patch, and use another patch to remove all of them. Since this takes
a little time to discuss with our btcoex guys, could I send patches 12-15 first?
The version related variables are used to display in debug message, so they
work on multiple devices. 

Thanks
PK

Re: mt76x2: fix warning in ieee80211_get_key_rx_seq()

[Kalle Valo]

Lorenzo Bianconi  wrote:

> Fall back to software encryption for hw unsupported ciphers in order
> to fix the following warning in ieee80211_get_key_rx_seq routine:
> 
> WARNING: CPU: 1 PID: 1277 at backports-2017-11-01/net/mac80211/key.c:
> 1010 mt76_wcid_key_setup+0x6c/0x138 [mt76]
> CPU: 1 PID: 1277 Comm: hostapd Tainted: GW   4.9.86 #0
> Stack :   80527b4a 0042 80523824   
> 8052
> 8fd79a9c 804bbda7 80454c84 0001 04fd 80523824 8f7e4ba0 
> 8eceda12
> 0010 8006af94 0001 8052 804c1f04 804c1f08 80459890 
> 8ec999b4
> 0003 800a7840 8f7e4ba0 8eceda12 8121de20  0001 
> 00c999b4
>        
> 
> ...
> Call Trace:
> [<8000f52c>] show_stack+0x70/0x8c
> [<801d8d04>] dump_stack+0x94/0xd0
> [<8002bcd4>] __warn+0x110/0x118
> [<8002bd70>] warn_slowpath_null+0x1c/0x2c
> [<8f0415cc>] mt76_wcid_key_setup+0x6c/0x138 [mt76]
> [<8f1311b4>] mt76x2_dma_cleanup+0xa38/0x1048 [mt76x2e]
> 
> Fixes: 30ce7f4456ae ("mt76: validate rx CCMP PN")
> Signed-off-by: Lorenzo Bianconi 
> Acked-by: Felix Fietkau 

Patch applied to wireless-drivers-next.git, thanks.

c03a5aacde0c mt76x2: fix warning in ieee80211_get_key_rx_seq()

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

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

Re: mt76x2: fix possible NULL pointer dereferencing in mt76x2_tx()

[Kalle Valo]

Lorenzo Bianconi  wrote:

> Fix a theoretical NULL pointer dereferencing in mt76x2_tx routine that
> can occurs for injected frames in a monitor vif since vif pointer could
> be NULL for that interfaces
> 
> Fixes: 23405236460b ("mt76: fix transmission of encrypted mgmt frames")
> Signed-off-by: Lorenzo Bianconi 
> Acked-by: Felix Fietkau 

Patch applied to wireless-drivers-next.git, thanks.

6958b027435a mt76x2: fix possible NULL pointer dereferencing in mt76x2_tx()

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

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

Re: mt76: use mt76_poll_msec routine in mt76pci_load_firmware()

[Kalle Valo]

Lorenzo Bianconi  wrote:

> Use mt76_poll_msec() in mt76pci_load_firmware to check if the firmware
> has been started instead of explicitly poll MCU running register
> 
> Signed-off-by: Lorenzo Bianconi 

Patch applied to wireless-drivers-next.git, thanks.

db2ad7c25a9a mt76: use mt76_poll_msec routine in mt76pci_load_firmware()

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

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

Re: brcmsmac: allocate ucode with GFP_KERNEL

[Kalle Valo]

Takashi Iwai  wrote:

> The brcms_ucode_init_buf() duplicates the ucode chunks via kmemdup()
> with GFP_ATOMIC as a precondition of wl->lock acquired.  This caused
> allocation failures sometimes as reported in the bugzilla below.
> 
> When looking at the the real usage, one can find that it's called
> solely from brcms_request_fw(), and it's obviously outside the lock.
> Hence we can use GFP_KERNEL there safely for avoiding such allocation
> errors.
> 
> Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=1085174
> Signed-off-by: Takashi Iwai 
> Acked-by: Arend van Spriel 

Patch applied to wireless-drivers-next.git, thanks.

b1c2d0f2507b brcmsmac: allocate ucode with GFP_KERNEL

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

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

Re: [V2, 01/12] brcmfmac: do not convert linux error to firmware error string

[Kalle Valo]

Arend Van Spriel  wrote:

> In case of a linux error brcmf_fil_cmd_data() blurts an error message
> in which the error code is translated to an error string. However, it
> maps it to a firmware error string which should not happen. Simply
> print only the numeric error code and be done with it.
> 
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Pieter-Paul Giesberts 
> Reviewed-by: Franky Lin 
> Signed-off-by: Arend van Spriel 

12 patches applied to wireless-drivers-next.git, thanks.

1170f6d1be6a brcmfmac: do not convert linux error to firmware error string
756a2b390874 brcmfmac: use brcmf_chip_name() to store name in revinfo
c88cfa075de3 brcmfmac: use brcmf_chip_name() for consistency
856d5a011c86 brcmfmac: allocate struct brcmf_pub instance using wiphy_new()
34789d0cf682 brcmfmac: use wiphy debugfs dir entry
41f573dbb534 brcmfmac: derive firmware filenames from basename mapping
d09ae51a4b67 brcmfmac: pass struct in brcmf_fw_get_firmwares()
2baa3aaee27f brcmfmac: introduce brcmf_fw_alloc_request() function
bf7a7b37f6ef brcmfmac: add extension to .get_fwname() callbacks
18c2b20e276e brcmfmac: get rid of brcmf_fw_map_chip_to_name()
bf291b7247e5 brcmfmac: get rid of brcmf_fw_get_full_name()
48eaee3f272a brcmfmac: add kerneldoc for struct brcmf_bus::msgbuf

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

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

Re: rtlwifi: rtl8821ae: fix spelling mistake: "Aboslute" -> "Absolute"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in RT_TRACE message text.
> 
> Signed-off-by: Colin Ian King 
> Acked-by: Larry Finger  "Absolute"

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

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

Re: rtlwifi: correct comment

[Kalle Valo]

Kevin Lo  wrote:

> Correct comment.  Set bit 3 and bit 4 of 0x0005 register (REG_APS_FSMCO + 1)
> to 0 which means disable WL suspend, not enable WL suspend.
> 
> Signed-off-by: Kevin Lo 
> Acked-by: Ping-Ke Shih 
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/pwrseq.h 
> b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/pwrseq.h
> index f2d9c6116e5c..8379a3e5198c 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/pwrseq.h
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/pwrseq.h
> @@ -142,7 +142,7 @@
>   /*wait power state to suspend*/},   \
>   {0x0005, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_ALL_MSK,\
>   PWR_BASEADDR_MAC, PWR_CMD_WRITE, BIT(3) | BIT(4), 0 \
> - /*0x04[12:11] = 2b'01enable WL suspend*/},
> + /*0x04[12:11] = 2b'00 disable WL suspend*/},
>  
>  #define RTL8188EE_TRANS_CARDEMU_TO_CARDDIS   \
>   {0x0026, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_ALL_MSK,\
> @@ -179,7 +179,7 @@
>   /*wait power state to suspend*/},   \
>   {0x0005, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_ALL_MSK,\
>   PWR_BASEADDR_MAC, PWR_CMD_WRITE, BIT(3)|BIT(4), 0   \
> - /*0x04[12:11] = 2b'01enable WL suspend*/},
> + /*0x04[12:11] = 2b'00 disable WL suspend*/},
>  
>  #define RTL8188EE_TRANS_CARDEMU_TO_PDN   
> \
>   {0x0006, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_ALL_MSK,\
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/pwrseq.h 
> b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/pwrseq.h
> index 781eeaa6af49..c570801508cc 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/pwrseq.h
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/pwrseq.h
> @@ -134,7 +134,7 @@
>   /*wait power state to suspend*/ \
>   {0x0086, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_SDIO_MSK,   \
>PWR_BASEADDR_SDIO , PWR_CMD_POLLING, BIT(1), BIT(1)},  \
> - /*0x04[12:11] = 2b'01enable WL suspend*/\
> + /*0x04[12:11] = 2b'00 disable WL suspend*/  \
>   {0x0005, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_ALL_MSK,\
>PWR_BASEADDR_MAC , PWR_CMD_WRITE, BIT(3) | BIT(4), 0},
>  
> @@ -181,7 +181,7 @@
>   /*Lock small LDO Register*/ \
>   {0x00CC, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_SDIO_MSK,   \
>PWR_BASEADDR_MAC , PWR_CMD_WRITE, BIT(2), 0},  \
> - /*0x04[12:11] = 2b'01enable WL suspend*/\
> + /*0x04[12:11] = 2b'00 disable WL suspend*/  \
>   {0x0005, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_ALL_MSK,\
>PWR_BASEADDR_MAC , PWR_CMD_WRITE, BIT(3) | BIT(4), 0},
>  
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/pwrseq.h 
> b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/pwrseq.h
> index 4ac7db526f15..e6c3aac3e9fd 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/pwrseq.h
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/pwrseq.h
> @@ -135,7 +135,7 @@
>   /*wait power state to suspend*/ \
>   {0x0086, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_SDIO_MSK,\
>   PWR_BASEADDR_SDIO, PWR_CMD_POLLING, BIT(1), BIT(1)},\
> - /*0x04[12:11] = 2b'01enable WL suspend*/ \
> + /*0x04[12:11] = 2b'00 disable WL suspend*/ \
>   {0x0005, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_ALL_MSK,\
>   PWR_BASEADDR_MAC, PWR_CMD_WRITE, BIT(3)|BIT(4), 0},
>  
> @@ -172,7 +172,7 @@
>   {0x0086, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, \
>   PWR_INTF_SDIO_MSK, PWR_BASEADDR_SDIO,\
>   PWR_CMD_POLLING, BIT(1), BIT(1)},\
> - /*0x04[12:11] = 2b'00enable WL suspend*/ \
> + /*0x04[12:11] = 2b'00 disable WL suspend*/ \
>   {0x0005, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, \
>   PWR_INTF_ALL_MSK, PWR_BASEADDR_MAC,\
>   PWR_CMD_WRITE, BIT(3)|BIT(4), 0},\
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/pwrseq.h 
> b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/pwrseq.h
> index 0fee5e0e55c2..3367cfbc9502 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/pwrseq.h
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/pwrseq.h
> @@ -204,7 +204,7 @@
>   /*0x23[4] = 1b'0 12H LDO enter normal mode*/\
>   {0x0023, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_SDIO_MSK,   \
>PWR_BASEADDR_MAC, PWR_CMD_WRITE, BIT(4), 0},   \
> - /*0x04[12:11] = 2b'01enable WL suspend*/\
> + /*0x04[12:11] = 2b'00 disable WL suspend*/  \
>   {0x0005, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_ALL_MSK,\
>PWR_BASEADDR_MAC, PWR_CMD_WRITE, BIT(3)|BIT(4), 0},
>  
> @@ -251,7 +251,7 @@
>   

Re: [v2, 01/15] rtlwifi: Add modifier static to functions reported by sparse

[Kalle Valo]

Ping-Ke Shih  wrote:

> From: Ping-Ke Shih 
> 
> sparse reports some functions were not declared, so add 'static' as
> modifier. Remove an unused function btc8821a1ant_is_wifi_status_changed()
> exposed due to 'static'.
> 
> Signed-off-by: Ping-Ke Shih 
> Acked-by: Larry Finger 

11 patches applied to wireless-drivers-next.git, thanks.

91b9e6844240 rtlwifi: Add modifier static to functions reported by sparse
757a9eb8df1f rtlwifi: remove redundant statement found by static checker
5ffd1155d536 rtlwifi: btcoex: Add enum DM_INFO for btcoex to query dm's counters
a1ee1a09cbba rtlwifi: btcoex: Add customer_id to do special deal to oem vendor
123068f2eb30 rtlwifi: btcoex: Get status of multichannel concurrence
1f0ab4fbacc6 rtlwifi: btcoex: Add rate table for the use of btcoex
7fd34dc4d827 rtlwifi: btcoex: Add interaction with phydm
c3468950ef80 rtlwifi: btcoex: Add pre- and post- normal LPS function
0843e98a3b9a rtlwifi: btcoex: add assoc type v2 to connection notify
b82f5e0fd2a2 rtlwifi: btcoex: new definitions introduced by 8822be
c37889472515 rtlwifi: btcoex: Add new but dummy definitions introduced by 8822b

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

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

Re: [PATCH 00/11] staging: wilc1000: fix for checkpatch and handled malloc memory properly

[Claudiu Beznea]

On 27.03.2018 10:22, Ajay Singh wrote:
> 
> Please let me know, in case I have to rework and resubmit this patch
> series to make them into staging branch.
> 

As I suggested in patch 6, I prefer having the same format for
wilc_wfi_cfg_tx_vendor_spec() and wilc_wfi_cfg_parse_rx_vendor_spec(). I
think this could be achieved. To merge them I don't think would be feasible.

This series could go as is but I would like to see another future patch to
treat the format of wilc_wfi_cfg_tx_vendor_spec().

Thank you,
Claudiu

> Regards,
> Ajay
> 

Re: [1/2] rsi: fix error path handling in SDIO probe

[Kalle Valo]

Amitkumar Karwar  wrote:

> From: Amitkumar Karwar 
> 
> We miss to release IRQ in certain error path in SDIO probe which
> causes following kernel panic. This patch corrects error path
> handling
> 
> BUG: unable to handle kernel NULL pointer dereference at(null)
> IP:   (null)
> PGD 0 P4D 0
> Oops: 0010 [#1] SMP PTI
> Call Trace:
>  
>  ? call_timer_fn+0x29/0x120
>  ? run_timer_softirq+0x1da/0x420
>  ? timer_interrupt+0x11/0x20
>  ? __do_softirq+0xef/0x26e
>  ? irq_exit+0xbe/0xd0
>  ? do_IRQ+0x4a/0xc0
>  ? common_interrupt+0xa2/0xa2
>  
>  ? cpuidle_enter_state+0x118/0x250
>  ? do_idle+0x186/0x1e0
>  ? cpu_startup_entry+0x6f/0x80
>  ? start_kernel+0x47c/0x49c
>  ? secondary_startup_64+0xa5/0xb0
> 
> Fixes: 50117605770c ("rsi: improve RX handling in SDIO interface")
> Signed-off-by: Amitkumar Karwar 

2 patches applied to wireless-drivers-next.git, thanks.

90b12aebe54b rsi: fix error path handling in SDIO probe
864db4d50853 rsi: fix kernel panic observed on 64bit machine

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

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

Re: [next] rsi: remove redundant duplicate assignment of buffer_size

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Variable buffer_size is re-assigned the same value, this duplicated
> assignment is redundant and can be removed.
> 
> Cleans up clang warning:
> drivers/net/wireless/rsi/rsi_91x_usb.c:140:4: warning: Value stored
> to 'buffer_size' is never read
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

a31f9314114c rsi: remove redundant duplicate assignment of buffer_size

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

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

[RFC 0/4] wireless: Per-sta NoAck and offload support

[Vasanthakumar Thiagarajan]

Adds infrastructure for driver to offload NoAck functionality, driver
like ath10k could make use of it. Also extends the current ndev wide
NoAck policy to per-station, with sta level NoAck policy configuration
userspace could selectively turn off/on Noack based on various connection
parameters of the station.

Vasanthakumar Thiagarajan (4):
  mac80211: Add NoAck policy functionality offload infrastructure
  nl80211/mac80211: Extend NoAck policy command with peer MAC address
  mac80211: Apply per-peer NoAck tid bitmap configuration
  mac80211: Advertise per-peer NoAck policy support

 include/net/cfg80211.h   |  9 +++--
 include/net/mac80211.h   | 18 ++
 include/uapi/linux/nl80211.h | 12 +++-
 net/mac80211/cfg.c   | 45 +---
 net/mac80211/debugfs.c   |  1 +
 net/mac80211/driver-ops.h| 22 ++
 net/mac80211/iface.c |  4 
 net/mac80211/main.c  |  8 
 net/mac80211/sta_info.h  |  3 +++
 net/mac80211/trace.h | 28 +++
 net/mac80211/tx.c|  3 ++-
 net/mac80211/wme.c   | 35 +-
 net/wireless/nl80211.c   | 12 +++-
 net/wireless/rdev-ops.h  |  7 ---
 net/wireless/trace.h | 11 +++
 15 files changed, 202 insertions(+), 16 deletions(-)

-- 
1.9.1

[RFC 4/4] mac80211: Advertise per-peer NoAck policy support

[Vasanthakumar Thiagarajan]

This enables per-peer NoAck handling in mac80211 when
the functionality is not offloaded to the drivers.

Signed-off-by: Vasanthakumar Thiagarajan 
---
 net/mac80211/main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 78f2574..2b136fb 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -565,6 +565,10 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t 
priv_data_len,
 
wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_RRM);
 
+   if (!ops->set_noack_tid_bitmap)
+   wiphy_ext_feature_set(wiphy,
+ NL80211_EXT_FEATURE_PER_STA_NOACK_MAP);
+
wiphy->bss_priv_size = sizeof(struct ieee80211_bss);
 
local = wiphy_priv(wiphy);
-- 
1.9.1

[RFC 2/4] nl80211/mac80211: Extend NoAck policy command with peer MAC address

[Vasanthakumar Thiagarajan]

Provides peer level NoAck policy configuration by extending
NL80211_CMD_SET_NOACK_MAP command with peer MAC address.
If user space does not give any peer mac address, the driver
should retain the existing functionality of applying the NoAck
policy for all the staions connected to the netdev. Peer specific
configuration takes precedence over netdev level configuration when
both are set by the user. Drivers supporting per-sta NoAck policy
must advertise the support through the extended flag index
NL80211_EXT_FEATURE_PER_STA_NOACK_MAP.

Signed-off-by: Vasanthakumar Thiagarajan 
---
 include/net/cfg80211.h   |  9 +++--
 include/uapi/linux/nl80211.h | 12 +++-
 net/mac80211/cfg.c   |  1 +
 net/wireless/nl80211.c   | 12 +++-
 net/wireless/rdev-ops.h  |  7 ---
 net/wireless/trace.h | 11 +++
 6 files changed, 41 insertions(+), 11 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index fc40843..b974d32 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2872,7 +2872,12 @@ struct cfg80211_external_auth_params {
  * @probe_client: probe an associated client, must return a cookie that it
  * later passes to cfg80211_probe_status().
  *
- * @set_noack_map: Set the NoAck Map for the TIDs.
+ * @set_noack_map: Set the NoAck Map for the TIDs. When peer is not %NULL NoAck
+ * map will be applied for that particular peer. When peer is %NULL NoAck
+ * map will be applied for all the connected stations (except the ones
+ * which already have per-peer TID map configured) on the netdev.
+ * Driver should return -ENOSPC when the it does not have room for
+ * additional entries for per-peer NoAck map.
  *
  * @get_channel: Get the current operating channel for the virtual interface.
  * For monitor interfaces, it should return %NULL unless there's a single
@@ -3180,7 +3185,7 @@ struct cfg80211_ops {
 
int (*set_noack_map)(struct wiphy *wiphy,
  struct net_device *dev,
- u16 noack_map);
+ const u8 *peer, u16 noack_map);
 
int (*get_channel)(struct wiphy *wiphy,
   struct wireless_dev *wdev,
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 60fefc5..7425ea6 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -784,7 +784,14 @@
  * messages. Note that per PHY only one application may register.
  *
  * @NL80211_CMD_SET_NOACK_MAP: sets a bitmap for the individual TIDs whether
- *  No Acknowledgement Policy should be applied.
+ * No Acknowledgement Policy should be applied. %NL80211_ATTR_MAC is used
+ * to apply No Acknowledgement policy for a particular connected station.
+ * Station specific NoAck policy configuration is valid only for STA's
+ * current connection, i.e. the configuration will not be used when the
+ * station connects back after disconnection/roaming.
+ * When user-space does not include %NL80211_ATTR_MAC, the No
+ * Acknowledgement Policy setting should be treated as per-netdev
+ * configuration.
  *
  * @NL80211_CMD_CH_SWITCH_NOTIFY: An AP or GO may decide to switch channels
  * independently of the userspace SME, send this event indicating
@@ -5005,6 +5012,8 @@ enum nl80211_feature_flags {
  * channel change triggered by radar detection event.
  * No need to start CAC from user-space, no need to react to
  * "radar detected" event.
+ * @NL80211_EXT_FEATURE_PER_STA_NOACK_MAP: Driver supports STA specific NoAck
+ * policy functionality.
  *
  * @NUM_NL80211_EXT_FEATURES: number of extended features.
  * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -5036,6 +5045,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_LOW_POWER_SCAN,
NL80211_EXT_FEATURE_HIGH_ACCURACY_SCAN,
NL80211_EXT_FEATURE_DFS_OFFLOAD,
+   NL80211_EXT_FEATURE_PER_STA_NOACK_MAP,
 
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a2f0eae..621ef38 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -341,6 +341,7 @@ static void ieee80211_del_nan_func(struct wiphy *wiphy,
 
 static int ieee80211_set_noack_map(struct wiphy *wiphy,
  struct net_device *dev,
+ const u8 *peer,
  u16 noack_map)
 {
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index fe27ab4..8d7f055a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3095,16 +3095,26 @@ static int nl80211_set_noack_map(struct sk_buff *skb, 
struct genl_info *info)
struct cfg80211_registered_device *rdev = info->user_ptr[0];

Re: [PATCH] staging: wilc1000: replace kmalloc + memcpy with kmemdup

[Claudiu Beznea]

On 26.03.2018 20:16, Colin King wrote:
> From: Colin Ian King 
> 
> Replace several allocation and memcpys with kmemdup and add in some
> missing memory allocation failure checks.  Also fix an incorrect 
> -EFAULT return with -ENOMEM.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/staging/wilc1000/host_interface.c | 75 
> +++
>  1 file changed, 46 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c 
> b/drivers/staging/wilc1000/host_interface.c
> index 9b9b86654958..8fd367f87fa5 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -797,6 +797,10 @@ static s32 handle_scan(struct wilc_vif *vif, struct 
> scan_attr *scan_info)
>   for (i = 0; i < hidden_net->n_ssids; i++)
>   valuesize += ((hidden_net->net_info[i].ssid_len) + 1);
>   hdn_ntwk_wid_val = kmalloc(valuesize + 1, GFP_KERNEL);
> + if (!hdn_ntwk_wid_val) {
> + result = -ENOMEM;
> + goto error;
> + }
>   wid_list[index].val = hdn_ntwk_wid_val;
>   if (wid_list[index].val) {
>   buffer = wid_list[index].val;
> @@ -943,39 +947,35 @@ static s32 handle_connect(struct wilc_vif *vif,
>   }
>  
>   if (conn_attr->bssid) {

These:
> - hif_drv->usr_conn_req.bssid = kmalloc(6, GFP_KERNEL);
> + hif_drv->usr_conn_req.bssid = kmemdup(conn_attr->bssid, 6,
> +   GFP_KERNEL);
>   if (!hif_drv->usr_conn_req.bssid) {
>   result = -ENOMEM;
>   goto error;
>   }
> - memcpy(hif_drv->usr_conn_req.bssid, conn_attr->bssid, 6);
>   }
>  
>   hif_drv->usr_conn_req.ssid_len = conn_attr->ssid_len;
>   if (conn_attr->ssid) {
> - hif_drv->usr_conn_req.ssid = kmalloc(conn_attr->ssid_len + 1,
> + hif_drv->usr_conn_req.ssid = kmemdup(conn_attr->ssid,
> +  conn_attr->ssid_len + 1,
>GFP_KERNEL);
>   if (!hif_drv->usr_conn_req.ssid) {
>   result = -ENOMEM;
>   goto error;
>   }
> - memcpy(hif_drv->usr_conn_req.ssid,
> -conn_attr->ssid,
> -conn_attr->ssid_len);
>   hif_drv->usr_conn_req.ssid[conn_attr->ssid_len] = '\0';
>   }
>  
>   hif_drv->usr_conn_req.ies_len = conn_attr->ies_len;
>   if (conn_attr->ies) {

and these:
> - hif_drv->usr_conn_req.ies = kmalloc(conn_attr->ies_len,
> + hif_drv->usr_conn_req.ies = kmemdup(conn_attr->ies,
> + conn_attr->ies_len,
>   GFP_KERNEL);

were already done in [1]. I don't know which was the first...

[1] https://patchwork.kernel.org/patch/10308575/

>   if (!hif_drv->usr_conn_req.ies) {
>   result = -ENOMEM;
>   goto error;
>   }
> - memcpy(hif_drv->usr_conn_req.ies,
> -conn_attr->ies,
> -conn_attr->ies_len);
>   }
>  
>   hif_drv->usr_conn_req.security = conn_attr->security;
> @@ -1009,9 +1009,12 @@ static s32 handle_connect(struct wilc_vif *vif,
>  
>   if (memcmp("DIRECT-", conn_attr->ssid, 7)) {
>   info_element_size = hif_drv->usr_conn_req.ies_len;
> - info_element = kmalloc(info_element_size, GFP_KERNEL);
> - memcpy(info_element, hif_drv->usr_conn_req.ies,
> -info_element_size);
> + info_element = kmemdup(hif_drv->usr_conn_req.ies,
> +info_element_size, GFP_KERNEL);
> + if (!info_element) {
> + result = -ENOMEM;
> + goto error;
> + }
>   }
>   wid_list[wid_cnt].id = (u16)WID_11I_MODE;
>   wid_list[wid_cnt].type = WID_CHAR;
> @@ -1039,9 +1042,13 @@ static s32 handle_connect(struct wilc_vif *vif,
>   if (memcmp("DIRECT-", conn_attr->ssid, 7)) {
>   join_req_size = wid_list[wid_cnt].size;
>   join_req = kmalloc(join_req_size, GFP_KERNEL);
> + if (!join_req) {
> + result = -ENOMEM;
> + goto error;
> + }
>   }
>   if (!wid_list[wid_cnt].val) {
> - result = -EFAULT;
> + result = -ENOMEM;
>   goto error;
>   }
>  
> @@ -1166,11 +1173,13 @@ static s32 handle_connect(struct wilc_vif *vif,
>  
>   if (conn_attr->ies) {
>   conn_info.req_ies_len = conn_attr->ies_len;
> - conn_info.req_ies = kmalloc(conn_attr->ies_len,
> +

[RFC 1/4] mac80211: Add NoAck policy functionality offload infrastructure

[Vasanthakumar Thiagarajan]

Add infrastructure for drivers to implement NoAck policy functionlity.
Driver like ath10k does not use the per-packet TID NoAck policy
configuration.  Instead NoAck map is sent to the firmware/hardware
in control path. Firmware takes care of setting up QOS header and
hw with NoAck policy based on the TID NoAck map.

Drivers having this support should advertise it through a new hw_flag,
IEEE80211_HW_SUPPORTS_NOACK_POLICY, and must implement callback
set_noack_tid_bitmap(). Supporting drivers would receive TID NoAck map
through set_noack_tid_bitmap() instead of receiving as part of every
tx skb.

Signed-off-by: Vasanthakumar Thiagarajan 
---
 include/net/mac80211.h| 15 +++
 net/mac80211/cfg.c| 10 --
 net/mac80211/debugfs.c|  1 +
 net/mac80211/driver-ops.h | 21 +
 net/mac80211/iface.c  |  4 
 net/mac80211/main.c   |  4 
 net/mac80211/trace.h  | 25 +
 net/mac80211/tx.c |  3 ++-
 net/mac80211/wme.c|  3 ++-
 9 files changed, 82 insertions(+), 4 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d39fd68..5a49c90 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2081,6 +2081,13 @@ struct ieee80211_txq {
  * the frame, as it is not synced with the AP/P2P GO yet, and thus the
  * deauthentication frame might not be transmitted.
  *
+ * @IEEE80211_HW_SUPPORTS_NOACK_POLICY: Hardware (or driver) manages noack
+ * policy handling. Hardware (or driver) takes care of setting
+ * noack policy in the qos header and does not wait for the ack based
+ * on the noack TID map. Driver advertising this support must implement
+ * callback @set_noack_tid_bitmap to receive the user configured noack TID
+ * bitmap.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -2125,6 +2132,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SUPPORTS_TX_FRAG,
IEEE80211_HW_SUPPORTS_TDLS_BUFFER_STA,
IEEE80211_HW_DEAUTH_NEED_MGD_TX_PREP,
+   IEEE80211_HW_SUPPORTS_NOACK_POLICY,
 
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
@@ -3490,6 +3498,10 @@ enum ieee80211_reconfig_type {
  * @del_nan_func: Remove a NAN function. The driver must call
  * ieee80211_nan_func_terminated() with
  * NL80211_NAN_FUNC_TERM_REASON_USER_REQUEST reason code upon removal.
+ *
+ * @set_noack_tid_bitmap: Set NoAck policy TID bitmap for a virtual interface.
+ * Drivers advertising NoAck policy handing support
+ * (%IEEE80211_HW_SUPPORTS_NOACK_POLICY) must implement this callback.
  */
 struct ieee80211_ops {
void (*tx)(struct ieee80211_hw *hw,
@@ -3771,6 +3783,9 @@ struct ieee80211_ops {
void (*del_nan_func)(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
u8 instance_id);
+
+   int (*set_noack_tid_bitmap)(struct ieee80211_hw *hw,
+   struct ieee80211_vif *vif, u8 noack_map);
 };
 
 /**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 5c4b105..a2f0eae 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -347,9 +347,15 @@ static int ieee80211_set_noack_map(struct wiphy *wiphy,
 
sdata->noack_map = noack_map;
 
-   ieee80211_check_fast_xmit_iface(sdata);
+   if (!ieee80211_hw_check(>local->hw, SUPPORTS_NOACK_POLICY)) {
+   ieee80211_check_fast_xmit_iface(sdata);
+   return 0;
+   }
 
-   return 0;
+   if (!ieee80211_sdata_running(sdata))
+   return 0;
+
+   return drv_set_noack_tid_bitmap(sdata->local, sdata, noack_map);
 }
 
 static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index a75653a..b6e6243 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -213,6 +213,7 @@ static ssize_t reset_write(struct file *file, const char 
__user *user_buf,
FLAG(SUPPORTS_TX_FRAG),
FLAG(SUPPORTS_TDLS_BUFFER_STA),
FLAG(DEAUTH_NEED_MGD_TX_PREP),
+   FLAG(SUPPORTS_NOACK_POLICY),
 #undef FLAG
 };
 
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 4d82fe7..a0a2d3c 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -1250,4 +1250,25 @@ static inline void drv_del_nan_func(struct 
ieee80211_local *local,
trace_drv_return_void(local);
 }
 
+static inline int drv_set_noack_tid_bitmap(struct ieee80211_local *local,
+  struct ieee80211_sub_if_data *sdata,
+  u16 noack_map)
+{
+   int ret;
+
+   might_sleep();
+   if (!check_sdata_in_driver(sdata))
+   return -EIO;
+
+   if (!local->ops->set_noack_tid_bitmap)
+   return -EOPNOTSUPP;
+
+   trace_drv_set_noack_tid_bitmap(local, 

[RFC 3/4] mac80211: Apply per-peer NoAck tid bitmap configuration

[Vasanthakumar Thiagarajan]

Use per-peer noack tid bitmap, if it is configured,
when setting up the qos header. If no per-peer configuration
is set, use the existing nedev wide noack policy configuration.
Also modifies callback set_noack_tid_bitmap() with the provision
to send per-peer NoAck policy configuration to the drivers supporting
the NoAck offload functionality (IEEE80211_HW_SUPPORTS_NOACK_POLICY).

Signed-off-by: Vasanthakumar Thiagarajan 
---
 include/net/mac80211.h|  7 +--
 net/mac80211/cfg.c| 42 +-
 net/mac80211/driver-ops.h |  5 +++--
 net/mac80211/iface.c  |  2 +-
 net/mac80211/sta_info.h   |  3 +++
 net/mac80211/trace.h  |  9 ++---
 net/mac80211/tx.c |  2 +-
 net/mac80211/wme.c| 34 +-
 8 files changed, 89 insertions(+), 15 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 5a49c90..a5ed552 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -3499,7 +3499,9 @@ enum ieee80211_reconfig_type {
  * ieee80211_nan_func_terminated() with
  * NL80211_NAN_FUNC_TERM_REASON_USER_REQUEST reason code upon removal.
  *
- * @set_noack_tid_bitmap: Set NoAck policy TID bitmap for a virtual interface.
+ * @set_noack_tid_bitmap: Set NoAck policy TID bitmap. Apply the TID NoAck
+ * configuration for a particular station when @sta is non-NULL. When @sta
+ * is NULL, apply TID NoAck configuration at virtual interface level.
  * Drivers advertising NoAck policy handing support
  * (%IEEE80211_HW_SUPPORTS_NOACK_POLICY) must implement this callback.
  */
@@ -3785,7 +3787,8 @@ struct ieee80211_ops {
u8 instance_id);
 
int (*set_noack_tid_bitmap)(struct ieee80211_hw *hw,
-   struct ieee80211_vif *vif, u8 noack_map);
+   struct ieee80211_vif *vif,
+   struct ieee80211_sta *sta, u8 noack_map);
 };
 
 /**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 621ef38..1efc9cf 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -345,18 +345,50 @@ static int ieee80211_set_noack_map(struct wiphy *wiphy,
  u16 noack_map)
 {
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+   struct sta_info *sta;
+   int ret;
 
-   sdata->noack_map = noack_map;
+   if (!peer) {
+   sdata->noack_map = noack_map;
 
-   if (!ieee80211_hw_check(>local->hw, SUPPORTS_NOACK_POLICY)) {
-   ieee80211_check_fast_xmit_iface(sdata);
-   return 0;
+   if (!ieee80211_hw_check(>local->hw, 
SUPPORTS_NOACK_POLICY)) {
+   ieee80211_check_fast_xmit_iface(sdata);
+   return 0;
+   }
+
+   if (!ieee80211_sdata_running(sdata))
+   return 0;
+
+   return drv_set_noack_tid_bitmap(sdata->local, sdata, NULL,
+   noack_map);
}
 
+   /* NoAck policy is for a connected client on the dev */
+
if (!ieee80211_sdata_running(sdata))
+   return -ENETDOWN;
+
+   mutex_lock(>local->sta_mtx);
+
+   sta = sta_info_get_bss(sdata, peer);
+   if (!sta) {
+   mutex_unlock(>local->sta_mtx);
+   return -ENOENT;
+   }
+
+   sta->noack_map = noack_map;
+
+   if (!ieee80211_hw_check(>local->hw, SUPPORTS_NOACK_POLICY)) {
+   ieee80211_check_fast_xmit(sta);
+   mutex_unlock(>local->sta_mtx);
return 0;
+   }
+
+   ret = drv_set_noack_tid_bitmap(sdata->local, sdata, sta, noack_map);
 
-   return drv_set_noack_tid_bitmap(sdata->local, sdata, noack_map);
+   mutex_unlock(>local->sta_mtx);
+
+   return ret;
 }
 
 static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index a0a2d3c..8a2154a 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -1252,6 +1252,7 @@ static inline void drv_del_nan_func(struct 
ieee80211_local *local,
 
 static inline int drv_set_noack_tid_bitmap(struct ieee80211_local *local,
   struct ieee80211_sub_if_data *sdata,
+  struct sta_info *sta,
   u16 noack_map)
 {
int ret;
@@ -1263,9 +1264,9 @@ static inline int drv_set_noack_tid_bitmap(struct 
ieee80211_local *local,
if (!local->ops->set_noack_tid_bitmap)
return -EOPNOTSUPP;
 
-   trace_drv_set_noack_tid_bitmap(local, sdata, noack_map);
+   trace_drv_set_noack_tid_bitmap(local, sdata, >sta, noack_map);
ret = local->ops->set_noack_tid_bitmap(>hw, >vif,
-  noack_map);
+  

Re: [v2] rsi: Remove stack VLA usage

[Kalle Valo]

"Tobin C. Harding"  wrote:

> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> (kernel Oops) or a security flaw (overwriting memory beyond the
> stack). Also, in general, as code evolves it is easy to lose track of
> how big a VLA can get. Thus, we can end up having runtime failures
> that are hard to debug. As part of the directive[1] to remove all VLAs
> from the kernel, and build with -Wvla.
> 
> Currently rsi code uses a VLA based on a function argument to
> `rsi_sdio_load_data_master_write()`.  The function call chain is
> 
> Both these functions
> 
>   rsi_sdio_reinit_device()
>   rsi_probe()
> 
> start the call chain:
> 
>   rsi_hal_device_init()
>   rsi_load_fw()
>   auto_fw_upgrade()
>   ping_pong_write()
>   rsi_sdio_load_data_master_write()
> 
> [Without familiarity with the code] it appears that none of the 4 locks
> 
>   mutex
>   rx_mutex
>   tx_mutex
>   tx_bus_mutex
> 
> are held when `rsi_sdio_load_data_master_write()` is called.  It is therefore
> safe to use kmalloc with GFP_KERNEL.
> 
> We can avoid using the VLA by using `kmalloc()` and free'ing the memory on all
> exit paths.
> 
> Change buffer from 'u8 array' to 'u8 *'.  Call `kmalloc()` to allocate memory 
> for
> the buffer.  Using goto statement to call `kfree()` on all return paths.
> 
> It can be expected that this patch will result in a small increase in overhead
> due to the use of `kmalloc()` however this code is only called on 
> initialization
> (and re-initialization) so this overhead should not degrade performance.
> 
> [1] https://lkml.org/lkml/2018/3/7/621
> 
> Signed-off-by: Tobin C. Harding 

Patch applied to wireless-drivers-next.git, thanks.

44f98a9332e4 rsi: Remove stack VLA usage

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

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

Re: mwifiex: remove warnings in mwifiex_cmd_append_11n_tlv()

[Kalle Valo]

Ganapathi Bhat  wrote:

> Fix the following sparse warning in mwifiex_cmd_append_11n_tlv:
> 
> drivers/net/wireless/marvell/mwifiex/11n.c:358:65: warning: invalid 
> assignment: &=
> drivers/net/wireless/marvell/mwifiex/11n.c:358:65:left side has type 
> restricted __le16
> drivers/net/wireless/marvell/mwifiex/11n.c:358:65:right side has type int
> drivers/net/wireless/marvell/mwifiex/11n.c:360:65: warning: invalid 
> assignment: &=
> drivers/net/wireless/marvell/mwifiex/11n.c:360:65:left side has type 
> restricted __le16
> drivers/net/wireless/marvell/mwifiex/11n.c:360:65:right side has type int
> drivers/net/wireless/marvell/mwifiex/11n.c:366:65: warning: invalid 
> assignment: &=
> drivers/net/wireless/marvell/mwifiex/11n.c:366:65:left side has type 
> restricted __le16
> drivers/net/wireless/marvell/mwifiex/11n.c:366:65:right side has type int
> drivers/net/wireless/marvell/mwifiex/11n.c:368:65: warning: invalid 
> assignment: &=
> drivers/net/wireless/marvell/mwifiex/11n.c:368:65:left side has type 
> restricted __le16
> drivers/net/wireless/marvell/mwifiex/11n.c:368:65:right side has type int
> 
> Fixes: 77423fa73927 ("mwifiex: fix incorrect ht capability problem")
> Signed-off-by: Ganapathi Bhat 

Patch applied to wireless-drivers-next.git, thanks.

6c20495b7deb mwifiex: remove warnings in mwifiex_cmd_append_11n_tlv()

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

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

Re: [PATCH v7 00/11] EAPoL over NL80211

[Arend van Spriel]

On 3/26/2018 7:52 PM, Denis Kenzior wrote:

The proposed patchset has been tested in a mac80211_hwsim based environment with
hostapd and iwd.


Hi Denis,

Looking pretty good. Do you also have hostapd and iwd patches available 
somewhere. I would like to see if I can get brcmfmac using it.


Regards,
Arend

Re: [2/4] wireless: Use octal not symbolic permissions

[Kalle Valo]

Joe Perches  wrote:

> Prefer the direct use of octal for permissions.
> 
> Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace
> and some typing.
> 
> Miscellanea:
> 
> o Whitespace neatening around these conversions.
> 
> Signed-off-by: Joe Perches 

Patch applied to wireless-drivers-next.git, thanks.

2ef00c53049b wireless: Use octal not symbolic permissions

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

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

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

[Mathias Kresin]

26.03.2018 12:35, Stanislaw Gruszka:

Hi Mathias


sorry for the delayed testing. I had to create a new test setup
first, fought with buggy hardware and was busy with other stuff.


Thanks for doing it.


The two attached patches are causing a performance regression for me again:

OpenWrt head (forced HT40, 100Mbit wired interface)

wireless (iperf client) to wired (iperf server)
   Interval   Transfer Bitrate Retr
 0.00-60.00  sec   584 MBytes  81.6 Mbits/sec  666   sender
 0.00-60.00  sec   584 MBytes  81.6 Mbits/secreceiver

wired (iperf client) to wireless (iperf server)
   Interval   Transfer Bitrate Retr
 0.00-60.00  sec   620 MBytes  86.7 Mbits/sec   33   sender
 0.00-60.00  sec   617 MBytes  86.2 Mbits/secreceiver



OpenWrt head (forced HT40, 100Mbit wired interface)
   + rt2800_change_rx_ampdu_factor.patch
   + rt2800_change_ba_size.patch

wireless (iperf client) to wired (iperf server)
   Interval   Transfer Bitrate Retr
 0.00-60.00  sec   356 MBytes  49.8 Mbits/sec6   sender
 0.00-60.00  sec   356 MBytes  49.7 Mbits/secreceiver

wired (iperf client) to wireless (iperf server)
   Interval   Transfer Bitrate Retr
 0.00-60.00  sec   627 MBytes  87.7 Mbits/sec5   sender
 0.00-60.00  sec   626 MBytes  87.5 Mbits/secreceiver


Due to the regression I haven't tested your ampdu_density patch so
far. Let me hear if you want to see more tests done.


Could you test just RX AMPDU patches, i.e.

rt2800_change_rx_ampdu_factor.patch
rt2800_change_rx_ampdu_density.patch

I have somewhat positive results on RX performance on some devices
with those. Perhaps you could confirm that :-)


This time I've done the test with HT20 only, to not annoy my neighbours.

The test setup is the following:

ath9k (STA) <=> (AP) o2 Box 6431 (RJ45) <=> desktop

With the patches applied the bandwidth is somewhat around 10 MBit/sec 
lower. Even if I was able to reliable reproduce it, I'm not sure if it 
is within the measuring tolerance.



OpenWrt head

  mkresin@desktop ~ $ iperf3 -c 192.168.1.156
  Connecting to host 192.168.1.156, port 5201
  Interval   Transfer Bandwidth   Retr
0.00-10.00  sec  89.5 MBytes  75.0 Mbits/sec1   sender
0.00-10.00  sec  88.2 MBytes  74.0 Mbits/secreceiver

  mkresin@desktop ~ $ iperf3 -c 192.168.1.156 -R
  Connecting to host 192.168.1.156, port 5201
  Reverse mode, remote host 192.168.1.156 is sending
  Interval   Transfer Bandwidth   Retr
0.00-10.00  sec  70.8 MBytes  59.4 Mbits/sec0   sender
0.00-10.00  sec  70.5 MBytes  59.1 Mbits/secreceiver

OpenWrt head
 + rt2800_change_rx_ampdu_factor.patch
 + rt2800_change_rx_ampdu_density.patch

mkresin@desktop ~ $ iperf3 -c 192.168.1.156
  Connecting to host 192.168.1.156, port 5201
  Interval   Transfer Bandwidth   Retr
0.00-10.00  sec  78.2 MBytes  65.6 Mbits/sec0   sender
0.00-10.00  sec  77.1 MBytes  64.7 Mbits/secreceiver

mkresin@desktop ~ $ iperf3 -c 192.168.1.156 -R
  Connecting to host 192.168.1.156, port 5201
  Reverse mode, remote host 192.168.1.156 is sending
  Interval   Transfer Bandwidth   Retr
0.00-10.00  sec  51.8 MBytes  43.5 Mbits/sec1   sender
0.00-10.00  sec  51.7 MBytes  43.3 Mbits/secreceiver

Mathias

Re: [PATCH 12/15] rtlwifi: btcoex: Add 8822b 1ant/2ant coex files

[Kalle Valo]

 writes:

> From: Ping-Ke Shih 
>
> There are two or three physical antenna in 8822be WiFi modules, so btcoex
> introduce two coex files to handle these two cases.
>
> Signed-off-by: Ping-Ke Shih 
> ---
>  .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.c| 5327 +++
>  .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.h|  413 ++
>  .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.c| 5370 
> 
>  .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.h|  434 ++
>  4 files changed, 11544 insertions(+)

Huge patches like this are pain to review. I'm going to split this into
two sets, patches 1-11 and patches 12-15.

> +/* 
> + * Description:
> + *
> + * This file is for RTL8822B Co-exist mechanism
> + *
> + * History
> + * 2012/11/15 Cosa first check in.

The history feels useless to me.

> + *
> + * */
> +
> +/* 
> + * include files
> + * */
> +/*only for rf4ce*/
> +#include "halbt_precomp.h"
> +
> +/* 
> + * Global variables, these are static variables
> + * */

Also extensive use of "**" lines is not really upstream style.

> +static struct coex_dm_8822b_1ant glcoex_dm_8822b_1ant;
> +static struct coex_dm_8822b_1ant *coex_dm = _dm_8822b_1ant;
> +static struct coex_sta_8822b_1antglcoex_sta_8822b_1ant;
> +static struct coex_sta_8822b_1ant*coex_sta = _sta_8822b_1ant;
> +static struct rfe_type_8822b_1antgl_rfe_type_8822b_1ant;
> +static struct rfe_type_8822b_1ant*rfe_type = _rfe_type_8822b_1ant;
> +
> +static const char *const glbt_info_src_8822b_1ant[] = {
> + "BT Info[wifi fw]",
> + "BT Info[bt rsp]",
> + "BT Info[bt auto report]",
> +};
> +
> +static u32 glcoex_ver_date_8822b_1ant = 20180112;
> +static u32 glcoex_ver_8822b_1ant = 0x59;
> +static u32 glcoex_ver_btdesired_8822b_1ant = 0x56;

Having static variables like this means that this will not work if there
are two or more device per host, right? IIRC we discussed this before,
so what's the plan to solve that? 

In upstream drivers there should not be artificial limitations like one
device per host. Is that even checked anywhere or will it just be buggy
if there are more than one device?

-- 
Kalle Valo

Re: [PATCH 00/11] staging: wilc1000: fix for checkpatch and handled malloc memory properly

[Ajay Singh]

Please let me know, in case I have to rework and resubmit this patch
series to make them into staging branch.

Regards,
Ajay

Re: [v3] Bluetooth: btrsi: rework dependencies

[Kalle Valo]

Arnd Bergmann  wrote:

> The linkage between the bluetooth driver and the wireless
> driver is not defined properly, leading to build problems
> such as:
> 
> warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies 
> (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X)
> drivers/net/wireless/rsi/rsi_91x_main.o: In function `rsi_read_pkt':
> (.text+0x205): undefined reference to `rsi_bt_ops'
> 
> As the dependency is actually the reverse (RSI_91X uses
> the BT_RSI driver, not the other way round), this changes
> the dependency to match, and enables the bluetooth driver
> from the RSI_COEX symbol.
> 
> Fixes: 38aa4da50483 ("Bluetooth: btrsi: add new rsi bluetooth driver")
> Acked-by; Marcel Holtmann 
> Signed-off-by: Arnd Bergmann 

Patch applied to wireless-drivers-next.git, thanks.

255dd5b79d54 Bluetooth: btrsi: rework dependencies

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

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

[RFC 1/3] cfg80211: fix data type of sta_opmode_info parameter

[Tamizh chelvam]

Currently bw and smps_mode are u8 type value in sta_opmode_info
structure. This values filled in mac80211 from ieee80211_sta_rx_bandwidth
and ieee80211_smps_mode. These enum values are specific to mac80211 and
userspace/cfg80211 doesn't know about that. This will lead to incorrect
result/assumption by the user space application.
Change bw and smps_mode parameters to their respective enums in nl80211.

Signed-off-by: Tamizh chelvam 
---
 include/net/cfg80211.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index fc40843..4341508 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3572,15 +3572,15 @@ enum wiphy_opmode_flag {
 /**
  * struct sta_opmode_info - Station's ht/vht operation mode information
  * @changed: contains value from  wiphy_opmode_flag
- * @smps_mode: New SMPS mode of a station
- * @bw: new max bandwidth value of a station
+ * @smps_mode: New SMPS mode value from  nl80211_smps_mode of a station
+ * @bw: new max bandwidth value from  nl80211_chan_width of a station
  * @rx_nss: new rx_nss value of a station
  */
 
 struct sta_opmode_info {
u32 changed;
-   u8 smps_mode;
-   u8 bw;
+   enum nl80211_smps_mode smps_mode;
+   enum nl80211_chan_width bw;
u8 rx_nss;
 };
 
-- 
1.9.1

[RFC 2/3] mac80211: Use proper smps_mode enum in sta opmode event

[Tamizh chelvam]

SMPS_MODE change value notified via nl80211 contains mac80211
specific value(ieee80211_smps_mode) and user space application
will not know those values. This patch add support to map
the mac80211 enum value to nl80211_smps_mode which will be
understood by the userspace application.

Signed-off-by: Tamizh chelvam 
---
 net/mac80211/ht.c  | 15 +++
 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/rx.c  |  3 ++-
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index d752353..c78036a 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -466,6 +466,21 @@ void ieee80211_process_delba(struct ieee80211_sub_if_data 
*sdata,
__ieee80211_stop_tx_ba_session(sta, tid, AGG_STOP_PEER_REQUEST);
 }
 
+enum nl80211_smps_mode
+ieee80211_smps_mode_to_smps_mode(enum ieee80211_smps_mode smps)
+{
+   switch (smps) {
+   case IEEE80211_SMPS_OFF:
+   return NL80211_SMPS_OFF;
+   case IEEE80211_SMPS_STATIC:
+   return NL80211_SMPS_STATIC;
+   case IEEE80211_SMPS_DYNAMIC:
+   return NL80211_SMPS_DYNAMIC;
+   default:
+   return NL80211_SMPS_OFF;
+   }
+}
+
 int ieee80211_send_smps_action(struct ieee80211_sub_if_data *sdata,
   enum ieee80211_smps_mode smps, const u8 *da,
   const u8 *bssid)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index ae9c33c..9237ffb 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1788,6 +1788,8 @@ void ieee80211_stop_tx_ba_cb(struct sta_info *sta, int 
tid,
 void ieee80211_release_reorder_timeout(struct sta_info *sta, int tid);
 
 u8 ieee80211_mcs_to_chains(const struct ieee80211_mcs_info *mcs);
+enum nl80211_smps_mode
+ieee80211_smps_mode_to_smps_mode(enum ieee80211_smps_mode smps);
 
 /* VHT */
 void
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 27bb1f0..f8c69ac 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2883,7 +2883,8 @@ static void ieee80211_process_sa_query_req(struct 
ieee80211_sub_if_data *sdata,
if (rx->sta->sta.smps_mode == smps_mode)
goto handled;
rx->sta->sta.smps_mode = smps_mode;
-   sta_opmode.smps_mode = smps_mode;
+   sta_opmode.smps_mode =
+   ieee80211_smps_mode_to_smps_mode(smps_mode);
sta_opmode.changed = STA_OPMODE_SMPS_MODE_CHANGED;
 
sband = rx->local->hw.wiphy->bands[status->band];
-- 
1.9.1

[RFC 0/3] cfg80211/mac80211: Notify proper sta opmode change value

[Tamizh chelvam]

Currently bw and smps_mode are u8 type value in sta_opmode_info
structure. This values filled in mac80211 from ieee80211_sta_rx_bandwidth
and ieee80211_smps_mode. These enum values are specific to mac80211 and
userspace/cfg80211 doesn't know about that. This patchset change its
data type in the sta_opmode_info structure and mapping from mac80211
specific enum to nl80211 enum value.

Tamizh chelvam (3):
  cfg80211: fix data type of sta_opmode_info parameter
  mac80211: Use proper smps_mode enum in sta opmode event
  mac80211: Use proper chan_width enum in sta opmode event

Note :
  * Is this mac80211 approach sufficient ? or whether some more
complete cleanup would be preferred ?

 include/net/cfg80211.h |  8 
 net/mac80211/ht.c  | 15 +++
 net/mac80211/ieee80211_i.h |  4 
 net/mac80211/rx.c  |  6 --
 net/mac80211/vht.c | 32 +++-
 5 files changed, 58 insertions(+), 7 deletions(-)

-- 
1.9.1

[RFC 3/3] mac80211: Use proper chan_width enum in sta opmode event

[Tamizh chelvam]

Bandwidth change value reported via nl80211 contains mac80211
specific enum value(ieee80211_sta_rx_bw) and which is not
understand by userspace application. Map the mac80211 specific
value to nl80211_chan_width enum value to avoid using wrong value
in the userspace application. And used station's ht/vht capability
to map IEEE80211_STA_RX_BW_20 and IEEE80211_STA_RX_BW_160 with
proper nl80211 value.

Signed-off-by: Tamizh chelvam 
---
 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/rx.c  |  3 ++-
 net/mac80211/vht.c | 32 +++-
 3 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 9237ffb..6c341d8 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1816,6 +1816,8 @@ void ieee80211_apply_vhtcap_overrides(struct 
ieee80211_sub_if_data *sdata,
  struct ieee80211_sta_vht_cap *vht_cap);
 void ieee80211_get_vht_mask_from_cap(__le16 vht_cap,
 u16 vht_mask[NL80211_VHT_NSS_MAX]);
+enum nl80211_chan_width
+ieee80211_sta_rx_bw_to_chan_width(struct sta_info *sta);
 
 /* Spectrum management */
 void ieee80211_process_measurement_req(struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index f8c69ac..3a9f0c0 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2922,7 +2922,8 @@ static void ieee80211_process_sa_query_req(struct 
ieee80211_sub_if_data *sdata,
 
rx->sta->sta.bandwidth = new_bw;
sband = rx->local->hw.wiphy->bands[status->band];
-   sta_opmode.bw = new_bw;
+   sta_opmode.bw =
+   ieee80211_sta_rx_bw_to_chan_width(rx->sta);
sta_opmode.changed = STA_OPMODE_MAX_BW_CHANGED;
 
rate_control_rate_update(local, sband, rx->sta,
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index 5714dee..259325c 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -358,6 +358,36 @@ enum nl80211_chan_width ieee80211_sta_cap_chan_bw(struct 
sta_info *sta)
return NL80211_CHAN_WIDTH_80;
 }
 
+enum nl80211_chan_width
+ieee80211_sta_rx_bw_to_chan_width(struct sta_info *sta)
+{
+   enum ieee80211_sta_rx_bandwidth cur_bw = sta->sta.bandwidth;
+   struct ieee80211_sta_vht_cap *vht_cap = >sta.vht_cap;
+   u32 cap_width;
+
+   switch (cur_bw) {
+   case IEEE80211_STA_RX_BW_20:
+   if (!sta->sta.ht_cap.ht_supported)
+   return NL80211_CHAN_WIDTH_20_NOHT;
+   else
+   return NL80211_CHAN_WIDTH_20;
+   case IEEE80211_STA_RX_BW_40:
+   return NL80211_CHAN_WIDTH_40;
+   case IEEE80211_STA_RX_BW_80:
+   return NL80211_CHAN_WIDTH_80;
+   case IEEE80211_STA_RX_BW_160:
+   cap_width =
+   vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
+
+   if (cap_width == IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ)
+   return NL80211_CHAN_WIDTH_160;
+
+   return NL80211_CHAN_WIDTH_80P80;
+   default:
+   return NL80211_CHAN_WIDTH_20;
+   }
+}
+
 enum ieee80211_sta_rx_bandwidth
 ieee80211_chan_width_to_rx_bw(enum nl80211_chan_width width)
 {
@@ -484,7 +514,7 @@ u32 __ieee80211_vht_handle_opmode(struct 
ieee80211_sub_if_data *sdata,
new_bw = ieee80211_sta_cur_vht_bw(sta);
if (new_bw != sta->sta.bandwidth) {
sta->sta.bandwidth = new_bw;
-   sta_opmode.bw = new_bw;
+   sta_opmode.bw = ieee80211_sta_rx_bw_to_chan_width(sta);
changed |= IEEE80211_RC_BW_CHANGED;
sta_opmode.changed |= STA_OPMODE_MAX_BW_CHANGED;
}
-- 
1.9.1

Re: [PATCHv2] ath10k: fix kernel panic while reading tpc_stats

[Tamizh chelvam]

On 2018-03-26 21:19, Kalle Valo wrote:

Tamizh chelvam  writes:


When attempt to read tpc_stats for the chipsets which support
more than 3 tx chain will trigger kernel panic(kernel stack is 
corrupted)

due to writing values on rate_code array out of range.
This patch changes the array size depends on the WMI_TPC_TX_N_CHAIN 
and

added check to avoid write values on the array if the num tx chain
get in tpc config event is greater than WMI_TPC_TX_N_CHAIN.

Tested on QCA9984 with firmware-5.bin_10.4-3.5.3-00057

Kernel panic log :

[  323.510944] Kernel panic - not syncing: stack-protector: Kernel 
stack is corrupted in: bf90c654

[  323.510944]
[  323.524390] CPU: 0 PID: 1908 Comm: cat Not tainted 3.14.77 #31
[  323.530224] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[  323.537941] [] (show_stack) from [] 
(dump_stack+0x80/0xa0)
[  323.545146] [] (dump_stack) from [] 
(panic+0x84/0x1e4)
[  323.552000] [] (panic) from [] 
(__stack_chk_fail+0x10/0x14)
[  323.559350] [] (__stack_chk_fail) from [] 
(ath10k_wmi_event_pdev_tpc_config+0x424/0x438 [ath10k_core])
[  323.570471] [] (ath10k_wmi_event_pdev_tpc_config 
[ath10k_core]) from [] (ath10k_wmi_10_4_op_rx+0x2f0/0x39c 
[ath10k_core])
[  323.583047] [] (ath10k_wmi_10_4_op_rx [ath10k_core]) from 
[] (ath10k_htc_rx_completion_handler+0x170/0x1a0 
[ath10k_core])
[  323.595702] [] (ath10k_htc_rx_completion_handler 
[ath10k_core]) from [] 
(ath10k_pci_hif_send_complete_check+0x1f0/0x220 [ath10k_pci])
[  323.609421] [] (ath10k_pci_hif_send_complete_check 
[ath10k_pci]) from [] 
(ath10k_ce_per_engine_service+0x74/0xc4 [ath10k_pci])
[  323.622490] [] (ath10k_ce_per_engine_service 
[ath10k_pci]) from [] 
(ath10k_ce_per_engine_service_any+0x74/0x80 [ath10k_pci])
[  323.635423] [] (ath10k_ce_per_engine_service_any 
[ath10k_pci]) from [] (ath10k_pci_napi_poll+0x44/0xe8 
[ath10k_pci])
[  323.647665] [] (ath10k_pci_napi_poll [ath10k_pci]) from 
[] (net_rx_action+0xac/0x160)
[  323.657208] [] (net_rx_action) from [] 
(__do_softirq+0x104/0x294)
[  323.665017] [] (__do_softirq) from [] 
(irq_exit+0x9c/0x11c)
[  323.672314] [] (irq_exit) from [] 
(handle_IRQ+0x6c/0x90)
[  323.679341] [] (handle_IRQ) from [] 
(gic_handle_irq+0x3c/0x60)
[  323.686893] [] (gic_handle_irq) from [] 
(__irq_svc+0x40/0x70)

[  323.694349] Exception stack(0xdd489c58 to 0xdd489ca0)
[  323.699384] 9c40:   
 a013
[  323.707547] 9c60:  dc4bce40 6013 ddc1d800 dd488000 
0990  c085c800
[  323.715707] 9c80:  dd489d44 092d dd489ca0 c026e664 
c026e668 6013 
[  323.723877] [] (__irq_svc) from [] 
(rcu_note_context_switch+0x170/0x184)
[  323.732298] [] (rcu_note_context_switch) from 
[] (__schedule+0x50/0x4d4)
[  323.740716] [] (__schedule) from [] 
(schedule_timeout+0x148/0x178)
[  323.748611] [] (schedule_timeout) from [] 
(wait_for_common+0x114/0x154)
[  323.756972] [] (wait_for_common) from [] 
(ath10k_tpc_stats_open+0xc8/0x340 [ath10k_core])
[  323.766873] [] (ath10k_tpc_stats_open [ath10k_core]) from 
[] (do_dentry_open+0x1ac/0x274)
[  323.776741] [] (do_dentry_open) from [] 
(do_last+0x8c0/0xb08)
[  323.784201] [] (do_last) from [] 
(path_openat+0x210/0x598)
[  323.791408] [] (path_openat) from [] 
(do_filp_open+0x2c/0x78)
[  323.798873] [] (do_filp_open) from [] 
(do_sys_open+0x114/0x1b4)
[  323.806509] [] (do_sys_open) from [] 
(ret_fast_syscall+0x0/0x44)

[  323.814241] CPU1: stopping
[  323.816927] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.77 #31
[  323.823008] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[  323.830731] [] (show_stack) from [] 
(dump_stack+0x80/0xa0)
[  323.837934] [] (dump_stack) from [] 
(handle_IPI+0xb8/0x140)
[  323.845224] [] (handle_IPI) from [] 
(gic_handle_irq+0x58/0x60)
[  323.852774] [] (gic_handle_irq) from [] 
(__irq_svc+0x40/0x70)

[  323.860233] Exception stack(0xdd499fa0 to 0xdd499fe8)
[  323.865273] 9fa0: ffed  1d3c9000  dd498000 
dd498030 10c0387d c08b62c8
[  323.873432] 9fc0: 4220406a 512f04d0   0001 
dd499fe8 c021838c c0218390

[  323.881588] 9fe0: 6013 
[  323.885070] [] (__irq_svc) from [] 
(arch_cpu_idle+0x30/0x50)
[  323.892454] [] (arch_cpu_idle) from [] 
(cpu_startup_entry+0xa4/0x108)
[  323.900690] [] (cpu_startup_entry) from [<422085a4>] 
(0x422085a4)


Signed-off-by: Tamizh chelvam 


In v1 kbuild reported this warning:

drivers/net/wireless/ath/ath10k/wmi.c:4465:14: error: 'struct ath10k'
has no member named 'debug'

Did you fix it?


oops:( sorry, I'll send next version of the patch by fixing it.

@@ -4455,6 +4461,8 @@ void ath10k_wmi_event_pdev_tpc_config(struct 
ath10k *ar, struct sk_buff *skb)

   __le32_to_cpu(ev->twice_max_rd_power) / 2,
   __le32_to_cpu(ev->num_tx_chain),
   __le32_to_cpu(ev->rate_max));
+exit:
+   complete(>debug.tpc_complete);
 }


And why do you 

Re: [PATCH v2] ath10k: debugfs support to get final TPC stats for 10.4 variants

[Joshua Zhao]

What exactly "control power" means? Can you illustrate or give examples?
Thanks!

On Mon, Feb 26, 2018 at 9:33 PM, Maharaja Kennadyrajan
 wrote:
> On 2018-02-27 1:19 am, Joshua Zhao wrote:
>>
>> as you said:
>> The existing tpc_stats debugfs file provides the dump which is
>> minimum of target power and regulatory domain.
>> cat
>> /sys/kernel/debug/ieee80211/phyX/ath10k/tpc_stats
>>
>> I’m curious what’s exact difference w/ this new addition:
>> Export the final Transmit Power Control (TPC) value, which is
>> the minimum of control power and existing TPC value to user space via
>> a new debugfs file "tpc_stats_final" to help with debugging.
>>
>> Can you clarify or give examples on the difference?
>>
>> Thanks!
>
>
> The existing tpc_stats is the minimum of "target power and regulatory
> domain".
> The new addition is the minimum of "existing tpc_stats and control power"
> which means minimum of "control power, target power and regulatory domain".
>
> --
> Regards,
> Maha