From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleksij Rempel Date: Sat, 18 May 2013 12:59:36 +0200 Subject: [ath9k-devel] ath9k_htc: Target is unresponsive In-Reply-To: <51967C24.1010508@rempel-privat.de> 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> <51967C24.1010508@rempel-privat.de> Message-ID: <51975F18.507@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 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 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