ath9k-htc on OHCI -> bogus usb xfer

ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hello,

Looks like this is another manifestation of already seen problem with ath9k-htc
and OHCI controller.

I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
development board (this is Synopsys AXS103) and seeing a picture very similar to
what was discussed here?http://thread.gmane.org/gmane.linux.usb.general/110847

Below is what I see on insertion of the dongle.
Note I have the most recent ath9k-htc firmware (see "ath9k_htc/htc_9271-1.4.0.fw"
in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the same
happens even on 4.4.

Interesting enough if I simply remove or disable the warning like that
------------------------>8---------------------------
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index 3d27477..a317e1e 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
?????????* cause problems in HCDs if they get it wrong.
?????????*/
?
-???????/* Check that the pipe's type matches the endpoint's type */
-???????if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
-???????????????dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n",
-???????????????????????usb_pipetype(urb->pipe), pipetypes[xfertype]);
-
????????/* Check against a simple/standard policy */
????????allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
????????????????????????URB_FREE_BUFFER);
------------------------>8---------------------------
everything seem to work quite nice.

Any thoughts are much appreciated.

That's the log itself:
------------------------>8---------------------------
usb 1-1: new full-speed USB device number 2 using ohci-platform
usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
------------[ cut here ]------------
WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
Modules linked in:
CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
Workqueue: events request_firmware_work_func

Stack Trace:
? arc_unwind_core.constprop.1+0x94/0x10c
---[ end trace 2249b79eac9991d1 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
Modules linked in:
CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G????????W???????4.6.3 #10
Workqueue: events request_firmware_work_func

Stack Trace:
? arc_unwind_core.constprop.1+0x94/0x10c
---[ end trace 2249b79eac9991d2 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
Modules linked in:
CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G????????W???????4.6.3 #10
Workqueue: events request_firmware_work_func

Stack Trace:
? arc_unwind_core.constprop.1+0x94/0x10c
---[ end trace 2249b79eac9991d3 ]---

...
------------------------>8---------------------------

-Alexey

ath9k-htc on OHCI -> bogus usb xfer

[Oleksij Rempel]

Hi,

Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
> Hello,
> 
> Looks like this is another manifestation of already seen problem with ath9k-htc
> and OHCI controller.
> 
> I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
> development board (this is Synopsys AXS103) and seeing a picture very similar to
> what was discussed here http://thread.gmane.org/gmane.linux.usb.general/110847
> 
> Below is what I see on insertion of the dongle.
> Note I have the most recent ath9k-htc firmware (see "ath9k_htc/htc_9271-1.4.0.fw"
> in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the same
> happens even on 4.4.
> 
> Interesting enough if I simply remove or disable the warning like that
> ------------------------>8---------------------------
> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
> index 3d27477..a317e1e 100644
> --- a/drivers/usb/core/urb.c
> +++ b/drivers/usb/core/urb.c
> @@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
>          * cause problems in HCDs if they get it wrong.
>          */
>  
> -       /* Check that the pipe's type matches the endpoint's type */
> -       if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
> -               dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n",
> -                       usb_pipetype(urb->pipe), pipetypes[xfertype]);
> -
>         /* Check against a simple/standard policy */
>         allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
>                         URB_FREE_BUFFER);
> ------------------------>8---------------------------
> everything seem to work quite nice.
> 
> Any thoughts are much appreciated.
> 
> That's the log itself:
> ------------------------>8---------------------------
> usb 1-1: new full-speed USB device number 2 using ohci-platform
> usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
> usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> Modules linked in:
> CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
> Workqueue: events request_firmware_work_func
> 
> Stack Trace:
>   arc_unwind_core.constprop.1+0x94/0x10c
> ---[ end trace 2249b79eac9991d1 ]---
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> Modules linked in:
> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G        W       4.6.3 #10
> Workqueue: events request_firmware_work_func
> 
> Stack Trace:
>   arc_unwind_core.constprop.1+0x94/0x10c
> ---[ end trace 2249b79eac9991d2 ]---
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> Modules linked in:
> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G        W       4.6.3 #10
> Workqueue: events request_firmware_work_func
> 
> Stack Trace:
>   arc_unwind_core.constprop.1+0x94/0x10c
> ---[ end trace 2249b79eac9991d3 ]---
> 


please send content of hif_usb_send_regout() from your source code.
It is located in drivers/net/wireless/ath/ath9k/hif_usb.c


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-snps-arc/attachments/20160705/2dd279e2/attachment.sig>

ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi Oleksij,

On Tue, 2016-07-05@19:23 +0200, Oleksij Rempel wrote:
> Hi,
> 
> Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
> > 
> > Hello,
> > 
> > Looks like this is another manifestation of already seen problem with ath9k-htc
> > and OHCI controller.
> > 
> > I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
> > development board (this is Synopsys AXS103) and seeing a picture very similar to
> > what was discussed here http://thread.gmane.org/gmane.linux.usb.general/110847
> > 
> > Below is what I see on insertion of the dongle.
> > Note I have the most recent ath9k-htc firmware (see "ath9k_htc/htc_9271-1.4.0.fw"
> > in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the same
> > happens even on 4.4.
> > 
> > Interesting enough if I simply remove or disable the warning like that
> > ------------------------>8---------------------------
> > diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
> > index 3d27477..a317e1e 100644
> > --- a/drivers/usb/core/urb.c
> > +++ b/drivers/usb/core/urb.c
> > @@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
> > ?????????* cause problems in HCDs if they get it wrong.
> > ?????????*/
> > ?
> > -???????/* Check that the pipe's type matches the endpoint's type */
> > -???????if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
> > -???????????????dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n",
> > -???????????????????????usb_pipetype(urb->pipe), pipetypes[xfertype]);
> > -
> > ????????/* Check against a simple/standard policy */
> > ????????allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
> > ????????????????????????URB_FREE_BUFFER);
> > ------------------------>8---------------------------
> > everything seem to work quite nice.
> > 
> > Any thoughts are much appreciated.
> > 
> > That's the log itself:
> > ------------------------>8---------------------------
> > usb 1-1: new full-speed USB device number 2 using ohci-platform
> > usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
> > usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> > usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> > Modules linked in:
> > CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
> > Workqueue: events request_firmware_work_func
> > 
> > Stack Trace:
> > ? arc_unwind_core.constprop.1+0x94/0x10c
> > ---[ end trace 2249b79eac9991d1 ]---
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> > usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> > Modules linked in:
> > CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G????????W???????4.6.3 #10
> > Workqueue: events request_firmware_work_func
> > 
> > Stack Trace:
> > ? arc_unwind_core.constprop.1+0x94/0x10c
> > ---[ end trace 2249b79eac9991d2 ]---
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> > usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> > Modules linked in:
> > CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G????????W???????4.6.3 #10
> > Workqueue: events request_firmware_work_func
> > 
> > Stack Trace:
> > ? arc_unwind_core.constprop.1+0x94/0x10c
> > ---[ end trace 2249b79eac9991d3 ]---
> > 
> 
> please send content of hif_usb_send_regout() from your source code.
> It is located in drivers/net/wireless/ath/ath9k/hif_usb.c

I use vanilla 4.6.3 tree so that's what I have is the same as
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/ath/ath9k/hif_usb.c?h=linu
x-4.6.y#n99

-Alexey

ath9k-htc on OHCI -> bogus usb xfer

[Oleksij Rempel]

Am 05.07.2016 um 19:31 schrieb Alexey Brodkin:
> Hi Oleksij,
> 
> On Tue, 2016-07-05@19:23 +0200, Oleksij Rempel wrote:
>> Hi,
>>
>> Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
>>>
>>> Hello,
>>>
>>> Looks like this is another manifestation of already seen problem with ath9k-htc
>>> and OHCI controller.
>>>
>>> I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
>>> development board (this is Synopsys AXS103) and seeing a picture very similar to
>>> what was discussed here http://thread.gmane.org/gmane.linux.usb.general/110847
>>>
>>> Below is what I see on insertion of the dongle.
>>> Note I have the most recent ath9k-htc firmware (see "ath9k_htc/htc_9271-1.4.0.fw"
>>> in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the same
>>> happens even on 4.4.
>>>
>>> Interesting enough if I simply remove or disable the warning like that
>>> ------------------------>8---------------------------
>>> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
>>> index 3d27477..a317e1e 100644
>>> --- a/drivers/usb/core/urb.c
>>> +++ b/drivers/usb/core/urb.c
>>> @@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
>>>          * cause problems in HCDs if they get it wrong.
>>>          */
>>>  
>>> -       /* Check that the pipe's type matches the endpoint's type */
>>> -       if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
>>> -               dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n",
>>> -                       usb_pipetype(urb->pipe), pipetypes[xfertype]);
>>> -
>>>         /* Check against a simple/standard policy */
>>>         allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
>>>                         URB_FREE_BUFFER);
>>> ------------------------>8---------------------------
>>> everything seem to work quite nice.
>>>
>>> Any thoughts are much appreciated.
>>>
>>> That's the log itself:
>>> ------------------------>8---------------------------
>>> usb 1-1: new full-speed USB device number 2 using ohci-platform
>>> usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
>>> usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>> Modules linked in:
>>> CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
>>> Workqueue: events request_firmware_work_func
>>>
>>> Stack Trace:
>>>   arc_unwind_core.constprop.1+0x94/0x10c
>>> ---[ end trace 2249b79eac9991d1 ]---
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>> Modules linked in:
>>> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G        W       4.6.3 #10
>>> Workqueue: events request_firmware_work_func
>>>
>>> Stack Trace:
>>>   arc_unwind_core.constprop.1+0x94/0x10c
>>> ---[ end trace 2249b79eac9991d2 ]---
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>> Modules linked in:
>>> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G        W       4.6.3 #10
>>> Workqueue: events request_firmware_work_func
>>>
>>> Stack Trace:
>>>   arc_unwind_core.constprop.1+0x94/0x10c
>>> ---[ end trace 2249b79eac9991d3 ]---
>>>
>>
>> please send content of hif_usb_send_regout() from your source code.
>> It is located in drivers/net/wireless/ath/ath9k/hif_usb.c
> 
> I use vanilla 4.6.3 tree so that's what I have is the same as
> http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/ath/ath9k/hif_usb.c?h=linu
> x-4.6.y#n99

Interesting.
Can you please send lsusb -v for this adapter? and it will be
interesting to see, which usb endpoint was actualy used.

-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-snps-arc/attachments/20160705/ca22433a/attachment.sig>

ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi?Oleksij,

On Tue, 2016-07-05@21:01 +0200, Oleksij Rempel wrote:
> Am 05.07.2016 um 19:31 schrieb Alexey Brodkin:
> > 
> > Hi Oleksij,
> > 
> > On Tue, 2016-07-05@19:23 +0200, Oleksij Rempel wrote:
> > > 
> > > Hi,
> > > 
> > > Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
> > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > Looks like this is another manifestation of already seen problem with ath9k-htc
> > > > and OHCI controller.
> > > > 
> > > > I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
> > > > development board (this is Synopsys AXS103) and seeing a picture very similar to
> > > > what was discussed here http://thread.gmane.org/gmane.linux.usb.general/110847
> > > > 
> > > > Below is what I see on insertion of the dongle.
> > > > Note I have the most recent ath9k-htc firmware (see "ath9k_htc/htc_9271-1.4.0.fw"
> > > > in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the same
> > > > happens even on 4.4.
> > > > 
> > > > Interesting enough if I simply remove or disable the warning like that
> > > > ------------------------>8---------------------------
> > > > diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
> > > > index 3d27477..a317e1e 100644
> > > > --- a/drivers/usb/core/urb.c
> > > > +++ b/drivers/usb/core/urb.c
> > > > @@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
> > > > ?????????* cause problems in HCDs if they get it wrong.
> > > > ?????????*/
> > > > ?
> > > > -???????/* Check that the pipe's type matches the endpoint's type */
> > > > -???????if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
> > > > -???????????????dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n",
> > > > -???????????????????????usb_pipetype(urb->pipe), pipetypes[xfertype]);
> > > > -
> > > > ????????/* Check against a simple/standard policy */
> > > > ????????allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
> > > > ????????????????????????URB_FREE_BUFFER);
> > > > ------------------------>8---------------------------
> > > > everything seem to work quite nice.
> > > > 
> > > > Any thoughts are much appreciated.
> > > > 
> > > > That's the log itself:
> > > > ------------------------>8---------------------------
> > > > usb 1-1: new full-speed USB device number 2 using ohci-platform
> > > > usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
> > > > usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
> > > > ------------[ cut here ]------------
> > > > WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> > > > usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> > > > Modules linked in:
> > > > CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
> > > > Workqueue: events request_firmware_work_func
> > > > 
> > > > Stack Trace:
> > > > ? arc_unwind_core.constprop.1+0x94/0x10c
> > > > ---[ end trace 2249b79eac9991d1 ]---
> > > > ------------[ cut here ]------------
> > > > WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> > > > usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> > > > Modules linked in:
> > > > CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G????????W???????4.6.3 #10
> > > > Workqueue: events request_firmware_work_func
> > > > 
> > > > Stack Trace:
> > > > ? arc_unwind_core.constprop.1+0x94/0x10c
> > > > ---[ end trace 2249b79eac9991d2 ]---
> > > > ------------[ cut here ]------------
> > > > WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> > > > usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> > > > Modules linked in:
> > > > CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G????????W???????4.6.3 #10
> > > > Workqueue: events request_firmware_work_func
> > > > 
> > > > Stack Trace:
> > > > ? arc_unwind_core.constprop.1+0x94/0x10c
> > > > ---[ end trace 2249b79eac9991d3 ]---
> > > > 
> > > please send content of hif_usb_send_regout() from your source code.
> > > It is located in drivers/net/wireless/ath/ath9k/hif_usb.c
> > I use vanilla 4.6.3 tree so that's what I have is the same as
> > http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/ath/ath9k/hif_usb.c?h=
> > linu
> > x-4.6.y#n99
>
> Interesting.
> Can you please send lsusb -v for this adapter?

See below:
-------------------------->8---------------------------
# lsusb -v

Bus 002 Device 002: ID 0cf3:9271??
Device Descriptor:
? bLength????????????????18
? bDescriptorType?????????1
? bcdUSB???????????????2.00
? bDeviceClass??????????255?
? bDeviceSubClass???????255?
? bDeviceProtocol???????255?
? bMaxPacketSize0????????64
? idVendor???????????0x0cf3?
? idProduct??????????0x9271?
? bcdDevice????????????1.08
? iManufacturer??????????16 ATHEROS
? iProduct???????????????32 USB2.0 WLAN
? iSerial????????????????48 12345
? bNumConfigurations??????1
? Configuration Descriptor:
????bLength?????????????????9
????bDescriptorType?????????2
????wTotalLength???????????60
????bNumInterfaces??????????1
????bConfigurationValue?????1
????iConfiguration??????????0?
????bmAttributes?????????0x80
??????(Bus Powered)
????MaxPower??????????????500mA
????Interface Descriptor:
??????bLength?????????????????9
??????bDescriptorType?????????4
??????bInterfaceNumber????????0
??????bAlternateSetting???????0
??????bNumEndpoints???????????6
??????bInterfaceClass???????255?
??????bInterfaceSubClass??????0?
??????bInterfaceProtocol??????0?
??????iInterface??????????????0?
??????Endpoint Descriptor:
????????bLength?????????????????7
????????bDescriptorType?????????5
????????bEndpointAddress?????0x01??EP 1 OUT
????????bmAttributes????????????2
??????????Transfer Type????????????Bulk
??????????Synch Type???????????????None
??????????Usage Type???????????????Data
????????wMaxPacketSize?????0x0040??1x 64 bytes
????????bInterval???????????????0
??????Endpoint Descriptor:
????????bLength?????????????????7
????????bDescriptorType?????????5
????????bEndpointAddress?????0x82??EP 2 IN
????????bmAttributes????????????2
??????????Transfer Type????????????Bulk
??????????Synch Type???????????????None
??????????Usage Type???????????????Data
????????wMaxPacketSize?????0x0040??1x 64 bytes
????????bInterval???????????????0
??????Endpoint Descriptor:
????????bLength?????????????????7
????????bDescriptorType?????????5
????????bEndpointAddress?????0x83??EP 3 IN
????????bmAttributes????????????3
??????????Transfer Type????????????Interrupt
??????????Synch Type???????????????None
??????????Usage Type???????????????Data
????????wMaxPacketSize?????0x0040??1x 64 bytes
????????bInterval???????????????1
??????Endpoint Descriptor:
????????bLength?????????????????7
????????bDescriptorType?????????5
????????bEndpointAddress?????0x04??EP 4 OUT
????????bmAttributes????????????2
??????????Transfer Type????????????Bulk
??????????Synch Type???????????????None
??????????Usage Type???????????????Data
????????wMaxPacketSize?????0x0040??1x 64 bytes
????????bInterval???????????????0
??????Endpoint Descriptor:
????????bLength?????????????????7
????????bDescriptorType?????????5
????????bEndpointAddress?????0x05??EP 5 OUT
????????bmAttributes????????????2
??????????Transfer Type????????????Bulk
??????????Synch Type???????????????None
??????????Usage Type???????????????Data
????????wMaxPacketSize?????0x0040??1x 64 bytes
????????bInterval???????????????0
??????Endpoint Descriptor:
????????bLength?????????????????7
????????bDescriptorType?????????5
????????bEndpointAddress?????0x06??EP 6 OUT
????????bmAttributes????????????2
??????????Transfer Type????????????Bulk
??????????Synch Type???????????????None
??????????Usage Type???????????????Data
????????wMaxPacketSize?????0x0040??1x 64 bytes
????????bInterval???????????????0
Device Qualifier (for other device speed):
? bLength????????????????10
? bDescriptorType?????????6
? bcdUSB???????????????2.00
? bDeviceClass??????????255?
? bDeviceSubClass???????255?
? bDeviceProtocol???????255?
? bMaxPacketSize0????????64
? bNumConfigurations??????1
can't get debug descriptor: Resource temporarily unavailable
Device Status:?????0x0000
? (Bus Powered)

Bus 002 Device 001: ID 1d6b:0001??
Device Descriptor:
? bLength????????????????18
? bDescriptorType?????????1
? bcdUSB???????????????1.10
? bDeviceClass????????????9?
? bDeviceSubClass?????????0?
? bDeviceProtocol?????????0?
? bMaxPacketSize0????????64
? idVendor???????????0x1d6b?
? idProduct??????????0x0001?
? bcdDevice????????????4.06
? iManufacturer???????????3 Linux 4.6.3 ohci_hcd
? iProduct????????????????2 Generic Platform OHCI controller
? iSerial?????????????????1 e0060000.ohci
? bNumConfigurations??????1
? Configuration Descriptor:
????bLength?????????????????9
????bDescriptorType?????????2
????wTotalLength???????????25
????bNumInterfaces??????????1
????bConfigurationValue?????1
????iConfiguration??????????0?
????bmAttributes?????????0xe0
??????Self Powered
??????Remote Wakeup
????MaxPower????????????????0mA
????Interface Descriptor:
??????bLength?????????????????9
??????bDescriptorType?????????4
??????bInterfaceNumber????????0
??????bAlternateSetting???????0
??????bNumEndpoints???????????1
??????bInterfaceClass?????????9?
??????bInterfaceSubClass??????0?
??????bInterfaceProtocol??????0?
??????iInterface??????????????0?
??????Endpoint Descriptor:
????????bLength?????????????????7
????????bDescriptorType?????????5
????????bEndpointAddress?????0x81??EP 1 IN
????????bmAttributes????????????3
??????????Transfer Type????????????Interrupt
??????????Synch Type???????????????None
??????????Usage Type???????????????Data
????????wMaxPacketSize?????0x0002??1x 2 bytes
????????bInterval?????????????255
Hub Descriptor:
? bLength???????????????9
? bDescriptorType??????41
? nNbrPorts?????????????1
? wHubCharacteristic 0x0002
????No power switching (usb 1.0)
????Ganged overcurrent protection
? bPwrOn2PwrGood????????2 * 2 milli seconds
? bHubContrCurrent??????0 milli Ampere
? DeviceRemovable????0x00
? PortPwrCtrlMask????0xff
?Hub Port Status:
???Port 1: 0000.0103 power enable connect
can't get debug descriptor: Resource temporarily unavailable
Device Status:?????0x0001
? Self Powered

Bus 001 Device 001: ID 1d6b:0002??
Device Descriptor:
? bLength????????????????18
? bDescriptorType?????????1
? bcdUSB???????????????2.00
? bDeviceClass????????????9?
? bDeviceSubClass?????????0?
? bDeviceProtocol?????????0?
? bMaxPacketSize0????????64
? idVendor???????????0x1d6b?
? idProduct??????????0x0002?
? bcdDevice????????????4.06
? iManufacturer???????????3 Linux 4.6.3 ehci_hcd
? iProduct????????????????2 EHCI Host Controller
? iSerial?????????????????1 e0040000.ehci
? bNumConfigurations??????1
? Configuration Descriptor:
????bLength?????????????????9
????bDescriptorType?????????2
????wTotalLength???????????25
????bNumInterfaces??????????1
????bConfigurationValue?????1
????iConfiguration??????????0?
????bmAttributes?????????0xe0
??????Self Powered
??????Remote Wakeup
????MaxPower????????????????0mA
????Interface Descriptor:
??????bLength?????????????????9
??????bDescriptorType?????????4
??????bInterfaceNumber????????0
??????bAlternateSetting???????0
??????bNumEndpoints???????????1
??????bInterfaceClass?????????9?
??????bInterfaceSubClass??????0?
??????bInterfaceProtocol??????0?
??????iInterface??????????????0?
??????Endpoint Descriptor:
????????bLength?????????????????7
????????bDescriptorType?????????5
????????bEndpointAddress?????0x81??EP 1 IN
????????bmAttributes????????????3
??????????Transfer Type????????????Interrupt
??????????Synch Type???????????????None
??????????Usage Type???????????????Data
????????wMaxPacketSize?????0x0004??1x 4 bytes
????????bInterval??????????????12
Hub Descriptor:
? bLength???????????????9
? bDescriptorType??????41
? nNbrPorts?????????????1
? wHubCharacteristic 0x0009
????Per-port power switching
????Per-port overcurrent protection
? bPwrOn2PwrGood???????10 * 2 milli seconds
? bHubContrCurrent??????0 milli Ampere
? DeviceRemovable????0x00
? PortPwrCtrlMask????0xff
?Hub Port Status:
???Port 1: 0000.0100 power
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status:?????0x0001
? Self Powered
-------------------------->8---------------------------

> and it will be
> interesting to see, which usb endpoint was actualy used.

Any hints on how may I get this information?

-Alexey

ath9k-htc on OHCI -> bogus usb xfer

[fixed-term.Oleksij.Rempel]

On 06.07.2016 09:44, Alexey Brodkin wrote:
> Hi Oleksij,
> 
> On Tue, 2016-07-05@21:01 +0200, Oleksij Rempel wrote:
>> Am 05.07.2016 um 19:31 schrieb Alexey Brodkin:
>>>
>>> Hi Oleksij,
>>>
>>> On Tue, 2016-07-05@19:23 +0200, Oleksij Rempel wrote:
>>>>
>>>> Hi,
>>>>
>>>> Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Looks like this is another manifestation of already seen problem with ath9k-htc
>>>>> and OHCI controller.
>>>>>
>>>>> I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
>>>>> development board (this is Synopsys AXS103) and seeing a picture very similar to
>>>>> what was discussed here http://thread.gmane.org/gmane.linux.usb.general/110847
>>>>>
>>>>> Below is what I see on insertion of the dongle.
>>>>> Note I have the most recent ath9k-htc firmware (see "ath9k_htc/htc_9271-1.4.0.fw"
>>>>> in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the same
>>>>> happens even on 4.4.
>>>>>
>>>>> Interesting enough if I simply remove or disable the warning like that
>>>>> ------------------------>8---------------------------
>>>>> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
>>>>> index 3d27477..a317e1e 100644
>>>>> --- a/drivers/usb/core/urb.c
>>>>> +++ b/drivers/usb/core/urb.c
>>>>> @@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
>>>>>          * cause problems in HCDs if they get it wrong.
>>>>>          */
>>>>>  
>>>>> -       /* Check that the pipe's type matches the endpoint's type */
>>>>> -       if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
>>>>> -               dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n",
>>>>> -                       usb_pipetype(urb->pipe), pipetypes[xfertype]);
>>>>> -
>>>>>         /* Check against a simple/standard policy */
>>>>>         allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
>>>>>                         URB_FREE_BUFFER);
>>>>> ------------------------>8---------------------------
>>>>> everything seem to work quite nice.
>>>>>
>>>>> Any thoughts are much appreciated.
>>>>>
>>>>> That's the log itself:
>>>>> ------------------------>8---------------------------
>>>>> usb 1-1: new full-speed USB device number 2 using ohci-platform
>>>>> usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
>>>>> usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
>>>>> ------------[ cut here ]------------
>>>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
>>>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>>>> Modules linked in:
>>>>> CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
>>>>> Workqueue: events request_firmware_work_func
>>>>>
>>>>> Stack Trace:
>>>>>   arc_unwind_core.constprop.1+0x94/0x10c
>>>>> ---[ end trace 2249b79eac9991d1 ]---
>>>>> ------------[ cut here ]------------
>>>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
>>>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>>>> Modules linked in:
>>>>> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G        W       4.6.3 #10
>>>>> Workqueue: events request_firmware_work_func
>>>>>
>>>>> Stack Trace:
>>>>>   arc_unwind_core.constprop.1+0x94/0x10c
>>>>> ---[ end trace 2249b79eac9991d2 ]---
>>>>> ------------[ cut here ]------------
>>>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
>>>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>>>> Modules linked in:
>>>>> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G        W       4.6.3 #10
>>>>> Workqueue: events request_firmware_work_func
>>>>>
>>>>> Stack Trace:
>>>>>   arc_unwind_core.constprop.1+0x94/0x10c
>>>>> ---[ end trace 2249b79eac9991d3 ]---
>>>>>
>>>> please send content of hif_usb_send_regout() from your source code.
>>>> It is located in drivers/net/wireless/ath/ath9k/hif_usb.c
>>> I use vanilla 4.6.3 tree so that's what I have is the same as
>>> http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/ath/ath9k/hif_usb.c?h=
>>> linu
>>> x-4.6.y#n99
>>
>> Interesting.
>> Can you please send lsusb -v for this adapter?
> 
> See below:
> -------------------------->8---------------------------
> # lsusb -v
> 
> Bus 002 Device 002: ID 0cf3:9271  
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               2.00
>   bDeviceClass          255 
>   bDeviceSubClass       255 
>   bDeviceProtocol       255 
>   bMaxPacketSize0        64
>   idVendor           0x0cf3 
>   idProduct          0x9271 
>   bcdDevice            1.08
>   iManufacturer          16 ATHEROS
>   iProduct               32 USB2.0 WLAN
>   iSerial                48 12345
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           60
>     bNumInterfaces          1
>     bConfigurationValue     1
>     iConfiguration          0 
>     bmAttributes         0x80
>       (Bus Powered)
>     MaxPower              500mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           6
>       bInterfaceClass       255 
>       bInterfaceSubClass      0 
>       bInterfaceProtocol      0 
>       iInterface              0 
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x01  EP 1 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x82  EP 2 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x83  EP 3 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               1
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x04  EP 4 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               0

Hm... this Endpoint should be Interrupt, not Bulk. If you search for
lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.

what did went wrong here? Is it not working in USB High Speed mode?

ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi?Oleksij,

On Wed, 2016-07-06@10:24 +0200, fixed-term.Oleksij.Rempel wrote:
>?
> Hm... this Endpoint should be Interrupt, not Bulk. If you search for
> lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
> 
> what did went wrong here? Is it not working in USB High Speed mode?

Unfortunately as of now on that board EHCI doesn't work.

That's not a problem of a particular USB device but something in either
ECHI host controller or its integration. I do hope we will fix it sometime soon
(this is a development board and USB controller is implemented in FPGA so
there's a chance to fix stuff later on).

So given only OHCI works on the board I went forward and attempted to use it
with Wi-Fi USB dongle.

-Alexey

ath9k-htc on OHCI -> bogus usb xfer

[fixed-term.Oleksij.Rempel]

On 06.07.2016 10:32, Alexey Brodkin wrote:
> Hi Oleksij,
> 
> On Wed, 2016-07-06@10:24 +0200, fixed-term.Oleksij.Rempel wrote:
>>  
>> Hm... this Endpoint should be Interrupt, not Bulk. If you search for
>> lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
>>
>> what did went wrong here? Is it not working in USB High Speed mode?
> 
> Unfortunately as of now on that board EHCI doesn't work.
> 
> That's not a problem of a particular USB device but something in either
> ECHI host controller or its integration. I do hope we will fix it sometime soon
> (this is a development board and USB controller is implemented in FPGA so
> there's a chance to fix stuff later on).
> 
> So given only OHCI works on the board I went forward and attempted to use it
> with Wi-Fi USB dongle.

I did some tests for 2 years on OHCI controller on x86. There was no
noticable issues. It was even a bit faster then Intels EHCI. I don't
think OHCI alone is the source of this problem.

On other side, so far i know, this adapter claims to provide usb full
speed support, (Not only high speed) and may use different usb
descriptor for this. May be this is the problem.

ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi?Oleksij,

On Wed, 2016-07-06@10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> 
> On 06.07.2016 10:32, Alexey Brodkin wrote:
> > 
> > Hi Oleksij,
> > 
> > On Wed, 2016-07-06@10:24 +0200, fixed-term.Oleksij.Rempel wrote:
> > > 
> > > ?
> > > Hm... this Endpoint should be Interrupt, not Bulk. If you search for
> > > lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
> > > 
> > > what did went wrong here? Is it not working in USB High Speed mode?
> > Unfortunately as of now on that board EHCI doesn't work.
> > 
> > That's not a problem of a particular USB device but something in either
> > ECHI host controller or its integration. I do hope we will fix it sometime soon
> > (this is a development board and USB controller is implemented in FPGA so
> > there's a chance to fix stuff later on).
> > 
> > So given only OHCI works on the board I went forward and attempted to use it
> > with Wi-Fi USB dongle.
>
> I did some tests for 2 years on OHCI controller on x86. There was no
> noticable issues. It was even a bit faster then Intels EHCI. I don't
> think OHCI alone is the source of this problem.

Well I was also surprised how well that dongle works with that board in
OHCI mode. I saw quite consistent ~4-5 Mbit/second rates when doing Speedtest
from my smartphone. So IMHO it's completely usable. Especially on that kind of
HW which has main CPU running at just 100MHz.

> On other side, so far i know, this adapter claims to provide usb full
> speed support, (Not only high speed) and may use different usb
> descriptor for this. May be this is the problem.

So is there something we may do with all that?

-Alexey

ath9k-htc on OHCI -> bogus usb xfer

[fixed-term.Oleksij.Rempel]

On 06.07.2016 10:45, Alexey Brodkin wrote:
> Hi Oleksij,
> 
> On Wed, 2016-07-06@10:38 +0200, fixed-term.Oleksij.Rempel wrote:
>>
>> On 06.07.2016 10:32, Alexey Brodkin wrote:
>>>
>>> Hi Oleksij,
>>>
>>> On Wed, 2016-07-06@10:24 +0200, fixed-term.Oleksij.Rempel wrote:
>>>>
>>>>  
>>>> Hm... this Endpoint should be Interrupt, not Bulk. If you search for
>>>> lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
>>>>
>>>> what did went wrong here? Is it not working in USB High Speed mode?
>>> Unfortunately as of now on that board EHCI doesn't work.
>>>
>>> That's not a problem of a particular USB device but something in either
>>> ECHI host controller or its integration. I do hope we will fix it sometime soon
>>> (this is a development board and USB controller is implemented in FPGA so
>>> there's a chance to fix stuff later on).
>>>
>>> So given only OHCI works on the board I went forward and attempted to use it
>>> with Wi-Fi USB dongle.
>>
>> I did some tests for 2 years on OHCI controller on x86. There was no
>> noticable issues. It was even a bit faster then Intels EHCI. I don't
>> think OHCI alone is the source of this problem.
> 
> Well I was also surprised how well that dongle works with that board in
> OHCI mode. I saw quite consistent ~4-5 Mbit/second rates when doing Speedtest
> from my smartphone. So IMHO it's completely usable. Especially on that kind of
> HW which has main CPU running at just 100MHz.
> 
>> On other side, so far i know, this adapter claims to provide usb full
>> speed support, (Not only high speed) and may use different usb
>> descriptor for this. May be this is the problem.
> 
> So is there something we may do with all that?

Sure...

This shows that EP4 is Bluk in full speed mode. And it is defined by a
boot loader of this chip:
grep -R USB_FS_EP4_ATTRIBUTE *
sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:
m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),
sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define
USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK
sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE
 bUSB_EP_TYPE_BULK
target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define
USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK
target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define
USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK


So, there are fallowing variants to fix it:
a) patch full speed usb descriptor in firmware and add usb reinit
support to the driver.
b) add support of different EP4 types.

In any case, some one need to implement it... right now i have time only
for mentoring.

It is hard to say, which solution is better. It will affect performance
and stability. We will need lots of testing on different HW variants to
know it.
May be usb maeling list can give some input here?

Currently we have fallowing issues:
- if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
- if EP4 and EP3 are Bulk, the work better on High Speed and brake on
Super Speed controllers. This adapter support my 64B packets and if we
have more, fifo of this adapter will overrun.
- Full Speed is currently unknown field for me, and it looks like it was
never actually working properly.

ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi?Oleksij,

On Wed, 2016-07-06@11:09 +0200, fixed-term.Oleksij.Rempel wrote:
> 
> On 06.07.2016 10:45, Alexey Brodkin wrote:
> > 
> > Hi Oleksij,
> > 
> > On Wed, 2016-07-06@10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> > > 
> > > 
> > > On 06.07.2016 10:32, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi Oleksij,
> > > > 
> > > > On Wed, 2016-07-06@10:24 +0200, fixed-term.Oleksij.Rempel wrote:
> > > > > 
> > > > > 
> > > > > ?
> > > > > Hm... this Endpoint should be Interrupt, not Bulk. If you search for
> > > > > lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
> > > > > 
> > > > > what did went wrong here? Is it not working in USB High Speed mode?
> > > > Unfortunately as of now on that board EHCI doesn't work.
> > > > 
> > > > That's not a problem of a particular USB device but something in either
> > > > ECHI host controller or its integration. I do hope we will fix it sometime soon
> > > > (this is a development board and USB controller is implemented in FPGA so
> > > > there's a chance to fix stuff later on).
> > > > 
> > > > So given only OHCI works on the board I went forward and attempted to use it
> > > > with Wi-Fi USB dongle.
> > > I did some tests for 2 years on OHCI controller on x86. There was no
> > > noticable issues. It was even a bit faster then Intels EHCI. I don't
> > > think OHCI alone is the source of this problem.
> > Well I was also surprised how well that dongle works with that board in
> > OHCI mode. I saw quite consistent ~4-5 Mbit/second rates when doing Speedtest
> > from my smartphone. So IMHO it's completely usable. Especially on that kind of
> > HW which has main CPU running at just 100MHz.
> > 
> > > 
> > > On other side, so far i know, this adapter claims to provide usb full
> > > speed support, (Not only high speed) and may use different usb
> > > descriptor for this. May be this is the problem.
> > So is there something we may do with all that?
> Sure...
> 
> This shows that EP4 is Bluk in full speed mode. And it is defined by a
> boot loader of this chip:
> grep -R USB_FS_EP4_ATTRIBUTE *
> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:
> m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),
> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK
> sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE
> ?bUSB_EP_TYPE_BULK
> target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK
> target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK
> 
> 
> So, there are fallowing variants to fix it:
> a) patch full speed usb descriptor in firmware and add usb reinit
> support to the driver.
> b) add support of different EP4 types.
> 
> In any case, some one need to implement it... right now i have time only
> for mentoring.

That's understood.

> It is hard to say, which solution is better. It will affect performance
> and stability. We will need lots of testing on different HW variants to
> know it.
> May be usb maeling list can give some input here?

Let's hope so :)

> Currently we have fallowing issues:
> - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
> - if EP4 and EP3 are Bulk, the work better on High Speed and brake on
> Super Speed controllers. This adapter support my 64B packets and if we
> have more, fifo of this adapter will overrun.
> - Full Speed is currently unknown field for me, and it looks like it was
> never actually working properly.

But given that dongle seem to work fine with muted warning do you think it's
fine to continue that way or not?

I mean if there's a chance this "bogus usb xfer" might affect something during
execution? Otherwise if that's just not a crucial problem or not a problem at all
may be we may just think how to make this warning not so annoying (in my case
I saw never ending flood of those warnings so that basically stopped me from using
the board after that warning started to appear.

-Alexey

ath9k-htc on OHCI -> bogus usb xfer

[fixed-term.Oleksij.Rempel]

On 06.07.2016 11:30, Alexey Brodkin wrote:
> Hi Oleksij,
> 
> On Wed, 2016-07-06@11:09 +0200, fixed-term.Oleksij.Rempel wrote:
>>
>> On 06.07.2016 10:45, Alexey Brodkin wrote:
>>>
>>> Hi Oleksij,
>>>
>>> On Wed, 2016-07-06@10:38 +0200, fixed-term.Oleksij.Rempel wrote:
>>>>
>>>>
>>>> On 06.07.2016 10:32, Alexey Brodkin wrote:
>>>>>
>>>>>
>>>>> Hi Oleksij,
>>>>>
>>>>> On Wed, 2016-07-06@10:24 +0200, fixed-term.Oleksij.Rempel wrote:
>>>>>>
>>>>>>
>>>>>>  
>>>>>> Hm... this Endpoint should be Interrupt, not Bulk. If you search for
>>>>>> lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
>>>>>>
>>>>>> what did went wrong here? Is it not working in USB High Speed mode?
>>>>> Unfortunately as of now on that board EHCI doesn't work.
>>>>>
>>>>> That's not a problem of a particular USB device but something in either
>>>>> ECHI host controller or its integration. I do hope we will fix it sometime soon
>>>>> (this is a development board and USB controller is implemented in FPGA so
>>>>> there's a chance to fix stuff later on).
>>>>>
>>>>> So given only OHCI works on the board I went forward and attempted to use it
>>>>> with Wi-Fi USB dongle.
>>>> I did some tests for 2 years on OHCI controller on x86. There was no
>>>> noticable issues. It was even a bit faster then Intels EHCI. I don't
>>>> think OHCI alone is the source of this problem.
>>> Well I was also surprised how well that dongle works with that board in
>>> OHCI mode. I saw quite consistent ~4-5 Mbit/second rates when doing Speedtest
>>> from my smartphone. So IMHO it's completely usable. Especially on that kind of
>>> HW which has main CPU running at just 100MHz.
>>>
>>>>
>>>> On other side, so far i know, this adapter claims to provide usb full
>>>> speed support, (Not only high speed) and may use different usb
>>>> descriptor for this. May be this is the problem.
>>> So is there something we may do with all that?
>> Sure...
>>
>> This shows that EP4 is Bluk in full speed mode. And it is defined by a
>> boot loader of this chip:
>> grep -R USB_FS_EP4_ATTRIBUTE *
>> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:
>> m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),
>> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define
>> USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK
>> sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE
>>  bUSB_EP_TYPE_BULK
>> target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define
>> USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK
>> target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define
>> USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK
>>
>>
>> So, there are fallowing variants to fix it:
>> a) patch full speed usb descriptor in firmware and add usb reinit
>> support to the driver.
>> b) add support of different EP4 types.
>>
>> In any case, some one need to implement it... right now i have time only
>> for mentoring.
> 
> That's understood.
> 
>> It is hard to say, which solution is better. It will affect performance
>> and stability. We will need lots of testing on different HW variants to
>> know it.
>> May be usb maeling list can give some input here?
> 
> Let's hope so :)
> 
>> Currently we have fallowing issues:
>> - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
>> - if EP4 and EP3 are Bulk, the work better on High Speed and brake on
>> Super Speed controllers. This adapter support my 64B packets and if we
>> have more, fifo of this adapter will overrun.
>> - Full Speed is currently unknown field for me, and it looks like it was
>> never actually working properly.
> 
> But given that dongle seem to work fine with muted warning do you think it's
> fine to continue that way or not?
> 
> I mean if there's a chance this "bogus usb xfer" might affect something during
> execution? Otherwise if that's just not a crucial problem or not a problem at all
> may be we may just think how to make this warning not so annoying (in my case
> I saw never ending flood of those warnings so that basically stopped me from using
> the board after that warning started to appear.

I'll answer with an example:
on USB3 hw this warning was ignore and caused hard reproducible bug
which cost me some week to debug. The result was a FIFO overflow on
adapter side.

ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi?Oleksij,

On Wed, 2016-07-06@12:32 +0200, fixed-term.Oleksij.Rempel wrote:
> 
> On 06.07.2016 11:30, Alexey Brodkin wrote:
> > 
> > Hi Oleksij,
> > 
> > On Wed, 2016-07-06@11:09 +0200, fixed-term.Oleksij.Rempel wrote:
> > > 
> > > 
> > > On 06.07.2016 10:45, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi Oleksij,
> > > > 
> > > > On Wed, 2016-07-06@10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 06.07.2016 10:32, Alexey Brodkin wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hi Oleksij,
> > > > > > 
> > > > > > On Wed, 2016-07-06@10:24 +0200, fixed-term.Oleksij.Rempel wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ?
> > > > > > > Hm... this Endpoint should be Interrupt, not Bulk. If you search for
> > > > > > > lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
> > > > > > > 
> > > > > > > what did went wrong here? Is it not working in USB High Speed mode?
> > > > > > Unfortunately as of now on that board EHCI doesn't work.
> > > > > > 
> > > > > > That's not a problem of a particular USB device but something in either
> > > > > > ECHI host controller or its integration. I do hope we will fix it sometime soon
> > > > > > (this is a development board and USB controller is implemented in FPGA so
> > > > > > there's a chance to fix stuff later on).
> > > > > > 
> > > > > > So given only OHCI works on the board I went forward and attempted to use it
> > > > > > with Wi-Fi USB dongle.
> > > > > I did some tests for 2 years on OHCI controller on x86. There was no
> > > > > noticable issues. It was even a bit faster then Intels EHCI. I don't
> > > > > think OHCI alone is the source of this problem.
> > > > Well I was also surprised how well that dongle works with that board in
> > > > OHCI mode. I saw quite consistent ~4-5 Mbit/second rates when doing Speedtest
> > > > from my smartphone. So IMHO it's completely usable. Especially on that kind of
> > > > HW which has main CPU running at just 100MHz.
> > > > 
> > > > > 
> > > > > 
> > > > > On other side, so far i know, this adapter claims to provide usb full
> > > > > speed support, (Not only high speed) and may use different usb
> > > > > descriptor for this. May be this is the problem.
> > > > So is there something we may do with all that?
> > > Sure...
> > > 
> > > This shows that EP4 is Bluk in full speed mode. And it is defined by a
> > > boot loader of this chip:
> > > grep -R USB_FS_EP4_ATTRIBUTE *
> > > sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:
> > > m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),
> > > sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define
> > > USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK
> > > sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE
> > > ?bUSB_EP_TYPE_BULK
> > > target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define
> > > USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK
> > > target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define
> > > USB_FS_EP4_ATTRIBUTE????????????bUSB_EP_TYPE_BULK
> > > 
> > > 
> > > So, there are fallowing variants to fix it:
> > > a) patch full speed usb descriptor in firmware and add usb reinit
> > > support to the driver.
> > > b) add support of different EP4 types.
> > > 
> > > In any case, some one need to implement it... right now i have time only
> > > for mentoring.
> > That's understood.
> > 
> > > 
> > > It is hard to say, which solution is better. It will affect performance
> > > and stability. We will need lots of testing on different HW variants to
> > > know it.
> > > May be usb maeling list can give some input here?
> > Let's hope so :)
> > 
> > > 
> > > Currently we have fallowing issues:
> > > - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
> > > - if EP4 and EP3 are Bulk, the work better on High Speed and brake on
> > > Super Speed controllers. This adapter support my 64B packets and if we
> > > have more, fifo of this adapter will overrun.
> > > - Full Speed is currently unknown field for me, and it looks like it was
> > > never actually working properly.
> > But given that dongle seem to work fine with muted warning do you think it's
> > fine to continue that way or not?
> > 
> > I mean if there's a chance this "bogus usb xfer" might affect something during
> > execution? Otherwise if that's just not a crucial problem or not a problem at all
> > may be we may just think how to make this warning not so annoying (in my case
> > I saw never ending flood of those warnings so that basically stopped me from using
> > the board after that warning started to appear.
>
> I'll answer with an example:
> on USB3 hw this warning was ignore and caused hard reproducible bug
> which cost me some week to debug. The result was a FIFO overflow on
> adapter side.

Yeah that makes a perfect sense then.
Let's see if there're any other suggestions on the topic.

-Alexey