From: "Nerijus Bendžiūnas" <nerijus.bendziunas@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>, linux-wireless@vger.kernel.org
Cc: Kalle Valo <kvalo@kernel.org>,
Oleksij Rempel <linux@rempel-privat.de>,
linux-kernel@vger.kernel.org
Subject: [PATCH v3 1/2] wifi: ath9k_htc: fix the byte count of a full RMW buffer flush
Date: Sat, 5 Sep 2026 11:58:06 +0300 [thread overview]
Message-ID: <20260905085807.384488-2-nerijus.bendziunas@gmail.com> (raw)
In-Reply-To: <20260905085807.384488-1-nerijus.bendziunas@gmail.com>
The AR9271 PA calibration has been running with its last five
register writes dropped since the RMW buffer was added.
ar9271_hw_pa_cal() queues exactly 15 read-modify-writes, which fills
the buffer, and ath9k_reg_rmw_buffer() sizes that flush with
sizeof(struct register_write), 8 bytes, instead of
sizeof(struct register_rmw), 12 bytes. The firmware gets 120 of the
180 bytes and applies only the first 10.
Fixing the size alone kills the device. The command becomes
8 (HTC) + 4 (WMI) + 180 = 192 bytes, three full 64-byte USB packets,
and the firmware ends a command only on a short packet
(usb_reg_out_patch() in open-ath9k-htc-firmware). The 192-byte
command is never delivered: the device stops answering WMI and stays
dead through a warm reboot until power is removed. An AR9271 hangs
this way on the first interface open, with the linux-firmware 1.4.0
blob and with an open-firmware build alike.
So cap the buffer at 14 entries as well. A command of n entries is
12 * (n + 1) bytes, a multiple of 64 only at n = 15 within the
buffer's reach. The next largest RMW batch, ath9k_hw_4k_set_gain(),
queues at most 14 entries, 180 bytes, and a register write batch is
8n + 12 bytes, never a multiple of 64. The PA calibration then goes
out as 14 + 1 entries and all 15 writes reach the chip.
AR9271_AN_RF2G6_OFFS then reads 30 on 40 of 40 opens, where the
truncated command gave 32 on 78 of 80; a firmware with fixed
reassembly, given the full 15-entry command, gave 30 on 19 of 20. The
on-air effect is not measured yet. With the cap, 120 interface opens
ran clean: 60 with this patch, 20 of them on the linux-firmware 1.4.0
blob and 20 on a second AR9271, and 60 with a bench build of the same
wire lengths.
Fixes: 8badb50cfab6 ("ath9k_htc: add new WMI_REG_RMW_CMDID command")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Nerijus Bendžiūnas <nerijus.bendziunas@gmail.com>
---
Changes in v3:
- v2 said no caller fills the buffer; ar9271_hw_pa_cal() does, on
every AR9271 reset.
- Cap MAX_RMW_CMD_NUMBER at 14 in the same patch: the corrected size
alone yields a 192-byte command the firmware never delivers.
- Assisted-by in the form Documentation/process/coding-assistants.rst
now asks for.
Changes in v2:
- Add Assisted-by, rewrite the commit message, rebase onto ath-next.
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 +-
drivers/net/wireless/ath/ath9k/wmi.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 6de78ae85726..0b49d2cc99f0 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -405,7 +405,7 @@ static void ath9k_reg_rmw_buffer(void *hw_priv,
if (priv->wmi->multi_rmw_idx == MAX_RMW_CMD_NUMBER) {
r = ath9k_wmi_cmd(priv->wmi, WMI_REG_RMW_CMDID,
(u8 *) &priv->wmi->multi_rmw,
- sizeof(struct register_write) * priv->wmi->multi_rmw_idx,
+ sizeof(struct register_rmw) * priv->wmi->multi_rmw_idx,
(u8 *) &rsp_status, sizeof(rsp_status),
100);
if (unlikely(r)) {
diff --git a/drivers/net/wireless/ath/ath9k/wmi.h b/drivers/net/wireless/ath/ath9k/wmi.h
index 5c3b710b8f31..256f46098a6b 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.h
+++ b/drivers/net/wireless/ath/ath9k/wmi.h
@@ -126,7 +126,8 @@ enum wmi_event_id {
};
#define MAX_CMD_NUMBER 62
-#define MAX_RMW_CMD_NUMBER 15
+/* 15 entries make 192 bytes, three full USB packets: never delivered. */
+#define MAX_RMW_CMD_NUMBER 14
struct register_write {
__be32 reg;
--
2.55.0
next prev parent reply other threads:[~2026-09-05 8:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-05 8:58 [PATCH v3 0/2] wifi: ath9k_htc: keep WMI commands off the 64-byte packet boundary Nerijus Bendžiūnas
2026-09-05 8:58 ` Nerijus Bendžiūnas [this message]
2026-09-05 8:58 ` [PATCH v3 2/2] wifi: ath9k_htc: refuse a command that fills whole USB packets Nerijus Bendžiūnas
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=20260905085807.384488-2-nerijus.bendziunas@gmail.com \
--to=nerijus.bendziunas@gmail.com \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linux@rempel-privat.de \
--cc=toke@toke.dk \
/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