* [PATCH AUTOSEL 3.18 4/6] mac80211: Fix kernel panic due to use of txq after free
From: Sasha Levin @ 2019-05-16 11:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Bhagavathi Perumal S, Toke Høiland-Jørgensen,
Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190516114159.9382-1-sashal@kernel.org>
From: Bhagavathi Perumal S <bperumal@codeaurora.org>
[ Upstream commit f1267cf3c01b12e0f843fb6a7450a7f0b2efab8a ]
The txq of vif is added to active_txqs list for ATF TXQ scheduling
in the function ieee80211_queue_skb(), but it was not properly removed
before freeing the txq object. It was causing use after free of the txq
objects from the active_txqs list, result was kernel panic
due to invalid memory access.
Fix kernel invalid memory access by properly removing txq object
from active_txqs list before free the object.
Signed-off-by: Bhagavathi Perumal S <bperumal@codeaurora.org>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/iface.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index f4ce34670fa83..e052c11d8900a 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1764,6 +1764,9 @@ void ieee80211_if_remove(struct ieee80211_sub_if_data *sdata)
list_del_rcu(&sdata->list);
mutex_unlock(&sdata->local->iflist_mtx);
+ if (sdata->vif.txq)
+ ieee80211_txq_purge(sdata->local, to_txq_info(sdata->vif.txq));
+
synchronize_rcu();
if (sdata->dev) {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 12/16] iwlwifi: mvm: check for length correctness in iwl_mvm_create_skb()
From: Sasha Levin @ 2019-05-16 11:41 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Luca Coelho, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190516114107.8963-1-sashal@kernel.org>
From: Luca Coelho <luciano.coelho@intel.com>
[ Upstream commit de1887c064b9996ac03120d90d0a909a3f678f98 ]
We don't check for the validity of the lengths in the packet received
from the firmware. If the MPDU length received in the rx descriptor
is too short to contain the header length and the crypt length
together, we may end up trying to copy a negative number of bytes
(headlen - hdrlen < 0) which will underflow and cause us to try to
copy a huge amount of data. This causes oopses such as this one:
BUG: unable to handle kernel paging request at ffff896be2970000
PGD 5e201067 P4D 5e201067 PUD 5e205067 PMD 16110d063 PTE 8000000162970161
Oops: 0003 [#1] PREEMPT SMP NOPTI
CPU: 2 PID: 1824 Comm: irq/134-iwlwifi Not tainted 4.19.33-04308-geea41cf4930f #1
Hardware name: [...]
RIP: 0010:memcpy_erms+0x6/0x10
Code: 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3
0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe
RSP: 0018:ffffa4630196fc60 EFLAGS: 00010287
RAX: ffff896be2924618 RBX: ffff896bc8ecc600 RCX: 00000000fffb4610
RDX: 00000000fffffff8 RSI: ffff896a835e2a38 RDI: ffff896be2970000
RBP: ffffa4630196fd30 R08: ffff896bc8ecc600 R09: ffff896a83597000
R10: ffff896bd6998400 R11: 000000000200407f R12: ffff896a83597050
R13: 00000000fffffff8 R14: 0000000000000010 R15: ffff896a83597038
FS: 0000000000000000(0000) GS:ffff896be8280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff896be2970000 CR3: 000000005dc12002 CR4: 00000000003606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
iwl_mvm_rx_mpdu_mq+0xb51/0x121b [iwlmvm]
iwl_pcie_rx_handle+0x58c/0xa89 [iwlwifi]
iwl_pcie_irq_rx_msix_handler+0xd9/0x12a [iwlwifi]
irq_thread_fn+0x24/0x49
irq_thread+0xb0/0x122
kthread+0x138/0x140
ret_from_fork+0x1f/0x40
Fix that by checking the lengths for correctness and trigger a warning
to show that we have received wrong data.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 28 ++++++++++++++++---
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index 8ba8c70571fb7..7fb8bbaf21420 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -141,9 +141,9 @@ static inline int iwl_mvm_check_pn(struct iwl_mvm *mvm, struct sk_buff *skb,
}
/* iwl_mvm_create_skb Adds the rxb to a new skb */
-static void iwl_mvm_create_skb(struct sk_buff *skb, struct ieee80211_hdr *hdr,
- u16 len, u8 crypt_len,
- struct iwl_rx_cmd_buffer *rxb)
+static int iwl_mvm_create_skb(struct iwl_mvm *mvm, struct sk_buff *skb,
+ struct ieee80211_hdr *hdr, u16 len, u8 crypt_len,
+ struct iwl_rx_cmd_buffer *rxb)
{
struct iwl_rx_packet *pkt = rxb_addr(rxb);
struct iwl_rx_mpdu_desc *desc = (void *)pkt->data;
@@ -184,6 +184,20 @@ static void iwl_mvm_create_skb(struct sk_buff *skb, struct ieee80211_hdr *hdr,
* present before copying packet data.
*/
hdrlen += crypt_len;
+
+ if (WARN_ONCE(headlen < hdrlen,
+ "invalid packet lengths (hdrlen=%d, len=%d, crypt_len=%d)\n",
+ hdrlen, len, crypt_len)) {
+ /*
+ * We warn and trace because we want to be able to see
+ * it in trace-cmd as well.
+ */
+ IWL_DEBUG_RX(mvm,
+ "invalid packet lengths (hdrlen=%d, len=%d, crypt_len=%d)\n",
+ hdrlen, len, crypt_len);
+ return -EINVAL;
+ }
+
skb_put_data(skb, hdr, hdrlen);
skb_put_data(skb, (u8 *)hdr + hdrlen + pad_len, headlen - hdrlen);
@@ -196,6 +210,8 @@ static void iwl_mvm_create_skb(struct sk_buff *skb, struct ieee80211_hdr *hdr,
skb_add_rx_frag(skb, 0, rxb_steal_page(rxb), offset,
fraglen, rxb->truesize);
}
+
+ return 0;
}
/* iwl_mvm_pass_packet_to_mac80211 - passes the packet for mac80211 */
@@ -1033,7 +1049,11 @@ void iwl_mvm_rx_mpdu_mq(struct iwl_mvm *mvm, struct napi_struct *napi,
rx_status->boottime_ns = ktime_get_boot_ns();
}
- iwl_mvm_create_skb(skb, hdr, len, crypt_len, rxb);
+ if (iwl_mvm_create_skb(mvm, skb, hdr, len, crypt_len, rxb)) {
+ kfree_skb(skb);
+ goto out;
+ }
+
if (!iwl_mvm_reorder(mvm, napi, queue, sta, skb, desc))
iwl_mvm_pass_packet_to_mac80211(mvm, napi, skb, queue, sta);
out:
--
2.20.1
^ permalink raw reply related
* SPDX identifier
From: Arend Van Spriel @ 2019-05-16 11:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Thomas Gleixner
Hi Kalle, Thomas,
I added SPDX tags in brcm80211 driver sources. Although it is a
no-brainer I decided to run checkpatch for the changes and quirky stuff
started to happen. For all files I added:
// SPDX-License-Identifier
but checkpatch started complaining I should use /* ... */ instead of //.
WARNING: Improper SPDX comment style for
'drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h', please
use '/*' instead
#29: FILE: drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h:1:
+// SPDX-License-Identifier: ISC
So I edited all patches and ran again. And again it started complaining.
WARNING: Improper SPDX comment style for
'drivers/net/wireless/broadcom/brcm80211/brcmsmac/aiutils.c', please use
'//' instead
So now I am in a bonkers state. It seems for header files we want /* */
and for c files we want //. For real?
This is on wireless-drivers-next so maybe it is already fixed, but I
think this should be fixed.
Regards,
Arend
^ permalink raw reply
* [PATCH 1/2] mac80211: call rate_control_send_low() internally
From: Johannes Berg @ 2019-05-16 9:52 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
There's no rate control algorithm that *doesn't* want to call
it internally, and calling it internally will let us modify
its behaviour in the future.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
.../driver-api/80211/mac80211-advanced.rst | 3 ---
drivers/net/wireless/intel/iwlegacy/3945-rs.c | 3 ---
drivers/net/wireless/intel/iwlegacy/4965-rs.c | 4 ----
drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 4 ----
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 ----
drivers/net/wireless/realtek/rtlwifi/rc.c | 3 ---
include/net/mac80211.h | 23 -------------------
net/mac80211/rate.c | 13 ++++++-----
net/mac80211/rc80211_minstrel.c | 4 ----
net/mac80211/rc80211_minstrel_ht.c | 3 ---
10 files changed, 7 insertions(+), 57 deletions(-)
diff --git a/Documentation/driver-api/80211/mac80211-advanced.rst b/Documentation/driver-api/80211/mac80211-advanced.rst
index 70a89b2163c2..9f1c5bb7ac35 100644
--- a/Documentation/driver-api/80211/mac80211-advanced.rst
+++ b/Documentation/driver-api/80211/mac80211-advanced.rst
@@ -226,9 +226,6 @@ TBD
.. kernel-doc:: include/net/mac80211.h
:functions: ieee80211_tx_rate_control
-.. kernel-doc:: include/net/mac80211.h
- :functions: rate_control_send_low
-
TBD
This part of the book describes mac80211 internals.
diff --git a/drivers/net/wireless/intel/iwlegacy/3945-rs.c b/drivers/net/wireless/intel/iwlegacy/3945-rs.c
index a697edd46e7f..922f09f7ea3e 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945-rs.c
+++ b/drivers/net/wireless/intel/iwlegacy/3945-rs.c
@@ -646,9 +646,6 @@ il3945_rs_get_rate(void *il_r, struct ieee80211_sta *sta, void *il_sta,
il_sta = NULL;
}
- if (rate_control_send_low(sta, il_sta, txrc))
- return;
-
rate_mask = sta->supp_rates[sband->band];
/* get user max rate if set */
diff --git a/drivers/net/wireless/intel/iwlegacy/4965-rs.c b/drivers/net/wireless/intel/iwlegacy/4965-rs.c
index 54ff83829afb..946f352fd9a4 100644
--- a/drivers/net/wireless/intel/iwlegacy/4965-rs.c
+++ b/drivers/net/wireless/intel/iwlegacy/4965-rs.c
@@ -2224,10 +2224,6 @@ il4965_rs_get_rate(void *il_r, struct ieee80211_sta *sta, void *il_sta,
il_sta = NULL;
}
- /* Send management frames and NO_ACK data using lowest rate. */
- if (rate_control_send_low(sta, il_sta, txrc))
- return;
-
if (!lq_sta)
return;
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/rs.c b/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
index ef4b9de256f7..838e76a5db68 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
@@ -2731,10 +2731,6 @@ static void rs_get_rate(void *priv_r, struct ieee80211_sta *sta, void *priv_sta,
priv_sta = NULL;
}
- /* Send management frames and NO_ACK data using lowest rate. */
- if (rate_control_send_low(sta, priv_sta, txrc))
- return;
-
rate_idx = lq_sta->last_txrate_idx;
if (lq_sta->last_rate_n_flags & RATE_MCS_HT_MSK) {
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index c182821ab22b..9107b1698b0f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -2960,10 +2960,6 @@ static void rs_drv_get_rate(void *mvm_r, struct ieee80211_sta *sta,
mvm_sta = NULL;
}
- /* Send management frames and NO_ACK data using lowest rate. */
- if (rate_control_send_low(sta, mvm_sta, txrc))
- return;
-
if (!mvm_sta)
return;
diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c b/drivers/net/wireless/realtek/rtlwifi/rc.c
index cf8e42a01015..0c7d74902d33 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
@@ -173,9 +173,6 @@ static void rtl_get_rate(void *ppriv, struct ieee80211_sta *sta,
u8 try_per_rate, i, rix;
bool not_data = !ieee80211_is_data(fc);
- if (rate_control_send_low(sta, priv_sta, txrc))
- return;
-
rix = _rtl_rc_get_highest_rix(rtlpriv, sta, skb, not_data);
try_per_rate = 1;
_rtl_rc_rate_set_series(rtlpriv, sta, &rates[0], txrc,
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 72080d9d617e..9dc98d6d1b4d 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -5951,29 +5951,6 @@ static inline int rate_supported(struct ieee80211_sta *sta,
return (sta == NULL || sta->supp_rates[band] & BIT(index));
}
-/**
- * rate_control_send_low - helper for drivers for management/no-ack frames
- *
- * Rate control algorithms that agree to use the lowest rate to
- * send management frames and NO_ACK data with the respective hw
- * retries should use this in the beginning of their mac80211 get_rate
- * callback. If true is returned the rate control can simply return.
- * If false is returned we guarantee that sta and sta and priv_sta is
- * not null.
- *
- * Rate control algorithms wishing to do more intelligent selection of
- * rate for multicast/broadcast frames may choose to not use this.
- *
- * @sta: &struct ieee80211_sta pointer to the target destination. Note
- * that this may be null.
- * @priv_sta: private rate control structure. This may be null.
- * @txrc: rate control information we sholud populate for mac80211.
- */
-bool rate_control_send_low(struct ieee80211_sta *sta,
- void *priv_sta,
- struct ieee80211_tx_rate_control *txrc);
-
-
static inline s8
rate_lowest_index(struct ieee80211_supported_band *sband,
struct ieee80211_sta *sta)
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 76f303fda3ed..09f89d004a70 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -369,9 +369,8 @@ static void __rate_control_send_low(struct ieee80211_hw *hw,
}
-bool rate_control_send_low(struct ieee80211_sta *pubsta,
- void *priv_sta,
- struct ieee80211_tx_rate_control *txrc)
+static bool rate_control_send_low(struct ieee80211_sta *pubsta,
+ struct ieee80211_tx_rate_control *txrc)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(txrc->skb);
struct ieee80211_supported_band *sband = txrc->sband;
@@ -379,7 +378,7 @@ bool rate_control_send_low(struct ieee80211_sta *pubsta,
int mcast_rate;
bool use_basicrate = false;
- if (!pubsta || !priv_sta || rc_no_data_or_no_ack_use_min(txrc)) {
+ if (!pubsta || rc_no_data_or_no_ack_use_min(txrc)) {
__rate_control_send_low(txrc->hw, sband, pubsta, info,
txrc->rate_idx_mask);
@@ -405,7 +404,6 @@ bool rate_control_send_low(struct ieee80211_sta *pubsta,
}
return false;
}
-EXPORT_SYMBOL(rate_control_send_low);
static bool rate_idx_match_legacy_mask(s8 *rate_idx, int n_bitrates, u32 mask)
{
@@ -902,12 +900,15 @@ void rate_control_get_rate(struct ieee80211_sub_if_data *sdata,
if (ieee80211_hw_check(&sdata->local->hw, HAS_RATE_CONTROL))
return;
+ if (rate_control_send_low(ista, txrc))
+ return;
+
if (ista) {
spin_lock_bh(&sta->rate_ctrl_lock);
ref->ops->get_rate(ref->priv, ista, priv_sta, txrc);
spin_unlock_bh(&sta->rate_ctrl_lock);
} else {
- ref->ops->get_rate(ref->priv, NULL, NULL, txrc);
+ rate_control_send_low(NULL, txrc);
}
if (ieee80211_hw_check(&sdata->local->hw, SUPPORTS_RC_TABLE))
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index a34e9c2ca626..ee86c3333999 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -340,10 +340,6 @@ minstrel_get_rate(void *priv, struct ieee80211_sta *sta,
int delta;
int sampling_ratio;
- /* management/no-ack frames do not use rate control */
- if (rate_control_send_low(sta, priv_sta, txrc))
- return;
-
/* check multi-rate-retry capabilities & adjust lookaround_rate */
mrr_capable = mp->has_mrr &&
!txrc->rts &&
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 8b168724c5e7..da18c6fb6c1d 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -1098,9 +1098,6 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
struct minstrel_priv *mp = priv;
int sample_idx;
- if (rate_control_send_low(sta, priv_sta, txrc))
- return;
-
if (!msp->is_ht)
return mac80211_minstrel.get_rate(priv, sta, &msp->legacy, txrc);
--
2.17.2
^ permalink raw reply related
* [PATCH 2/2] mac80211: use STA info in rate_control_send_low()
From: Johannes Berg @ 2019-05-16 9:52 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <20190516095257.11503-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Even if we have a station, we currently call rate_control_send_low()
with the NULL station unless further rate control (driver, minstrel)
has been initialized.
Change this so we can use more information about the station to use
a better rate. For example, when we associate with an AP, we will
now use the lowest rate it advertised as supported (that we can)
rather than the lowest mandatory rate. This aligns our behaviour
with most other 802.11 implementations.
To make this possible, we need to also ensure that we have non-zero
rates at all times, so in case we really have *nothing* pre-fill
the supp_rates bitmap with the very lowest mandatory bitmap (11b
and 11a on 2.4 and 5 GHz respectively).
Additionally, hostapd appears to be giving us an empty supported
rates bitmap (it can and should do better, since the STA must have
supported for at least the basic rates in the BSS), so ignore any
such bitmaps that would actually zero out the supp_rates, and in
that case just keep the pre-filled mandatory rates.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/cfg.c | 2 +-
net/mac80211/mlme.c | 7 ++++++-
net/mac80211/rate.c | 12 ++++++------
net/mac80211/sta_info.c | 31 +++++++++++++++++++++++++++++++
4 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 52e6a091b7e4..58c97e6dadb0 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1466,7 +1466,7 @@ static int sta_apply_parameters(struct ieee80211_local *local,
return ret;
}
- if (params->supported_rates) {
+ if (params->supported_rates && params->supported_rates_len) {
ieee80211_parse_bitrates(&sdata->vif.bss_conf.chandef,
sband, params->supported_rates,
params->supported_rates_len,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index b7a9fe3d5fcb..bc2fdadf69bc 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -4941,7 +4941,12 @@ static int ieee80211_prep_connection(struct ieee80211_sub_if_data *sdata,
basic_rates = BIT(min_rate_index);
}
- new_sta->sta.supp_rates[cbss->channel->band] = rates;
+ if (rates)
+ new_sta->sta.supp_rates[cbss->channel->band] = rates;
+ else
+ sdata_info(sdata,
+ "No rates found, keeping mandatory only\n");
+
sdata->vif.bss_conf.basic_rates = basic_rates;
/* cf. IEEE 802.11 9.2.12 */
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 09f89d004a70..bc3cedc653f0 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -886,11 +886,6 @@ void rate_control_get_rate(struct ieee80211_sub_if_data *sdata,
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(txrc->skb);
int i;
- if (sta && test_sta_flag(sta, WLAN_STA_RATE_CONTROL)) {
- ista = &sta->sta;
- priv_sta = sta->rate_ctrl_priv;
- }
-
for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
info->control.rates[i].idx = -1;
info->control.rates[i].flags = 0;
@@ -900,9 +895,14 @@ void rate_control_get_rate(struct ieee80211_sub_if_data *sdata,
if (ieee80211_hw_check(&sdata->local->hw, HAS_RATE_CONTROL))
return;
- if (rate_control_send_low(ista, txrc))
+ if (rate_control_send_low(sta ? &sta->sta : NULL, txrc))
return;
+ if (sta && test_sta_flag(sta, WLAN_STA_RATE_CONTROL)) {
+ ista = &sta->sta;
+ priv_sta = sta->rate_ctrl_priv;
+ }
+
if (ista) {
spin_lock_bh(&sta->rate_ctrl_lock);
ref->ops->get_rate(ref->priv, ista, priv_sta, txrc);
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index a4932ee3595c..4b4774e07151 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -404,6 +404,37 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
for (i = 0; i < IEEE80211_NUM_TIDS; i++)
sta->last_seq_ctrl[i] = cpu_to_le16(USHRT_MAX);
+ for (i = 0; i < NUM_NL80211_BANDS; i++) {
+ u32 mandatory = 0;
+ int r;
+
+ if (!hw->wiphy->bands[i])
+ continue;
+
+ switch (i) {
+ case NL80211_BAND_2GHZ:
+ mandatory = IEEE80211_RATE_MANDATORY_B;
+ break;
+ case NL80211_BAND_5GHZ:
+ mandatory = IEEE80211_RATE_MANDATORY_G;
+ break;
+ case NL80211_BAND_60GHZ:
+ WARN_ON(1);
+ mandatory = 0;
+ break;
+ }
+
+ for (r = 0; r < hw->wiphy->bands[i]->n_bitrates; r++) {
+ struct ieee80211_rate *rate;
+
+ rate = &hw->wiphy->bands[i]->bitrates[r];
+
+ if (!(rate->flags & mandatory))
+ continue;
+ sta->sta.supp_rates[i] |= BIT(r);
+ }
+ }
+
sta->sta.smps_mode = IEEE80211_SMPS_OFF;
if (sdata->vif.type == NL80211_IFTYPE_AP ||
sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
--
2.17.2
^ permalink raw reply related
* [RFC PATCH v2] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-05-16 7:37 UTC (permalink / raw)
To: jes.sorensen, kvalo, davem
Cc: linux-wireless, netdev, linux-kernel, linux, Chris Chiu
We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets ~1Mbps.
Nevertheless, the signal strength is reported as around -40dBm,
which is quite good. From the wireshark capture, the tx rate for each
data and qos data packet is only 1Mbps. Compare to the driver from
https://github.com/lwfinger/rtl8723bu, the same iperf test gets ~12
Mbps or more. The signal strength is reported similarly around
-40dBm. That's why we want to improve.
After reading the source code of the rtl8xxxu driver and Larry's, the
major difference is that Larry's driver has a watchdog which will keep
monitoring the signal quality and updating the rate mask just like the
rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
And this kind of watchdog also exists in rtlwifi driver of some specific
chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
the same member function named dm_watchdog and will invoke the
corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
mask.
With this commit, the tx rate of each data and qos data packet will
be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
to 23th bit means MCS4 to MCS7. It means that the firmware still picks
the lowest rate from the rate mask and explains why the tx rate of
data and qos data is always lowest 1Mbps because the default rate mask
passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
and MCS rate. However, with Larry's driver, the tx rate observed from
wireshark under the same condition is almost 65Mbps or 72Mbps.
I believe the firmware of RTL8723BU may need fix. And I think we
can still bring in the dm_watchdog as rtlwifi to improve from the
driver side. Please leave precious comments for my commits and
suggest what I can do better. Or suggest if there's any better idea
to fix this. Thanks.
Signed-off-by: Chris Chiu <chiu@endlessm.com>
---
Notes:
v2:
- Fix errors and warnings complained by checkpatch.pl
- Replace data structure rate_adaptive by 2 member variables
- Make rtl8xxxu_wireless_mode non-static
- Runs refresh_rate_mask() only in station mode
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 49 ++++++
.../realtek/rtl8xxxu/rtl8xxxu_8723b.c | 145 ++++++++++++++++++
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 78 +++++++++-
3 files changed, 271 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 8828baf26e7b..74bc5c8a1471 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1195,6 +1195,49 @@ struct rtl8723bu_c2h {
struct rtl8xxxu_fileops;
+/*mlme related.*/
+enum wireless_mode {
+ WIRELESS_MODE_UNKNOWN = 0,
+ /* Sub-Element */
+ WIRELESS_MODE_B = BIT(0),
+ WIRELESS_MODE_G = BIT(1),
+ WIRELESS_MODE_A = BIT(2),
+ WIRELESS_MODE_N_24G = BIT(3),
+ WIRELESS_MODE_N_5G = BIT(4),
+ WIRELESS_AUTO = BIT(5),
+ WIRELESS_MODE_AC = BIT(6),
+ WIRELESS_MODE_MAX = 0x7F,
+};
+
+/* from rtlwifi/wifi.h */
+enum ratr_table_mode_new {
+ RATEID_IDX_BGN_40M_2SS = 0,
+ RATEID_IDX_BGN_40M_1SS = 1,
+ RATEID_IDX_BGN_20M_2SS_BN = 2,
+ RATEID_IDX_BGN_20M_1SS_BN = 3,
+ RATEID_IDX_GN_N2SS = 4,
+ RATEID_IDX_GN_N1SS = 5,
+ RATEID_IDX_BG = 6,
+ RATEID_IDX_G = 7,
+ RATEID_IDX_B = 8,
+ RATEID_IDX_VHT_2SS = 9,
+ RATEID_IDX_VHT_1SS = 10,
+ RATEID_IDX_MIX1 = 11,
+ RATEID_IDX_MIX2 = 12,
+ RATEID_IDX_VHT_3SS = 13,
+ RATEID_IDX_BGN_3SS = 14,
+};
+
+#define RTL8XXXU_RATR_STA_INIT 0
+#define RTL8XXXU_RATR_STA_HIGH 1
+#define RTL8XXXU_RATR_STA_MID 2
+#define RTL8XXXU_RATR_STA_LOW 3
+
+struct rtl8xxxu_watchdog {
+ struct ieee80211_vif *vif;
+ struct delayed_work ra_wq;
+};
+
struct rtl8xxxu_priv {
struct ieee80211_hw *hw;
struct usb_device *udev;
@@ -1299,6 +1342,9 @@ struct rtl8xxxu_priv {
u8 pi_enabled:1;
u8 no_pape:1;
u8 int_buf[USB_INTR_CONTENT_LENGTH];
+ u8 ratr_index;
+ u8 rssi_level;
+ struct rtl8xxxu_watchdog watchdog;
};
struct rtl8xxxu_rx_urb {
@@ -1335,6 +1381,8 @@ struct rtl8xxxu_fileops {
bool ht40);
void (*update_rate_mask) (struct rtl8xxxu_priv *priv,
u32 ramask, int sgi);
+ void (*refresh_rate_mask) (struct rtl8xxxu_priv *priv, int signal,
+ struct ieee80211_sta *sta);
void (*report_connect) (struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void (*fill_txdesc) (struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
@@ -1445,6 +1493,7 @@ void rtl8xxxu_fill_txdesc_v2(struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
struct rtl8xxxu_txdesc32 *tx_desc32, bool sgi,
bool short_preamble, bool ampdu_enable,
u32 rts_rate);
+u16 rtl8xxxu_wireless_mode(struct ieee80211_hw *hw, struct ieee80211_sta *sta);
extern struct rtl8xxxu_fileops rtl8192cu_fops;
extern struct rtl8xxxu_fileops rtl8192eu_fops;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 26b674aca125..7a510bc22a60 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1645,6 +1645,150 @@ static void rtl8723bu_init_statistics(struct rtl8xxxu_priv *priv)
rtl8xxxu_write32(priv, REG_OFDM0_FA_RSTC, val32);
}
+static u8 rtl8723b_signal_to_rssi(int signal)
+{
+ if (signal < -95)
+ signal = -95;
+ return (u8)(signal + 95);
+}
+
+static void rtl8723b_refresh_rate_mask(struct rtl8xxxu_priv *priv,
+ int signal, struct ieee80211_sta *sta)
+{
+ struct ieee80211_hw *hw = priv->hw;
+ u16 wireless_mode;
+ u8 rssi_level, ratr_index;
+ u8 txbw_40mhz;
+ u8 rssi, rssi_thresh_high, rssi_thresh_low;
+
+ rssi_level = priv->rssi_level;
+ rssi = rtl8723b_signal_to_rssi(signal);
+ ratr_index = priv->ratr_index;
+ txbw_40mhz = (hw->conf.chandef.width == NL80211_CHAN_WIDTH_40) ? 1 : 0;
+
+ switch (rssi_level) {
+ case RTL8XXXU_RATR_STA_HIGH:
+ rssi_thresh_high = 50;
+ rssi_thresh_low = 20;
+ break;
+ case RTL8XXXU_RATR_STA_MID:
+ rssi_thresh_high = 55;
+ rssi_thresh_low = 20;
+ break;
+ case RTL8XXXU_RATR_STA_LOW:
+ rssi_thresh_high = 60;
+ rssi_thresh_low = 25;
+ break;
+ default:
+ rssi_thresh_high = 50;
+ rssi_thresh_low = 20;
+ break;
+ }
+
+ if (rssi > rssi_thresh_high)
+ rssi_level = RTL8XXXU_RATR_STA_HIGH;
+ else if (rssi > rssi_thresh_low)
+ rssi_level = RTL8XXXU_RATR_STA_MID;
+ else
+ rssi_level = RTL8XXXU_RATR_STA_LOW;
+
+ if (rssi_level != priv->rssi_level) {
+ int sgi = 0;
+ u32 rate_bitmap = 0;
+
+ rcu_read_lock();
+ rate_bitmap = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[1] << 20);
+ if (sta->ht_cap.cap &
+ (IEEE80211_HT_CAP_SGI_40 | IEEE80211_HT_CAP_SGI_20))
+ sgi = 1;
+ rcu_read_unlock();
+
+ wireless_mode = rtl8xxxu_wireless_mode(hw, sta);
+ switch (wireless_mode) {
+ case WIRELESS_MODE_B:
+ ratr_index = RATEID_IDX_B;
+ if (rate_bitmap & 0x0000000c)
+ rate_bitmap &= 0x0000000d;
+ else
+ rate_bitmap &= 0x0000000f;
+ break;
+ case WIRELESS_MODE_A:
+ case WIRELESS_MODE_G:
+ ratr_index = RATEID_IDX_G;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else
+ rate_bitmap &= 0x00000ff0;
+ break;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G):
+ ratr_index = RATEID_IDX_BG;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else if (rssi_level == RTL8XXXU_RATR_STA_MID)
+ rate_bitmap &= 0x00000ff0;
+ else
+ rate_bitmap &= 0x00000ff5;
+ break;
+ case WIRELESS_MODE_N_24G:
+ case WIRELESS_MODE_N_5G:
+ case (WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_A | WIRELESS_MODE_N_5G):
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_index = RATEID_IDX_GN_N2SS;
+ else
+ ratr_index = RATEID_IDX_GN_N1SS;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_B | WIRELESS_MODE_N_24G):
+ if (txbw_40mhz) {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_index = RATEID_IDX_BGN_40M_2SS;
+ else
+ ratr_index = RATEID_IDX_BGN_40M_1SS;
+ } else {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_index = RATEID_IDX_BGN_20M_2SS_BN;
+ else
+ ratr_index = RATEID_IDX_BGN_20M_1SS_BN;
+ }
+
+ if (priv->tx_paths == 2 && priv->rx_paths == 2) {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x0f8f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x0f8ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x0f8ff015;
+ else
+ rate_bitmap &= 0x0f8ff005;
+ }
+ } else {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x000f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x000ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x000ff015;
+ else
+ rate_bitmap &= 0x000ff005;
+ }
+ }
+ break;
+ default:
+ ratr_index = RATEID_IDX_BGN_40M_2SS;
+ rate_bitmap &= 0x0fffffff;
+ break;
+ }
+
+ priv->ratr_index = ratr_index;
+ priv->rssi_level = rssi_level;
+ priv->fops->update_rate_mask(priv, rate_bitmap, sgi);
+ }
+}
+
struct rtl8xxxu_fileops rtl8723bu_fops = {
.parse_efuse = rtl8723bu_parse_efuse,
.load_firmware = rtl8723bu_load_firmware,
@@ -1665,6 +1809,7 @@ struct rtl8xxxu_fileops rtl8723bu_fops = {
.usb_quirks = rtl8xxxu_gen2_usb_quirks,
.set_tx_power = rtl8723b_set_tx_power,
.update_rate_mask = rtl8xxxu_gen2_update_rate_mask,
+ .refresh_rate_mask = rtl8723b_refresh_rate_mask,
.report_connect = rtl8xxxu_gen2_report_connect,
.fill_txdesc = rtl8xxxu_fill_txdesc_v2,
.writeN_block_size = 1024,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 039e5ca9d2e4..39aa6e0644b9 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4345,7 +4345,7 @@ void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
h2c.b_macid_cfg.ramask3 = (ramask >> 24) & 0xff;
h2c.ramask.arg = 0x80;
- h2c.b_macid_cfg.data1 = 0;
+ h2c.b_macid_cfg.data1 = priv->ratr_index;
if (sgi)
h2c.b_macid_cfg.data1 |= BIT(7);
@@ -4485,6 +4485,40 @@ static void rtl8xxxu_set_basic_rates(struct rtl8xxxu_priv *priv, u32 rate_cfg)
rtl8xxxu_write8(priv, REG_INIRTS_RATE_SEL, rate_idx);
}
+u16
+rtl8xxxu_wireless_mode(struct ieee80211_hw *hw, struct ieee80211_sta *sta)
+{
+ u16 network_type = WIRELESS_MODE_UNKNOWN;
+ u32 rate_mask;
+
+ rate_mask = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[0] << 20);
+
+ if (hw->conf.chandef.chan->band == NL80211_BAND_5GHZ) {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_5G;
+
+ network_type |= WIRELESS_MODE_A;
+ } else {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_24G;
+
+ if (sta->supp_rates[0] <= 0xf)
+ network_type |= WIRELESS_MODE_B;
+ else if (sta->supp_rates[0] & 0xf)
+ network_type |= (WIRELESS_MODE_B | WIRELESS_MODE_G);
+ else
+ network_type |= WIRELESS_MODE_G;
+ }
+
+ return network_type;
+}
+
static void
rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_bss_conf *bss_conf, u32 changed)
@@ -4527,6 +4561,10 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
sgi = 1;
rcu_read_unlock();
+ priv->watchdog.vif = vif;
+ priv->ratr_index = RATEID_IDX_BGN_40M_2SS;
+ priv->rssi_level = RTL8XXXU_RATR_STA_INIT;
+
priv->fops->update_rate_mask(priv, ramask, sgi);
rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
@@ -5779,6 +5817,39 @@ rtl8xxxu_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
return 0;
}
+static void rtl8xxxu_watchdog_callback(struct work_struct *work)
+{
+ struct ieee80211_vif *vif;
+ struct rtl8xxxu_watchdog *wdog;
+ struct rtl8xxxu_priv *priv;
+
+ wdog = container_of(work, struct rtl8xxxu_watchdog, ra_wq.work);
+ priv = container_of(wdog, struct rtl8xxxu_priv, watchdog);
+ vif = wdog->vif;
+
+ if (vif && vif->type == NL80211_IFTYPE_STATION) {
+ int signal;
+ struct ieee80211_sta *sta;
+
+ rcu_read_lock();
+ sta = ieee80211_find_sta(vif, vif->bss_conf.bssid);
+ if (!sta) {
+ struct device *dev = &priv->udev->dev;
+
+ dev_info(dev, "%s: no sta found\n", __func__);
+ rcu_read_unlock();
+ return;
+ }
+ rcu_read_unlock();
+
+ signal = ieee80211_ave_rssi(vif);
+ if (priv->fops->refresh_rate_mask)
+ priv->fops->refresh_rate_mask(priv, signal, sta);
+ }
+
+ schedule_delayed_work(&priv->watchdog.ra_wq, 2 * HZ);
+}
+
static int rtl8xxxu_start(struct ieee80211_hw *hw)
{
struct rtl8xxxu_priv *priv = hw->priv;
@@ -5835,6 +5906,8 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
ret = rtl8xxxu_submit_rx_urb(priv, rx_urb);
}
+
+ schedule_delayed_work(&priv->watchdog.ra_wq, 2 * HZ);
exit:
/*
* Accept all data and mgmt frames
@@ -6058,6 +6131,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
INIT_LIST_HEAD(&priv->rx_urb_pending_list);
spin_lock_init(&priv->rx_urb_lock);
INIT_WORK(&priv->rx_urb_wq, rtl8xxxu_rx_urb_work);
+ INIT_DELAYED_WORK(&priv->watchdog.ra_wq, rtl8xxxu_watchdog_callback);
usb_set_intfdata(interface, hw);
@@ -6183,6 +6257,8 @@ static void rtl8xxxu_disconnect(struct usb_interface *interface)
mutex_destroy(&priv->usb_buf_mutex);
mutex_destroy(&priv->h2c_mutex);
+ cancel_delayed_work_sync(&priv->watchdog.ra_wq);
+
if (priv->udev->state != USB_STATE_NOTATTACHED) {
dev_info(&priv->udev->dev,
"Device still attached, trying to reset\n");
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] mac80211: mesh: fix RCU warning
From: Thomas Pedersen @ 2019-05-15 22:24 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Peter Oh
In-Reply-To: <1557958906-1432-1-git-send-email-thomas@eero.com>
On Wed, May 15, 2019 at 3:21 PM Thomas Pedersen <thomas@eero.com> wrote:
>
> ifmsh->csa was being dereferenced without the RCU read
> lock held.
>
> fixes the following warning:
>
> [ 74.930435] =============================
> [ 74.932066] WARNING: suspicious RCU usage
> [ 74.933671] 4.20.13 #5 Tainted: G W
> [ 74.935804] -----------------------------
> [ 74.937427] net/mac80211/mesh.c:1218 suspicious rcu_dereference_check() usage!
> [ 74.940473] other info that might help us debug this:
> [ 74.943654] rcu_scheduler_active = 2, debug_locks = 1
> [ 74.946311] 5 locks held by kworker/u8:3/107:
> [ 74.948087] #0: 000000007623c1f0 ((wq_completion)"%s"wiphy_name(local->hw.wiphy)){+.+.}, at: process_one_work+0x1a2/0x610
> [ 74.952464] #1: 00000000077b4215 ((work_completion)(&sdata->csa_finalize_work)){+.+.}, at: process_one_work+0x1a2/0x610
> [ 74.957228] #2: 00000000e02b12da (&wdev->mtx){+.+.}, at: ieee80211_csa_finalize_work+0x2f/0x90
> [ 74.959870] #3: 00000000e6855095 (&local->mtx){+.+.}, at: ieee80211_csa_finalize_work+0x47/0x90
> [ 74.962937] #4: 00000000bb5e3bca (&local->chanctx_mtx){+.+.}, at: ieee80211_csa_finalize_work+0x51/0x90
Sorry the commit message is a little out of date, I actually tested on
5.1.0-rc7-wt as well.
> Signed-off-by: Thomas Pedersen <thomas@eero.com>
> ---
> net/mac80211/mesh.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
> index 766e5e5..70aeb34 100644
> --- a/net/mac80211/mesh.c
> +++ b/net/mac80211/mesh.c
> @@ -1220,10 +1220,12 @@ int ieee80211_mesh_finish_csa(struct ieee80211_sub_if_data *sdata)
> ifmsh->chsw_ttl = 0;
>
> /* Remove the CSA and MCSP elements from the beacon */
> + rcu_read_lock();
> tmp_csa_settings = rcu_dereference(ifmsh->csa);
> RCU_INIT_POINTER(ifmsh->csa, NULL);
> if (tmp_csa_settings)
> kfree_rcu(tmp_csa_settings, rcu_head);
> + rcu_read_unlock();
> ret = ieee80211_mesh_rebuild_beacon(sdata);
> if (ret)
> return -EINVAL;
> --
> 2.7.4
>
--
thomas
^ permalink raw reply
* [PATCH] mac80211: mesh: fix RCU warning
From: Thomas Pedersen @ 2019-05-15 22:21 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, peter.oh, Thomas Pedersen
ifmsh->csa was being dereferenced without the RCU read
lock held.
fixes the following warning:
[ 74.930435] =============================
[ 74.932066] WARNING: suspicious RCU usage
[ 74.933671] 4.20.13 #5 Tainted: G W
[ 74.935804] -----------------------------
[ 74.937427] net/mac80211/mesh.c:1218 suspicious rcu_dereference_check() usage!
[ 74.940473] other info that might help us debug this:
[ 74.943654] rcu_scheduler_active = 2, debug_locks = 1
[ 74.946311] 5 locks held by kworker/u8:3/107:
[ 74.948087] #0: 000000007623c1f0 ((wq_completion)"%s"wiphy_name(local->hw.wiphy)){+.+.}, at: process_one_work+0x1a2/0x610
[ 74.952464] #1: 00000000077b4215 ((work_completion)(&sdata->csa_finalize_work)){+.+.}, at: process_one_work+0x1a2/0x610
[ 74.957228] #2: 00000000e02b12da (&wdev->mtx){+.+.}, at: ieee80211_csa_finalize_work+0x2f/0x90
[ 74.959870] #3: 00000000e6855095 (&local->mtx){+.+.}, at: ieee80211_csa_finalize_work+0x47/0x90
[ 74.962937] #4: 00000000bb5e3bca (&local->chanctx_mtx){+.+.}, at: ieee80211_csa_finalize_work+0x51/0x90
Signed-off-by: Thomas Pedersen <thomas@eero.com>
---
net/mac80211/mesh.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 766e5e5..70aeb34 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1220,10 +1220,12 @@ int ieee80211_mesh_finish_csa(struct ieee80211_sub_if_data *sdata)
ifmsh->chsw_ttl = 0;
/* Remove the CSA and MCSP elements from the beacon */
+ rcu_read_lock();
tmp_csa_settings = rcu_dereference(ifmsh->csa);
RCU_INIT_POINTER(ifmsh->csa, NULL);
if (tmp_csa_settings)
kfree_rcu(tmp_csa_settings, rcu_head);
+ rcu_read_unlock();
ret = ieee80211_mesh_rebuild_beacon(sdata);
if (ret)
return -EINVAL;
--
2.7.4
^ permalink raw reply related
* [PATCH v3] wireless-regdb: Update regulatory rules for South Korea
From: Peter Oh @ 2019-05-15 19:28 UTC (permalink / raw)
To: wireless-regdb@lists.infradead.org
Cc: Peter Oh, linux-wireless@vger.kernel.org
From: Peter Oh <peter.oh@bowerswilkins.com>
Update power limit as documented in:
http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/
%EC%8B%A0%EA%B3%A0%ED%95%98%EC%A7%80%EC%95%84%EB%8B%88%ED
%95%98%EA%B3%A0%EA%B0%9C%EC%84%A4%ED%95%A0%EC%88%98%EC%9E
%88%EB%8A%94%EB%AC%B4%EC%84%A0%EA%B5%AD%EC%9A%A9%EB%AC%B4
%EC%84%A0%EA%B8%B0%EA%B8%B0/(2018-89,20181227)
which revised on December 27, 2018.
Signed-off-by: Peter Oh <peter.oh@bowerswilkins.com>
---
db.txt | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/db.txt b/db.txt
index 4fb1948..6e5019f 100644
--- a/db.txt
+++ b/db.txt
@@ -695,11 +695,12 @@ country KP: DFS-JP
(5735 - 5815 @ 20), (30)
country KR: DFS-JP
- (2402 - 2482 @ 40), (13)
- (5170 - 5250 @ 80), (20), AUTO-BW
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW
- (5490 - 5710 @ 160), (30), DFS
- (5735 - 5835 @ 80), (30)
+ # ref: https://www.rra.go.kr
+ (2400 - 2483.5 @ 40), (23)
+ (5150 - 5250 @ 80), (23), AUTO-BW
+ (5250 - 5350 @ 80), (20), DFS, AUTO-BW
+ (5470 - 5725 @ 160), (20), DFS
+ (5725 - 5835 @ 80), (23)
# 60 GHz band channels 1-4,
# ref: http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EB%AC%B4%EC%84%A0%EC%84%A4%EB%B9%84%EA%B7%9C%EC%B9%99
(57000 - 66000 @ 2160), (43)
--
2.7.4
^ permalink raw reply related
* Re: [wireless-regdb] [PATCH v2] wireless-regdb: Update regulatory rules for South Korea
From: Peter Oh @ 2019-05-15 19:08 UTC (permalink / raw)
To: Seth Forshee, suchan
Cc: wireless-regdb@lists.infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <20190515162142.GC4357@ubuntu-xps13>
On 05/15/2019 09:21 AM, Seth Forshee wrote:
> You dropped Peter and the linux-wireless list from your reply, adding
> them back.
>
> On Thu, May 16, 2019 at 12:10:16AM +0900, suchan wrote:
>> 2019-05-15 10:03PM at Seth Forshee wrote:
>>> Is there any mention of transmit power control in the document? The fact
>>> that some of the old limits are exactly half of they values you've given
>>> makes me wonder if they weren't set lower for TPC, especially for
>>> 5250-5350 MHz where TPC is common.
>>>
>>> Since you're changing these rules, I'd also like to see the frequency
>>> ranges changed to match the documented ranges, i.e.:
>>>
>>> 2400 - 2483.5
>>> 5150 - 5250
>>> 5250 - 5350
>>> 5470 - 5710
>>> 5735 - 5850
>>>
>>> I left the gap in the 5470-5850 MHz range since I can't tell exactly
>>> where the DFS requirement ends. Usually it seems to be 5725 MHz, but
>>> that is not universal. If you can determine where the break is those
>>> ranges could also be expanded.
>>>
>>> Thanks,
>>> Seth
>>>
>>> _______________________________________________
>>> wireless-regdb mailing list
>>> wireless-regdb@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/wireless-regdb
>> from same document, just under the table for wifi range itself 5250∼5350
>> MHz and 5470∼5725 MHz need TPC and DFS
>>
>> TPC rule is if power exceeds 25mW/MHz (this includes antenna gain), it
>> has do be able to reduce it under 12.5mW/Mhz.
>>
>> DFS rule itself (DFS-JP) looks right.
DFS bandwidth is correct although the rules(radar types and etc.) are
different from JP, but no plan yet to add KR rules to DFS (requires
kernel space patches).
> Thanks! Based on that I think this is probably what we need:
>
> (2400 - 2483.5 @ 40), (23)
> (5150 - 5250 @ 80), (23), AUTO-BW
> (5250 - 5350 @ 80), (20), DFS, AUTO-BW
> (5470 - 5725 @ 160), (20), DFS
> (5725 - 5835 @ 80), (23)
>
> Peter, if that looks good to you please send a v3 patch.
It looks good to me, too. I'll do v3.
Thanks,
Peter
^ permalink raw reply
* Re: [wireless-regdb] [PATCH v2] wireless-regdb: Update regulatory rules for South Korea
From: Seth Forshee @ 2019-05-15 16:21 UTC (permalink / raw)
To: suchan; +Cc: wireless-regdb, Peter Oh, linux-wireless
In-Reply-To: <a2fa616d-7829-137c-7f48-6c59974cfa46@mail.com>
You dropped Peter and the linux-wireless list from your reply, adding
them back.
On Thu, May 16, 2019 at 12:10:16AM +0900, suchan wrote:
>
> 2019-05-15 10:03PM at Seth Forshee wrote:
> >
> > Is there any mention of transmit power control in the document? The fact
> > that some of the old limits are exactly half of they values you've given
> > makes me wonder if they weren't set lower for TPC, especially for
> > 5250-5350 MHz where TPC is common.
> >
> > Since you're changing these rules, I'd also like to see the frequency
> > ranges changed to match the documented ranges, i.e.:
> >
> > 2400 - 2483.5
> > 5150 - 5250
> > 5250 - 5350
> > 5470 - 5710
> > 5735 - 5850
> >
> > I left the gap in the 5470-5850 MHz range since I can't tell exactly
> > where the DFS requirement ends. Usually it seems to be 5725 MHz, but
> > that is not universal. If you can determine where the break is those
> > ranges could also be expanded.
> >
> > Thanks,
> > Seth
> >
> > _______________________________________________
> > wireless-regdb mailing list
> > wireless-regdb@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/wireless-regdb
>
> from same document, just under the table for wifi range itself 5250∼5350
> MHz and 5470∼5725 MHz need TPC and DFS
>
> TPC rule is if power exceeds 25mW/MHz (this includes antenna gain), it
> has do be able to reduce it under 12.5mW/Mhz.
>
> DFS rule itself (DFS-JP) looks right.
Thanks! Based on that I think this is probably what we need:
(2400 - 2483.5 @ 40), (23)
(5150 - 5250 @ 80), (23), AUTO-BW
(5250 - 5350 @ 80), (20), DFS, AUTO-BW
(5470 - 5725 @ 160), (20), DFS
(5725 - 5835 @ 80), (23)
Peter, if that looks good to you please send a v3 patch.
Thanks,
Seth
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Stanislaw Gruszka @ 2019-05-15 13:59 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515134828.GA2992@redhat.com>
On Wed, May 15, 2019 at 03:48:29PM +0200, Stanislaw Gruszka wrote:
> > Tx hangs occur in very particular conditions (e.g 200Mbps bidirectional
> > traffic) and moreover they do not always occur so I am not convinced they
> > are always EDCCA related and so I am not confident to remove the watchdog
>
> I'm not opting for watchdog removal, but for full EDCCA removal.
On mt76x02, on other chips/firmwares it can work just fine.
Stanislaw
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Stanislaw Gruszka @ 2019-05-15 13:48 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515120741.GD30757@localhost.localdomain>
On Wed, May 15, 2019 at 02:07:42PM +0200, Lorenzo Bianconi wrote:
> > On Wed, May 15, 2019 at 01:13:49PM +0200, Lorenzo Bianconi wrote:
> > > > On Wed, May 15, 2019 at 12:03:44PM +0200, Lorenzo Bianconi wrote:
> > > > > > On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > > > > > > > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > > > > > > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > > > > > > > > > >
> > > > > > > > > > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > > > > > > > > > edcca processing
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > > > > > > >
> > > > > > > > > > > It's good to explain what edcca does and how the file is used supposed
> > > > > > > > > > > to be used. In other words, have a small introduction for the user.
> > > > > > > > > >
> > > > > > > > > > Hi Kalle,
> > > > > > > > > >
> > > > > > > > > > edcca is used for adjusting energy detect based on CCA thresholds.
> > > > > > > > > > The code was already there so I just reported the acronym.
> > > > > > > > >
> > > > > > > > > What for it is needed ?
> > > > > > > >
> > > > > > > > Care to comment why EDCCA is needed at all ?
> > > > > > > >
> > > > > > > > Taking that debugfs file that enable it is read-only, it looks like
> > > > > > > > feature that nobody needs nor tests.
> > > > > > >
> > > > > > > already fixed in v2
> > > > > > > https://patchwork.kernel.org/patch/10940645/
> > > > > >
> > > > > > I'm aware of this patch and other one for mt76x02. But so far in the
> > > > > > sources EDCCA is disabled for mt76x02 without possibility to enable it
> > > > > > (and this permission file issue was pointed by Kalle during review, not
> > > > > > by someone who want to test EDCCA). So again, what for EDCCA is needed ?
> > > > >
> > > > > As I have already written in a previous email, ED/CCA is used to control tx power
> > > > > according to the CCA MIB counters (e.g do not transmit if the channel busy time
> > > > > is higher than 90% for given amount of time in a row). I guess it is required
> > > > > by ETSI regulatory.
> > > > But what is user case for that, i.e. who need this (it wasn't implemented in
> > > > mt76x2 since you added it on Dec 2018). What will happen if it will be removed?
> > > >
> > > > > Regarding file permission for mt76x02 debugfs edcca node is a typo.
> > > > Typo or not, effectively disable the feature and show nobody is
> > > > testing it.
> > > >
> > > > The reason I'm asking is that seems EDCCA is the main reason to
> > > > implement watchod for mt76x2, it wasn't necessary to have a watchdog
> > > > as seems devices did not hung before EDCCA was added.
> > >
> > > IIRC I added the first watchdog implementation to fix tx hangs that occur
> > > under heavy load even using FCC regulatory (so when EDCCA processing is
> > > disabled)
> >
> > There was changes in various registers programming introduced by EDCCA
> > support, even with EDCCA disabled. It's rally not convenient that
> > watchdog and EDCCA are not related, since you added tx hung watchdog
> > 2 weeks after adding EDCCA.
> >
> > You can look at this report:
> > https://github.com/openwrt/mt76/issues/246
> > Before mt76x2e worked without hungs & watchodg. Now, even with EDCCA
> > disabled watchdog and HW restarts are required to fix hungs on runtime.
>
> Tx hangs occur in very particular conditions (e.g 200Mbps bidirectional
> traffic) and moreover they do not always occur so I am not convinced they
> are always EDCCA related and so I am not confident to remove the watchdog
I'm not opting for watchdog removal, but for full EDCCA removal.
Apparently nobody cares, if it can be enabled or not.
Stanislaw
^ permalink raw reply
* Re: [PATCH] wireless-regdb: Update regulatory rules for Japan (JP) on 5GHz
From: Seth Forshee @ 2019-05-15 13:32 UTC (permalink / raw)
To: Vladimir Koutny; +Cc: wireless-regdb, linux-wireless
In-Reply-To: <82a15f3c-fe0c-a5dc-9846-13b3efb01f0d@streamunlimited.com>
On Wed, May 15, 2019 at 01:50:59PM +0200, Vladimir Koutny wrote:
> According to multiple sources channels 8-16 (5030-5090MHz) were only
> allowed in Japan until Nov-30, 2017 (later extended to Nov-30, 2018).
>
> https://www.tele.soumu.go.jp/j/adm/system/trunk/wimax/5ghz/index.htm
> http://www.dspr.co.jp/wp/wp-content/uploads/2017/10/The-expiration-date-of-some-frequency-of-the-5GHz-band-radio-access-system_eng.pdf
>
> Signed-off-by: Vladimir Koutny <vladimir.koutny@streamunlimited.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] wireless-regdb: update source of information for ES
From: Seth Forshee @ 2019-05-15 13:29 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: WIRELESS ML, REGDB ML
In-Reply-To: <20190504191817.3668-1-xose.vazquez@gmail.com>
On Sat, May 04, 2019 at 09:18:17PM +0200, Xose Vazquez Perez wrote:
> Cc: Seth Forshee <seth.forshee@canonical.com>
> Cc: WIRELESS ML <linux-wireless@vger.kernel.org>
> Cc: REGDB ML <wireless-regdb@lists.infradead.org>
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Applied, thanks!
> ---
> db.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/db.txt b/db.txt
> index 4fb1948..fe909a8 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -432,7 +432,7 @@ country EG: DFS-ETSI
>
> # Source:
> # Cuadro nacional de atribución de frecuencias (CNAF)
> -# http://www.mincotur.gob.es/telecomunicaciones/espectro/paginas/cnaf.aspx
> +# https://avancedigital.gob.es/espectro/Paginas/cnaf.aspx
> country ES: DFS-ETSI
> (2400 - 2483.5 @ 40), (100 mW)
> (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
Applied, thanks!
^ permalink raw reply
* [PATCH] wireless-regdb: Expand 60 GHz band for Japan to 57-66 GHz
From: Seth Forshee @ 2019-05-15 13:26 UTC (permalink / raw)
To: wireless-regdb; +Cc: linux-wireless
The official documents are not feely available, but based on
summaries such as [1] and numerous third-party resources the 60
GHz band in Japan has been 57-66 GHz for some time now. Update
our rules accordingly.
[1] https://webstore.arib.or.jp/en/products/detail.php?product_id=288
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
db.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/db.txt b/db.txt
index 4fb194835116..e11e0f747386 100644
--- a/db.txt
+++ b/db.txt
@@ -664,7 +664,7 @@ country JP: DFS-JP
(5490 - 5710 @ 160), (23), DFS
# 60 GHz band channels 2-4 at 10mW,
# ref: http://www.arib.or.jp/english/html/overview/doc/1-STD-T74v1_1.pdf
- (59000 - 66000 @ 2160), (10 mW)
+ (57000 - 66000 @ 2160), (10 mW)
country KE: DFS-JP
(2402 - 2482 @ 40), (20)
--
2.20.1
^ permalink raw reply related
* Re: [wireless-regdb] wireless-regdb: Please update regulatory rules for Japan (JP) on 60GHz
From: seth.forshee @ 2019-05-15 13:15 UTC (permalink / raw)
To: b.K.il.h.u+tigbuh
Cc: junping.xu@jaguarwave.com, linux-wireless, wireless-regdb
In-Reply-To: <CAPuHQ=EvWzXtxk0fLOT6PyeYkcNOOXmw0ck-yT-JsqhhDmu2gA@mail.gmail.com>
On Fri, Apr 26, 2019 at 12:00:22AM +0200, b.K.il.h.u+tigbuh@gmail.com wrote:
> This seems to be the page for the previous standard:
> https://www.arib.or.jp/english/std_tr/telecommunications/std-t74.html
>
> And the following should be the new standard, but I don't know where
> to obtain it:
> https://www.arib.or.jp/english/std_tr/telecommunications/std-t117.html
>
> The description fields here do note the range of 57-66GHz, though:
> https://www.arib.or.jp/kikaku/kikaku_tushin/desc/std-t117.html
> https://webstore.arib.or.jp/en/products/detail.php?product_id=288
>
> Similar mentions in the news (search for T117):
> https://www.arib.or.jp/image/osirase/news/1044.pdf
> https://www.arib.or.jp/image/iinkai/kikaku-kaigi/rireki/101.pdf
>
> Testing procedure is described here, not sure if it's considered useful:
> file:///home/bkil/chrome.root/Downloads/60ghz2_1_19_4_2_1.pdf
Thanks. Judging by these and numerous other third-party resources I've
found, I think it's safe to say that the range was expanded back to 57
GHz quite some time ago. I'll send a patch to update this range.
Seth
^ permalink raw reply
* Re: [wireless-regdb] [PATCH v2] wireless-regdb: Update regulatory rules for South Korea
From: Seth Forshee @ 2019-05-15 13:03 UTC (permalink / raw)
To: Peter Oh; +Cc: wireless-regdb@lists.infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1556314283-17842-1-git-send-email-peter.oh@bowerswilkins.com>
On Fri, Apr 26, 2019 at 09:31:31PM +0000, Peter Oh wrote:
> From: Peter Oh <peter.oh@bowerswilkins.com>
>
> Update power limit as documented in:
> http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/
> %EC%8B%A0%EA%B3%A0%ED%95%98%EC%A7%80%EC%95%84%EB%8B%88%ED
> %95%98%EA%B3%A0%EA%B0%9C%EC%84%A4%ED%95%A0%EC%88%98%EC%9E
> %88%EB%8A%94%EB%AC%B4%EC%84%A0%EA%B5%AD%EC%9A%A9%EB%AC%B4
> %EC%84%A0%EA%B8%B0%EA%B8%B0/(2018-89,20181227)
> which revised on December 27, 2018.
>
> Signed-off-by: Peter Oh <peter.oh@bowerswilkins.com>
> ---
> db.txt | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/db.txt b/db.txt
> index 4fb1948..8d24305 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -695,11 +695,12 @@ country KP: DFS-JP
> (5735 - 5815 @ 20), (30)
>
> country KR: DFS-JP
> - (2402 - 2482 @ 40), (13)
> - (5170 - 5250 @ 80), (20), AUTO-BW
> - (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> - (5490 - 5710 @ 160), (30), DFS
> - (5735 - 5835 @ 80), (30)
> + # ref: https://www.rra.go.kr
> + (2402 - 2482 @ 40), (23)
> + (5170 - 5250 @ 80), (23), AUTO-BW
> + (5250 - 5330 @ 80), (23), DFS, AUTO-BW
> + (5490 - 5710 @ 160), (23), DFS
> + (5735 - 5835 @ 80), (23)
Is there any mention of transmit power control in the document? The fact
that some of the old limits are exactly half of they values you've given
makes me wonder if they weren't set lower for TPC, especially for
5250-5350 MHz where TPC is common.
Since you're changing these rules, I'd also like to see the frequency
ranges changed to match the documented ranges, i.e.:
2400 - 2483.5
5150 - 5250
5250 - 5350
5470 - 5710
5735 - 5850
I left the gap in the 5470-5850 MHz range since I can't tell exactly
where the DFS requirement ends. Usually it seems to be 5725 MHz, but
that is not universal. If you can determine where the break is those
ranges could also be expanded.
Thanks,
Seth
^ permalink raw reply
* Re: [PATCH] libertas/libertas_tf: fix spelling mistake "Donwloading" -> "Downloading"
From: Mukesh Ojha @ 2019-05-15 12:26 UTC (permalink / raw)
To: Colin King, Kalle Valo, David S . Miller, libertas-dev,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190514211406.6353-1-colin.king@canonical.com>
On 5/15/2019 2:44 AM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is are two spelling mistakes in lbtf_deb_usb2 messages, fix these.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Cheers,
-Mukesh
> ---
> drivers/net/wireless/marvell/libertas/if_usb.c | 2 +-
> drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/wireless/marvell/libertas/if_usb.c
> index 220dcdee8d2b..1d06fa564e28 100644
> --- a/drivers/net/wireless/marvell/libertas/if_usb.c
> +++ b/drivers/net/wireless/marvell/libertas/if_usb.c
> @@ -367,7 +367,7 @@ static int if_usb_send_fw_pkt(struct if_usb_card *cardp)
> cardp->fwseqnum, cardp->totalbytes);
> } else if (fwdata->hdr.dnldcmd == cpu_to_le32(FW_HAS_LAST_BLOCK)) {
> lbs_deb_usb2(&cardp->udev->dev, "Host has finished FW downloading\n");
> - lbs_deb_usb2(&cardp->udev->dev, "Donwloading FW JUMP BLOCK\n");
> + lbs_deb_usb2(&cardp->udev->dev, "Downloading FW JUMP BLOCK\n");
>
> cardp->fwfinalblk = 1;
> }
> diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> index a4b9ede70705..38f77b1a02ca 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> @@ -319,7 +319,7 @@ static int if_usb_send_fw_pkt(struct if_usb_card *cardp)
> } else if (fwdata->hdr.dnldcmd == cpu_to_le32(FW_HAS_LAST_BLOCK)) {
> lbtf_deb_usb2(&cardp->udev->dev,
> "Host has finished FW downloading\n");
> - lbtf_deb_usb2(&cardp->udev->dev, "Donwloading FW JUMP BLOCK\n");
> + lbtf_deb_usb2(&cardp->udev->dev, "Downloading FW JUMP BLOCK\n");
>
> /* Host has finished FW downloading
> * Donwloading FW JUMP BLOCK
^ permalink raw reply
* [PATCH] wireless-regdb: Update regulatory rules for Japan (JP) on 5GHz
From: Vladimir Koutny @ 2019-05-15 11:50 UTC (permalink / raw)
To: seth.forshee; +Cc: wireless-regdb, linux-wireless
According to multiple sources channels 8-16 (5030-5090MHz) were only
allowed in Japan until Nov-30, 2017 (later extended to Nov-30, 2018).
https://www.tele.soumu.go.jp/j/adm/system/trunk/wimax/5ghz/index.htm
http://www.dspr.co.jp/wp/wp-content/uploads/2017/10/The-expiration-date-of-some-frequency-of-the-5GHz-band-radio-access-system_eng.pdf
Signed-off-by: Vladimir Koutny <vladimir.koutny@streamunlimited.com>
---
db.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/db.txt b/db.txt
index 4fb1948..7e10d0d 100644
--- a/db.txt
+++ b/db.txt
@@ -658,7 +658,6 @@ country JP: DFS-JP
(2402 - 2482 @ 40), (20)
(2474 - 2494 @ 20), (20), NO-OFDM
(4910 - 4990 @ 40), (23)
- (5030 - 5090 @ 40), (23)
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (23), DFS
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] NFC: nxp-nci: Fix recommendation for NFC_NXP_NCI_I2C Kconfig
From: Sedat Dilek @ 2019-05-15 12:04 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, Samuel Ortiz, linux-nfc,
linux-wireless, linux-kernel
Cc: Sedat Dilek, Andy Shevchenko, Oleg Zhurakivskyy
This is a simple cleanup to the Kconfig help text as discussed in [1].
[1] https://marc.info/?t=155774435600001&r=1&w=2
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Suggested-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
Signed-off-by: Sedat Dilek <sedat.dilek@credativ.de>
---
drivers/nfc/nxp-nci/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
index 16473cfcb1d8..a38c426452ca 100644
--- a/drivers/nfc/nxp-nci/Kconfig
+++ b/drivers/nfc/nxp-nci/Kconfig
@@ -21,4 +21,4 @@ config NFC_NXP_NCI_I2C
To compile this driver as a module, choose m here. The module will
be called nxp_nci_i2c.
- Say Y if unsure.
+ Say N if unsure.
--
2.20.1
^ permalink raw reply related
* [PATCH 1/2] NFC: nxp-nci: Clarify on supported chips
From: Sedat Dilek @ 2019-05-15 12:02 UTC (permalink / raw)
To: Samuel Ortiz, Charles Gorand, Clément Perrochaud, linux-nfc,
linux-wireless, linux-kernel
Cc: Sedat Dilek, Andy Shevchenko, Oleg Zhurakivskyy
This patch clarifies on the supported NXP NCI chips and families
and lists PN547 and PN548 separately which are known as NPC100
respectively NPC300.
This helps to find informations and identify drivers on vendor's
support websites.
This patch is on top of Andy Shevchenko's patchset:
"[PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID"
For details see the discussion in [1] and [2].
I add the references to the linux-wireless mailing-list and patchwork
URLs as Linux NFC is marked orphan now (see commit "NFC: Orphan the
subsystem").
NOTE: Tested above patchset against Linux v5.1.1 and v5.1.2.
[1] https://marc.info/?t=155774435600001&r=1&w=2
[2] https://patchwork.kernel.org/project/linux-wireless/list/?submitter=33142
[3] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=d0a7e8cb3c9d7d4fa2bcdd557be19f0841e2a3be
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Suggested-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
Signed-off-by: Sedat Dilek <sedat.dilek@credativ.de>
---
drivers/nfc/nxp-nci/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
index a28c4265354d..16473cfcb1d8 100644
--- a/drivers/nfc/nxp-nci/Kconfig
+++ b/drivers/nfc/nxp-nci/Kconfig
@@ -2,8 +2,8 @@ config NFC_NXP_NCI
tristate "NXP-NCI NFC driver"
depends on NFC_NCI
---help---
- Generic core driver for NXP NCI chips such as the NPC100
- or PN7150 families.
+ Generic core driver for NXP NCI chips such as the NPC100 (PN547),
+ NPC300 (PN548) or PN7150 families.
This is a driver based on the NCI NFC kernel layers and
will thus not work with NXP libnfc library.
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 1/2] NFC: nxp-nci: Clarify on supported chips
From: Oleg Zhurakivskyy @ 2019-05-15 12:10 UTC (permalink / raw)
To: Sedat Dilek, Samuel Ortiz, Charles Gorand,
Clément Perrochaud, linux-nfc, linux-wireless, linux-kernel
Cc: Andy Shevchenko
In-Reply-To: <20190515120233.19159-1-sedat.dilek@credativ.de>
On 5/15/19 3:02 PM, Sedat Dilek wrote:
> This patch clarifies on the supported NXP NCI chips and families
> and lists PN547 and PN548 separately which are known as NPC100
> respectively NPC300.
LGTM and thanks!
Regards,
Oleg
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Lorenzo Bianconi @ 2019-05-15 12:07 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515114615.GB15134@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3644 bytes --]
> On Wed, May 15, 2019 at 01:13:49PM +0200, Lorenzo Bianconi wrote:
> > > On Wed, May 15, 2019 at 12:03:44PM +0200, Lorenzo Bianconi wrote:
> > > > > On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > > > > > > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > > > > > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > > > > > > > > >
> > > > > > > > > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > > > > > > > > edcca processing
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > > > > > >
> > > > > > > > > > It's good to explain what edcca does and how the file is used supposed
> > > > > > > > > > to be used. In other words, have a small introduction for the user.
> > > > > > > > >
> > > > > > > > > Hi Kalle,
> > > > > > > > >
> > > > > > > > > edcca is used for adjusting energy detect based on CCA thresholds.
> > > > > > > > > The code was already there so I just reported the acronym.
> > > > > > > >
> > > > > > > > What for it is needed ?
> > > > > > >
> > > > > > > Care to comment why EDCCA is needed at all ?
> > > > > > >
> > > > > > > Taking that debugfs file that enable it is read-only, it looks like
> > > > > > > feature that nobody needs nor tests.
> > > > > >
> > > > > > already fixed in v2
> > > > > > https://patchwork.kernel.org/patch/10940645/
> > > > >
> > > > > I'm aware of this patch and other one for mt76x02. But so far in the
> > > > > sources EDCCA is disabled for mt76x02 without possibility to enable it
> > > > > (and this permission file issue was pointed by Kalle during review, not
> > > > > by someone who want to test EDCCA). So again, what for EDCCA is needed ?
> > > >
> > > > As I have already written in a previous email, ED/CCA is used to control tx power
> > > > according to the CCA MIB counters (e.g do not transmit if the channel busy time
> > > > is higher than 90% for given amount of time in a row). I guess it is required
> > > > by ETSI regulatory.
> > > But what is user case for that, i.e. who need this (it wasn't implemented in
> > > mt76x2 since you added it on Dec 2018). What will happen if it will be removed?
> > >
> > > > Regarding file permission for mt76x02 debugfs edcca node is a typo.
> > > Typo or not, effectively disable the feature and show nobody is
> > > testing it.
> > >
> > > The reason I'm asking is that seems EDCCA is the main reason to
> > > implement watchod for mt76x2, it wasn't necessary to have a watchdog
> > > as seems devices did not hung before EDCCA was added.
> >
> > IIRC I added the first watchdog implementation to fix tx hangs that occur
> > under heavy load even using FCC regulatory (so when EDCCA processing is
> > disabled)
>
> There was changes in various registers programming introduced by EDCCA
> support, even with EDCCA disabled. It's rally not convenient that
> watchdog and EDCCA are not related, since you added tx hung watchdog
> 2 weeks after adding EDCCA.
>
> You can look at this report:
> https://github.com/openwrt/mt76/issues/246
> Before mt76x2e worked without hungs & watchodg. Now, even with EDCCA
> disabled watchdog and HW restarts are required to fix hungs on runtime.
Tx hangs occur in very particular conditions (e.g 200Mbps bidirectional
traffic) and moreover they do not always occur so I am not convinced they
are always EDCCA related and so I am not confident to remove the watchdog
Lorenzo
>
> Stanislaw
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Lorenzo Bianconi @ 2019-05-15 11:13 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515103309.GA15134@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]
> On Wed, May 15, 2019 at 12:03:44PM +0200, Lorenzo Bianconi wrote:
> > > On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > > > > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > > > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > > > > > > >
> > > > > > > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > > > > > > edcca processing
> > > > > > > > >
> > > > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > > > >
> > > > > > > > It's good to explain what edcca does and how the file is used supposed
> > > > > > > > to be used. In other words, have a small introduction for the user.
> > > > > > >
> > > > > > > Hi Kalle,
> > > > > > >
> > > > > > > edcca is used for adjusting energy detect based on CCA thresholds.
> > > > > > > The code was already there so I just reported the acronym.
> > > > > >
> > > > > > What for it is needed ?
> > > > >
> > > > > Care to comment why EDCCA is needed at all ?
> > > > >
> > > > > Taking that debugfs file that enable it is read-only, it looks like
> > > > > feature that nobody needs nor tests.
> > > >
> > > > already fixed in v2
> > > > https://patchwork.kernel.org/patch/10940645/
> > >
> > > I'm aware of this patch and other one for mt76x02. But so far in the
> > > sources EDCCA is disabled for mt76x02 without possibility to enable it
> > > (and this permission file issue was pointed by Kalle during review, not
> > > by someone who want to test EDCCA). So again, what for EDCCA is needed ?
> >
> > As I have already written in a previous email, ED/CCA is used to control tx power
> > according to the CCA MIB counters (e.g do not transmit if the channel busy time
> > is higher than 90% for given amount of time in a row). I guess it is required
> > by ETSI regulatory.
> But what is user case for that, i.e. who need this (it wasn't implemented in
> mt76x2 since you added it on Dec 2018). What will happen if it will be removed?
>
> > Regarding file permission for mt76x02 debugfs edcca node is a typo.
> Typo or not, effectively disable the feature and show nobody is
> testing it.
>
> The reason I'm asking is that seems EDCCA is the main reason to
> implement watchod for mt76x2, it wasn't necessary to have a watchdog
> as seems devices did not hung before EDCCA was added.
IIRC I added the first watchdog implementation to fix tx hangs that occur
under heavy load even using FCC regulatory (so when EDCCA processing is
disabled)
Regards,
Lorenzo
>
> Stanislaw
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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