Re: [PATCH v2] wifi: ath9k: reject short WMI command responses

[Mehmet Fide <mehmet.fide@gmail.com>]

Hi,

this change breaks ath9k_htc with the AR9271 firmware from linux-firmware
(ath9k_htc/htc_9271-1.4.0.fw, "FW Version: 1.4"). The firmware answers
most commands with an empty payload, while the driver passes a response
buffer for every command: cmd_rsp in WMI_CMD()/WMI_CMD_BUF(), the 4-byte
value of WMI_REG_WRITE_CMDID, the 4- or 12-byte buffer of
WMI_REG_RMW_CMDID. With the new check all of these calls return
-EMSGSIZE, and bringing the interface up fails (hostapd: "Could not set
interface wlan0 flags (UP): Message too long").

Seen on a Colibri VF50 (Vybrid, armv7) with an AR9271 USB adapter on
6.12.113, which carries this commit as 03ef61d05aa2. A log line in
ath9k_wmi_rsp_callback() for every rejected response shows, during boot
and interface up:

  WMI_ATH_INIT_CMDID          0 bytes, 1 expected
  WMI_START_RECV_CMDID        0 bytes, 1 expected
  WMI_FLUSH_RECV_CMDID        0 bytes, 1 expected
  WMI_SET_MODE_CMDID          0 bytes, 1 expected
  WMI_REG_WRITE_CMDID         0 bytes, 4 expected
  WMI_TARGET_IC_UPDATE_CMDID  0 bytes, 1 expected
  WMI_REG_RMW_CMDID           0 bytes, 12 or 4 expected

With the commit reverted on the same kernel, logging instead of rejecting,
the same commands keep answering with 0 bytes, and so do
WMI_DISABLE_INTR_CMDID, WMI_ENABLE_INTR_CMDID, WMI_DRAIN_TXQ_ALL_CMDID,
WMI_STOP_RECV_CMDID, WMI_NODE_CREATE/REMOVE_CMDID and
WMI_VAP_CREATE/REMOVE_CMDID. WMI_REG_READ_CMDID is the only command in
the log that returns data.

So an empty reply is how this firmware answers a command without a
result, and rejecting it takes the device down. I have not tried other
firmware versions. I can test a fix on this hardware.

#regzbot introduced: 93ce8ea70451

Thanks,
Mehmet