* Re: [PATCH v2] drivers: bcma: driver_pcie2.c: Comment format correction & moving trailing */ to a separate line as per checkpatch
From: Morgan Freeman @ 2017-11-28 8:35 UTC (permalink / raw)
To: Ashish Kalra; +Cc: zajec5, linux-wireless, linux-kernel
In-Reply-To: <20171128021142.2793-1-eashishkalra@gmail.com>
Hi Ashish,
On Tue, Nov 28, 2017 at 07:41:42AM +0530, Ashish Kalra wrote:
> This patch fixes the checkpatch.pl warning:
Write in _imperative_mood_ as I said before.
Like "Use this..." or "Make this..."
> WARNING: Block comments use * on subsequent lines
> + /* TODO:
> + si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); */
>
> WARNING: Block comments use a trailing */ on a separate line
> + si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); */
>
> total: 0 errors, 2 warnings, 200 lines checked
No need to mention all of this!
> Signed-off-by: Ashish Kalra <eashishkalra@gmail.com>
> ---
> changes from v1 (https://lkml.org/lkml/2017/11/26/85)
> v2: Improved commit message as per review from Morgan Freeman <morganfreeman6991@gmail.com>
Your patch subject is again *wrong* here.
Look here: https://pastebin.com/X7x89Q4v
Please take a look at this :
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Also, don't send me the patch directly, instead to the relevant maintainer and
CC me.
Thanks
Himanshu Jha
^ permalink raw reply
* [PATCH] ath10k: handling qos at STA side based on AP WMM enable/disable
From: bpothuno @ 2017-11-28 10:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Balaji Pothunoori
From: Balaji Pothunoori <bpothuno@qti.qualcomm.com>
Data packets are not sent by STA in case of STA joined to
non QOS AP (WMM disabled AP). This is happening because of STA
is sending data packets to firmware from host with qos enabled
along with non qos queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.
This patch fixes this issue by updating the qos based on station
WME capability field if WMM is disabled in AP.
This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.
For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
has no effect.
Signed-off-by: Balaji Pothunoori <bpothuno@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947ee..2616b99 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
}
break;
case WMI_VDEV_TYPE_STA:
- if (vif->bss_conf.qos)
+ if (sta->wme)
arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
break;
case WMI_VDEV_TYPE_IBSS:
--
1.7.9.5
^ permalink raw reply related
* [RFC v2] cfg80211: Implement Multiple BSSID capability in scanning
From: Jouni Malinen @ 2017-11-28 11:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Peng Xu, Jouni Malinen
From: Peng Xu <pxu@qti.qualcomm.com>
This extends cfg80211 BSS table processing to be able to parse Multiple
BSSID element from Beacon and Probe Response frames and to update the
BSS profiles in internal database for non-transmitted BSSs.
Signed-off-by: Peng Xu <pxu@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
net/wireless/core.h | 1 +
net/wireless/scan.c | 450 ++++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 437 insertions(+), 14 deletions(-)
v2:
- address number of comments from Johannes on the first version
- fix number of issues that came up during additional testing
- some additional cleanup on the implementation
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 35165f4..3b4a566 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -139,6 +139,7 @@ extern int cfg80211_rdev_list_generation;
struct cfg80211_internal_bss {
struct list_head list;
struct list_head hidden_list;
+ struct list_head nontrans_list;
struct rb_node rbn;
u64 ts_boottime;
unsigned long ts;
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 9f0901f..4be56b1 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -149,6 +149,7 @@ static bool __cfg80211_unlink_bss(struct cfg80211_registered_device *rdev,
}
list_del_init(&bss->list);
+ list_del_init(&bss->nontrans_list);
rb_erase(&bss->rbn, &rdev->bss_tree);
rdev->bss_entries--;
WARN_ONCE((rdev->bss_entries == 0) ^ list_empty(&rdev->bss_list),
@@ -1005,6 +1006,7 @@ cfg80211_bss_update(struct cfg80211_registered_device *rdev,
memcpy(new, tmp, sizeof(*new));
new->refcount = 1;
INIT_LIST_HEAD(&new->hidden_list);
+ INIT_LIST_HEAD(&new->nontrans_list);
if (rcu_access_pointer(tmp->pub.proberesp_ies)) {
hidden = rb_find_bss(rdev, tmp, BSS_CMP_HIDE_ZLEN);
@@ -1086,18 +1088,157 @@ cfg80211_get_bss_channel(struct wiphy *wiphy, const u8 *ie, size_t ielen,
return channel;
}
+static void gen_new_bssid(const u8 *bssid, u8 max_bssid, u8 mbssid_index,
+ u8 *new_bssid_addr)
+{
+ u64 bssid_tmp, new_bssid = 0;
+ u64 lsb_n;
+
+ bssid_tmp = ether_addr_to_u64(bssid);
+
+ lsb_n = bssid_tmp & ((1 << max_bssid) - 1);
+ new_bssid = bssid_tmp;
+ new_bssid &= ~((1 << max_bssid) - 1);
+ new_bssid |= (lsb_n + mbssid_index) % (1 << max_bssid);
+
+ u64_to_ether_addr(new_bssid, new_bssid_addr);
+}
+
+static size_t gen_new_ie(const u8 *ie, size_t ielen, const u8 *subelement,
+ size_t subie_len, u8 *new_ie, gfp_t gfp)
+{
+ u8 *pos, *tmp;
+ const u8 *tmp_old, *tmp_new;
+ u8 *sub_copy;
+
+ /* copy subelement as we need to change its content to
+ * mark an ie after it is processed.
+ */
+ sub_copy = kmalloc(subie_len, gfp);
+ if (!sub_copy)
+ return 0;
+ memcpy(sub_copy, subelement, subie_len);
+
+ pos = &new_ie[0];
+
+ /* set new ssid */
+ tmp_new = cfg80211_find_ie(WLAN_EID_SSID, sub_copy, subie_len);
+ if (tmp_new) {
+ memcpy(pos, tmp_new, tmp_new[1] + 2);
+ pos += (tmp_new[1] + 2);
+ }
+
+ /* go through IEs in ie (skip SSID) and subelement,
+ * merge them into new_ie
+ */
+ tmp_old = cfg80211_find_ie(WLAN_EID_SSID, ie, ielen);
+ tmp_old = (tmp_old) ? tmp_old + tmp_old[1] + 2 : ie;
+
+ while (tmp_old + tmp_old[1] + 2 - ie <= ielen) {
+ if (tmp_old[0] == 0) {
+ tmp_old++;
+ continue;
+ }
+
+ tmp = (u8 *)cfg80211_find_ie(tmp_old[0], sub_copy, subie_len);
+ if (!tmp) {
+ /* ie in old ie but not in subelement */
+ if (tmp_old[0] != WLAN_EID_MULTIPLE_BSSID) {
+ memcpy(pos, tmp_old, tmp_old[1] + 2);
+ pos += tmp_old[1] + 2;
+ }
+ } else {
+ /* ie in transmitting ie also in subelement,
+ * copy from subelement and flag the ie in subelement
+ * as copied (by setting eid field to 0xff). For
+ * vendor ie, compare OUI + type + subType to
+ * determine if they are the same ie.
+ */
+ if (tmp_old[0] == WLAN_EID_VENDOR_SPECIFIC) {
+ if (!memcmp(tmp_old + 2, tmp + 2, 5)) {
+ /* same vendor ie, copy from
+ * subelement
+ */
+ memcpy(pos, tmp, tmp[1] + 2);
+ pos += tmp[1] + 2;
+ tmp[0] = 0xff;
+ } else {
+ memcpy(pos, tmp_old, tmp_old[1] + 2);
+ pos += tmp_old[1] + 2;
+ }
+ } else {
+ /* copy ie from subelement into new ie */
+ memcpy(pos, tmp, tmp[1] + 2);
+ pos += tmp[1] + 2;
+ tmp[0] = 0xff;
+ }
+ }
+
+ if (tmp_old + tmp_old[1] + 2 - ie == ielen)
+ break;
+
+ tmp_old += tmp_old[1] + 2;
+ }
+
+ /* go through subelement again to check if there is any ie not
+ * copied to new ie, skip ssid, capability, bssid-index ie
+ */
+ tmp_new = sub_copy;
+ while (tmp_new + tmp_new[1] + 2 - sub_copy <= subie_len) {
+ if (!(tmp_new[0] == WLAN_EID_NON_TX_BSSID_CAP ||
+ tmp_new[0] == WLAN_EID_SSID ||
+ tmp_new[0] == WLAN_EID_MULTI_BSSID_IDX ||
+ tmp_new[0] == 0xff)) {
+ memcpy(pos, tmp_new, tmp_new[1] + 2);
+ pos += tmp_new[1] + 2;
+ }
+ if (tmp_new + tmp_new[1] + 2 - sub_copy == subie_len)
+ break;
+ tmp_new += tmp_new[1] + 2;
+ }
+
+ kfree(sub_copy);
+ return pos - new_ie;
+}
+
+static int add_nontrans_list(struct cfg80211_internal_bss *trans_bss,
+ struct cfg80211_internal_bss *nontrans_bss)
+{
+ const u8 *ssid;
+ size_t ssid_len;
+ struct cfg80211_internal_bss *bss = NULL;
+
+ ssid = ieee80211_bss_get_ie(&nontrans_bss->pub, WLAN_EID_SSID);
+ if (!ssid)
+ return -EINVAL;
+ ssid_len = ssid[1];
+ ssid = ssid + 2;
+
+ /* check if nontrans_bss is in the list */
+ list_for_each_entry(bss, &trans_bss->nontrans_list, nontrans_list) {
+ if (is_bss(&bss->pub, nontrans_bss->pub.bssid, ssid, ssid_len))
+ return 0;
+ }
+
+ /* add to the list */
+ list_add_tail(&nontrans_bss->nontrans_list, &trans_bss->nontrans_list);
+ return 0;
+}
+
/* Returned bss is reference counted and must be cleaned up appropriately. */
-struct cfg80211_bss *
-cfg80211_inform_bss_data(struct wiphy *wiphy,
- struct cfg80211_inform_bss *data,
- enum cfg80211_bss_frame_type ftype,
- const u8 *bssid, u64 tsf, u16 capability,
- u16 beacon_interval, const u8 *ie, size_t ielen,
- gfp_t gfp)
+static struct cfg80211_bss *
+cfg80211_inform_single_bss_data(struct wiphy *wiphy,
+ struct cfg80211_inform_bss *data,
+ enum cfg80211_bss_frame_type ftype,
+ const u8 *bssid, u64 tsf, u16 capability,
+ u16 beacon_interval, const u8 *ie, size_t ielen,
+ struct cfg80211_bss *trans_bss,
+ gfp_t gfp)
{
+ struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
struct cfg80211_bss_ies *ies;
struct ieee80211_channel *channel;
- struct cfg80211_internal_bss tmp = {}, *res;
+ struct cfg80211_internal_bss tmp = {}, *res, *trans_internal;
int bss_type;
bool signal_valid;
@@ -1165,18 +1306,248 @@ cfg80211_inform_bss_data(struct wiphy *wiphy,
regulatory_hint_found_beacon(wiphy, channel, gfp);
}
+ if (trans_bss) {
+ /* this is a nontransmitting bss, we need to add it to
+ * transmitting bss' list if it is not there
+ */
+ trans_internal = container_of(trans_bss,
+ struct cfg80211_internal_bss,
+ pub);
+ if (add_nontrans_list(trans_internal, res)) {
+ if (__cfg80211_unlink_bss(rdev, res))
+ rdev->bss_generation++;
+ }
+ }
+
trace_cfg80211_return_bss(&res->pub);
/* cfg80211_bss_update gives us a referenced result */
return &res->pub;
}
+
+static void parse_mbssid_data(struct wiphy *wiphy,
+ struct cfg80211_inform_bss *data,
+ enum cfg80211_bss_frame_type ftype,
+ const u8 *bssid, u64 tsf,
+ u16 beacon_interval, const u8 *ie, size_t ielen,
+ struct cfg80211_bss *trans_bss,
+ gfp_t gfp)
+{
+ const u8 *pos, *subelement, *mbssid_end_pos;
+ const u8 *tmp, *mbssid_index_ie;
+ size_t subie_len, new_ie_len;
+ u8 new_bssid[ETH_ALEN];
+ u8 *new_ie;
+ u16 capability;
+ struct cfg80211_bss *bss;
+
+ if (!trans_bss)
+ return;
+ if (!cfg80211_find_ie(WLAN_EID_MULTIPLE_BSSID, ie, ielen))
+ return;
+
+ pos = ie;
+
+ new_ie = kmalloc(IEEE80211_MAX_DATA_LEN, gfp);
+ if (!new_ie)
+ return;
+
+ while (pos < ie + ielen + 2) {
+ tmp = cfg80211_find_ie(WLAN_EID_MULTIPLE_BSSID, pos,
+ ielen - (pos - ie));
+ if (!tmp)
+ break;
+
+ mbssid_end_pos = tmp + tmp[1] + 2;
+ /* Skip Element ID, Len, MaxBSSID Indicator */
+ if (tmp[1] < 4)
+ break;
+ for (subelement = tmp + 3; subelement < mbssid_end_pos - 1;
+ subelement += 2 + subelement[1]) {
+ subie_len = subelement[1];
+ if (mbssid_end_pos - subelement < 2 + subie_len)
+ break;
+ if (subelement[0] != 0 || subelement[1] < 4) {
+ /* not a valid BSS profile */
+ continue;
+ }
+
+ if (subelement[2] != WLAN_EID_NON_TX_BSSID_CAP ||
+ subelement[3] != 2) {
+ /* The first element within the Nontransmitted
+ * BSSID Profile is not the Nontransmitted
+ * BSSID Capability element.
+ */
+ continue;
+ }
+
+ /* found a Nontransmitted BSSID Profile */
+ mbssid_index_ie = cfg80211_find_ie(
+ WLAN_EID_MULTI_BSSID_IDX,
+ subelement + 2, subie_len);
+ if (!mbssid_index_ie || mbssid_index_ie[1] < 1 ||
+ mbssid_index_ie[2] == 0) {
+ /* No valid Multiple BSSID-Index element */
+ continue;
+ }
+
+ gen_new_bssid(bssid, tmp[2], mbssid_index_ie[2],
+ new_bssid);
+ memset(new_ie, 0, IEEE80211_MAX_DATA_LEN);
+ new_ie_len = gen_new_ie(ie, ielen, subelement + 2,
+ subie_len, new_ie, gfp);
+ if (!new_ie_len)
+ continue;
+
+ capability = le16_to_cpup((const u16 *)&subelement[4]);
+ bss = cfg80211_inform_single_bss_data(wiphy, data,
+ ftype,
+ new_bssid, tsf,
+ capability,
+ beacon_interval,
+ new_ie,
+ new_ie_len,
+ trans_bss, gfp);
+ if (!bss)
+ break;
+ cfg80211_put_bss(wiphy, bss);
+ }
+
+ pos = mbssid_end_pos;
+ }
+
+ kfree(new_ie);
+}
+
+struct cfg80211_bss *
+cfg80211_inform_bss_data(struct wiphy *wiphy,
+ struct cfg80211_inform_bss *data,
+ enum cfg80211_bss_frame_type ftype,
+ const u8 *bssid, u64 tsf, u16 capability,
+ u16 beacon_interval, const u8 *ie, size_t ielen,
+ gfp_t gfp)
+{
+ struct cfg80211_bss *res;
+
+ res = cfg80211_inform_single_bss_data(wiphy, data, ftype, bssid, tsf,
+ capability, beacon_interval, ie,
+ ielen, NULL, gfp);
+ parse_mbssid_data(wiphy, data, ftype, bssid, tsf, beacon_interval,
+ ie, ielen, res, gfp);
+ return res;
+}
EXPORT_SYMBOL(cfg80211_inform_bss_data);
+static void parse_mbssid_frame_data(struct wiphy *wiphy,
+ struct cfg80211_inform_bss *data,
+ struct ieee80211_mgmt *mgmt, size_t len,
+ struct cfg80211_bss *trans_bss,
+ gfp_t gfp)
+{
+ enum cfg80211_bss_frame_type ftype;
+ const u8 *ie = mgmt->u.probe_resp.variable;
+ size_t ielen = len - offsetof(struct ieee80211_mgmt,
+ u.probe_resp.variable);
+
+ ftype = ieee80211_is_beacon(mgmt->frame_control) ?
+ CFG80211_BSS_FTYPE_BEACON : CFG80211_BSS_FTYPE_PRESP;
+
+ parse_mbssid_data(wiphy, data, ftype, mgmt->bssid,
+ le64_to_cpu(mgmt->u.probe_resp.timestamp),
+ le16_to_cpu(mgmt->u.probe_resp.beacon_int),
+ ie, ielen, trans_bss, gfp);
+}
+
+static void update_notlisted_nontrans(struct wiphy *wiphy,
+ struct cfg80211_internal_bss
+ *nontrans_bss,
+ struct ieee80211_mgmt *mgmt, size_t len,
+ gfp_t gfp)
+
+{
+ enum cfg80211_bss_frame_type ftype;
+ u8 *ie, *new_ie, *pos;
+ const u8 *tmp, *tmp1;
+ size_t ielen = len - offsetof(struct ieee80211_mgmt,
+ u.probe_resp.variable);
+ size_t new_ie_len;
+ struct cfg80211_bss_ies *new_ies;
+ const struct cfg80211_bss_ies *old;
+
+ ie = mgmt->u.probe_resp.variable;
+ ftype = ieee80211_is_beacon(mgmt->frame_control) ?
+ CFG80211_BSS_FTYPE_BEACON : CFG80211_BSS_FTYPE_PRESP;
+
+ new_ie_len = ielen;
+ tmp = cfg80211_find_ie(WLAN_EID_SSID, ie, ielen);
+ if (!tmp)
+ return;
+ new_ie_len -= tmp[1];
+ tmp = cfg80211_find_ie(WLAN_EID_MULTIPLE_BSSID, ie, ielen);
+ if (!tmp)
+ return;
+ new_ie_len -= tmp[1];
+ tmp = ieee80211_bss_get_ie(&nontrans_bss->pub, WLAN_EID_SSID);
+ if (!tmp)
+ return;
+ new_ie_len += tmp[1];
+
+ /* generate new ie for nontrans BSS
+ * 1. replace SSID with nontrans BSS' SSID
+ * 2. skip MBSSID IE
+ */
+ new_ie = kzalloc(new_ie_len, gfp);
+ if (!new_ie)
+ goto error;
+ pos = new_ie;
+ tmp = ieee80211_bss_get_ie(&nontrans_bss->pub, WLAN_EID_SSID);
+ if (!tmp)
+ goto error;
+
+ memcpy(pos, tmp, tmp[1] + 2);
+ pos += tmp[1] + 2;
+ tmp = cfg80211_find_ie(WLAN_EID_MULTIPLE_BSSID, ie, ielen);
+ tmp1 = cfg80211_find_ie(WLAN_EID_SSID, ie, ielen);
+ if (!tmp || !tmp1)
+ goto error;
+ memcpy(pos, (tmp1 + tmp1[1] + 2), (tmp - (tmp1 + tmp1[1] + 2)));
+ pos += (tmp - (tmp1 + tmp1[1] + 2));
+ memcpy(pos, tmp + tmp[1] + 2, ((ie + ielen) - (tmp + tmp[1] + 2)));
+
+ /* update ie */
+ new_ies = kzalloc(sizeof(*new_ies) + new_ie_len, gfp);
+ if (!new_ies)
+ goto error;
+ new_ies->len = new_ie_len;
+ new_ies->tsf = le64_to_cpu(mgmt->u.probe_resp.timestamp);
+ new_ies->from_beacon = ieee80211_is_beacon(mgmt->frame_control);
+ memcpy(new_ies->data, new_ie, new_ie_len);
+ if (ieee80211_is_probe_resp(mgmt->frame_control)) {
+ old = rcu_access_pointer(nontrans_bss->pub.proberesp_ies);
+ rcu_assign_pointer(nontrans_bss->pub.proberesp_ies, new_ies);
+ rcu_assign_pointer(nontrans_bss->pub.ies, new_ies);
+ if (old)
+ kfree_rcu((struct cfg80211_bss_ies *)old, rcu_head);
+ } else {
+ old = rcu_access_pointer(nontrans_bss->pub.beacon_ies);
+ rcu_assign_pointer(nontrans_bss->pub.beacon_ies, new_ies);
+ rcu_assign_pointer(nontrans_bss->pub.ies, new_ies);
+ if (old)
+ kfree_rcu((struct cfg80211_bss_ies *)old, rcu_head);
+ }
+
+ return;
+
+error:
+ kfree(new_ie);
+}
+
/* cfg80211_inform_bss_width_frame helper */
-struct cfg80211_bss *
-cfg80211_inform_bss_frame_data(struct wiphy *wiphy,
- struct cfg80211_inform_bss *data,
- struct ieee80211_mgmt *mgmt, size_t len,
- gfp_t gfp)
+static struct cfg80211_bss *
+cfg80211_inform_single_bss_frame_data(struct wiphy *wiphy,
+ struct cfg80211_inform_bss *data,
+ struct ieee80211_mgmt *mgmt, size_t len,
+ struct cfg80211_bss *trans_bss,
+ gfp_t gfp)
{
struct cfg80211_internal_bss tmp = {}, *res;
@@ -1254,6 +1625,50 @@ cfg80211_inform_bss_frame_data(struct wiphy *wiphy,
/* cfg80211_bss_update gives us a referenced result */
return &res->pub;
}
+
+struct cfg80211_bss *
+cfg80211_inform_bss_frame_data(struct wiphy *wiphy,
+ struct cfg80211_inform_bss *data,
+ struct ieee80211_mgmt *mgmt, size_t len,
+ gfp_t gfp)
+{
+ struct cfg80211_bss *res;
+ struct cfg80211_internal_bss *trans_bss, *tmp_bss;
+ const u8 *ie = mgmt->u.probe_resp.variable;
+ const struct cfg80211_bss_ies *ies1, *ies2;
+ size_t ielen = len - offsetof(struct ieee80211_mgmt,
+ u.probe_resp.variable);
+
+ res = cfg80211_inform_single_bss_frame_data(wiphy, data, mgmt,
+ len, NULL, gfp);
+ if (!cfg80211_find_ie(WLAN_EID_MULTIPLE_BSSID, ie, ielen))
+ return res;
+
+ /* process each non-transmitting bss */
+ parse_mbssid_frame_data(wiphy, data, mgmt, len, res, gfp);
+
+ /* check if the res has other nontransmitting bss which is not
+ * in MBSSID IE
+ */
+ ies1 = rcu_access_pointer(res->ies);
+ trans_bss = container_of(res, struct cfg80211_internal_bss, pub);
+ if (!trans_bss)
+ return res;
+
+ /* go through nontrans_list, if the timestamp of the BSS is
+ * earlier than the timestamp of the transmitting BSS then
+ * update it
+ */
+ list_for_each_entry(tmp_bss, &trans_bss->nontrans_list,
+ nontrans_list) {
+ ies2 = rcu_access_pointer(tmp_bss->pub.ies);
+ if (ies2->tsf < ies1->tsf)
+ update_notlisted_nontrans(wiphy, tmp_bss, mgmt,
+ len, gfp);
+ }
+
+ return res;
+}
EXPORT_SYMBOL(cfg80211_inform_bss_frame_data);
void cfg80211_ref_bss(struct wiphy *wiphy, struct cfg80211_bss *pub)
@@ -1291,7 +1706,7 @@ EXPORT_SYMBOL(cfg80211_put_bss);
void cfg80211_unlink_bss(struct wiphy *wiphy, struct cfg80211_bss *pub)
{
struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
- struct cfg80211_internal_bss *bss;
+ struct cfg80211_internal_bss *bss, *nontrans_bss, *tmp;
if (WARN_ON(!pub))
return;
@@ -1300,6 +1715,13 @@ void cfg80211_unlink_bss(struct wiphy *wiphy, struct cfg80211_bss *pub)
spin_lock_bh(&rdev->bss_lock);
if (!list_empty(&bss->list)) {
+ list_for_each_entry_safe(nontrans_bss, tmp,
+ &bss->nontrans_list,
+ nontrans_list) {
+ if (__cfg80211_unlink_bss(rdev, nontrans_bss))
+ rdev->bss_generation++;
+ }
+
if (__cfg80211_unlink_bss(rdev, bss))
rdev->bss_generation++;
}
--
2.7.4
^ permalink raw reply related
* platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
From: Cristian @ 2017-11-28 12:09 UTC (permalink / raw)
To: linux-wireless
Hello,
Linux version 4.15.0-041500rc1-generic
Report in:
https://bugzilla.kernel.org/show_bug.cgi?id=198013
dmesg:
[ 5.663292] platform regulatory.0: Direct firmware load for
regulatory.db failed with error -2
Regards,
--
Cristian
^ permalink raw reply
* Re: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
From: Johannes Berg @ 2017-11-28 12:21 UTC (permalink / raw)
To: Cristian, linux-wireless
In-Reply-To: <CABwnbUmWhxx0oN8H1H-0Qy9OYczszFX7yoLLud7VSBLxTn7Dyg@mail.gmail.com>
On Tue, 2017-11-28 at 09:09 -0300, Cristian wrote:
> Hello,
>
> Linux version 4.15.0-041500rc1-generic
>
> Report in:
> https://bugzilla.kernel.org/show_bug.cgi?id=198013
>
> dmesg:
> [ 5.663292] platform regulatory.0: Direct firmware load for
> regulatory.db failed with error -2
Yeah, nothing to worry about.
Seth will publish the file, and then people can get it, but until then
it's not actually needed.
johannes
^ permalink raw reply
* pull-request: iwlwifi 2017-11-28
From: Luca Coelho @ 2017-11-28 12:23 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi
[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]
Hi Kalle,
Here is my second set of fixes for 4.15. More details in the tag
description.
I have sent this out before and kbuildbot didn't find any issues.
Please let me know if there are any issues.
Cheers,
Luca.
The following changes since commit ed59b7d53c95548d83d4e7e1bc5edafcdcad09c9:
Merge ath-current from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2017-11-21 11:52:18 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2017-11-28
for you to fetch changes up to 0232d2cd7aa8e1b810fe84fb4059a0bd1eabe2ba:
iwlwifi: fix access to prph when transport is stopped (2017-11-25 17:12:56 +0200)
----------------------------------------------------------------
Second batch of fixes intended for 4.15.
* One fix in rate-scaling;
* One fix for the TX queue hang detection for AP/GO modes;
* Fix the TX queue hang timeout used in monitor interfaces;
* Fix packet injection;
* Remove a wrong error message when dumping PCI registers;
* Fix race condition with RF-kill;
----------------------------------------------------------------
Emmanuel Grumbach (3):
iwlwifi: mvm: don't use transmit queue hang detection when it is not possible
iwlwifi: mvm: fix the TX queue hang timeout for MONITOR vif type
iwlwifi: mvm: fix packet injection
Sara Sharon (2):
iwlwifi: pcie: fix erroneous "Read failed message"
iwlwifi: fix access to prph when transport is stopped
Shaul Triebitz (1):
iwlwifi: mvm: set correct chains in Rx status
drivers/net/wireless/intel/iwlwifi/fw/api/txq.h | 4 ++++
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 2 --
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 4 +++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 53 ++++++++++++++++++++++++++++++++++++++++-------------
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 3 ++-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 13 ++++++++++++-
drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c | 6 ++++++
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 10 ++++++++++
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 08/11] iwlwifi: mvm: Add debugfs support for FTM initiator fields
From: kbuild test robot @ 2017-11-28 13:34 UTC (permalink / raw)
To: Luca Coelho; +Cc: kbuild-all, kvalo, linux-wireless, Adiel Aloni, Luca Coelho
In-Reply-To: <20171125163444.24258-9-luca@coelho.fi>
[-- Attachment #1: Type: text/plain, Size: 10874 bytes --]
Hi Adiel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.15-rc1 next-20171128]
[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/Luca-Coelho/iwlwifi-updates-intended-for-v4-16-2017-11-25/20171128-205312
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
config: x86_64-randconfig-x011-201748 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c: In function 'iwl_dbgfs_tof_range_request_write':
>> drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:957:27: error: 'struct iwl_tof_range_req_cmd' has no member named 'common_calib'
mvm->tof_data.range_req.common_calib =
^
>> drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:966:27: error: 'struct iwl_tof_range_req_cmd' has no member named 'specific_calib'
mvm->tof_data.range_req.specific_calib =
^
In file included from include/linux/byteorder/little_endian.h:5:0,
from arch/x86/include/uapi/asm/byteorder.h:5,
from include/asm-generic/bitops/le.h:6,
from arch/x86/include/asm/bitops.h:518,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:71,
from drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:67:
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c: In function 'iwl_dbgfs_tof_range_request_read':
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:1055:20: error: 'struct iwl_tof_range_req_cmd' has no member named 'common_calib'
le16_to_cpu(cmd->common_calib));
^
include/uapi/linux/byteorder/little_endian.h:36:51: note: in definition of macro '__le16_to_cpu'
#define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
^
>> drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:1055:5: note: in expansion of macro 'le16_to_cpu'
le16_to_cpu(cmd->common_calib));
^~~~~~~~~~~
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:1057:20: error: 'struct iwl_tof_range_req_cmd' has no member named 'specific_calib'
le16_to_cpu(cmd->specific_calib));
^
include/uapi/linux/byteorder/little_endian.h:36:51: note: in definition of macro '__le16_to_cpu'
#define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
^
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:1057:5: note: in expansion of macro 'le16_to_cpu'
le16_to_cpu(cmd->specific_calib));
^~~~~~~~~~~
vim +957 drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
860
861 static ssize_t iwl_dbgfs_tof_range_request_write(struct ieee80211_vif *vif,
862 char *buf, size_t count,
863 loff_t *ppos)
864 {
865 struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
866 struct iwl_mvm *mvm = mvmvif->mvm;
867 u32 value;
868 int ret = 0;
869 char *data;
870
871 mutex_lock(&mvm->mutex);
872
873 data = iwl_dbgfs_is_match("request_id=", buf);
874 if (data) {
875 ret = kstrtou32(data, 10, &value);
876 if (ret == 0)
877 mvm->tof_data.range_req.request_id = value;
878 goto out;
879 }
880
881 data = iwl_dbgfs_is_match("initiator=", buf);
882 if (data) {
883 ret = kstrtou32(data, 10, &value);
884 if (ret == 0)
885 mvm->tof_data.range_req.initiator = value;
886 goto out;
887 }
888
889 data = iwl_dbgfs_is_match("one_sided_los_disable=", buf);
890 if (data) {
891 ret = kstrtou32(data, 10, &value);
892 if (ret == 0)
893 mvm->tof_data.range_req.one_sided_los_disable = value;
894 goto out;
895 }
896
897 data = iwl_dbgfs_is_match("req_timeout=", buf);
898 if (data) {
899 ret = kstrtou32(data, 10, &value);
900 if (ret == 0)
901 mvm->tof_data.range_req.req_timeout = value;
902 goto out;
903 }
904
905 data = iwl_dbgfs_is_match("report_policy=", buf);
906 if (data) {
907 ret = kstrtou32(data, 10, &value);
908 if (ret == 0)
909 mvm->tof_data.range_req.report_policy = value;
910 goto out;
911 }
912
913 data = iwl_dbgfs_is_match("macaddr_random=", buf);
914 if (data) {
915 ret = kstrtou32(data, 10, &value);
916 if (ret == 0)
917 mvm->tof_data.range_req.macaddr_random = value;
918 goto out;
919 }
920
921 data = iwl_dbgfs_is_match("num_of_ap=", buf);
922 if (data) {
923 ret = kstrtou32(data, 10, &value);
924 if (ret == 0)
925 mvm->tof_data.range_req.num_of_ap = value;
926 goto out;
927 }
928
929 data = iwl_dbgfs_is_match("macaddr_template=", buf);
930 if (data) {
931 u8 mac[ETH_ALEN];
932
933 if (!mac_pton(data, mac)) {
934 ret = -EINVAL;
935 goto out;
936 }
937 memcpy(mvm->tof_data.range_req.macaddr_template, mac, ETH_ALEN);
938 goto out;
939 }
940
941 data = iwl_dbgfs_is_match("macaddr_mask=", buf);
942 if (data) {
943 u8 mac[ETH_ALEN];
944
945 if (!mac_pton(data, mac)) {
946 ret = -EINVAL;
947 goto out;
948 }
949 memcpy(mvm->tof_data.range_req.macaddr_mask, mac, ETH_ALEN);
950 goto out;
951 }
952
953 data = iwl_dbgfs_is_match("common_calib=", buf);
954 if (data) {
955 ret = kstrtou32(data, 10, &value);
956 if (ret == 0)
> 957 mvm->tof_data.range_req.common_calib =
958 cpu_to_le16(value);
959 goto out;
960 }
961
962 data = iwl_dbgfs_is_match("specific_calib=", buf);
963 if (data) {
964 ret = kstrtou32(data, 10, &value);
965 if (ret == 0)
> 966 mvm->tof_data.range_req.specific_calib =
967 cpu_to_le16(value);
968 goto out;
969 }
970
971 data = iwl_dbgfs_is_match("ap=", buf);
972 if (data) {
973 struct iwl_tof_range_req_ap_entry ap = {};
974 int size = sizeof(struct iwl_tof_range_req_ap_entry);
975 u16 burst_period;
976 u8 *mac = ap.bssid;
977 unsigned int i;
978
979 if (sscanf(data, "%u %hhd %hhd %hhd"
980 "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx"
981 "%hhd %hhd %hd"
982 "%hhd %hhd %d"
983 "%hhx %hhd %hhd %hhd",
984 &i, &ap.channel_num, &ap.bandwidth,
985 &ap.ctrl_ch_position,
986 mac, mac + 1, mac + 2, mac + 3, mac + 4, mac + 5,
987 &ap.measure_type, &ap.num_of_bursts,
988 &burst_period,
989 &ap.samples_per_burst, &ap.retries_per_sample,
990 &ap.tsf_delta, &ap.location_req, &ap.asap_mode,
991 &ap.enable_dyn_ack, &ap.rssi) != 20) {
992 ret = -EINVAL;
993 goto out;
994 }
995 if (i >= IWL_MVM_TOF_MAX_APS) {
996 IWL_ERR(mvm, "Invalid AP index %d\n", i);
997 ret = -EINVAL;
998 goto out;
999 }
1000
1001 ap.burst_period = cpu_to_le16(burst_period);
1002
1003 memcpy(&mvm->tof_data.range_req.ap[i], &ap, size);
1004 goto out;
1005 }
1006
1007 data = iwl_dbgfs_is_match("send_range_request=", buf);
1008 if (data) {
1009 ret = kstrtou32(data, 10, &value);
1010 if (ret == 0 && value)
1011 ret = iwl_mvm_tof_range_request_cmd(mvm, vif);
1012 goto out;
1013 }
1014
1015 ret = -EINVAL;
1016 out:
1017 mutex_unlock(&mvm->mutex);
1018 return ret ?: count;
1019 }
1020
1021 static ssize_t iwl_dbgfs_tof_range_request_read(struct file *file,
1022 char __user *user_buf,
1023 size_t count, loff_t *ppos)
1024 {
1025 struct ieee80211_vif *vif = file->private_data;
1026 struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
1027 struct iwl_mvm *mvm = mvmvif->mvm;
1028 char buf[512];
1029 int pos = 0;
1030 const size_t bufsz = sizeof(buf);
1031 struct iwl_tof_range_req_cmd *cmd;
1032 int i;
1033
1034 cmd = &mvm->tof_data.range_req;
1035
1036 mutex_lock(&mvm->mutex);
1037
1038 pos += scnprintf(buf + pos, bufsz - pos, "request_id= %d\n",
1039 cmd->request_id);
1040 pos += scnprintf(buf + pos, bufsz - pos, "initiator= %d\n",
1041 cmd->initiator);
1042 pos += scnprintf(buf + pos, bufsz - pos, "one_sided_los_disable = %d\n",
1043 cmd->one_sided_los_disable);
1044 pos += scnprintf(buf + pos, bufsz - pos, "req_timeout= %d\n",
1045 cmd->req_timeout);
1046 pos += scnprintf(buf + pos, bufsz - pos, "report_policy= %d\n",
1047 cmd->report_policy);
1048 pos += scnprintf(buf + pos, bufsz - pos, "macaddr_random= %d\n",
1049 cmd->macaddr_random);
1050 pos += scnprintf(buf + pos, bufsz - pos, "macaddr_template= %pM\n",
1051 cmd->macaddr_template);
1052 pos += scnprintf(buf + pos, bufsz - pos, "macaddr_mask= %pM\n",
1053 cmd->macaddr_mask);
1054 pos += scnprintf(buf + pos, bufsz - pos, "common_calib= %d\n",
> 1055 le16_to_cpu(cmd->common_calib));
1056 pos += scnprintf(buf + pos, bufsz - pos, "specific_calib= %d\n",
1057 le16_to_cpu(cmd->specific_calib));
1058 pos += scnprintf(buf + pos, bufsz - pos, "num_of_ap= %d\n",
1059 cmd->num_of_ap);
1060 for (i = 0; i < cmd->num_of_ap; i++) {
1061 struct iwl_tof_range_req_ap_entry *ap = &cmd->ap[i];
1062
1063 pos += scnprintf(buf + pos, bufsz - pos,
1064 "ap %.2d: channel_num=%hhd bw=%hhd"
1065 " control=%hhd bssid=%pM type=%hhd"
1066 " num_of_bursts=%hhd burst_period=%hd ftm=%hhd"
1067 " retries=%hhd tsf_delta=%d"
1068 " tsf_delta_direction=%hhd location_req=0x%hhx "
1069 " asap=%hhd enable=%hhd rssi=%hhd\n",
1070 i, ap->channel_num, ap->bandwidth,
1071 ap->ctrl_ch_position, ap->bssid,
1072 ap->measure_type, ap->num_of_bursts,
1073 ap->burst_period, ap->samples_per_burst,
1074 ap->retries_per_sample, ap->tsf_delta,
1075 ap->tsf_delta_direction,
1076 ap->location_req, ap->asap_mode,
1077 ap->enable_dyn_ack, ap->rssi);
1078 }
1079
1080 mutex_unlock(&mvm->mutex);
1081
1082 return simple_read_from_buffer(user_buf, count, ppos, buf, pos);
1083 }
1084
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33526 bytes --]
^ permalink raw reply
* Re: [PATCH 08/11] iwlwifi: mvm: Add debugfs support for FTM initiator fields
From: Luciano Coelho @ 2017-11-28 14:39 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, kvalo, linux-wireless, Adiel Aloni
In-Reply-To: <201711282154.dLWMuU7H%fengguang.wu@intel.com>
On Tue, 2017-11-28 at 21:34 +0800, kbuild test robot wrote:
> Hi Adiel,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on wireless-drivers-next/master]
> [also build test ERROR on v4.15-rc1 next-20171128]
> [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/Luca-Coelho/iwlwifi-
> updates-intended-for-v4-16-2017-11-25/20171128-205312
> base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireles
> s-drivers-next.git master
> config: x86_64-randconfig-x011-201748 (attached as .config)
> compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All error/warnings (new ones prefixed by >>):
>
> drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c: In function
> 'iwl_dbgfs_tof_range_request_write':
> > > drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c:957:27:
> > > error: 'struct iwl_tof_range_req_cmd' has no member named
> > > 'common_calib'
>
> mvm->tof_data.range_req.common_calib =
Ouch, for some reason I didn't have debugfs enabled in my .config and
missed this.
This patch depends on some code that is not upstream yet, so I'll just
remove it for now.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH v3] bcma:Adjust block comments
From: Ashish Kalra @ 2017-11-28 15:54 UTC (permalink / raw)
To: zajec5; +Cc: himanshujha199640, linux-wireless, linux-kernel, eashishkalra
use * for block comments in multiple lines according to kernel coding
style
Reported by: checkpatch.pl
Signed-off-by: Ashish Kalra <eashishkalra@gmail.com>
---
Change log:
-v3: Improvement on commit message as per review from Morgan Freeman <morganfreeman6991@gmail.com>
-v2: Improvement on commit message as per review from Morgan Freeman <morganfreeman6991@gmail.com>(https://lkml.org/lkml/2017/11/27/1259)
-v1: https://lkml.org/lkml/2017/11/26/85
drivers/bcma/driver_pcie2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/bcma/driver_pcie2.c b/drivers/bcma/driver_pcie2.c
index b1a6e327cb23..cf889fc62ac7 100644
--- a/drivers/bcma/driver_pcie2.c
+++ b/drivers/bcma/driver_pcie2.c
@@ -83,7 +83,8 @@ static void bcma_core_pcie2_hw_ltr_war(struct bcma_drv_pcie2 *pcie2)
bcma_core_pcie2_set_ltr_vals(pcie2);
/* TODO:
- si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); */
+ *si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0);
+ */
/* enable the LTR */
devstsctr2 |= PCIE2_CAP_DEVSTSCTRL2_LTRENAB;
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v3] bcma:Adjust block comments
From: Himanshu Jha @ 2017-11-28 16:05 UTC (permalink / raw)
To: Ashish Kalra; +Cc: zajec5, linux-wireless, linux-kernel
In-Reply-To: <20171128155458.1036-1-eashishkalra@gmail.com>
Hi Ashish,
On Tue, Nov 28, 2017 at 09:24:58PM +0530, Ashish Kalra wrote:
> use * for block comments in multiple lines according to kernel coding
> style
>
> Reported by: checkpatch.pl
>
> Signed-off-by: Ashish Kalra <eashishkalra@gmail.com>
> ---
Looks good now!
FWIW,
Reviewed-by: Himanshu Jha <himanshujha199640@gmail.com>
> Change log:
> -v3: Improvement on commit message as per review from Morgan Freeman <morganfreeman6991@gmail.com>
BTW, this <morganfreeman6991@gmail.com> is my secondary email subscibed
to linux-wirless as I don't want my primary email to be flooded with
frequent emails, and my upstream mail is himanshujha199640@gmail.com !
Thanks
Himanshu Jha
^ permalink raw reply
* Re: Wifi RTL8723bu driver test: failed to scan
From: Jes Sorensen @ 2017-11-28 16:14 UTC (permalink / raw)
To: Mylene JOSSERAND
Cc: kvalo, linux-wireless, netdev, Thomas Petazzoni, Maxime Ripard
In-Reply-To: <20171122105116.57c3c000@dell-desktop.home>
On 11/22/2017 04:51 AM, Mylene JOSSERAND wrote:
> Hello Jes Sorensen,
>
> I am currently testing a LM811 Wifi/BT USB dongle [1] on a Sinlinx
> SinA33 Allwinner SoC board [2]. I saw that I should use the realtek
> driver RTL8723BU for this USB dongle.
>
> Currently, I am only testing the Wifi and the mainline driver (kernel
> 4.14-rc7) does not seem to work. At least, the scanning does not output
> anything.
>
> I tested the driver recommended by LM Technologies [3] and it works
> fine (scan, connect and ping are ok). Before investigating on the
> differences between these two drivers, do you have any idea about this
> issue?
>
> Here are the commands and output I got with mainline's driver:
I have not looked at the driver these LM Technologies people are
referring to, but I am guessing it's the vendor code.
8723bu is a little dicey because it has BT in the chip and if you enable
that the two drivers need to interact, which rtl8xxxu currently doesn't
know about. Check your dmesg output to make sure you don't have some BT
thing loaded hijacking the chip.
Jes
^ permalink raw reply
* Re: Slow connection with rtl8xxxu and 8192eu chipset
From: Jes Sorensen @ 2017-11-28 16:16 UTC (permalink / raw)
To: Nikolay Borisov, linux-wireless
In-Reply-To: <ce042534-6ba9-9654-c99f-7cfdff45b88a@gmail.com>
On 11/14/2017 05:39 AM, Nikolay Borisov wrote:
>
>
> On 14.11.2017 11:26, Nikolay Borisov wrote:
>> (Please CC as I'm not subscribed)
>>
>> Hello,
>>
>> I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as
>>
>> Bus 001 Device 003: ID 2357:0108
>>
>> Unfortunately with the in-kernel rtl8xxxu driver I don't get very good
>> results:
>>
>> wifi1 IEEE 802.11 ESSID:"HOME"
>> Mode:Managed Frequency:2.462 GHz Access Point:
>> 30:B5:C2:75:A4:CD
>> Bit Rate=1 Mb/s Tx-Power=20 dBm
>> Retry short limit:7 RTS thr=2347 B Fragment thr:off
>> Power Management:off
>> Link Quality=26/70 Signal level=-84 dBm
>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>> Tx excessive retries:0 Invalid misc:165 Missed beacon:0
>>
>>
>> At the same time if I use an out of tree driver acquired from github:
>> https://github.com/Mange/rtl8192eu-linux-driver I get the following:
>>
>> wifi1 IEEE 802.11bgn ESSID:"HOME" Nickname:"<WIFI@REALTEK>"
>> Mode:Managed Frequency:2.462 GHz Access Point:
>> 30:B5:C2:75:A4:CD
>> Bit Rate:144.4 Mb/s Sensitivity:0/0
>> Retry:off RTS thr:off Fragment thr:off
>> Power Management:off
>> Link Quality=81/100 Signal level=100/100 Noise level=0/100
>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>>
>> Clearly this is a software problem of the in-kernel driver. I'm using
>> v4.10.17 with commit c14239f23adb ("rtl8xxxu: Add another 8192eu device
>> to the USB list") so that my device is recognised. Latest commit for
>> that driver in my kernel is: c59f13bbead4 ("rtl8xxxu: Work around issue
>> with 8192eu and 8723bu devices not reconnecting").
>>
>> Any ideas what I can do to further debug this, I'd really like to use
>> the in-kernel driver ?
>
> I just tested with verbatim 4.14 and even though the wireless works,
> iwconfig reports something strange:
>
> iwconfig wifi1
> wifi1 no wireless extensions.
>
> However, my device works as expected (albeit still slow):
>
> wifi1 Link encap:Ethernet HWaddr 18:d6:c7:0d:47:3c
> inet addr:10.20.1.175 Bcast:10.20.1.255 Mask:255.255.255.0
> inet6 addr: fe80::281d:5f27:eb1b:8ded/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:38903 errors:0 dropped:0 overruns:0 frame:0
> TX packets:24689 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:51524413 (51.5 MB) TX bytes:5503039 (5.5 MB)
iwconfig has been deprecated for a decade, but maybe you could elaborate
on what you feel is strange in this output?
The 8192eu driver has some issues, it looks like firmware rate support
isn't working and it therefore transmits everything at low rates. I have
to find some time to look into this.
Jes
^ permalink raw reply
* Re: Slow connection with rtl8xxxu and 8192eu chipset
From: Nikolay Borisov @ 2017-11-28 16:26 UTC (permalink / raw)
To: Jes Sorensen, linux-wireless
In-Reply-To: <61e93af9-ef8a-5319-5a23-0b622d3cf0d0@gmail.com>
On 28.11.2017 18:16, Jes Sorensen wrote:
> On 11/14/2017 05:39 AM, Nikolay Borisov wrote:
>>
>>
>> On 14.11.2017 11:26, Nikolay Borisov wrote:
>>> (Please CC as I'm not subscribed)
>>>
>>> Hello,
>>>
>>> I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as
>>>
>>> Bus 001 Device 003: ID 2357:0108
>>>
>>> Unfortunately with the in-kernel rtl8xxxu driver I don't get very good
>>> results:
>>>
>>> wifi1 IEEE 802.11 ESSID:"HOME"
>>> Mode:Managed Frequency:2.462 GHz Access Point:
>>> 30:B5:C2:75:A4:CD
>>> Bit Rate=1 Mb/s Tx-Power=20 dBm
>>> Retry short limit:7 RTS thr=2347 B Fragment thr:off
>>> Power Management:off
>>> Link Quality=26/70 Signal level=-84 dBm
>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>>> Tx excessive retries:0 Invalid misc:165 Missed beacon:0
>>>
>>>
>>> At the same time if I use an out of tree driver acquired from github:
>>> https://github.com/Mange/rtl8192eu-linux-driver I get the following:
>>>
>>> wifi1 IEEE 802.11bgn ESSID:"HOME" Nickname:"<WIFI@REALTEK>"
>>> Mode:Managed Frequency:2.462 GHz Access Point:
>>> 30:B5:C2:75:A4:CD
>>> Bit Rate:144.4 Mb/s Sensitivity:0/0
>>> Retry:off RTS thr:off Fragment thr:off
>>> Power Management:off
>>> Link Quality=81/100 Signal level=100/100 Noise level=0/100
>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>>> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>>>
>>> Clearly this is a software problem of the in-kernel driver. I'm using
>>> v4.10.17 with commit c14239f23adb ("rtl8xxxu: Add another 8192eu device
>>> to the USB list") so that my device is recognised. Latest commit for
>>> that driver in my kernel is: c59f13bbead4 ("rtl8xxxu: Work around issue
>>> with 8192eu and 8723bu devices not reconnecting").
>>>
>>> Any ideas what I can do to further debug this, I'd really like to use
>>> the in-kernel driver ?
>>
>> I just tested with verbatim 4.14 and even though the wireless works,
>> iwconfig reports something strange:
>>
>> iwconfig wifi1
>> wifi1 no wireless extensions.
>>
>> However, my device works as expected (albeit still slow):
>>
>> wifi1 Link encap:Ethernet HWaddr 18:d6:c7:0d:47:3c
>> inet addr:10.20.1.175 Bcast:10.20.1.255 Mask:255.255.255.0
>> inet6 addr: fe80::281d:5f27:eb1b:8ded/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:38903 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:24689 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:51524413 (51.5 MB) TX bytes:5503039 (5.5 MB)
>
> iwconfig has been deprecated for a decade, but maybe you could elaborate
> on what you feel is strange in this output?
Well there are 2 things:
1. The low bitrate - which I've confirmed doing actual data test, ie,
not just the number but the fact that the speeds are low.
2. The worse signal level/link quality.
>
> The 8192eu driver has some issues, it looks like firmware rate support
> isn't working and it therefore transmits everything at low rates. I have
> to find some time to look into this.>
> Jes
>
^ permalink raw reply
* Re: Slow connection with rtl8xxxu and 8192eu chipset
From: Jes Sorensen @ 2017-11-28 16:35 UTC (permalink / raw)
To: Nikolay Borisov, linux-wireless
In-Reply-To: <7cb804e5-c1f5-a5d4-764d-e5a786625093@gmail.com>
On 11/28/2017 11:26 AM, Nikolay Borisov wrote:
>
>
> On 28.11.2017 18:16, Jes Sorensen wrote:
>> On 11/14/2017 05:39 AM, Nikolay Borisov wrote:
>>>
>>>
>>> On 14.11.2017 11:26, Nikolay Borisov wrote:
>>>> (Please CC as I'm not subscribed)
>>>>
>>>> Hello,
>>>>
>>>> I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as
>>>>
>>>> Bus 001 Device 003: ID 2357:0108
>>>>
>>>> Unfortunately with the in-kernel rtl8xxxu driver I don't get very good
>>>> results:
>>>>
>>>> wifi1 IEEE 802.11 ESSID:"HOME"
>>>> Mode:Managed Frequency:2.462 GHz Access Point:
>>>> 30:B5:C2:75:A4:CD
>>>> Bit Rate=1 Mb/s Tx-Power=20 dBm
>>>> Retry short limit:7 RTS thr=2347 B Fragment thr:off
>>>> Power Management:off
>>>> Link Quality=26/70 Signal level=-84 dBm
>>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>>>> Tx excessive retries:0 Invalid misc:165 Missed beacon:0
>>>>
>>>>
>>>> At the same time if I use an out of tree driver acquired from github:
>>>> https://github.com/Mange/rtl8192eu-linux-driver I get the following:
>>>>
>>>> wifi1 IEEE 802.11bgn ESSID:"HOME" Nickname:"<WIFI@REALTEK>"
>>>> Mode:Managed Frequency:2.462 GHz Access Point:
>>>> 30:B5:C2:75:A4:CD
>>>> Bit Rate:144.4 Mb/s Sensitivity:0/0
>>>> Retry:off RTS thr:off Fragment thr:off
>>>> Power Management:off
>>>> Link Quality=81/100 Signal level=100/100 Noise level=0/100
>>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>>>> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>>>>
>>>> Clearly this is a software problem of the in-kernel driver. I'm using
>>>> v4.10.17 with commit c14239f23adb ("rtl8xxxu: Add another 8192eu device
>>>> to the USB list") so that my device is recognised. Latest commit for
>>>> that driver in my kernel is: c59f13bbead4 ("rtl8xxxu: Work around issue
>>>> with 8192eu and 8723bu devices not reconnecting").
>>>>
>>>> Any ideas what I can do to further debug this, I'd really like to use
>>>> the in-kernel driver ?
>>>
>>> I just tested with verbatim 4.14 and even though the wireless works,
>>> iwconfig reports something strange:
>>>
>>> iwconfig wifi1
>>> wifi1 no wireless extensions.
>>>
>>> However, my device works as expected (albeit still slow):
>>>
>>> wifi1 Link encap:Ethernet HWaddr 18:d6:c7:0d:47:3c
>>> inet addr:10.20.1.175 Bcast:10.20.1.255 Mask:255.255.255.0
>>> inet6 addr: fe80::281d:5f27:eb1b:8ded/64 Scope:Link
>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>> RX packets:38903 errors:0 dropped:0 overruns:0 frame:0
>>> TX packets:24689 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:1000
>>> RX bytes:51524413 (51.5 MB) TX bytes:5503039 (5.5 MB)
>>
>> iwconfig has been deprecated for a decade, but maybe you could elaborate
>> on what you feel is strange in this output?
>
> Well there are 2 things:
>
> 1. The low bitrate - which I've confirmed doing actual data test, ie,
> not just the number but the fact that the speeds are low.
>
> 2. The worse signal level/link quality.
I don't see either of those in the iwconfig output
The low TX bitrate is a known issue. Somehow the firmware rate handling
doesn't seem to work (or it works differently than I assumed) similar to
for the 8188eu. It's something I need to figure out when I have some time.
As for link quality is this something you measured or read out of 'iw' ?
Thanks,
Jes
^ permalink raw reply
* Re: Slow connection with rtl8xxxu and 8192eu chipset
From: Nikolay Borisov @ 2017-11-28 16:49 UTC (permalink / raw)
To: Jes Sorensen, linux-wireless
In-Reply-To: <0b5d91b2-7e79-5767-aab7-7911806454a3@gmail.com>
On 28.11.2017 18:35, Jes Sorensen wrote:
> On 11/28/2017 11:26 AM, Nikolay Borisov wrote:
>>
>>
>> On 28.11.2017 18:16, Jes Sorensen wrote:
>>> On 11/14/2017 05:39 AM, Nikolay Borisov wrote:
>>>>
>>>>
>>>> On 14.11.2017 11:26, Nikolay Borisov wrote:
>>>>> (Please CC as I'm not subscribed)
>>>>>
>>>>> Hello,
>>>>>
>>>>> I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as
>>>>>
>>>>> Bus 001 Device 003: ID 2357:0108
>>>>>
>>>>> Unfortunately with the in-kernel rtl8xxxu driver I don't get very good
>>>>> results:
>>>>>
>>>>> wifi1 IEEE 802.11 ESSID:"HOME"
>>>>> Mode:Managed Frequency:2.462 GHz Access Point:
>>>>> 30:B5:C2:75:A4:CD
>>>>> Bit Rate=1 Mb/s Tx-Power=20 dBm
>>>>> Retry short limit:7 RTS thr=2347 B Fragment thr:off
>>>>> Power Management:off
>>>>> Link Quality=26/70 Signal level=-84 dBm
>>>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>>>>> Tx excessive retries:0 Invalid misc:165 Missed beacon:0
>>>>>
>>>>>
>>>>> At the same time if I use an out of tree driver acquired from github:
>>>>> https://github.com/Mange/rtl8192eu-linux-driver I get the following:
>>>>>
>>>>> wifi1 IEEE 802.11bgn ESSID:"HOME" Nickname:"<WIFI@REALTEK>"
>>>>> Mode:Managed Frequency:2.462 GHz Access Point:
>>>>> 30:B5:C2:75:A4:CD
>>>>> Bit Rate:144.4 Mb/s Sensitivity:0/0
>>>>> Retry:off RTS thr:off Fragment thr:off
>>>>> Power Management:off
>>>>> Link Quality=81/100 Signal level=100/100 Noise level=0/100
>>>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>>>>> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>>>>>
>>>>> Clearly this is a software problem of the in-kernel driver. I'm using
>>>>> v4.10.17 with commit c14239f23adb ("rtl8xxxu: Add another 8192eu device
>>>>> to the USB list") so that my device is recognised. Latest commit for
>>>>> that driver in my kernel is: c59f13bbead4 ("rtl8xxxu: Work around issue
>>>>> with 8192eu and 8723bu devices not reconnecting").
>>>>>
>>>>> Any ideas what I can do to further debug this, I'd really like to use
>>>>> the in-kernel driver ?
>>>>
>>>> I just tested with verbatim 4.14 and even though the wireless works,
>>>> iwconfig reports something strange:
>>>>
>>>> iwconfig wifi1
>>>> wifi1 no wireless extensions.
>>>>
>>>> However, my device works as expected (albeit still slow):
>>>>
>>>> wifi1 Link encap:Ethernet HWaddr 18:d6:c7:0d:47:3c
>>>> inet addr:10.20.1.175 Bcast:10.20.1.255 Mask:255.255.255.0
>>>> inet6 addr: fe80::281d:5f27:eb1b:8ded/64 Scope:Link
>>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>>> RX packets:38903 errors:0 dropped:0 overruns:0 frame:0
>>>> TX packets:24689 errors:0 dropped:0 overruns:0 carrier:0
>>>> collisions:0 txqueuelen:1000
>>>> RX bytes:51524413 (51.5 MB) TX bytes:5503039 (5.5 MB)
>>>
>>> iwconfig has been deprecated for a decade, but maybe you could elaborate
>>> on what you feel is strange in this output?
>>
>> Well there are 2 things:
>>
>> 1. The low bitrate - which I've confirmed doing actual data test, ie,
>> not just the number but the fact that the speeds are low.
>>
>> 2. The worse signal level/link quality.
>
> I don't see either of those in the iwconfig output
>
> The low TX bitrate is a known issue. Somehow the firmware rate handling
> doesn't seem to work (or it works differently than I assumed) similar to
> for the 8188eu. It's something I need to figure out when I have some time.
>
> As for link quality is this something you measured or read out of 'iw' ?
Well there is:
Link Quality=26/70 Signal level=-84 dBm < - with rtl8xxxu driver
Link Quality=81/100 Signal level=100/100 Noise level=0/100 <-- with
vendor's driver. Another vector was the icon of network manager had only
2 bars with the in-tree driver and had full bars with out (yeah, this is
a bit subjective metric but it's the best i've got).
>
> Thanks,
> Jes
>
^ permalink raw reply
* drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c: Odd array size
From: Joe Perches @ 2017-11-28 16:49 UTC (permalink / raw)
To: Kalle Valo; +Cc: Larry.Finger, linux-wireless
61 entries in this table:
static const u8 OFDM_CONFIG[] = {
0x10, 0x0F, 0x0A, 0x0C, 0x14, 0xFA, 0xFF, 0x50,
0x00, 0x50, 0x00, 0x00, 0x00, 0x5C, 0x00, 0x00,
0x40, 0x00, 0x40, 0x00, 0x00, 0x00, 0xA8, 0x26,
0x32, 0x33, 0x06, 0xA5, 0x6F, 0x55, 0xC8, 0xBB,
0x0A, 0xE1, 0x2C, 0x4A, 0x86, 0x83, 0x34, 0x00,
0x4F, 0x24, 0x6F, 0xC2, 0x03, 0x40, 0x80, 0x00,
0xC0, 0xC1, 0x58, 0xF1, 0x00, 0xC4, 0x90, 0x3e,
0xD8, 0x3C, 0x7B, 0x10, 0x10
};
but only 60 written?
static void rtl8187se_write_ofdm_config(struct ieee80211_hw *dev)
{
/* write OFDM_CONFIG table */
int i;
for (i = 0; i < 60; i++)
rtl8225se_write_phy_ofdm(dev, i, OFDM_CONFIG[i]);
}
This is the only use of OFDM_CONFIG.
What is the defect here?
Should 60 be ARRAY_SIZE(OFDM_CONFIG) or should the array be shortened?
One too many entries or one too few a write?
My guess would be one too few a write.
^ permalink raw reply
* Re: Slow connection with rtl8xxxu and 8192eu chipset
From: Jes Sorensen @ 2017-11-28 16:59 UTC (permalink / raw)
To: Nikolay Borisov, linux-wireless
In-Reply-To: <12fed6ac-0e21-a137-4d7c-3bb341c4e831@gmail.com>
On 11/28/2017 11:49 AM, Nikolay Borisov wrote:
>
>
> On 28.11.2017 18:35, Jes Sorensen wrote:
>> On 11/28/2017 11:26 AM, Nikolay Borisov wrote:
>>>
>>>
>>> On 28.11.2017 18:16, Jes Sorensen wrote:
>>>> On 11/14/2017 05:39 AM, Nikolay Borisov wrote:
>>>>>
>>>>>
>>>>> I just tested with verbatim 4.14 and even though the wireless works,
>>>>> iwconfig reports something strange:
>>>>>
>>>>> iwconfig wifi1
>>>>> wifi1 no wireless extensions.
>>>>>
>>>>> However, my device works as expected (albeit still slow):
>>>>>
>>>>> wifi1 Link encap:Ethernet HWaddr 18:d6:c7:0d:47:3c
>>>>> inet addr:10.20.1.175 Bcast:10.20.1.255 Mask:255.255.255.0
>>>>> inet6 addr: fe80::281d:5f27:eb1b:8ded/64 Scope:Link
>>>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>>>> RX packets:38903 errors:0 dropped:0 overruns:0 frame:0
>>>>> TX packets:24689 errors:0 dropped:0 overruns:0 carrier:0
>>>>> collisions:0 txqueuelen:1000
>>>>> RX bytes:51524413 (51.5 MB) TX bytes:5503039 (5.5 MB)
>>>>
>>>> iwconfig has been deprecated for a decade, but maybe you could elaborate
>>>> on what you feel is strange in this output?
>>>
>>> Well there are 2 things:
>>>
>>> 1. The low bitrate - which I've confirmed doing actual data test, ie,
>>> not just the number but the fact that the speeds are low.
>>>
>>> 2. The worse signal level/link quality.
>>
>> I don't see either of those in the iwconfig output
>>
>> The low TX bitrate is a known issue. Somehow the firmware rate handling
>> doesn't seem to work (or it works differently than I assumed) similar to
>> for the 8188eu. It's something I need to figure out when I have some time.
>>
>> As for link quality is this something you measured or read out of 'iw' ?
>
> Well there is:
>
> Link Quality=26/70 Signal level=-84 dBm < - with rtl8xxxu driver
>
> Link Quality=81/100 Signal level=100/100 Noise level=0/100 <-- with
> vendor's driver. Another vector was the icon of network manager had only
> 2 bars with the in-tree driver and had full bars with out (yeah, this is
> a bit subjective metric but it's the best i've got).
OK, the link reporting from rtl8xxxu isn't complete, so I wouldn't put
too much into this.
Cheers,
Jes
^ permalink raw reply
* Re: drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c: Odd array size
From: Larry Finger @ 2017-11-28 20:39 UTC (permalink / raw)
To: Joe Perches, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1511887757.19952.38.camel@perches.com>
On 11/28/2017 10:49 AM, Joe Perches wrote:
> 61 entries in this table:
>
> static const u8 OFDM_CONFIG[] = {
> 0x10, 0x0F, 0x0A, 0x0C, 0x14, 0xFA, 0xFF, 0x50,
> 0x00, 0x50, 0x00, 0x00, 0x00, 0x5C, 0x00, 0x00,
> 0x40, 0x00, 0x40, 0x00, 0x00, 0x00, 0xA8, 0x26,
> 0x32, 0x33, 0x06, 0xA5, 0x6F, 0x55, 0xC8, 0xBB,
> 0x0A, 0xE1, 0x2C, 0x4A, 0x86, 0x83, 0x34, 0x00,
> 0x4F, 0x24, 0x6F, 0xC2, 0x03, 0x40, 0x80, 0x00,
> 0xC0, 0xC1, 0x58, 0xF1, 0x00, 0xC4, 0x90, 0x3e,
> 0xD8, 0x3C, 0x7B, 0x10, 0x10
> };
>
> but only 60 written?
>
> static void rtl8187se_write_ofdm_config(struct ieee80211_hw *dev)
> {
> /* write OFDM_CONFIG table */
> int i;
>
> for (i = 0; i < 60; i++)
> rtl8225se_write_phy_ofdm(dev, i, OFDM_CONFIG[i]);
>
> }
>
> This is the only use of OFDM_CONFIG.
>
> What is the defect here?
>
> Should 60 be ARRAY_SIZE(OFDM_CONFIG) or should the array be shortened?
>
> One too many entries or one too few a write?
> My guess would be one too few a write.
Joe,
You are probably right; however, as I do not have this device and cannot test,
the safer thing would be to crop the array back to 60 entries. That way the
driver's behavior does not change.
I looked to see if rtl8187 had a similar construct, but it does not.
Larry
^ permalink raw reply
* Re: drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c: Odd array size
From: Joe Perches @ 2017-11-28 20:50 UTC (permalink / raw)
To: Larry Finger, Kalle Valo, Andrea Merello; +Cc: linux-wireless
In-Reply-To: <f2da30a1-0b42-ce8c-2054-47fa9ae3b4e5@lwfinger.net>
(adding the original submitter: Andrea Merello)
On Tue, 2017-11-28 at 14:39 -0600, Larry Finger wrote:
> On 11/28/2017 10:49 AM, Joe Perches wrote:
> > 61 entries in this table:
> >
> > static const u8 OFDM_CONFIG[] = {
> > 0x10, 0x0F, 0x0A, 0x0C, 0x14, 0xFA, 0xFF, 0x50,
> > 0x00, 0x50, 0x00, 0x00, 0x00, 0x5C, 0x00, 0x00,
> > 0x40, 0x00, 0x40, 0x00, 0x00, 0x00, 0xA8, 0x26,
> > 0x32, 0x33, 0x06, 0xA5, 0x6F, 0x55, 0xC8, 0xBB,
> > 0x0A, 0xE1, 0x2C, 0x4A, 0x86, 0x83, 0x34, 0x00,
> > 0x4F, 0x24, 0x6F, 0xC2, 0x03, 0x40, 0x80, 0x00,
> > 0xC0, 0xC1, 0x58, 0xF1, 0x00, 0xC4, 0x90, 0x3e,
> > 0xD8, 0x3C, 0x7B, 0x10, 0x10
> > };
> >
> > but only 60 written?
> >
> > static void rtl8187se_write_ofdm_config(struct ieee80211_hw *dev)
> > {
> > /* write OFDM_CONFIG table */
> > int i;
> >
> > for (i = 0; i < 60; i++)
> > rtl8225se_write_phy_ofdm(dev, i, OFDM_CONFIG[i]);
> >
> > }
> >
> > This is the only use of OFDM_CONFIG.
> >
> > What is the defect here?
> >
> > Should 60 be ARRAY_SIZE(OFDM_CONFIG) or should the array be shortened?
> >
> > One too many entries or one too few a write?
> > My guess would be one too few a write.
>
> Joe,
>
> You are probably right; however, as I do not have this device and cannot test,
> the safer thing would be to crop the array back to 60 entries. That way the
> driver's behavior does not change.
I'd guess the safest change would be adding a comment
and not making a code change at all.
cheers, Joe
^ permalink raw reply
* Re: [PATCH] ath10k: handling qos at STA side based on AP WMM enable/disable
From: Sebastian Gottschall @ 2017-11-29 2:57 UTC (permalink / raw)
To: bpothuno, ath10k; +Cc: linux-wireless
In-Reply-To: <1511863650-9419-1-git-send-email-bpothuno@qti.qualcomm.com>
did you notice that Marvell 88W8964 based clients will crash 10.4-3.5.3
firmwares? (tested with 9984 and 10.4-3.5.3-00038)
client device was a linksys wrt3200acm running dd-wrt for testing
Am 28.11.2017 um 11:07 schrieb bpothuno@qti.qualcomm.com:
> From: Balaji Pothunoori <bpothuno@qti.qualcomm.com>
>
> Data packets are not sent by STA in case of STA joined to
> non QOS AP (WMM disabled AP). This is happening because of STA
> is sending data packets to firmware from host with qos enabled
> along with non qos queue value(TID = 16).
> Due to qos enabled, firmware is discarding the packet.
>
> This patch fixes this issue by updating the qos based on station
> WME capability field if WMM is disabled in AP.
>
> This patch is required by 10.4 family chipsets like
> QCA4019/QCA9888/QCA9884/QCA99X0.
> Firmware Versoin : 10.4-3.5.1-00018.
>
> For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
> has no effect.
>
> Signed-off-by: Balaji Pothunoori <bpothuno@qti.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 0a947ee..2616b99 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
> }
> break;
> case WMI_VDEV_TYPE_STA:
> - if (vif->bss_conf.qos)
> + if (sta->wme)
> arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
> break;
> case WMI_VDEV_TYPE_IBSS:
--
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.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* RE: [PATCH] ath10k: handling qos at STA side based on AP WMM enable/disable
From: Balaji Pothunoori @ 2017-11-29 6:58 UTC (permalink / raw)
To: Sebastian Gottschall, ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <5ec76365-7ca2-15bd-0bcc-9cc19b9f3b27@dd-wrt.com>
SGkgU2ViYXN0aWFuLA0KDQpJZiBJIGFtIG5vdCB3cm9uZyB5b3UgYXJlIHNlZWluZyB0aGUgaXNz
dWUgd2l0aCBXUlQzMjAwQUNNIChNYXJ2ZWxsIDg4Vzg5NjQpIGFzIGNsaWVudCArIFFDQTk5ODQg
KEZXIDogMTAuNC0zLjUuMy0wMDAzOCkgYXMgQVAgd2l0aCBiZWxvdyBjaGFuZ2UgeW91IGFyZSBz
ZWVpbmcgdGhlIGNyYXNoIHdoaWxlIHJ1bm5pbmcgdHJhZmZpYyBiZXR3ZWVuIHRoZSBXUlQzMjAw
QUNNICsgUUNBOTk4NCA/DQpEbyB5b3UgdXNlZCAgYW55IG90aGVyIGNsaWVudCBpbiBwbGFjZSBv
ZiBXUlQzMjAwQUNNID8NCkNhbiB5b3Ugc2hhcmUgdGhlIG1vcmUgZGV0YWlscyBvbiBmaXJtd2Fy
ZSBjcmFzaCA/DQoNClJlZ2FyZHMsDQpCYWxhamkuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBTZWJhc3RpYW4gR290dHNjaGFsbCBbbWFpbHRvOnMuZ290dHNjaGFsbEBkZC13
cnQuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgODoyOCBBTQ0KVG86
IEJhbGFqaSBQb3RodW5vb3JpIDxicG90aHVub0BxdGkucXVhbGNvbW0uY29tPjsgYXRoMTBrQGxp
c3RzLmluZnJhZGVhZC5vcmcNCkNjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmcNClN1
YmplY3Q6IFJlOiBbUEFUQ0hdIGF0aDEwazogaGFuZGxpbmcgcW9zIGF0IFNUQSBzaWRlIGJhc2Vk
IG9uIEFQIFdNTSBlbmFibGUvZGlzYWJsZQ0KDQpkaWQgeW91IG5vdGljZcKgIHRoYXQgTWFydmVs
bCA4OFc4OTY0IGJhc2VkIGNsaWVudHMgd2lsbCBjcmFzaCAxMC40LTMuNS4zIGZpcm13YXJlcz/C
oCAodGVzdGVkIHdpdGggOTk4NCBhbmQgMTAuNC0zLjUuMy0wMDAzOCkgY2xpZW50IGRldmljZSB3
YXMgYSBsaW5rc3lzIHdydDMyMDBhY20gcnVubmluZyBkZC13cnQgZm9yIHRlc3RpbmcNCg0KQW0g
MjguMTEuMjAxNyB1bSAxMTowNyBzY2hyaWViIGJwb3RodW5vQHF0aS5xdWFsY29tbS5jb206DQo+
IEZyb206IEJhbGFqaSBQb3RodW5vb3JpIDxicG90aHVub0BxdGkucXVhbGNvbW0uY29tPg0KPg0K
PiBEYXRhIHBhY2tldHMgYXJlIG5vdCBzZW50IGJ5IFNUQSBpbiBjYXNlIG9mIFNUQSBqb2luZWQg
dG8gbm9uIFFPUyBBUCANCj4gKFdNTSBkaXNhYmxlZCBBUCkuIFRoaXMgaXMgaGFwcGVuaW5nIGJl
Y2F1c2Ugb2YgU1RBIGlzIHNlbmRpbmcgZGF0YSANCj4gcGFja2V0cyB0byBmaXJtd2FyZSBmcm9t
IGhvc3Qgd2l0aCBxb3MgZW5hYmxlZCBhbG9uZyB3aXRoIG5vbiBxb3MgDQo+IHF1ZXVlIHZhbHVl
KFRJRCA9IDE2KS4NCj4gRHVlIHRvIHFvcyBlbmFibGVkLCBmaXJtd2FyZSBpcyBkaXNjYXJkaW5n
IHRoZSBwYWNrZXQuDQo+DQo+IFRoaXMgcGF0Y2ggZml4ZXMgdGhpcyBpc3N1ZSBieSB1cGRhdGlu
ZyB0aGUgcW9zIGJhc2VkIG9uIHN0YXRpb24gV01FIA0KPiBjYXBhYmlsaXR5IGZpZWxkIGlmIFdN
TSBpcyBkaXNhYmxlZCBpbiBBUC4NCj4NCj4gVGhpcyBwYXRjaCBpcyByZXF1aXJlZCBieSAxMC40
IGZhbWlseSBjaGlwc2V0cyBsaWtlIA0KPiBRQ0E0MDE5L1FDQTk4ODgvUUNBOTg4NC9RQ0E5OVgw
Lg0KPiBGaXJtd2FyZSBWZXJzb2luIDogMTAuNC0zLjUuMS0wMDAxOC4NCj4NCj4gRm9yIDEwLjIu
NCBmYW1pbHkgY2hpcHNldHMgUUNBOTg4WC9RQ0E5ODg3IGFuZCBRQ0E2MTc0IHRoaXMgcGF0Y2gg
aGFzIA0KPiBubyBlZmZlY3QuDQo+DQo+IFNpZ25lZC1vZmYtYnk6IEJhbGFqaSBQb3RodW5vb3Jp
IDxicG90aHVub0BxdGkucXVhbGNvbW0uY29tPg0KPiAtLS0NCj4gICBkcml2ZXJzL25ldC93aXJl
bGVzcy9hdGgvYXRoMTBrL21hYy5jIHwgICAgMiArLQ0KPiAgIDEgZmlsZSBjaGFuZ2VkLCAxIGlu
c2VydGlvbigrKSwgMSBkZWxldGlvbigtKQ0KPg0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQv
d2lyZWxlc3MvYXRoL2F0aDEway9tYWMuYyANCj4gYi9kcml2ZXJzL25ldC93aXJlbGVzcy9hdGgv
YXRoMTBrL21hYy5jDQo+IGluZGV4IDBhOTQ3ZWUuLjI2MTZiOTkgMTAwNjQ0DQo+IC0tLSBhL2Ry
aXZlcnMvbmV0L3dpcmVsZXNzL2F0aC9hdGgxMGsvbWFjLmMNCj4gKysrIGIvZHJpdmVycy9uZXQv
d2lyZWxlc3MvYXRoL2F0aDEway9tYWMuYw0KPiBAQCAtMjU2Myw3ICsyNTYzLDcgQEAgc3RhdGlj
IHZvaWQgYXRoMTBrX3BlZXJfYXNzb2NfaF9xb3Moc3RydWN0IGF0aDEwayAqYXIsDQo+ICAgCQl9
DQo+ICAgCQlicmVhazsNCj4gICAJY2FzZSBXTUlfVkRFVl9UWVBFX1NUQToNCj4gLQkJaWYgKHZp
Zi0+YnNzX2NvbmYucW9zKQ0KPiArCQlpZiAoc3RhLT53bWUpDQo+ICAgCQkJYXJnLT5wZWVyX2Zs
YWdzIHw9IGFydmlmLT5hci0+d21pLnBlZXJfZmxhZ3MtPnFvczsNCj4gICAJCWJyZWFrOw0KPiAg
IAljYXNlIFdNSV9WREVWX1RZUEVfSUJTUzoNCg0KDQotLQ0KTWl0IGZyZXVuZGxpY2hlbiBHcsO8
c3NlbiAvIFJlZ2FyZHMNCg0KU2ViYXN0aWFuIEdvdHRzY2hhbGwgLyBDVE8NCg0KTmV3TWVkaWEt
TkVUIEdtYkggLSBERC1XUlQNCkZpcm1lbnNpdHo6ICBTdHViZW53YWxkYWxsZWUgMjFhLCA2NDYy
NSBCZW5zaGVpbQ0KUmVnaXN0ZXJnZXJpY2h0OiBBbXRzZ2VyaWNodCBEYXJtc3RhZHQsIEhSQiAy
NTQ3Mw0KR2VzY2jDpGZ0c2bDvGhyZXI6IFBldGVyIFN0ZWluaMOkdXNlciwgQ2hyaXN0aWFuIFNj
aGVlbGUgaHR0cDovL3d3dy5kZC13cnQuY29tDQplbWFpbDogcy5nb3R0c2NoYWxsQGRkLXdydC5j
b20NClRlbC46ICs0OTYyNTEtNTgyNjUwIC8gRmF4OiArNDk2MjUxLTU4MjY1NjUNCg0K
^ permalink raw reply
* Re: pull-request: iwlwifi 2017-11-19
From: Sedat Dilek @ 2017-11-29 7:51 UTC (permalink / raw)
To: Luca Coelho; +Cc: kvalo, linux-wireless, linuxwifi
In-Reply-To: <1511259055.4011.268.camel@coelho.fi>
On Tue, Nov 21, 2017 at 11:10 AM, Luca Coelho <luca@coelho.fi> wrote:
> On Tue, 2017-11-21 at 10:30 +0100, Sedat Dilek wrote:
>> On Mon, Nov 20, 2017 at 12:02 PM, Luca Coelho <luca@coelho.fi> wrote:
>> [..]
>> > ----------------------------------------------------------------
>> > iwlwifi: first set of fixes for 4.15
>> >
>> > * Support new FW API version of scan cmd (used in FW version 34);
>>
>> While seeing this...
>> I have here a iwlwifi-8265 hardware and have seen a recently uploaded
>> FW-version 34 in iwlwifi-firmware Git.
>> Can you explain the dependence of iwlwifi firmware-version / Linux
>> kernel-release and especially probing?
>> Currently, I am using Linux v4.14 from Debian/experimental.
>
> Mostly for backwards-compatibility, the driver is able to work with a
> range of firmware versions. It only uses one of them at a time (i.e.
> the highest supported version it finds).
>
> The driver in v4.14 support version 34 and below. So it starts looking
> for that one and, if not found, falls back to the next lower version
> (i.e. 33) and so on, until it finds one.
>
Isn't Linux v4.14.3 (here: -rc1) minimum to completely support new
features in v34 firmware?
"iwlwifi: mvm: support version 7 of the SCAN_REQ_UMAC FW command"
commit dac4df1c5f2c34903f61b1bc4fc722e31b4199e7 upstream.
- Sedat -
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-4.14.y&id=930929379cc8f92275675fb27e572c4d539f6b8a
^ permalink raw reply
* pull-request: iwlwifi-next 2017-11-29
From: Luca Coelho @ 2017-11-29 8:15 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi, david.e.box, janet.morgan, joe.konno
[-- Attachment #1: Type: text/plain, Size: 4184 bytes --]
Hi Kalle,
This is my first batch of patches intended for v4.16. As I mentioned
in the patchset thread, I removed patch 08/11 because it was broken.
More details about the contents in the tag description.
I have sent this out before and kbuildbot reported success.
Please let me know if there are any issues.
Cheers,
Luca.
The following changes since commit fdd0bd88ceaecf729db103ac8836af5805dd2dc1:
brcmfmac: add CLM download support (2017-11-11 03:04:09 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2017-11-29
for you to fetch changes up to 2f7a3863191afc2c132854b7ffb1b867b4b9e8be:
iwlwifi: rename the temporary name of A000 to the official 22000 (2017-11-28 16:39:57 +0200)
----------------------------------------------------------------
First batch of iwlwifi updates for v4.16
* Rename the temporary name A000 to 22000;
* Change in the way we print the firmware version;
* Remove some unused code;
* Other small improvements;
----------------------------------------------------------------
Emmanuel Grumbach (4):
iwlwifi: mvm: rs: don't override the rate history in the search cycle
iwlwifi: mvm: revert support new Coex firmware API
iwlwifi: print the version number of the firmware in hex
iwlwifi: fix the ALIVE notification layout
Johannes Berg (2):
iwlwifi: mvm: remove TCP wakeup support
iwlwifi: mvm: remove superfluous flush_work()
Liad Kaufman (2):
iwlwifi: mvm: support MGMT frames in compressed BA
iwlwifi: dbg: allow wrt collection before ALIVE
Luca Coelho (1):
iwlwifi: rename the temporary name of A000 to the official 22000
Sara Sharon (1):
iwlwifi: mvm: check for short GI only for OFDM
drivers/net/wireless/intel/iwlwifi/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 216 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 216 ------------------------------------------------------------------------------------------
drivers/net/wireless/intel/iwlwifi/fw/api/alive.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/api/coex.h | 30 -------------
drivers/net/wireless/intel/iwlwifi/fw/api/commands.h | 2 +-
drivers/net/wireless/intel/iwlwifi/fw/api/tx.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 15 ++++++-
drivers/net/wireless/intel/iwlwifi/fw/file.h | 3 --
drivers/net/wireless/intel/iwlwifi/fw/smem.c | 8 ++--
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 20 ++++-----
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 11 +++--
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 12 ++---
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/coex.c | 33 +++-----------
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 232 +------------------------------------------------------------------------------------------------
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 12 ++---
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 +--
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 30 +++----------
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 8 +---
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 10 ++---
drivers/net/wireless/intel/iwlwifi/mvm/time-event.c | 6 ---
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 12 +++--
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 36 +++++++--------
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 4 +-
28 files changed, 323 insertions(+), 622 deletions(-)
create mode 100644 drivers/net/wireless/intel/iwlwifi/cfg/22000.c
delete mode 100644 drivers/net/wireless/intel/iwlwifi/cfg/a000.c
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: pull-request: iwlwifi 2017-11-19
From: Luca Coelho @ 2017-11-29 8:20 UTC (permalink / raw)
To: sedat.dilek; +Cc: kvalo, linux-wireless, linuxwifi
In-Reply-To: <CA+icZUVPzwX6hyPZaUJWwn7zOGMaRAkQ7SA6haw6p0F-YX7kBw@mail.gmail.com>
On Wed, 2017-11-29 at 08:51 +0100, Sedat Dilek wrote:
> On Tue, Nov 21, 2017 at 11:10 AM, Luca Coelho <luca@coelho.fi> wrote:
> > On Tue, 2017-11-21 at 10:30 +0100, Sedat Dilek wrote:
> > > On Mon, Nov 20, 2017 at 12:02 PM, Luca Coelho <luca@coelho.fi>
> > > wrote:
> > > [..]
> > > > -------------------------------------------------------------
> > > > ---
> > > > iwlwifi: first set of fixes for 4.15
> > > >
> > > > * Support new FW API version of scan cmd (used in FW version
> > > > 34);
> > >
> > > While seeing this...
> > > I have here a iwlwifi-8265 hardware and have seen a recently
> > > uploaded
> > > FW-version 34 in iwlwifi-firmware Git.
> > > Can you explain the dependence of iwlwifi firmware-version /
> > > Linux
> > > kernel-release and especially probing?
> > > Currently, I am using Linux v4.14 from Debian/experimental.
> >
> > Mostly for backwards-compatibility, the driver is able to work with
> > a
> > range of firmware versions. It only uses one of them at a time
> > (i.e.
> > the highest supported version it finds).
> >
> > The driver in v4.14 support version 34 and below. So it starts
> > looking
> > for that one and, if not found, falls back to the next lower
> > version
> > (i.e. 33) and so on, until it finds one.
> >
>
> Isn't Linux v4.14.3 (here: -rc1) minimum to completely support new
> features in v34 firmware?
Yes, it is. But this was a bug and we can't go back and fix v4.14.0-2,
right? So it's the best we can do and whoever is using v4.14, should
update to v4.14.3 when it comes out to be able to use version 34 of the
firmware.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] ath10k: handling qos at STA side based on AP WMM enable/disable
From: Sebastian Gottschall @ 2017-11-29 8:33 UTC (permalink / raw)
To: Balaji Pothunoori, ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <e93273148ad44a54bfb39bc7018bfcc0@aptaiexm02b.ap.qualcomm.com>
Am 29.11.2017 um 07:58 schrieb Balaji Pothunoori:
> Hi Sebastian,
>
> If I am not wrong you are seeing the issue with WRT3200ACM (Marvell 88W8964) as client + QCA9984 (FW : 10.4-3.5.3-00038) as AP with below change you are seeing the crash while running traffic between the WRT3200ACM + QCA9984 ?
> Do you used any other client in place of WRT3200ACM ?
there is not much traffic required. as it seems the firmware crashes
immediatly after association. the issue is also not present in
10.4-3.4-0082ww
> Can you share the more details on firmware crash ?
so a firmware crashdump from log? i'll try to get it within the next
hours. just need to resetup the test scenario
Sebastian
>
> Regards,
> Balaji.
>
> -----Original Message-----
> From: Sebastian Gottschall [mailto:s.gottschall@dd-wrt.com]
> Sent: Wednesday, November 29, 2017 8:28 AM
> To: Balaji Pothunoori <bpothuno@qti.qualcomm.com>; ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: Re: [PATCH] ath10k: handling qos at STA side based on AP WMM enable/disable
>
> did you notice that Marvell 88W8964 based clients will crash 10.4-3.5.3 firmwares? (tested with 9984 and 10.4-3.5.3-00038) client device was a linksys wrt3200acm running dd-wrt for testing
>
> Am 28.11.2017 um 11:07 schrieb bpothuno@qti.qualcomm.com:
>> From: Balaji Pothunoori <bpothuno@qti.qualcomm.com>
>>
>> Data packets are not sent by STA in case of STA joined to non QOS AP
>> (WMM disabled AP). This is happening because of STA is sending data
>> packets to firmware from host with qos enabled along with non qos
>> queue value(TID = 16).
>> Due to qos enabled, firmware is discarding the packet.
>>
>> This patch fixes this issue by updating the qos based on station WME
>> capability field if WMM is disabled in AP.
>>
>> This patch is required by 10.4 family chipsets like
>> QCA4019/QCA9888/QCA9884/QCA99X0.
>> Firmware Versoin : 10.4-3.5.1-00018.
>>
>> For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch has
>> no effect.
>>
>> Signed-off-by: Balaji Pothunoori <bpothuno@qti.qualcomm.com>
>> ---
>> drivers/net/wireless/ath/ath10k/mac.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
>> b/drivers/net/wireless/ath/ath10k/mac.c
>> index 0a947ee..2616b99 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
>> }
>> break;
>> case WMI_VDEV_TYPE_STA:
>> - if (vif->bss_conf.qos)
>> + if (sta->wme)
>> arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
>> break;
>> case WMI_VDEV_TYPE_IBSS:
>
> --
> 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.gottschall@dd-wrt.com
> Tel.: +496251-582650 / Fax: +496251-5826565
>
--
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.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox