Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-11-15 08:31:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

carl9170: handle traps from firmware loader

Browse Source 
This patch changes the way the driver deals with
command responses and traps which are sent through
the special interrupt input endpoint 3.

While the carl9170 firmware does not use this
endpoint for command responses or traps, the
firmware loader on the device does. It uses it
to notify the host about 'watchdog triggered'
in case the firmware/hardware has crashed.

Note:
Even without this patch, the driver is still
able to detect the mishap and reset the device.
But previously it did that because the trap
event caused an out-of-order message sequence
number error, which also triggered a reset.

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This commit is contained in:
Christian Lamparter 2012-10-06 20:42:54 +02:00 committed by John W. Linville
parent afe3840a1a
commit b4764c809a
2 changed files with 10 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
drivers/net/wireless/ath/carl9170/rx.c
View File

@ -164,9 +164,6 @@ void carl9170_handle_command_response(struct ar9170 *ar, void *buf, u32 len)
struct carl9170_rsp *cmd = buf;
struct ieee80211_vif *vif;
if (carl9170_check_sequence(ar, cmd->hdr.seq))
return;
if ((cmd->hdr.cmd & CARL9170_RSP_FLAG) != CARL9170_RSP_FLAG) {
if (!(cmd->hdr.cmd & CARL9170_CMD_ASYNC_FLAG))
carl9170_cmd_callback(ar, len, buf);
@ -820,6 +817,9 @@ static void carl9170_rx_untie_cmds(struct ar9170 *ar, const u8 *respbuf,
if (unlikely(i > resplen))
break;
if (carl9170_check_sequence(ar, cmd->hdr.seq))
break;
carl9170_handle_command_response(ar, cmd, cmd->hdr.len + 4);
}

7
drivers/net/wireless/ath/carl9170/usb.c
View File

@ -295,6 +295,13 @@ static void carl9170_usb_rx_irq_complete(struct urb *urb)
goto resubmit;
}
/*
* While the carl9170 firmware does not use this EP, the
* firmware loader in the EEPROM unfortunately does.
* Therefore we need to be ready to handle out-of-band
* responses and traps in case the firmware crashed and
* the loader took over again.
*/
carl9170_handle_command_response(ar, urb->transfer_buffer,
urb->actual_length);