Re: FUSB200 xhci issue

Re: FUSB200 xhci issue

[Christian Lamparter]

Hello!

On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of 
> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i 
> accidentally discovered that 9170 have it too. Are there any issue with 
> usb-suspend + xhci controllers by you? Did you some how specially 
> handled it?

No, I haven't heard any complains about xhci + suspend. In fact, 
it's working fine with the NEC xhci I have. I also have a AR9271
and AR7010, so if you want I could try if they survive a suspend
+resume cycle when attached.

But, I do have a bug-report from someone else who has/had? problems
with carl9170 and xhci. If you want, you can get the details from:
"carl9170 A-MPDU transmit problem":
<http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>

The likely cause is related to Intel's xhci silicon (Ivy Bridge is
affected, but I don't know about Haswell):
<http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>

However, I haven't heard back from Sarah or Seth about this matter
(Added them to the CC. so "PLEASE" join if either of you think to
have something to add about carl9170 transmit problem or ath9k_htc's
suspend issue... of course, if it was fixed, then it would be really
great to know which commit "fixed it"...)

Regards

Christian

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 22.07.2013 21:54, schrieb Christian Lamparter:
> Hello!
>
> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
>> accidentally discovered that 9170 have it too. Are there any issue with
>> usb-suspend + xhci controllers by you? Did you some how specially
>> handled it?
>
> No, I haven't heard any complains about xhci + suspend. In fact,
> it's working fine with the NEC xhci I have. I also have a AR9271
> and AR7010, so if you want I could try if they survive a suspend
> +resume cycle when attached.
>
> But, I do have a bug-report from someone else who has/had? problems
> with carl9170 and xhci. If you want, you can get the details from:
> "carl9170 A-MPDU transmit problem":
> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
>
> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
> affected, but I don't know about Haswell):
> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>

Same situation is here - i have problem on Ivy Bridge.
Steps to reproduce:
- plug adapter. Module and firmware will be loaded
- make sure usb autosupend is enabled. By default it is not! Use 
powertop or directly sysfs to enable autosuspend for this device
- rmmod .... and wait some seconds until adapter is suspended and then 
modprobe ath9k_htc

first packet which is bigger as 64Byte will kill EP4 FIFO. Size register 
will report wrong size.. bigger as FIFO can handle. And only first ~40 
readet bytes will be actually OK.. all the rest of packet will be trashed.

But... i'm not 100% sure, if the FIFO as actually over filled, or host 
controller sending brocken data, or wrong timing...

There are flawing workarounds:
- reload xhci_hcd module.
- do USB_PHY reset, from firmware.
- use other host controller

It will be good if you can test it on you NEX xhci.

>
> However, I haven't heard back from Sarah or Seth about this matter
> (Added them to the CC. so "PLEASE" join if either of you think to
> have something to add about carl9170 transmit problem or ath9k_htc's
> suspend issue... of course, if it was fixed, then it would be really
> great to know which commit "fixed it"...)
>
> Regards
>
> Christian



-- 
Regards,
Oleksij

Re: FUSB200 xhci issue

[Christian Lamparter]

On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
> Am 22.07.2013 21:54, schrieb Christian Lamparter:
> > Hello!
> >
> > On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
> >> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
> >> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
> >> accidentally discovered that 9170 have it too. Are there any issue with
> >> usb-suspend + xhci controllers by you? Did you some how specially
> >> handled it?
> >
> > No, I haven't heard any complains about xhci + suspend. In fact,
> > it's working fine with the NEC xhci I have. I also have a AR9271
> > and AR7010, so if you want I could try if they survive a suspend
> > +resume cycle when attached.
> >
> > But, I do have a bug-report from someone else who has/had? problems
> > with carl9170 and xhci. If you want, you can get the details from:
> > "carl9170 A-MPDU transmit problem":
> > <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
> >
> > The likely cause is related to Intel's xhci silicon (Ivy Bridge is
> > affected, but I don't know about Haswell):
> > <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
> 
> Same situation is here - i have problem on Ivy Bridge.
(Note: I don't have any Ivy Bridge system. Just Sandy Bridge
and AMD's new A6-1450 Temash and both xhci work. So I can't
do any proper comparisons like you.)

> Steps to reproduce:
> - plug adapter. Module and firmware will be loaded
> - make sure usb autosupend is enabled. By default it is not! Use 
> powertop or directly sysfs to enable autosuspend for this device
> - rmmod .... and wait some seconds until adapter is suspended and then 
> modprobe ath9k_htc
> 
> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register 
> will report wrong size.. bigger as FIFO can handle. And only first ~40 
> readet bytes will be actually OK.. all the rest of packet will be trashed.

This is what happens with a WN721 (ar9271):

[17619.597905] usbcore: deregistering interface driver ath9k_htc
[17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
[17619.679602] ath9k_htc: Driver unloaded
<suspend>

<resume>
[17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
[17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
[17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
[17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
[17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
[17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
[17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
[17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
[17667.573873] usbcore: registered new interface driver ath9k_htc
[17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
[17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits

The driver loads, but there's no "wlanX" interface, no phyX interface
and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".

Regards

Christian

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 22.07.2013 23:23, schrieb Christian Lamparter:
> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
>> Am 22.07.2013 21:54, schrieb Christian Lamparter:
>>> Hello!
>>>
>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
>>>> accidentally discovered that 9170 have it too. Are there any issue with
>>>> usb-suspend + xhci controllers by you? Did you some how specially
>>>> handled it?
>>>
>>> No, I haven't heard any complains about xhci + suspend. In fact,
>>> it's working fine with the NEC xhci I have. I also have a AR9271
>>> and AR7010, so if you want I could try if they survive a suspend
>>> +resume cycle when attached.
>>>
>>> But, I do have a bug-report from someone else who has/had? problems
>>> with carl9170 and xhci. If you want, you can get the details from:
>>> "carl9170 A-MPDU transmit problem":
>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
>>>
>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
>>> affected, but I don't know about Haswell):
>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
>>
>> Same situation is here - i have problem on Ivy Bridge.
> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge
> and AMD's new A6-1450 Temash and both xhci work. So I can't
> do any proper comparisons like you.)
>
>> Steps to reproduce:
>> - plug adapter. Module and firmware will be loaded
>> - make sure usb autosupend is enabled. By default it is not! Use
>> powertop or directly sysfs to enable autosuspend for this device
>> - rmmod .... and wait some seconds until adapter is suspended and then
>> modprobe ath9k_htc

>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
>> will report wrong size.. bigger as FIFO can handle. And only first ~40
>> readet bytes will be actually OK.. all the rest of packet will be trashed.
>
> This is what happens with a WN721 (ar9271):
>
> [17619.597905] usbcore: deregistering interface driver ath9k_htc
> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
> [17619.679602] ath9k_htc: Driver unloaded
> <suspend>
>
> <resume>
> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
> [17667.573873] usbcore: registered new interface driver ath9k_htc
> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits
>
> The driver loads, but there's no "wlanX" interface, no phyX interface
> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".

So, it is exactly this bug.
After firmware was loaded ath9k trying to set some registers. Since 
command buffer is trashed it will write some nonsense to registers and 
some times in wrong to wrong addresses. I have some patches to do crc 
check of commands, to easy detect corrupted ones.

You reproduced it on NEC xhci? Is it possible to reproduce it in 
carl9170? How about "carl9170 A-MPDU transmit problem"?

I noticed one more workaround. By reducing skb size to 64byte for EP4, 
this bug can be avoided. But, since it works on EHCI, and on XHCI before 
usb-suspend, i would prefer to fix host controller driver.

-- 
Regards,
Oleksij

Re: FUSB200 xhci issue

[Christian Lamparter]

On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
> Am 22.07.2013 23:23, schrieb Christian Lamparter:
> > On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
> >> Am 22.07.2013 21:54, schrieb Christian Lamparter:
> >>> Hello!
> >>>
> >>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
> >>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
> >>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
> >>>> accidentally discovered that 9170 have it too. Are there any issue with
> >>>> usb-suspend + xhci controllers by you? Did you some how specially
> >>>> handled it?
> >>>
> >>> No, I haven't heard any complains about xhci + suspend. In fact,
> >>> it's working fine with the NEC xhci I have. I also have a AR9271
> >>> and AR7010, so if you want I could try if they survive a suspend
> >>> +resume cycle when attached.
> >>>
> >>> But, I do have a bug-report from someone else who has/had? problems
> >>> with carl9170 and xhci. If you want, you can get the details from:
> >>> "carl9170 A-MPDU transmit problem":
> >>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
> >>>
> >>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
> >>> affected, but I don't know about Haswell):
> >>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
> >>
> >> Same situation is here - i have problem on Ivy Bridge.
> > (Note: I don't have any Ivy Bridge system. Just Sandy Bridge
> > and AMD's new A6-1450 Temash and both xhci work. So I can't
> > do any proper comparisons like you.)
> >
> >> Steps to reproduce:
> >> - plug adapter. Module and firmware will be loaded
> >> - make sure usb autosupend is enabled. By default it is not! Use
> >> powertop or directly sysfs to enable autosuspend for this device
> >> - rmmod .... and wait some seconds until adapter is suspended and then
> >> modprobe ath9k_htc
> 
> >> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
> >> will report wrong size.. bigger as FIFO can handle. And only first ~40
> >> readet bytes will be actually OK.. all the rest of packet will be trashed.
> >
> > This is what happens with a WN721 (ar9271):
> >
> > [17619.597905] usbcore: deregistering interface driver ath9k_htc
> > [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
> > [17619.679602] ath9k_htc: Driver unloaded
> > <suspend>
> >
> > <resume>
> > [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
> > [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
> > [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
> > [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
> > [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
> > [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
> > [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
> > [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
> > [17667.573873] usbcore: registered new interface driver ath9k_htc
> > [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
> > [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits
> >
> > The driver loads, but there's no "wlanX" interface, no phyX interface
> > and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".
> 
> So, it is exactly this bug.
> After firmware was loaded ath9k trying to set some registers. Since 
> command buffer is trashed it will write some nonsense to registers and 
> some times in wrong to wrong addresses. I have some patches to do crc 
> check of commands, to easy detect corrupted ones.
> 
> You reproduced it on NEC xhci? Is it possible to reproduce it in 
> carl9170?

Ok: That's dmesg of your scenario:

[  809.995966] usbcore: deregistering interface driver carl9170
<suspend>

<resume>
[  826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd
[  826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900
[  826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940
[  826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980
[  826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0
[  826.432257] usbcore: registered new interface driver carl9170
[  826.433717] usb 2-2: driver   API: 1.9.8 2013-03-23 [1-1]
...
[  826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3'

carl9170 is able to recover and the stick is working after autosuspend cycle.

> How about "carl9170 A-MPDU transmit problem"?
This was already isolated. The "AMPDU transmit problem" only happens with 
Ivy Bridge's xhci.

Regards

Christian 

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 23.07.2013 20:26, schrieb Christian Lamparter:
> On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
>> Am 22.07.2013 23:23, schrieb Christian Lamparter:
>>> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
>>>> Am 22.07.2013 21:54, schrieb Christian Lamparter:
>>>>> Hello!
>>>>>
>>>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
>>>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
>>>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
>>>>>> accidentally discovered that 9170 have it too. Are there any issue with
>>>>>> usb-suspend + xhci controllers by you? Did you some how specially
>>>>>> handled it?
>>>>>
>>>>> No, I haven't heard any complains about xhci + suspend. In fact,
>>>>> it's working fine with the NEC xhci I have. I also have a AR9271
>>>>> and AR7010, so if you want I could try if they survive a suspend
>>>>> +resume cycle when attached.
>>>>>
>>>>> But, I do have a bug-report from someone else who has/had? problems
>>>>> with carl9170 and xhci. If you want, you can get the details from:
>>>>> "carl9170 A-MPDU transmit problem":
>>>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
>>>>>
>>>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
>>>>> affected, but I don't know about Haswell):
>>>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
>>>>
>>>> Same situation is here - i have problem on Ivy Bridge.
>>> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge
>>> and AMD's new A6-1450 Temash and both xhci work. So I can't
>>> do any proper comparisons like you.)
>>>
>>>> Steps to reproduce:
>>>> - plug adapter. Module and firmware will be loaded
>>>> - make sure usb autosupend is enabled. By default it is not! Use
>>>> powertop or directly sysfs to enable autosuspend for this device
>>>> - rmmod .... and wait some seconds until adapter is suspended and then
>>>> modprobe ath9k_htc
>>
>>>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
>>>> will report wrong size.. bigger as FIFO can handle. And only first ~40
>>>> readet bytes will be actually OK.. all the rest of packet will be trashed.
>>>
>>> This is what happens with a WN721 (ar9271):
>>>
>>> [17619.597905] usbcore: deregistering interface driver ath9k_htc
>>> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
>>> [17619.679602] ath9k_htc: Driver unloaded
>>> <suspend>
>>>
>>> <resume>
>>> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
>>> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
>>> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
>>> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
>>> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
>>> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
>>> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
>>> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
>>> [17667.573873] usbcore: registered new interface driver ath9k_htc
>>> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
>>> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits
>>>
>>> The driver loads, but there's no "wlanX" interface, no phyX interface
>>> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".
>>
>> So, it is exactly this bug.
>> After firmware was loaded ath9k trying to set some registers. Since
>> command buffer is trashed it will write some nonsense to registers and
>> some times in wrong to wrong addresses. I have some patches to do crc
>> check of commands, to easy detect corrupted ones.
>>
>> You reproduced it on NEC xhci? Is it possible to reproduce it in
>> carl9170?
>
> Ok: That's dmesg of your scenario:
>
> [  809.995966] usbcore: deregistering interface driver carl9170
> <suspend>
>
> <resume>
> [  826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd
> [  826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900
> [  826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940
> [  826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980
> [  826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0
> [  826.432257] usbcore: registered new interface driver carl9170
> [  826.433717] usb 2-2: driver   API: 1.9.8 2013-03-23 [1-1]
> ...
> [  826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3'
>
> carl9170 is able to recover and the stick is working after autosuspend cycle.

Thank you for your tests. USB configuration and handlers look similar on 
this two firmwares. May be problem is not in FUSB200 and it is clock 
related issue so carl9170 do not need reset. - I don't know :(

Can you please test this branch:
https://github.com/olerem/open-ath9k-htc-firmware/commits/next
There is a workaround to reset adapter, right after this bug is 
detected. It is really dirty hack, but currently i do not know how to 
fix this bug on xhci or on ath9k-htc side.

-- 
Regards,
Oleksij

Re: FUSB200 xhci issue

[Christian Lamparter]

On Wednesday, July 24, 2013 12:37:55 PM Oleksij Rempel wrote:
> Am 23.07.2013 20:26, schrieb Christian Lamparter:
> > On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
> >> Am 22.07.2013 23:23, schrieb Christian Lamparter:
> >>> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
> >>>> Am 22.07.2013 21:54, schrieb Christian Lamparter:
> >>>>> Hello!
> >>>>>
> >>>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
> >>>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
> >>>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
> >>>>>> accidentally discovered that 9170 have it too. Are there any issue with
> >>>>>> usb-suspend + xhci controllers by you? Did you some how specially
> >>>>>> handled it?
> >>>>>
> >>>>> No, I haven't heard any complains about xhci + suspend. In fact,
> >>>>> it's working fine with the NEC xhci I have. I also have a AR9271
> >>>>> and AR7010, so if you want I could try if they survive a suspend
> >>>>> +resume cycle when attached.
> >>>>>
> >>>>> But, I do have a bug-report from someone else who has/had? problems
> >>>>> with carl9170 and xhci. If you want, you can get the details from:
> >>>>> "carl9170 A-MPDU transmit problem":
> >>>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
> >>>>>
> >>>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
> >>>>> affected, but I don't know about Haswell):
> >>>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
> >>>>
> >>>> Same situation is here - i have problem on Ivy Bridge.
> >>> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge
> >>> and AMD's new A6-1450 Temash and both xhci work. So I can't
> >>> do any proper comparisons like you.)
> >>>
> >>>> Steps to reproduce:
> >>>> - plug adapter. Module and firmware will be loaded
> >>>> - make sure usb autosupend is enabled. By default it is not! Use
> >>>> powertop or directly sysfs to enable autosuspend for this device
> >>>> - rmmod .... and wait some seconds until adapter is suspended and then
> >>>> modprobe ath9k_htc
> >>
> >>>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
> >>>> will report wrong size.. bigger as FIFO can handle. And only first ~40
> >>>> readet bytes will be actually OK.. all the rest of packet will be trashed.
> >>>
> >>> This is what happens with a WN721 (ar9271):
> >>>
> >>> [17619.597905] usbcore: deregistering interface driver ath9k_htc
> >>> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
> >>> [17619.679602] ath9k_htc: Driver unloaded
> >>> <suspend>
> >>>
> >>> <resume>
> >>> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
> >>> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
> >>> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
> >>> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
> >>> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
> >>> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
> >>> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
> >>> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
> >>> [17667.573873] usbcore: registered new interface driver ath9k_htc
> >>> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
> >>> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits
> >>>
> >>> The driver loads, but there's no "wlanX" interface, no phyX interface
> >>> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".
> >>
> >> So, it is exactly this bug.
> >> After firmware was loaded ath9k trying to set some registers. Since
> >> command buffer is trashed it will write some nonsense to registers and
> >> some times in wrong to wrong addresses. I have some patches to do crc
> >> check of commands, to easy detect corrupted ones.
> >>
> >> You reproduced it on NEC xhci? Is it possible to reproduce it in
> >> carl9170?
> >
> > Ok: That's dmesg of your scenario:
> >
> > [  809.995966] usbcore: deregistering interface driver carl9170
> > <suspend>
> >
> > <resume>
> > [  826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd
> > [  826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900
> > [  826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940
> > [  826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980
> > [  826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0
> > [  826.432257] usbcore: registered new interface driver carl9170
> > [  826.433717] usb 2-2: driver   API: 1.9.8 2013-03-23 [1-1]
> > ...
> > [  826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3'
> >
> > carl9170 is able to recover and the stick is working after autosuspend cycle.
> 
> Thank you for your tests. USB configuration and handlers look similar on 
> this two firmwares. May be problem is not in FUSB200 and it is clock 
> related issue so carl9170 do not need reset. - I don't know :(
> 
> Can you please test this branch:
> https://github.com/olerem/open-ath9k-htc-firmware/commits/next
> There is a workaround to reset adapter, right after this bug is 
> detected. It is really dirty hack, but currently i do not know how to 
> fix this bug on xhci or on ath9k-htc side.
> 
Is it still Saturday?

Anyway, I tried the -next branch.

commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Wed Jul 24 10:26:18 2013 +0200

    k2_fw_usb_api: workaround for EP4 bug.

but still, the device won't show up after autosuspend.

regards,
	Chr

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 27.07.2013 23:59, schrieb Christian Lamparter:
> On Wednesday, July 24, 2013 12:37:55 PM Oleksij Rempel wrote:
>> Am 23.07.2013 20:26, schrieb Christian Lamparter:
>>> On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
>>>> Am 22.07.2013 23:23, schrieb Christian Lamparter:
>>>>> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
>>>>>> Am 22.07.2013 21:54, schrieb Christian Lamparter:
>>>>>>> Hello!
>>>>>>>
>>>>>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
>>>>>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
>>>>>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
>>>>>>>> accidentally discovered that 9170 have it too. Are there any issue with
>>>>>>>> usb-suspend + xhci controllers by you? Did you some how specially
>>>>>>>> handled it?
>>>>>>>
>>>>>>> No, I haven't heard any complains about xhci + suspend. In fact,
>>>>>>> it's working fine with the NEC xhci I have. I also have a AR9271
>>>>>>> and AR7010, so if you want I could try if they survive a suspend
>>>>>>> +resume cycle when attached.
>>>>>>>
>>>>>>> But, I do have a bug-report from someone else who has/had? problems
>>>>>>> with carl9170 and xhci. If you want, you can get the details from:
>>>>>>> "carl9170 A-MPDU transmit problem":
>>>>>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
>>>>>>>
>>>>>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
>>>>>>> affected, but I don't know about Haswell):
>>>>>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
>>>>>>
>>>>>> Same situation is here - i have problem on Ivy Bridge.
>>>>> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge
>>>>> and AMD's new A6-1450 Temash and both xhci work. So I can't
>>>>> do any proper comparisons like you.)
>>>>>
>>>>>> Steps to reproduce:
>>>>>> - plug adapter. Module and firmware will be loaded
>>>>>> - make sure usb autosupend is enabled. By default it is not! Use
>>>>>> powertop or directly sysfs to enable autosuspend for this device
>>>>>> - rmmod .... and wait some seconds until adapter is suspended and then
>>>>>> modprobe ath9k_htc
>>>>
>>>>>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
>>>>>> will report wrong size.. bigger as FIFO can handle. And only first ~40
>>>>>> readet bytes will be actually OK.. all the rest of packet will be trashed.
>>>>>
>>>>> This is what happens with a WN721 (ar9271):
>>>>>
>>>>> [17619.597905] usbcore: deregistering interface driver ath9k_htc
>>>>> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
>>>>> [17619.679602] ath9k_htc: Driver unloaded
>>>>> <suspend>
>>>>>
>>>>> <resume>
>>>>> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
>>>>> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
>>>>> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
>>>>> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
>>>>> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
>>>>> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
>>>>> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
>>>>> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
>>>>> [17667.573873] usbcore: registered new interface driver ath9k_htc
>>>>> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
>>>>> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits
>>>>>
>>>>> The driver loads, but there's no "wlanX" interface, no phyX interface
>>>>> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".
>>>>
>>>> So, it is exactly this bug.
>>>> After firmware was loaded ath9k trying to set some registers. Since
>>>> command buffer is trashed it will write some nonsense to registers and
>>>> some times in wrong to wrong addresses. I have some patches to do crc
>>>> check of commands, to easy detect corrupted ones.
>>>>
>>>> You reproduced it on NEC xhci? Is it possible to reproduce it in
>>>> carl9170?
>>>
>>> Ok: That's dmesg of your scenario:
>>>
>>> [  809.995966] usbcore: deregistering interface driver carl9170
>>> <suspend>
>>>
>>> <resume>
>>> [  826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd
>>> [  826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900
>>> [  826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940
>>> [  826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980
>>> [  826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0
>>> [  826.432257] usbcore: registered new interface driver carl9170
>>> [  826.433717] usb 2-2: driver   API: 1.9.8 2013-03-23 [1-1]
>>> ...
>>> [  826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3'
>>>
>>> carl9170 is able to recover and the stick is working after autosuspend cycle.
>>
>> Thank you for your tests. USB configuration and handlers look similar on
>> this two firmwares. May be problem is not in FUSB200 and it is clock
>> related issue so carl9170 do not need reset. - I don't know :(
>>
>> Can you please test this branch:
>> https://github.com/olerem/open-ath9k-htc-firmware/commits/next
>> There is a workaround to reset adapter, right after this bug is
>> detected. It is really dirty hack, but currently i do not know how to
>> fix this bug on xhci or on ath9k-htc side.
>>
> Is it still Saturday?
>
> Anyway, I tried the -next branch.
>
> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
> Author: Oleksij Rempel <linux@rempel-privat.de>
> Date:   Wed Jul 24 10:26:18 2013 +0200
>
>      k2_fw_usb_api: workaround for EP4 bug.
>
> but still, the device won't show up after autosuspend.

Hm... firmware probably didn't rebooted before suspend. Did interface 
was up, before autosuspend? If no, you need latest wireles-testing - 
there are patches to handle this issue. Or just make "ifconfig wlan1 up" 
  before  rmmod.
If it was up... then i would need last log messages from firmware.. If 
there is some way to attach to uart pins on it.

-- 
Regards,
Oleksij

Re: FUSB200 xhci issue

[Christian Lamparter]

On Sunday 28 July 2013 07:50:32 Oleksij Rempel wrote:
> Am 27.07.2013 23:59, schrieb Christian Lamparter:
> > On Wednesday, July 24, 2013 12:37:55 PM Oleksij Rempel wrote:
> >> Am 23.07.2013 20:26, schrieb Christian Lamparter:
> >>> On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
> >>>> Am 22.07.2013 23:23, schrieb Christian Lamparter:
> >>>>> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
> >>>>>> Am 22.07.2013 21:54, schrieb Christian Lamparter:
> >>>>>>> Hello!
> >>>>>>>
> >>>>>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
> >>>>>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
> >>>>>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
> >>>>>>>> accidentally discovered that 9170 have it too. Are there any issue with
> >>>>>>>> usb-suspend + xhci controllers by you? Did you some how specially
> >>>>>>>> handled it?
> >>>>>>>
> >>>>>>> No, I haven't heard any complains about xhci + suspend. In fact,
> >>>>>>> it's working fine with the NEC xhci I have. I also have a AR9271
> >>>>>>> and AR7010, so if you want I could try if they survive a suspend
> >>>>>>> +resume cycle when attached.
> >>>>>>>
> >>>>>>> But, I do have a bug-report from someone else who has/had? problems
> >>>>>>> with carl9170 and xhci. If you want, you can get the details from:
> >>>>>>> "carl9170 A-MPDU transmit problem":
> >>>>>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
> >>>>>>>
> >>>>>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
> >>>>>>> affected, but I don't know about Haswell):
> >>>>>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
> >>>>>>
> >>>>>> Same situation is here - i have problem on Ivy Bridge.
> >>>>> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge
> >>>>> and AMD's new A6-1450 Temash and both xhci work. So I can't
> >>>>> do any proper comparisons like you.)
> >>>>>
> >>>>>> Steps to reproduce:
> >>>>>> - plug adapter. Module and firmware will be loaded
> >>>>>> - make sure usb autosupend is enabled. By default it is not! Use
> >>>>>> powertop or directly sysfs to enable autosuspend for this device
> >>>>>> - rmmod .... and wait some seconds until adapter is suspended and then
> >>>>>> modprobe ath9k_htc
> >>>>
> >>>>>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
> >>>>>> will report wrong size.. bigger as FIFO can handle. And only first ~40
> >>>>>> readet bytes will be actually OK.. all the rest of packet will be trashed.
> >>>>>
> >>>>> This is what happens with a WN721 (ar9271):
> >>>>>
> >>>>> [17619.597905] usbcore: deregistering interface driver ath9k_htc
> >>>>> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
> >>>>> [17619.679602] ath9k_htc: Driver unloaded
> >>>>> <suspend>
> >>>>>
> >>>>> <resume>
> >>>>> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
> >>>>> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
> >>>>> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
> >>>>> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
> >>>>> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
> >>>>> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
> >>>>> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
> >>>>> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
> >>>>> [17667.573873] usbcore: registered new interface driver ath9k_htc
> >>>>> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
> >>>>> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits
> >>>>>
> >>>>> The driver loads, but there's no "wlanX" interface, no phyX interface
> >>>>> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".
> >>>>
> >>>> So, it is exactly this bug.
> >>>> After firmware was loaded ath9k trying to set some registers. Since
> >>>> command buffer is trashed it will write some nonsense to registers and
> >>>> some times in wrong to wrong addresses. I have some patches to do crc
> >>>> check of commands, to easy detect corrupted ones.
> >>>>
> >>>> You reproduced it on NEC xhci? Is it possible to reproduce it in
> >>>> carl9170?
> >>>
> >>> Ok: That's dmesg of your scenario:
> >>>
> >>> [  809.995966] usbcore: deregistering interface driver carl9170
> >>> <suspend>
> >>>
> >>> <resume>
> >>> [  826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd
> >>> [  826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900
> >>> [  826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940
> >>> [  826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980
> >>> [  826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0
> >>> [  826.432257] usbcore: registered new interface driver carl9170
> >>> [  826.433717] usb 2-2: driver   API: 1.9.8 2013-03-23 [1-1]
> >>> ...
> >>> [  826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3'
> >>>
> >>> carl9170 is able to recover and the stick is working after autosuspend cycle.
> >>
> >> Thank you for your tests. USB configuration and handlers look similar on
> >> this two firmwares. May be problem is not in FUSB200 and it is clock
> >> related issue so carl9170 do not need reset. - I don't know :(
> >>
> >> Can you please test this branch:
> >> https://github.com/olerem/open-ath9k-htc-firmware/commits/next
> >> There is a workaround to reset adapter, right after this bug is
> >> detected. It is really dirty hack, but currently i do not know how to
> >> fix this bug on xhci or on ath9k-htc side.
> >>
> > Is it still Saturday?
> >
> > Anyway, I tried the -next branch.
> >
> > commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
> > Author: Oleksij Rempel <linux@rempel-privat.de>
> > Date:   Wed Jul 24 10:26:18 2013 +0200
> >
> >      k2_fw_usb_api: workaround for EP4 bug.
> >
> > but still, the device won't show up after autosuspend.
> 
> Hm... firmware probably didn't rebooted before suspend. Did interface 
> was up, before autosuspend? If no, you need latest wireles-testing - 
> there are patches to handle this issue. Or just make "ifconfig wlan1 up" 
>   before  rmmod.
Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module
had the patch "ath9k_htc: reboot firmwware if it was loaded").

Furthermore, I did the same test with one of the ehci-only ports
and it worked. Both, devices (one had a AR7015, the other a AR9271)
came back after autosuspend there.

> then i would need last log messages from firmware.. If  there is
> some way to attach to uart pins on it.
Sorry, I can't really help you there as I don't have the
necessary tools. But I would be happy to test patches.

Regards,
	Chr

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 28.07.2013 13:38, schrieb Christian Lamparter:

>>>
>>> Anyway, I tried the -next branch.
>>>
>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
>>> Author: Oleksij Rempel <linux@rempel-privat.de>
>>> Date:   Wed Jul 24 10:26:18 2013 +0200
>>>
>>>       k2_fw_usb_api: workaround for EP4 bug.
>>>
>>> but still, the device won't show up after autosuspend.
>>
>> Hm... firmware probably didn't rebooted before suspend. Did interface
>> was up, before autosuspend? If no, you need latest wireles-testing -
>> there are patches to handle this issue. Or just make "ifconfig wlan1 up"
>>    before  rmmod.
> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module
> had the patch "ath9k_htc: reboot firmwware if it was loaded").
>
> Furthermore, I did the same test with one of the ehci-only ports
> and it worked. Both, devices (one had a AR7015, the other a AR9271)
> came back after autosuspend there.

Grrr... so it brings us back to xhci issue. Even EP4 workaround wont 
work here :( Suddenly i have no more ideas.

Sarah, it's your turn now.
-- 
Regards,
Oleksij

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 28.07.2013 14:12, schrieb Oleksij Rempel:
> Am 28.07.2013 13:38, schrieb Christian Lamparter:
>
>>>>
>>>> Anyway, I tried the -next branch.
>>>>
>>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
>>>> Author: Oleksij Rempel <linux@rempel-privat.de>
>>>> Date:   Wed Jul 24 10:26:18 2013 +0200
>>>>
>>>>       k2_fw_usb_api: workaround for EP4 bug.
>>>>
>>>> but still, the device won't show up after autosuspend.
>>>
>>> Hm... firmware probably didn't rebooted before suspend. Did interface
>>> was up, before autosuspend? If no, you need latest wireles-testing -
>>> there are patches to handle this issue. Or just make "ifconfig wlan1 up"
>>>    before  rmmod.
>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module
>> had the patch "ath9k_htc: reboot firmwware if it was loaded").
>>
>> Furthermore, I did the same test with one of the ehci-only ports
>> and it worked. Both, devices (one had a AR7015, the other a AR9271)
>> came back after autosuspend there.
>
> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
> work here :( Suddenly i have no more ideas.
>
> Sarah, it's your turn now.


Christian,
can you please provide some more info about your xhci controller. I'll 
try to get me same.

-- 
Regards,
Oleksij

Re: FUSB200 xhci issue

[Christian Lamparter]

On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
> Am 28.07.2013 14:12, schrieb Oleksij Rempel:
> > Am 28.07.2013 13:38, schrieb Christian Lamparter:
> >
> >>>>
> >>>> Anyway, I tried the -next branch.
> >>>>
> >>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
> >>>> Author: Oleksij Rempel <linux@rempel-privat.de>
> >>>> Date:   Wed Jul 24 10:26:18 2013 +0200
> >>>>
> >>>>       k2_fw_usb_api: workaround for EP4 bug.
> >>>>
> >>>> but still, the device won't show up after autosuspend.
> >>>
> >>> Hm... firmware probably didn't rebooted before suspend. Did interface
> >>> was up, before autosuspend? If no, you need latest wireles-testing -
> >>> there are patches to handle this issue. Or just make "ifconfig wlan1 up"
> >>>    before  rmmod.
> >> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module
> >> had the patch "ath9k_htc: reboot firmwware if it was loaded").
> >>
> >> Furthermore, I did the same test with one of the ehci-only ports
> >> and it worked. Both, devices (one had a AR7015, the other a AR9271)
> >> came back after autosuspend there.
> >
> > Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
> > work here :( Suddenly i have no more ideas.
> >
> > Sarah, it's your turn now.
> 
> Christian,
> can you please provide some more info about your xhci controller. I'll 
> try to get me same.

Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the
same setup will be difficult. However, since the uPD720200 was/is
very popular, it should be very easy to find one. [It's probably
on all of these "10 euro usb-3.0 pcie-adapters". So as long as you
got a free 1x-pcie port you should be good.]

Here's the lspci summary:

19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04) (prog-if 30 [XHCI])
        Subsystem: Hewlett-Packard Company Device [103c:1657]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at d3400000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: <access denied>
        Kernel driver in use: xhci_hcd

Regards,
	Chr

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 28.07.2013 22:41, schrieb Christian Lamparter:
> On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
>> Am 28.07.2013 14:12, schrieb Oleksij Rempel:
>>> Am 28.07.2013 13:38, schrieb Christian Lamparter:
>>>
>>>>>>
>>>>>> Anyway, I tried the -next branch.
>>>>>>
>>>>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
>>>>>> Author: Oleksij Rempel <linux@rempel-privat.de>
>>>>>> Date:   Wed Jul 24 10:26:18 2013 +0200
>>>>>>
>>>>>>        k2_fw_usb_api: workaround for EP4 bug.
>>>>>>
>>>>>> but still, the device won't show up after autosuspend.
>>>>>
>>>>> Hm... firmware probably didn't rebooted before suspend. Did interface
>>>>> was up, before autosuspend? If no, you need latest wireles-testing -
>>>>> there are patches to handle this issue. Or just make "ifconfig wlan1 up"
>>>>>     before  rmmod.
>>>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module
>>>> had the patch "ath9k_htc: reboot firmwware if it was loaded").
>>>>
>>>> Furthermore, I did the same test with one of the ehci-only ports
>>>> and it worked. Both, devices (one had a AR7015, the other a AR9271)
>>>> came back after autosuspend there.
>>>
>>> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
>>> work here :( Suddenly i have no more ideas.
>>>
>>> Sarah, it's your turn now.
>>
>> Christian,
>> can you please provide some more info about your xhci controller. I'll
>> try to get me same.
>
> Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the
> same setup will be difficult. However, since the uPD720200 was/is
> very popular, it should be very easy to find one. [It's probably
> on all of these "10 euro usb-3.0 pcie-adapters". So as long as you
> got a free 1x-pcie port you should be good.]
>
> Here's the lspci summary:
>
> 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04) (prog-if 30 [XHCI])
>          Subsystem: Hewlett-Packard Company Device [103c:1657]
>          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>          Latency: 0, Cache Line Size: 64 bytes
>          Interrupt: pin A routed to IRQ 19
>          Region 0: Memory at d3400000 (64-bit, non-prefetchable) [size=8K]
>          Capabilities: <access denied>
>          Kernel driver in use: xhci_hcd
>

Thx... i purchased on random on ebay, will see what i get.

I know now why carl9170 don't triggering this bug. Carl uses EP4 as 
Interrupt with packet size 64. ath9k-htc initially have EP4=Intr, 
Interval=1, but will reconfigure it to Bulk, Interval=0.
It mean, before usb suspend EP4=Bulk, Interval=0 and after resume 
EP4=Intr, Inter=?. May be xhci can't handle some thing like this? Or may 
be interval stay 0, and xhci will overfill usb buffer on adapter - at 
least it looks so.


-- 
Regards,
Oleksij

Re: FUSB200 xhci issue

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]

Am 31.07.2013 08:52, schrieb Oleksij Rempel:
> Am 28.07.2013 22:41, schrieb Christian Lamparter:
>> On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
>>> Am 28.07.2013 14:12, schrieb Oleksij Rempel:
>>>> Am 28.07.2013 13:38, schrieb Christian Lamparter:
>>>>
>>>>>>     before  rmmod.
>>>>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc"
>>>>> module
>>>>> had the patch "ath9k_htc: reboot firmwware if it was loaded").
>>>>>
>>>>> Furthermore, I did the same test with one of the ehci-only ports
>>>>> and it worked. Both, devices (one had a AR7015, the other a AR9271)
>>>>> came back after autosuspend there.
>>>>
>>>> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
>>>> work here :( Suddenly i have no more ideas.
>>>>
>>>> Sarah, it's your turn now.
>>>
>>> Christian,
>>> can you please provide some more info about your xhci controller. I'll
>>> try to get me same.
>>
>> Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the
>> same setup will be difficult. However, since the uPD720200 was/is
>> very popular, it should be very easy to find one. [It's probably
>> on all of these "10 euro usb-3.0 pcie-adapters". So as long as you
>> got a free 1x-pcie port you should be good.]
>>
>> Here's the lspci summary:
>>
>> 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host
>> Controller [1033:0194] (rev 04) (prog-if 30 [XHCI])
>>          Subsystem: Hewlett-Packard Company Device [103c:1657]
>>          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx+
>>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
>> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>          Latency: 0, Cache Line Size: 64 bytes
>>          Interrupt: pin A routed to IRQ 19
>>          Region 0: Memory at d3400000 (64-bit, non-prefetchable)
>> [size=8K]
>>          Capabilities: <access denied>
>>          Kernel driver in use: xhci_hcd
>>
>
> Thx... i purchased on random on ebay, will see what i get.
>
> I know now why carl9170 don't triggering this bug. Carl uses EP4 as
> Interrupt with packet size 64. ath9k-htc initially have EP4=Intr,
> Interval=1, but will reconfigure it to Bulk, Interval=0.
> It mean, before usb suspend EP4=Bulk, Interval=0 and after resume
> EP4=Intr, Inter=?. May be xhci can't handle some thing like this? Or may
> be interval stay 0, and xhci will overfill usb buffer on adapter - at
> least it looks so.

Christian,
can you please test one more patch. It is working for me, but who knows. 
More testing is never bad idea ;)

-- 
Regards,
Oleksij

[-- Attachment #2: interval.diff --]
[-- Type: text/x-patch, Size: 510 bytes --]

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 5205a36..6f4f39c 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1053,7 +1053,7 @@ static int ath9k_hif_usb_dev_init(struct hif_device_usb *hif_dev)
 				== USB_ENDPOINT_XFER_INT) {
 			endp->bmAttributes &= ~USB_ENDPOINT_XFERTYPE_MASK;
 			endp->bmAttributes |= USB_ENDPOINT_XFER_BULK;
-			endp->bInterval = 0;
+	//		endp->bInterval = 0;
 		}
 	}
 

Re: FUSB200 xhci issue

[Christian Lamparter]

On Thursday 08 August 2013 17:35:34 Oleksij Rempel wrote:
> Am 31.07.2013 08:52, schrieb Oleksij Rempel:
> > Am 28.07.2013 22:41, schrieb Christian Lamparter:
> >> On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
> >>> Am 28.07.2013 14:12, schrieb Oleksij Rempel:
> >>>> Am 28.07.2013 13:38, schrieb Christian Lamparter:
> >>>>
> >>>>>>     before  rmmod.
> >>>>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc"
> >>>>> module
> >>>>> had the patch "ath9k_htc: reboot firmwware if it was loaded").
> >>>>>
> >>>>> Furthermore, I did the same test with one of the ehci-only ports
> >>>>> and it worked. Both, devices (one had a AR7015, the other a AR9271)
> >>>>> came back after autosuspend there.
> >>>>
> >>>> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
> >>>> work here :( Suddenly i have no more ideas.
> >>>>
> >>>> Sarah, it's your turn now.
> >>>
> >>> Christian,
> >>> can you please provide some more info about your xhci controller. I'll
> >>> try to get me same.
> >>
> >> Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the
> >> same setup will be difficult. However, since the uPD720200 was/is
> >> very popular, it should be very easy to find one. [It's probably
> >> on all of these "10 euro usb-3.0 pcie-adapters". So as long as you
> >> got a free 1x-pcie port you should be good.]
> >>
> >> Here's the lspci summary:
> >>
> >> 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host
> >> Controller [1033:0194] (rev 04) (prog-if 30 [XHCI])
> >>          Subsystem: Hewlett-Packard Company Device [103c:1657]
> >>          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> >> ParErr- Stepping- SERR- FastB2B- DisINTx+
> >>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
> >> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> >>          Latency: 0, Cache Line Size: 64 bytes
> >>          Interrupt: pin A routed to IRQ 19
> >>          Region 0: Memory at d3400000 (64-bit, non-prefetchable)
> >> [size=8K]
> >>          Capabilities: <access denied>
> >>          Kernel driver in use: xhci_hcd
> >>
> >
> > Thx... i purchased on random on ebay, will see what i get.
> >
> > I know now why carl9170 don't triggering this bug. Carl uses EP4 as
> > Interrupt with packet size 64. ath9k-htc initially have EP4=Intr,
> > Interval=1, but will reconfigure it to Bulk, Interval=0.
> > It mean, before usb suspend EP4=Bulk, Interval=0 and after resume
> > EP4=Intr, Inter=?. May be xhci can't handle some thing like this? Or may
> > be interval stay 0, and xhci will overfill usb buffer on adapter - at
> > least it looks so.
> 
> Christian,
> can you please test one more patch. It is working for me, but who knows. 
> More testing is never bad idea ;)

It sort of works, but not without a hiccup: 

I get the following messages when I try to load the driver
again after an autosuspend cycle (ar9271, NEC xhci):

ath: phy6: Reading Magic # failed
ath9k_htc: Failed to Initialize the device
usb 2-1: ath9k_htc: USB layer deinitialized
....

However, the device is resetted automatically and it
comes back on the second probe attempt.



Anyway, I do have a question about something else too.

in ath9k_htc's hif_usb:

> struct usb_host_interface *alt = &hif_dev->interface->altsetting[0];
> struct usb_endpoint_descriptor *endp;
> ...
> /* On downloading the firmware to the target, the USB descriptor of EP4
>  * is 'patched' to change the type of the endpoint to Bulk. This will
>  * bring down CPU usage during the scan period. */
>
> for (idx = 0; idx < alt->desc.bNumEndpoints; idx++) {
>   endp = &alt->endpoint[idx].desc;
>   if ((endp->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) {
>     endp->bmAttributes &= ~USB_ENDPOINT_XFERTYPE_MASK;
>     endp->bmAttributes |= USB_ENDPOINT_XFER_BULK;
>//     endp->bInterval = 0;
>   }
> }

Alan, can you please tell us, if it is really safe to
override the bmAttributes this way? After all (according to
the comment) the device has "morphed" (EP4 has changed).

Or, is it necessary for the driver call "usb_reset_device"
or (usb_reset_configuration) in this case? 

Regards,
   Chr

Re: FUSB200 xhci issue

[Alan Stern]

On Thu, 8 Aug 2013, Christian Lamparter wrote:

> Anyway, I do have a question about something else too.
> 
> in ath9k_htc's hif_usb:
> 
> > struct usb_host_interface *alt = &hif_dev->interface->altsetting[0];
> > struct usb_endpoint_descriptor *endp;
> > ...
> > /* On downloading the firmware to the target, the USB descriptor of EP4
> >  * is 'patched' to change the type of the endpoint to Bulk. This will
> >  * bring down CPU usage during the scan period. */
> >
> > for (idx = 0; idx < alt->desc.bNumEndpoints; idx++) {
> >   endp = &alt->endpoint[idx].desc;
> >   if ((endp->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) {
> >     endp->bmAttributes &= ~USB_ENDPOINT_XFERTYPE_MASK;
> >     endp->bmAttributes |= USB_ENDPOINT_XFER_BULK;
> >//     endp->bInterval = 0;
> >   }
> > }
> 
> Alan, can you please tell us, if it is really safe to
> override the bmAttributes this way? After all (according to
> the comment) the device has "morphed" (EP4 has changed).

This does not look like a good idea.  Why does the driver do it?

> Or, is it necessary for the driver call "usb_reset_device"
> or (usb_reset_configuration) in this case? 

After loading firmware, a reset generally is necessary.  Some devices 
will do it themselves; others require you to call usb_reset_device().

Alan Stern

Re: FUSB200 xhci issue

[Christian Lamparter]

On Thursday 08 August 2013 22:19:32 Alan Stern wrote:
> On Thu, 8 Aug 2013, Christian Lamparter wrote:
> 
> > Anyway, I do have a question about something else too.
> > 
> > in ath9k_htc's hif_usb:
> > 
> > > struct usb_host_interface *alt = &hif_dev->interface->altsetting[0];
> > > struct usb_endpoint_descriptor *endp;
> > > ...
> > > /* On downloading the firmware to the target, the USB descriptor of EP4
> > >  * is 'patched' to change the type of the endpoint to Bulk. This will
> > >  * bring down CPU usage during the scan period. */
> > >
> > > for (idx = 0; idx < alt->desc.bNumEndpoints; idx++) {
> > >   endp = &alt->endpoint[idx].desc;
> > >   if ((endp->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) {
> > >     endp->bmAttributes &= ~USB_ENDPOINT_XFERTYPE_MASK;
> > >     endp->bmAttributes |= USB_ENDPOINT_XFER_BULK;
> > >//     endp->bInterval = 0;
> > >   }
> > > }
> > 
> > Alan, can you please tell us, if it is really safe to
> > override the bmAttributes this way? After all (according to
> > the comment) the device has "morphed" (EP4 has changed).
> 
> This does not look like a good idea.  Why does the driver do it?

Probably because people use ath9k_htc devices with everything that
has some sort of usb port (devkits and embedded systems: Dockstar,
Rasberry Pi, ...) to get "wifi connectivity". ...


Yeah. I think we better ask "Rajkumar Manoharan" 
(before I write more text out of thin air :-D )

commit 4a0e8ecca4eeed38d4b3b7a317a3aaab4dd3cacd
Author: Rajkumar Manoharan <rmanoharan@atheros.com>
Date:   Tue Sep 14 14:35:55 2010 +0530

    ath9k_htc: Fix CPU usage issue during scan period

Does anyone know his Qualcomm Atheros address?
 
> > Or, is it necessary for the driver call "usb_reset_device"
> > or (usb_reset_configuration) in this case? 
> 
> After loading firmware, a reset generally is necessary.  Some devices 
> will do it themselves; others require you to call usb_reset_device().

This makes things complicated. Because, as far as I remember,
usb_reset_device() will cause the current driver to be unbound
unless its called during .probe, right?

You see, ath9k_htc loads its firmware asynchronously in ".probe"
(ath9k_htc's .probe routine finishes before the firmware is
retrieved via the firmware loader helper... so part of the
firmware download is done in a firmware_complete callback
on a workqueue). 

So, if we call usb_reset_device there and the driver is unbound
and later rebound. the next ath9k_htc .probe will start again and
again and again not knowing that it is already initialized 
(and we have a loop).


This could be solved, if the devices changes the usb-id again 
when a proper "wifi" ath9k_htc firmware was downloaded. So, the
driver would know that it doesn't have to download and reset
the device... But we need a "free" USB-ID for that.

Alan, Oleksij: What do you think?

Regards,
	Chr

Re: FUSB200 xhci issue

[Sujith Manoharan]

Christian Lamparter wrote:
> So, if we call usb_reset_device there and the driver is unbound
> and later rebound. the next ath9k_htc .probe will start again and
> again and again not knowing that it is already initialized 
> (and we have a loop).

The HW/FW is buggy and this workaround is required:
http://marc.info/?l=linux-usb&m=127960864905646&w=2

Sujith

ath9k_htc firmware problem [was: Re: FUSB200 xhci issue]

[Alan Stern]

On Fri, 9 Aug 2013, Sujith Manoharan wrote:

> Christian Lamparter wrote:
> > So, if we call usb_reset_device there and the driver is unbound
> > and later rebound. the next ath9k_htc .probe will start again and
> > again and again not knowing that it is already initialized 
> > (and we have a loop).
> 
> The HW/FW is buggy and this workaround is required:
> http://marc.info/?l=linux-usb&m=127960864905646&w=2

I see the problem.  The device loses its firmware when it gets reset or
its port is disabled.  This is really a very serious bug.  For one
thing, it means the device cannot support runtime PM.  (Not unless the
driver caches a copy of the firmware and reloads it every time the
device resumes.)  IMO a bug like this should disqualify the device from
being allowed to wear the USB logo.

One way around the problem might be for the firmware-loading thread to
issue a usb_set_configuration call to switch to config 0 (i.e., to
unconfigure the device), then patch the host's copy of the descriptor,
and then switch back to the original configuration.

This _will_ unbind and rebind the driver, so it definitely will need a
way to tell whether the firmware has already been loaded.

Alan Stern

Re: FUSB200 xhci issue

[Alan Stern]

On Fri, 9 Aug 2013, Christian Lamparter wrote:

> > After loading firmware, a reset generally is necessary.  Some devices 
> > will do it themselves; others require you to call usb_reset_device().
> 
> This makes things complicated. Because, as far as I remember,
> usb_reset_device() will cause the current driver to be unbound
> unless its called during .probe, right?

If the driver defines pre_reset and post_reset methods, it won't get 
unbound during a reset.

> You see, ath9k_htc loads its firmware asynchronously in ".probe"
> (ath9k_htc's .probe routine finishes before the firmware is
> retrieved via the firmware loader helper... so part of the
> firmware download is done in a firmware_complete callback
> on a workqueue). 
> 
> So, if we call usb_reset_device there and the driver is unbound
> and later rebound. the next ath9k_htc .probe will start again and
> again and again not knowing that it is already initialized 
> (and we have a loop).
> 
> 
> This could be solved, if the devices changes the usb-id again 
> when a proper "wifi" ath9k_htc firmware was downloaded. So, the
> driver would know that it doesn't have to download and reset
> the device... But we need a "free" USB-ID for that.

What about a "get firmware version" sort of thing?  There really should 
be a way for the driver to tell whether the firmware has already been 
updated.

Alan Stern

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 09.08.2013 16:13, schrieb Alan Stern:
> On Fri, 9 Aug 2013, Christian Lamparter wrote:
>
>>> After loading firmware, a reset generally is necessary.  Some devices
>>> will do it themselves; others require you to call usb_reset_device().
>>
>> This makes things complicated. Because, as far as I remember,
>> usb_reset_device() will cause the current driver to be unbound
>> unless its called during .probe, right?
>
> If the driver defines pre_reset and post_reset methods, it won't get
> unbound during a reset.
>
>> You see, ath9k_htc loads its firmware asynchronously in ".probe"
>> (ath9k_htc's .probe routine finishes before the firmware is
>> retrieved via the firmware loader helper... so part of the
>> firmware download is done in a firmware_complete callback
>> on a workqueue).
>>
>> So, if we call usb_reset_device there and the driver is unbound
>> and later rebound. the next ath9k_htc .probe will start again and
>> again and again not knowing that it is already initialized
>> (and we have a loop).
>>
>>
>> This could be solved, if the devices changes the usb-id again
>> when a proper "wifi" ath9k_htc firmware was downloaded. So, the
>> driver would know that it doesn't have to download and reset
>> the device... But we need a "free" USB-ID for that.
>
> What about a "get firmware version" sort of thing?  There really should
> be a way for the driver to tell whether the firmware has already been
> updated.

I was not able to find good direct way to check firmware version. If i 
would add some new command then i will get option like: if responding FW 
is updated; if not, then dead or old.
How about overwriting iProduct field? Let say, if iProduct == ath9k_htc, 
then firmware is updated? Is it more or less acceptable method? I need 
to ask this because it is really new for me.
-- 
Regards,
Oleksij

Re: FUSB200 xhci issue

[Alan Stern]

On Fri, 9 Aug 2013, Oleksij Rempel wrote:

> > What about a "get firmware version" sort of thing?  There really should
> > be a way for the driver to tell whether the firmware has already been
> > updated.
> 
> I was not able to find good direct way to check firmware version. If i 
> would add some new command then i will get option like: if responding FW 
> is updated; if not, then dead or old.
> How about overwriting iProduct field? Let say, if iProduct == ath9k_htc, 
> then firmware is updated? Is it more or less acceptable method? I need 
> to ask this because it is really new for me.

Changing the iProduct string descriptor would work, because the 
descriptors_changed() routine doesn't compare the old value of that 
string with the new value.  (On the other hand, it does compare the 
iSerialNumber strings.)

Is there any way to read the firmware back from the device?  Then you 
could check directly.

Alan Stern

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 09.08.2013 16:52, schrieb Alan Stern:
> On Fri, 9 Aug 2013, Oleksij Rempel wrote:
>
>>> What about a "get firmware version" sort of thing?  There really should
>>> be a way for the driver to tell whether the firmware has already been
>>> updated.
>>
>> I was not able to find good direct way to check firmware version. If i
>> would add some new command then i will get option like: if responding FW
>> is updated; if not, then dead or old.
>> How about overwriting iProduct field? Let say, if iProduct == ath9k_htc,
>> then firmware is updated? Is it more or less acceptable method? I need
>> to ask this because it is really new for me.
>
> Changing the iProduct string descriptor would work, because the
> descriptors_changed() routine doesn't compare the old value of that
> string with the new value.  (On the other hand, it does compare the
> iSerialNumber strings.)

Just to make sure. You mean, i should avoid changing iSerialNumber 
because host will initiate usb reset and this device will probably not 
survive it?

> Is there any way to read the firmware back from the device?  Then you
> could check directly.

No, this device is a SoC with usb client interface based on FUSB200 core 
(If i'm correct, same core as on carl9170 devices). We can't read memory 
unless FW provide this service.
At power on, this device will boot from external or internal ROM and 
load minimal FW. Without it, USB wont work.
If i read FW code correctly, it should be responsible for suspend and reset.
I do not have documentation, so created doc[1] based on code. From what 
is see, i assume that we can reset usb from FW. There is at least two 
methods:
- reset complete USB core. It looks for me like brute force, since we 
will need completely reconfigure usb core.
- use TEST registers? ZM_TEST_OFFSET or ZM_PHY_TEST_SELECT_OFFSET - i 
didn't played with it. So it is just assumption.
- other regs?


[1] https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-regs
-- 
Regards,
Oleksij

Re: FUSB200 xhci issue

[Alan Stern]

On Fri, 9 Aug 2013, Oleksij Rempel wrote:

> Am 09.08.2013 16:52, schrieb Alan Stern:
> > On Fri, 9 Aug 2013, Oleksij Rempel wrote:
> >
> >>> What about a "get firmware version" sort of thing?  There really should
> >>> be a way for the driver to tell whether the firmware has already been
> >>> updated.
> >>
> >> I was not able to find good direct way to check firmware version. If i
> >> would add some new command then i will get option like: if responding FW
> >> is updated; if not, then dead or old.
> >> How about overwriting iProduct field? Let say, if iProduct == ath9k_htc,
> >> then firmware is updated? Is it more or less acceptable method? I need
> >> to ask this because it is really new for me.
> >
> > Changing the iProduct string descriptor would work, because the
> > descriptors_changed() routine doesn't compare the old value of that
> > string with the new value.  (On the other hand, it does compare the
> > iSerialNumber strings.)
> 
> Just to make sure. You mean, i should avoid changing iSerialNumber 
> because host will initiate usb reset and this device will probably not 
> survive it?

Right.  If the device would survive a reset then there would be no 
problem.

BTW, it is common for new firmware to change the bcdDevice value in the 
device descriptor.  That might be easier than changing a string 
descriptor.

> > Is there any way to read the firmware back from the device?  Then you
> > could check directly.
> 
> No, this device is a SoC with usb client interface based on FUSB200 core 
> (If i'm correct, same core as on carl9170 devices). We can't read memory 
> unless FW provide this service.
> At power on, this device will boot from external or internal ROM and 
> load minimal FW. Without it, USB wont work.
> If i read FW code correctly, it should be responsible for suspend and reset.

How do you tell the device to start running the new firmware after it 
is loaded?  Normally this requires some sort of reset.

Is there any way to prevent the device from losing its firmware during 
a USB reset or suspend?

Alan Stern

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 09.08.2013 19:16, schrieb Alan Stern:
> On Fri, 9 Aug 2013, Oleksij Rempel wrote:
>
>> Am 09.08.2013 16:52, schrieb Alan Stern:
>>> On Fri, 9 Aug 2013, Oleksij Rempel wrote:
>>>
>>>>> What about a "get firmware version" sort of thing?  There really should
>>>>> be a way for the driver to tell whether the firmware has already been
>>>>> updated.
>>>>
>>>> I was not able to find good direct way to check firmware version. If i
>>>> would add some new command then i will get option like: if responding FW
>>>> is updated; if not, then dead or old.
>>>> How about overwriting iProduct field? Let say, if iProduct == ath9k_htc,
>>>> then firmware is updated? Is it more or less acceptable method? I need
>>>> to ask this because it is really new for me.
>>>
>>> Changing the iProduct string descriptor would work, because the
>>> descriptors_changed() routine doesn't compare the old value of that
>>> string with the new value.  (On the other hand, it does compare the
>>> iSerialNumber strings.)
>>
>> Just to make sure. You mean, i should avoid changing iSerialNumber
>> because host will initiate usb reset and this device will probably not
>> survive it?
>
> Right.  If the device would survive a reset then there would be no
> problem.
>
> BTW, it is common for new firmware to change the bcdDevice value in the
> device descriptor.  That might be easier than changing a string
> descriptor.
>
>>> Is there any way to read the firmware back from the device?  Then you
>>> could check directly.
>>
>> No, this device is a SoC with usb client interface based on FUSB200 core
>> (If i'm correct, same core as on carl9170 devices). We can't read memory
>> unless FW provide this service.
>> At power on, this device will boot from external or internal ROM and
>> load minimal FW. Without it, USB wont work.
>> If i read FW code correctly, it should be responsible for suspend and reset.
>
> How do you tell the device to start running the new firmware after it
> is loaded?  Normally this requires some sort of reset.

There are two vendor commands cUSB_REQ_DOWNLOAD and 
cUSB_REQ_DOWNLOAD_COMP. With cUSB_REQ_DOWNLOAD firmware will be uploaded 
and cUSB_REQ_DOWNLOAD_COMP should just jump to first address of the 
firmware.

This system has micro modular structure. Firmware can register own 
modules. Or relink modules of bootloader, but this is limited only to 
existing api.

> Is there any way to prevent the device from losing its firmware during
> a USB reset or suspend?

For suspend - yes. It is possible to ignore suspend command or put the 
SoC in low power mode - but is it probably not so easy to bring it back. 
I would need to read more code and create some doc as side effect untill 
i understand how it works.
I'm not sure how about reset command. I would need more testing and some 
ones help. If i see it correctly, usb reset should affect only usb core 
and usb pll.

How can i trigger usb reset?

-- 
Regards,
Oleksij

Re: FUSB200 xhci issue

[Alan Stern]

On Fri, 9 Aug 2013, Oleksij Rempel wrote:

> > Is there any way to prevent the device from losing its firmware during
> > a USB reset or suspend?
> 
> For suspend - yes. It is possible to ignore suspend command or put the 
> SoC in low power mode - but is it probably not so easy to bring it back. 
> I would need to read more code and create some doc as side effect untill 
> i understand how it works.
> I'm not sure how about reset command. I would need more testing and some 
> ones help. If i see it correctly, usb reset should affect only usb core 
> and usb pll.
> 
> How can i trigger usb reset?

http://marc.info/?l=linux-usb&m=121459435621262&w=2

Give the program the pathname for the USB device node.  For example:

	usbreset /dev/bus/usb/001/004

Alan Stern

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 09.08.2013 21:32, schrieb Alan Stern:
> On Fri, 9 Aug 2013, Oleksij Rempel wrote:
>
>>> Is there any way to prevent the device from losing its firmware during
>>> a USB reset or suspend?
>>
>> For suspend - yes. It is possible to ignore suspend command or put the
>> SoC in low power mode - but is it probably not so easy to bring it back.
>> I would need to read more code and create some doc as side effect untill
>> i understand how it works.
>> I'm not sure how about reset command. I would need more testing and some
>> ones help. If i see it correctly, usb reset should affect only usb core
>> and usb pll.
>>
>> How can i trigger usb reset?
>
> http://marc.info/?l=linux-usb&m=121459435621262&w=2
>
> Give the program the pathname for the USB device node.  For example:
>
> 	usbreset /dev/bus/usb/001/004

Great! thx!

usb reset do not affect behaviour of firmware. At least after i remove 
all attempts to reboot FW from driver.
If adapter will got reset signal, FW will be notified about it. Then FW 
will remove reset flag and will just continue to work. After usb reset, 
lsusb show correct, update information - EP3 and EP4 was updated from 
INT to BULK.

I assume, no i need to add to the driver some kind of firmware check. 
What is the proper way to do it?

-- 
Regards,
Oleksij

Re: FUSB200 xhci issue

[Alan Stern]

On Sat, 10 Aug 2013, Oleksij Rempel wrote:

> usb reset do not affect behaviour of firmware. At least after i remove 
> all attempts to reboot FW from driver.
> If adapter will got reset signal, FW will be notified about it. Then FW 
> will remove reset flag and will just continue to work. After usb reset, 
> lsusb show correct, update information - EP3 and EP4 was updated from 
> INT to BULK.
> 
> I assume, no i need to add to the driver some kind of firmware check. 
> What is the proper way to do it?

The simplest way is to put a new value for the device descriptor's 
bcdDevice value in the firmware.  Then all you have to do is check that 
value.

Alan Stern

Re: FUSB200 xhci issue

[Oleksij Rempel]

Am 10.08.2013 13:57, schrieb Alan Stern:
> On Sat, 10 Aug 2013, Oleksij Rempel wrote:
>
>> usb reset do not affect behaviour of firmware. At least after i remove
>> all attempts to reboot FW from driver.
>> If adapter will got reset signal, FW will be notified about it. Then FW
>> will remove reset flag and will just continue to work. After usb reset,
>> lsusb show correct, update information - EP3 and EP4 was updated from
>> INT to BULK.
>>
>> I assume, no i need to add to the driver some kind of firmware check.
>> What is the proper way to do it?
>
> The simplest way is to put a new value for the device descriptor's
> bcdDevice value in the firmware.  Then all you have to do is check that
> value.

Since adding fw check will need fw version update. I would like to do 
quick fix for current kernel and firmware version.
I will revert EP3 and EP4 from bulk back to interrupt. But, before 
sending patch to the list i would like to know, how to reproduce the bug 
which was fixed by converting this endpoints from interrupt to bulk.

-- 
Regards,
Oleksij

-- 
Regards,
Oleksij