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 0/2] wifi: ath9k_htc: keep WMI commands off the 64-byte packet boundary
Date: Sat, 5 Sep 2026 11:58:05 +0300 [thread overview]
Message-ID: <20260905085807.384488-1-nerijus.bendziunas@gmail.com> (raw)
v2 [1] must not be applied. Its message said no caller fills the RMW
buffer; ar9271_hw_pa_cal() does, on every AR9271 reset. With the size
corrected the flush is a 192-byte command, three full 64-byte USB
packets. The firmware ends a command only on a short packet, so this
one is never delivered: the device stops answering WMI and stays dead
until power is removed. This happens on the first interface open,
with the linux-firmware 1.4.0 blob and with an open-firmware build.
Patch 1 fixes the size and caps MAX_RMW_CMD_NUMBER at 14, so the
buffer can never produce a 192-byte command. With the cap, 120
interface opens ran clean: 60 with this patch, 20 of them on the
linux-firmware blob and 20 on a second AR9271, and 60 with a bench
build of the same wire lengths. A 16-entry, 204-byte command is
delivered while the 15-entry, 192-byte one is not. Patch 2 refuses
any command whose length is a multiple of the endpoint's packet size.
With all 15 writes applied the PA calibration reads offset 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.
The firmware rule is usb_reg_out_patch() in open-ath9k-htc-firmware,
target_firmware/magpie_fw_dev/target/hif/usb_api_main_patch.c. A fix
for it exists and goes to the firmware project separately; it does
not reach devices already in the field, so the driver has to stay
clear anyway.
[1] https://lore.kernel.org/linux-wireless/20260904180849.775404-1-nerijus.bendziunas@gmail.com/
Based on ath-next, commit 1d8e73163ef9.
Nerijus Bendžiūnas (2):
wifi: ath9k_htc: fix the byte count of a full RMW buffer flush
wifi: ath9k_htc: refuse a command that fills whole USB packets
drivers/net/wireless/ath/ath9k/hif_usb.c | 7 +++++++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 +-
drivers/net/wireless/ath/ath9k/wmi.h | 3 ++-
3 files changed, 10 insertions(+), 2 deletions(-)
--
2.55.0
next 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 Nerijus Bendžiūnas [this message]
2026-09-05 8:58 ` [PATCH v3 1/2] wifi: ath9k_htc: fix the byte count of a full RMW buffer flush Nerijus Bendžiūnas
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-1-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
all inboxes | Powered by JetHome®