Linux wireless drivers development
 help / color / mirror / Atom feed
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


      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