[ath9k-devel] ath9k_htc: Target is unresponsive

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

To be able to reproduce this bug a bit easier, i added usbautosuspend to 
ath9k_htc. There is some interesting statistic of power usage for now:
ar9271:
? power on + wifi on = 160 uA
? "ifconfig wlan0 down" without autosuspend = 60 uA
? "ifconfig wlan0" down with autosupend = 1,6 uA

Current problem is to bring adapter back.


Am 17.05.2013 20:51, schrieb Oleksij Rempel:
> 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