[ath9k-devel] ath9k_htc: Target is unresponsive
Oleksij Rempel
linux at rempel-privat.de
Fri May 17 14:51:16 EDT 2013
Am 17.05.2013 17:37, schrieb Adrian Chadd:
> On 17 May 2013 05:00, Oleksij Rempel <linux at 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
More information about the ath9k_htc_fw
mailing list