The AR9170 SH-2 processor retains its internal command queue state across USB disconnect/reconnect when power is not fully cut (dirty disconnect). On the next probe the firmware delivers the stale echo test response from the previous session BEFORE the new echo test is sent. carl9170_cmd_callback() sees: ar->readlen == 0 (no command pending yet, cmd_seq still -2) response len == 4 (stale echo payload) and logs: received invalid command response: got 4, instead of 0 carl9170 cmd: 04 02 00 00 ef be ad de carl9170 rsp: 04 02 0e 00 ef be ad de restart device (9) This cascades into probe failure -115. BUG-015 (0015) drains the USB bulk IN endpoint before URBs are attached, but cannot catch responses that arrive after URB submission begins. Add a second line of defence inside carl9170_cmd_callback(): when cmd_seq is still -2 (init phase, before the command sequence counter is synchronised) a length mismatch is treated as a stale response from a prior session and discarded at dev_dbg level without triggering a restart. Signed-off-by: Masi Osmani --- drivers/net/wireless/ath/carl9170/rx.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c index XXXXXXX..YYYYYYY 100644 --- a/drivers/net/wireless/ath/carl9170/rx.c +++ b/drivers/net/wireless/ath/carl9170/rx.c @@ -142,6 +142,18 @@ * So we only check if we provided enough space for the data. */ if (unlikely(ar->readlen != (len - 4))) { + if (ar->cmd_seq == -2) { + /* + * Firmware retained a stale response from a previous + * probe's echo test across USB reconnect (SH-2 retains + * state if power is not fully cut). The real echo test + * has not been sent yet -- discard silently. + */ + dev_dbg(&ar->udev->dev, + "discarding stale init response (len %d)\n", + len - 4); + return; + } dev_warn(&ar->udev->dev, "received invalid command response:" "got %d, instead of %d\n", len - 4, ar->readlen); print_hex_dump_bytes("carl9170 cmd:", DUMP_PREFIX_OFFSET, -- Regards, Masi Osmani