ath9k-htc on OHCI -> bogus usb xfer
diff mbox

Message ID 1467721137.3144.81.camel@synopsys.com
State New
Headers show

Commit Message

Alexey Brodkin July 5, 2016, 12:20 p.m. UTC
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---------------------------
------------------------>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

Comments

Oleksij Rempel July 5, 2016, 5:23 p.m. UTC | #1
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
Alexey Brodkin July 5, 2016, 5:31 p.m. UTC | #2
Hi Oleksij,

On Tue, 2016-07-05 at 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
Oleksij Rempel July 5, 2016, 7:01 p.m. UTC | #3
Am 05.07.2016 um 19:31 schrieb Alexey Brodkin:
> Hi Oleksij,
> 
> On Tue, 2016-07-05 at 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.
Alexey Brodkin July 6, 2016, 7:44 a.m. UTC | #4
Hi Oleksij,

On Tue, 2016-07-05 at 21:01 +0200, Oleksij Rempel wrote:
> Am 05.07.2016 um 19:31 schrieb Alexey Brodkin:
> > 
> > Hi Oleksij,
> > 
> > On Tue, 2016-07-05 at 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
fixed-term.Oleksij.Rempel July 6, 2016, 8:24 a.m. UTC | #5
On 06.07.2016 09:44, Alexey Brodkin wrote:
> Hi Oleksij,
> 
> On Tue, 2016-07-05 at 21:01 +0200, Oleksij Rempel wrote:
>> Am 05.07.2016 um 19:31 schrieb Alexey Brodkin:
>>>
>>> Hi Oleksij,
>>>
>>> On Tue, 2016-07-05 at 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?
Alexey Brodkin July 6, 2016, 8:32 a.m. UTC | #6
Hi Oleksij,

On Wed, 2016-07-06 at 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
fixed-term.Oleksij.Rempel July 6, 2016, 8:38 a.m. UTC | #7
On 06.07.2016 10:32, Alexey Brodkin wrote:
> Hi Oleksij,
> 
> On Wed, 2016-07-06 at 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.
Alexey Brodkin July 6, 2016, 8:45 a.m. UTC | #8
Hi Oleksij,

On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> 
> On 06.07.2016 10:32, Alexey Brodkin wrote:
> > 
> > Hi Oleksij,
> > 
> > On Wed, 2016-07-06 at 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
fixed-term.Oleksij.Rempel July 6, 2016, 9:09 a.m. UTC | #9
On 06.07.2016 10:45, Alexey Brodkin wrote:
> Hi Oleksij,
> 
> On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:
>>
>> On 06.07.2016 10:32, Alexey Brodkin wrote:
>>>
>>> Hi Oleksij,
>>>
>>> On Wed, 2016-07-06 at 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.
Alexey Brodkin July 6, 2016, 9:30 a.m. UTC | #10
Hi Oleksij,

On Wed, 2016-07-06 at 11:09 +0200, fixed-term.Oleksij.Rempel wrote:
> 
> On 06.07.2016 10:45, Alexey Brodkin wrote:
> > 
> > Hi Oleksij,
> > 
> > On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> > > 
> > > 
> > > On 06.07.2016 10:32, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi Oleksij,
> > > > 
> > > > On Wed, 2016-07-06 at 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
fixed-term.Oleksij.Rempel July 6, 2016, 10:32 a.m. UTC | #11
On 06.07.2016 11:30, Alexey Brodkin wrote:
> Hi Oleksij,
> 
> On Wed, 2016-07-06 at 11:09 +0200, fixed-term.Oleksij.Rempel wrote:
>>
>> On 06.07.2016 10:45, Alexey Brodkin wrote:
>>>
>>> Hi Oleksij,
>>>
>>> On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:
>>>>
>>>>
>>>> On 06.07.2016 10:32, Alexey Brodkin wrote:
>>>>>
>>>>>
>>>>> Hi Oleksij,
>>>>>
>>>>> On Wed, 2016-07-06 at 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.
Alexey Brodkin July 7, 2016, 5:16 a.m. UTC | #12
Hi Oleksij,

On Wed, 2016-07-06 at 12:32 +0200, fixed-term.Oleksij.Rempel wrote:
> 
> On 06.07.2016 11:30, Alexey Brodkin wrote:
> > 
> > Hi Oleksij,
> > 
> > On Wed, 2016-07-06 at 11:09 +0200, fixed-term.Oleksij.Rempel wrote:
> > > 
> > > 
> > > On 06.07.2016 10:45, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi Oleksij,
> > > > 
> > > > On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 06.07.2016 10:32, Alexey Brodkin wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hi Oleksij,
> > > > > > 
> > > > > > On Wed, 2016-07-06 at 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

Patch
diff mbox

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);