[PATCH 08/10] rtlwifi: add efuse ops for other components

[pkshih]

From: Ping-Ke Shih 

The new component phydm need to access efuse content, so we prepare ops
for reference.

Signed-off-by: Tsang-Shian Lin 
Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/efuse.c | 13 +
 drivers/net/wireless/realtek/rtlwifi/efuse.h |  2 +-
 drivers/net/wireless/realtek/rtlwifi/pci.c   |  1 +
 drivers/net/wireless/realtek/rtlwifi/wifi.h  |  7 +++
 4 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.c 
b/drivers/net/wireless/realtek/rtlwifi/efuse.c
index 35b50be633f1..fd13d4ef53b8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/efuse.c
+++ b/drivers/net/wireless/realtek/rtlwifi/efuse.c
@@ -50,6 +50,11 @@ static const struct efuse_map RTL8712_SDIO_EFUSE_TABLE[] = {
{11, 0, 0, 28}
 };
 
+static const struct rtl_efuse_ops efuse_ops = {
+   .efuse_onebyte_read = efuse_one_byte_read,
+   .efuse_logical_map_read = efuse_shadow_read,
+};
+
 static void efuse_shadow_read_1byte(struct ieee80211_hw *hw, u16 offset,
u8 *value);
 static void efuse_shadow_read_2byte(struct ieee80211_hw *hw, u16 offset,
@@ -1364,3 +1369,11 @@ void rtl_fill_dummy(u8 *pfwbuf, u32 *pfwlen)
*pfwlen = fwlen;
 }
 EXPORT_SYMBOL_GPL(rtl_fill_dummy);
+
+void rtl_efuse_ops_init(struct ieee80211_hw *hw)
+{
+   struct rtl_priv *rtlpriv = rtl_priv(hw);
+
+   rtlpriv->efuse.efuse_ops = _ops;
+}
+EXPORT_SYMBOL_GPL(rtl_efuse_ops_init);
diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.h 
b/drivers/net/wireless/realtek/rtlwifi/efuse.h
index 952fdc288f0e..dfa31c13fc7a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/efuse.h
+++ b/drivers/net/wireless/realtek/rtlwifi/efuse.h
@@ -116,5 +116,5 @@ void rtl_fill_dummy(u8 *pfwbuf, u32 *pfwlen);
 void rtl_fw_page_write(struct ieee80211_hw *hw, u32 page, const u8 *buffer,
   u32 size);
 void rtl_fw_block_write(struct ieee80211_hw *hw, const u8 *buffer, u32 size);
-
+void rtl_efuse_ops_init(struct ieee80211_hw *hw);
 #endif
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 01ccf8884831..2437422625bf 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -2238,6 +2238,7 @@ int rtl_pci_probe(struct pci_dev *pdev,
rtlpriv->cfg = (struct rtl_hal_cfg *)(id->driver_data);
rtlpriv->intf_ops = _pci_ops;
rtlpriv->glb_var = _global_var;
+   rtl_efuse_ops_init(hw);
 
/* MEM map */
err = pci_request_regions(pdev, KBUILD_MODNAME);
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 2e9a20273a2d..0e8aae0c05c1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -1812,6 +1812,7 @@ struct rtl_dm {
 #defineEFUSE_MAX_LOGICAL_SIZE  512
 
 struct rtl_efuse {
+   const struct rtl_efuse_ops *efuse_ops;
bool autoLoad_ok;
bool bootfromefuse;
u16 max_physical_size;
@@ -1917,6 +1918,12 @@ struct rtl_efuse {
u8 channel_plan;
 };
 
+struct rtl_efuse_ops {
+   int (*efuse_onebyte_read)(struct ieee80211_hw *hw, u16 addr, u8 *data);
+   void (*efuse_logical_map_read)(struct ieee80211_hw *hw, u8 type,
+  u16 offset, u32 *value);
+};
+
 struct rtl_tx_report {
atomic_t sn;
u16 last_sent_sn;
-- 
2.15.1

[PATCH 05/10] rtlwifi: Add rate section and its related definition and comment

[pkshih]

From: Ping-Ke Shih 

Add comments to make it to be easier to understand, and add compile time
assertions.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/base.c | 3 +++
 drivers/net/wireless/realtek/rtlwifi/wifi.h | 7 ---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index c000c85a3ded..6db3389e2ced 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -2647,6 +2647,9 @@ EXPORT_SYMBOL_GPL(rtl_global_var);
 static int __init rtl_core_module_init(void)
 {
BUILD_BUG_ON(TX_PWR_BY_RATE_NUM_RATE < TX_PWR_BY_RATE_NUM_SECTION);
+   BUILD_BUG_ON(MAX_RATE_SECTION_NUM != MAX_RATE_SECTION);
+   BUILD_BUG_ON(MAX_BASE_NUM_IN_PHY_REG_PG_24G != MAX_RATE_SECTION);
+   BUILD_BUG_ON(MAX_BASE_NUM_IN_PHY_REG_PG_5G != (MAX_RATE_SECTION - 1));
 
if (rtl_rate_control_register())
pr_err("rtl: Unable to register rtl_rc, use default RC !!\n");
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 5b29502a2864..4de2ab1d5416 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -163,7 +163,7 @@ enum rtl8192c_h2c_cmd {
 #define MAX_TX_COUNT   4
 #define MAX_REGULATION_NUM 4
 #define MAX_RF_PATH_NUM4
-#define MAX_RATE_SECTION_NUM   6
+#define MAX_RATE_SECTION_NUM   6   /* = MAX_RATE_SECTION */
 #define MAX_2_4G_BANDWIDTH_NUM 4
 #define MAX_5G_BANDWIDTH_NUM   4
 #defineMAX_RF_PATH 4
@@ -174,8 +174,8 @@ enum rtl8192c_h2c_cmd {
 #define TX_PWR_BY_RATE_NUM_RF  4
 #define TX_PWR_BY_RATE_NUM_SECTION 12
 #define TX_PWR_BY_RATE_NUM_RATE84 /* >= 
TX_PWR_BY_RATE_NUM_SECTION */
-#define MAX_BASE_NUM_IN_PHY_REG_PG_24G  6
-#define MAX_BASE_NUM_IN_PHY_REG_PG_5G  5
+#define MAX_BASE_NUM_IN_PHY_REG_PG_24G 6  /* MAX_RATE_SECTION */
+#define MAX_BASE_NUM_IN_PHY_REG_PG_5G  5  /* MAX_RATE_SECTION -1 */
 
 #define BUFDESC_SEG_NUM1 /* 0:2 seg, 1: 4 seg, 2: 8 seg */
 
@@ -271,6 +271,7 @@ enum rate_section {
HT_MCS8_MCS15,
VHT_1SSMCS0_1SSMCS9,
VHT_2SSMCS0_2SSMCS9,
+   MAX_RATE_SECTION,
 };
 
 enum intf_type {
-- 
2.15.1

[PATCH 01/10] rtlwifi: enable mac80211 fast-tx support

[pkshih]

From: Ping-Ke Shih 

Enable the mac80211 fast-tx feature, since our driver already support
hw_flags required by fast-tx and is able to let mac80211 stack to transmit
packet through fast-xmit path.

Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/base.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index d6c03bd5cc65..e461eed32699 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -397,6 +397,7 @@ static void _rtl_init_mac80211(struct ieee80211_hw *hw)
ieee80211_hw_set(hw, MFP_CAPABLE);
ieee80211_hw_set(hw, REPORTS_TX_ACK_STATUS);
ieee80211_hw_set(hw, SUPPORTS_AMSDU_IN_AMPDU);
+   ieee80211_hw_set(hw, SUPPORT_FAST_XMIT);
 
/* swlps or hwlps has been set in diff chip in init_sw_vars */
if (rtlpriv->psc.swctrl_lps) {
-- 
2.15.1

[PATCH 10/10] rtlwifi: btcoex: Add 8822be btcoex supported files for wifi only

[pkshih]

From: Ping-Ke Shih 

The wifi only btcoex is used to solo card (without BT), and it is also
useful to exclude the interference with BT to make debug easier.
There are only four ops for wifi only btcoex to initialze antenna and
switch the settings while band is changed.

Signed-off-by: Ping-Ke Shih 
---
 .../rtlwifi/btcoexist/halbtc8822bwifionly.c| 55 ++
 .../rtlwifi/btcoexist/halbtc8822bwifionly.h| 25 ++
 2 files changed, 80 insertions(+)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822bwifionly.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822bwifionly.h

diff --git 
a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822bwifionly.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822bwifionly.c
new file mode 100644
index ..951b8c1e0153
--- /dev/null
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822bwifionly.c
@@ -0,0 +1,55 @@
+/**
+ *
+ * Copyright(c) 2016-2017  Realtek Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+#include "halbt_precomp.h"
+
+void ex_hal8822b_wifi_only_hw_config(struct wifi_only_cfg *wifionlycfg)
+{
+   /*BB control*/
+   halwifionly_phy_set_bb_reg(wifionlycfg, 0x4c, 0x0180, 0x2);
+   /*SW control*/
+   halwifionly_phy_set_bb_reg(wifionlycfg, 0xcb4, 0xff, 0x77);
+   /*antenna mux switch */
+   halwifionly_phy_set_bb_reg(wifionlycfg, 0x974, 0x300, 0x3);
+
+   halwifionly_phy_set_bb_reg(wifionlycfg, 0x1990, 0x300, 0x0);
+
+   halwifionly_phy_set_bb_reg(wifionlycfg, 0xcbc, 0x8, 0x0);
+   /*switch to WL side controller and gnt_wl gnt_bt debug signal */
+   halwifionly_phy_set_bb_reg(wifionlycfg, 0x70, 0xff00, 0x0e);
+   /*gnt_wl=1 , gnt_bt=0*/
+   halwifionly_phy_set_bb_reg(wifionlycfg, 0x1704, 0x, 0x7700);
+   halwifionly_phy_set_bb_reg(wifionlycfg, 0x1700, 0x, 0xc00f0038);
+}
+
+void ex_hal8822b_wifi_only_scannotify(struct wifi_only_cfg *wifionlycfg,
+ u8 is_5g)
+{
+   hal8822b_wifi_only_switch_antenna(wifionlycfg, is_5g);
+}
+
+void ex_hal8822b_wifi_only_switchbandnotify(struct wifi_only_cfg *wifionlycfg,
+   u8 is_5g)
+{
+   hal8822b_wifi_only_switch_antenna(wifionlycfg, is_5g);
+}
+
+void hal8822b_wifi_only_switch_antenna(struct wifi_only_cfg *wifionlycfg,
+  u8 is_5g)
+{
+   if (is_5g)
+   halwifionly_phy_set_bb_reg(wifionlycfg, 0xcbc, 0x300, 0x1);
+   else
+   halwifionly_phy_set_bb_reg(wifionlycfg, 0xcbc, 0x300, 0x2);
+}
diff --git 
a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822bwifionly.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822bwifionly.h
new file mode 100644
index ..6ec356542eea
--- /dev/null
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822bwifionly.h
@@ -0,0 +1,25 @@
+/**
+ *
+ * Copyright(c) 2016-2017  Realtek Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+#ifndef __INC_HAL8822BWIFIONLYHWCFG_H
+#define __INC_HAL8822BWIFIONLYHWCFG_H
+
+void ex_hal8822b_wifi_only_hw_config(struct wifi_only_cfg *wifionlycfg);
+void ex_hal8822b_wifi_only_scannotify(struct wifi_only_cfg *wifionlycfg,
+ u8 is_5g);
+void ex_hal8822b_wifi_only_switchbandnotify(struct wifi_only_cfg *wifionlycfg,
+   u8 is_5g);
+void hal8822b_wifi_only_switch_antenna(struct wifi_only_cfg *wifionlycfg,
+  u8 is_5g);
+#endif
-- 
2.15.1

[PATCH 07/10] rtlwifi: add definition radio_mask for RF and maximum bandwidth

[pkshih]

From: Ping-Ke Shih 

Add rf mask definition (BIT 0, BIT 1, BIT 2, ...) that is different from
rf path definition (0, 1, 2, ...), and then combinations of rf path are
possible.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/wifi.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 4de2ab1d5416..2e9a20273a2d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -286,6 +286,13 @@ enum radio_path {
RF90_PATH_D = 3,
 };
 
+enum radio_mask {
+   RF_MASK_A = BIT(0),
+   RF_MASK_B = BIT(1),
+   RF_MASK_C = BIT(2),
+   RF_MASK_D = BIT(3),
+};
+
 enum regulation_txpwr_lmt {
TXPWR_LMT_FCC = 0,
TXPWR_LMT_MKK = 1,
@@ -579,6 +586,7 @@ enum ht_channel_width {
HT_CHANNEL_WIDTH_20 = 0,
HT_CHANNEL_WIDTH_20_40 = 1,
HT_CHANNEL_WIDTH_80 = 2,
+   HT_CHANNEL_WIDTH_MAX,
 };
 
 /* Ref: 802.11i sepc D10.0 7.3.2.25.1
-- 
2.15.1

[PATCH 02/10] rtlwifi: Add Support VHT to spec_ver

[pkshih]

From: Ping-Ke Shih 

We are going to add 8822be, which is a VHT 2x2 wifi chip, so add VHT flag
to replace enumeration of chips.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/base.c | 6 --
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 1 +
 drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 +
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index e461eed32699..a2da057d3cdd 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -244,6 +244,9 @@ static void _rtl_init_hw_vht_capab(struct ieee80211_hw *hw,
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
 
+   if (!(rtlpriv->cfg->spec_ver & RTL_SPEC_SUPPORT_VHT))
+   return;
+
if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE ||
rtlhal->hw_type == HARDWARE_TYPE_RTL8822BE) {
u16 mcs_map;
@@ -887,8 +890,7 @@ static void _rtl_query_bandwidth_mode(struct ieee80211_hw 
*hw,
 
tcb_desc->packet_bw = HT_CHANNEL_WIDTH_20_40;
 
-   if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8812AE ||
-   rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8821AE) {
+   if (rtlpriv->cfg->spec_ver & RTL_SPEC_SUPPORT_VHT) {
if (mac->opmode == NL80211_IFTYPE_AP ||
mac->opmode == NL80211_IFTYPE_ADHOC ||
mac->opmode == NL80211_IFTYPE_MESH_POINT) {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
index ab5d462b1a3a..9bb3d9dfce79 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
@@ -328,6 +328,7 @@ static const struct rtl_hal_cfg rtl8821ae_hal_cfg = {
.alt_fw_name = "rtlwifi/rtl8821aefw.bin",
.ops = _hal_ops,
.mod_params = _mod_params,
+   .spec_ver = RTL_SPEC_SUPPORT_VHT,
.maps[SYS_ISO_CTRL] = REG_SYS_ISO_CTRL,
.maps[SYS_FUNC_EN] = REG_SYS_FUNC_EN,
.maps[SYS_CLK] = REG_SYS_CLKR,
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index a7aacbc3984e..2df0bc316532 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -951,6 +951,7 @@ enum package_type {
 
 enum rtl_spec_ver {
RTL_SPEC_NEW_RATEID = BIT(0),   /* use ratr_table_mode_new */
+   RTL_SPEC_SUPPORT_VHT = BIT(1),  /* support VHT */
 };
 
 struct octet_string {
-- 
2.15.1

[PATCH 04/10] rtlwifi: Extend tx_power_by_rate_offset size for newer IC

[pkshih]

From: Ping-Ke Shih 

In older design, the TX power is grouped into rate section (smaller array
size), but new design groups them into rate (larger array size). Thus,
we extend the size for both cases, and add compile time assertion.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/base.c | 2 ++
 drivers/net/wireless/realtek/rtlwifi/wifi.h | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index 92f99a303920..c000c85a3ded 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -2646,6 +2646,8 @@ EXPORT_SYMBOL_GPL(rtl_global_var);
 
 static int __init rtl_core_module_init(void)
 {
+   BUILD_BUG_ON(TX_PWR_BY_RATE_NUM_RATE < TX_PWR_BY_RATE_NUM_SECTION);
+
if (rtl_rate_control_register())
pr_err("rtl: Unable to register rtl_rc, use default RC !!\n");
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index be45420f34d3..5b29502a2864 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -173,6 +173,7 @@ enum rtl8192c_h2c_cmd {
 #define TX_PWR_BY_RATE_NUM_BAND2
 #define TX_PWR_BY_RATE_NUM_RF  4
 #define TX_PWR_BY_RATE_NUM_SECTION 12
+#define TX_PWR_BY_RATE_NUM_RATE84 /* >= 
TX_PWR_BY_RATE_NUM_SECTION */
 #define MAX_BASE_NUM_IN_PHY_REG_PG_24G  6
 #define MAX_BASE_NUM_IN_PHY_REG_PG_5G  5
 
@@ -1285,7 +1286,7 @@ struct rtl_phy {
u32 tx_power_by_rate_offset[TX_PWR_BY_RATE_NUM_BAND]
   [TX_PWR_BY_RATE_NUM_RF]
   [TX_PWR_BY_RATE_NUM_RF]
-  [TX_PWR_BY_RATE_NUM_SECTION];
+  [TX_PWR_BY_RATE_NUM_RATE];
u8 txpwr_by_rate_base_24g[TX_PWR_BY_RATE_NUM_RF]
 [TX_PWR_BY_RATE_NUM_RF]
 [MAX_BASE_NUM_IN_PHY_REG_PG_24G];
-- 
2.15.1

[PATCH 00/10] rtlwifi: add more materials for 8822be

[pkshih]

From: Ping-Ke Shih 

I continue to submit more materials needed by 8822be. A special patch is
"PATCH 10/10" that add new files to support 8822be btcoex in case wifi
only. In my plan, 8822be btcoex for combo card will be sumitted in next
patchset.

Ping-Ke Shih (10):
  rtlwifi: enable mac80211 fast-tx support
  rtlwifi: Add Support VHT to spec_ver
  rtlwifi: Use 6 bits as sequence number of TX report
  rtlwifi: Extend tx_power_by_rate_offset size for newer IC
  rtlwifi: Add rate section and its related definition and comment
  rtlwifi: Fix VHT NSS in RC
  rtlwifi: add definition radio_mask for RF and maximum bandwidth
  rtlwifi: add efuse ops for other components
  rtlwifi: btcoex: add routine to set default port id
  rtlwifi: btcoex: Add 8822be btcoex supported files for wifi only

 drivers/net/wireless/realtek/rtlwifi/base.c| 34 ++---
 .../rtlwifi/btcoexist/halbtc8822bwifionly.c| 55 ++
 .../rtlwifi/btcoexist/halbtc8822bwifionly.h| 25 ++
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 22 +
 drivers/net/wireless/realtek/rtlwifi/efuse.c   | 13 +
 drivers/net/wireless/realtek/rtlwifi/efuse.h   |  2 +-
 drivers/net/wireless/realtek/rtlwifi/pci.c |  1 +
 drivers/net/wireless/realtek/rtlwifi/rc.c  | 49 +++
 .../net/wireless/realtek/rtlwifi/rtl8821ae/sw.c|  1 +
 drivers/net/wireless/realtek/rtlwifi/wifi.h| 39 +--
 10 files changed, 221 insertions(+), 20 deletions(-)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822bwifionly.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822bwifionly.h

-- 
2.15.1

[PATCH 06/10] rtlwifi: Fix VHT NSS in RC

[pkshih]

From: Ping-Ke Shih 

NSS is a argument of highest rate in RC, and it occupies bit 4-7 so use
ieee80211_rate_set_vht() to fill the values. Since it got correct rate
index, we don't need to check chips to assign NSS in set function anymore.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/rc.c | 49 +--
 1 file changed, 40 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c 
b/drivers/net/wireless/realtek/rtlwifi/rc.c
index d1cb7d405618..396bed8d3d51 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
@@ -42,6 +42,17 @@ static u8 _rtl_rc_get_highest_rix(struct rtl_priv *rtlpriv,
struct rtl_phy *rtlphy = &(rtlpriv->phy);
struct rtl_sta_info *sta_entry = NULL;
u16 wireless_mode = 0;
+   u8 nss;
+   struct ieee80211_tx_rate rate;
+
+   if (get_rf_type(rtlphy) >= RF_4T4R)
+   nss = 4;
+   else if (get_rf_type(rtlphy) >= RF_3T3R)
+   nss = 3;
+   else if (get_rf_type(rtlphy) >= RF_2T2R)
+   nss = 2;
+   else
+   nss = 1;
 
/*
 *this rate is no use for true rate, firmware
@@ -66,28 +77,51 @@ static u8 _rtl_rc_get_highest_rix(struct rtl_priv *rtlpriv,
} else if (wireless_mode == WIRELESS_MODE_G) {
return G_MODE_MAX_RIX;
} else if (wireless_mode == WIRELESS_MODE_N_24G) {
-   if (get_rf_type(rtlphy) != RF_2T2R)
+   if (nss == 1)
return N_MODE_MCS7_RIX;
else
return N_MODE_MCS15_RIX;
} else if (wireless_mode == WIRELESS_MODE_AC_24G) {
-   return AC_MODE_MCS9_RIX;
+   if (sta->bandwidth == IEEE80211_STA_RX_BW_20) {
+   ieee80211_rate_set_vht(,
+  AC_MODE_MCS8_RIX,
+  nss);
+   goto out;
+   } else {
+   ieee80211_rate_set_vht(,
+  AC_MODE_MCS9_RIX,
+  nss);
+   goto out;
+   }
}
return 0;
} else {
if (wireless_mode == WIRELESS_MODE_A) {
return A_MODE_MAX_RIX;
} else if (wireless_mode == WIRELESS_MODE_N_5G) {
-   if (get_rf_type(rtlphy) != RF_2T2R)
+   if (nss == 1)
return N_MODE_MCS7_RIX;
else
return N_MODE_MCS15_RIX;
} else if (wireless_mode == WIRELESS_MODE_AC_5G) {
-   return AC_MODE_MCS9_RIX;
+   if (sta->bandwidth == IEEE80211_STA_RX_BW_20) {
+   ieee80211_rate_set_vht(,
+  AC_MODE_MCS8_RIX,
+  nss);
+   goto out;
+   } else {
+   ieee80211_rate_set_vht(,
+  AC_MODE_MCS9_RIX,
+  nss);
+   goto out;
+   }
}
return 0;
}
}
+
+out:
+   return rate.idx;
 }
 
 static void _rtl_rc_rate_set_series(struct rtl_priv *rtlpriv,
@@ -111,9 +145,6 @@ static void _rtl_rc_rate_set_series(struct rtl_priv 
*rtlpriv,
}
rate->count = tries;
rate->idx = rix >= 0x00 ? rix : 0x00;
-   if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8812AE &&
-   wireless_mode == WIRELESS_MODE_AC_5G)
-   rate->idx += 0x10;/*2NSS for 8812AE*/
 
if (!not_data) {
if (txrc->short_preamble)
@@ -126,10 +157,10 @@ static void _rtl_rc_rate_set_series(struct rtl_priv 
*rtlpriv,
if (sta && sta->vht_cap.vht_supported)
rate->flags |= IEEE80211_TX_RC_80_MHZ_WIDTH;
} else {
-   if (mac->bw_40)
-   rate->flags |= IEEE80211_TX_RC_40_MHZ_WIDTH;

[PATCH 09/10] rtlwifi: btcoex: add routine to set default port id

[pkshih]

From: Ping-Ke Shih 

Tell wifi and BT firmware the default port ID to set multiports' state
properly, but only 8822be needs this function currently.

Signed-off-by: Ping-Ke Shih 
---
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 22 ++
 drivers/net/wireless/realtek/rtlwifi/wifi.h|  5 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 1404729441a2..5e41b204f7c0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1039,6 +1039,28 @@ static void halbtc_fill_h2c_cmd(void *bt_context, u8 
element_id,
cmd_len, cmd_buf);
 }
 
+static void halbtc_send_wifi_port_id_cmd(void *bt_context)
+{
+   struct btc_coexist *btcoexist = (struct btc_coexist *)bt_context;
+   struct rtl_priv *rtlpriv = btcoexist->adapter;
+   u8 cmd_buf[1] = {0};/* port id [2:0] = 0 */
+
+   rtlpriv->cfg->ops->fill_h2c_cmd(rtlpriv->mac80211.hw, H2C_BT_PORT_ID,
+   1, cmd_buf);
+}
+
+static void halbtc_set_default_port_id_cmd(void *bt_context)
+{
+   struct btc_coexist *btcoexist = (struct btc_coexist *)bt_context;
+   struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct ieee80211_hw *hw = rtlpriv->mac80211.hw;
+
+   if (!rtlpriv->cfg->ops->set_default_port_id_cmd)
+   return;
+
+   rtlpriv->cfg->ops->set_default_port_id_cmd(hw);
+}
+
 static
 void halbtc_set_bt_reg(void *btc_context, u8 reg_type, u32 offset, u32 set_val)
 {
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 0e8aae0c05c1..1c9ed28b42da 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -153,6 +153,10 @@ enum rtl8192c_h2c_cmd {
MAX_H2CCMD
 };
 
+enum {
+   H2C_BT_PORT_ID = 0x71,
+};
+
 #define GET_TX_REPORT_SN_V1(c2h)   (c2h[6])
 #define GET_TX_REPORT_ST_V1(c2h)   (c2h[0] & 0xC0)
 #define GET_TX_REPORT_RETRY_V1(c2h)(c2h[2] & 0x3F)
@@ -2256,6 +2260,7 @@ struct rtl_hal_ops {
void (*bt_coex_off_before_lps) (struct ieee80211_hw *hw);
void (*fill_h2c_cmd) (struct ieee80211_hw *hw, u8 element_id,
  u32 cmd_len, u8 *p_cmdbuffer);
+   void (*set_default_port_id_cmd)(struct ieee80211_hw *hw);
bool (*get_btc_status) (void);
bool (*is_fw_header)(struct rtlwifi_firmware_header *hdr);
u32 (*rx_command_packet)(struct ieee80211_hw *hw,
-- 
2.15.1

[PATCH 03/10] rtlwifi: Use 6 bits as sequence number of TX report

[pkshih]

From: Ping-Ke Shih 

In new design, SW_DEFINE[1:0] of tx desc are used by firmware, and the TX
report only contains SW_DEFINE[7:0]. To satisfy with all cases, driver uses
SW_DEFINE[7:2] as sequence number.
Besides, the format of tx report have been changed, so a new flag
RTL_SPEC_EXT_C2H is used to access report.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/base.c | 22 ++
 drivers/net/wireless/realtek/rtlwifi/wifi.h |  8 
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index a2da057d3cdd..92f99a303920 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -1597,7 +1597,11 @@ static u16 rtl_get_tx_report_sn(struct ieee80211_hw *hw)
struct rtl_tx_report *tx_report = >tx_report;
u16 sn;
 
-   sn = atomic_inc_return(_report->sn) & 0x0FFF;
+   /* SW_DEFINE[11:8] are reserved (driver fills zeros)
+* SW_DEFINE[7:2] are used by driver
+* SW_DEFINE[1:0] are reserved for firmware (driver fills zeros)
+*/
+   sn = (atomic_inc_return(_report->sn) & 0x003F) << 2;
 
tx_report->last_sent_sn = sn;
tx_report->last_sent_time = jiffies;
@@ -1625,14 +1629,23 @@ void rtl_tx_report_handler(struct ieee80211_hw *hw, u8 
*tmp_buf, u8 c2h_cmd_len)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_tx_report *tx_report = >tx_report;
u16 sn;
+   u8 st, retry;
 
-   sn = ((tmp_buf[7] & 0x0F) << 8) | tmp_buf[6];
+   if (rtlpriv->cfg->spec_ver & RTL_SPEC_EXT_C2H) {
+   sn = GET_TX_REPORT_SN_V2(tmp_buf);
+   st = GET_TX_REPORT_ST_V2(tmp_buf);
+   retry = GET_TX_REPORT_RETRY_V2(tmp_buf);
+   } else {
+   sn = GET_TX_REPORT_SN_V1(tmp_buf);
+   st = GET_TX_REPORT_ST_V1(tmp_buf);
+   retry = GET_TX_REPORT_RETRY_V1(tmp_buf);
+   }
 
tx_report->last_recv_sn = sn;
 
RT_TRACE(rtlpriv, COMP_TX_REPORT, DBG_DMESG,
 "Recv TX-Report st=0x%02X sn=0x%X retry=0x%X\n",
-tmp_buf[0], sn, tmp_buf[2]);
+st, sn, retry);
 }
 EXPORT_SYMBOL_GPL(rtl_tx_report_handler);
 
@@ -1646,7 +1659,8 @@ bool rtl_check_tx_report_acked(struct ieee80211_hw *hw)
 
if (time_before(tx_report->last_sent_time + 3 * HZ, jiffies)) {
RT_TRACE(rtlpriv, COMP_TX_REPORT, DBG_WARNING,
-"Check TX-Report timeout!!\n");
+"Check TX-Report timeout!! s_sn=0x%X r_sn=0x%X\n",
+tx_report->last_sent_sn, tx_report->last_recv_sn);
return true;/* 3 sec. (timeout) seen as acked */
}
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 2df0bc316532..be45420f34d3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -153,6 +153,13 @@ enum rtl8192c_h2c_cmd {
MAX_H2CCMD
 };
 
+#define GET_TX_REPORT_SN_V1(c2h)   (c2h[6])
+#define GET_TX_REPORT_ST_V1(c2h)   (c2h[0] & 0xC0)
+#define GET_TX_REPORT_RETRY_V1(c2h)(c2h[2] & 0x3F)
+#define GET_TX_REPORT_SN_V2(c2h)   (c2h[6])
+#define GET_TX_REPORT_ST_V2(c2h)   (c2h[7] & 0xC0)
+#define GET_TX_REPORT_RETRY_V2(c2h)(c2h[8] & 0x3F)
+
 #define MAX_TX_COUNT   4
 #define MAX_REGULATION_NUM 4
 #define MAX_RF_PATH_NUM4
@@ -952,6 +959,7 @@ enum package_type {
 enum rtl_spec_ver {
RTL_SPEC_NEW_RATEID = BIT(0),   /* use ratr_table_mode_new */
RTL_SPEC_SUPPORT_VHT = BIT(1),  /* support VHT */
+   RTL_SPEC_EXT_C2H = BIT(2),  /* extend FW C2H (e.g. TX REPORT) */
 };
 
 struct octet_string {
-- 
2.15.1

Darlehen Geld für Einzelpersonen und Fachleute in weniger als 72 Stunden

[Peter Schuster]

Hallo,

Sind Sie in einer schwierigen Situation, für die Sie sich für ein
Darlehen suchen? Benötigen Sie eine Finanzierung, um eine Schuld zu
begleichen oder eine Aktivität zu finanzieren? Haben Sie einen
Verbraucherkredit, eine Hypothek, einen persönlichen Kredit, eine
Hypothek, Investition Darlehen, Schuldenkonsolidierung Darlehen oder
andere braucht?

Ich bin ein einzelner Investor. I zur Verfügung stellen die Kredit
kurz-, mittel- und langfristige. Ihr Finanzierungsbedingungen sind
sehr einfach und meine Zinssatz beträgt 3% pro Jahr.

Für alle Anfragen, bleibe ich zur Verfügung, um Ihre Fragen zu beantworten.

Danke, dass Sie mir per E-Mail an Sie von  :   klaus.peterschus...@outlook.de

Mit freundlichen Grüßen.

Peter Schuster

Financial Bank
https://firstfinancialsa.com/de

Re: ath10k: correct the length of DRAM dump for QCA6174 hw3.x/QCA9377 hw1.1

[Kalle Valo]

Yu Wang  wrote:

> The length of DRAM dump for QCA6174 hw3.0/hw3.2 and QCA9377 hw1.1
> are less than the actual value, some coredump contents are missed.
> To fix it, change the length from 0x9 to 0xa8000.
> 
> Fixes: 703f261dd77f ("ath10k: add memory dump support for QCA6174/QCA9377")
> Signed-off-by: Yu Wang 

I'm planning to queue this to 4.16.

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

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

Re: ath10k: Update the phymode along with bandwidth change request

[Kalle Valo]

ryan...@codeaurora.org wrote:

> From: Ryan Hsu 
> 
> In the case of Station connects to AP with narrower bandwidth at beginning.
> And later the AP changes the bandwidth to winder bandwidth, the AP will
> beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80.
> 
> Since the supported BANDWIDTH will be limited by the PHYMODE, so while
> Station receives the bandwidth change request, it will also need to
> reconfigure the PHYMODE setting to firmware instead of just configuring
> the BANDWIDTH info, otherwise it'll trigger a firmware crash with
> non-support bandwidth.
> 
> The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174 with
> below scenario.

Fails to compile:

drivers/net/wireless/ath/ath10k/mac.c: In function ‘ath10k_sta_rc_update_wk’:
drivers/net/wireless/ath/ath10k/mac.c:6000:3: error: ‘mode’ undeclared (first 
use in this function)
   mode = chan_to_phymode();
   ^
drivers/net/wireless/ath/ath10k/mac.c:6000:3: note: each undeclared identifier 
is reported only once for each function it appears in
drivers/net/wireless/ath/ath10k/mac.c:6006:7: error: ‘WMI_PEER_PHYMODE’ 
undeclared (first use in this function)
   WMI_PEER_PHYMODE, mode);
   ^
make[5]: *** [drivers/net/wireless/ath/ath10k/mac.o] Error 1
make[4]: *** [drivers/net/wireless/ath/ath10k] Error 2
make[3]: *** [drivers/net/wireless/ath] Error 2
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2

Patch set to Changes Requested.

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

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

[PATCH] ath10k: correct the length of DRAM dump for QCA6174 hw3.x/QCA9377 hw1.1

[Yu Wang]

The length of DRAM dump for QCA6174 hw3.0/hw3.2 and QCA9377 hw1.1
are less than the actual value, some coredump contents are missed.
To fix it, change the length from 0x9 to 0xa8000.

Fixes: 703f261dd77f ("ath10k: add memory dump support for QCA6174/QCA9377")

Yu Wang (1):
  ath10k: correct the length of DRAM dump for QCA6174 hw3.x/QCA9377
hw1.1

 drivers/net/wireless/ath/ath10k/coredump.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH] ath10k: correct the length of DRAM dump for QCA6174 hw3.x/QCA9377 hw1.1

[Yu Wang]

The length of DRAM dump for QCA6174 hw3.0/hw3.2 and QCA9377 hw1.1
are less than the actual value, some coredump contents are missed.
To fix it, change the length from 0x9 to 0xa8000.

Fixes: 703f261dd77f ("ath10k: add memory dump support for QCA6174/QCA9377")
Signed-off-by: Yu Wang 
---
 drivers/net/wireless/ath/ath10k/coredump.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/coredump.c 
b/drivers/net/wireless/ath/ath10k/coredump.c
index 4dde126..7173b37 100644
--- a/drivers/net/wireless/ath/ath10k/coredump.c
+++ b/drivers/net/wireless/ath/ath10k/coredump.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2011-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -616,7 +617,7 @@
{
.type = ATH10K_MEM_REGION_TYPE_DRAM,
.start = 0x40,
-   .len = 0x9,
+   .len = 0xa8000,
.name = "DRAM",
.section_table = {
.sections = NULL,
-- 
1.9.1

Re: [PATCH v2] mac80211_hwsim: don't use WQ_MEM_RECLAIM

[Tejun Heo]

Hello,

On Thu, Jan 25, 2018 at 10:01:26PM +0100, Johannes Berg wrote:
> I guess we should just ask Tejun :-)
> 
> Tejun, the problem was a report that a WQ_MEM_RECLAIM workqueue is
> flushing another that isn't, and it turns out that lots of wireless
> drivers are using WQ_MEM_RECLAIM for some reason.

Yeah, that came up a couple years ago.  IIRC, there wasn't a definite
answer but the sentiment seemed that things like nfs over wireless
should probably considered.  No idea how serious that concern is.

> Arend said:
> > >  > > Maybe a hint in the documentation, that a work item on a 
> > > WQ_MEM_RECLAIM
> > >  > > queue must not call flush of an !WQ_MEM_RECLAIM queue would be nice.
> > >  > > Maybe it's kind of obvious, but there is also a reminder not to 
> > > forget
> > >  > > that flag, if a queue may have work items that reclaim memory
> > >  >
> > >  > Yeah, honestly, I'm not really sure either. Clearly we can't set it,
> > >  > but other drivers also set it...

So, anything which can sit in memory reclaim path needs to have that
flag set and having that flag set automatically means that it can't
depend on anything which isn't protected the same way as that'd break
that protection.

> > > That triggered something in my memory. So indeed we use it in brcmfmac
> > > as well. We used create_singlethread_workqueue(), but I wanted to avoid
> > > snprintf and specify the name format so switched to using
> > > alloc_ordered_workqueue() keeping WQ_MEM_RECLAIM as per the macro
> > > definition.
> > 
> > #define create_singlethread_workqueue(name) \
> > alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)
> > 
> > > Don't recall why I dropped the __WQ_LEGACY flag though.

The only thing that flag does is disabling the flush dependency check
which is necessary because in the old implementation, all workqueues
were basically WQ_MEM_RECLAIM workqueues leading to spurious
triggering of the warnings.

Thanks.

-- 
tejun

Re: [PATCH v2] mac80211_hwsim: don't use WQ_MEM_RECLAIM

[Johannes Berg]

I guess we should just ask Tejun :-)

Tejun, the problem was a report that a WQ_MEM_RECLAIM workqueue is
flushing another that isn't, and it turns out that lots of wireless
drivers are using WQ_MEM_RECLAIM for some reason.

Arend said:
> >  > > Maybe a hint in the documentation, that a work item on a WQ_MEM_RECLAIM
> >  > > queue must not call flush of an !WQ_MEM_RECLAIM queue would be nice.
> >  > > Maybe it's kind of obvious, but there is also a reminder not to forget
> >  > > that flag, if a queue may have work items that reclaim memory
> >  >
> >  > Yeah, honestly, I'm not really sure either. Clearly we can't set it,
> >  > but other drivers also set it...
> > 
> > That triggered something in my memory. So indeed we use it in brcmfmac
> > as well. We used create_singlethread_workqueue(), but I wanted to avoid
> > snprintf and specify the name format so switched to using
> > alloc_ordered_workqueue() keeping WQ_MEM_RECLAIM as per the macro
> > definition.
> 
> #define create_singlethread_workqueue(name)   \
>   alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)
> 
> > Don't recall why I dropped the __WQ_LEGACY flag though.

johannes

Re: [PATCH v2] mac80211_hwsim: don't use WQ_MEM_RECLAIM

[Arend van Spriel]

resending as it included html and got blocked from the list.

On 1/25/2018 7:21 PM, Arend Van Spriel wrote:

Op 24 jan. 2018 11:46 schreef "Johannes Berg" >:
 >
 > On Wed, 2018-01-24 at 10:39 +0100, Benjamin Beichler wrote:
 >
 > > sorry for introducing that error, but I'm a bit confused by the
 > > workqueue documentation.
 > > My assumption was, that deleting hwsim radios is reclaiming memory, and
 > > since this queue does nothing else it would save/necessary to set
this flag.
 > >
 > > Maybe a hint in the documentation, that a work item on a WQ_MEM_RECLAIM
 > > queue must not call flush of an !WQ_MEM_RECLAIM queue would be nice.
 > > Maybe it's kind of obvious, but there is also a reminder not to forget
 > > that flag, if a queue may have work items that reclaim memory
 >
 > Yeah, honestly, I'm not really sure either. Clearly we can't set it,
 > but other drivers also set it...

That triggered something in my memory. So indeed we use it in brcmfmac
as well. We used create_singlethread_workqueue(), but I wanted to avoid
snprintf and specify the name format so switched to using
alloc_ordered_workqueue() keeping WQ_MEM_RECLAIM as per the macro
definition.


#define create_singlethread_workqueue(name) \
alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)


Don't recall why I dropped the __WQ_LEGACY flag though.

Regards,
Arend

 > I don't think it was *intended* for when you're freeing memory, since I
 > think reclaiming is what happens when you write out dirty buffers to
 > disk etc.
 >
 > johannes

Re: [PATCH v3] mac80211: mesh: fix wrong mesh TTL offset calculation

[Johannes Berg]

On Thu, 2018-01-25 at 11:01 -0800, Peter Oh wrote:
> Ignore the patch below for now. Just noticed mesh_chansw_params_ie is 
> constance.
> 
Just remove the const?

johannes

Re: [PATCH v3] mac80211: mesh: fix wrong mesh TTL offset calculation

[Peter Oh]

Ignore the patch below for now. Just noticed mesh_chansw_params_ie is 
constance.


will come up with new approach.


Thanks,

Peter


On 01/24/2018 05:16 PM, peter...@bowerswilkins.com wrote:

From: Peter Oh 

mesh TTL offset in Mesh Channel Switch Parameters element depends on
not only Secondary Channel Offset element, but also affected by
HT Control field and Wide Bandwidth Channel Switch element.
Use element structure to correct the miscalculation.

Signed-off-by: Peter Oh 
---
  net/mac80211/mesh.c | 17 ++---
  1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 73ac607..6a381cb 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1255,13 +1255,12 @@ int ieee80211_mesh_csa_beacon(struct 
ieee80211_sub_if_data *sdata,
  }
  
  static int mesh_fwd_csa_frame(struct ieee80211_sub_if_data *sdata,

-  struct ieee80211_mgmt *mgmt, size_t len)
+  struct ieee80211_mgmt *mgmt, size_t len,
+  struct ieee802_11_elems *elems)
  {
struct ieee80211_mgmt *mgmt_fwd;
struct sk_buff *skb;
struct ieee80211_local *local = sdata->local;
-   u8 *pos = mgmt->u.action.u.chan_switch.variable;
-   size_t offset_ttl;
  
  	skb = dev_alloc_skb(local->tx_headroom + len);

if (!skb)
@@ -1269,13 +1268,9 @@ static int mesh_fwd_csa_frame(struct 
ieee80211_sub_if_data *sdata,
skb_reserve(skb, local->tx_headroom);
mgmt_fwd = skb_put(skb, len);
  
-	/* offset_ttl is based on whether the secondary channel

-* offset is available or not. Subtract 1 from the mesh TTL
-* and disable the initiator flag before forwarding.
-*/
-   offset_ttl = (len < 42) ? 7 : 10;
-   *(pos + offset_ttl) -= 1;
-   *(pos + offset_ttl + 1) &= ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
+   elems->mesh_chansw_params_ie->mesh_ttl--;
+   elems->mesh_chansw_params_ie->mesh_flags &=
+   ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
  
  	memcpy(mgmt_fwd, mgmt, len);

eth_broadcast_addr(mgmt_fwd->da);
@@ -1323,7 +1318,7 @@ static void mesh_rx_csa_frame(struct 
ieee80211_sub_if_data *sdata,
  
  	/* forward or re-broadcast the CSA frame */

if (fwd_csa) {
-   if (mesh_fwd_csa_frame(sdata, mgmt, len) < 0)
+   if (mesh_fwd_csa_frame(sdata, mgmt, len, ) < 0)
mcsa_dbg(sdata, "Failed to forward the CSA frame");
}
  }

Re: [PATCH 1/2] mwifiex: schedule rx_work on RX interrupt for USB

[Brian Norris]

On Mon, Jan 22, 2018 at 08:34:56PM +0530, Ganapathi Bhat wrote:
> From: Shrenik Shikhare 
> 
> There is race for data_received flag between main thread and
> RX data interrupt(mwifiex_usb_rx_complete()):
> 1. USB received an RX data interrupt, set data_received flag
> 2. main thread checks data_received, if set queues rx_work

Stop right there.

There is a flag, data_received, and as you say, you are setting it one
thread, and reading it in another thread (and later clearing it; step
#5). Where is the locking? There is none. Therefore, you have a data
race.

You are not resolving any locking problems here, so you're not really
solving the entire problem.

Brian

> 3. rx worker thread independently start processing rx_data_q
> 4. rx work exits (once rx_data_q is empty)
> 5. main thread resets the data_received flag(after #2)
> 6. Now at the corner case there will be high RX data interrupts
> between #4 and #5
> 7. Driver stops submitting URBs to firmware, once rx_pending
> exceeds HIGH_RX_PENDING
> 8. The flag data_received(cleared in #5) will remain unset since
> there will be no interrupts from firmware to set it(after #7)
> 
> Above scenario causes RX stall in driver, which will finally
> result in command/TX timeouts in firmware.
> 
> As a fix, queue rx_work directly in mwifiex_usb_rx_complete()
> callback, instead in the main thread. This removes dependency
> of RX processing on data_received flag.
> 
> Signed-off-by: Cathy Luo 
> Signed-off-by: Ganapathi Bhat 
> ---
>  drivers/net/wireless/marvell/mwifiex/main.c | 7 ---
>  drivers/net/wireless/marvell/mwifiex/main.h | 1 +
>  drivers/net/wireless/marvell/mwifiex/usb.c  | 2 ++
>  3 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
> b/drivers/net/wireless/marvell/mwifiex/main.c
> index 12e7399..6e6e1a7 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.c
> +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> @@ -171,7 +171,7 @@ void mwifiex_queue_main_work(struct mwifiex_adapter 
> *adapter)
>  }
>  EXPORT_SYMBOL_GPL(mwifiex_queue_main_work);
>  
> -static void mwifiex_queue_rx_work(struct mwifiex_adapter *adapter)
> +void mwifiex_queue_rx_work(struct mwifiex_adapter *adapter)
>  {
>   unsigned long flags;
>  
> @@ -183,6 +183,7 @@ static void mwifiex_queue_rx_work(struct mwifiex_adapter 
> *adapter)
>   queue_work(adapter->rx_workqueue, >rx_work);
>   }
>  }
> +EXPORT_SYMBOL_GPL(mwifiex_queue_rx_work);
>  
>  static int mwifiex_process_rx(struct mwifiex_adapter *adapter)
>  {
> @@ -283,10 +284,10 @@ int mwifiex_main_process(struct mwifiex_adapter 
> *adapter)
>   mwifiex_process_hs_config(adapter);
>   if (adapter->if_ops.process_int_status)
>   adapter->if_ops.process_int_status(adapter);
> + if (adapter->rx_work_enabled && adapter->data_received)
> + mwifiex_queue_rx_work(adapter);
>   }
>  
> - if (adapter->rx_work_enabled && adapter->data_received)
> - mwifiex_queue_rx_work(adapter);
>  
>   /* Need to wake up the card ? */
>   if ((adapter->ps_state == PS_STATE_SLEEP) &&
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
> b/drivers/net/wireless/marvell/mwifiex/main.h
> index 6b5539b..66ba95c 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.h
> +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> @@ -1667,6 +1667,7 @@ u8 mwifiex_adjust_data_rate(struct mwifiex_private 
> *priv,
>  void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter);
>  void *mwifiex_alloc_dma_align_buf(int rx_len, gfp_t flags);
>  void mwifiex_queue_main_work(struct mwifiex_adapter *adapter);
> +void mwifiex_queue_rx_work(struct mwifiex_adapter *adapter);
>  int mwifiex_get_wakeup_reason(struct mwifiex_private *priv, u16 action,
> int cmd_type,
> struct mwifiex_ds_wakeup_reason *wakeup_reason);
> diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c 
> b/drivers/net/wireless/marvell/mwifiex/usb.c
> index 4bc2448..d20fda1 100644
> --- a/drivers/net/wireless/marvell/mwifiex/usb.c
> +++ b/drivers/net/wireless/marvell/mwifiex/usb.c
> @@ -144,6 +144,8 @@ static int mwifiex_usb_recv(struct mwifiex_adapter 
> *adapter,
>   skb_queue_tail(>rx_data_q, skb);
>   adapter->data_received = true;
>   atomic_inc(>rx_pending);
> + if (adapter->rx_work_enabled)
> + mwifiex_queue_rx_work(adapter);
>   break;
>   default:
>   mwifiex_dbg(adapter, ERROR,
> -- 
> 1.9.1
> 

Re: [EXT] Re: [2/2] mwifiex: use more_rx_task_flag to avoid USB RX stall

[Brian Norris]

On Thu, Jan 25, 2018 at 09:59:04AM +, Ganapathi Bhat wrote:
> > I can't find any commit with id c7dbdcb2a4e1, is it correct?
> Correct. Actually the commit id c7dbdcb2a4e1 is the PATCH [1/2] sent in this 
> series.

What? Why would you introduce a bug and only fix it in the next patch?
Does that mean you should just combine the two? Or reverse the order, if
patch 2 doesn't cause problems on its own?

Brian

Re: [1/2] mwifiex: schedule rx_work on RX interrupt for USB

[Brian Norris]

On Thu, Jan 25, 2018 at 07:10:52AM +, Kalle Valo wrote:
> Ganapathi Bhat  wrote:
> 
> > From: Shrenik Shikhare 
> > 
> > There is race for data_received flag between main thread and
> > RX data interrupt(mwifiex_usb_rx_complete()):
> > 1. USB received an RX data interrupt, set data_received flag
> > 2. main thread checks data_received, if set queues rx_work
> > 3. rx worker thread independently start processing rx_data_q
> > 4. rx work exits (once rx_data_q is empty)
> > 5. main thread resets the data_received flag(after #2)
> > 6. Now at the corner case there will be high RX data interrupts
> > between #4 and #5
> > 7. Driver stops submitting URBs to firmware, once rx_pending
> > exceeds HIGH_RX_PENDING
> > 8. The flag data_received(cleared in #5) will remain unset since
> > there will be no interrupts from firmware to set it(after #7)
> > 
> > Above scenario causes RX stall in driver, which will finally
> > result in command/TX timeouts in firmware.
> > 
> > As a fix, queue rx_work directly in mwifiex_usb_rx_complete()
> > callback, instead in the main thread. This removes dependency
> > of RX processing on data_received flag.
> > 
> > Signed-off-by: Cathy Luo 
> > Signed-off-by: Ganapathi Bhat 
> 
> Brian, did you have a chance to review these two?

Not really. I don't generally make a lot of time to review the USB
driver unless it's really screwing around with the main driver, since I
don't use the USB driver. But I'll try to give it a few glances.

[PATCHv2 2/2] mac80211: Add support to notify ht/vht opmode modification.

[Tamizh chelvam]

This will add support to send an event to a userspace application
whenever station advertise its ht/vht opmode modification through
an action frame.

Signed-off-by: Tamizh chelvam 
---
 net/mac80211/rx.c  | 14 ++
 net/mac80211/vht.c |  9 +
 2 files changed, 23 insertions(+)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index fd58061..d1efe8a 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2848,6 +2848,7 @@ static void ieee80211_process_sa_query_req(struct 
ieee80211_sub_if_data *sdata,
case WLAN_HT_ACTION_SMPS: {
struct ieee80211_supported_band *sband;
enum ieee80211_smps_mode smps_mode;
+   struct sta_opmode_info sta_opmode;
 
/* convert to HT capability */
switch (mgmt->u.action.u.ht_smps.smps_control) {
@@ -2868,17 +2869,24 @@ 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.changed = STA_OPMODE_SMPS_MODE_CHANGED;
 
sband = rx->local->hw.wiphy->bands[status->band];
 
rate_control_rate_update(local, sband, rx->sta,
 IEEE80211_RC_SMPS_CHANGED);
+   cfg80211_sta_opmode_change_notify(sdata->dev,
+ rx->sta->addr,
+ _opmode,
+ GFP_KERNEL);
goto handled;
}
case WLAN_HT_ACTION_NOTIFY_CHANWIDTH: {
struct ieee80211_supported_band *sband;
u8 chanwidth = mgmt->u.action.u.ht_notify_cw.chanwidth;
enum ieee80211_sta_rx_bandwidth max_bw, new_bw;
+   struct sta_opmode_info sta_opmode;
 
/* If it doesn't support 40 MHz it can't change ... */
if (!(rx->sta->sta.ht_cap.cap &
@@ -2899,9 +2907,15 @@ 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.changed = STA_OPMODE_MAX_BW_CHANGED;
 
rate_control_rate_update(local, sband, rx->sta,
 IEEE80211_RC_BW_CHANGED);
+   cfg80211_sta_opmode_change_notify(sdata->dev,
+ rx->sta->addr,
+ _opmode,
+ GFP_KERNEL);
goto handled;
}
default:
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index b9276ac..5f5db8e 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -447,6 +447,7 @@ u32 __ieee80211_vht_handle_opmode(struct 
ieee80211_sub_if_data *sdata,
  enum nl80211_band band)
 {
enum ieee80211_sta_rx_bandwidth new_bw;
+   struct sta_opmode_info sta_opmode;
u32 changed = 0;
u8 nss;
 
@@ -460,7 +461,9 @@ u32 __ieee80211_vht_handle_opmode(struct 
ieee80211_sub_if_data *sdata,
 
if (sta->sta.rx_nss != nss) {
sta->sta.rx_nss = nss;
+   sta_opmode.rx_nss = nss;
changed |= IEEE80211_RC_NSS_CHANGED;
+   sta_opmode.changed |= STA_OPMODE_N_SS_CHANGED;
}
 
switch (opmode & IEEE80211_OPMODE_NOTIF_CHANWIDTH_MASK) {
@@ -481,9 +484,15 @@ 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;
changed |= IEEE80211_RC_BW_CHANGED;
+   sta_opmode.changed |= STA_OPMODE_MAX_BW_CHANGED;
}
 
+   if (sta_opmode.changed)
+   cfg80211_sta_opmode_change_notify(sdata->dev, sta->addr,
+ _opmode, GFP_KERNEL);
+
return changed;
 }
 
-- 
1.9.1

[PATCHv2 1/2] cfg80211: Add support to notify station's opmode change to userspace

[Tamizh chelvam]

ht/vht action frames will be sent to AP from station to notify
change of its ht/vht opmode(max bandwidth, smps mode or nss) modified
values. Currently these valuse used by driver/firmware for rate control
algorithm. This patch introduces NL80211_CMD_STA_OPMODE_CHANGED
command to notify those modified/current supported values(max bandwidth,
smps mode, max nss) to userspace application. This will be useful for the
application like steering, which closely monitoring station's capability
changes. Since the application has taken these values during station
association.

Signed-off-by: Tamizh chelvam 
---
v2:
  * Address Johannes comments.

 include/net/cfg80211.h   | 43 ++
 include/uapi/linux/nl80211.h | 12 ++
 net/wireless/nl80211.c   | 55 
 3 files changed, 110 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 81174f9..81caf86 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3517,6 +3517,35 @@ enum wiphy_vendor_command_flags {
 };
 
 /**
+ * enum wiphy_opmode_flag - Station's ht/vht operation mode information flags
+ *
+ * @STA_OPMODE_MAX_BW_CHANGED: Max Bandwidth changed
+ * @STA_OPMODE_SMPS_MODE_CHANGED: SMPS mode changed
+ * @STA_OPMODE_N_SS_CHANGED: max N_SS (number of spatial streams) changed
+ *
+ */
+enum wiphy_opmode_flag {
+   STA_OPMODE_MAX_BW_CHANGED   = BIT(0),
+   STA_OPMODE_SMPS_MODE_CHANGED= BIT(1),
+   STA_OPMODE_N_SS_CHANGED = BIT(2),
+};
+
+/**
+ * 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
+ * @rx_nss: new rx_nss value of a station
+ */
+
+struct sta_opmode_info {
+   u32 changed;
+   u8 smps_mode;
+   u8 bw;
+   u8 rx_nss;
+};
+
+/**
  * struct wiphy_vendor_command - vendor command definition
  * @info: vendor command identifying information, as used in nl80211
  * @flags: flags, see  wiphy_vendor_command_flags
@@ -5685,6 +5714,20 @@ void cfg80211_radar_event(struct wiphy *wiphy,
  struct cfg80211_chan_def *chandef, gfp_t gfp);
 
 /**
+ * cfg80211_sta_opmode_change_notify - STA's ht/vht operation mode change event
+ * @dev: network device
+ * @mac: MAC address of a station which opmode got modified
+ * @sta_opmode: station's current opmode value
+ * @gfp: context flags
+ *
+ * Driver should call this function when station's opmode modified via action
+ * frame.
+ */
+void cfg80211_sta_opmode_change_notify(struct net_device *dev, const u8 *mac,
+  struct sta_opmode_info *sta_opmode,
+  gfp_t gfp);
+
+/**
  * cfg80211_cac_event - Channel availability check (CAC) event
  * @netdev: network device
  * @chandef: chandef for the current channel
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index c587a61..b3b449f 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -992,6 +992,11 @@
  *
  * @NL80211_CMD_RELOAD_REGDB: Request that the regdb firmware file is reloaded.
  *
+ * @NL80211_CMD_STA_OPMODE_CHANGED: An event that notify station's
+ * ht opmode or vht opmode changes using any of _ATTR_SMPS_MODE,
+ * _ATTR_CHANNEL_WIDTH,_ATTR_NSS attributes with its
+ * address(specified in _ATTR_MAC).
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -1198,6 +1203,8 @@ enum nl80211_commands {
 
NL80211_CMD_RELOAD_REGDB,
 
+   NL80211_CMD_STA_OPMODE_CHANGED,
+
/* add new commands above here */
 
/* used to define NL80211_CMD_MAX below */
@@ -2153,6 +2160,9 @@ enum nl80211_commands {
  * @NL80211_ATTR_PMKR0_NAME: PMK-R0 Name for offloaded FT.
  * @NL80211_ATTR_PORT_AUTHORIZED: (reserved)
  *
+ * @NL80211_ATTR_NSS: Station's New/updated  RX_NSS value notified using this
+ * u8 attribute. This is used with %NL80211_CMD_STA_OPMODE_CHANGED.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2579,6 +2589,8 @@ enum nl80211_attrs {
NL80211_ATTR_PMKR0_NAME,
NL80211_ATTR_PORT_AUTHORIZED,
 
+   NL80211_ATTR_NSS,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ab0c687..733259f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -14887,6 +14887,61 @@ void cfg80211_ch_switch_started_notify(struct 
net_device *dev,
nlmsg_free(msg);
 }
 
+void cfg80211_sta_opmode_change_notify(struct net_device *dev, const u8 *mac,
+  struct sta_opmode_info *sta_opmode,
+   

Re: [v2] rtlwifi: btcoex: Fix some static warnings from Sparse

[Kalle Valo]

Ping-Ke Shih  wrote:

> From: Ping-Ke Shih 
> 
> Add 'static' or declaration to resolve the warnings, and remove two unused
> functions halbtc_set_macreg() and halbtc_get_macreg() exposed when they
> were made static.
> 
> Signed-off-by: Ping-Ke Shih 
> Acked-by: Larry Finger 

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

f2f6026af7a8 rtlwifi: btcoex: Fix some static warnings from Sparse

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

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

Re: [PATCH v2] rtlwifi: btcoex: Fix some static warnings from Sparse

[Larry Finger]

On 01/24/2018 08:49 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih 

Add 'static' or declaration to resolve the warnings, and remove two unused
functions halbtc_set_macreg() and halbtc_get_macreg() exposed when they
were made static.

Signed-off-by: Ping-Ke Shih 
---
The original subject of this patch is '[PATCH 07/10]' in previous
patchset, and other patches are applied excepcting to this one that Larry
suggested to add comments why two functions are revmoed, but the content is
unchanged.
---


Acked-by: Larry Finger 


  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 36 +++---
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |  4 +++
  2 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 73ef5b271f3b..1404729441a2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -29,7 +29,7 @@
   *Debug related function
   ***/
  
-const char *const gl_btc_wifi_bw_string[] = {

+static const char *const gl_btc_wifi_bw_string[] = {
"11bg",
"HT20",
"HT40",
@@ -37,7 +37,7 @@ const char *const gl_btc_wifi_bw_string[] = {
"HT160"
  };
  
-const char *const gl_btc_wifi_freq_string[] = {

+static const char *const gl_btc_wifi_freq_string[] = {
"2.4G",
"5G"
  };
@@ -156,7 +156,7 @@ static u8 halbtc_get_wifi_central_chnl(struct btc_coexist 
*btcoexist)
return chnl;
  }
  
-u8 rtl_get_hwpg_single_ant_path(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_single_ant_path(struct rtl_priv *rtlpriv)
  {
struct rtl_mod_params *mod_params = rtlpriv->cfg->mod_params;
  
@@ -171,12 +171,12 @@ u8 rtl_get_hwpg_single_ant_path(struct rtl_priv *rtlpriv)

return rtlpriv->btcoexist.btc_info.single_ant_path;
  }
  
-u8 rtl_get_hwpg_bt_type(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_bt_type(struct rtl_priv *rtlpriv)
  {
return rtlpriv->btcoexist.btc_info.bt_type;
  }
  
-u8 rtl_get_hwpg_ant_num(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_ant_num(struct rtl_priv *rtlpriv)
  {
struct rtl_mod_params *mod_params = rtlpriv->cfg->mod_params;
u8 num;
@@ -193,7 +193,7 @@ u8 rtl_get_hwpg_ant_num(struct rtl_priv *rtlpriv)
return num;
  }
  
-u8 rtl_get_hwpg_package_type(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_package_type(struct rtl_priv *rtlpriv)
  {
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
  
@@ -504,7 +504,7 @@ static u32 halbtc_get_bt_forbidden_slot_val(void *btc_context)

return btcoexist->bt_info.bt_forb_slot_val;
  }
  
-u32 halbtc_get_wifi_link_status(struct btc_coexist *btcoexist)

+static u32 halbtc_get_wifi_link_status(struct btc_coexist *btcoexist)
  {
/* return value:
 * [31:16] => connected port number
@@ -980,7 +980,8 @@ static void halbtc_write_4byte(void *bt_context, u32 
reg_addr, u32 data)
rtl_write_dword(rtlpriv, reg_addr, data);
  }
  
-void halbtc_write_local_reg_1byte(void *btc_context, u32 reg_addr, u8 data)

+static void halbtc_write_local_reg_1byte(void *btc_context, u32 reg_addr,
+u8 data)
  {
struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -993,22 +994,6 @@ void halbtc_write_local_reg_1byte(void *btc_context, u32 
reg_addr, u8 data)
rtl_write_byte(rtlpriv, reg_addr, data);
  }
  
-void halbtc_set_macreg(void *btc_context, u32 reg_addr, u32 bit_mask, u32 data)

-{
-   struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
-   struct rtl_priv *rtlpriv = btcoexist->adapter;
-
-   rtl_set_bbreg(rtlpriv->mac80211.hw, reg_addr, bit_mask, data);
-}
-
-u32 halbtc_get_macreg(void *btc_context, u32 reg_addr, u32 bit_mask)
-{
-   struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
-   struct rtl_priv *rtlpriv = btcoexist->adapter;
-
-   return rtl_get_bbreg(rtlpriv->mac80211.hw, reg_addr, bit_mask);
-}
-
  static void halbtc_set_bbreg(void *bt_context, u32 reg_addr, u32 bit_mask,
 u32 data)
  {
@@ -1054,6 +1039,7 @@ static void halbtc_fill_h2c_cmd(void *bt_context, u8 
element_id,
cmd_len, cmd_buf);
  }
  
+static

  void halbtc_set_bt_reg(void *btc_context, u8 reg_type, u32 offset, u32 
set_val)
  {
struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
@@ -1093,7 +1079,7 @@ static void halbtc_display_dbg_msg(void *bt_context, u8 
disp_type,
}
  }
  
-bool halbtc_under_ips(struct btc_coexist *btcoexist)

+static bool halbtc_under_ips(struct btc_coexist *btcoexist)
  {
struct rtl_priv 

[PATCH v3 2/3] cfg80211/nl80211: Optional authentication offload to userspace

[Jouni Malinen]

From: Srinivas Dasari 

This interface allows the host driver to offload the authentication to
user space. This is exclusively defined for host drivers that do not
define separate commands for authentication and association, but rely on
userspace SME (e.g., in wpa_supplicant for the ~WPA_DRIVER_FLAGS_SME
case) for the authentication to happen. This can be used to implement
SAE without full implementation in the kernel/firmware while still being
able to use NL80211_CMD_CONNECT with driver-based BSS selection.

Host driver sends NL80211_CMD_EXTERNAL_AUTH event to start/abort
authentication to the port on which connect is triggered and status
of authentication is further indicated by user space to host
driver through the same command response interface.

User space entities advertise this capability through the
NL80211_ATTR_EXTERNAL_AUTH_SUPP flag in the NL80211_CMD_CONNECT request.
Host drivers shall look at this capability to offload the authentication.

Signed-off-by: Srinivas Dasari 
Signed-off-by: Jouni Malinen 
---
 include/net/cfg80211.h   | 54 +--
 include/uapi/linux/nl80211.h | 48 
 net/wireless/nl80211.c   | 88 
 net/wireless/rdev-ops.h  | 15 
 net/wireless/trace.h | 23 
 5 files changed, 225 insertions(+), 3 deletions(-)

v3:
- rename CONNECT_REQ_EXTERNAL_AUTH_SUPP to
  CONNECT_REQ_EXTERNAL_AUTH_SUPPORT
- rename NL80211_ATTR_EXTERNAL_AUTH_SUPP to
  NL80211_ATTR_EXTERNAL_AUTH_SUPPORT
- remove NL80211_EXT_FEATURE_EXTERNAL_AUTH
- unicast netlink events to the port used for the connect command

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ab30a22..1aebcf1 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1903,11 +1903,16 @@ struct cfg80211_auth_request {
  * @ASSOC_REQ_DISABLE_HT:  Disable HT (802.11n)
  * @ASSOC_REQ_DISABLE_VHT:  Disable VHT
  * @ASSOC_REQ_USE_RRM: Declare RRM capability in this association
+ * @CONNECT_REQ_EXTERNAL_AUTH_SUPPORT: User space indicates external
+ *  authentication capability. Drivers can offload authentication to
+ *  userspace if this flag is set. Only applicable for cfg80211_connect()
+ *  request (connect callback).
  */
 enum cfg80211_assoc_req_flags {
-   ASSOC_REQ_DISABLE_HT= BIT(0),
-   ASSOC_REQ_DISABLE_VHT   = BIT(1),
-   ASSOC_REQ_USE_RRM   = BIT(2),
+   ASSOC_REQ_DISABLE_HT= BIT(0),
+   ASSOC_REQ_DISABLE_VHT   = BIT(1),
+   ASSOC_REQ_USE_RRM   = BIT(2),
+   CONNECT_REQ_EXTERNAL_AUTH_SUPPORT   = BIT(3),
 };
 
 /**
@@ -2599,6 +2604,33 @@ struct cfg80211_pmk_conf {
 };
 
 /**
+ * struct cfg80211_external_auth_params - Trigger External authentication.
+ *
+ * Commonly used across the external auth request and event interfaces.
+ *
+ * @action: action type / trigger for external authentication. Only significant
+ * for the authentication request event interface (driver to user space).
+ * @bssid: BSSID of the peer with which the authentication has
+ * to happen. Used by both the authentication request event and
+ * authentication response command interface.
+ * @ssid: SSID of the AP.  Used by both the authentication request event and
+ * authentication response command interface.
+ * @key_mgmt_suite: AKM suite of the respective authentication. Used by the
+ * authentication request event interface.
+ * @status: status code, %WLAN_STATUS_SUCCESS for successful authentication,
+ * use %WLAN_STATUS_UNSPECIFIED_FAILURE if user space cannot give you
+ * the real status code for failures. Used only for the authentication
+ * response command interface (user space to driver).
+ */
+struct cfg80211_external_auth_params {
+   enum nl80211_external_auth_action action;
+   u8 bssid[ETH_ALEN] __aligned(2);
+   struct cfg80211_ssid ssid;
+   unsigned int key_mgmt_suite;
+   u16 status;
+};
+
+/**
  * struct cfg80211_ops - backend description for wireless configuration
  *
  * This struct is registered by fullmac card drivers and/or wireless stacks
@@ -2921,6 +2953,9 @@ struct cfg80211_pmk_conf {
  * (invoked with the wireless_dev mutex held)
  * @del_pmk: delete the previously configured PMK for the given authenticator.
  * (invoked with the wireless_dev mutex held)
+ *
+ * @external_auth: indicates result of offloaded authentication processing from
+ * user space
  */
 struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -3214,6 +3249,8 @@ struct cfg80211_ops {
   const struct cfg80211_pmk_conf *conf);
int (*del_pmk)(struct wiphy *wiphy, struct net_device *dev,
   const u8 *aa);
+   int (*external_auth)(struct wiphy *wiphy, struct 

[PATCH v3 1/3] nl80211: Introduce scan flags to emphasize requested scan behavior

[Jouni Malinen]

From: Sunil Dutt 

This commit defines new scan flags (LOW_SPAN, LOW_POWER, HIGH_LATENCY)
to emphasize the requested scan behavior for the driver. These flags
are optional and are mutually exclusive. The implementation of the
respective functionality can be driver/hardware specific.

These flags can be used to control the compromise between how long
a scan takes, how much power it uses, and high accurate/complete
the scan is in finding the BSSs.

Signed-off-by: Sunil Dutt 
Signed-off-by: Jouni Malinen 
---
 include/uapi/linux/nl80211.h | 28 +++-
 net/wireless/nl80211.c   | 13 +++--
 2 files changed, 38 insertions(+), 3 deletions(-)

v3:
- rebased (moved this scan related change to the top of the series)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index c587a61..6f60503 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4945,6 +4945,9 @@ enum nl80211_feature_flags {
  * probe request tx deferral and suppression
  * @NL80211_EXT_FEATURE_MFP_OPTIONAL: Driver supports the %NL80211_MFP_OPTIONAL
  * value in %NL80211_ATTR_USE_MFP.
+ * @NL80211_EXT_FEATURE_LOW_SPAN_SCAN: Driver supports low span scan.
+ * @NL80211_EXT_FEATURE_LOW_POWER_SCAN: Driver supports low power scan.
+ * @NL80211_EXT_FEATURE_HIGH_ACCURACY_SCAN: Driver supports high accuracy scan.
  *
  * @NUM_NL80211_EXT_FEATURES: number of extended features.
  * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -4972,6 +4975,9 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_OCE_PROBE_REQ_HIGH_TX_RATE,
NL80211_EXT_FEATURE_OCE_PROBE_REQ_DEFERRAL_SUPPRESSION,
NL80211_EXT_FEATURE_MFP_OPTIONAL,
+   NL80211_EXT_FEATURE_LOW_SPAN_SCAN,
+   NL80211_EXT_FEATURE_LOW_POWER_SCAN,
+   NL80211_EXT_FEATURE_HIGH_ACCURACY_SCAN,
 
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
@@ -5032,6 +5038,10 @@ enum nl80211_timeout_reason {
  * of NL80211_CMD_TRIGGER_SCAN and NL80211_CMD_START_SCHED_SCAN
  * requests.
  *
+ * NL80211_SCAN_FLAG_LOW_SPAN, NL80211_SCAN_FLAG_LOW_POWER, and
+ * NL80211_SCAN_FLAG_HIGH_ACCURACY flags are exclusive of each other, i.e., 
only
+ * one of them can be used in the request.
+ *
  * @NL80211_SCAN_FLAG_LOW_PRIORITY: scan request has low priority
  * @NL80211_SCAN_FLAG_FLUSH: flush cache before scanning
  * @NL80211_SCAN_FLAG_AP: force a scan even if the interface is configured
@@ -5059,7 +5069,20 @@ enum nl80211_timeout_reason {
  * and suppression (if it has received a broadcast Probe Response frame,
  * Beacon frame or FILS Discovery frame from an AP that the STA considers
  * a suitable candidate for (re-)association - suitable in terms of
- * SSID and/or RSSI
+ * SSID and/or RSSI.
+ * @NL80211_SCAN_FLAG_LOW_SPAN: Span corresponds to the total time taken to
+ * accomplish the scan. Thus, this flag intends the driver to perform the
+ * scan request with lesser span/duration. It is specific to the driver
+ * implementations on how this is accomplished. Scan accuracy may get
+ * impacted with this flag.
+ * @NL80211_SCAN_FLAG_LOW_POWER: This flag intends the scan attempts to consume
+ * optimal possible power. Drivers can resort to their specific means to
+ * optimize the power. Scan accuracy may get impacted with this flag.
+ * @NL80211_SCAN_FLAG_HIGH_ACCURACY: Accuracy here intends to the extent of 
scan
+ * results obtained. Thus HIGH_ACCURACY scan flag aims to get maximum
+ * possible scan results. This flag hints the driver to use the best
+ * possible scan configuration to improve the accuracy in scanning.
+ * Latency and power use may get impacted with this flag.
  */
 enum nl80211_scan_flags {
NL80211_SCAN_FLAG_LOW_PRIORITY  = 1<<0,
@@ -5070,6 +5093,9 @@ enum nl80211_scan_flags {
NL80211_SCAN_FLAG_ACCEPT_BCAST_PROBE_RESP   = 1<<5,
NL80211_SCAN_FLAG_OCE_PROBE_REQ_HIGH_TX_RATE= 1<<6,
NL80211_SCAN_FLAG_OCE_PROBE_REQ_DEFERRAL_SUPPRESSION= 1<<7,
+   NL80211_SCAN_FLAG_LOW_SPAN  = 1<<8,
+   NL80211_SCAN_FLAG_LOW_POWER = 1<<9,
+   NL80211_SCAN_FLAG_HIGH_ACCURACY = 1<<10,
 };
 
 /**
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c084dd2..a83e758 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6712,8 +6712,17 @@ nl80211_check_scan_flags(struct wiphy *wiphy, struct 
wireless_dev *wdev,
 
*flags = nla_get_u32(attrs[NL80211_ATTR_SCAN_FLAGS]);
 
-   if ((*flags & NL80211_SCAN_FLAG_LOW_PRIORITY) &&
-   !(wiphy->features & NL80211_FEATURE_LOW_PRIORITY_SCAN))
+   if (((*flags & NL80211_SCAN_FLAG_LOW_PRIORITY) &&
+!(wiphy->features & NL80211_FEATURE_LOW_PRIORITY_SCAN)) ||
+   

[PATCH v3 3/3] nl80211: Allow SAE Authentication for NL80211_CMD_CONNECT

[Jouni Malinen]

From: Srinivas Dasari 

This commit allows SAE Authentication for NL80211_CMD_CONNECT
interface, provided host driver advertises the support.

Host drivers offload the SAE authentication to user space
through NL80211_CMD_EXTERNAL_AUTH interface and thus expect
the user space to advertise support to handle offload through
NL80211_ATTR_EXTERNAL_AUTH_SUPPORT in NL80211_CMD_CONNECT
request. Such drivers should reject the connect request on no
offload support from user space.

Signed-off-by: Srinivas Dasari 
Signed-off-by: Jouni Malinen 
---
 net/wireless/nl80211.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

v3:
- clarified commit message to cover NL80211_ATTR_EXTERNAL_AUTH_SUPPORT
  in NL80211_CMD_CONNECT and potential need to reject the command with
  missing support

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8b10598..7478a6d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3918,9 +3918,10 @@ static bool nl80211_valid_auth_type(struct 
cfg80211_registered_device *rdev,
return false;
return true;
case NL80211_CMD_CONNECT:
-   /* SAE not supported yet */
-   if (auth_type == NL80211_AUTHTYPE_SAE)
+   if (!(rdev->wiphy.features & NL80211_FEATURE_SAE) &&
+   auth_type == NL80211_AUTHTYPE_SAE)
return false;
+
/* FILS with SK PFS or PK not supported yet */
if (auth_type == NL80211_AUTHTYPE_FILS_SK_PFS ||
auth_type == NL80211_AUTHTYPE_FILS_PK)
-- 
2.7.4

RE: [EXT] Re: [2/2] mwifiex: use more_rx_task_flag to avoid USB RX stall

[Ganapathi Bhat]

Hi Kalle,

> -Original Message-
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Thursday, January 25, 2018 6:29 PM
> To: Ganapathi Bhat
> Cc: linux-wireless@vger.kernel.org; Brian Norris; Cathy Luo; Xinming Hu;
> Zhiyuan Yang; James Cao; Mangesh Malusare; Shrenik Shikhare
> Subject: Re: [EXT] Re: [2/2] mwifiex: use more_rx_task_flag to avoid USB RX
> stall
>
> Ganapathi Bhat  writes:
>
> >> > The above scenario occurs in some platforms where the RX processing
> >> > is comparitively slower. This results in RX stall in driver,
> >> > command/TX timeouts in firmware. The above scenario is introduced
> >> > after commit
> >> > c7dbdcb2a4e1
> >> > ("mwifiex: schedule rx_work on RX interrupt for USB")
> >> >
> >> > To fix this set a new more_rx_task_flag whenever RX data callback
> >> > is trying to schedule rx_work but rx_processing is not yet cleared.
> >> > This will let the current rx_work(which was waiting for
> >> > rx_proc_lock) to loopback and process newly arrived RX packets.
> >> >
> >> > Signed-off-by: Cathy Luo 
> >> > Signed-off-by: Ganapathi Bhat 
> >>
> >> I can't find any commit with id c7dbdcb2a4e1, is it correct?
> >
> > Correct. Actually the commit id c7dbdcb2a4e1 is the PATCH [1/2] sent in this
> series.
>
> Actually the commit id will be different, I just tested it to be sure:
>
> $ git reset --hard master
> HEAD is now at b69c1df47281 brcmfmac: separate firmware errors from i/o
> errors $ git am -s -3 1.patch
> Applying: mwifiex: schedule rx_work on RX interrupt for USB $ git log --
> oneline -1 | cat
> 676bc4833907 mwifiex: schedule rx_work on RX interrupt for USB $ git reset -
> -hard master HEAD is now at b69c1df47281 brcmfmac: separate firmware
> errors from i/o errors $ git am -s -3 1.patch
> Applying: mwifiex: schedule rx_work on RX interrupt for USB $ git log --
> oneline -1 | cat
> 74c5fc1d45b4 mwifiex: schedule rx_work on RX interrupt for USB $
>
> So the date, and most likely also the commiter, is included when calculating
> the hash. So you can't really refer to uncommited patches using a commit id
> as the id is determined only once the maintainer applies the patch.
Ok. So, what can be done in this case. Should we wait for 1st patch to be 
committed and then send v3 of second patch?
>
> --
> Kalle Valo
Regards,
Ganapathi

Re: [EXT] Re: [2/2] mwifiex: use more_rx_task_flag to avoid USB RX stall

[Kalle Valo]

Ganapathi Bhat  writes:

>> > The above scenario occurs in some platforms where the RX processing is
>> > comparitively slower. This results in RX stall in driver, command/TX
>> > timeouts in firmware. The above scenario is introduced after commit
>> > c7dbdcb2a4e1
>> > ("mwifiex: schedule rx_work on RX interrupt for USB")
>> >
>> > To fix this set a new more_rx_task_flag whenever RX data callback is
>> > trying to schedule rx_work but rx_processing is not yet cleared. This
>> > will let the current rx_work(which was waiting for
>> > rx_proc_lock) to loopback and process newly arrived RX packets.
>> >
>> > Signed-off-by: Cathy Luo 
>> > Signed-off-by: Ganapathi Bhat 
>>
>> I can't find any commit with id c7dbdcb2a4e1, is it correct?
>
> Correct. Actually the commit id c7dbdcb2a4e1 is the PATCH [1/2] sent in this 
> series.

Actually the commit id will be different, I just tested it to be sure:

$ git reset --hard master
HEAD is now at b69c1df47281 brcmfmac: separate firmware errors from i/o errors
$ git am -s -3 1.patch
Applying: mwifiex: schedule rx_work on RX interrupt for USB
$ git log --oneline -1 | cat
676bc4833907 mwifiex: schedule rx_work on RX interrupt for USB
$ git reset --hard master
HEAD is now at b69c1df47281 brcmfmac: separate firmware errors from i/o errors
$ git am -s -3 1.patch
Applying: mwifiex: schedule rx_work on RX interrupt for USB
$ git log --oneline -1 | cat
74c5fc1d45b4 mwifiex: schedule rx_work on RX interrupt for USB
$ 

So the date, and most likely also the commiter, is included when
calculating the hash. So you can't really refer to uncommited patches
using a commit id as the id is determined only once the maintainer
applies the patch.

-- 
Kalle Valo

[PATCH v3 2/2] ath10k: Add support for Ubiquiti rebranded QCA988X v2

[Tobias Schramm]

Some modern Ubiquiti devices contain a rebranded QCA988X rev2 with
a custom Ubiquiti vendor and device id. This patch adds support for
those devices, treating them as a QCA988X v2.

Signed-off-by: Tobias Schramm 
---
 drivers/net/wireless/ath/ath10k/core.c | 24 
 drivers/net/wireless/ath/ath10k/hw.h   |  1 +
 drivers/net/wireless/ath/ath10k/pci.c  |  4 
 3 files changed, 29 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index b29fdbd21ead..9fb38f2c1d6e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -52,6 +52,30 @@ MODULE_PARM_DESC(cryptmode, "Crypto mode: 0-hardware, 
1-software");
 MODULE_PARM_DESC(rawmode, "Use raw 802.11 frame datapath");
 
 static const struct ath10k_hw_params ath10k_hw_params_list[] = {
+   {
+   .id = QCA988X_HW_2_0_VERSION,
+   .dev_id = QCA988X_2_0_DEVICE_ID_UBNT,
+   .name = "qca988x hw2.0",
+   .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
+   .uart_pin = 7,
+   .cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
+   .otp_exe_param = 0,
+   .channel_counters_freq_hz = 88000,
+   .max_probe_resp_desc_thres = 0,
+   .cal_data_len = 2116,
+   .fw = {
+   .dir = QCA988X_HW_2_0_FW_DIR,
+   .board = QCA988X_HW_2_0_BOARD_DATA_FILE,
+   .board_size = QCA988X_BOARD_DATA_SZ,
+   .board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
+   },
+   .hw_ops = _ops,
+   .decap_align_bytes = 4,
+   .spectral_bin_discard = 0,
+   .vht160_mcs_rx_highest = 0,
+   .vht160_mcs_tx_highest = 0,
+   .n_cipher_suites = 8,
+   },
{
.id = QCA988X_HW_2_0_VERSION,
.dev_id = QCA988X_2_0_DEVICE_ID,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h 
b/drivers/net/wireless/ath/ath10k/hw.h
index 05f26e5858ad..5ae3b56acc19 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -22,6 +22,7 @@
 
 #define ATH10K_FW_DIR  "ath10k"
 
+#define QCA988X_2_0_DEVICE_ID_UBNT   (0x11ac)
 #define QCA988X_2_0_DEVICE_ID   (0x003c)
 #define QCA6164_2_1_DEVICE_ID   (0x0041)
 #define QCA6174_2_1_DEVICE_ID   (0x003e)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index ffea348b2190..e28e2f5f09c5 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -52,6 +52,7 @@ MODULE_PARM_DESC(reset_mode, "0: auto, 1: warm only (default: 
0)");
 #define ATH10K_PCI_NUM_WARM_RESET_ATTEMPTS 3
 
 static const struct pci_device_id ath10k_pci_id_table[] = {
+   { PCI_VDEVICE(UBIQUITI, QCA988X_2_0_DEVICE_ID_UBNT) }, /* PCI-E QCA988X 
V2 (Ubiquiti branded) */
{ PCI_VDEVICE(ATHEROS, QCA988X_2_0_DEVICE_ID) }, /* PCI-E QCA988X V2 */
{ PCI_VDEVICE(ATHEROS, QCA6164_2_1_DEVICE_ID) }, /* PCI-E QCA6164 V2.1 
*/
{ PCI_VDEVICE(ATHEROS, QCA6174_2_1_DEVICE_ID) }, /* PCI-E QCA6174 V2.1 
*/
@@ -68,6 +69,7 @@ static const struct ath10k_pci_supp_chip 
ath10k_pci_supp_chips[] = {
 * hacks. ath10k doesn't have them and these devices crash horribly
 * because of that.
 */
+   { QCA988X_2_0_DEVICE_ID_UBNT, QCA988X_HW_2_0_CHIP_ID_REV },
{ QCA988X_2_0_DEVICE_ID, QCA988X_HW_2_0_CHIP_ID_REV },
 
{ QCA6164_2_1_DEVICE_ID, QCA6174_HW_2_1_CHIP_ID_REV },
@@ -1977,6 +1979,7 @@ static int ath10k_pci_get_num_banks(struct ath10k *ar)
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 
switch (ar_pci->pdev->device) {
+   case QCA988X_2_0_DEVICE_ID_UBNT:
case QCA988X_2_0_DEVICE_ID:
case QCA99X0_2_0_DEVICE_ID:
case QCA9888_2_0_DEVICE_ID:
@@ -3208,6 +3211,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
u32 (*targ_cpu_to_ce_addr)(struct ath10k *ar, u32 addr);
 
switch (pci_dev->device) {
+   case QCA988X_2_0_DEVICE_ID_UBNT:
case QCA988X_2_0_DEVICE_ID:
hw_rev = ATH10K_HW_QCA988X;
pci_ps = false;
-- 
2.16.0

[PATCH v3 1/2] pci: Add vendor id of Ubiquiti Networks

[Tobias Schramm]

Signed-off-by: Tobias Schramm 
---
 include/linux/pci_ids.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index ab20dc5db423..35871adfdc86 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -149,6 +149,8 @@
 #define PCI_VENDOR_ID_DYNALINK 0x0675
 #define PCI_DEVICE_ID_DYNALINK_IS64PH  0x1702
 
+#define PCI_VENDOR_ID_UBIQUITI 0x0777
+
 #define PCI_VENDOR_ID_BERKOM   0x0871
 #define PCI_DEVICE_ID_BERKOM_A1T   0xffa1
 #define PCI_DEVICE_ID_BERKOM_T_CONCEPT 0xffa2
-- 
2.16.0

[PATCH v3 0/2] ath10k: Add support for Ubiquiti-branded QCA988X

[Tobias Schramm]

A lot of more modern Ubiquiti AirMAX wireless devices contain a rebranded
QCA988X with changed PCI vendor and device id.
This patch adds support for those chips by treating them as QCA988X rev2
radios.

Changes since v1:
 * Send patch to more people and lists

Changes since v2:
 * Rename PCI_VENDOR_ID_UBNT to PCI_VENDOR_ID_UBIQUITI

Tobias Schramm (2):
  pci: Add vendor id of Ubiquiti Networks
  ath10k: Add support for Ubiquiti rebranded QCA988X v2

 drivers/net/wireless/ath/ath10k/core.c | 24 
 drivers/net/wireless/ath/ath10k/hw.h   |  1 +
 drivers/net/wireless/ath/ath10k/pci.c  |  4 
 include/linux/pci_ids.h|  2 ++
 4 files changed, 31 insertions(+)

-- 
2.16.0

Re: [PATCH v2 2/2] ath10k: Add support for Uiquiti rebranded QCA988X v2

[Tobias Schramm]

True, I'll fix it in v3

2018-01-25 11:49 GMT+01:00 Arend van Spriel :
> On 1/25/2018 8:41 AM, Tobias Schramm wrote:
>>
>> Some modern Ubiquiti devices contain a rebranded QCA988X rev2 with
>
>
> You dropped a 'b' in the subject, ie. Uiquiti.
>
> Regards,
> Arend
>

Re: [PATCH v2 1/2] pci: Add vendor id of Ubiquiti Networks

[Tobias Schramm]

Ok, will change that to PCI_VENDOR_ID_UBIQUITI in v3

Re: [PATCH v2 2/2] ath10k: Add support for Uiquiti rebranded QCA988X v2

[Arend van Spriel]

On 1/25/2018 8:41 AM, Tobias Schramm wrote:

Some modern Ubiquiti devices contain a rebranded QCA988X rev2 with


You dropped a 'b' in the subject, ie. Uiquiti.

Regards,
Arend

Re: [PATCH v2 1/2] pci: Add vendor id of Ubiquiti Networks

[Arend van Spriel]

On 1/25/2018 8:41 AM, Tobias Schramm wrote:

Signed-off-by: Tobias Schramm 
---
  include/linux/pci_ids.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index ab20dc5db423..6b01ac1e9bce 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -149,6 +149,8 @@
  #define PCI_VENDOR_ID_DYNALINK0x0675
  #define PCI_DEVICE_ID_DYNALINK_IS64PH 0x1702

+#define PCI_VENDOR_ID_UBNT 0x0777


Guess this is the stock symbol, but that does not seem a common approach 
here. Why not just PCI_VENDOR_ID_UBIQUITI?


Regards,
Arend

[PATCH v2 8/8] mt76: validate rx CCMP PN

[Felix Fietkau]

Apparently hardware does not perform CCMP PN validation in hardware, so
we need to take care of this in the driver. This is important for
protecting against replay attacks.

Since validation of fragmented frames is more complex, the CCMP header
for those is preserved. To keep the counter in sync, the first fragment
is verified by both mt76 and mac80211, and all other fragments only by
mac80211.

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/mediatek/mt76/mac80211.c| 65 
 drivers/net/wireless/mediatek/mt76/mt76.h| 12 -
 drivers/net/wireless/mediatek/mt76/mt76x2_init.c |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x2_mac.c  | 61 +-
 drivers/net/wireless/mediatek/mt76/mt76x2_main.c |  1 +
 5 files changed, 125 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c 
b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 77f1be161009..5fcb2deb89a2 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -384,6 +384,27 @@ int mt76_get_survey(struct ieee80211_hw *hw, int idx,
 }
 EXPORT_SYMBOL_GPL(mt76_get_survey);
 
+void mt76_wcid_key_setup(struct mt76_dev *dev, struct mt76_wcid *wcid,
+struct ieee80211_key_conf *key)
+{
+   struct ieee80211_key_seq seq;
+   int i;
+
+   wcid->rx_check_pn = false;
+
+   if (!key)
+   return;
+
+   if (key->cipher == WLAN_CIPHER_SUITE_CCMP)
+   wcid->rx_check_pn = true;
+
+   for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
+   ieee80211_get_key_rx_seq(key, i, );
+   memcpy(wcid->rx_key_pn[i], seq.ccmp.pn, sizeof(seq.ccmp.pn));
+   }
+}
+EXPORT_SYMBOL(mt76_wcid_key_setup);
+
 static struct ieee80211_sta *mt76_rx_convert(struct sk_buff *skb)
 {
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
@@ -410,6 +431,45 @@ static struct ieee80211_sta *mt76_rx_convert(struct 
sk_buff *skb)
return wcid_to_sta(mstat.wcid);
 }
 
+static int
+mt76_check_ccmp_pn(struct sk_buff *skb)
+{
+   struct mt76_rx_status *status = (struct mt76_rx_status *) skb->cb;
+   struct mt76_wcid *wcid = status->wcid;
+   struct ieee80211_hdr *hdr;
+   int ret;
+
+   if (!(status->flag & RX_FLAG_DECRYPTED))
+   return 0;
+
+   if (!wcid || !wcid->rx_check_pn)
+   return 0;
+
+   if (!(status->flag & RX_FLAG_IV_STRIPPED)) {
+   /*
+* Validate the first fragment both here and in mac80211
+* All further fragments will be validated by mac80211 only.
+*/
+   hdr = (struct ieee80211_hdr *) skb->data;
+   if (ieee80211_is_frag(hdr) &&
+   !ieee80211_is_first_frag(hdr->frame_control))
+   return 0;
+   }
+
+   BUILD_BUG_ON(sizeof(status->iv) != sizeof(wcid->rx_key_pn[0]));
+   ret = memcmp(status->iv, wcid->rx_key_pn[status->tid],
+sizeof(status->iv));
+   if (ret <= 0)
+   return -EINVAL; /* replay */
+
+   memcpy(wcid->rx_key_pn[status->tid], status->iv, sizeof(status->iv));
+
+   if (status->flag & RX_FLAG_IV_STRIPPED)
+   status->flag |= RX_FLAG_PN_VALIDATED;
+
+   return 0;
+}
+
 void mt76_rx_complete(struct mt76_dev *dev, struct sk_buff_head *frames,
  int queue)
 {
@@ -421,6 +481,11 @@ void mt76_rx_complete(struct mt76_dev *dev, struct 
sk_buff_head *frames,
napi = >napi[queue];
 
while ((skb = __skb_dequeue(frames)) != NULL) {
+   if (mt76_check_ccmp_pn(skb)) {
+   dev_kfree_skb(skb);
+   continue;
+   }
+
sta = mt76_rx_convert(skb);
ieee80211_rx_napi(dev->hw, sta, skb, napi);
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h 
b/drivers/net/wireless/mediatek/mt76/mt76.h
index af98bc65c2e1..129015c9d116 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -131,6 +131,9 @@ struct mt76_wcid {
 
u8 sta:1;
 
+   u8 rx_check_pn;
+   u8 rx_key_pn[IEEE80211_NUM_TIDS][6];
+
__le16 tx_rate;
bool tx_rate_set;
u8 tx_rate_nss;
@@ -279,12 +282,14 @@ struct mt76_rx_status {
 
unsigned long reorder_time;
 
-   u8 aggr;
+   u8 iv[6];
+
+   u8 aggr:1;
u8 tid;
u16 seqno;
 
-   u32 flag;
u16 freq;
+   u32 flag;
u8 enc_flags;
u8 encoding:2, bw:3;
u8 rate_idx;
@@ -413,6 +418,9 @@ int mt76_rx_aggr_start(struct mt76_dev *dev, struct 
mt76_wcid *wcid, u8 tid,
   u16 ssn, u8 size);
 void mt76_rx_aggr_stop(struct mt76_dev *dev, struct mt76_wcid *wcid, u8 tid);
 
+void mt76_wcid_key_setup(struct mt76_dev *dev, struct mt76_wcid *wcid,
+struct 

[PATCH v2 1/2] mwifiex: schedule rx_work on RX interrupt for USB

[Ganapathi Bhat]

From: Shrenik Shikhare 

There is race for data_received flag between main thread and
RX data interrupt(mwifiex_usb_rx_complete()):
1. USB received an RX data interrupt, set data_received flag
2. main thread checks data_received, if set queues rx_work
3. rx worker thread independently start processing rx_data_q
4. rx work exits (once rx_data_q is empty)
5. main thread resets the data_received flag(after #2)
6. Now at the corner case there will be high RX data interrupts
between #4 and #5
7. Driver stops submitting URBs to firmware, once rx_pending
exceeds HIGH_RX_PENDING
8. The flag data_received(cleared in #5) will remain unset since
there will be no interrupts from firmware to set it(after #7)

Above scenario causes RX stall in driver, which will finally
result in command/TX timeouts in firmware.

As a fix, queue rx_work directly in mwifiex_usb_rx_complete()
callback, instead in the main thread. This removes dependency
of RX processing on data_received flag.

Signed-off-by: Cathy Luo 
Signed-off-by: Ganapathi Bhat 
---
v2: same as v1
---
 drivers/net/wireless/marvell/mwifiex/main.c | 7 ---
 drivers/net/wireless/marvell/mwifiex/main.h | 1 +
 drivers/net/wireless/marvell/mwifiex/usb.c  | 2 ++
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 12e7399..6e6e1a7 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -171,7 +171,7 @@ void mwifiex_queue_main_work(struct mwifiex_adapter 
*adapter)
 }
 EXPORT_SYMBOL_GPL(mwifiex_queue_main_work);
 
-static void mwifiex_queue_rx_work(struct mwifiex_adapter *adapter)
+void mwifiex_queue_rx_work(struct mwifiex_adapter *adapter)
 {
unsigned long flags;
 
@@ -183,6 +183,7 @@ static void mwifiex_queue_rx_work(struct mwifiex_adapter 
*adapter)
queue_work(adapter->rx_workqueue, >rx_work);
}
 }
+EXPORT_SYMBOL_GPL(mwifiex_queue_rx_work);
 
 static int mwifiex_process_rx(struct mwifiex_adapter *adapter)
 {
@@ -283,10 +284,10 @@ int mwifiex_main_process(struct mwifiex_adapter *adapter)
mwifiex_process_hs_config(adapter);
if (adapter->if_ops.process_int_status)
adapter->if_ops.process_int_status(adapter);
+   if (adapter->rx_work_enabled && adapter->data_received)
+   mwifiex_queue_rx_work(adapter);
}
 
-   if (adapter->rx_work_enabled && adapter->data_received)
-   mwifiex_queue_rx_work(adapter);
 
/* Need to wake up the card ? */
if ((adapter->ps_state == PS_STATE_SLEEP) &&
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 6b5539b..66ba95c 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1667,6 +1667,7 @@ u8 mwifiex_adjust_data_rate(struct mwifiex_private *priv,
 void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter);
 void *mwifiex_alloc_dma_align_buf(int rx_len, gfp_t flags);
 void mwifiex_queue_main_work(struct mwifiex_adapter *adapter);
+void mwifiex_queue_rx_work(struct mwifiex_adapter *adapter);
 int mwifiex_get_wakeup_reason(struct mwifiex_private *priv, u16 action,
  int cmd_type,
  struct mwifiex_ds_wakeup_reason *wakeup_reason);
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c 
b/drivers/net/wireless/marvell/mwifiex/usb.c
index 4bc2448..d20fda1 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -144,6 +144,8 @@ static int mwifiex_usb_recv(struct mwifiex_adapter *adapter,
skb_queue_tail(>rx_data_q, skb);
adapter->data_received = true;
atomic_inc(>rx_pending);
+   if (adapter->rx_work_enabled)
+   mwifiex_queue_rx_work(adapter);
break;
default:
mwifiex_dbg(adapter, ERROR,
-- 
1.9.1

[PATCH v2 2/2] mwifiex: use more_rx_task_flag to avoid USB RX stall

[Ganapathi Bhat]

From: Shrenik Shikhare 

There is a race condition for acquiring rx_proc_lock between
rx worker thread and USB RX data interrupt
(mwifiex_usb_rx_complete):

1. USB receives an RX data interrupt, queues rx_work
2. rx_work empties rx_data_q, tries to acquire rx_proc_lock (to
clear rx_processing flag)
3. While #2 is yet to acquire rx_proc_lock, driver receives
continuous RX data interupts(mwifiex_usb_rx_complete)
3. For each interrupt at #3, driver acquires rx_proc_lock(it gets
the lock since it is in interrupt context), tries to queue
rx_work, but fails to do so since rx_processing is still set(#2)
4. When rx_pending exceeds HIGH_RX_PENDING, driver stops
submitting URBs back to USB subsystem and thus firmware stops
uploading RX data to driver
5. Now finally #2 will acquire rx_proc_lock, but because of #4,
there are no further triggers to schedule rx_work again

The above scenario occurs in some platforms where the RX
processing is comparitively slower. This results in RX stall in
driver, command/TX timeouts in firmware. The above scenario is
introduced after commit c7dbdcb2a4e1
("mwifiex: schedule rx_work on RX interrupt for USB")

To fix this set a new more_rx_task_flag whenever RX data callback
is trying to schedule rx_work but rx_processing is not yet
cleared. This will let the current rx_work(which was waiting for
rx_proc_lock) to loopback and process newly arrived RX packets.

Fixes: c7dbdcb2a4e1 ("mwifiex: schedule rx_work on RX interrupt for USB")
Signed-off-by: Cathy Luo 
Signed-off-by: Ganapathi Bhat 
---
v2: added 'Fixes' label in commit message
---
 drivers/net/wireless/marvell/mwifiex/main.c | 10 +-
 drivers/net/wireless/marvell/mwifiex/main.h |  1 +
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 6e6e1a7..ea87c7c 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -163,6 +163,7 @@ void mwifiex_queue_main_work(struct mwifiex_adapter 
*adapter)
spin_lock_irqsave(>main_proc_lock, flags);
if (adapter->mwifiex_processing) {
adapter->more_task_flag = true;
+   adapter->more_rx_task_flag = true;
spin_unlock_irqrestore(>main_proc_lock, flags);
} else {
spin_unlock_irqrestore(>main_proc_lock, flags);
@@ -177,6 +178,7 @@ void mwifiex_queue_rx_work(struct mwifiex_adapter *adapter)
 
spin_lock_irqsave(>rx_proc_lock, flags);
if (adapter->rx_processing) {
+   adapter->more_rx_task_flag = true;
spin_unlock_irqrestore(>rx_proc_lock, flags);
} else {
spin_unlock_irqrestore(>rx_proc_lock, flags);
@@ -193,13 +195,14 @@ static int mwifiex_process_rx(struct mwifiex_adapter 
*adapter)
 
spin_lock_irqsave(>rx_proc_lock, flags);
if (adapter->rx_processing || adapter->rx_locked) {
+   adapter->more_rx_task_flag = true;
spin_unlock_irqrestore(>rx_proc_lock, flags);
goto exit_rx_proc;
} else {
adapter->rx_processing = true;
spin_unlock_irqrestore(>rx_proc_lock, flags);
}
-
+rx_process_start:
/* Check for Rx data */
while ((skb = skb_dequeue(>rx_data_q))) {
atomic_dec(>rx_pending);
@@ -221,6 +224,11 @@ static int mwifiex_process_rx(struct mwifiex_adapter 
*adapter)
}
}
spin_lock_irqsave(>rx_proc_lock, flags);
+   if (adapter->more_rx_task_flag) {
+   adapter->more_rx_task_flag = false;
+   spin_unlock_irqrestore(>rx_proc_lock, flags);
+   goto rx_process_start;
+   }
adapter->rx_processing = false;
spin_unlock_irqrestore(>rx_proc_lock, flags);
 
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 66ba95c..242e05e 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -891,6 +891,7 @@ struct mwifiex_adapter {
spinlock_t main_proc_lock;
u32 mwifiex_processing;
u8 more_task_flag;
+   u8 more_rx_task_flag;
u16 tx_buf_size;
u16 curr_tx_buf_size;
/* sdio single port rx aggregation capability */
-- 
1.9.1

[PATCH v2 0/2] mwifiex: fix RX data stall issue on USB interface

[Ganapathi Bhat]

This patch series contains 2 fixes to avoid RX data stall on
observed on high through put scenarios on some slower platforms.

Shrenik Shikhare (2):
  mwifiex: schedule rx_work on RX interrupt for USB
  mwifiex: use more_rx_task_flag to avoid USB RX stall

 drivers/net/wireless/marvell/mwifiex/main.c | 17 +
 drivers/net/wireless/marvell/mwifiex/main.h |  2 ++
 drivers/net/wireless/marvell/mwifiex/usb.c  |  2 ++
 3 files changed, 17 insertions(+), 4 deletions(-)

-- 
1.9.1

RE: [EXT] Re: [2/2] mwifiex: use more_rx_task_flag to avoid USB RX stall

[Ganapathi Bhat]

Hi Kalle,

> --
> Kalle Valo  writes:
>
> > Ganapathi Bhat  wrote:
> >
> >> From: Shrenik Shikhare 
> >>
> >> There is a race condition for acquiring rx_proc_lock between rx
> >> worker thread and USB RX data interrupt
> >> (mwifiex_usb_rx_complete):
> >>
> >> 1. USB receives an RX data interrupt, queues rx_work 2. rx_work
> >> empties rx_data_q, tries to acquire rx_proc_lock (to clear
> >> rx_processing flag) 3. While #2 is yet to acquire rx_proc_lock,
> >> driver receives continuous RX data interupts(mwifiex_usb_rx_complete)
> >> 3. For each interrupt at #3, driver acquires rx_proc_lock(it gets the
> >> lock since it is in interrupt context), tries to queue rx_work, but
> >> fails to do so since rx_processing is still set(#2) 4. When
> >> rx_pending exceeds HIGH_RX_PENDING, driver stops submitting URBs
> back
> >> to USB subsystem and thus firmware stops uploading RX data to driver
> >> 5. Now finally #2 will acquire rx_proc_lock, but because of #4, there
> >> are no further triggers to schedule rx_work again
> >>
> >> The above scenario occurs in some platforms where the RX processing
> >> is comparitively slower. This results in RX stall in driver,
> >> command/TX timeouts in firmware. The above scenario is introduced
> >> after commit c7dbdcb2a4e1
> >> ("mwifiex: schedule rx_work on RX interrupt for USB")
> >>
> >> To fix this set a new more_rx_task_flag whenever RX data callback is
> >> trying to schedule rx_work but rx_processing is not yet cleared. This
> >> will let the current rx_work(which was waiting for
> >> rx_proc_lock) to loopback and process newly arrived RX packets.
> >>
> >> Signed-off-by: Cathy Luo 
> >> Signed-off-by: Ganapathi Bhat 
> >
> > I can't find any commit with id c7dbdcb2a4e1, is it correct?
>
> Oh, and please use Fixes line to mark the commit which broke this.
Ok Sure.  I will do that and send v2.
>
> --
> Kalle Valo
Regards,
Ganapathi

RE: [EXT] Re: [2/2] mwifiex: use more_rx_task_flag to avoid USB RX stall

[Ganapathi Bhat]

Hi Kalle,
>
> --
> Ganapathi Bhat  wrote:
>
> > From: Shrenik Shikhare 
> >
> > There is a race condition for acquiring rx_proc_lock between rx worker
> > thread and USB RX data interrupt
> > (mwifiex_usb_rx_complete):
> >
> > 1. USB receives an RX data interrupt, queues rx_work 2. rx_work
> > empties rx_data_q, tries to acquire rx_proc_lock (to clear
> > rx_processing flag) 3. While #2 is yet to acquire rx_proc_lock, driver
> > receives continuous RX data interupts(mwifiex_usb_rx_complete)
> > 3. For each interrupt at #3, driver acquires rx_proc_lock(it gets the
> > lock since it is in interrupt context), tries to queue rx_work, but
> > fails to do so since rx_processing is still set(#2) 4. When rx_pending
> > exceeds HIGH_RX_PENDING, driver stops submitting URBs back to USB
> > subsystem and thus firmware stops uploading RX data to driver 5. Now
> > finally #2 will acquire rx_proc_lock, but because of #4, there are no
> > further triggers to schedule rx_work again
> >
> > The above scenario occurs in some platforms where the RX processing is
> > comparitively slower. This results in RX stall in driver, command/TX
> > timeouts in firmware. The above scenario is introduced after commit
> > c7dbdcb2a4e1
> > ("mwifiex: schedule rx_work on RX interrupt for USB")
> >
> > To fix this set a new more_rx_task_flag whenever RX data callback is
> > trying to schedule rx_work but rx_processing is not yet cleared. This
> > will let the current rx_work(which was waiting for
> > rx_proc_lock) to loopback and process newly arrived RX packets.
> >
> > Signed-off-by: Cathy Luo 
> > Signed-off-by: Ganapathi Bhat 
>
> I can't find any commit with id c7dbdcb2a4e1, is it correct?
Correct. Actually the commit id c7dbdcb2a4e1 is the PATCH [1/2] sent in this 
series.
>
> --
> https://patchwork.kernel.org/patch/10178729/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingp
> atches
Regards,
Ganapathi

Re: [mac80211-next:master 3/5] net//wireless/wext-compat.c:1351:9: warning: function returns address of local variable

[Johannes Berg]

On Thu, 2018-01-25 at 03:41 +, Pkshih wrote:
> 
> In commit c179e9151, you remove 'static' from struct, but function return the
> address of local variable as kbuild robot mentioned. It is a problem, but
> my prior experiment looks fine. Hence, I check the callers of 
> get_wireless_stats(),
> and found they use the address that points to stack immediately, so content of
> stack wasn't broken luckily.
> 
> So, please recall the 'static' of 'struct iw_statistics wstats'.

Yeah, that was garbage. I dropped the patch already.

johannes