[ath9k-devel] ath9k_htc: Target is unresponsive

[Oleksij Rempel <linux@rempel-privat.de>]

Am 17.05.2013 17:37, schrieb Adrian Chadd:
> On 17 May 2013 05:00, Oleksij Rempel <linux@rempel-privat.de> wrote:
>
>>>>> here is a workaround for this issue, please test it:
>>>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend
>>>>
>>>> It seems to work just right on the PC.  I'll test on the RPi and let you know.
>>>
>>> Works on the RPi as well!  Are there any implications for this being a
>>> workaround and not a proper fix?
>>
>> Yes, i do not know what i did. I will need to find out, what it actually
>> should do.
>
> ... hm, is this reset type not working? Is this the whole "reset
> through watchdog" versus "reset through reset" thing you talked about
> a couple weeks ago?

No, it is different issue, at least at different path.
I did some more test and i'll try now to reflect all collected informations:
- Only ar9271 devices are affected. ar7010 seems to be fine.
- the issue is in:
target_firmware/magpie_fw_dev/target/hif/k2_fw_usb_api.c:
in _fw_usb_suspend_reboot()

this function is called from two points:
- _fw_usbfifo_recv_command(), this one is triggered if host go to supend
- _fw_usb_fw_task(), this function is called on different events, 
including reset, some cases if suspend? and resume? last was never 
called. I'll need to check how exactly this part is working.

So,  _fw_usb_suspend_reboot() should theoretically prepare adapter for 
suspend, to reduce power consumption. But there are fallowing problems 
with this function:
- some hosts will completely power down this device. Absolutely no power 
is consumed and all preparations made by this function are lost (cald 
reset).
- some hosts keep usb port powered to be able to charge some device. It 
is done only on laptops/pcs connected to power supply (i have one of 
this, so i was able to check it). In this case we go to some undefined 
state, and probably prepared to receive firmware.  In this state device 
use about 40mA.
- in all cases linux will do reset on resume. So all side effects 
produced by _fw_usb_suspend_reboot() are reseted. This is why it is so 
hard to reproduce this case.

The problem what we now have is passed from _fw_usb_fw_task(), in this 
case adapter will restart to boot loader and got ready to receive 
firmware. But it looks like usb descriptor in this case is incomplete:

here is brocken descriptor:
Bus 003 Device 002: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               2.00
   bDeviceClass          255 Vendor Specific Class
   bDeviceSubClass       255 Vendor Specific Subclass
   bDeviceProtocol       255 Vendor Specific Protocol
   bMaxPacketSize0        64
   idVendor           0x0cf3 Atheros Communications, Inc.
   idProduct          0x9271 AR9271 802.11n
   bcdDevice            1.08
   iManufacturer          16
   iProduct               32
   iSerial                48
   bNumConfigurations      1
---end---


here is ok descriptor:

Bus 003 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               2.00
   bDeviceClass          255 Vendor Specific Class
   bDeviceSubClass       255 Vendor Specific Subclass
   bDeviceProtocol       255 Vendor Specific Protocol
   bMaxPacketSize0        64
   idVendor           0x0cf3 Atheros Communications, Inc.
   idProduct          0x9271 AR9271 802.11n
   bcdDevice            1.08
   iManufacturer          16 ATHEROS
   iProduct               32 UB91C
   iSerial                48 12345
   bNumConfigurations      1
   Configuration Descriptor:
     bLength                 9
     bDescriptorType         2
     wTotalLength           60
     bNumInterfaces          1
     bConfigurationValue     1
     iConfiguration          0
     bmAttributes         0x80
       (Bus Powered)
     MaxPower              500mA
--- and some more --------


after i disabled this function... see my workaround patch. I got 
fallowing process. Host send suspend command.... no changes was made, 
(currently i do not know what should we send as response), host trying 
to send it some more times and the send reset. After this, adapter is 
rebooting and firmware is uploaded... so it comes to normal working state.

There is no way to support WoW here. So, there is no need to have some 
sort of reduced power state. I assume, we can remove most part of 
suspend sequence from firmware. And replace it with some correct 
response to the host that every thing is ok, or that we do not support 
this bit.
-- 
Regards,
Oleksij