HTC way of error handling.
Oleksij Rempel
linux at rempel-privat.de
Fri Jul 19 16:10:33 EDT 2013
Hallo Adrian,
Most parts of firmware reload bug are now fixed. At least for one tester...
There is still one bug, which for now I was able to reproduce only on
intels usb3.0 host controller.
If unload module and give enough time (2-4 seconds), adapter will be
suspended. After modprobe adapter will work with some issues. For
example misconfigured EP4 FIFO. If you or some one else can help me here
it will be great! :)
I assume it is not last error of this kind.
Now to other problem. Since this issue is not last one, we need some way
to report errors to the host. First off all, we need it make hosts live
easier. If there is some firmware error, host waiting long time or keeps
trying to send other request. No actual firmware errors are reported.
Probably it will be better to do it HTC way. Assume it should be HTC
service which check for messages, or some thing like current rx handler.
If I understand correctly we have fallowing HTC services:
WMI_CONTROL_SVC
WMI_BEACON_SVC
WMI_CAB_SVC
WMI_UAPSD_SVC
WMI_MGMT_SVC
WMI_DATA_VO_SVC
WMI_DATA_VI_SVC
WMI_DATA_BE_SVC
WMI_DATA_BK_SVC
- Only WMI_CONTROL_SVC is actual WMI service.
- All others are purely HTC services.
- By registering each service we add ath9k_htc_rxep, so we do not need
to check RX packets separately and so reducing USB bandwidth.
- RX data has no HTC header, instead it has ath_htc_rx_status.
- Currently we have no way to report errors from target to host.
Are this assumptions correct?
If so I think we have fallowing options:
- add HTC header before ath_htc_rx_status, so we can separate RX and
ERROR btw STATUS messages.
- use WMI for periodic checks.
Other ideas?
--
Regards,
Oleksij
More information about the ath9k_htc_fw
mailing list