| Message ID | 20170426220444.10539-1-bjorn.andersson@linaro.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | Andy Gross |
| Headers | show |
> @@ -371,7 +371,7 @@ static void reap_tx_dxes(struct wcn36xx *wcn, > struct wcn36xx_dxe_ch *ch) > info = IEEE80211_SKB_CB(ctl->skb); > if (!(info->flags & > IEEE80211_TX_CTL_REQ_TX_STATUS)) { > /* Keep frame until TX status comes > */ > - ieee80211_free_txskb(wcn->hw, ctl- > >skb); > + ieee80211_tx_status(wcn->hw, ctl- > >skb); > I don't think this is a good idea. This code intentionally checked if TX status was requested, and if not then it doesn't go to the effort of building it. As it is with your patch, it'll go and report the TX status without any TX status information - which is handled in wcn36xx_dxe_tx_ack_ind() for those frames needing it. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu 27 Apr 01:22 PDT 2017, Johannes Berg wrote: > > > @@ -371,7 +371,7 @@ static void reap_tx_dxes(struct wcn36xx *wcn, > > struct wcn36xx_dxe_ch *ch) > > info = IEEE80211_SKB_CB(ctl->skb); > > if (!(info->flags & > > IEEE80211_TX_CTL_REQ_TX_STATUS)) { > > /* Keep frame until TX status comes > > */ > > - ieee80211_free_txskb(wcn->hw, ctl- > > >skb); > > + ieee80211_tx_status(wcn->hw, ctl- > > >skb); > > > > I don't think this is a good idea. Thanks for letting me know :) > This code intentionally checked if TX status was requested, and if not > then it doesn't go to the effort of building it. > What I'm finding puzzling is the fact that the only caller of ieee80211_led_tx() is ieee80211_tx_status() and it seems like drivers, such as ath10k, call this for each packet handled - but I'm likely missing something. > As it is with your patch, it'll go and report the TX status without any > TX status information - which is handled in wcn36xx_dxe_tx_ack_ind() > for those frames needing it. > Right, it doesn't sound desired. However, during normal operation I'm not seeing IEEE80211_TX_CTL_REQ_TX_STATUS being set and as such ieee80211_led_tx() is never called. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bjorn Andersson <bjorn.andersson@linaro.org> writes: > On Thu 27 Apr 01:22 PDT 2017, Johannes Berg wrote: > >> >> > @@ -371,7 +371,7 @@ static void reap_tx_dxes(struct wcn36xx *wcn, >> > struct wcn36xx_dxe_ch *ch) >> > info = IEEE80211_SKB_CB(ctl->skb); >> > if (!(info->flags & >> > IEEE80211_TX_CTL_REQ_TX_STATUS)) { >> > /* Keep frame until TX status comes >> > */ >> > - ieee80211_free_txskb(wcn->hw, ctl- >> > >skb); >> > + ieee80211_tx_status(wcn->hw, ctl- >> > >skb); >> > >> >> I don't think this is a good idea. > > Thanks for letting me know :) > >> This code intentionally checked if TX status was requested, and if not >> then it doesn't go to the effort of building it. >> > > What I'm finding puzzling is the fact that the only caller of > ieee80211_led_tx() is ieee80211_tx_status() and it seems like drivers, > such as ath10k, call this for each packet handled - but I'm likely > missing something. > >> As it is with your patch, it'll go and report the TX status without any >> TX status information - which is handled in wcn36xx_dxe_tx_ack_ind() >> for those frames needing it. >> > > Right, it doesn't sound desired. However, during normal operation I'm > not seeing IEEE80211_TX_CTL_REQ_TX_STATUS being set and as such > ieee80211_led_tx() is never called. So what's the conclusion? How do we get leds working? -- Kalle Valo
On Thu, 2017-05-04 at 13:13 +0000, Kalle Valo wrote: > > > > This code intentionally checked if TX status was requested, and > > > if not then it doesn't go to the effort of building it. > > > > > > > What I'm finding puzzling is the fact that the only caller of > > ieee80211_led_tx() is ieee80211_tx_status() and it seems like > > drivers, such as ath10k, call this for each packet handled - but > > I'm likely missing something. Yes, many drivers do call it for each packet, and as such, this deficiency was never noted. > > > As it is with your patch, it'll go and report the TX status > > > without any > > > TX status information - which is handled in > > > wcn36xx_dxe_tx_ack_ind() > > > for those frames needing it. > > > > > > > Right, it doesn't sound desired. However, during normal operation > > I'm not seeing IEEE80211_TX_CTL_REQ_TX_STATUS being set and as such > > ieee80211_led_tx() is never called. > > So what's the conclusion? How do we get leds working? Well, frankly, I never thought the TX LED was a super good idea - but it had been supported by the original code IIRC, so never removed. Some people like frantic blinking I guess ;-) But I think the problem also applies to the throughput trigger thing, so perhaps we need to stick some LED feedback calls into other places, like _noskb() or provide an extra way to do it? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed 17 May 06:14 PDT 2017, Johannes Berg wrote: > On Thu, 2017-05-04 at 13:13 +0000, Kalle Valo wrote: > > > > > > This code intentionally checked if TX status was requested, and > > > > if not then it doesn't go to the effort of building it. > > > > > > > > > > What I'm finding puzzling is the fact that the only caller of > > > ieee80211_led_tx() is ieee80211_tx_status() and it seems like > > > drivers, such as ath10k, call this for each packet handled - but > > > I'm likely missing something. > > Yes, many drivers do call it for each packet, and as such, this > deficiency was never noted. > > > > > As it is with your patch, it'll go and report the TX status > > > > without any > > > > TX status information - which is handled in > > > > wcn36xx_dxe_tx_ack_ind() > > > > for those frames needing it. > > > > > > > > > > Right, it doesn't sound desired. However, during normal operation > > > I'm not seeing IEEE80211_TX_CTL_REQ_TX_STATUS being set and as such > > > ieee80211_led_tx() is never called. > > > > So what's the conclusion? How do we get leds working? > > Well, frankly, I never thought the TX LED was a super good idea - but > it had been supported by the original code IIRC, so never removed. Some > people like frantic blinking I guess ;-) > It seems very important to a lot of people... But if ieee80211_free_txskb() is the counterpart of ieee80211_tx_status() then we should be able to push the ieee80211_led_tx() call down into ieee80211_report_used_skb() and handle both cases. The ieee80211_free_txskb() seems to be used in various cases where we discard skbs, but perhaps this is not an issue in reality. > But I think the problem also applies to the throughput trigger thing, > so perhaps we need to stick some LED feedback calls into other places, > like _noskb() or provide an extra way to do it? > Looking around it seems that we either have a call to free_txskb() or one of the tx_status(); where the _noskb() would need some special handling. Are there others or would it be reasonable to add a call in this one "special" case? Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2017-05-17 at 22:05 -0700, Bjorn Andersson wrote: > > It seems very important to a lot of people... I get blinking, I guess, but I don't get toggling for every packet :) The throughput thing we did in iwlwifi seems like a so much better idea. Not that it really matters for this discussion though. > But if ieee80211_free_txskb() is the counterpart of > ieee80211_tx_status() then we should be able to push the > ieee80211_led_tx() call down into ieee80211_report_used_skb() and > handle both cases. Yeah, I guess that works. > The ieee80211_free_txskb() seems to be used in various cases where we > discard skbs, but perhaps this is not an issue in reality. Those should be code paths that are really rare, when we fail allocations in some places, etc. So it shouldn't really lead to any problems. > Looking around it seems that we either have a call to free_txskb() or > one of the tx_status(); Yes, you're right - we always need one of those for each SKB that passed through mac80211, everything else is already a bug. > where the _noskb() would need some special > handling. Are there others or would it be reasonable to add a call in > this one "special" case? Now that I think more about it, the _noskb() doesn't actually make sense - it's for a separate status report, pretty much only for rate control feedback, but the SKB should be freed separately with free_txskb(). johannes -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c b/drivers/net/wireless/ath/wcn36xx/dxe.c index 87dfdaf9044c..938b7bd733cf 100644 --- a/drivers/net/wireless/ath/wcn36xx/dxe.c +++ b/drivers/net/wireless/ath/wcn36xx/dxe.c @@ -371,7 +371,7 @@ static void reap_tx_dxes(struct wcn36xx *wcn, struct wcn36xx_dxe_ch *ch) info = IEEE80211_SKB_CB(ctl->skb); if (!(info->flags & IEEE80211_TX_CTL_REQ_TX_STATUS)) { /* Keep frame until TX status comes */ - ieee80211_free_txskb(wcn->hw, ctl->skb); + ieee80211_tx_status(wcn->hw, ctl->skb); } spin_lock(&ctl->skb_lock); if (wcn->queues_stopped) {
As the tx skbs are collected they should be passed to ieee80211_tx_status() rather than ieee80211_free_txskb(), as the prior will take care of monitoring and LED triggers while the latter will consider the skb dropped. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> --- drivers/net/wireless/ath/wcn36xx/dxe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)