HTC way of error handling.

[Oleksij Rempel]

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