Need support for Intel new wifi module 9462NGW

[Chris Chiu]

Hi,
We just have the Intel new WiFi module 9462NGW from Acer and tried
to verify if it works on the latest linux kernel. Unfortunately it
seems not even detected because the PCI ID seems unknown to the
iwlwifi driver. Then I add the following line to
drivers/net/wireless/intel/iwlwifi/pcie/drv.c
iwl_hw_card_ids
{IWL_PCI_DEVICE(0x31DC, 0x02A4, iwl9460_2ac_cfg)},

dmesg shows the following

[   12.994422] iwlwifi :00:0c.0: Direct firmware load for
iwlwifi-9260-th-b0-jf-b0-33.ucode failed with error -2
[   12.994442] iwlwifi :00:0c.0: Direct firmware load for
iwlwifi-9260-th-b0-jf-b0-32.ucode failed with error -2
[   12.994456] iwlwifi :00:0c.0: Direct firmware load for
iwlwifi-9260-th-b0-jf-b0-31.ucode failed with error -2
[   12.994470] iwlwifi :00:0c.0: Direct firmware load for
iwlwifi-9260-th-b0-jf-b0-30.ucode failed with error -2
[   12.994473] iwlwifi :00:0c.0: no suitable firmware found!
[   12.994477] iwlwifi :00:0c.0: minimum version required:
iwlwifi-9260-th-b0-jf-b0-30
[   12.994479] iwlwifi :00:0c.0: maximum version supported:
iwlwifi-9260-th-b0-jf-b0-33



I'm not able to find these missing files in linux-firmware.git and any
other possible place. What's the status of supporting this 9462NGW?
Please let me know if any more information required. Thanks

Chris

Re: rtlwifi oops

[Barry Day]

On Sun, Oct 29, 2017 at 01:08:24AM +0300, nirinA raseliarison wrote:
> [  145.966016] usb 2-1.4: new high-speed USB device number 4 using ehci-pci
> [  146.045808] usb 2-1.4: New USB device found, idVendor=0bda,
> idProduct=8178
> [  146.045811] usb 2-1.4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [  146.045812] usb 2-1.4: Product: 802.11n WLAN Adapter
> [  146.045813] usb 2-1.4: Manufacturer: Realtek
> [  146.045814] usb 2-1.4: SerialNumber: 00e04c01
> [  146.202043] rtl8192cu: Chip version 0x11
> [  146.278549] rtl8192cu: Board Type 0
> [  146.278790] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
> [  146.278823] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
> [  146.278938] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> [  146.279113] usbcore: registered new interface driver rtl8192cu
> [  146.281706] usbcore: registered new interface driver rtl8xxxu
> --
> nirinA

It appears that both rtl8192cu and rtl8xxxu are being loaded for the
one device.

Try blacklisting one of them.

Barry

[PATCH V2 2/9] qtnfmac: initialize HT/VHT caps "can override" masks

[igor . mitsyanko . os]

From: Igor Mitsyanko 

Information on which HT/VHT capabilities can be overridden is reported
per-MAC by wireless device.

Signed-off-by: Igor Mitsyanko 
---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 2 ++
 drivers/net/wireless/quantenna/qtnfmac/commands.c | 7 ---
 drivers/net/wireless/quantenna/qtnfmac/core.h | 4 ++--
 drivers/net/wireless/quantenna/qtnfmac/qlink.h| 8 
 4 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c 
b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 2f60331..b6a2540 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -925,6 +925,8 @@ int qtnf_wiphy_register(struct qtnf_hw_info *hw_info, 
struct qtnf_wmac *mac)
wiphy->available_antennas_rx = mac->macinfo.num_rx_chain;
 
wiphy->max_ap_assoc_sta = mac->macinfo.max_ap_assoc_sta;
+   wiphy->ht_capa_mod_mask = >macinfo.ht_cap_mod_mask;
+   wiphy->vht_capa_mod_mask = >macinfo.vht_cap_mod_mask;
 
ether_addr_copy(wiphy->perm_addr, mac->macaddr);
 
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c 
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index a7422c5..35ff7e8 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -1110,9 +1110,10 @@ qtnf_cmd_resp_proc_mac_info(struct qtnf_wmac *mac,
qlink_chan_width_mask_to_nl(le16_to_cpu(
resp_info->radar_detect_widths));
 
-   memcpy(_info->ht_cap, _info->ht_cap, sizeof(mac_info->ht_cap));
-   memcpy(_info->vht_cap, _info->vht_cap,
-  sizeof(mac_info->vht_cap));
+   memcpy(_info->ht_cap_mod_mask, _info->ht_cap_mod_mask,
+  sizeof(mac_info->ht_cap_mod_mask));
+   memcpy(_info->vht_cap_mod_mask, _info->vht_cap_mod_mask,
+  sizeof(mac_info->vht_cap_mod_mask));
 }
 
 static void qtnf_cmd_resp_band_fill_htcap(const u8 *info,
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.h 
b/drivers/net/wireless/quantenna/qtnfmac/core.h
index da2c24e..74b94ce 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
@@ -103,8 +103,8 @@ struct qtnf_mac_info {
u8 sretry_limit;
u8 coverage_class;
u8 radar_detect_widths;
-   struct ieee80211_ht_cap ht_cap;
-   struct ieee80211_vht_cap vht_cap;
+   struct ieee80211_ht_cap ht_cap_mod_mask;
+   struct ieee80211_vht_cap vht_cap_mod_mask;
struct ieee80211_iface_limit *limits;
size_t n_limits;
 };
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink.h 
b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
index dfef7fa..b2c4e27 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
@@ -636,8 +636,8 @@ struct qlink_resp {
  * specified WMAC).
  * @num_tx_chain: Number of transmit chains used by WMAC.
  * @num_rx_chain: Number of receive chains used by WMAC.
- * @vht_cap: VHT capabilities.
- * @ht_cap: HT capabilities.
+ * @vht_cap_mod_mask: mask specifying which VHT capabilities can be altered.
+ * @ht_cap_mod_mask: mask specifying which HT capabilities can be altered.
  * @bands_cap: wireless bands WMAC can operate in, bitmap of  qlink_band.
  * @phymode_cap: PHY modes WMAC can operate in, bitmap of  qlink_phy_mode.
  * @max_ap_assoc_sta: Maximum number of associations supported by WMAC.
@@ -649,8 +649,8 @@ struct qlink_resp_get_mac_info {
u8 dev_mac[ETH_ALEN];
u8 num_tx_chain;
u8 num_rx_chain;
-   struct ieee80211_vht_cap vht_cap;
-   struct ieee80211_ht_cap ht_cap;
+   struct ieee80211_vht_cap vht_cap_mod_mask;
+   struct ieee80211_ht_cap ht_cap_mod_mask;
u8 bands_cap;
u8 phymode_cap;
__le16 max_ap_assoc_sta;
-- 
2.9.5

[PATCH V2 4/9] qtnfmac: extend "IE set" TLV to include frame type info

[igor . mitsyanko . os]

From: Igor Mitsyanko 

Specifying frame type for "IE set" TLV will allow to use several
TLVs in a single message.
Modify users accordingly.

Signed-off-by: Igor Mitsyanko 
---
 drivers/net/wireless/quantenna/qtnfmac/commands.c | 25 +++---
 drivers/net/wireless/quantenna/qtnfmac/event.c| 58 +--
 drivers/net/wireless/quantenna/qtnfmac/qlink.h| 27 +++
 3 files changed, 80 insertions(+), 30 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c 
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index 503187a..8d3cdba 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -147,6 +147,21 @@ static struct sk_buff *qtnf_cmd_alloc_new_cmdskb(u8 macid, 
u8 vifid, u16 cmd_no,
return cmd_skb;
 }
 
+static void qtnf_cmd_tlv_ie_set_add(struct sk_buff *cmd_skb, u8 frame_type,
+   const u8 *buf, size_t len)
+{
+   struct qlink_tlv_ie_set *tlv;
+
+   tlv = (struct qlink_tlv_ie_set *)skb_put(cmd_skb, sizeof(*tlv) + len);
+   tlv->hdr.type = cpu_to_le16(QTN_TLV_ID_IE_SET);
+   tlv->hdr.len = cpu_to_le16(len + sizeof(*tlv) - sizeof(tlv->hdr));
+   tlv->type = frame_type;
+   tlv->flags = 0;
+
+   if (len && buf)
+   memcpy(tlv->ie_data, buf, len);
+}
+
 int qtnf_cmd_send_start_ap(struct qtnf_vif *vif)
 {
struct sk_buff *cmd_skb;
@@ -2028,9 +2043,8 @@ int qtnf_cmd_send_scan(struct qtnf_wmac *mac)
}
 
if (scan_req->ie_len != 0)
-   qtnf_cmd_skb_put_tlv_arr(cmd_skb, QTN_TLV_ID_IE_SET,
-scan_req->ie,
-scan_req->ie_len);
+   qtnf_cmd_tlv_ie_set_add(cmd_skb, QLINK_IE_SET_PROBE_REQ,
+   scan_req->ie, scan_req->ie_len);
 
if (scan_req->n_channels) {
n_channels = scan_req->n_channels;
@@ -2154,9 +2168,8 @@ int qtnf_cmd_send_connect(struct qtnf_vif *vif,
 sme->ssid_len);
 
if (sme->ie_len != 0)
-   qtnf_cmd_skb_put_tlv_arr(cmd_skb, QTN_TLV_ID_IE_SET,
-sme->ie,
-sme->ie_len);
+   qtnf_cmd_tlv_ie_set_add(cmd_skb, QLINK_IE_SET_ASSOC_REQ,
+   sme->ie, sme->ie_len);
 
qtnf_bus_lock(vif->mac->bus);
 
diff --git a/drivers/net/wireless/quantenna/qtnfmac/event.c 
b/drivers/net/wireless/quantenna/qtnfmac/event.c
index 4b29f9f..b67a082 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/event.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/event.c
@@ -65,34 +65,39 @@ qtnf_event_handle_sta_assoc(struct qtnf_wmac *mac, struct 
qtnf_vif *vif,
sinfo.assoc_req_ies_len = 0;
 
payload_len = len - sizeof(*sta_assoc);
-   tlv = (struct qlink_tlv_hdr *)sta_assoc->ies;
+   tlv = (const struct qlink_tlv_hdr *)sta_assoc->ies;
 
-   while (payload_len >= sizeof(struct qlink_tlv_hdr)) {
+   while (payload_len >= sizeof(*tlv)) {
tlv_type = le16_to_cpu(tlv->type);
tlv_value_len = le16_to_cpu(tlv->len);
tlv_full_len = tlv_value_len + sizeof(struct qlink_tlv_hdr);
 
-   if (tlv_full_len > payload_len) {
-   pr_warn("VIF%u.%u: malformed TLV 0x%.2X; LEN: %u\n",
-   mac->macid, vif->vifid, tlv_type,
-   tlv_value_len);
+   if (tlv_full_len > payload_len)
return -EINVAL;
-   }
 
if (tlv_type == QTN_TLV_ID_IE_SET) {
-   sinfo.assoc_req_ies = tlv->val;
-   sinfo.assoc_req_ies_len = tlv_value_len;
+   const struct qlink_tlv_ie_set *ie_set;
+   unsigned int ie_len;
+
+   if (payload_len < sizeof(*ie_set))
+   return -EINVAL;
+
+   ie_set = (const struct qlink_tlv_ie_set *)tlv;
+   ie_len = tlv_value_len -
+   (sizeof(*ie_set) - sizeof(ie_set->hdr));
+
+   if (ie_set->type == QLINK_IE_SET_ASSOC_REQ && ie_len) {
+   sinfo.assoc_req_ies = ie_set->ie_data;
+   sinfo.assoc_req_ies_len = ie_len;
+   }
}
 
payload_len -= tlv_full_len;
tlv = (struct qlink_tlv_hdr *)(tlv->val + tlv_value_len);
}
 
-   if (payload_len) {
-   pr_warn("VIF%u.%u: malformed TLV buf; bytes left: %zu\n",
-   mac->macid, vif->vifid, payload_len);
+   if (payload_len)
return -EINVAL;
-   }
 
cfg80211_new_sta(vif->netdev, 

[PATCH V2 3/9] qtnfmac: get rid of PHYMODE capabilities flags

[igor . mitsyanko . os]

From: Igor Mitsyanko 

Supported WiFi operation modes are now identified per-band based on
HT/VHT capabilities of each band.

Signed-off-by: Igor Mitsyanko 
---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c |  3 ---
 drivers/net/wireless/quantenna/qtnfmac/commands.c |  1 -
 drivers/net/wireless/quantenna/qtnfmac/core.h |  1 -
 drivers/net/wireless/quantenna/qtnfmac/qlink.h| 11 ++-
 4 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c 
b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index b6a2540..1a0c538 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -891,9 +891,6 @@ int qtnf_wiphy_register(struct qtnf_hw_info *hw_info, 
struct qtnf_wmac *mac)
if (ret)
goto out;
 
-   pr_info("MAC%u: phymode=%#x radar=%#x\n", mac->macid,
-   mac->macinfo.phymode_cap, mac->macinfo.radar_detect_widths);
-
wiphy->frag_threshold = mac->macinfo.frag_thr;
wiphy->rts_threshold = mac->macinfo.rts_thr;
wiphy->retry_short = mac->macinfo.sretry_limit;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c 
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index 35ff7e8..503187a 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -1090,7 +1090,6 @@ qtnf_cmd_resp_proc_mac_info(struct qtnf_wmac *mac,
mac_info = >macinfo;
 
mac_info->bands_cap = resp_info->bands_cap;
-   mac_info->phymode_cap = resp_info->phymode_cap;
memcpy(_info->dev_mac, _info->dev_mac,
   sizeof(mac_info->dev_mac));
 
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.h 
b/drivers/net/wireless/quantenna/qtnfmac/core.h
index 74b94ce..1b7bc03 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
@@ -92,7 +92,6 @@ struct qtnf_vif {
 
 struct qtnf_mac_info {
u8 bands_cap;
-   u8 phymode_cap;
u8 dev_mac[ETH_ALEN];
u8 num_tx_chain;
u8 num_rx_chain;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink.h 
b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
index b2c4e27..c558d81 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
@@ -74,12 +74,6 @@ enum qlink_hw_capab {
QLINK_HW_CAPAB_STA_INACT_TIMEOUT = BIT(1),
 };
 
-enum qlink_phy_mode {
-   QLINK_PHYMODE_BGN   = BIT(0),
-   QLINK_PHYMODE_AN= BIT(1),
-   QLINK_PHYMODE_AC= BIT(2),
-};
-
 enum qlink_iface_type {
QLINK_IFTYPE_AP = 1,
QLINK_IFTYPE_STATION= 2,
@@ -639,7 +633,6 @@ struct qlink_resp {
  * @vht_cap_mod_mask: mask specifying which VHT capabilities can be altered.
  * @ht_cap_mod_mask: mask specifying which HT capabilities can be altered.
  * @bands_cap: wireless bands WMAC can operate in, bitmap of  qlink_band.
- * @phymode_cap: PHY modes WMAC can operate in, bitmap of  qlink_phy_mode.
  * @max_ap_assoc_sta: Maximum number of associations supported by WMAC.
  * @radar_detect_widths: bitmask of channels BW for which WMAC can detect 
radar.
  * @var_info: variable-length WMAC info data.
@@ -651,10 +644,10 @@ struct qlink_resp_get_mac_info {
u8 num_rx_chain;
struct ieee80211_vht_cap vht_cap_mod_mask;
struct ieee80211_ht_cap ht_cap_mod_mask;
-   u8 bands_cap;
-   u8 phymode_cap;
__le16 max_ap_assoc_sta;
__le16 radar_detect_widths;
+   u8 bands_cap;
+   u8 rsvd[1];
u8 var_info[0];
 } __packed;
 
-- 
2.9.5

[PATCH V2 5/9] qtnfmac: SCAN results: retreive frame type information from "IE set" TLV

[igor . mitsyanko . os]

From: Igor Mitsyanko 

"IE set" TLV carries the same information as
qlink_event_scan_result::frame_type. Convert the event to make use of
TLV and drop frame_type member.
While at it, make qlink_event_scan_result structure alignement-safe.

Signed-off-by: Igor Mitsyanko 
---
 drivers/net/wireless/quantenna/qtnfmac/event.c | 25 -
 drivers/net/wireless/quantenna/qtnfmac/qlink.h | 11 ++-
 2 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/event.c 
b/drivers/net/wireless/quantenna/qtnfmac/event.c
index b67a082..4abc6d9 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/event.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/event.c
@@ -252,13 +252,12 @@ qtnf_event_handle_scan_results(struct qtnf_vif *vif,
struct cfg80211_bss *bss;
struct ieee80211_channel *channel;
struct wiphy *wiphy = priv_to_wiphy(vif->mac);
-   enum cfg80211_bss_frame_type frame_type;
+   enum cfg80211_bss_frame_type frame_type = CFG80211_BSS_FTYPE_UNKNOWN;
size_t payload_len;
u16 tlv_type;
u16 tlv_value_len;
size_t tlv_full_len;
const struct qlink_tlv_hdr *tlv;
-
const u8 *ies = NULL;
size_t ies_len = 0;
 
@@ -275,17 +274,6 @@ qtnf_event_handle_scan_results(struct qtnf_vif *vif,
return -EINVAL;
}
 
-   switch (sr->frame_type) {
-   case QLINK_BSS_FTYPE_BEACON:
-   frame_type = CFG80211_BSS_FTYPE_BEACON;
-   break;
-   case QLINK_BSS_FTYPE_PRESP:
-   frame_type = CFG80211_BSS_FTYPE_PRESP;
-   break;
-   default:
-   frame_type = CFG80211_BSS_FTYPE_UNKNOWN;
-   }
-
payload_len = len - sizeof(*sr);
tlv = (struct qlink_tlv_hdr *)sr->payload;
 
@@ -308,6 +296,17 @@ qtnf_event_handle_scan_results(struct qtnf_vif *vif,
ie_len = tlv_value_len -
(sizeof(*ie_set) - sizeof(ie_set->hdr));
 
+   switch (ie_set->type) {
+   case QLINK_IE_SET_BEACON_IES:
+   frame_type = CFG80211_BSS_FTYPE_BEACON;
+   break;
+   case QLINK_IE_SET_PROBE_RESP_IES:
+   frame_type = CFG80211_BSS_FTYPE_PRESP;
+   break;
+   default:
+   frame_type = CFG80211_BSS_FTYPE_UNKNOWN;
+   }
+
if (ie_len) {
ies = ie_set->ie_data;
ies_len = ie_len;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink.h 
b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
index f491942..81effd2 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
@@ -881,12 +881,6 @@ struct qlink_event_rxmgmt {
u8 frame_data[0];
 } __packed;
 
-enum qlink_frame_type {
-   QLINK_BSS_FTYPE_UNKNOWN,
-   QLINK_BSS_FTYPE_BEACON,
-   QLINK_BSS_FTYPE_PRESP,
-};
-
 /**
  * struct qlink_event_scan_result - data for QLINK_EVENT_SCAN_RESULTS event
  *
@@ -896,7 +890,6 @@ enum qlink_frame_type {
  * @capab: capabilities field.
  * @bintval: beacon interval announced by discovered BSS.
  * @signal: signal strength.
- * @frame_type: frame type used to get scan result, see  qlink_frame_type.
  * @bssid: BSSID announced by discovered BSS.
  * @ssid_len: length of SSID announced by BSS.
  * @ssid: SSID announced by discovered BSS.
@@ -909,10 +902,10 @@ struct qlink_event_scan_result {
__le16 capab;
__le16 bintval;
s8 signal;
-   u8 frame_type;
-   u8 bssid[ETH_ALEN];
u8 ssid_len;
u8 ssid[IEEE80211_MAX_SSID_LEN];
+   u8 bssid[ETH_ALEN];
+   u8 rsvd[2];
u8 payload[0];
 } __packed;
 
-- 
2.9.5

[PATCH V2 9/9] qtnfmac: pass all CONNECT cmd params to wireless card for processing

[igor . mitsyanko . os]

From: Igor Mitsyanko 

Specifically, following parameters are needed for wireless device
configuration but were not available to it before:
- HT/VHT capabilities and capabilities masks.
- full channel info (not just IEEE number)
- BSSID hint
- previous BSSID for reassoc request

Move Management Frame Protection setting from common encr info
structure into STA-specific .connect command parameters.

Make sure that all new qlink structure definitions are alignment-safe.

Signed-off-by: Igor Mitsyanko 
---
 drivers/net/wireless/quantenna/qtnfmac/commands.c | 63 +++
 drivers/net/wireless/quantenna/qtnfmac/qlink.h| 32 +---
 2 files changed, 65 insertions(+), 30 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c 
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index c2f0b75..8bc8dd6 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -221,7 +221,6 @@ int qtnf_cmd_send_start_ap(struct qtnf_vif *vif,
aen = >aen;
aen->auth_type = s->auth_type;
aen->privacy = !!s->privacy;
-   aen->mfp = 0;
aen->wpa_versions = cpu_to_le32(s->crypto.wpa_versions);
aen->cipher_group = cpu_to_le32(s->crypto.cipher_group);
aen->n_ciphers_pairwise = cpu_to_le32(s->crypto.n_ciphers_pairwise);
@@ -2029,17 +2028,36 @@ int qtnf_cmd_send_del_sta(struct qtnf_vif *vif,
return ret;
 }
 
+static void qtnf_cmd_channel_tlv_add(struct sk_buff *cmd_skb,
+const struct ieee80211_channel *sc)
+{
+   struct qlink_tlv_channel *qchan;
+   u32 flags = 0;
+
+   qchan = skb_put_zero(cmd_skb, sizeof(*qchan));
+   qchan->hdr.type = cpu_to_le16(QTN_TLV_ID_CHANNEL);
+   qchan->hdr.len = cpu_to_le16(sizeof(*qchan) - sizeof(qchan->hdr));
+   qchan->center_freq = cpu_to_le16(sc->center_freq);
+   qchan->hw_value = cpu_to_le16(sc->hw_value);
+
+   if (sc->flags & IEEE80211_CHAN_NO_IR)
+   flags |= QLINK_CHAN_NO_IR;
+
+   if (sc->flags & IEEE80211_CHAN_RADAR)
+   flags |= QLINK_CHAN_RADAR;
+
+   qchan->flags = cpu_to_le32(flags);
+}
+
 int qtnf_cmd_send_scan(struct qtnf_wmac *mac)
 {
struct sk_buff *cmd_skb;
u16 res_code = QLINK_CMD_RESULT_OK;
struct ieee80211_channel *sc;
struct cfg80211_scan_request *scan_req = mac->scan_req;
-   struct qlink_tlv_channel *qchan;
int n_channels;
int count = 0;
int ret;
-   u32 flags;
 
if (scan_req->n_ssids > QTNF_MAX_SSID_LIST_LENGTH) {
pr_err("MAC%u: too many SSIDs in scan request\n", mac->macid);
@@ -2081,22 +2099,8 @@ int qtnf_cmd_send_scan(struct qtnf_wmac *mac)
pr_debug("MAC%u: scan chan=%d, freq=%d, flags=%#x\n",
 mac->macid, sc->hw_value, sc->center_freq,
 sc->flags);
-   qchan = skb_put_zero(cmd_skb, sizeof(*qchan));
-   flags = 0;
-
-   qchan->hdr.type = cpu_to_le16(QTN_TLV_ID_CHANNEL);
-   qchan->hdr.len = cpu_to_le16(sizeof(*qchan) -
-   sizeof(struct qlink_tlv_hdr));
-   qchan->center_freq = cpu_to_le16(sc->center_freq);
-   qchan->hw_value = cpu_to_le16(sc->hw_value);
-
-   if (sc->flags & IEEE80211_CHAN_NO_IR)
-   flags |= QLINK_CHAN_NO_IR;
 
-   if (sc->flags & IEEE80211_CHAN_RADAR)
-   flags |= QLINK_CHAN_RADAR;
-
-   qchan->flags = cpu_to_le32(flags);
+   qtnf_cmd_channel_tlv_add(cmd_skb, sc);
n_channels--;
count++;
}
@@ -2140,10 +2144,15 @@ int qtnf_cmd_send_connect(struct qtnf_vif *vif,
 
ether_addr_copy(cmd->bssid, vif->bssid);
 
-   if (sme->channel)
-   cmd->channel = cpu_to_le16(sme->channel->hw_value);
+   if (sme->bssid_hint)
+   ether_addr_copy(cmd->bssid_hint, sme->bssid_hint);
else
-   cmd->channel = 0;
+   eth_zero_addr(cmd->bssid_hint);
+
+   if (sme->prev_bssid)
+   ether_addr_copy(cmd->prev_bssid, sme->prev_bssid);
+   else
+   eth_zero_addr(cmd->prev_bssid);
 
if ((sme->bg_scan_period > 0) &&
(sme->bg_scan_period <= QTNF_MAX_BG_SCAN_PERIOD))
@@ -2161,11 +2170,18 @@ int qtnf_cmd_send_connect(struct qtnf_vif *vif,
connect_flags |= QLINK_STA_CONNECT_USE_RRM;
 
cmd->flags = cpu_to_le32(connect_flags);
+   memcpy(>ht_capa, >ht_capa, sizeof(cmd->ht_capa));
+   memcpy(>ht_capa_mask, >ht_capa_mask,
+  sizeof(cmd->ht_capa_mask));
+   memcpy(>vht_capa, >vht_capa, 

[PATCH V2 0/9] qtnfmac: allow to configure channel, BW, HT/VHT caps

[igor . mitsyanko . os]

From: Igor Mitsyanko 

This patchset has a goal to make operational parameters (channel, BW,
HT/VHT capabilities) configuration possible for qtnfmac driver.

It was part of bigger changeset when it was V1, rest are already applied.

Changelist V1->V2:
PATCH 8:
  - fix a typo causing initialization of HT capabilities with VHT data.

Igor Mitsyanko (9):
  qtnfmac: use per-band HT/VHT info from wireless device
  qtnfmac: initialize HT/VHT caps "can override" masks
  qtnfmac: get rid of PHYMODE capabilities flags
  qtnfmac: extend "IE set" TLV to include frame type info
  qtnfmac: SCAN results: retreive frame type information from "IE set"
TLV
  qtnfmac: convert "Append IEs" command to QTN_TLV_ID_IE_SET usage
  qtnfmac: configure and start AP interface with a single command
  qtnfmac: include HTCAP and VHTCAP into config AP command
  qtnfmac: pass all CONNECT cmd params to wireless card for processing

 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c |  64 +
 drivers/net/wireless/quantenna/qtnfmac/commands.c | 276 +++---
 drivers/net/wireless/quantenna/qtnfmac/commands.h |   9 +-
 drivers/net/wireless/quantenna/qtnfmac/core.c |   3 +-
 drivers/net/wireless/quantenna/qtnfmac/core.h |   5 +-
 drivers/net/wireless/quantenna/qtnfmac/event.c|  83 ---
 drivers/net/wireless/quantenna/qtnfmac/qlink.h| 138 ++-
 7 files changed, 330 insertions(+), 248 deletions(-)

-- 
2.9.5

[PATCH V2 8/9] qtnfmac: include HTCAP and VHTCAP into config AP command

[igor . mitsyanko . os]

From: Igor Mitsyanko 

Include HT/VHT caps directly into command so that they won't have
to be searched for in IEs.

Signed-off-by: Igor Mitsyanko 
---
 drivers/net/wireless/quantenna/qtnfmac/commands.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c 
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index 5186116..c2f0b75 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -266,6 +266,24 @@ int qtnf_cmd_send_start_ap(struct qtnf_vif *vif,
s->beacon.assocresp_ies,
s->beacon.assocresp_ies_len);
 
+   if (s->ht_cap) {
+   struct qlink_tlv_hdr *tlv = (struct qlink_tlv_hdr *)
+   skb_put(cmd_skb, sizeof(*tlv) + sizeof(*s->ht_cap));
+
+   tlv->type = cpu_to_le16(WLAN_EID_HT_CAPABILITY);
+   tlv->len = cpu_to_le16(sizeof(*s->ht_cap));
+   memcpy(tlv->val, s->ht_cap, sizeof(*s->ht_cap));
+   }
+
+   if (s->vht_cap) {
+   struct qlink_tlv_hdr *tlv = (struct qlink_tlv_hdr *)
+   skb_put(cmd_skb, sizeof(*tlv) + sizeof(*s->vht_cap));
+
+   tlv->type = cpu_to_le16(WLAN_EID_VHT_CAPABILITY);
+   tlv->len = cpu_to_le16(sizeof(*s->vht_cap));
+   memcpy(tlv->val, s->vht_cap, sizeof(*s->vht_cap));
+   }
+
qtnf_bus_lock(vif->mac->bus);
 
ret = qtnf_cmd_send(vif->mac->bus, cmd_skb, _code);
-- 
2.9.5

[PATCH V2 6/9] qtnfmac: convert "Append IEs" command to QTN_TLV_ID_IE_SET usage

[igor . mitsyanko . os]

From: Igor Mitsyanko 

Data contained within "Append IEs" command (QLINK_CMD_MGMT_SET_APPIE)
duplicates QTN_TLV_ID_IE_SET TLV. Convert the command to use that TLV
instead.

Signed-off-by: Igor Mitsyanko 
---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 12 ++--
 drivers/net/wireless/quantenna/qtnfmac/commands.c | 17 -
 drivers/net/wireless/quantenna/qtnfmac/qlink.h| 15 ---
 3 files changed, 10 insertions(+), 34 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c 
b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 1a0c538..27b11dc 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -217,10 +217,10 @@ static int qtnf_mgmt_set_appie(struct qtnf_vif *vif,
int ret = 0;
 
if (!info->beacon_ies || !info->beacon_ies_len) {
-   ret = qtnf_cmd_send_mgmt_set_appie(vif, QLINK_MGMT_FRAME_BEACON,
+   ret = qtnf_cmd_send_mgmt_set_appie(vif, QLINK_IE_SET_BEACON_IES,
   NULL, 0);
} else {
-   ret = qtnf_cmd_send_mgmt_set_appie(vif, QLINK_MGMT_FRAME_BEACON,
+   ret = qtnf_cmd_send_mgmt_set_appie(vif, QLINK_IE_SET_BEACON_IES,
   info->beacon_ies,
   info->beacon_ies_len);
}
@@ -230,11 +230,11 @@ static int qtnf_mgmt_set_appie(struct qtnf_vif *vif,
 
if (!info->proberesp_ies || !info->proberesp_ies_len) {
ret = qtnf_cmd_send_mgmt_set_appie(vif,
-  QLINK_MGMT_FRAME_PROBE_RESP,
+  QLINK_IE_SET_PROBE_RESP_IES,
   NULL, 0);
} else {
ret = qtnf_cmd_send_mgmt_set_appie(vif,
-  QLINK_MGMT_FRAME_PROBE_RESP,
+  QLINK_IE_SET_PROBE_RESP_IES,
   info->proberesp_ies,
   info->proberesp_ies_len);
}
@@ -244,11 +244,11 @@ static int qtnf_mgmt_set_appie(struct qtnf_vif *vif,
 
if (!info->assocresp_ies || !info->assocresp_ies_len) {
ret = qtnf_cmd_send_mgmt_set_appie(vif,
-  QLINK_MGMT_FRAME_ASSOC_RESP,
+  QLINK_IE_SET_ASSOC_RESP,
   NULL, 0);
} else {
ret = qtnf_cmd_send_mgmt_set_appie(vif,
-  QLINK_MGMT_FRAME_ASSOC_RESP,
+  QLINK_IE_SET_ASSOC_RESP,
   info->assocresp_ies,
   info->assocresp_ies_len);
}
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c 
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index 8d3cdba..294418c 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -395,11 +395,10 @@ int qtnf_cmd_send_mgmt_set_appie(struct qtnf_vif *vif, u8 
frame_type,
 const u8 *buf, size_t len)
 {
struct sk_buff *cmd_skb;
-   struct qlink_cmd_mgmt_append_ie *cmd;
u16 res_code = QLINK_CMD_RESULT_OK;
int ret;
 
-   if (sizeof(*cmd) + len > QTNF_MAX_CMD_BUF_SIZE) {
+   if (len > QTNF_MAX_CMD_BUF_SIZE) {
pr_warn("VIF%u.%u: %u frame is too big: %zu\n", vif->mac->macid,
vif->vifid, frame_type, len);
return -E2BIG;
@@ -407,21 +406,13 @@ int qtnf_cmd_send_mgmt_set_appie(struct qtnf_vif *vif, u8 
frame_type,
 
cmd_skb = qtnf_cmd_alloc_new_cmdskb(vif->mac->macid, vif->vifid,
QLINK_CMD_MGMT_SET_APPIE,
-   sizeof(*cmd));
+   sizeof(struct qlink_cmd));
if (unlikely(!cmd_skb))
return -ENOMEM;
 
-   qtnf_bus_lock(vif->mac->bus);
-
-   cmd = (struct qlink_cmd_mgmt_append_ie *)cmd_skb->data;
-   cmd->type = frame_type;
-   cmd->flags = 0;
+   qtnf_cmd_tlv_ie_set_add(cmd_skb, frame_type, buf, len);
 
-   /* If len == 0 then IE buf for specified frame type
-* should be cleared on EP.
-*/
-   if (len && buf)
-   qtnf_cmd_skb_put_buffer(cmd_skb, buf, len);
+   qtnf_bus_lock(vif->mac->bus);
 
ret = qtnf_cmd_send(vif->mac->bus, cmd_skb, _code);
 
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink.h 

[PATCH V2 1/9] qtnfmac: use per-band HT/VHT info from wireless device

[igor . mitsyanko . os]

From: Igor Mitsyanko 

HT/VHT capabilities must be reported per each band supported by a radio,
not for all bands on a radio. Furthermore, driver better not assume
any capabilities and just use whetever is reported by device itself.

To support this, convert "get channels" command into "get band info"
command. Difference is that it may also carry HT/VHT capabilities along
with channels information.

While at it, also add "num_bitrates" field to "get band info" command,
for future use.

Signed-off-by: Igor Mitsyanko 
---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 30 +
 drivers/net/wireless/quantenna/qtnfmac/commands.c | 77 +++
 drivers/net/wireless/quantenna/qtnfmac/commands.h |  4 +-
 drivers/net/wireless/quantenna/qtnfmac/core.c |  3 +-
 drivers/net/wireless/quantenna/qtnfmac/qlink.h| 29 +
 5 files changed, 84 insertions(+), 59 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c 
b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index e70f5bd..2f60331 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -823,8 +823,7 @@ static void qtnf_cfg80211_reg_notifier(struct wiphy 
*wiphy_in,
if (!wiphy->bands[band])
continue;
 
-   ret = qtnf_cmd_get_mac_chan_info(mac,
-wiphy->bands[band]);
+   ret = qtnf_cmd_band_info_get(mac, wiphy->bands[band]);
if (ret)
pr_err("failed to get chan info for mac %u band 
%u\n",
   mac_idx, band);
@@ -832,33 +831,6 @@ static void qtnf_cfg80211_reg_notifier(struct wiphy 
*wiphy_in,
}
 }
 
-void qtnf_band_setup_htvht_caps(struct qtnf_mac_info *macinfo,
-   struct ieee80211_supported_band *band)
-{
-   struct ieee80211_sta_ht_cap *ht_cap;
-   struct ieee80211_sta_vht_cap *vht_cap;
-
-   ht_cap = >ht_cap;
-   ht_cap->ht_supported = true;
-   memcpy(_cap->cap, >ht_cap.cap_info,
-  sizeof(u16));
-   ht_cap->ampdu_factor = IEEE80211_HT_MAX_AMPDU_64K;
-   ht_cap->ampdu_density = IEEE80211_HT_MPDU_DENSITY_NONE;
-   memcpy(_cap->mcs, >ht_cap.mcs,
-  sizeof(ht_cap->mcs));
-
-   if (macinfo->phymode_cap & QLINK_PHYMODE_AC) {
-   vht_cap = >vht_cap;
-   vht_cap->vht_supported = true;
-   memcpy(_cap->cap,
-  >vht_cap.vht_cap_info, sizeof(u32));
-   /* Update MCS support for VHT */
-   memcpy(_cap->vht_mcs,
-  >vht_cap.supp_mcs,
-  sizeof(struct ieee80211_vht_mcs_info));
-   }
-}
-
 struct wiphy *qtnf_wiphy_allocate(struct qtnf_bus *bus)
 {
struct wiphy *wiphy;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c 
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index b81f81b..a7422c5 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -1115,19 +1115,50 @@ qtnf_cmd_resp_proc_mac_info(struct qtnf_wmac *mac,
   sizeof(mac_info->vht_cap));
 }
 
+static void qtnf_cmd_resp_band_fill_htcap(const u8 *info,
+ struct ieee80211_sta_ht_cap *bcap)
+{
+   const struct ieee80211_ht_cap *ht_cap =
+   (const struct ieee80211_ht_cap *)info;
+
+   bcap->ht_supported = true;
+   bcap->cap = le16_to_cpu(ht_cap->cap_info);
+   bcap->ampdu_factor =
+   ht_cap->ampdu_params_info & IEEE80211_HT_AMPDU_PARM_FACTOR;
+   bcap->ampdu_density =
+   (ht_cap->ampdu_params_info & IEEE80211_HT_AMPDU_PARM_DENSITY) >>
+   IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT;
+   memcpy(>mcs, _cap->mcs, sizeof(bcap->mcs));
+}
+
+static void qtnf_cmd_resp_band_fill_vhtcap(const u8 *info,
+  struct ieee80211_sta_vht_cap *bcap)
+{
+   const struct ieee80211_vht_cap *vht_cap =
+   (const struct ieee80211_vht_cap *)info;
+
+   bcap->vht_supported = true;
+   bcap->cap = le32_to_cpu(vht_cap->vht_cap_info);
+   memcpy(>vht_mcs, _cap->supp_mcs, sizeof(bcap->vht_mcs));
+}
+
 static int
-qtnf_cmd_resp_fill_channels_info(struct ieee80211_supported_band *band,
-struct qlink_resp_get_chan_info *resp,
-size_t payload_len)
+qtnf_cmd_resp_fill_band_info(struct ieee80211_supported_band *band,
+struct qlink_resp_band_info_get *resp,
+size_t payload_len)
 {
u16 tlv_type;
size_t tlv_len;
+   size_t tlv_dlen;
const struct qlink_tlv_hdr *tlv;
const struct 

[PATCH V2 7/9] qtnfmac: configure and start AP interface with a single command

[igor . mitsyanko . os]

From: Igor Mitsyanko 

Current logic artificially divides "start AP" procedure into three
stages:
- generic interface configuration (security, channel etc)
- IE's processing
- enable AP mode on interface

This separation would not allow to do a proper device configuration as
first stage needs to use information from IEs that are processed on
a second stage. Which means first and second stages have to be meged.
In that case there is no point anymore to keep third stage either, so
merge all three into a single command.

This new command carries all the same info as contained in
"struct cfg80211_ap_settings".

Signed-off-by: Igor Mitsyanko 
---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 17 +-
 drivers/net/wireless/quantenna/qtnfmac/commands.c | 72 +--
 drivers/net/wireless/quantenna/qtnfmac/commands.h |  5 +-
 drivers/net/wireless/quantenna/qtnfmac/qlink.h|  5 +-
 4 files changed, 47 insertions(+), 52 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c 
b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 27b11dc..7d6dc76 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -271,26 +271,11 @@ static int qtnf_start_ap(struct wiphy *wiphy, struct 
net_device *dev,
struct qtnf_vif *vif = qtnf_netdev_get_priv(dev);
int ret;
 
-   ret = qtnf_cmd_send_config_ap(vif, settings);
-   if (ret) {
-   pr_err("VIF%u.%u: failed to push config to FW\n",
-  vif->mac->macid, vif->vifid);
-   goto out;
-   }
-
-   ret = qtnf_mgmt_set_appie(vif, >beacon);
-   if (ret) {
-   pr_err("VIF%u.%u: failed to add IEs to beacon\n",
-  vif->mac->macid, vif->vifid);
-   goto out;
-   }
-
-   ret = qtnf_cmd_send_start_ap(vif);
+   ret = qtnf_cmd_send_start_ap(vif, settings);
if (ret)
pr_err("VIF%u.%u: failed to start AP\n", vif->mac->macid,
   vif->vifid);
 
-out:
return ret;
 }
 
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c 
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index 294418c..5186116 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -162,56 +162,51 @@ static void qtnf_cmd_tlv_ie_set_add(struct sk_buff 
*cmd_skb, u8 frame_type,
memcpy(tlv->ie_data, buf, len);
 }
 
-int qtnf_cmd_send_start_ap(struct qtnf_vif *vif)
+static bool qtnf_cmd_start_ap_can_fit(const struct qtnf_vif *vif,
+ const struct cfg80211_ap_settings *s)
 {
-   struct sk_buff *cmd_skb;
-   u16 res_code = QLINK_CMD_RESULT_OK;
-   int ret;
+   unsigned int len = sizeof(struct qlink_cmd_start_ap);
 
-   cmd_skb = qtnf_cmd_alloc_new_cmdskb(vif->mac->macid, vif->vifid,
-   QLINK_CMD_START_AP,
-   sizeof(struct qlink_cmd));
-   if (unlikely(!cmd_skb))
-   return -ENOMEM;
+   len += s->ssid_len;
+   len += s->beacon.head_len;
+   len += s->beacon.tail_len;
+   len += s->beacon.beacon_ies_len;
+   len += s->beacon.proberesp_ies_len;
+   len += s->beacon.assocresp_ies_len;
+   len += s->beacon.probe_resp_len;
 
-   qtnf_bus_lock(vif->mac->bus);
-
-   ret = qtnf_cmd_send(vif->mac->bus, cmd_skb, _code);
+   if (cfg80211_chandef_valid(>chandef))
+   len += sizeof(struct qlink_tlv_chandef);
 
-   if (unlikely(ret))
-   goto out;
-
-   if (unlikely(res_code != QLINK_CMD_RESULT_OK)) {
-   pr_err("VIF%u.%u: CMD failed: %u\n", vif->mac->macid,
-  vif->vifid, res_code);
-   ret = -EFAULT;
-   goto out;
+   if (len > (sizeof(struct qlink_cmd) + QTNF_MAX_CMD_BUF_SIZE)) {
+   pr_err("VIF%u.%u: can not fit AP settings: %u\n",
+  vif->mac->macid, vif->vifid, len);
+   return false;
}
 
-   netif_carrier_on(vif->netdev);
-
-out:
-   qtnf_bus_unlock(vif->mac->bus);
-   return ret;
+   return true;
 }
 
-int qtnf_cmd_send_config_ap(struct qtnf_vif *vif,
-   const struct cfg80211_ap_settings *s)
+int qtnf_cmd_send_start_ap(struct qtnf_vif *vif,
+  const struct cfg80211_ap_settings *s)
 {
struct sk_buff *cmd_skb;
-   struct qlink_cmd_config_ap *cmd;
+   struct qlink_cmd_start_ap *cmd;
struct qlink_auth_encr *aen;
u16 res_code = QLINK_CMD_RESULT_OK;
int ret;
int i;
 
+   if (!qtnf_cmd_start_ap_can_fit(vif, s))
+   return -E2BIG;
+
cmd_skb = qtnf_cmd_alloc_new_cmdskb(vif->mac->macid, vif->vifid,
-   

Re: [PATCH v2 1/3] mac80211: Add TXQ scheduling API

[kbuild test robot]

Hi Toke,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on mac80211/master]
[also build test ERROR on v4.14-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Toke-H-iland-J-rgensen/mac80211-Add-TXQ-scheduling-API/20171030-220903
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
master
config: mips-ip27_defconfig (attached as .config)
compiler: mips64-linux-gnuabi64-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

Note: the 
linux-review/Toke-H-iland-J-rgensen/mac80211-Add-TXQ-scheduling-API/20171030-220903
 HEAD aa503ef75660b7c9cb9ede292f03047372517d4e builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> ERROR: "__ath_tx_queue_tid" [drivers/net/wireless/ath/ath9k/ath9k.ko] 
>> undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] mac80211: Update last_ack status for all except probing frames

[Rajkumar Manoharan]

Update last_ack status for all except station probing frames
(i.e null data). Otherwise the station inactivity duration is
cleared whenever AP is checking presence of idle stations by sending
null data frame for every inactive threshold (ap_max_inactivity).
Though the station is idle for longer period, the inactive
time in station dump is restricted ap_max_inactivity threshold.

Signed-off-by: Rajkumar Manoharan 
---
 net/mac80211/status.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index da7427a41529..24ce416f74cd 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -185,10 +185,21 @@ static void ieee80211_check_pending_bar(struct sta_info 
*sta, u8 *addr, u8 tid)
 static void ieee80211_frame_acked(struct sta_info *sta, struct sk_buff *skb)
 {
struct ieee80211_mgmt *mgmt = (void *) skb->data;
+   struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_local *local = sta->local;
struct ieee80211_sub_if_data *sdata = sta->sdata;
 
-   if (ieee80211_hw_check(>hw, REPORTS_TX_ACK_STATUS))
+   /* Update last_ack status for all except station probing frames
+* (i.e null data). Otherwise the station inactivity duration is cleared
+* whenever AP is checking presence of idle stations by sending
+* null data frame for every inactive threshold (ap_max_inactivity).
+* Though the station is idle for longer period, the inactive time in
+* station dump is restricted ap_max_inactivity threshold.
+*/
+   if (ieee80211_hw_check(>hw, REPORTS_TX_ACK_STATUS) &&
+   !((info->flags & IEEE80211_TX_INTFL_NL80211_FRAME_TX) &&
+ (ieee80211_is_nullfunc(mgmt->frame_control) ||
+  ieee80211_is_qos_nullfunc(mgmt->frame_control
sta->status_stats.last_ack = jiffies;
 
if (ieee80211_is_data_qos(mgmt->frame_control)) {
-- 
1.9.1

Re: [PATCH v2 1/3] mac80211: Add TXQ scheduling API

[kbuild test robot]

Hi Toke,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on mac80211/master]
[also build test ERROR on v4.14-rc7 next-20171018]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Toke-H-iland-J-rgensen/mac80211-Add-TXQ-scheduling-API/20171030-220903
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
master
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/Toke-H-iland-J-rgensen/mac80211-Add-TXQ-scheduling-API/20171030-220903
 HEAD aa503ef75660b7c9cb9ede292f03047372517d4e builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/net/wireless/ath/ath9k/recv.o: In function `ath_rx_tasklet':
>> recv.c:(.text+0x16bc): undefined reference to `__ath_tx_queue_tid'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007

[Fengguang Wu]

On Mon, Oct 30, 2017 at 12:29:47PM -0700, Linus Torvalds wrote:

On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu  wrote:


Here are 3 dmesgs related to wireless and 1 from ethernet.


Fengguang, these would be lovelier still _if_ you have DEBUG_INFO
enabled on the kernel, and your script were to find things like
"symbol+0xhex/0xhex", and run "./scripts/faddr2line" on them.

So


[  235.425464] BUG: unable to handle kernel paging request at 00010007
[  235.425470] IP: run_timer_softirq+0x13a/0x470


would also then have

  run_timer_softirq at timer.c:XYZ

which would make it easier to see exactly _what_ it is that faults. As
it is, I think there's a fair number of inlining that makes it hard to
see the cause, but that faddrtoline would make very obvious.


Good idea and tips! It'll definitely help debug the issues where
bisect cannot help.


Finding that "symbol+xyz/abc" pattern should be fairly easy to
automate, and should fit the 0day model fairly well. No?


Sure. We'll add DEBUG_INFO and automate faddr2line.

Regards,
Fengguang

Re: [EXT] Re: pull-request mwifiex-firmware 2017-10-30

[Brian Norris]

On Mon, Oct 30, 2017 at 12:02 PM, Ganapathi Bhat  wrote:
> Ok, prepared the follow up patch.  Let me also know if we can send a merge 
> request while previous one is pending?
> If that is not the case I will send it as soon as the current request is 
> merged.

That's not up to me. I'm sure the maintainer will let you know if they
need something, eventually. It's so trivial, I don't see why they
couldn't just pull it in without any more fuss.

Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007

[Linus Torvalds]

On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu  wrote:
>
> Here are 3 dmesgs related to wireless and 1 from ethernet.

Fengguang, these would be lovelier still _if_ you have DEBUG_INFO
enabled on the kernel, and your script were to find things like
"symbol+0xhex/0xhex", and run "./scripts/faddr2line" on them.

So

> [  235.425464] BUG: unable to handle kernel paging request at 00010007
> [  235.425470] IP: run_timer_softirq+0x13a/0x470

would also then have

   run_timer_softirq at timer.c:XYZ

which would make it easier to see exactly _what_ it is that faults. As
it is, I think there's a fair number of inlining that makes it hard to
see the cause, but that faddrtoline would make very obvious.

Finding that "symbol+xyz/abc" pattern should be fairly easy to
automate, and should fit the 0day model fairly well. No?

In this case, the trapping instruction ends up decoding to

   0: 4c 8d 6c c5 90lea-0x70(%rbp,%rax,8),%r13
   5: 49 8b 45 00  mov0x0(%r13),%rax
   9: 48 85 c0  test   %rax,%rax
   c: 74 deje 0xffec
   e: 4d 8b 7d 00  mov0x0(%r13),%r15
  12: 4d 89 7c 24 08mov%r15,0x8(%r12)
  17: 0f 1f 44 00 00nopl   0x0(%rax,%rax,1)
  1c: 49 8b 07  mov(%r15),%rax
  1f: 49 8b 57 08  mov0x8(%r15),%rdx
  23: 48 85 c0  test   %rax,%rax
  26: 48 89 02  mov%rax,(%rdx)
  29: 74 04je 0x2f
  2b:* 48 89 50 08  mov%rdx,0x8(%rax) <-- trapping instruction
  2f: 41 f6 47 2a 20testb  $0x20,0x2a(%r15)
  34: 49 c7 47 08 00 00 00 movq   $0x0,0x8(%r15)

and %rax has the value 0x, so yes, it will trap at 0x10007.

It's not trivial to see just *wjhat* access it is.

I *think* that "testb $32" is checking for TIMER_IRQSAFE in
expire_timers(), and that the oops is due to the list operations in
detach_timer() (inlined).

Which doesn't really help: it looks like the timer lists are corrupt.
With some luck, some register state could have the timer function
pointer in it, and we'd get a hint of *which* timer this is, but that
doesn't look to be the case here either.

I'm not seeing anything to really help debug this here.

   Linus

RE: [EXT] Re: pull-request mwifiex-firmware 2017-10-30

[Ganapathi Bhat]

Hi Brian,

> On Mon, Oct 30, 2017 at 06:47:58PM +, Ganapathi Bhat wrote:
> > > 
> > > -- On Mon, Oct 30, 2017 at 02:13:31PM +, Ganapathi Bhat wrote:
>
> > > > --- a/WHENCE
> > > > +++ b/WHENCE
> > > > @@ -757,7 +757,7 @@ File: mrvl/pcieuart8997_combo_v4.bin
> > > >  Version: 16.68.1.p70
> > > >
> > > >  File: mrvl/pcieusb8997_combo_v4.bin
> > > > -Version: 16.68.1.p133
> > > > +Version: 16.68.1.p40
> > >
> > > This says .p40, whereas the commit message (and the version tag
> > > within the
> > > firmware) says p140. I think you're missing a "1".
> >  I did miss this.  Will it make sense to trigger another pull request with 
> > just
> the version change?
>
> Sure, why not? Email is cheap, and so is git. Either rewrite the commit or add
> another on top to fix it...
Ok, prepared the follow up patch.  Let me also know if we can send a merge 
request while previous one is pending?
If that is not the case I will send it as soon as the current request is merged.

Thanks,
Ganapathi

Re: [EXT] Re: pull-request mwifiex-firmware 2017-10-30

[Brian Norris]

On Mon, Oct 30, 2017 at 06:47:58PM +, Ganapathi Bhat wrote:
> > --
> > On Mon, Oct 30, 2017 at 02:13:31PM +, Ganapathi Bhat wrote:

> > > --- a/WHENCE
> > > +++ b/WHENCE
> > > @@ -757,7 +757,7 @@ File: mrvl/pcieuart8997_combo_v4.bin
> > >  Version: 16.68.1.p70
> > >
> > >  File: mrvl/pcieusb8997_combo_v4.bin
> > > -Version: 16.68.1.p133
> > > +Version: 16.68.1.p40
> >
> > This says .p40, whereas the commit message (and the version tag within the
> > firmware) says p140. I think you're missing a "1".
>  I did miss this.  Will it make sense to trigger another pull request with 
> just the version change?

Sure, why not? Email is cheap, and so is git. Either rewrite the commit
or add another on top to fix it...

RE: [EXT] Re: pull-request mwifiex-firmware 2017-10-30

[Ganapathi Bhat]

Hi Brian,

>
> --
> On Mon, Oct 30, 2017 at 02:13:31PM +, Ganapathi Bhat wrote:
> > The following changes since commit
> e0494e95192ac5329989f4d128cf95c417d618cc:
> >
> >   linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-08-01
> 23:55:30 +0530)
> >
> > are available in the git repository at:
> >
> >   git://git.marvell.com/mwifiex-firmware.git
> >
> > for you to fetch changes up to
> c5bed1294f6cf6bf6cbef612204f96361a3c2539:
> >
> >   linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-10-30
> 19:23:05 +0530)
>
> Hooray, your git server is working again! And FWIW:
>
> Tested-by: Brian Norris 
>
> But quoting your patch...
>
> > --- a/WHENCE
> > +++ b/WHENCE
> > @@ -757,7 +757,7 @@ File: mrvl/pcieuart8997_combo_v4.bin
> >  Version: 16.68.1.p70
> >
> >  File: mrvl/pcieusb8997_combo_v4.bin
> > -Version: 16.68.1.p133
> > +Version: 16.68.1.p40
>
> This says .p40, whereas the commit message (and the version tag within the
> firmware) says p140. I think you're missing a "1".
 I did miss this.  Will it make sense to trigger another pull request with just 
the version change?
>
> >
> >  File: mrvl/pcie8997_wlan_v4.bin
> >  Version: 16.68.1.p97
>
>
> Brian
>
> >
> > 
> > Ganapathi Bhat (1):
> >   linux-firmware: update Marvell PCIe-USB8997 firmware image
> >
> > WHENCE|   2 +-
> > mrvl/pcieusb8997_combo_v4.bin | Bin 620800 -> 622532 bytes
> > 2 files changed, 1 insertion(+), 1 deletion(-)

Regards,
Ganapathi

Re: pull-request mwifiex-firmware 2017-10-30

[Brian Norris]

On Mon, Oct 30, 2017 at 02:13:31PM +, Ganapathi Bhat wrote:
> The following changes since commit e0494e95192ac5329989f4d128cf95c417d618cc:
> 
>   linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-08-01 
> 23:55:30 +0530)
> 
> are available in the git repository at:
> 
>   git://git.marvell.com/mwifiex-firmware.git
> 
> for you to fetch changes up to c5bed1294f6cf6bf6cbef612204f96361a3c2539:
> 
>   linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-10-30 
> 19:23:05 +0530)

Hooray, your git server is working again! And FWIW:

Tested-by: Brian Norris 

But quoting your patch...

> --- a/WHENCE
> +++ b/WHENCE
> @@ -757,7 +757,7 @@ File: mrvl/pcieuart8997_combo_v4.bin
>  Version: 16.68.1.p70
>  
>  File: mrvl/pcieusb8997_combo_v4.bin
> -Version: 16.68.1.p133
> +Version: 16.68.1.p40

This says .p40, whereas the commit message (and the version tag within the
firmware) says p140. I think you're missing a "1".

>  
>  File: mrvl/pcie8997_wlan_v4.bin
>  Version: 16.68.1.p97


Brian

> 
> 
> Ganapathi Bhat (1):
>   linux-firmware: update Marvell PCIe-USB8997 firmware image
> 
> WHENCE|   2 +-
> mrvl/pcieusb8997_combo_v4.bin | Bin 620800 -> 622532 bytes
> 2 files changed, 1 insertion(+), 1 deletion(-)

pull-request mwifiex-firmware 2017-10-30

[Ganapathi Bhat]

The following changes since commit e0494e95192ac5329989f4d128cf95c417d618cc:

  linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-08-01 
23:55:30 +0530)

are available in the git repository at:

  git://git.marvell.com/mwifiex-firmware.git

for you to fetch changes up to c5bed1294f6cf6bf6cbef612204f96361a3c2539:

  linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-10-30 
19:23:05 +0530)


Ganapathi Bhat (1):
  linux-firmware: update Marvell PCIe-USB8997 firmware image

WHENCE|   2 +-
mrvl/pcieusb8997_combo_v4.bin | Bin 620800 -> 622532 bytes
2 files changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH 4/5] wlcore: Use common error handling code in wlcore_set_beacon_template()

[SF Markus Elfring]

>> @@ -4081,9 +4078,8 @@ static int wlcore_set_beacon_template(struct wl1271 
>> *wl,
>>   beacon->data,
>>   beacon->len, 0,
>>   min_rate);
>> -end_bcn:
>> +free_skb:
> 
> Why rename the label?

I find it clearer according to the Linux coding style.

Regards,
Markus

Re: [PATCH 1/5] wlcore: Use common error handling code in wlcore_nvs_cb()

[SF Markus Elfring]

>> @@ -6551,6 +6549,11 @@ static void wlcore_nvs_cb(const struct firmware *fw, 
>> void *context)
>>  out:
>> release_firmware(fw);
>> complete_all(>nvs_loading_complete);
>> +   return;
>> +
>> +power_off:
> 
> Name this "out_power_off" to match the other labels.

Do you expect a second approach for this patch series then?


>> +   wl1271_power_off(wl);
>> +   goto out_free_nvs;
> 
> Why not put this in front of the out_free_nvs label?

It seems that I can not really follow this suggestion at the moment.


> It looks weird here.

Which detail do you not like?

Regards,
Markus

Re: [PATCH 5/5] wlcore: Use common error handling code in wl1271_op_suspend()

[Julian Calaby]

Hi Markus,

On Mon, Oct 30, 2017 at 7:16 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Sun, 29 Oct 2017 20:36:39 +0100
>
> Add a jump target so that a specific error message is stored only once
> at the end of this function implementation.
> Replace two calls of the macro "wl1271_warning" by goto statements.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 

This patch is bogus, moving error messages around like this is just bizarre.

These are both reporting different failures, so the error messages
should be different.

> ---
>  drivers/net/wireless/ti/wlcore/main.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/main.c 
> b/drivers/net/wireless/ti/wlcore/main.c
> index 12a9d6509382..a110f61110d5 100644
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -1732,8 +1732,7 @@ static int wl1271_op_suspend(struct ieee80211_hw *hw,
> ret = wl1271_configure_suspend(wl, wlvif, wow);
> if (ret < 0) {
> mutex_unlock(>mutex);
> -   wl1271_warning("couldn't prepare device to suspend");

"couldn't configure device for suspend"?

> -   return ret;
> +   goto report_preparation_failure;
> }
> }
>
> @@ -1752,10 +1751,8 @@ static int wl1271_op_suspend(struct ieee80211_hw *hw,
> wl1271_ps_elp_sleep(wl);
> mutex_unlock(>mutex);
>
> -   if (ret < 0) {
> -   wl1271_warning("couldn't prepare device to suspend");

"couldn't enable power saving"?

> -   return ret;
> -   }
> +   if (ret < 0)
> +   goto report_preparation_failure;
>
> /* flush any remaining work */
> wl1271_debug(DEBUG_MAC80211, "flushing remaining works");

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH 4/5] wlcore: Use common error handling code in wlcore_set_beacon_template()

[Julian Calaby]

Hi Markus,

On Mon, Oct 30, 2017 at 7:14 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Sun, 29 Oct 2017 20:16:22 +0100
>
> Adjust jump targets so that a bit of exception handling can be better
> reused at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 

Reviewed-by: Julian Calaby 

However,

> ---
>  drivers/net/wireless/ti/wlcore/main.c | 18 +++---
>  1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/main.c 
> b/drivers/net/wireless/ti/wlcore/main.c
> index 0365b5e40a8d..12a9d6509382 100644
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -4081,9 +4078,8 @@ static int wlcore_set_beacon_template(struct wl1271 *wl,
>   beacon->data,
>   beacon->len, 0,
>   min_rate);
> -end_bcn:
> +free_skb:

Why rename the label?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH 3/5] wlcore: Return directly after a failed ieee80211_beacon_get() in wlcore_set_beacon_template()

[Julian Calaby]

On Mon, Oct 30, 2017 at 7:13 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Sun, 29 Oct 2017 20:00:41 +0100
>
> Return directly after a call of the function "ieee80211_beacon_get"
> failed at the beginning.
>
> Signed-off-by: Markus Elfring 

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH 1/5] wlcore: Use common error handling code in wlcore_nvs_cb()

[Julian Calaby]

Hi Markus,

On Mon, Oct 30, 2017 at 7:11 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Sun, 29 Oct 2017 18:38:04 +0100
>
> Add a jump target so that a bit of exception handling can be better reused
> at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/net/wireless/ti/wlcore/main.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/main.c 
> b/drivers/net/wireless/ti/wlcore/main.c
> index c346c021b999..48380d48ef09 100644
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -6551,6 +6549,11 @@ static void wlcore_nvs_cb(const struct firmware *fw, 
> void *context)
>  out:
> release_firmware(fw);
> complete_all(>nvs_loading_complete);
> +   return;
> +
> +power_off:

Name this "out_power_off" to match the other labels.

> +   wl1271_power_off(wl);
> +   goto out_free_nvs;

Why not put this in front of the out_free_nvs label? It looks weird here.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH 2/5] wlcore: Delete an unnecessary check statement in wlcore_set_beacon_template()

[Julian Calaby]

On Mon, Oct 30, 2017 at 7:12 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Sun, 29 Oct 2017 19:45:07 +0100
>
> A goto statement jumped to a target which followed a condition check
> immediately without the specification of useful actions between.
> Thus remove such unnecessary source code at the end of this function.
>
> Signed-off-by: Markus Elfring 

Looks good to me.

Reviewed-by: Julian Calaby 

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [v2,1/5] qtnfmac: modify full Tx queue error reporting

[Kalle Valo]

Sergey Matyukevich  wrote:

> Under heavy load it is normal that h/w Tx queue is almost full all the time
> and reclaim should be done before transmitting next packet. Warning still
> should be reported as well as s/w Tx queues should be stopped in the
> case when reclaim failed.
> 
> Signed-off-by: Sergey Matyukevich 

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

e9931f984dd1 qtnfmac: modify full Tx queue error reporting
3dd06cecb1b8 qtnfmac: enable registration of more mgmt frames
bf024645ac9d qtnfmac: drop nonexistent function declaration
c35c0d54a77d qtnfmac: modify full Tx queue recovery
db5c6d4a9b92 qtnfmac: advertise support of inactivity timeout

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

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

Re: [v3,1/3] rsi: sdio: add WOWLAN support for S3 suspend state

[Kalle Valo]

Amitkumar Karwar  wrote:

> From: Karun Eagalapati 
> 
> WoWLAN is supported in RS9113 device through GPIO pin2.
> wowlan config frame is internally sent to firmware in mac80211
> suspend handler. Also beacon miss threshold and keep-alive time
> values are increased to avoid un-necessary disconnection with AP.
> 
> Signed-off-by: Karun Eagalapati 
> Signed-off-by: Amitkumar Karwar 

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

f3ac4e7394a1 rsi: sdio: add WOWLAN support for S3 suspend state
b6c8d06c8a64 rsi: sdio: Add WOWLAN support for S4 hibernate state
063848c3e155 rsi: sdio: Add WOWLAN support for S5 shutdown state

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

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

Re: mwifiex: do not transmit in 11N rates when connected in TKIP security

[Kalle Valo]

Ganapathi Bhat  wrote:

> Driver is transmitting in 11N rates, when connected to an AP in
> TKIP security mode. Add a check to disable_11n to fix the issue.
> 
> Signed-off-by: Ganapathi Bhat 

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

c6c65a8411cf mwifiex: do not transmit in 11N rates when connected in TKIP 
security

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

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

Re: libertas: don't write wdev->ssid/_len

[Kalle Valo]

Johannes Berg  wrote:

> From: Johannes Berg 
> 
> When joining an IBSS network, wdev->ssid/_len will already be
> set, so there's no need to write them. In any case, they are
> internal cfg80211 values, and have very little user-visible
> impact.
> 
> Signed-off-by: Johannes Berg 

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

39a9cd5a0e4e libertas: don't write wdev->ssid/_len

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

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

Re: [net-next] rsi: remove unused including

[Kalle Valo]

"weiyongjun \(A\)"  wrote:

> Remove including  that don't need it.
> 
> Signed-off-by: Wei Yongjun 

Wei, your name in patchwork is badly formatted. Please register to patchwork
and you should be able to fix it:

https://patchwork.kernel.org/patch/10030879/

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

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

Re: [1/5] qtnfmac: modify full Tx queue error reporting

[Kalle Valo]

Sergey Matyukevich  writes:

>> > My assumption is that by default all the patches should cleanly apply
>> > to wireless-drivers-next. I could apply the patch in question to
>> > wireless-drivers-next without any issues.
>> 
>> Odd. How did you apply it? My script uses 'git am -s -3' individually
>> for each patch in the series, but to my knowledge that shouldn't cause
>> any problems.
>
> It turns out I mechanically rebased my branch on top of w-d-n before writing
> the previous email. Now I could reproduce the same failure when using this
> command for the original patches downloaded from patchwork.

Ok, that makes sense. Most likely when git-rebase does a 3-way merge
automatically and that's why you were able to successfully apply them.
But as git-am was not able to use 3-way merge due to incorrect sha1
information it failed.

> The problem was in conflict with qtnfmac fixes pulled to w-d-n from
> w-d.

Ok, thanks for investigating the root cause.

-- 
Kalle Valo

[PATCH v2 4/5] qtnfmac: modify full Tx queue recovery

[Sergey Matyukevich]

Current recovery approach is to wake s/w Tx queues for skb->dev netdevice.
However this approach doesn't cover the case when h/w queue is full of
packets from a single wireless interface. Suppose xmit attempt from the
second wireless interface fails due to failed reclaim. Then the second
interface will not have a chance to recover even if subsequent reclaims
succeed. Possible solution is to attempt to wake all the s/w queues
belonging to driver interfaces.

Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/core.c  | 27 ++
 drivers/net/wireless/quantenna/qtnfmac/core.h  |  1 +
 .../net/wireless/quantenna/qtnfmac/pearl/pcie.c| 13 +++
 .../quantenna/qtnfmac/pearl/pcie_bus_priv.h|  1 +
 4 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.c 
b/drivers/net/wireless/quantenna/qtnfmac/core.c
index aa7f146278a7..6a6e5ffb0348 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.c
@@ -618,6 +618,33 @@ struct net_device *qtnf_classify_skb(struct qtnf_bus *bus, 
struct sk_buff *skb)
 }
 EXPORT_SYMBOL_GPL(qtnf_classify_skb);
 
+void qtnf_wake_all_queues(struct net_device *ndev)
+{
+   struct qtnf_vif *vif = qtnf_netdev_get_priv(ndev);
+   struct qtnf_wmac *mac;
+   struct qtnf_bus *bus;
+   int macid;
+   int i;
+
+   if (unlikely(!vif || !vif->mac || !vif->mac->bus))
+   return;
+
+   bus = vif->mac->bus;
+
+   for (macid = 0; macid < QTNF_MAX_MAC; macid++) {
+   if (!(bus->hw_info.mac_bitmap & BIT(macid)))
+   continue;
+
+   mac = bus->mac[macid];
+   for (i = 0; i < QTNF_MAX_INTF; i++) {
+   vif = >iflist[i];
+   if (vif->netdev && netif_queue_stopped(vif->netdev))
+   netif_tx_wake_all_queues(vif->netdev);
+   }
+   }
+}
+EXPORT_SYMBOL_GPL(qtnf_wake_all_queues);
+
 MODULE_AUTHOR("Quantenna Communications");
 MODULE_DESCRIPTION("Quantenna 802.11 wireless LAN FullMAC driver.");
 MODULE_LICENSE("GPL");
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.h 
b/drivers/net/wireless/quantenna/qtnfmac/core.h
index 49ae700f66f0..da2c24e2271d 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
@@ -153,6 +153,7 @@ int qtnf_cmd_send_get_phy_params(struct qtnf_wmac *mac);
 
 struct qtnf_wmac *qtnf_core_get_mac(const struct qtnf_bus *bus, u8 macid);
 struct net_device *qtnf_classify_skb(struct qtnf_bus *bus, struct sk_buff 
*skb);
+void qtnf_wake_all_queues(struct net_device *ndev);
 void qtnf_virtual_intf_cleanup(struct net_device *ndev);
 
 void qtnf_netdev_updown(struct net_device *ndev, bool up);
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index 146e42a132e7..7e487622d87d 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -617,9 +617,10 @@ static void qtnf_pcie_data_tx_reclaim(struct 
qtnf_pcie_bus_priv *priv)
if (skb->dev) {
skb->dev->stats.tx_packets++;
skb->dev->stats.tx_bytes += skb->len;
-
-   if (netif_queue_stopped(skb->dev))
-   netif_wake_queue(skb->dev);
+   if (unlikely(priv->tx_stopped)) {
+   qtnf_wake_all_queues(skb->dev);
+   priv->tx_stopped = 0;
+   }
}
 
dev_kfree_skb_any(skb);
@@ -669,8 +670,10 @@ static int qtnf_pcie_data_tx(struct qtnf_bus *bus, struct 
sk_buff *skb)
spin_lock_irqsave(>tx0_lock, flags);
 
if (!qtnf_tx_queue_ready(priv)) {
-   if (skb->dev)
-   netif_stop_queue(skb->dev);
+   if (skb->dev) {
+   netif_tx_stop_all_queues(skb->dev);
+   priv->tx_stopped = 1;
+   }
 
spin_unlock_irqrestore(>tx0_lock, flags);
return NETDEV_TX_BUSY;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h
index 86ac1ccedb52..397875a50fc2 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h
@@ -37,6 +37,7 @@ struct qtnf_pcie_bus_priv {
/* lock for tx0 operations */
spinlock_t tx0_lock;
u8 msi_enabled;
+   u8 tx_stopped;
int mps;
 
struct workqueue_struct *workqueue;
-- 
2.11.0

[PATCH v2 3/5] qtnfmac: drop nonexistent function declaration

[Sergey Matyukevich]

Function qtnf_classify_skb_no_mbss has been used for debug
during early stage of development. Drop its declaration.

Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/core.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.h 
b/drivers/net/wireless/quantenna/qtnfmac/core.h
index 44a2cbb19310..49ae700f66f0 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
@@ -153,9 +153,6 @@ int qtnf_cmd_send_get_phy_params(struct qtnf_wmac *mac);
 
 struct qtnf_wmac *qtnf_core_get_mac(const struct qtnf_bus *bus, u8 macid);
 struct net_device *qtnf_classify_skb(struct qtnf_bus *bus, struct sk_buff 
*skb);
-struct net_device *qtnf_classify_skb_no_mbss(struct qtnf_bus *bus,
-struct sk_buff *skb);
-
 void qtnf_virtual_intf_cleanup(struct net_device *ndev);
 
 void qtnf_netdev_updown(struct net_device *ndev, bool up);
-- 
2.11.0

[PATCH v2 1/5] qtnfmac: modify full Tx queue error reporting

[Sergey Matyukevich]

Under heavy load it is normal that h/w Tx queue is almost full all the time
and reclaim should be done before transmitting next packet. Warning still
should be reported as well as s/w Tx queues should be stopped in the
case when reclaim failed.

Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index 69131965a298..146e42a132e7 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -643,11 +643,11 @@ static int qtnf_tx_queue_ready(struct qtnf_pcie_bus_priv 
*priv)
 {
if (!CIRC_SPACE(priv->tx_bd_w_index, priv->tx_bd_r_index,
priv->tx_bd_num)) {
-   pr_err_ratelimited("reclaim full Tx queue\n");
qtnf_pcie_data_tx_reclaim(priv);
 
if (!CIRC_SPACE(priv->tx_bd_w_index, priv->tx_bd_r_index,
priv->tx_bd_num)) {
+   pr_warn_ratelimited("reclaim full Tx queue\n");
priv->tx_full_count++;
return 0;
}
-- 
2.11.0

[PATCH v2 2/5] qtnfmac: enable registration of more mgmt frames

[Sergey Matyukevich]

Support registration for more mgmt frame types
for debug and monitoring purposes.

Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c 
b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 63a540d1216e..64db4082c9d2 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -73,7 +73,10 @@ qtnf_mgmt_stypes[NUM_NL80211_IFTYPES] = {
[NL80211_IFTYPE_AP] = {
.tx = BIT(IEEE80211_STYPE_ACTION >> 4),
.rx = BIT(IEEE80211_STYPE_ACTION >> 4) |
- BIT(IEEE80211_STYPE_PROBE_REQ >> 4),
+ BIT(IEEE80211_STYPE_PROBE_REQ >> 4) |
+ BIT(IEEE80211_STYPE_ASSOC_REQ >> 4) |
+ BIT(IEEE80211_STYPE_REASSOC_REQ >> 4) |
+ BIT(IEEE80211_STYPE_AUTH >> 4),
},
 };
 
@@ -353,6 +356,13 @@ qtnf_mgmt_frame_register(struct wiphy *wiphy, struct 
wireless_dev *wdev,
return;
 
switch (frame_type & IEEE80211_FCTL_STYPE) {
+   case IEEE80211_STYPE_REASSOC_REQ:
+   case IEEE80211_STYPE_ASSOC_REQ:
+   qlink_frame_type = QLINK_MGMT_FRAME_ASSOC_REQ;
+   break;
+   case IEEE80211_STYPE_AUTH:
+   qlink_frame_type = QLINK_MGMT_FRAME_AUTH;
+   break;
case IEEE80211_STYPE_PROBE_REQ:
qlink_frame_type = QLINK_MGMT_FRAME_PROBE_REQ;
break;
-- 
2.11.0

[PATCH v2 5/5] qtnfmac: advertise support of inactivity timeout

[Sergey Matyukevich]

From: Igor Mitsyanko 

Wireless device may implement a logic to kick-out STA due to inactivity
for a certain period of time. This feature needs to be advertised to
higher layers if supported. Timeout value is still taken from
parameters to START_AP command, nothing changes here.

Signed-off-by: Igor Mitsyanko 
---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c |  5 -
 drivers/net/wireless/quantenna/qtnfmac/commands.c |  5 +++--
 drivers/net/wireless/quantenna/qtnfmac/qlink.h| 11 ++-
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c 
b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 64db4082c9d2..e70f5bd5e498 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -956,7 +956,10 @@ int qtnf_wiphy_register(struct qtnf_hw_info *hw_info, 
struct qtnf_wmac *mac)
 
ether_addr_copy(wiphy->perm_addr, mac->macaddr);
 
-   if (hw_info->hw_capab & QLINK_HW_SUPPORTS_REG_UPDATE) {
+   if (hw_info->hw_capab & QLINK_HW_CAPAB_STA_INACT_TIMEOUT)
+   wiphy->features |= NL80211_FEATURE_INACTIVITY_TIMER;
+
+   if (hw_info->hw_capab & QLINK_HW_CAPAB_REG_UPDATE) {
wiphy->regulatory_flags |= REGULATORY_STRICT_REG |
REGULATORY_CUSTOM_REG;
wiphy->reg_notifier = qtnf_cfg80211_reg_notifier;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c 
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index babdc600c193..b81f81bd1411 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -975,10 +975,11 @@ qtnf_cmd_resp_proc_hw_info(struct qtnf_bus *bus,
return -EINVAL;
}
 
-   pr_info("fw_version=%d, MACs map %#x, alpha2=\"%c%c\", chains Tx=%u 
Rx=%u\n",
+   pr_info("fw_version=%d, MACs map %#x, alpha2=\"%c%c\", chains Tx=%u 
Rx=%u, capab=0x%x\n",
hwinfo->fw_ver, hwinfo->mac_bitmap,
hwinfo->rd->alpha2[0], hwinfo->rd->alpha2[1],
-   hwinfo->total_tx_chain, hwinfo->total_rx_chain);
+   hwinfo->total_tx_chain, hwinfo->total_rx_chain,
+   hwinfo->hw_capab);
 
return 0;
 }
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink.h 
b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
index 7b313d38c30b..0f582782682f 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
@@ -61,8 +61,17 @@ struct qlink_msg_header {
 /* Generic definitions of data and information carried in QLINK messages
  */
 
+/**
+ * enum qlink_hw_capab - device capabilities.
+ *
+ * @QLINK_HW_CAPAB_REG_UPDATE: device can update it's regulatory region.
+ * @QLINK_HW_CAPAB_STA_INACT_TIMEOUT: device implements a logic to kick-out
+ * associated STAs due to inactivity. Inactivity timeout period is taken
+ * from QLINK_CMD_START_AP parameters.
+ */
 enum qlink_hw_capab {
-   QLINK_HW_SUPPORTS_REG_UPDATE= BIT(0),
+   QLINK_HW_CAPAB_REG_UPDATE = BIT(0),
+   QLINK_HW_CAPAB_STA_INACT_TIMEOUT = BIT(1),
 };
 
 enum qlink_phy_mode {
-- 
2.11.0

[PATCH v2 0/5] qtnfmac: misc small features and fixes

[Sergey Matyukevich]

Hello Kalle, Igor, and all

This patch series includes a number of small features and fixes
for qtnfmac driver.

Changes v1->v2:
Rebase on top of latest wireless-drivers-next to resolve the conflict
caused by qtnfmac fixes merged from wireless-drivers.

Igor Mitsyanko (1):
 qtnfmac: advertise support of inactivity timeout

Sergey Matyukevich (4):
 qtnfmac: modify full Tx queue error reporting
 qtnfmac: enable registration of more mgmt frames
 qtnfmac: drop nonexistent function declaration
 qtnfmac: modify full Tx queue recovery

 cfg80211.c|   17 +++--
 commands.c|5 +++--
 core.c|   27 +++
 core.h|4 +---
 pearl/pcie.c  |   15 +--
 pearl/pcie_bus_priv.h |1 +
 qlink.h   |   11 ++-
 7 files changed, 66 insertions(+), 14 deletions(-)

Re: [1/5] qtnfmac: modify full Tx queue error reporting

[Sergey Matyukevich]

> > My assumption is that by default all the patches should cleanly apply
> > to wireless-drivers-next. I could apply the patch in question to
> > wireless-drivers-next without any issues.
> 
> Odd. How did you apply it? My script uses 'git am -s -3' individually
> for each patch in the series, but to my knowledge that shouldn't cause
> any problems.

It turns out I mechanically rebased my branch on top of w-d-n before writing
the previous email. Now I could reproduce the same failure when using this
command for the original patches downloaded from patchwork. The problem
was in conflict with qtnfmac fixes pulled to w-d-n from w-d.

Regards,
Sergey

Re: [v3] ath10k: rebuild crypto header in rx data frames

[Sebastian Gottschall]

will check it tomorrow including gcmp-256, ccmp-256. was out for weekend :-)

Am 30.10.2017 um 09:39 schrieb Kalle Valo:

Kalle Valo  wrote:


Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
on host (mac80211) rather than firmware. Rebuild cipher header
in every received data frames (that are notified through those
HTT interfaces) from the rx_hdr_status tlv available in the
rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
flag for the packets which requires mac80211 PN/TSC check support
and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the
rebuilding of cipher header to perform PN/TSC check for replay
attack.

Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers
in raw mode needs to be fixed. Since Rx with these ciphers in raw
mode does not work in the current form even without this patch and
removing crypto tail for these chipers needs clean up, raw mode related
issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up
patches.

Tested-by: Manikanta Pubbisetty 
Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: Kalle Valo 

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

7eccb738fce5 ath10k: rebuild crypto header in rx data frames



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH 1/5] mac80211: always update the PM state of a peer on MGMT / DATA frames

[Johannes Berg]

On Sun, 2017-10-29 at 11:51 +0200, Luca Coelho wrote:
> From: Emmanuel Grumbach 
> 
> The 2016 version of the spec is more generic about when the
> AP should update the power management state of the peer:
> the AP shall update the state based on any management or
> data frames. This means that even non-bufferable management
> frames should be looked at to update to maintain the power
> management state of the peer.
> 
> This can avoid problematic cases for example if a station
> disappears while being asleep and then re-appears. The AP
> would remember it as in power save, but the Authentication
> frame couldn't be used to set the peer as awake again.
> Note that this issues wasn't really critical since at some
> point (after the association) we would have removed the
> station and created another one with all the states cleared.

IIRC this caused a hwsim test failure - is that addressed yet?

johannes

Re: Revert "ath10k: fix napi_poll budget overflow"

[Kalle Valo]

Kalle Valo  wrote:

> Thorsten reported on  that
> commit c9353bf483d3 made ath10k unstable with QCA6174 on his Dell XPS13 (9360)
> with an error message:
> 
> ath10k_pci :3a:00.0: failed to extract amsdu: -11
> 
> It only seemed to happen with certain APs, not all, but when it happened the
> only way to get ath10k working was to switch the wifi off and on with a 
> hotkey.
> 
> As this commit made things even worse (a warning vs breaking the whole
> connection) let's revert the commit for now and while the issue is being 
> fixed.
> 
> Link: http://lists.infradead.org/pipermail/ath10k/2017-October/010227.html
> Reported-by: Thorsten Leemhuis 
> Signed-off-by: Kalle Valo 

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

e48e9c429a95 Revert "ath10k: fix napi_poll budget overflow"

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

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

Re: [v3] ath10k: rebuild crypto header in rx data frames

[Kalle Valo]

Kalle Valo  wrote:

> Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
> HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
> on host (mac80211) rather than firmware. Rebuild cipher header
> in every received data frames (that are notified through those
> HTT interfaces) from the rx_hdr_status tlv available in the
> rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
> flag for the packets which requires mac80211 PN/TSC check support
> and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
> QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the
> rebuilding of cipher header to perform PN/TSC check for replay
> attack.
> 
> Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers
> in raw mode needs to be fixed. Since Rx with these ciphers in raw
> mode does not work in the current form even without this patch and
> removing crypto tail for these chipers needs clean up, raw mode related
> issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up
> patches.
> 
> Tested-by: Manikanta Pubbisetty 
> Signed-off-by: Vasanthakumar Thiagarajan 
> Signed-off-by: Kalle Valo 

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

7eccb738fce5 ath10k: rebuild crypto header in rx data frames

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

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

Re: [1/5] qtnfmac: modify full Tx queue error reporting

[Kalle Valo]

Sergey Matyukevich  writes:

> Hello Kalle,
>
>> Failed to apply:
>> 
>> fatal: sha1 information is lacking or useless
>> (drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c).
>> error: could not build fake ancestor
>> Applying: qtnfmac: modify full Tx queue recovery
>> Patch failed at 0001 qtnfmac: modify full Tx queue recovery
>> The copy of the patch that failed is found in: .git/rebase-apply/patch
>> 
>> 5 patches set to Changes Requested.
>> 
>> 10007281 [1/5] qtnfmac: modify full Tx queue error reporting
>> 10007279 [2/5] qtnfmac: enable registration of more mgmt frames
>> 10007283 [3/5] qtnfmac: drop nonexistent function declaration
>> 10007285 [4/5] qtnfmac: modify full Tx queue recovery
>> 10007287 [5/5] qtnfmac: advertise support of inactivity timeout
>
> My assumption is that by default all the patches should cleanly apply
> to wireless-drivers-next. I could apply the patch in question to
> wireless-drivers-next without any issues.

Odd. How did you apply it? My script uses 'git am -s -3' individually
for each patch in the series, but to my knowledge that shouldn't cause
any problems.

> Rebase of the whole series on top of wireless-drivers-next looks good
> as well. I will resend rebased patches as v2.

Thanks, sending v2 is the easiest for me. If there are problems again
I'll investigate in detail what's going on.

> Meanwhile do you have any idea what could go wrong ? The error message
> looks scary...

You mean the "sha1 information is lacking", right? It means that git was
not able to find a common ancestor for the file which it could use to
create the 3-way merge. Usually that happens when people have
out-of-tree patches on the branch they are submitting from.

And that's why I recommend to use the w-d-next master branch as the
baseline when submitting patches, and not have any other custom patches
applied on the branch. This should keep sha1 information correct and
make it possible for git to use 3-way merge.

-- 
Kalle Valo

Re: [PATCH 03/12] wil6210: refresh FW capabilities during interface up

[Kalle Valo]

Lior David  writes:

> On 10/28/2017 6:01 PM, Kalle Valo wrote:
>> Maya Erez  writes:
>> 
>>> From: Lior David 
>>>
>>> FW capabilities are currently retrieved only during module
>>> initialization, but userspace can replace the firmware while
>>> interface is down, so refresh the FW capabilities when
>>> interface is up (after FW is loaded) to ensure driver
>>> functionality matches the loaded FW.
>> 
>> I think usually the firmware is loaded only once during probe() and I
>> think it's quite special that you retrieve it during interface up. Being
>> able to change the firmware version runtime like that can lead to
>> problems eventually, for example cfg80211 might not allow changing
>> already registered configuration etc.
>> 
> Yes you are right, it is not perfect.
> We shutdown our chip in interface down so the FW is lost, we have to load it
> every interface up. We could request_firmware only once at insmod and store it
> so the same FW will be used every time but this is a big waste of memory (FW
> size is ~400KB and may be larger with future chips). We only touch one or two
> very simple fields in struct wiphy that are not validated in wiphy_register. 
> The
> behavior is not 100% proof but good enough, and we recommend to our users to
> always rmmod/insmod when replacing FW (replacing FW at runtime is usually not
> done in production systems, this is only for debugging).
> However, if we do not refresh the capabilities we will have larger problems -
> the driver can try to access features not supported by FW and cause FW/host 
> crashes.

Yes, I agree that this patch does improve things and should be applied.
But I think in the long run you should consider changing this and do the
same as other drivers do (load the firmware only on probe()).

-- 
Kalle Valo