From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleksij Rempel Date: Fri, 17 May 2013 20:51:16 +0200 Subject: [ath9k-devel] ath9k_htc: Target is unresponsive In-Reply-To: References: <20130516234526.GH3795@alittletooquiet.net> <20130517060042.GA21663@sig21.net> <5195E524.8000508@rempel-privat.de> <20130517081507.GA9673@zenon.in.qult.net> <5195EAE0.7040403@rempel-privat.de> <20130517103034.GA13060@zenon.in.qult.net> <20130517104047.GA14150@zenon.in.qult.net> <51960B15.8030001@rempel-privat.de> <20130517112243.GA15539@zenon.in.qult.net> <20130517114135.GA16784@zenon.in.qult.net> <51961BD9.6050300@rempel-privat.de> Message-ID: <51967C24.1010508@rempel-privat.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Am 17.05.2013 17:37, schrieb Adrian Chadd: > On 17 May 2013 05:00, Oleksij Rempel 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