Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Thu, May 16, 2013 at 07:45:26PM -0400, Forest Bond wrote: On Fri, May 17, 2013 at 01:48:57AM +0200, Ignacy Gawedzki wrote: On Thu, May 16, 2013 at 08:50:30PM +0200, thus spake Ignacy Gawedzki: I'll try on yet another one and will tell you the results. Just tried on ICH7, same thing. The easiest way to reproduce the bug is to boot into single user mode (recovery mode on Ubuntu), in order to prevent any NetworkManager or udev from interfering. Then, without any attempt to up the interface, reboot the system by typing reboot in a root shell. FWIW, this has also been a problem for me on Ubuntu 12.04. I can reproduce it the same way. FWIW, I also met this problem after I added ath9k_htc to my initrd (via /etc/initramfs-tools/modules). So I removed it and the issue went away. I first noticed it after resume from suspend-to-disk, but later found it doesn't work after warm reboot, too. The mainboard has Intel H77 chipset, the TL-WN722N is plugged into USB2.0 port. Johannes ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath10k: program FW with appropriate regdomain
We already setup scan channel list upon regdomain
update but we should also setup the regpair to the
FW.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/mac.c | 13 +
drivers/net/wireless/ath/ath10k/wmi.c | 18 ++
drivers/net/wireless/ath/ath10k/wmi.h |3 ++-
3 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 974f992..49e3940 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1249,6 +1249,7 @@ static void ath10k_reg_notifier(struct wiphy *wiphy,
struct regulatory_request *request)
{
struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
+ struct reg_dmn_pair_mapping *regpair;
struct ath10k *ar = hw-priv;
int ret;
@@ -1257,6 +1258,18 @@ static void ath10k_reg_notifier(struct wiphy *wiphy,
ret = ath10k_update_channel_list(ar);
if (ret)
ath10k_warn(could not update channel list (%d)\n, ret);
+
+ regpair = ar-ath_common.regulatory.regpair;
+ /* Target allows setting up per-band regdomain but ath_common provides
+* a combined one only */
+ ret = ath10k_wmi_pdev_set_regdomain(ar,
+ regpair-regDmnEnum,
+ regpair-regDmnEnum, /* 2ghz */
+ regpair-regDmnEnum, /* 5ghz */
+ regpair-reg_2ghz_ctl,
+ regpair-reg_5ghz_ctl);
+ if (ret)
+ ath10k_warn(could not set pdev regdomain (%d)\n, ret);
}
/***/
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 0d5070d..bb33421a 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1132,7 +1132,8 @@ int ath10k_wmi_connect_htc_service(struct ath10k *ar)
return 0;
}
-int ath10k_wmi_pdev_set_regdomain(struct ath10k *ar)
+int ath10k_wmi_pdev_set_regdomain(struct ath10k *ar, u16 rd, u16 rd2g,
+ u16 rd5g, u16 ctl2g, u16 ctl5g)
{
struct wmi_pdev_set_regdomain_cmd *cmd;
struct sk_buff *skb;
@@ -1142,14 +1143,15 @@ int ath10k_wmi_pdev_set_regdomain(struct ath10k *ar)
return -ENOMEM;
cmd = (struct wmi_pdev_set_regdomain_cmd *)skb-data;
+ cmd-reg_domain = __cpu_to_le32(rd);
+ cmd-reg_domain_2G = __cpu_to_le32(rd2g);
+ cmd-reg_domain_5G = __cpu_to_le32(rd5g);
+ cmd-conformance_test_limit_2G = __cpu_to_le32(ctl2g);
+ cmd-conformance_test_limit_5G = __cpu_to_le32(ctl5g);
- /* FIXME: do not use hardcoded values */
- /* TODO: provide correct values for reg domain */
- cmd-reg_domain= __cpu_to_le32(0x3a); /* FCC3_FCCA */
- cmd-reg_domain_2G = __cpu_to_le32(0x0a10); /* FCCA */
- cmd-reg_domain_5G = __cpu_to_le32(0x160); /* FCC3 */
- cmd-conformance_test_limit_2G = __cpu_to_le32(0x12); /* FCC4-FCCA */
- cmd-conformance_test_limit_5G = __cpu_to_le32(0x10); /* FCC1-FCCA */
+ ath10k_dbg(ATH10K_DBG_WMI,
+ wmi pdev regdomain rd %x rd2g %x rd5g %x ctl2g %x ctl5g
%x\n,
+ rd, rd2g, rd5g, ctl2g, ctl5g);
return ath10k_wmi_cmd_send(ar, skb, WMI_PDEV_SET_REGDOMAIN_CMDID);
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index ccab87e..6c00e59 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -2958,7 +2958,8 @@ int ath10k_wmi_pdev_set_channel(struct ath10k *ar,
const struct wmi_channel_arg *);
int ath10k_wmi_pdev_suspend_target(struct ath10k *ar);
int ath10k_wmi_pdev_resume_target(struct ath10k *ar);
-int ath10k_wmi_pdev_set_regdomain(struct ath10k *ar);
+int ath10k_wmi_pdev_set_regdomain(struct ath10k *ar, u16 rd, u16 rd2g,
+ u16 rd5g, u16 ctl2g, u16 ctl5g);
int ath10k_wmi_pdev_set_param(struct ath10k *ar, enum wmi_pdev_param id,
u32 value);
int ath10k_wmi_cmd_init(struct ath10k *ar);
--
1.7.9.5
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 17.05.2013 08:00, schrieb Johannes Stezenbach: On Thu, May 16, 2013 at 07:45:26PM -0400, Forest Bond wrote: On Fri, May 17, 2013 at 01:48:57AM +0200, Ignacy Gawedzki wrote: On Thu, May 16, 2013 at 08:50:30PM +0200, thus spake Ignacy Gawedzki: I'll try on yet another one and will tell you the results. Just tried on ICH7, same thing. The easiest way to reproduce the bug is to boot into single user mode (recovery mode on Ubuntu), in order to prevent any NetworkManager or udev from interfering. Then, without any attempt to up the interface, reboot the system by typing reboot in a root shell. FWIW, this has also been a problem for me on Ubuntu 12.04. I can reproduce it the same way. FWIW, I also met this problem after I added ath9k_htc to my initrd (via /etc/initramfs-tools/modules). So I removed it and the issue went away. I first noticed it after resume from suspend-to-disk, but later found it doesn't work after warm reboot, too. The mainboard has Intel H77 chipset, the TL-WN722N is plugged into USB2.0 port. OK, now i was able to reproduce it on ar9271. In attachment is the log i grubbed form adapter. Lines starting with # are my comments -- Regards, Oleksij [2013-05-17 09:49:10] ## turn on pc [2013-05-17 09:49:15] [2013-05-17 09:49:15] ASIC-ROM_1.8 [2013-05-17 09:49:15] 1. 40Mhz [2013-05-17 09:49:15] 2. post [2013-05-17 09:49:16] 3. eep chk [2013-05-17 09:49:16] [%s+] [2013-05-17 09:49:16] patch.offset: 0x%04x, patch.size : 0x%04x [2013-05-17 09:49:16] [%s+] [2013-05-17 09:49:16] CheckSum: 0x%08x [2013-05-17 09:49:16] size: %d bytes [2013-05-17 09:49:16] ld_addr: 0x%08x [2013-05-17 09:49:16] fun_addr: 0x%08x [2013-05-17 09:49:16] copy %d bytes from 0x%08x to 0x%08x[%s-] [2013-05-17 09:49:16] [%s-] [2013-05-17 09:49:16] 4. cold start [2013-05-17 09:49:16] 5. usb only!! [2013-05-17 09:49:16] 6. read usb_conf(0x%04x) to ram(0x%08x) [2013-05-17 09:49:16] 7. usb_hclk rdy [2013-05-17 09:49:16] 8. download [2013-05-17 09:49:16] - custom usb config [2013-05-17 09:49:37] [2013-05-17 09:49:38] start ubuntu kernel 3.8.0-13-generic [2013-05-17 09:50:04] - custom usb config [2013-05-17 09:50:06] - custom usb config [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [2013-05-17 09:50:07] ==[cUSB_REQ_COMP]: 0x%08x [2013-05-17 09:50:07] VendorCmd: DownloadComplete! [2013-05-17 09:50:07] 5. usb only!! [2013-05-17 09:50:07] A_WDT_INIT() [2013-05-17 09:50:07] ==cold start== [2013-05-17 09:50:07] ALLOCRAM start 0x50d7f4 size 106508 [2013-05-17 09:50:07] Enable Tx Stream mode [2013-05-17 09:50:08] [+++Magpie_init] [2013-05-17 09:50:08] [+++VBUF_init(100)] [2013-05-17 09:50:08] [+++VBUF_init(100)] [2013-05-17 09:50:08] wlan_pci_probe: Attaching the driver [2013-05-17 09:50:08] wlan_pci_probe: Vendor id 0x168c Dev id 0x24 [2013-05-17 09:50:08] ath_pci_probe 24 [2013-05-17 09:50:08] ath_hal = 0x00510910 [2013-05-17 09:50:08] [2013-05-17 09:50:08] =[dnQ] 0x0050f270 [2013-05-17 09:50:08] [ =[upQ] 0x0050f24c [2013-05-17 09:50:08] [ =[hp dnQ] 0x0050f228 [2013-05-17 09:50:08] [ =[mp dnQ] 0x0050f204 [2013-05-17 09:50:08] [Tgt running [2013-05-17 09:50:10] !USB suspend [2013-05-17 09:50:10] [2013-05-17 09:50:10] change clock to 22 and go to suspend now!øøøøxüøøx ÿ [2013-05-17 09:50:10] ASIC-ROM_1.8 [2013-05-17 09:50:10] 1. 40Mhz [2013-05-17 09:50:10] 2. post [2013-05-17 09:50:10] 3. eep chk [2013-05-17 09:50:10] [%s+] [2013-05-17 09:50:10] patch.offset: 0x%04x, patch.size : 0x%04x [2013-05-17 09:50:10] [%s+] [2013-05-17 09:50:10] CheckSum: 0x%08x [2013-05-17 09:50:10] size: %d bytes [2013-05-17 09:50:10] ld_addr: 0x%08x [2013-05-17 09:50:10] fun_addr: 0x%08x [2013-05-17 09:50:10] copy %d bytes from 0x%08x to 0x%08x[%s-] [2013-05-17 09:50:10] [%s-] [2013-05-17 09:50:10] 4. warm start [2013-05-17 09:50:10] 5. usb only!! [2013-05-17 09:50:10] 6. read usb_conf(0x%04x) to ram(0x%08x) [2013-05-17 09:50:10] 7. usb_hclk rdy [2013-05-17 09:50:10] 8. download [2013-05-17 09:50:10] [2013-05-17 09:50:40] ### kernel started [2013-05-17 09:50:40] ### reboot pc [2013-05-17 09:51:07] Generate Event [2013-05-17 09:51:07] - custom usb config [2013-05-17 09:51:13] [2013-05-17 09:51:17] starting kcurrent kernel [2013-05-17 09:51:31] - custom usb config
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Fri, May 17, 2013 at 10:07:00AM +0200, thus spake Oleksij Rempel: OK, now i was able to reproduce it on ar9271. Ah, good, but what did you do wrong previously then? In attachment is the log i grubbed form adapter. Lines starting with # are my comments At least we can already diagnose a problem with A_PRINTF. :/ Do these logs speak to anyone? -- /* This is not a comment */ ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 17.05.2013 10:15, schrieb Ignacy Gawedzki: On Fri, May 17, 2013 at 10:07:00AM +0200, thus spake Oleksij Rempel: OK, now i was able to reproduce it on ar9271. Ah, good, but what did you do wrong previously then? Nothing. I needed to start single user mode first, and reboot the system to et this error. In attachment is the log i grubbed form adapter. Lines starting with # are my comments At least we can already diagnose a problem with A_PRINTF. :/ Do these logs speak to anyone? Here are some explanations: ASIC-ROM_1.8 - is start of boot loader on device. It should go immediately after adapter got power. 8. download - at this stage bootloader is ready to receive firmware. [Tgt running - firmware was downloaded and running. !USB suspend - means usb suspend was initiated And that is probably our problem. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Did anybody tried to force the usb to go to suspend? If something like this echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level will help to reproduce this issue? 2013/5/17 Oleksij Rempel li...@rempel-privat.de: Am 17.05.2013 10:15, schrieb Ignacy Gawedzki: On Fri, May 17, 2013 at 10:07:00AM +0200, thus spake Oleksij Rempel: OK, now i was able to reproduce it on ar9271. Ah, good, but what did you do wrong previously then? Nothing. I needed to start single user mode first, and reboot the system to et this error. In attachment is the log i grubbed form adapter. Lines starting with # are my comments At least we can already diagnose a problem with A_PRINTF. :/ Do these logs speak to anyone? Here are some explanations: ASIC-ROM_1.8 - is start of boot loader on device. It should go immediately after adapter got power. 8. download - at this stage bootloader is ready to receive firmware. [Tgt running - firmware was downloaded and running. !USB suspend - means usb suspend was initiated And that is probably our problem. -- Regards, Oleksij -- Best regards, Eugene ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Fri, May 17, 2013 at 11:33:53AM +0200, thus spake Eugene Krasnikov: Did anybody tried to force the usb to go to suspend? If something like this echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level will help to reproduce this issue? This way of forcing suspend is apparently deprecated and doesn't work in my case. I tried to set power/control to auto, but it has no apparent effect on anything. :( -- I drive too fast to worry about cholesterol. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 17.05.2013 12:40, schrieb Ignacy Gawedzki: On Fri, May 17, 2013 at 12:30:34PM +0200, thus spake Ignacy Gawedzki: On Fri, May 17, 2013 at 11:33:53AM +0200, thus spake Eugene Krasnikov: Did anybody tried to force the usb to go to suspend? If something like this echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level will help to reproduce this issue? This way of forcing suspend is apparently deprecated and doesn't work in my case. I tried to set power/control to auto, but it has no apparent effect on anything. :( Okay, I did manage to make it fail. In single-user mode (to prevent any daemon from interfering), I plugged the dongle, set power/control to auto and after a few seconds unloaded/reloaded the ath9k_htc module. This made the target unresponsive. If I do the same without setting power/control to auto (it is on by default), then unloading/reloading the module doesn't make the device unresponsive. BTW, Oleksij, just out of curiosity, how did you manage to solder those UART pins? Here an example of soldered pins, it is ar7010 device. I attached here jtag pins. https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk here is a workaround for this issue, please test it: https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel: Here an example of soldered pins, it is ar7010 device. I attached here jtag pins. https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk Wow, my soldering iron has too broad a tip for that precision work. :/ 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. Big thanks! -- :wq! ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Fri, May 17, 2013 at 01:22:43PM +0200, thus spake Ignacy Gawedzki: On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel: Here an example of soldered pins, it is ar7010 device. I attached here jtag pins. https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk Wow, my soldering iron has too broad a tip for that precision work. :/ 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? -- Sex on TV doesn't hurtunless you fall off. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 17.05.2013 13:41, schrieb Ignacy Gawedzki: On Fri, May 17, 2013 at 01:22:43PM +0200, thus spake Ignacy Gawedzki: On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel: Here an example of soldered pins, it is ar7010 device. I attached here jtag pins. https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk Wow, my soldering iron has too broad a tip for that precision work. :/ 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. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On 17 May 2013 05:00, Oleksij Rempel li...@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? Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 17.05.2013 17:37, schrieb Adrian Chadd: On 17 May 2013 05:00, Oleksij Rempel li...@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: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x9271 AR9271 802.11n bcdDevice1.08 iManufacturer 16 iProduct 32 iSerial48 bNumConfigurations 1 ---end--- here is ok descriptor: Bus 003 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x9271 AR9271 802.11n bcdDevice1.08 iManufacturer 16 ATHEROS iProduct 32 UB91C iSerial48 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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
