| Message ID | 1467721137.3144.81.camel@synopsys.com |
|---|---|
| State | New |
| Headers | show |
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
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
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.
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
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?
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
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.
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
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.
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
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.
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
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);