From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
To: tamizh.raja@oss.qualcomm.com
Cc: ath11k@lists.infradead.org, ath12k@lists.infradead.org,
jjohnson@kernel.org, jtornosm@redhat.com,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 2/2] wifi: ath12k: implement custom wake_tx_queue with flow control
Date: Tue, 14 Jul 2026 18:01:51 +0200 [thread overview]
Message-ID: <20260714160151.664019-1-jtornosm@redhat.com> (raw)
In-Reply-To: <CABkEBKZABhFkS9MVqbeRFHLUXoNaJC-qocmcPVmZ8ov2j+DMzw@mail.gmail.com>
Hi Tamizh,
Thank you for the review.
> This assignment is wrong and all traffic is incorrectly steered to
> radio[0] as ah->radio is a flexible array, not a pointer
You are right, I will fix it in v2.
> tx_ring/tcl_ring selection should be corrected.
Yes, as also pointed out by Zhi-Jun You in the ath11k review, the ring
selection in wake_tx_queue needs to match dp_tx in a general way.
I will address this for both ath11k and ath12k in v2.
> Do we need this spin_lock_bh?
Yes. Without wake_tx_lock, there is a TOCTOU race between checking ring
space and dequeuing:
CPU A: num_free = 1 (sees 1 free slot)
CPU B: num_free = 1 (sees same slot)
CPU A: dequeue -> dp_tx (succeeds, fills last slot)
CPU B: dequeue -> dp_tx (fails -> -ENOMEM, frame dropped)
The tcl_ring->lock inside dp_tx only protects the descriptor write, not the
check-before-dequeue sequence.
> Do we need this check and spin_lock here? already ath12k_wifi7_dp_tx()
> has this lock and fetches the next entry. Can we check those return
> value here and break the loop?
We need to check before dequeuing. Once ieee80211_tx_dequeue removes the skb
from mac80211, a dp_tx failure means a dropped frame. Checking num_free first
avoids dequeuing when the ring is full, which is the whole point of the flow
control.
In addition, tcl_ring->lock is required by ath12k_hal_srng_src_num_free
itself, which asserts the lock is held.
The brief lock also ensures an accurate count synchronized with dp_tx on other
CPUs.
Best regards,
Jose Ignacio
prev parent reply other threads:[~2026-07-14 16:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 15:54 [PATCH 0/2] ath11k/ath12k: implement TX flow control Jose Ignacio Tornos Martinez
2026-07-10 15:54 ` [PATCH 1/2] wifi: ath11k: implement custom wake_tx_queue with " Jose Ignacio Tornos Martinez
2026-07-11 15:33 ` Zhi-Jun You
2026-07-13 15:01 ` Jose Ignacio Tornos Martinez
2026-07-14 2:38 ` Zhi-Jun You
2026-07-14 16:02 ` Jose Ignacio Tornos Martinez
2026-07-10 15:54 ` [PATCH 2/2] wifi: ath12k: " Jose Ignacio Tornos Martinez
2026-07-13 16:27 ` Jeff Johnson
2026-07-14 15:59 ` Jose Ignacio Tornos Martinez
2026-07-13 17:05 ` Tamizh Raja
2026-07-14 16:01 ` Jose Ignacio Tornos Martinez [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260714160151.664019-1-jtornosm@redhat.com \
--to=jtornosm@redhat.com \
--cc=ath11k@lists.infradead.org \
--cc=ath12k@lists.infradead.org \
--cc=jjohnson@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=tamizh.raja@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox