Re: [PATCH v3 0/2] add fw coredump for sdio when firmware assert
Wen Gong writes: > add fw coredump for sdio when firmware assert Please add the changelog here. > Wen Gong (2): > ath10k: add bus type for each layout of coredump > v2: change code style > v3: split bus type to another patch, > remove ATH10K_BUS_ANY, > add bus type for each layout > ath10k: add fw coredump for sdio when firmware assert > v2: change code style > v3: add commit log for fastdump, > add commit log for ath10k_sdio_hif_diag_read, > change ath10k_err to dbg log Then you mix the changelog with patch titles like that it makes it hard to read the summary. So instead add the changelog above, before the summary, and leave the summary intact. Also this didn't apply: Applying: ath10k: add bus type for each layout of coredump Applying: ath10k: add fw coredump for sdio when firmware assert fatal: sha1 information is lacking or useless (drivers/net/wireless/ath/ath10k/coredump.c). error: could not build fake ancestor Patch failed at 0002 ath10k: add fw coredump for sdio when firmware assert Then you submit the patch use ath.git master branch as the baseline and do NOT have any other patches applied. Otherwise the sha1 information is wrong and it's a lot more work for me to fix the conflicts. So please rebase and resend. -- Kalle Valo
Re: [PATCH 5/5] ath10k: pull_svc_rdy code-style fix
Tomislav Požega writes:
> Drop unneeded lines by moving skb data in both main and 10x WMI
> pull service ready event operations.
>
> Signed-off-by: Tomislav Požega
> ---
> drivers/net/wireless/ath/ath10k/wmi.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
> b/drivers/net/wireless/ath/ath10k/wmi.c
> index 59d2d2a..8ab178c 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -5345,13 +5345,12 @@ static int ath10k_wmi_alloc_host_mem(struct ath10k
> *ar, u32 req_id,
> ath10k_wmi_main_op_pull_svc_rdy_ev(struct ath10k *ar, struct sk_buff *skb,
> struct wmi_svc_rdy_ev_arg *arg)
> {
> - struct wmi_service_ready_event *ev;
> + struct wmi_service_ready_event *ev = (void *)skb->data;
> size_t i, n;
>
> if (skb->len < sizeof(*ev))
> return -EPROTO;
>
> - ev = (void *)skb->data;
Actually I prefer the original style, so that we first check the data in
skb is valid and only then assign the data to ev.
--
Kalle Valo
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 2/4] mac80211: defer txqs removal from rbtree
Toke Høiland-Jørgensen writes: > Kalle Valo writes: > >> Toke Høiland-Jørgensen writes: >> >>> Yibo Zhao writes: >>> On 2019-09-21 22:00, Toke Høiland-Jørgensen wrote: > Yibo Zhao writes: > >> On 2019-09-21 21:02, Toke Høiland-Jørgensen wrote: >>> Yibo Zhao writes: >>> On 2019-09-21 19:27, Toke Høiland-Jørgensen wrote: > Yibo Zhao writes: > >> On 2019-09-20 17:15, Toke Høiland-Jørgensen wrote: >>> Yibo Zhao writes: >>> On 2019-09-19 18:37, Toke Høiland-Jørgensen wrote: > Yibo Zhao writes: > >> On 2019-09-18 19:23, Toke Høiland-Jørgensen wrote: >>> Yibo Zhao writes: >>> On 2019-09-18 05:10, Toke Høiland-Jørgensen wrote: > Yibo Zhao writes: >> >> Guys, PLEASE please consider us poor maintainers drowning in email and >> edit your quotes :) This style of discussion makes patchwork unusable: >> >> https://patchwork.kernel.org/patch/11147019/ > > Heh, oops, didn't realise you were following the discussion from > patchwork; sorry, will be sure to cut things in the future. To be honest, I'm not sure how much Johannes uses patchwork. But I check everything from patchwork 95% of the time and try to keep my email boxes clean. > The quote marks do make a very nice (reverse) christmas tree, though ;) It did! I had to include that to my rant :) -- Kalle Valo
Re: [PATCH v2] ath10k: add fw coredump for sdio when firmware assert
patch v3 sent. https://patchwork.kernel.org/patch/11156663/ https://patchwork.kernel.org/patch/11156659/ ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH V3 4/4] mac80211: Sync airtime weight sum with per AC synced sta airtime weight together
On 2019-09-23 19:00, Toke Høiland-Jørgensen wrote:
- if (params->airtime_weight)
- sta->airtime_weight = params->airtime_weight;
+ if (params->airtime_weight &&
+ params->airtime_weight != sta->airtime_weight) {
This check doesn't work I think? You're not using the array-based
sta->airtime_weight[], and there are locking issues by just checking
like this; so maybe just keep the if() on params->airtime_weight, and
do
the checking inside the loop while holding the lock?
It should be array-based sta->airtime_weight[] and I am missing that
part during the porting. But you are right about we should check it
inside the loop with the lock.
Or could we just turn the weights into atomics to avoid the locking
entirely?
Actually, we still need the active txq locking to make sure the txq is
on the rbtree. Otherwise, no need to change airtime weight sum.
+ for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
+ spin_lock_bh(>active_txq_lock[ac]);
+ for (tid = 0; tid < IEEE80211_NUM_TIDS + 1; tid++) {
+ if (!sta->sta.txq[tid] ||
+ ac != ieee80211_ac_from_tid(tid))
+ continue;
+
+ pre_weight = sta->airtime_weight[ac];
+ sta->airtime_weight[ac] =
+ params->airtime_weight;
+
+ txqi = to_txq_info(sta->sta.txq[tid]);
+ if (RB_EMPTY_NODE(>schedule_order))
+ continue;
+
+ local->airtime_weight_sum[ac] =
local->airtime_weight_sum[ac] +
+
params->airtime_weight -
+ pre_weight;
+ }
+ spin_unlock_bh(>active_txq_lock[ac]);
+ }
+ }
--
Yibo
Re: [PATCH V3 2/4] mac80211: defer txqs removal from rbtree
On 2019-09-23 18:56, Toke Høiland-Jørgensen wrote: Yibo Zhao writes: In a loop txqs dequeue scenario, if the first txq in the rbtree gets removed from rbtree immediately in the ieee80211_return_txq(), the loop will break soon in the ieee80211_next_txq() due to schedule_pos not leading to the second txq in the rbtree. Thus, defering the removal right before the end of this schedule round. Didn't we agree that we could fix this by making __unschedule_txq() aware of schedule_pos instead of this deferred removal mechanism? Yes, V3 is actually used to update the commit log of [PATCH V3 3/4] so that we can discuss in parallel with others, and [PATCH V3 4/4] for discussion. Please ignore [PATCH V3 2/4]. we can keep our discussion in V2 until we conclude the final one and then a new version will be sent out along with [mac80211: Switch to a virtual time-based airtime scheduler] which includes the reducing lock fix. Sorry for the confusion, ;). -Toke -- Yibo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 2/4] mac80211: defer txqs removal from rbtree
On 2019-09-23 18:47, Toke Høiland-Jørgensen wrote: Yibo Zhao writes: So, instead we need to keep next_txq() the way it is, and just add Right, should keep next_txq() the way it is. local->schedule_pos[ac] = rb_prev(node); whenever we remove a node (both in return_txq() and resort_txq()). Agree, and also we may need to consider case like A is removed and soon be added back just the same as ii), B->C->A->D->E then B is schedule, removed and soon added back, C->A->B->D->E A and B will have a second chance to be scheduled and this may happen to others as well leading to the infinite loop as you have mentioned previously, so do we need to maintain a schedule_round like we do in DRR? Like, - If the node is in the same round, by pass schedule, go to rb_next(), either continue loop this round or end this round. - Increase the schedule_round at the schedule_start() only when the schedule_pos is NULL. Hmm, yeah, I guess we could end up with a loop like that as well. Keeping the schedule_round would be a way to fix it, but I'm not sure we should just skip that station; maybe we should just end the round instead? I am not sure. I believe, in some cases, the rest of the nodes which could be most of the nodes in the tree will not have the chance to be scheduled in this round. We'd still need a check in resort_txq() then, but it would make it safe to unschedule in return_txq()... Yes, agree with that. -- Yibo
[PATCH 4/5] ath10k: change sw version print format to hex
Software version within WMI event ready message was displayed in a not very useful decimal format. Change this info to be shown in a hexadecimal format instead. Signed-off-by: Tomislav Požega --- drivers/net/wireless/ath/ath10k/wmi.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index 2d43adf..59d2d2a 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -5650,7 +5650,7 @@ int ath10k_wmi_event_ready(struct ath10k *ar, struct sk_buff *skb) } ath10k_dbg(ar, ATH10K_DBG_WMI, - "wmi event ready sw_version %u abi_version %u mac_addr %pM status %d\n", + "wmi event ready sw_version 0x%08x abi_version %u mac_addr %pM status %d\n", __le32_to_cpu(arg.sw_version), __le32_to_cpu(arg.abi_version), arg.mac_addr, -- 1.7.0.4 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH 5/5] ath10k: pull_svc_rdy code-style fix
Drop unneeded lines by moving skb data in both main and 10x WMI
pull service ready event operations.
Signed-off-by: Tomislav Požega
---
drivers/net/wireless/ath/ath10k/wmi.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 59d2d2a..8ab178c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5345,13 +5345,12 @@ static int ath10k_wmi_alloc_host_mem(struct ath10k *ar,
u32 req_id,
ath10k_wmi_main_op_pull_svc_rdy_ev(struct ath10k *ar, struct sk_buff *skb,
struct wmi_svc_rdy_ev_arg *arg)
{
- struct wmi_service_ready_event *ev;
+ struct wmi_service_ready_event *ev = (void *)skb->data;
size_t i, n;
if (skb->len < sizeof(*ev))
return -EPROTO;
- ev = (void *)skb->data;
skb_pull(skb, sizeof(*ev));
arg->min_tx_power = ev->hw_min_tx_power;
arg->max_tx_power = ev->hw_max_tx_power;
@@ -5387,13 +5386,12 @@ static int ath10k_wmi_alloc_host_mem(struct ath10k *ar,
u32 req_id,
ath10k_wmi_10x_op_pull_svc_rdy_ev(struct ath10k *ar, struct sk_buff *skb,
struct wmi_svc_rdy_ev_arg *arg)
{
- struct wmi_10x_service_ready_event *ev;
+ struct wmi_10x_service_ready_event *ev = (void *)skb->data;
int i, n;
if (skb->len < sizeof(*ev))
return -EPROTO;
- ev = (void *)skb->data;
skb_pull(skb, sizeof(*ev));
arg->min_tx_power = ev->hw_min_tx_power;
arg->max_tx_power = ev->hw_max_tx_power;
--
1.7.0.4
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH 1/5] ath10k: add 2ghz channel arguments to service ready structure
Add lowest/highest 2ghz channel arguments for use within WMI service
ready structure.
Signed-off-by: Tomislav Požega
---
drivers/net/wireless/ath/ath10k/core.h|2 ++
drivers/net/wireless/ath/ath10k/wmi-tlv.c |2 ++
drivers/net/wireless/ath/ath10k/wmi.c |6 ++
drivers/net/wireless/ath/ath10k/wmi.h |2 ++
4 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index c96d1a1..2a0a008 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -967,6 +967,8 @@ struct ath10k {
u32 num_rf_chains;
u32 max_spatial_stream;
/* protected by conf_mutex */
+ u32 low_2ghz_chan;
+ u32 high_2ghz_chan;
u32 low_5ghz_chan;
u32 high_5ghz_chan;
bool ani_enabled;
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 363fd0b..bda52ca 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1207,6 +1207,8 @@ static int ath10k_wmi_tlv_op_pull_svc_rdy_ev(struct
ath10k *ar,
arg->phy_capab = ev->phy_capability;
arg->num_rf_chains = ev->num_rf_chains;
arg->eeprom_rd = reg->eeprom_rd;
+ arg->low_2ghz_chan = reg->low_2ghz_chan;
+ arg->high_2ghz_chan = reg->high_2ghz_chan;
arg->low_5ghz_chan = reg->low_5ghz_chan;
arg->high_5ghz_chan = reg->high_5ghz_chan;
arg->num_mem_reqs = ev->num_mem_reqs;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 1ec609d..3ef6ee3 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5362,6 +5362,8 @@ static int ath10k_wmi_alloc_host_mem(struct ath10k *ar,
u32 req_id,
arg->phy_capab = ev->phy_capability;
arg->num_rf_chains = ev->num_rf_chains;
arg->eeprom_rd = ev->hal_reg_capabilities.eeprom_rd;
+ arg->low_2ghz_chan = ev->hal_reg_capabilities.low_2ghz_chan;
+ arg->high_2ghz_chan = ev->hal_reg_capabilities.high_2ghz_chan;
arg->low_5ghz_chan = ev->hal_reg_capabilities.low_5ghz_chan;
arg->high_5ghz_chan = ev->hal_reg_capabilities.high_5ghz_chan;
arg->num_mem_reqs = ev->num_mem_reqs;
@@ -5400,6 +5402,8 @@ static int ath10k_wmi_alloc_host_mem(struct ath10k *ar,
u32 req_id,
arg->phy_capab = ev->phy_capability;
arg->num_rf_chains = ev->num_rf_chains;
arg->eeprom_rd = ev->hal_reg_capabilities.eeprom_rd;
+ arg->low_2ghz_chan = ev->hal_reg_capabilities.low_2ghz_chan;
+ arg->high_2ghz_chan = ev->hal_reg_capabilities.high_2ghz_chan;
arg->low_5ghz_chan = ev->hal_reg_capabilities.low_5ghz_chan;
arg->high_5ghz_chan = ev->hal_reg_capabilities.high_5ghz_chan;
arg->num_mem_reqs = ev->num_mem_reqs;
@@ -5454,6 +5458,8 @@ static void ath10k_wmi_event_service_ready_work(struct
work_struct *work)
ar->phy_capability = __le32_to_cpu(arg.phy_capab);
ar->num_rf_chains = __le32_to_cpu(arg.num_rf_chains);
ar->hw_eeprom_rd = __le32_to_cpu(arg.eeprom_rd);
+ ar->low_2ghz_chan = __le32_to_cpu(arg.low_2ghz_chan);
+ ar->high_2ghz_chan = __le32_to_cpu(arg.high_2ghz_chan);
ar->low_5ghz_chan = __le32_to_cpu(arg.low_5ghz_chan);
ar->high_5ghz_chan = __le32_to_cpu(arg.high_5ghz_chan);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index bdeebc5..9ccaeb7 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6870,6 +6870,8 @@ struct wmi_svc_rdy_ev_arg {
__le32 num_rf_chains;
__le32 eeprom_rd;
__le32 num_mem_reqs;
+ __le32 low_2ghz_chan;
+ __le32 high_2ghz_chan;
__le32 low_5ghz_chan;
__le32 high_5ghz_chan;
const __le32 *service_map;
--
1.7.0.4
[PATCH 3/5] ath10k: print supported MCS rates within service ready event
Add vht_supp_mcs argument to service ready structure and print
supported MCS rates in WMI service ready debug message.
Signed-off-by: Tomislav Požega
---
drivers/net/wireless/ath/ath10k/core.h|1 +
drivers/net/wireless/ath/ath10k/wmi-tlv.c |1 +
drivers/net/wireless/ath/ath10k/wmi.c |6 +-
drivers/net/wireless/ath/ath10k/wmi.h |1 +
4 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 2a0a008..153c4a2 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -964,6 +964,7 @@ struct ath10k {
u32 hw_eeprom_rd;
u32 ht_cap_info;
u32 vht_cap_info;
+ u32 vht_supp_mcs;
u32 num_rf_chains;
u32 max_spatial_stream;
/* protected by conf_mutex */
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index bda52ca..2432a74 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1201,6 +1201,7 @@ static int ath10k_wmi_tlv_op_pull_svc_rdy_ev(struct
ath10k *ar,
arg->max_tx_power = ev->hw_max_tx_power;
arg->ht_cap = ev->ht_cap_info;
arg->vht_cap = ev->vht_cap_info;
+ arg->vht_supp_mcs = ev->vht_supp_mcs;
arg->sw_ver0 = ev->abi.abi_ver0;
arg->sw_ver1 = ev->abi.abi_ver1;
arg->fw_build = ev->fw_build_vers;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index b7b8072..2d43adf 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5357,6 +5357,7 @@ static int ath10k_wmi_alloc_host_mem(struct ath10k *ar,
u32 req_id,
arg->max_tx_power = ev->hw_max_tx_power;
arg->ht_cap = ev->ht_cap_info;
arg->vht_cap = ev->vht_cap_info;
+ arg->vht_supp_mcs = ev->vht_supp_mcs;
arg->sw_ver0 = ev->sw_version;
arg->sw_ver1 = ev->sw_version_1;
arg->phy_capab = ev->phy_capability;
@@ -5398,6 +5399,7 @@ static int ath10k_wmi_alloc_host_mem(struct ath10k *ar,
u32 req_id,
arg->max_tx_power = ev->hw_max_tx_power;
arg->ht_cap = ev->ht_cap_info;
arg->vht_cap = ev->vht_cap_info;
+ arg->vht_supp_mcs = ev->vht_supp_mcs;
arg->sw_ver0 = ev->sw_version;
arg->phy_capab = ev->phy_capability;
arg->num_rf_chains = ev->num_rf_chains;
@@ -5449,6 +5451,7 @@ static void ath10k_wmi_event_service_ready_work(struct
work_struct *work)
ar->hw_max_tx_power = __le32_to_cpu(arg.max_tx_power);
ar->ht_cap_info = __le32_to_cpu(arg.ht_cap);
ar->vht_cap_info = __le32_to_cpu(arg.vht_cap);
+ ar->vht_supp_mcs = __le32_to_cpu(arg.vht_supp_mcs);
ar->fw_version_major =
(__le32_to_cpu(arg.sw_ver0) & 0xff00) >> 24;
ar->fw_version_minor = (__le32_to_cpu(arg.sw_ver0) & 0x00ff);
@@ -5563,11 +5566,12 @@ static void ath10k_wmi_event_service_ready_work(struct
work_struct *work)
skip_mem_alloc:
ath10k_dbg(ar, ATH10K_DBG_WMI,
- "wmi event service ready min_tx_power 0x%08x max_tx_power
0x%08x ht_cap 0x%08x vht_cap 0x%08x sw_ver0 0x%08x sw_ver1 0x%08x fw_build
0x%08x phy_capab 0x%08x num_rf_chains 0x%08x eeprom_rd 0x%08x low_2ghz_chan %d
high_2ghz_chan %d low_5ghz_chan %d high_5ghz_chan %d num_mem_reqs 0x%08x\n",
+ "wmi event service ready min_tx_power 0x%08x max_tx_power
0x%08x ht_cap 0x%08x vht_cap 0x%08x vht_supp_mcs 0x%08x sw_ver0 0x%08x sw_ver1
0x%08x fw_build 0x%08x phy_capab 0x%08x num_rf_chains 0x%08x eeprom_rd 0x%08x
low_2ghz_chan %d high_2ghz_chan %d low_5ghz_chan %d high_5ghz_chan %d
num_mem_reqs 0x%08x\n",
__le32_to_cpu(arg.min_tx_power),
__le32_to_cpu(arg.max_tx_power),
__le32_to_cpu(arg.ht_cap),
__le32_to_cpu(arg.vht_cap),
+ __le32_to_cpu(arg.vht_supp_mcs),
__le32_to_cpu(arg.sw_ver0),
__le32_to_cpu(arg.sw_ver1),
__le32_to_cpu(arg.fw_build),
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index 9ccaeb7..d9d53e5 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6863,6 +6863,7 @@ struct wmi_svc_rdy_ev_arg {
__le32 max_tx_power;
__le32 ht_cap;
__le32 vht_cap;
+ __le32 vht_supp_mcs;
__le32 sw_ver0;
__le32 sw_ver1;
__le32 fw_build;
--
1.7.0.4
[PATCH 2/5] ath10k: print service ready returned channel range
Displays lowest/highest supported channels for both 2ghz and 5ghz bands as they're fetched within WMI service ready event. These are shown in a frequency format. Signed-off-by: Tomislav Požega --- drivers/net/wireless/ath/ath10k/wmi.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index 3ef6ee3..b7b8072 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -5563,7 +5563,7 @@ static void ath10k_wmi_event_service_ready_work(struct work_struct *work) skip_mem_alloc: ath10k_dbg(ar, ATH10K_DBG_WMI, - "wmi event service ready min_tx_power 0x%08x max_tx_power 0x%08x ht_cap 0x%08x vht_cap 0x%08x sw_ver0 0x%08x sw_ver1 0x%08x fw_build 0x%08x phy_capab 0x%08x num_rf_chains 0x%08x eeprom_rd 0x%08x num_mem_reqs 0x%08x\n", + "wmi event service ready min_tx_power 0x%08x max_tx_power 0x%08x ht_cap 0x%08x vht_cap 0x%08x sw_ver0 0x%08x sw_ver1 0x%08x fw_build 0x%08x phy_capab 0x%08x num_rf_chains 0x%08x eeprom_rd 0x%08x low_2ghz_chan %d high_2ghz_chan %d low_5ghz_chan %d high_5ghz_chan %d num_mem_reqs 0x%08x\n", __le32_to_cpu(arg.min_tx_power), __le32_to_cpu(arg.max_tx_power), __le32_to_cpu(arg.ht_cap), @@ -5574,6 +5574,10 @@ static void ath10k_wmi_event_service_ready_work(struct work_struct *work) __le32_to_cpu(arg.phy_capab), __le32_to_cpu(arg.num_rf_chains), __le32_to_cpu(arg.eeprom_rd), + __le32_to_cpu(arg.low_2ghz_chan), + __le32_to_cpu(arg.high_2ghz_chan), + __le32_to_cpu(arg.low_5ghz_chan), + __le32_to_cpu(arg.high_5ghz_chan), __le32_to_cpu(arg.num_mem_reqs)); dev_kfree_skb(skb); -- 1.7.0.4
Re: [PATCH 2/4] mac80211: defer txqs removal from rbtree
Kalle Valo writes: > Toke Høiland-Jørgensen writes: > >> Yibo Zhao writes: >> >>> On 2019-09-21 22:00, Toke Høiland-Jørgensen wrote: Yibo Zhao writes: > On 2019-09-21 21:02, Toke Høiland-Jørgensen wrote: >> Yibo Zhao writes: >> >>> On 2019-09-21 19:27, Toke Høiland-Jørgensen wrote: Yibo Zhao writes: > On 2019-09-20 17:15, Toke Høiland-Jørgensen wrote: >> Yibo Zhao writes: >> >>> On 2019-09-19 18:37, Toke Høiland-Jørgensen wrote: Yibo Zhao writes: > On 2019-09-18 19:23, Toke Høiland-Jørgensen wrote: >> Yibo Zhao writes: >> >>> On 2019-09-18 05:10, Toke Høiland-Jørgensen wrote: Yibo Zhao writes: > > Guys, PLEASE please consider us poor maintainers drowning in email and > edit your quotes :) This style of discussion makes patchwork unusable: > > https://patchwork.kernel.org/patch/11147019/ Heh, oops, didn't realise you were following the discussion from patchwork; sorry, will be sure to cut things in the future. The quote marks do make a very nice (reverse) christmas tree, though ;) -Toke
[PATCH v3 2/2] ath10k: add fw coredump for sdio when firmware assert
When firmware assert, it need coredump to analyze, this patch will
collect the register and memory info for sdio chip.
The coredump configuration is different between PCIE and SDIO for
the same reversion, so this patch add bus type to distinguish PCIE
and SDIO chip for coredump.
It has 2 type to dump firmware: fastdump and slowdump. Fastdump is
not support in old version firmware, if this, ath10k will select
slowdump for it. If firmware support fastdump, ath10k will select
fastdump for it. Version WLAN.RMH.4.4.1-00017-QCARMSWPZ-2 of
firmware begin to support fastdump.
For slow dump, ath10k_sdio_hif_diag_read can not be used, the diag
window has a limit value, it is 4 bytes and the dump's buffer length
is larger than it, it will trigger error. So this patch add
ath10k_sdio_read_mem to read 4 bytes for each time.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00018-QCARMSWP-1.
Signed-off-by: Wen Gong
---
v2: change code style
v3: add commit log for fastdump,
add commit log for ath10k_sdio_hif_diag_read,
change ath10k_err to dbg log
drivers/net/wireless/ath/ath10k/bmi.c | 1 +
drivers/net/wireless/ath/ath10k/core.c | 4 +
drivers/net/wireless/ath/ath10k/coredump.c | 333 +++
drivers/net/wireless/ath/ath10k/sdio.c | 338 +++-
drivers/net/wireless/ath/ath10k/targaddrs.h | 10 +
5 files changed, 682 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/bmi.c
b/drivers/net/wireless/ath/ath10k/bmi.c
index 95dc4be..990fa4d 100644
--- a/drivers/net/wireless/ath/ath10k/bmi.c
+++ b/drivers/net/wireless/ath/ath10k/bmi.c
@@ -197,6 +197,7 @@ int ath10k_bmi_read_memory(struct ath10k *ar,
return 0;
}
+EXPORT_SYMBOL(ath10k_bmi_read_memory);
int ath10k_bmi_write_soc_reg(struct ath10k *ar, u32 address, u32 reg_val)
{
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index dc45d16..c4595f8 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -708,6 +708,10 @@ static void ath10k_init_sdio(struct ath10k *ar, enum
ath10k_firmware_mode mode)
ath10k_bmi_read32(ar, hi_option_flag, );
param |= HI_OPTION_DISABLE_DBGLOG;
ath10k_bmi_write32(ar, hi_option_flag, param);
+
+ ath10k_bmi_read32(ar, hi_option_flag2, );
+ param |= HI_OPTION_SDIO_CRASH_DUMP_ENHANCEMENT_HOST;
+ ath10k_bmi_write32(ar, hi_option_flag2, param);
}
static int ath10k_init_configure_target(struct ath10k *ar)
diff --git a/drivers/net/wireless/ath/ath10k/coredump.c
b/drivers/net/wireless/ath/ath10k/coredump.c
index abc133d..24c5c63 100644
--- a/drivers/net/wireless/ath/ath10k/coredump.c
+++ b/drivers/net/wireless/ath/ath10k/coredump.c
@@ -270,6 +270,277 @@
{0x80010, 0x80020},
};
+static const struct ath10k_mem_section qca6174_hw30_sdio_register_sections[] =
{
+ {0x800, 0x810},
+ {0x820, 0x82C},
+ {0x830, 0x8F4},
+ {0x90C, 0x91C},
+ {0xA14, 0xA18},
+ {0xA84, 0xA94},
+ {0xAA8, 0xAD4},
+ {0xADC, 0xB40},
+ {0x1000, 0x10A4},
+ {0x10BC, 0x111C},
+ {0x1134, 0x1138},
+ {0x1144, 0x114C},
+ {0x1150, 0x115C},
+ {0x1160, 0x1178},
+ {0x1240, 0x1260},
+ {0x2000, 0x207C},
+ {0x3000, 0x3014},
+ {0x4000, 0x4014},
+ {0x5000, 0x5124},
+ {0x6000, 0x6040},
+ {0x6080, 0x60CC},
+ {0x6100, 0x611C},
+ {0x6140, 0x61D8},
+ {0x6200, 0x6238},
+ {0x6240, 0x628C},
+ {0x62C0, 0x62EC},
+ {0x6380, 0x63E8},
+ {0x6400, 0x6440},
+ {0x6480, 0x64CC},
+ {0x6500, 0x651C},
+ {0x6540, 0x6580},
+ {0x6600, 0x6638},
+ {0x6640, 0x668C},
+ {0x66C0, 0x66EC},
+ {0x6780, 0x67E8},
+ {0x7080, 0x708C},
+ {0x70C0, 0x70C8},
+ {0x7400, 0x741C},
+ {0x7440, 0x7454},
+ {0x7800, 0x7818},
+ {0x8010, 0x8060},
+ {0x8080, 0x8084},
+ {0x80A0, 0x80A4},
+ {0x80C0, 0x80C4},
+ {0x80E0, 0x80ec},
+ {0x8110, 0x8128},
+ {0x9000, 0x9004},
+ {0xF000, 0xF0E0},
+ {0xF140, 0xF190},
+ {0xF250, 0xF25C},
+ {0xF260, 0xF268},
+ {0xF26C, 0xF2A8},
+ {0x10008, 0x1000C},
+ {0x10014, 0x10018},
+ {0x1001C, 0x10020},
+ {0x10024, 0x10028},
+ {0x10030, 0x10034},
+ {0x10040, 0x10054},
+ {0x10058, 0x1007C},
+ {0x10080, 0x100C4},
+ {0x100C8, 0x10114},
+ {0x1012C, 0x10130},
+ {0x10138, 0x10144},
+ {0x10200, 0x10220},
+ {0x10230, 0x10250},
+ {0x10260, 0x10280},
+ {0x10290, 0x102B0},
+ {0x102C0, 0x102DC},
+ {0x102E0, 0x102F4},
+ {0x102FC, 0x1037C},
+ {0x10380, 0x10390},
+ {0x10800, 0x10828},
+ {0x10840, 0x10844},
+ {0x10880, 0x10884},
+ {0x108C0, 0x108E8},
+ {0x10900, 0x10928},
+ {0x10940, 0x10944},
+ {0x10980, 0x10984},
+ {0x109C0,
[PATCH v3 0/2] add fw coredump for sdio when firmware assert
add fw coredump for sdio when firmware assert Wen Gong (2): ath10k: add bus type for each layout of coredump v2: change code style v3: split bus type to another patch, remove ATH10K_BUS_ANY, add bus type for each layout ath10k: add fw coredump for sdio when firmware assert v2: change code style v3: add commit log for fastdump, add commit log for ath10k_sdio_hif_diag_read, change ath10k_err to dbg log drivers/net/wireless/ath/ath10k/bmi.c | 1 + drivers/net/wireless/ath/ath10k/core.c | 4 + drivers/net/wireless/ath/ath10k/coredump.c | 348 +++- drivers/net/wireless/ath/ath10k/coredump.h | 1 + drivers/net/wireless/ath/ath10k/sdio.c | 338 ++- drivers/net/wireless/ath/ath10k/targaddrs.h | 10 + 6 files changed, 697 insertions(+), 5 deletions(-) -- 1.9.1 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH v3 1/2] ath10k: add bus type for each layout of coredump
For some hw version, it has more than one bus type, it need to add bus
type to distinguish different chip.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00018-QCARMSWP-1.
Signed-off-by: Wen Gong
---
v2: change code style
v3: split bus type to another patch,
remove ATH10K_BUS_ANY,
add bus type for each layout
drivers/net/wireless/ath/ath10k/coredump.c | 15 ++-
drivers/net/wireless/ath/ath10k/coredump.h | 1 +
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/coredump.c
b/drivers/net/wireless/ath/ath10k/coredump.c
index b6d2932..abc133d 100644
--- a/drivers/net/wireless/ath/ath10k/coredump.c
+++ b/drivers/net/wireless/ath/ath10k/coredump.c
@@ -955,6 +955,7 @@
{
.hw_id = QCA6174_HW_1_0_VERSION,
.hw_rev = ATH10K_HW_QCA6174,
+ .bus = ATH10K_BUS_PCI,
.region_table = {
.regions = qca6174_hw10_mem_regions,
.size = ARRAY_SIZE(qca6174_hw10_mem_regions),
@@ -963,6 +964,7 @@
{
.hw_id = QCA6174_HW_1_1_VERSION,
.hw_rev = ATH10K_HW_QCA6174,
+ .bus = ATH10K_BUS_PCI,
.region_table = {
.regions = qca6174_hw10_mem_regions,
.size = ARRAY_SIZE(qca6174_hw10_mem_regions),
@@ -971,6 +973,7 @@
{
.hw_id = QCA6174_HW_1_3_VERSION,
.hw_rev = ATH10K_HW_QCA6174,
+ .bus = ATH10K_BUS_PCI,
.region_table = {
.regions = qca6174_hw10_mem_regions,
.size = ARRAY_SIZE(qca6174_hw10_mem_regions),
@@ -979,6 +982,7 @@
{
.hw_id = QCA6174_HW_2_1_VERSION,
.hw_rev = ATH10K_HW_QCA6174,
+ .bus = ATH10K_BUS_PCI,
.region_table = {
.regions = qca6174_hw21_mem_regions,
.size = ARRAY_SIZE(qca6174_hw21_mem_regions),
@@ -987,6 +991,7 @@
{
.hw_id = QCA6174_HW_3_0_VERSION,
.hw_rev = ATH10K_HW_QCA6174,
+ .bus = ATH10K_BUS_PCI,
.region_table = {
.regions = qca6174_hw30_mem_regions,
.size = ARRAY_SIZE(qca6174_hw30_mem_regions),
@@ -995,6 +1000,7 @@
{
.hw_id = QCA6174_HW_3_2_VERSION,
.hw_rev = ATH10K_HW_QCA6174,
+ .bus = ATH10K_BUS_PCI,
.region_table = {
.regions = qca6174_hw30_mem_regions,
.size = ARRAY_SIZE(qca6174_hw30_mem_regions),
@@ -1003,6 +1009,7 @@
{
.hw_id = QCA9377_HW_1_1_DEV_VERSION,
.hw_rev = ATH10K_HW_QCA9377,
+ .bus = ATH10K_BUS_PCI,
.region_table = {
.regions = qca6174_hw30_mem_regions,
.size = ARRAY_SIZE(qca6174_hw30_mem_regions),
@@ -1011,6 +1018,7 @@
{
.hw_id = QCA988X_HW_2_0_VERSION,
.hw_rev = ATH10K_HW_QCA988X,
+ .bus = ATH10K_BUS_PCI,
.region_table = {
.regions = qca988x_hw20_mem_regions,
.size = ARRAY_SIZE(qca988x_hw20_mem_regions),
@@ -1019,6 +1027,7 @@
{
.hw_id = QCA9984_HW_1_0_DEV_VERSION,
.hw_rev = ATH10K_HW_QCA9984,
+ .bus = ATH10K_BUS_PCI,
.region_table = {
.regions = qca9984_hw10_mem_regions,
.size = ARRAY_SIZE(qca9984_hw10_mem_regions),
@@ -1027,6 +1036,7 @@
{
.hw_id = QCA9888_HW_2_0_DEV_VERSION,
.hw_rev = ATH10K_HW_QCA9888,
+ .bus = ATH10K_BUS_PCI,
.region_table = {
.regions = qca9984_hw10_mem_regions,
.size = ARRAY_SIZE(qca9984_hw10_mem_regions),
@@ -1035,6 +1045,7 @@
{
.hw_id = QCA99X0_HW_2_0_DEV_VERSION,
.hw_rev = ATH10K_HW_QCA99X0,
+ .bus = ATH10K_BUS_PCI,
.region_table = {
.regions = qca99x0_hw20_mem_regions,
.size = ARRAY_SIZE(qca99x0_hw20_mem_regions),
@@ -1043,6 +1054,7 @@
{
.hw_id = QCA4019_HW_1_0_DEV_VERSION,
.hw_rev = ATH10K_HW_QCA4019,
+ .bus = ATH10K_BUS_AHB,
.region_table = {
.regions = qca4019_hw10_mem_regions,
.size = ARRAY_SIZE(qca4019_hw10_mem_regions),
@@ -1090,7 +1102,8 @@ const struct ath10k_hw_mem_layout
*ath10k_coredump_get_mem_layout(struct ath10k
for (i = 0; i < ARRAY_SIZE(hw_mem_layouts); i++) {
if (ar->target_version == hw_mem_layouts[i].hw_id &&
- ar->hw_rev == hw_mem_layouts[i].hw_rev)
+
Re: [PATCH v2] ath10k: add fw coredump for sdio when firmware assert
On 2019-09-23 19:37, Kalle Valo wrote: Wen Gong writes: On 2019-09-21 19:38, Kalle Valo wrote: What's wrong with ath10k_sdio_hif_diag_read()? AFAICS this whole function duplicates just what it does. ath10k_sdio_hif_diag_read's buffer size is limit, and the dump memory/register's buffer size is larger than the diag window's limit, if use it directly will trigger crash like this for every time. You shouldn't blindly add extra code to ath10k workaround issues. And if you really need to use a workaround, then it needs to properly explained in the commit and as well as commented in the code. But before that the issue needs to be thoroughly investigated and understood where the problem is coming from. Because it might be even completely unrelated to ath10k. [ 149.947624] ath10k_sdio mmc1:0001:1: ath10k_sdio_hif_diag_read buf_len :4 [ 149.954741] ath10k_sdio mmc1:0001:1: ath10k_sdio_hif_diag_read buf_len :240 [ 151.005143] Unable to handle kernel paging request at virtual [ 151.114537] Process swapper/0 (pid: 0, stack limit = 0xe30dc665) 、 Did you investigate this? Is the buffer you reading to DMA accessible? What about the alignment? Is there a certain length which is the limit for crashes? And so on... the limit is 4 byte. for 5 bytes, it will crash.
Re: [PATCH 2/4] mac80211: defer txqs removal from rbtree
Toke Høiland-Jørgensen writes: > Yibo Zhao writes: > >> On 2019-09-21 22:00, Toke Høiland-Jørgensen wrote: >>> Yibo Zhao writes: >>> On 2019-09-21 21:02, Toke Høiland-Jørgensen wrote: > Yibo Zhao writes: > >> On 2019-09-21 19:27, Toke Høiland-Jørgensen wrote: >>> Yibo Zhao writes: >>> On 2019-09-20 17:15, Toke Høiland-Jørgensen wrote: > Yibo Zhao writes: > >> On 2019-09-19 18:37, Toke Høiland-Jørgensen wrote: >>> Yibo Zhao writes: >>> On 2019-09-18 19:23, Toke Høiland-Jørgensen wrote: > Yibo Zhao writes: > >> On 2019-09-18 05:10, Toke Høiland-Jørgensen wrote: >>> Yibo Zhao writes: Guys, PLEASE please consider us poor maintainers drowning in email and edit your quotes :) This style of discussion makes patchwork unusable: https://patchwork.kernel.org/patch/11147019/ -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v2] ath10k: add fw coredump for sdio when firmware assert
Wen Gong writes: > On 2019-09-21 19:38, Kalle Valo wrote: >> >> What's wrong with ath10k_sdio_hif_diag_read()? AFAICS this whole >> function duplicates just what it does. > > ath10k_sdio_hif_diag_read's buffer size is limit, > and the dump memory/register's buffer size is larger than the diag > window's limit, > if use it directly will trigger crash like this for every time. You shouldn't blindly add extra code to ath10k workaround issues. And if you really need to use a workaround, then it needs to properly explained in the commit and as well as commented in the code. But before that the issue needs to be thoroughly investigated and understood where the problem is coming from. Because it might be even completely unrelated to ath10k. > [ 149.947624] ath10k_sdio mmc1:0001:1: ath10k_sdio_hif_diag_read > buf_len :4 > [ 149.954741] ath10k_sdio mmc1:0001:1: ath10k_sdio_hif_diag_read > buf_len :240 > [ 151.005143] Unable to handle kernel paging request at virtual > address ffc0080ab980 > [ 151.013077] Mem abort info: > [ 151.015866] ESR = 0x9645 > [ 151.018918] Exception class = DABT (current EL), IL = 32 bits > [ 151.024830] SET = 0, FnV = 0 > [ 151.027880] EA = 0, S1PTW = 0 > [ 151.031016] Data abort info: > [ 151.033892] ISV = 0, ISS = 0x0045 > [ 151.037723] CM = 0, WnR = 1 > [ 151.040691] swapper pgtable: 4k pages, 39-bit VAs, pgdp = > 73b23692 > [ 151.047560] [ffc0080ab980] pgd=, > pud= > [ 151.054354] Internal error: Oops: 9645 [#1] PREEMPT SMP > [ 151.059925] Modules linked in: ath10k_sdio ath10k_core rfcomm > uinput cros_ec_rpmsg mtk_cam_isp ath mac80211 mtk_fd hci_uart btqca > bluetooth mtk_scp mtk_rpmsg rpmsg_core ecdh_generic mtk_scp_ipi bridge > stp llc nf_nat_tftp nf_conntrack_tftp nf_nat_ftp nf_conntrack_ftp esp6 > ah6 xfrm6_mode_tunnel xfrm6_mode_transport xfrm4_mode_tunnel > xfrm4_mode_transport ip6t_REJECT ip6t_ipv6header ipt_MASQUERADE fuse > cfg80211 iio_trig_sysfs cros_ec_sensors_sync cros_ec_sensors > cros_ec_sensors_ring industrialio_triggered_buffer kfifo_buf > cros_ec_sensors_core lzo_rle lzo_compress zram asix usbnet mii joydev > [last unloaded: ath10k_core] > [ 151.114537] Process swapper/0 (pid: 0, stack limit = > 0xe30dc665) > [ 151.121238] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.72 #11 > [ 151.127327] Hardware name: MediaTek kukui rev1 board (DT) > [ 151.132724] pstate: 2085 (nzCv daIf -PAN -UAO) > [ 151.137525] pc : __memcpy+0x110/0x180 > [ 151.141193] lr : swiotlb_tbl_unmap_single+0x84/0x150 > [ 151.146151] sp : ff8008003c60 > [ 151.149462] x29: ff8008003c90 x28: ffa2a9611f38 > [ 151.154774] x27: ffa2a92cc018 x26: > [ 151.160087] x25: ffa2a90b8000 x24: 0001 > [ 151.165399] x23: ffa2a975e000 x22: 1400 > [ 151.170710] x21: x20: fc7ff000 > [ 151.176021] x19: 00f0 x18: 0020 > [ 151.181332] x17: x16: > [ 151.186643] x15: x14: > [ 151.191955] x13: x12: > [ 151.197266] x11: x10: > [ 151.202578] x9 : x8 : > [ 151.207890] x7 : x6 : ffc0080ab980 > [ 151.213202] x5 : ff8016ffbdc8 x4 : > [ 151.218514] x3 : 0002 x2 : 0070 > [ 151.223825] x1 : fff37c7ff040 x0 : ffc0080ab980 > [ 151.229138] Call trace: > [ 151.231585] __memcpy+0x110/0x180 > [ 151.234899] unmap_single+0x6c/0x84 > [ 151.238386] swiotlb_unmap_sg_attrs+0x54/0x80 > [ 151.242744] __swiotlb_unmap_sg_attrs+0xa0/0xb8 > [ 151.247277] msdc_unprepare_data+0x6c/0x84 > [ 151.251372] msdc_request_done+0x58/0x84 > [ 151.255292] msdc_data_xfer_done+0x1a0/0x1c8 > [ 151.259559] msdc_irq+0x12c/0x17c Did you investigate this? Is the buffer you reading to DMA accessible? What about the alignment? Is there a certain length which is the limit for crashes? And so on... -- Kalle Valo
Re: [PATCH v2] ath10k: add fw coredump for sdio when firmware assert
On 2019-09-21 19:49, Kalle Valo wrote: After looking more closely, the ar->bmi.done_set checks in bmi.c does not look necessary to me, I have never seen that warning. I would remove those and the done_sent field altogether from ath10k to make the code cleaner and I avoid hacks like above. This should be done in a separate patch, of course. so I will use it this patch :)
Re: [PATCH v2] ath10k: add fw coredump for sdio when firmware assert
On 2019-09-21 19:38, Kalle Valo wrote: What's wrong with ath10k_sdio_hif_diag_read()? AFAICS this whole function duplicates just what it does. ath10k_sdio_hif_diag_read's buffer size is limit, and the dump memory/register's buffer size is larger than the diag window's limit, if use it directly will trigger crash like this for every time. [ 149.947624] ath10k_sdio mmc1:0001:1: ath10k_sdio_hif_diag_read buf_len :4 [ 149.954741] ath10k_sdio mmc1:0001:1: ath10k_sdio_hif_diag_read buf_len :240 [ 151.005143] Unable to handle kernel paging request at virtual address ffc0080ab980 [ 151.013077] Mem abort info: [ 151.015866] ESR = 0x9645 [ 151.018918] Exception class = DABT (current EL), IL = 32 bits [ 151.024830] SET = 0, FnV = 0 [ 151.027880] EA = 0, S1PTW = 0 [ 151.031016] Data abort info: [ 151.033892] ISV = 0, ISS = 0x0045 [ 151.037723] CM = 0, WnR = 1 [ 151.040691] swapper pgtable: 4k pages, 39-bit VAs, pgdp = 73b23692 [ 151.047560] [ffc0080ab980] pgd=, pud= [ 151.054354] Internal error: Oops: 9645 [#1] PREEMPT SMP [ 151.059925] Modules linked in: ath10k_sdio ath10k_core rfcomm uinput cros_ec_rpmsg mtk_cam_isp ath mac80211 mtk_fd hci_uart btqca bluetooth mtk_scp mtk_rpmsg rpmsg_core ecdh_generic mtk_scp_ipi bridge stp llc nf_nat_tftp nf_conntrack_tftp nf_nat_ftp nf_conntrack_ftp esp6 ah6 xfrm6_mode_tunnel xfrm6_mode_transport xfrm4_mode_tunnel xfrm4_mode_transport ip6t_REJECT ip6t_ipv6header ipt_MASQUERADE fuse cfg80211 iio_trig_sysfs cros_ec_sensors_sync cros_ec_sensors cros_ec_sensors_ring industrialio_triggered_buffer kfifo_buf cros_ec_sensors_core lzo_rle lzo_compress zram asix usbnet mii joydev [last unloaded: ath10k_core] [ 151.114537] Process swapper/0 (pid: 0, stack limit = 0xe30dc665) [ 151.121238] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.72 #11 [ 151.127327] Hardware name: MediaTek kukui rev1 board (DT) [ 151.132724] pstate: 2085 (nzCv daIf -PAN -UAO) [ 151.137525] pc : __memcpy+0x110/0x180 [ 151.141193] lr : swiotlb_tbl_unmap_single+0x84/0x150 [ 151.146151] sp : ff8008003c60 [ 151.149462] x29: ff8008003c90 x28: ffa2a9611f38 [ 151.154774] x27: ffa2a92cc018 x26: [ 151.160087] x25: ffa2a90b8000 x24: 0001 [ 151.165399] x23: ffa2a975e000 x22: 1400 [ 151.170710] x21: x20: fc7ff000 [ 151.176021] x19: 00f0 x18: 0020 [ 151.181332] x17: x16: [ 151.186643] x15: x14: [ 151.191955] x13: x12: [ 151.197266] x11: x10: [ 151.202578] x9 : x8 : [ 151.207890] x7 : x6 : ffc0080ab980 [ 151.213202] x5 : ff8016ffbdc8 x4 : [ 151.218514] x3 : 0002 x2 : 0070 [ 151.223825] x1 : fff37c7ff040 x0 : ffc0080ab980 [ 151.229138] Call trace: [ 151.231585] __memcpy+0x110/0x180 [ 151.234899] unmap_single+0x6c/0x84 [ 151.238386] swiotlb_unmap_sg_attrs+0x54/0x80 [ 151.242744] __swiotlb_unmap_sg_attrs+0xa0/0xb8 [ 151.247277] msdc_unprepare_data+0x6c/0x84 [ 151.251372] msdc_request_done+0x58/0x84 [ 151.255292] msdc_data_xfer_done+0x1a0/0x1c8 [ 151.259559] msdc_irq+0x12c/0x17c [ 151.262876] __handle_irq_event_percpu+0xe4/0x250 [ 151.267578] handle_irq_event_percpu+0x28/0x68 [ 151.272018] handle_irq_event+0x48/0x78 [ 151.275853] handle_fasteoi_irq+0xd0/0x1a0 [ 151.279948] __handle_domain_irq+0x84/0xc4 [ 151.284042] gic_handle_irq+0x124/0x1a4 [ 151.287875] el1_irq+0xb0/0x128 [ 151.291016] cpuidle_enter_state+0x298/0x328 [ 151.295282] cpuidle_enter+0x30/0x40 [ 151.298856] do_idle+0x190/0x270 [ 151.302081] cpu_startup_entry+0x24/0x28 [ 151.306005] rest_init+0xd4/0xe0 [ 151.309233] start_kernel+0x30c/0x38c [ 151.312896] Code: a8c12027 a8c12829 a8c1302b a8c1382d (a88120c7) [ 151.318987] ---[ end trace 4d779fa7753769c5 ]--- [ 151.342768] Kernel panic - not syncing: Fatal exception in interrupt [ 151.349134] SMP: stopping secondary CPUs [ 151.353074] Kernel Offset: 0x22a040 from 0xff800800 [ 151.358991] CPU features: 0x0,2188200c [ 151.362735] Memory Limit: none
Re: [PATCH v2] ath10k: add fw coredump for sdio when firmware assert
On 2019-09-21 19:35, Kalle Valo wrote: The commit log tells nothing about fast, it should always document the design decisions. Why this fast dump, what's the benefit? Why not always use the fast dump and forget the slow dump (or vice versa)? There needs to be really good reasons to have all this complexity to support both slow and fast dumps. fastdump is new added in fimrware of sdio, so if it is use old firmeare, then it will not support fastdump, then it need to use slow dump type. it is to compatibility for old/new version firmware. + ath10k_err(ar, "check fw reg : %x\n", param); +} This is a debug message, not an error. And debug messages should use format "sdio hi_option_flag2 %x\n".
Re: [PATCH V3 4/4] mac80211: Sync airtime weight sum with per AC synced sta airtime weight together
Yibo Zhao writes:
> Global airtime weight sum is updated only when txq is added/removed
> from rbtree. If upper layer configures sta weight during high load,
> airtime weight sum will not be updated since txq is most likely on the
> tree. It could a little late for upper layer to reconfigure sta weight
> when txq is already in the rbtree. And thus, incorrect airtime weight sum
> will lead to incorrect global virtual time calculation as well as overflow
> of airtime weight sum during txq removed.
>
> Hence, need to update airtime weight sum upon receiving event for
> configuring sta weight once sta's txq is on the rbtree.
>
> Besides, if airtime weight sum of ACs and sta weight is synced under the
> same per AC lock protection, there can be a very short window causing
> incorrct airtime weight sum calculation as below:
>
> active_txq_lock_VO .
> VO weight sum is syncd.
> sta airtime weight sum is synced .
> active_txq_unlock_VO .
> . .
> active_txq_lock_VI.
> VI weight sum is syncd.
> sta airtime weight sumactive_txq_lock_BE
> active_txq_unlock_VIRemove txq and thus sum
> . is calculated with synced
> . sta airtime weight
> . active_txq_unlock_BE
>
> So introduce a per ac synced station airtime weight synced with per
> AC synced weight sum together. And the per-AC station airtime weight
> is used to calculate weight sum.
>
> Signed-off-by: Yibo Zhao
> ---
> net/mac80211/cfg.c | 29 ++---
> net/mac80211/debugfs_sta.c | 2 +-
> net/mac80211/sta_info.c| 9 -
> net/mac80211/sta_info.h| 5 +++--
> net/mac80211/tx.c | 4 ++--
> 5 files changed, 36 insertions(+), 13 deletions(-)
>
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index d65aa01..c8a0683 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1284,7 +1284,8 @@ static int sta_apply_parameters(struct ieee80211_local
> *local,
> int ret = 0;
> struct ieee80211_supported_band *sband;
> struct ieee80211_sub_if_data *sdata = sta->sdata;
> - u32 mask, set;
> + u32 mask, set, tid, ac, pre_weight;
> + struct txq_info *txqi;
>
> sband = ieee80211_get_sband(sdata);
> if (!sband)
> @@ -1452,8 +1453,30 @@ static int sta_apply_parameters(struct ieee80211_local
> *local,
> if (ieee80211_vif_is_mesh(>vif))
> sta_apply_mesh_params(local, sta, params);
>
> - if (params->airtime_weight)
> - sta->airtime_weight = params->airtime_weight;
> + if (params->airtime_weight &&
> + params->airtime_weight != sta->airtime_weight) {
This check doesn't work I think? You're not using the array-based
sta->airtime_weight[], and there are locking issues by just checking
like this; so maybe just keep the if() on params->airtime_weight, and do
the checking inside the loop while holding the lock?
Or could we just turn the weights into atomics to avoid the locking
entirely?
> + for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
> + spin_lock_bh(>active_txq_lock[ac]);
> + for (tid = 0; tid < IEEE80211_NUM_TIDS + 1; tid++) {
> + if (!sta->sta.txq[tid] ||
> + ac != ieee80211_ac_from_tid(tid))
> + continue;
> +
> + pre_weight = sta->airtime_weight[ac];
> + sta->airtime_weight[ac] =
> + params->airtime_weight;
> +
> + txqi = to_txq_info(sta->sta.txq[tid]);
> + if (RB_EMPTY_NODE(>schedule_order))
> + continue;
> +
> + local->airtime_weight_sum[ac] =
> local->airtime_weight_sum[ac] +
> +
> params->airtime_weight -
> + pre_weight;
> + }
> + spin_unlock_bh(>active_txq_lock[ac]);
> + }
> + }
>
> /* set the STA state after all sta info from usermode has been set */
> if (test_sta_flag(sta, WLAN_STA_TDLS_PEER) ||
> diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
> index 80028da..43a7e6a 100644
> --- a/net/mac80211/debugfs_sta.c
> +++ b/net/mac80211/debugfs_sta.c
> @@ -223,7 +223,7 @@ static ssize_t sta_airtime_read(struct file *file, char
> __user *userbuf,
> "Virt-T: VO: %lld us VI: %lld us BE: %lld us BK: %lld us\n",
> rx_airtime,
> tx_airtime,
> - sta->airtime_weight,
> +
Re: [PATCH V3 2/4] mac80211: defer txqs removal from rbtree
Yibo Zhao writes: > In a loop txqs dequeue scenario, if the first txq in the rbtree gets > removed from rbtree immediately in the ieee80211_return_txq(), the > loop will break soon in the ieee80211_next_txq() due to schedule_pos > not leading to the second txq in the rbtree. Thus, defering the > removal right before the end of this schedule round. Didn't we agree that we could fix this by making __unschedule_txq() aware of schedule_pos instead of this deferred removal mechanism? -Toke ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH V3 3/4] mac80211: fix low throughput in multi-clients situation
Yibo Zhao writes: > Not long after the start of multi-clients test, not a single station is > an eligible candidate for transmission since global virtual time(g_vt) is > smaller than the virtual airtime(s_vt) of all the stations. As a result, > the Tx has been blocked and throughput is quite low. > > This may mainly due to sync mechanism and accumulative deviation from the > devision calculation of g_vt. > > For example: > Suppose we have 50 clients in first round. > Round 1: > STA weight Tx_time_round wt_sum s_vtg_vt valid_for_next_Tx > 1 256 204812800 20482000N > 2 256 20482048N > . . . . . > . . . . . > . . . . . > 50256 20482048N > > After this round, all the stations are not valid for next transmission due to > accumulative deviation. > > And if we add a new #51, > STA weight Tx_time_round wt_sum s_vtg_vt valid_for_next_Tx > 1 256 204813056 20482020N > 2 256 20482048N > . . . . > . . . . > . . . . > 50256 20482048N > 51256 10242524N That's better :) > Sync is done by: > max(g_vt of last round - grace period, s_vt) > and s_vt of #51 = max(2000 - 500, 0) + 1024 = 2524, and it is more than the > final > g_vt of this round. > > After this round, no more station is valid for transmission. > > The real situation can be more complicate, above is one of the extremely case. > > To avoid this situation to occur, the new proposal is: > > - Increase the airtime grace period a little more to reduce the > unexpected sync > > - If global virtual time is less than the virtual airtime of any station, > sync it to the airtime of first station in the red-black tree > > - Round the division result I can see why we need the second part (basically, this happens because I forgot to add a check for "no eligible stations" in may_transmit(), like the one in next_txq()). And rounding up the division result doesn't hurt, I guess. But why does it help to change the grace period if we're doing all the other stuff? -Toke
Re: [PATCH 2/4] mac80211: defer txqs removal from rbtree
Yibo Zhao writes:
> On 2019-09-21 22:00, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> On 2019-09-21 21:02, Toke Høiland-Jørgensen wrote:
Yibo Zhao writes:
> On 2019-09-21 19:27, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> On 2019-09-20 17:15, Toke Høiland-Jørgensen wrote:
Yibo Zhao writes:
> On 2019-09-19 18:37, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> On 2019-09-18 19:23, Toke Høiland-Jørgensen wrote:
Yibo Zhao writes:
> On 2019-09-18 05:10, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> In a loop txqs dequeue scenario, if the first txq in the
>>> rbtree
>>> gets
>>> removed from rbtree immediately in the
>>> ieee80211_return_txq(),
>>> the
>>> loop will break soon in the ieee80211_next_txq() due to
>>> schedule_pos
>>> not leading to the second txq in the rbtree. Thus,
>>> defering
>>> the
>>> removal right before the end of this schedule round.
>>>
>>> Co-developed-by: Yibo Zhao
>>> Signed-off-by: Yibo Zhao
>>> Signed-off-by: Toke Høiland-Jørgensen
>>
>> I didn't write this patch, so please don't use my sign-off.
>> I'll
>> add
>> ack or review tags as appropriate in reply; but a few
>> comments
>> first:
>>
>>> ---
>>> include/net/mac80211.h | 16 ++--
>>> net/mac80211/ieee80211_i.h | 3 +++
>>> net/mac80211/main.c| 6 +
>>> net/mac80211/tx.c | 63
>>> +++---
>>> 4 files changed, 83 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/include/net/mac80211.h
>>> b/include/net/mac80211.h
>>> index ac2ed8e..ba5a345 100644
>>> --- a/include/net/mac80211.h
>>> +++ b/include/net/mac80211.h
>>> @@ -925,6 +925,8 @@ struct ieee80211_tx_rate {
>>>
>>> #define IEEE80211_MAX_TX_RETRY 31
>>>
>>> +#define IEEE80211_AIRTIME_TXQ_RM_CHK_INTV_IN_MS 100
>>> +
>>> static inline void ieee80211_rate_set_vht(struct
>>> ieee80211_tx_rate
>>> *rate,
>>> u8 mcs, u8 nss)
>>> {
>>> @@ -6232,7 +6234,8 @@ struct sk_buff
>>> *ieee80211_tx_dequeue(struct
>>> ieee80211_hw *hw,
>>> * @ac: AC number to return packets from.
>>> *
>>> * Should only be called between calls to
>>> ieee80211_txq_schedule_start()
>>> - * and ieee80211_txq_schedule_end().
>>> + * and ieee80211_txq_schedule_end(). If the txq is empty,
>>> it
>>> will
>>> be
>>> added
>>> + * to a remove list and get removed later.
>>> * Returns the next txq if successful, %NULL if no queue
>>> is
>>> eligible.
>>> If a txq
>>> * is returned, it should be returned with
>>> ieee80211_return_txq()
>>> after the
>>> * driver has finished scheduling it.
>>> @@ -6268,7 +6271,8 @@ void
>>> ieee80211_txq_schedule_start(struct
>>> ieee80211_hw *hw, u8 ac)
>>> * @hw: pointer as obtained from ieee80211_alloc_hw()
>>> * @ac: AC number to acquire locks for
>>> *
>>> - * Release locks previously acquired by
>>> ieee80211_txq_schedule_end().
>>> + * Release locks previously acquired by
>>> ieee80211_txq_schedule_end().
>>> Check
>>> + * and remove the empty txq from rb-tree.
>>> */
>>> void ieee80211_txq_schedule_end(struct ieee80211_hw *hw,
>>> u8
>>> ac)
>>> __releases(txq_lock);
>>> @@ -6287,6 +6291,14 @@ void ieee80211_schedule_txq(struct
>>> ieee80211_hw
>>> *hw, struct ieee80211_txq *txq)
>>> __acquires(txq_lock) __releases(txq_lock);
>>>
>>> /**
>>> + * ieee80211_txqs_check - Check txqs waiting for removal
>>> + *
>>> + * @tmr: pointer as obtained from local
>>> + *
>>> + */
>>> +void ieee80211_txqs_check(struct timer_list *tmr);
>>> +
>>> +/**
>>> * ieee80211_txq_may_transmit - check whether TXQ is
Re: [PATCH v5 4/8] ath10k: add workqueue for RX path of sdio
Wen Gong writes:
> The thread of read rx message by sdio bus from firmware is
> synchronous, it will cost much time for process the left part
> of rx message which includes indicate the rx packet to uppper
> net stack. It will reduce the time of read from sdio.
This paragraph is hard to read.
> This patch move the indication to a workqueue, it results in
> significant performance improvement on RX path.
How much is "significant"? Some numbers would make it a lot easier to
understand the importance of the changes.
> Tested with QCA6174 SDIO with firmware
> WLAN.RMH.4.4.1-7-QCARMSWP-1.
>
> Signed-off-by: Wen Gong
[...]
> +static struct ath10k_sdio_rx_request *ath10k_sdio_alloc_rx_req(struct ath10k
> *ar)
> +{
> + struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> + struct ath10k_sdio_rx_request *rx_req;
> +
> + spin_lock_bh(_sdio->rx_lock);
> +
> + if (list_empty(_sdio->rx_req_freeq)) {
> + rx_req = NULL;
> + ath10k_dbg(ar, ATH10K_DBG_SDIO, "rx_req alloc fail\n");
> + goto out;
> + }
> +
> + rx_req = list_first_entry(_sdio->rx_req_freeq,
> + struct ath10k_sdio_rx_request, list);
> + list_del(_req->list);
> +
> +out:
> + spin_unlock_bh(_sdio->rx_lock);
> + return rx_req;
> +}
The name of the function is "alloc" but it does not allocate anything?
> +static void ath10k_sdio_free_rx_req(struct ath10k *ar,
> + struct ath10k_sdio_rx_request *rx_req)
> +{
> + struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> +
> + memset(rx_req, 0, sizeof(*rx_req));
> +
> + spin_lock_bh(_sdio->rx_lock);
> + list_add_tail(_req->list, _sdio->rx_req_freeq);
> + spin_unlock_bh(_sdio->rx_lock);
> +}
And this neither frees anything. IMHO that's quite misleading naming.
Maybe call _get() and _put()? Or maybe there's some more common naming
in kernel?
> +static int ath10k_sdio_prep_async_rx_req(struct ath10k *ar,
> + struct sk_buff *skb,
> + struct ath10k_htc_ep *ep)
> +{
> + struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> + struct ath10k_sdio_rx_request *rx_req;
> +
> + /* Allocate a rx request for the message and queue it on the
> + * SDIO rx workqueue.
> + */
> + rx_req = ath10k_sdio_alloc_rx_req(ar);
> + if (!rx_req) {
> + ath10k_warn(ar, "unable to allocate rx request for async
> request\n");
> + return -ENOMEM;
> + }
> +
> + rx_req->skb = skb;
> + rx_req->ep = ep;
> +
> + spin_lock_bh(_sdio->wr_async_lock_rx);
> + list_add_tail(_req->list, _sdio->wr_asyncq_rx);
> + spin_unlock_bh(_sdio->wr_async_lock_rx);
> +
> + return 0;
> +}
Is there enough room in struct ath10k_skb_cb so that you could add
struct ath10k_htc_ep there? That way struct ath10k_sdio_rx_request would
be useless and you could just use skb_queue_*() functions, which would
make this patch a lot simpler.
> @@ -209,6 +224,11 @@ struct ath10k_sdio {
> struct list_head wr_asyncq;
> /* protects access to wr_asyncq */
> spinlock_t wr_async_lock;
> +
> + struct work_struct wr_async_work_rx;
> + struct list_head wr_asyncq_rx;
> + /* protects access to wr_asyncq_rx */
> + spinlock_t wr_async_lock_rx;
> };
I think the naming is now confusing. I'm guessing "wr_async_lock" means
"write asynchronous lock"? So what is wr_asyncq_rx then? It would a lot
simpler if we have tx_lock and rx_lock, or something like that.
Naturally all cleanup for wr_async_lock needs to be done in a separate
patch.
--
Kalle Valo
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
ath10k-firmware: QCA4019 hw1.0: Update 8devices Habanero specific BDFs
Hi, I am currently working on the 8devices Habanero support for OpenWrt. This AP requires two special BDFs to get the Wi-Fi PHYs working (correctly). The bmi-board-id='s would clash with one of the the IPQ401X AP-DK boards because QCA doesn't provide special IDs for customers and seems to use the AP-DK board-ids in the wifi firmware to change its behavior. This update improves 5GHz radio. Now to the questions from the wiki page [1]: * description for what hardware this is: - it is a QCA4019 based module - one QCA4019 radio is used as 2.4GHz radio - one QCA4019 radio is used as 5GHz radio * origin of the board file (did you create it yourself or where you downloaded) - it was pulled from the 8devices OpenWrt fork - it is based on latest version * ids to be used with the board file (ATH10K_BD_IE_BOARD_NAME in ath10k) - QCA4019 hw1.0 + bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=8devices-Habanero md5sum: 64d0817da715875483d323f2bb0c898c + bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=8devices-Habanero md5sum: 56202ea33e96f16c65b75d464451c251 * attach the actual board file (board.bin) - The name of the files are equal to the id string in the board-2.bin (minus the ".bin") Kind regards, Robert Marko [1] https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=8devices-Habanero.bin Description: Binary data bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=8devices-Habanero.bin Description: Binary data ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v5 8/8] ath10k: enable napi on RX path for sdio
Wen Gong writes: > For tcp RX, the quantity of tcp acks to remote is 1/2 of the quantity > of tcp data from remote, then it will have many small length packets > on TX path of sdio bus, then it reduce the RX packets's bandwidth of > tcp. > > This patch enable napi on RX path, then the RX packet of tcp will not > feed to tcp stack immeditely from mac80211 since GRO is enabled by > default, it will feed to tcp stack after napi complete, if rx bundle > is enabled, then it will feed to tcp stack one time for each bundle > of RX. For example, RX bundle size is 32, then tcp stack will receive > one large length packet, its length is neary 1500*32, then tcp stack > will send a tcp ack for this large packet, this will reduce the tcp > acks ratio from 1/2 to 1/32. This results in significant performance > improvement for tcp RX. > > Tcp rx throughout is 240Mbps without this patch, and it arrive 390Mbps > with this patch. The cpu usage has no obvious difference with and > without NAPI. > > call stack for each RX packet on GRO path: > (skb length is about 1500 bytes) > skb_gro_receive ([kernel.kallsyms]) > tcp4_gro_receive ([kernel.kallsyms]) > inet_gro_receive ([kernel.kallsyms]) > dev_gro_receive ([kernel.kallsyms]) > napi_gro_receive ([kernel.kallsyms]) > ieee80211_deliver_skb ([mac80211]) > ieee80211_rx_handlers ([mac80211]) > ieee80211_prepare_and_rx_handle ([mac80211]) > ieee80211_rx_napi ([mac80211]) > ath10k_htt_rx_proc_rx_ind_hl ([ath10k_core]) > ath10k_htt_rx_pktlog_completion_handler ([ath10k_core]) > ath10k_sdio_napi_poll ([ath10k_sdio]) > net_rx_action ([kernel.kallsyms]) > softirqentry_text_start ([kernel.kallsyms]) > do_softirq ([kernel.kallsyms]) > > call stack for napi complete and send tcp ack from tcp stack: > (skb length is about 1500*32 bytes) > _tcp_ack_snd_check ([kernel.kallsyms]) > tcp_v4_do_rcv ([kernel.kallsyms]) > tcp_v4_rcv ([kernel.kallsyms]) > local_deliver_finish ([kernel.kallsyms]) > ip_local_deliver ([kernel.kallsyms]) > ip_rcv_finish ([kernel.kallsyms]) > ip_rcv ([kernel.kallsyms]) > netif_receive_skb_core ([kernel.kallsyms]) > netif_receive_skb_one_core([kernel.kallsyms]) > netif_receive_skb ([kernel.kallsyms]) > netif_receive_skb_internal ([kernel.kallsyms]) > napi_gro_complete ([kernel.kallsyms]) > napi_gro_flush ([kernel.kallsyms]) > napi_complete_done ([kernel.kallsyms]) > ath10k_sdio_napi_poll ([ath10k_sdio]) > net_rx_action ([kernel.kallsyms]) > __softirqentry_text_start ([kernel.kallsyms]) > do_softirq ([kernel.kallsyms]) > > Tested with QCA6174 SDIO with firmware > WLAN.RMH.4.4.1-7-QCARMSWP-1. > > Signed-off-by: Wen Gong [...] > --- a/drivers/net/wireless/ath/ath10k/htt_rx.c > +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c > @@ -2263,7 +2263,7 @@ static bool ath10k_htt_rx_proc_rx_ind_hl(struct > ath10k_htt *htt, > if (mpdu_ranges->mpdu_range_status == > HTT_RX_IND_MPDU_STATUS_TKIP_MIC_ERR) > rx_status->flag |= RX_FLAG_MMIC_ERROR; > > - ieee80211_rx_ni(ar->hw, skb); > + ieee80211_rx_napi(ar->hw, NULL, skb, >napi); Doesn't this break USB? -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v5 3/8] ath10k: change max RX bundle size from 8 to 32 for sdio
Wen Gong writes:
> The max bundle size support by firmware is 32, change it from 8 to 32
> will help performance. This results in significant performance
> improvement on RX path.
>
> Tested with QCA6174 SDIO with firmware
> WLAN.RMH.4.4.1-7-QCARMSWP-1.
>
> Signed-off-by: Wen Gong
[...]
> --- a/drivers/net/wireless/ath/ath10k/htc.h
> +++ b/drivers/net/wireless/ath/ath10k/htc.h
> @@ -39,7 +39,7 @@
> * 4-byte aligned.
> */
>
> -#define HTC_HOST_MAX_MSG_PER_RX_BUNDLE8
> +#define HTC_HOST_MAX_MSG_PER_RX_BUNDLE32
>
> enum ath10k_htc_tx_flags {
> ATH10K_HTC_FLAG_NEED_CREDIT_UPDATE = 0x01,
> @@ -48,10 +48,16 @@ enum ath10k_htc_tx_flags {
>
> enum ath10k_htc_rx_flags {
> ATH10K_HTC_FLAGS_RECV_1MORE_BLOCK = 0x01,
> - ATH10K_HTC_FLAG_TRAILER_PRESENT = 0x02,
> - ATH10K_HTC_FLAG_BUNDLE_MASK = 0xF0
> + ATH10K_HTC_FLAG_TRAILER_PRESENT = 0x02
> };
>
> +#define ATH10K_HTC_FLAG_BUNDLE_MASK 0xF0
> +#define ATH10K_HTC_BUNDLE_EXTRA_MASK GENMASK(3, 2)
> +
> +#define ATH10K_HTC_GET_BUNDLE_COUNT(flags) \
> + (FIELD_GET(ATH10K_HTC_FLAG_BUNDLE_MASK, (flags)) + \
> + (FIELD_GET(ATH10K_HTC_BUNDLE_EXTRA_MASK, (flags)) << 4))
When using FIELD_GET() there should be no need to use '<<', the main id
of FIELD_GET() and BITMASK() is that there's no need do any manual
shifting. So I suspect something is wrong here, but didn't have time to
investigate.
--
Kalle Valo
Re: [PATCH] ath10k: fix memory leak
Navid Emamdoost wrote: > In ath10k_usb_hif_tx_sg the allocated urb should be released if > usb_submit_urb fails. > > Signed-off-by: Navid Emamdoost > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. b8d17e7d93d2 ath10k: fix memory leak -- https://patchwork.kernel.org/patch/11153699/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: fix memory leak
Navid Emamdoost wrote: > In ath10k_usb_hif_tx_sg the allocated urb should be released if > usb_submit_urb fails. > > Signed-off-by: Navid Emamdoost > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. b8d17e7d93d2 ath10k: fix memory leak -- https://patchwork.kernel.org/patch/11153699/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] ath10k: remove the warning of sdio not full support
Wen Gong wrote: > Recently, it has the basic feature of sdio tested success, so remove > it. > > Tested with QCA6174 SDIO with firmware > WLAN.RMH.4.4.1-00017-QCARMSWP-1. > > Signed-off-by: Wen Gong > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 35cc054d944e ath10k: remove the warning of sdio not full support -- https://patchwork.kernel.org/patch/11135025/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: remove the warning of sdio not full support
Wen Gong wrote: > Recently, it has the basic feature of sdio tested success, so remove > it. > > Tested with QCA6174 SDIO with firmware > WLAN.RMH.4.4.1-00017-QCARMSWP-1. > > Signed-off-by: Wen Gong > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 35cc054d944e ath10k: remove the warning of sdio not full support -- https://patchwork.kernel.org/patch/11135025/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH][next] ath: fix various spelling mistakes
Colin King wrote: > There are a bunch of spelling mistakes in two ath drivers, fix > these. > > Signed-off-by: Colin Ian King > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 80ce8ca7a647 ath: fix various spelling mistakes -- https://patchwork.kernel.org/patch/11027799/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH][next] ath: fix various spelling mistakes
Colin King wrote: > There are a bunch of spelling mistakes in two ath drivers, fix > these. > > Signed-off-by: Colin Ian King > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 80ce8ca7a647 ath: fix various spelling mistakes -- https://patchwork.kernel.org/patch/11027799/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 1/2] ath10k: Fix rate table updation in tx stats
Rakesh Pillai wrote:
> The index for updating rate table, which is displayed
> in the tx stats via debugfs, is calculated using the
> bandwidth value. The bandwidth values do not map
> correctly with the bandwidth values shown in the rate table.
>
> Correct the bandwidth value calculation which is used
> to calculate the index for rate table updation for tx stats.
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
>
> Fixes: e88975ca37d1 ("ath10k: dump tx stats in rate table format")
> Signed-off-by: Rakesh Pillai
> Signed-off-by: Kalle Valo
I requested Surabhi to include these patches into his patchset, due to the
dependency.
https://patchwork.kernel.org/project/linux-wireless/list/?series=85455=*=date
2 patches set to Changes Requested.
10847733 [1/2] ath10k: Fix rate table updation in tx stats
10847737 [2/2] ath10k: Fix NSS tx stats for legacy rates
--
https://patchwork.kernel.org/patch/10847733/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 1/2] ath10k: Fix rate table updation in tx stats
Rakesh Pillai wrote:
> The index for updating rate table, which is displayed
> in the tx stats via debugfs, is calculated using the
> bandwidth value. The bandwidth values do not map
> correctly with the bandwidth values shown in the rate table.
>
> Correct the bandwidth value calculation which is used
> to calculate the index for rate table updation for tx stats.
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
>
> Fixes: e88975ca37d1 ("ath10k: dump tx stats in rate table format")
> Signed-off-by: Rakesh Pillai
> Signed-off-by: Kalle Valo
I requested Surabhi to include these patches into his patchset, due to the
dependency.
https://patchwork.kernel.org/project/linux-wireless/list/?series=85455=*=date
2 patches set to Changes Requested.
10847733 [1/2] ath10k: Fix rate table updation in tx stats
10847737 [2/2] ath10k: Fix NSS tx stats for legacy rates
--
https://patchwork.kernel.org/patch/10847733/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 0/2] Add support for per peer HTT tx stats for WCN3990
Surabhi Vishnoi writes: > WCN3990 firmware sends the HTT_TLV_T2H_MSG_TYPE_PEER_STATS in tlv > format so the handling of this message has to be done in different > manner. > > This patchset adds support to attach rx_ops based on htt version > and adds the handling of HTT_TLV_T2H_MSG_TYPE_PEER_STATS message > based on HTT version. > > Surabhi Vishnoi (2): > ath10k: Add support for adding htt_rx_ops based on htt_version > ath10k: Add support for per peer HTT tx stats for WCN3990 When you resubmit, could you please include Rakesh's fixes in the same patchset: ath10k: Fix rate table updation in tx stats ath10k: Fix NSS tx stats for legacy rates https://patchwork.kernel.org/project/linux-wireless/list/?series=90199=*=date They depend on this patchset, so it's easier to handle them all together. -- Kalle Valo
Re: [PATCH] net: ath: fix missing checks for bmi reads and writes
Kangjie Lu wrote: > ath10k_bmi_write32 and ath10k_bmi_read32 can fail. The fix > checks their statuses to avoid potential undefined behaviors. > > Signed-off-by: Kangjie Lu > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 8da96730331d ath10k: fix missing checks for bmi reads and writes -- https://patchwork.kernel.org/patch/10854069/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 2/2] ath10k: Add support for per peer HTT tx stats for WCN3990
Surabhi Vishnoi writes: > The firmware sends peer stats to the host driver if the firmware > advertises WMI_SERVICE_PEER_STATS service and the host driver > indicates the WMI_RSRC_CFG_FLAG_TX_PEER_STATS capability in the > host capab flag in wmi init cmd. > > When peer stats are enabled, firmware sends one HTT event > HTT_TLV_T2H_MSG_TYPE_PEER_STATS for every four PPDUs transmitted. > HTT msg payload has tag followed by length followed by > success pkts/bytes, failed pkts/bytes, retry pkts/bytes and rate > info per ppdu. > > Parse peer stats sent by the firmware in tlv format and update the > tx rate information and tx_stats debugfs entry per STA. > > To get the tx_stats: > echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/enable_extd_tx_stats > cat > /sys/kernel/debug/ieee80211/phyX/net:wlanX/stations/xx:xx:xx:xx:xx:xx/tx_stats > > Tested HW: WCN3990 > Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1 > > Signed-off-by: Surabhi Vishnoi [...] > @@ -3438,7 +3566,7 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, > struct sk_buff *skb) > ath10k_htt_rx_tx_mode_switch_ind(ar, skb); > break; > case HTT_T2H_MSG_TYPE_PEER_STATS: > - ath10k_htt_fetch_peer_stats(ar, skb); > + htt->rx_ops->htt_fetch_peer_stats(ar, skb); > break; I think this belongs to patch 1. > +#define ATH10K_HW_GI_MASKGENMASK(5, 5) BIT(5) > +#define ATH10K_HW_SKIPPED_RATE_CTRL_MASK GENMASK(6, 6) BIT(6) > +#define ATH10K_HW_WCN3990_GI_MASKGENMASK(6, 6) BIT(6) > +#define ATH10K_HW_WCN3990_SKIPPED_RATE_CTRL_MASK GENMASK(7, 7) BIT(7) -- Kalle Valo
Re: [PATCH 1/2] ath10k: Add support for adding htt_rx_ops based on htt_version
Surabhi Vishnoi writes:
> Refactor the code to add the support to attach htt_rx_ops
> based on HTT version.
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
>
> Signed-off-by: Surabhi Vishnoi
[...]
> @@ -3572,7 +3580,7 @@ int ath10k_htt_txrx_compl_task(struct ath10k *ar, int
> budget)
> .htt_reset_paddrs_ring = ath10k_htt_reset_paddrs_ring_64,
> };
>
> -static const struct ath10k_htt_rx_ops htt_rx_ops_hl = {
> +static struct ath10k_htt_rx_ops htt_rx_ops_hl = {
> };
>
> void ath10k_htt_set_rx_ops(struct ath10k_htt *htt)
> @@ -3585,4 +3593,19 @@ void ath10k_htt_set_rx_ops(struct ath10k_htt *htt)
> htt->rx_ops = _rx_ops_64;
> else
> htt->rx_ops = _rx_ops_32;
> +
> + switch (ar->running_fw->fw_file.htt_op_version) {
> + case ATH10K_FW_HTT_OP_VERSION_MAIN:
> + case ATH10K_FW_HTT_OP_VERSION_10_1:
> + case ATH10K_FW_HTT_OP_VERSION_10_4:
> + htt->rx_ops->htt_fetch_peer_stats = ath10k_htt_fetch_peer_stats;
> + break;
> + case ATH10K_FW_HTT_OP_VERSION_TLV:
> + htt->rx_ops->htt_fetch_peer_stats =
> ath10k_htt_fetch_peer_stats_tlv;
> + break;
> + case ATH10K_FW_HTT_OP_VERSION_MAX:
> + case ATH10K_FW_HTT_OP_VERSION_UNSET:
> + WARN_ON(1);
> + return;
> + }
> }
I just realised this won't work. Let's say that there's both a qca988x
and a qca6174 PCI device on the same host. Then htt->rx_ops is shared by
_both_ devices and the htt_fetch_peer_stats field will contain the value
of the last initialised ath10k device.
So back to the drawing board. As this feature is for wcn3990 would it be
enough to modify htt_rx_ops_64? IIRC only wcn3990 support 64bit HTT
interface, right? Of course then qca6174 won't support this feature, but
does the qca6174 firmware even support that?
--
Kalle Valo
Re: [PATCH v3] ath10k: Add support to provide higher range mem chunks in wmi init command
Surabhi Vishnoi wrote: > With the current implementation of wmi init command, > there is no provision for the host driver to provide mem > chunks addresses with more than 32-bit, to the firmware. > WCN3990 is a 35-bit target and can accept mem chunks addresses > which are above 32-bit. > > If firmware supports address range more than 32 bit, it > advertises the support by setting the WMI_SERVICE_EXTEND_ADDRESS > service. Based on this service fill the upper bits of paddr while > providing the mem chunks in the wmi init command. > > Tested HW: WCN3990 > Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1 > > Signed-off-by: Surabhi Vishnoi > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 40f4ef5e9232 ath10k: Add support to provide higher range mem chunks in wmi init command -- https://patchwork.kernel.org/patch/10828535/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v3] ath10k: Add support to provide higher range mem chunks in wmi init command
Surabhi Vishnoi wrote: > With the current implementation of wmi init command, > there is no provision for the host driver to provide mem > chunks addresses with more than 32-bit, to the firmware. > WCN3990 is a 35-bit target and can accept mem chunks addresses > which are above 32-bit. > > If firmware supports address range more than 32 bit, it > advertises the support by setting the WMI_SERVICE_EXTEND_ADDRESS > service. Based on this service fill the upper bits of paddr while > providing the mem chunks in the wmi init command. > > Tested HW: WCN3990 > Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1 > > Signed-off-by: Surabhi Vishnoi > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 40f4ef5e9232 ath10k: Add support to provide higher range mem chunks in wmi init command -- https://patchwork.kernel.org/patch/10828535/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 2/2] ath10k: correct wmi_tlv command params to enable pktlog for WCN3990
Kalle Valo writes:
> Abhishek Ambure wrote:
>
>> PKT log enable command expects pdev id in enable params which is missing
>> in current configuration. Fill pdev id in pkt log enable wmi command for
>> correct configuration.
>>
>> Fixes: ca996ec56608 ("ath10k: implement wmi-tlv backend")
>> Tested HW: WCN3990
>> Tested FW: WLAN.HL.3.1-00963-QCAHLSWMTPL-1
>>
>> Signed-off-by: Abhishek Ambure
>> Signed-off-by: Kalle Valo
>
> How do I know this doesn't break QCA6174/QCA9377?
Abhishek mentioned me privately that he is checking this.
--
Kalle Valo
Re: [PATCH] ath10k: Add peer param map for tlv and non-tlv
Rakesh Pillai wrote: > The peer param id for PEER_PARAM_USE_FIXED_PWR > is different for tlv and non-tlv firmware. This > causes incorrect peer param to be set by the driver > to the firmware(tlv/non-tlv). > > Create seperate peer param map for tlv and non-tlv > firmware and attach the peer param id based on the > firmware type during the init. > > Tested HW: WCN3990 > Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1 > > Signed-off-by: Rakesh Pillai > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. c0e33fe6fb0f ath10k: Add peer param map for tlv and non-tlv -- https://patchwork.kernel.org/patch/10819255/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: Add peer param map for tlv and non-tlv
Rakesh Pillai wrote: > The peer param id for PEER_PARAM_USE_FIXED_PWR > is different for tlv and non-tlv firmware. This > causes incorrect peer param to be set by the driver > to the firmware(tlv/non-tlv). > > Create seperate peer param map for tlv and non-tlv > firmware and attach the peer param id based on the > firmware type during the init. > > Tested HW: WCN3990 > Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1 > > Signed-off-by: Rakesh Pillai > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. c0e33fe6fb0f ath10k: Add peer param map for tlv and non-tlv -- https://patchwork.kernel.org/patch/10819255/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH V3 4/4] mac80211: Sync airtime weight sum with per AC synced sta airtime weight together
Global airtime weight sum is updated only when txq is added/removed
from rbtree. If upper layer configures sta weight during high load,
airtime weight sum will not be updated since txq is most likely on the
tree. It could a little late for upper layer to reconfigure sta weight
when txq is already in the rbtree. And thus, incorrect airtime weight sum
will lead to incorrect global virtual time calculation as well as overflow
of airtime weight sum during txq removed.
Hence, need to update airtime weight sum upon receiving event for
configuring sta weight once sta's txq is on the rbtree.
Besides, if airtime weight sum of ACs and sta weight is synced under the
same per AC lock protection, there can be a very short window causing
incorrct airtime weight sum calculation as below:
active_txq_lock_VO .
VO weight sum is syncd .
sta airtime weight sum is synced.
active_txq_unlock_VO.
. .
active_txq_lock_VI .
VI weight sum is syncd .
sta airtime weight sum active_txq_lock_BE
active_txq_unlock_VI Remove txq and thus sum
. is calculated with synced
. sta airtime weight
. active_txq_unlock_BE
So introduce a per ac synced station airtime weight synced with per
AC synced weight sum together. And the per-AC station airtime weight
is used to calculate weight sum.
Signed-off-by: Yibo Zhao
---
net/mac80211/cfg.c | 29 ++---
net/mac80211/debugfs_sta.c | 2 +-
net/mac80211/sta_info.c| 9 -
net/mac80211/sta_info.h| 5 +++--
net/mac80211/tx.c | 4 ++--
5 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index d65aa01..c8a0683 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1284,7 +1284,8 @@ static int sta_apply_parameters(struct ieee80211_local
*local,
int ret = 0;
struct ieee80211_supported_band *sband;
struct ieee80211_sub_if_data *sdata = sta->sdata;
- u32 mask, set;
+ u32 mask, set, tid, ac, pre_weight;
+ struct txq_info *txqi;
sband = ieee80211_get_sband(sdata);
if (!sband)
@@ -1452,8 +1453,30 @@ static int sta_apply_parameters(struct ieee80211_local
*local,
if (ieee80211_vif_is_mesh(>vif))
sta_apply_mesh_params(local, sta, params);
- if (params->airtime_weight)
- sta->airtime_weight = params->airtime_weight;
+ if (params->airtime_weight &&
+ params->airtime_weight != sta->airtime_weight) {
+ for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
+ spin_lock_bh(>active_txq_lock[ac]);
+ for (tid = 0; tid < IEEE80211_NUM_TIDS + 1; tid++) {
+ if (!sta->sta.txq[tid] ||
+ ac != ieee80211_ac_from_tid(tid))
+ continue;
+
+ pre_weight = sta->airtime_weight[ac];
+ sta->airtime_weight[ac] =
+ params->airtime_weight;
+
+ txqi = to_txq_info(sta->sta.txq[tid]);
+ if (RB_EMPTY_NODE(>schedule_order))
+ continue;
+
+ local->airtime_weight_sum[ac] =
local->airtime_weight_sum[ac] +
+
params->airtime_weight -
+ pre_weight;
+ }
+ spin_unlock_bh(>active_txq_lock[ac]);
+ }
+ }
/* set the STA state after all sta info from usermode has been set */
if (test_sta_flag(sta, WLAN_STA_TDLS_PEER) ||
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index 80028da..43a7e6a 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -223,7 +223,7 @@ static ssize_t sta_airtime_read(struct file *file, char
__user *userbuf,
"Virt-T: VO: %lld us VI: %lld us BE: %lld us BK: %lld us\n",
rx_airtime,
tx_airtime,
- sta->airtime_weight,
+ sta->airtime_weight[0],
v_t[0],
v_t[1],
v_t[2],
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index feac975..e599cf1 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -384,11 +384,10 @@ struct sta_info *sta_info_alloc(struct
ieee80211_sub_if_data *sdata,
if (sta_prepare_rate_control(local, sta, gfp))
goto free_txq;
- sta->airtime_weight =
[PATCH V3 3/4] mac80211: fix low throughput in multi-clients situation
Not long after the start of multi-clients test, not a single station is
an eligible candidate for transmission since global virtual time(g_vt) is
smaller than the virtual airtime(s_vt) of all the stations. As a result,
the Tx has been blocked and throughput is quite low.
This may mainly due to sync mechanism and accumulative deviation from the
devision calculation of g_vt.
For example:
Suppose we have 50 clients in first round.
Round 1:
STA weight Tx_time_round wt_sum s_vtg_vt valid_for_next_Tx
1 256 204812800 20482000N
2 256 20482048N
. . . . .
. . . . .
. . . . .
50 256 20482048N
After this round, all the stations are not valid for next transmission due to
accumulative deviation.
And if we add a new #51,
STA weight Tx_time_round wt_sum s_vtg_vt valid_for_next_Tx
1 256 204813056 20482020N
2 256 20482048N
. . . .
. . . .
. . . .
50 256 20482048N
51 256 10242524N
Sync is done by:
max(g_vt of last round - grace period, s_vt)
and s_vt of #51 = max(2000 - 500, 0) + 1024 = 2524, and it is more than the
final
g_vt of this round.
After this round, no more station is valid for transmission.
The real situation can be more complicate, above is one of the extremely case.
To avoid this situation to occur, the new proposal is:
- Increase the airtime grace period a little more to reduce the
unexpected sync
- If global virtual time is less than the virtual airtime of any station,
sync it to the airtime of first station in the red-black tree
- Round the division result
Signed-off-by: Yibo Zhao
---
net/mac80211/sta_info.c | 3 ++-
net/mac80211/sta_info.h | 2 +-
net/mac80211/tx.c | 16 +++-
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 9d01fdd..feac975 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1852,7 +1852,8 @@ void ieee80211_sta_register_airtime(struct ieee80211_sta
*pubsta, u8 tid,
weight_sum = local->airtime_weight_sum[ac] ?: sta->airtime_weight;
- local->airtime_v_t[ac] += airtime / weight_sum;
+ /* Round the calculation of global vt */
+ local->airtime_v_t[ac] += (airtime + (weight_sum >> 1)) / weight_sum;
sta->airtime[ac].v_t += airtime / sta->airtime_weight;
ieee80211_resort_txq(>hw, txq);
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 5c1cac9..5055f94 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -130,7 +130,7 @@ enum ieee80211_agg_stop_reason {
/* Debugfs flags to enable/disable use of RX/TX airtime in scheduler */
#define AIRTIME_USE_TX BIT(0)
#define AIRTIME_USE_RX BIT(1)
-#define AIRTIME_GRACE 500 /* usec of grace period before reset */
+#define AIRTIME_GRACE 2000 /* usec of grace period before reset */
struct airtime_info {
u64 rx_airtime;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 42ca010..60cf569 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3867,15 +3867,29 @@ bool ieee80211_txq_may_transmit(struct ieee80211_hw *hw,
struct ieee80211_txq *txq)
{
struct ieee80211_local *local = hw_to_local(hw);
- struct txq_info *txqi = to_txq_info(txq);
+ struct txq_info *first_txqi, *txqi = to_txq_info(txq);
+ struct rb_node *node = NULL;
struct sta_info *sta;
u8 ac = txq->ac;
+ first_txqi = NULL;
lockdep_assert_held(>active_txq_lock[ac]);
if (!txqi->txq.sta)
return true;
+ node = rb_first_cached(>active_txqs[ac]);
+ if (node) {
+ first_txqi = container_of(node, struct txq_info,
+ schedule_order);
+ if (first_txqi->txq.sta) {
+ sta = container_of(first_txqi->txq.sta,
+ struct sta_info, sta);
+ if (local->airtime_v_t[ac] < sta->airtime[ac].v_t)
+ local->airtime_v_t[ac] = sta->airtime[ac].v_t;
+ }
+ }
+
sta = container_of(txqi->txq.sta, struct sta_info, sta);
return (sta->airtime[ac].v_t <= local->airtime_v_t[ac]);
}
--
1.9.1
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH V3 1/4] mac80211: Switch to a virtual time-based airtime scheduler
From: Toke Høiland-Jørgensen
This switches the airtime scheduler in mac80211 to use a virtual time-based
scheduler instead of the round-robin scheduler used before. This has a
couple of advantages:
- No need to sync up the round-robin scheduler in firmware/hardware with
the round-robin airtime scheduler.
- If several stations are eligible for transmission we can schedule both of
them; no need to hard-block the scheduling rotation until the head of the
queue has used up its quantum.
- The check of whether a station is eligible for transmission becomes
simpler (in ieee80211_txq_may_transmit()).
The drawback is that scheduling becomes slightly more expensive, as we need
to maintain an rbtree of TXQs sorted by virtual time. This means that
ieee80211_register_airtime() becomes O(logN) in the number of currently
scheduled TXQs. However, hopefully this number rarely grows too big (it's
only TXQs currently backlogged, not all associated stations), so it
shouldn't be too big of an issue.
Signed-off-by: Toke Høiland-Jørgensen
---
net/mac80211/debugfs.c | 48 +-
net/mac80211/debugfs_sta.c | 16 ++--
net/mac80211/ieee80211_i.h | 14 ++-
net/mac80211/main.c| 2 +-
net/mac80211/sta_info.c| 19 +++-
net/mac80211/sta_info.h| 3 +-
net/mac80211/tx.c | 217 +
7 files changed, 223 insertions(+), 96 deletions(-)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 2d43bc1..4847168 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -150,6 +150,46 @@ static ssize_t aqm_write(struct file *file,
.llseek = default_llseek,
};
+static ssize_t airtime_read(struct file *file,
+ char __user *user_buf,
+ size_t count,
+ loff_t *ppos)
+{
+ struct ieee80211_local *local = file->private_data;
+ char buf[200];
+ u64 v_t[IEEE80211_NUM_ACS];
+ u64 wt[IEEE80211_NUM_ACS];
+ int len = 0, ac;
+
+ for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
+ spin_lock_bh(>active_txq_lock[ac]);
+ v_t[ac] = local->airtime_v_t[ac];
+ wt[ac] = local->airtime_weight_sum[ac];
+ spin_unlock_bh(>active_txq_lock[ac]);
+ }
+ len = scnprintf(buf, sizeof(buf),
+ "\tVO VI BE BK\n"
+ "Virt-t\t%-10llu %-10llu %-10llu %-10llu\n"
+ "Weight\t%-10llu %-10llu %-10llu %-10llu\n",
+ v_t[0],
+ v_t[1],
+ v_t[2],
+ v_t[3],
+ wt[0],
+ wt[1],
+ wt[2],
+ wt[3]);
+
+ return simple_read_from_buffer(user_buf, count, ppos,
+ buf, len);
+}
+
+static const struct file_operations airtime_ops = {
+ .read = airtime_read,
+ .open = simple_open,
+ .llseek = default_llseek,
+};
+
#ifdef CONFIG_PM
static ssize_t reset_write(struct file *file, const char __user *user_buf,
size_t count, loff_t *ppos)
@@ -386,8 +426,12 @@ void debugfs_hw_add(struct ieee80211_local *local)
if (local->ops->wake_tx_queue)
DEBUGFS_ADD_MODE(aqm, 0600);
- debugfs_create_u16("airtime_flags", 0600,
- phyd, >airtime_flags);
+ if (wiphy_ext_feature_isset(local->hw.wiphy,
+ NL80211_EXT_FEATURE_AIRTIME_FAIRNESS)) {
+ DEBUGFS_ADD_MODE(airtime, 0600);
+ debugfs_create_u16("airtime_flags", 0600,
+ phyd, >airtime_flags);
+ }
statsd = debugfs_create_dir("statistics", phyd);
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index 3aa618d..80028da 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -203,7 +203,7 @@ static ssize_t sta_airtime_read(struct file *file, char
__user *userbuf,
size_t bufsz = 200;
char *buf = kzalloc(bufsz, GFP_KERNEL), *p = buf;
u64 rx_airtime = 0, tx_airtime = 0;
- s64 deficit[IEEE80211_NUM_ACS];
+ u64 v_t[IEEE80211_NUM_ACS];
ssize_t rv;
int ac;
@@ -214,20 +214,20 @@ static ssize_t sta_airtime_read(struct file *file, char
__user *userbuf,
spin_lock_bh(>active_txq_lock[ac]);
rx_airtime += sta->airtime[ac].rx_airtime;
tx_airtime += sta->airtime[ac].tx_airtime;
- deficit[ac] = sta->airtime[ac].deficit;
+ v_t[ac] = sta->airtime[ac].v_t;
spin_unlock_bh(>active_txq_lock[ac]);
}
p += scnprintf(p, bufsz + buf - p,
"RX: %llu us\nTX: %llu us\nWeight: %u\n"
- "Deficit: VO: %lld us VI: %lld us BE: %lld us BK: %lld us\n",
+
[PATCH V3 0/4] Enable virtual time-based airtime scheduler support on ath10k
This series fix some issues when enabling virtual time-based airtime scheduler on ath10k. Changes since v2: Changes station airtime weight to be per-AC based to avoid sync issue Remove Co-developed-by and Toke's sign-off as Toke suggested Changes since v1: Modify the author of Co-developed-by as Johannes suggested Toke Høiland-Jørgensen (1): mac80211: Switch to a virtual time-based airtime scheduler Yibo Zhao (3): mac80211: defer txqs removal from rbtree mac80211: fix low throughput in multi-clients situation mac80211: Sync airtime weight sum with per AC synced sta airtime weight together include/net/mac80211.h | 16 ++- net/mac80211/cfg.c | 29 - net/mac80211/debugfs.c | 48 +++- net/mac80211/debugfs_sta.c | 18 +-- net/mac80211/ieee80211_i.h | 17 ++- net/mac80211/main.c| 8 +- net/mac80211/sta_info.c| 25 +++- net/mac80211/sta_info.h| 8 +- net/mac80211/tx.c | 282 + 9 files changed, 347 insertions(+), 104 deletions(-) -- 1.9.1
