Re: ASMedia AS2105 interface on USB 3.0 corrupts data

2014-05-22 Thread Heinz Diehl
On 21.05.2014, Alan Stern wrote:

> In that case, I have no idea what else could be causing the problem.

Thanks for your efforts!

If somebody of the developers is interested in debugging this, I'm
willing to provide/give away the device for free. Send me
an email with your postal adress in this case, and I'll send you 
the controller mentioned in this thread. My GPG-key is available 
from the link given in the header.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: USB 3.0 - Synopsis DWC Host-AHB - on Linux Kernel 3.10.28

2014-05-22 Thread Pratyush Anand
On Wed, May 21, 2014 at 05:23:33PM +0800, krishnamurthy holla wrote:
> Hello,
> 
> I am using Linux kernel 3.10.28 - MIPS processor (BIG Endian)
> 
> I see that XHCI fails during xhci_device_alloc() because of
> wait_for_completion_interruptible_timeout () when I connect a device.
> 
> So, I thought of initializing host controller as BE as my host is BE.
> But this time, it failed much earlier, i.e in xhci_handle_event()
> itself for the check le32_to_cpu(event->event_cmd.flags) & TRB_CYCLE)
> !=  xhci->event_ring->cycle_state)
> 
> I would like to know if any of you used Synopsis DWC Host-AHB and got
> successful device detection. Also, Please let me know if XHCI needs

Yes, our SNPS dwc3 xhci host works well with various SS/HS devices. But
our system is LE.

> special configuration on Big Endian system.

I do not think you need any special configuration of xhci register for
this.

USB and XHCI debug dmesg may help.

Pratyush

> 
> Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] MIPS: MSP71xx: remove checks for two macros

2014-05-22 Thread Paul Bolle
Since v2.6.39 there are checks for CONFIG_MSP_HAS_DUAL_USB and checks
for CONFIG_MSP_HAS_TSMAC in the code. The related Kconfig symbols have
never been added. These checks have evaluated to false for three years
now. Remove them and the code they have been hiding.

Signed-off-by: Paul Bolle 
---
Eyeball tested only.

 arch/mips/include/asm/mach-pmcs-msp71xx/msp_usb.h |  4 -
 arch/mips/pmcs-msp71xx/msp_eth.c  | 76 ---
 arch/mips/pmcs-msp71xx/msp_usb.c  | 90 ---
 drivers/usb/host/ehci-pmcmsp.c| 40 --
 4 files changed, 210 deletions(-)

diff --git a/arch/mips/include/asm/mach-pmcs-msp71xx/msp_usb.h 
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_usb.h
index aa45e6a07126..fe1566f2913e 100644
--- a/arch/mips/include/asm/mach-pmcs-msp71xx/msp_usb.h
+++ b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_usb.h
@@ -25,11 +25,7 @@
 #ifndef MSP_USB_H_
 #define MSP_USB_H_
 
-#ifdef CONFIG_MSP_HAS_DUAL_USB
-#define NUM_USB_DEVS   2
-#else
 #define NUM_USB_DEVS   1
-#endif
 
 /* Register spaces for USB host 0 */
 #define MSP_USB0_MAB_START (MSP_USB0_BASE + 0x0)
diff --git a/arch/mips/pmcs-msp71xx/msp_eth.c b/arch/mips/pmcs-msp71xx/msp_eth.c
index c584df393de2..15679b427f44 100644
--- a/arch/mips/pmcs-msp71xx/msp_eth.c
+++ b/arch/mips/pmcs-msp71xx/msp_eth.c
@@ -38,73 +38,6 @@
 #define MSP_ETHERNET_GPIO1 15
 #define MSP_ETHERNET_GPIO2 16
 
-#ifdef CONFIG_MSP_HAS_TSMAC
-#define MSP_TSMAC_SIZE 0x10020
-#define MSP_TSMAC_ID   "pmc_tsmac"
-
-static struct resource msp_tsmac0_resources[] = {
-   [0] = {
-   .start  = MSP_MAC0_BASE,
-   .end= MSP_MAC0_BASE + MSP_TSMAC_SIZE - 1,
-   .flags  = IORESOURCE_MEM,
-   },
-   [1] = {
-   .start  = MSP_INT_MAC0,
-   .end= MSP_INT_MAC0,
-   .flags  = IORESOURCE_IRQ,
-   },
-};
-
-static struct resource msp_tsmac1_resources[] = {
-   [0] = {
-   .start  = MSP_MAC1_BASE,
-   .end= MSP_MAC1_BASE + MSP_TSMAC_SIZE - 1,
-   .flags  = IORESOURCE_MEM,
-   },
-   [1] = {
-   .start  = MSP_INT_MAC1,
-   .end= MSP_INT_MAC1,
-   .flags  = IORESOURCE_IRQ,
-   },
-};
-static struct resource msp_tsmac2_resources[] = {
-   [0] = {
-   .start  = MSP_MAC2_BASE,
-   .end= MSP_MAC2_BASE + MSP_TSMAC_SIZE - 1,
-   .flags  = IORESOURCE_MEM,
-   },
-   [1] = {
-   .start  = MSP_INT_SAR,
-   .end= MSP_INT_SAR,
-   .flags  = IORESOURCE_IRQ,
-   },
-};
-
-
-static struct platform_device tsmac_device[] = {
-   [0] = {
-   .name   = MSP_TSMAC_ID,
-   .id = 0,
-   .num_resources = ARRAY_SIZE(msp_tsmac0_resources),
-   .resource = msp_tsmac0_resources,
-   },
-   [1] = {
-   .name   = MSP_TSMAC_ID,
-   .id = 1,
-   .num_resources = ARRAY_SIZE(msp_tsmac1_resources),
-   .resource = msp_tsmac1_resources,
-   },
-   [2] = {
-   .name   = MSP_TSMAC_ID,
-   .id = 2,
-   .num_resources = ARRAY_SIZE(msp_tsmac2_resources),
-   .resource = msp_tsmac2_resources,
-   },
-};
-#define msp_eth_devs   tsmac_device
-
-#else
-/* If it is not TSMAC assume MSP_ETH (100Mbps) */
 #define MSP_ETH_ID "pmc_mspeth"
 #define MSP_ETH_SIZE   0xE0
 static struct resource msp_eth0_resources[] = {
@@ -152,7 +85,6 @@ static struct platform_device mspeth_device[] = {
 };
 #define msp_eth_devs   mspeth_device
 
-#endif
 int __init msp_eth_setup(void)
 {
int i, ret = 0;
@@ -161,14 +93,6 @@ int __init msp_eth_setup(void)
msp_gpio_pin_mode(MSP_GPIO_OUTPUT, MSP_ETHERNET_GPIO0);
msp_gpio_pin_hi(MSP_ETHERNET_GPIO0);
 
-#ifdef CONFIG_MSP_HAS_TSMAC
-   /* 3 phys on boards with TSMAC */
-   msp_gpio_pin_mode(MSP_GPIO_OUTPUT, MSP_ETHERNET_GPIO1);
-   msp_gpio_pin_hi(MSP_ETHERNET_GPIO1);
-
-   msp_gpio_pin_mode(MSP_GPIO_OUTPUT, MSP_ETHERNET_GPIO2);
-   msp_gpio_pin_hi(MSP_ETHERNET_GPIO2);
-#endif
for (i = 0; i < ARRAY_SIZE(msp_eth_devs); i++) {
ret = platform_device_register(&msp_eth_devs[i]);
printk(KERN_INFO "device: %d, return value = %d\n", i, ret);
diff --git a/arch/mips/pmcs-msp71xx/msp_usb.c b/arch/mips/pmcs-msp71xx/msp_usb.c
index 4dab915696e7..c87c5f810cd1 100644
--- a/arch/mips/pmcs-msp71xx/msp_usb.c
+++ b/arch/mips/pmcs-msp71xx/msp_usb.c
@@ -75,47 +75,6 @@ static struct mspusb_device msp_usbhost0_device = {
.resource   = msp_usbhost0_resources,
},
 };
-
-/* MSP7140/MSP82XX has two USB2 hosts. */
-#ifdef CONFIG_MSP_HAS_DUAL_USB
-static u64 msp_usbhost1_dma_mask = 0xUL;
-
-static struct resource msp_usbhost1_resources[] = {
-   [0] = { /* EHCI-HS operational and capabi

[PATCH 1/2] usb: usbtest: fix unlink write error with pattern 1

2014-05-22 Thread Huang Rui
TEST 12 unlinks the URB write request for N times. When host and
gadget both initialize pattern 1 (mod 63) data series to transfer, the
gadget side will complain the wrong data which is not expected.
Because in host side, usbtest doesn't fill the data buffer as mod 63
and this patch fixed it.

[20285.488974] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready
[20285.489181] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active
[20285.489423] dwc3 dwc3.0.auto: ep1out-bulk: req 8800aa6cb480 dma aeb50800 
length 512 last
[20285.489727] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params 
 a9eaf000 
[20285.490055] dwc3 dwc3.0.auto: Command Complete --> 0
[20285.490281] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready
[20285.490492] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Active
[20285.490713] dwc3 dwc3.0.auto: ep1out-bulk: endpoint busy
[20285.490909] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Complete
[20285.491117] dwc3 dwc3.0.auto: request 8800aa6cb480 from ep1out-bulk 
completed 512/512 ===> 0
[20285.491431] zero gadget: bad OUT byte, buf[1] = 0
[20285.491605] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Set Stall' params  
 
[20285.491915] dwc3 dwc3.0.auto: Command Complete --> 0
[20285.492099] dwc3 dwc3.0.auto: queing request 8800aa6cb480 to ep1out-bulk 
length 512
[20285.492387] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready
[20285.492595] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active
[20285.492830] dwc3 dwc3.0.auto: ep1out-bulk: req 8800aa6cb480 dma aeb51000 
length 512 last
[20285.493135] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params 
 a9eaf000 
[20285.493465] dwc3 dwc3.0.auto: Command Complete --> 0

Cc: 
Signed-off-by: Huang Rui 
---
 drivers/usb/misc/usbtest.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index f6568b5..4e31418 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1320,6 +1320,11 @@ static int unlink1(struct usbtest_dev *dev, int pipe, 
int size, int async)
urb->context = &completion;
urb->complete = unlink1_callback;
 
+   if (usb_pipeout(urb->pipe)) {
+   simple_fill_buf(urb);
+   urb->transfer_flags |= URB_ZERO_PACKET;
+   }
+
/* keep the endpoint busy.  there are lots of hc/hcd-internal
 * states, and testing should get to all of them over time.
 *
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/2] usb: usbtest: add pattern check on pipe in phase of unlink read

2014-05-22 Thread Huang Rui
TEST 11 unlinks the URB read request for N times. When host and gadget
both initialize pattern 1 (mod 63) data series to do IN transfer, the
host side function should check the data buffer if it is as mod 63
series, because the data packet which host receivced will follow
pattern 1. So this patch adds this checking action.

Signed-off-by: Huang Rui 
---
 drivers/usb/misc/usbtest.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 4e31418..f7d37c1 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1345,6 +1345,9 @@ static int unlink1(struct usbtest_dev *dev, int pipe, int 
size, int async)
while (!completion_done(&completion)) {
retval = usb_unlink_urb(urb);
 
+   if (retval == 0 && usb_pipein(urb->pipe))
+   retval = simple_check_buf(dev, urb);
+
switch (retval) {
case -EBUSY:
case -EIDRM:
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


some question about usb_interrupt_msg

2014-05-22 Thread vichy
hi all:
I see usb_interrupt_msg do nothing but call usb_bulk_msg.
Why we still keep usb_interrupt_msg?
for old api compatibility?

thanks for your help in advance,
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Will Deacon
Hi all,

Although I don't think this is a new issue, booting mainline on my vexpress
a9x4 (Quad ARMv7 Cortex-A9 board) with USB and PM_RUNTIME results in each
CPU being constantly 20-50% loaded. A bit of investigation shows that this
is due to the runtime-pm callbacks trying to autosuspend USB, despite this
being unsupported by the host-controller (isp1760, which doesn't have a
->bus_suspend callback). I've included a backtrace at the bottom of this mail.

Anyway, since ->bus_suspend is not implemented, hcd_bus_suspend returns
-ENOENT, which propagates back up to usb_runtime_suspend via usb_suspend_both.
At this point, we override the return value with -EBUSY:

drivers/usb/core/driver.c:usb_runtime_suspend:

/* The PM core reacts badly unless the return code is 0,
 * -EAGAIN, or -EBUSY, so always return -EBUSY on an error.
 */
if (status != 0)
return -EBUSY;

This then tells the runtime PM code to try again:

drivers/base/power/runtime.c

if (retval == -EAGAIN || retval == -EBUSY) {
dev->power.runtime_error = 0;

/*
 * If the callback routine failed an autosuspend, and
 * if the last_busy time has been updated so that there
 * is a new autosuspend expiration time, automatically
 * reschedule another autosuspend.
 */
if ((rpmflags & RPM_AUTO) &&
pm_runtime_autosuspend_expiration(dev) != 0)
goto repeat;

Consequently, I see a kworker thread on each CPU consuming a significant
amount of the system resources. Worse, if I enable something like kmemleak
(which adds more work to the failed suspend operation), I end up failing
to boot entirely (NFS bombs out).

Reverting db7c7c0aeef5 ("usb: Always return 0 or -EBUSY to the runtime
PM core.") fixes this for me, but the commit log suggests that will break
lsusb. That patch has also been in for three and a half years...

Any ideas on how to fix this properly? In what ways does the PM core react
badly to -ENOENT?

Cheers,

Will

--->8

[  161.385424] CPU: 0 PID: 51 Comm: kworker/0:1 Not tainted 3.15.0-rc5 #2
[  161.405009] Workqueue: pm pm_runtime_work
[  161.417019] task: ed0bec00 ti: ed47 task.ti: ed47
[  161.433195] PC is at kmemleak_free+0x8/0x4c
[  161.445737] LR is at kfree+0xbc/0x154
[  161.456699] pc : []lr : []psr: 400f0013
[  161.456699] sp : ed471c58  ip : 001c  fp : ed39adc0
[  161.491098] r10:   r9 : ed59a300  r8 : c09df324
[  161.506743] r7 : c03e7960  r6 : ee59b340  r5 : ed59a300  r4 : ed001f00
[  161.526294] r3 : f0e0  r2 : edff  r1 : ed59a300  r0 : ed59a300
[  161.545848] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[  161.567743] Control: 10c5387d  Table: 8d5e004a  DAC: 0015
[  161.584955] CPU: 0 PID: 51 Comm: kworker/0:1 Not tainted 3.15.0-rc5 #2
[  161.604512] Workqueue: pm pm_runtime_work
[  161.616572] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[  161.639794] [] (show_stack) from [] 
(dump_stack+0x88/0x98)
[  161.661449] [] (dump_stack) from [] 
(sysrq_handle_showallcpus+0x5c/0x64)
[  161.686744] [] (sysrq_handle_showallcpus) from [] 
(__handle_sysrq+0x128/0x17c)
[  161.713600] [] (__handle_sysrq) from [] 
(pl011_fifo_to_tty+0x174/0x1c4)
[  161.738631] [] (pl011_fifo_to_tty) from [] 
(pl011_int+0x298/0x5a8)
[  161.762362] [] (pl011_int) from [] 
(handle_irq_event_percpu+0x78/0x134)
[  161.787393] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x40/0x60)
[  161.813991] [] (handle_irq_event) from [] 
(handle_fasteoi_irq+0xa8/0x1a8)
[  161.839562] [] (handle_fasteoi_irq) from [] 
(generic_handle_irq+0x2c/0x3c)
[  161.865377] [] (generic_handle_irq) from [] 
(handle_IRQ+0x40/0x90)
[  161.889105] [] (handle_IRQ) from [] 
(gic_handle_irq+0x2c/0x5c)
[  161.911788] [] (gic_handle_irq) from [] 
(__irq_svc+0x40/0x50)
[  161.934204] Exception stack(0xed471c10 to 0xed471c58)
[  161.949333] 1c00: ed59a300 ed59a300 
edff f0e0
[  161.973840] 1c20: ed001f00 ed59a300 ee59b340 c03e7960 c09df324 ed59a300 
 ed39adc0
[  161.998345] 1c40: 001c ed471c58 c00ecc14 c05be7e0 400f0013 
[  162.018168] [] (__irq_svc) from [] 
(kmemleak_free+0x8/0x4c)
[  162.040082] [] (kmemleak_free) from [] (kfree+0xbc/0x154)
[  162.061490] [] (kfree) from [] 
(usb_hcd_submit_urb+0x2d4/0x804)
[  162.084447] [] (usb_hcd_submit_urb) from [] 
(usb_start_wait_urb+0x4c/0xbc)
[  162.110264] [] (usb_start_wait_urb) from [] 
(usb_control_msg+0xa0/0xd0)
[  162.135298] [] (usb_control_msg) from [] 
(hub_port_status+0x74/0xfc)
[  162.159548] [] (hub_port_status) from [] 
(hub_activate+0x164/0x500)
[  162.183537] [] (hub_activate) from [] 
(hub_resume+0x14/0x1c)
[  162.205709] [] (hub_resume) from [] 
(usb_resume_interface.isra.6+0xe8/0x118)
[  162.232041] [] (usb_resume_interface.isra.6) from [] 
(usb_suspend_both+0xbc/0x19c)
[  162.

[PATCH V2] USB: Add LVS Test device driver

2014-05-22 Thread Pratyush Anand
OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.

USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).

Some modifications are needed for an embedded Linux USB host to pass all
these tests.  Most of these tests require just Link to be in U0. They do
not work with default Linux USB stack since, default stack does port
reset and then starts sending setup packet, which is not expected by
Link Layer Validation (LVS) device of Lecroy Compliance Suit.  Then,
There are many Link Layer Tests which need host to generate specific
traffic.

This patch supports specific traffic generation cases. As of now all the
host Lecroy Link Layer-USBIF tests (except TD7.26) passes
with this patch for single run using  Lecroy USB Compliance Suite
Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
Build 1603. Therefore patch seems to be a good candidate for inclusion.
Further modification can be done on top of it.

lvstest driver will not bind to any device by default. It can bind
manually to a super speed USB host controller root hub. Therefore, regular
hub driver must be unbound before this driver is bound. For example, if
2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.

 echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind

Then to bind lvs driver write Linux Foundation's vendor ID and SS root
hub's device ID into new_id file.

 echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id

Now connect LVS device with root hub port.
Test case specific traffic can be generated as follows whenever needed:

1. To issue "Get Device descriptor" command for TD.7.06:
 echo 1 > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc

2. To set U1 timeout to 127 for TD.7.18
 echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout

3. To set U2 timeout to 0 for TD.7.18
 echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout

4. To issue "Hot Reset" for TD.7.29
 echo 1 > /sys/bus/usb/devices/2-0\:1.0/hot_reset

5. To issue "U3 Entry" for TD.7.35
 echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_entry

6. To issue "U3 Exit" for TD.7.36
 echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Signed-off-by: Pratyush Anand 
---
 Documentation/ABI/testing/sysfs-bus-usb-lvstest |  47 +++
 drivers/usb/misc/Kconfig|   7 +
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/lvstest.c  | 434 
 4 files changed, 489 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-usb-lvstest
 create mode 100644 drivers/usb/misc/lvstest.c

diff --git a/Documentation/ABI/testing/sysfs-bus-usb-lvstest 
b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
new file mode 100644
index 000..f47e8a3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
@@ -0,0 +1,47 @@
+Link Layer Validation Device is a standard device for testing of Super
+Speed Link Layer tests. These nodes are available in sysfs only when lvs
+driver is bound with root hub device.
+
+What:  /sys/bus/usb/devices/.../get_dev_desc
+Date:  March 2014
+Contact:   Pratyush Anand 
+Description:
+   Write to this node to issue "Get Device Descriptor"
+   for Link Layer Validation device. It is needed for TD.7.06.
+
+What:  /sys/bus/usb/devices/.../u1_timeout
+Date:  March 2014
+Contact:   Pratyush Anand 
+Description:
+   Set "U1 timeout" for the downstream port where Link Layer
+   Validation device is connected. It is needed for TD.7.18,
+   TD.7.19, TD.7.20 and TD.7.21.
+
+What:  /sys/bus/usb/devices/.../u2_timeout
+Date:  March 2014
+Contact:   Pratyush Anand 
+Description:
+   Set "U2 timeout" for the downstream port where Link Layer
+   Validation device is connected. It is needed for TD.7.18,
+   TD.7.19, TD.7.20 and TD.7.21.
+
+What:  /sys/bus/usb/devices/.../hot_reset
+Date:  March 2014
+Contact:   Pratyush Anand 
+Description:
+   Write to this node to issue "Reset" for Link Layer Validation
+   device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35.
+
+What:  /sys/bus/usb/devices/.../u3_entry
+Date:  March 2014
+Contact:   Pratyush Anand 
+Description:
+   Write to this node to issue "U3 entry" for Link Layer
+   Validation device. It is needed for TD.7.35 and TD.7.36.
+
+What:  /sys/bus/usb/devices/.../u3_exit
+Date:  March 2014
+Contact:   Pratyush Anand 
+Description:
+   Write to this node to issue "U3 exit" for Link Layer
+   Validation device. It is needed for TD.7.36.
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 1bca274..76d7720 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -248,3 +248,10 @@ config USB_HSIC_US

[PATCH v2] usb: usb5303: add support for reference clock specified in device tree

2014-05-22 Thread Marek Szyprowski
USB3503 chip supports 8 values of reference clock. The value is
specified by REF_SEL[1:0] pins and INT_N line. This patch add support
for getting 'refclk' clock, enabling it and setting INT_N line according
to the value of the gathered clock. If no clock has been specified,
driver defaults to the old behaviour (assuming that clock has been
specified by REF_SEL pins from primary reference clock frequencies
table).

Signed-off-by: Marek Szyprowski 
---
Hello,

This extension to USB3503 driver is needed to add support for OdroidU3
board, which uses 24MHz reference clock, sourced directly from CLKOUT
line from Exynos4412 SoC.

Changelog:
v2
- fixed issues pointed by Mark Brown
- added optional refclk-frequency property, clock rate is read from DT
instead of getting it from clock

v1
- initial version

Best regards
Marek Szyprowski
Samsung R&D Institute Poland
---
 Documentation/devicetree/bindings/usb/usb3503.txt |  8 +++
 drivers/usb/misc/usb3503.c| 59 ++-
 2 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt 
b/Documentation/devicetree/bindings/usb/usb3503.txt
index a018da4a7ad7..221ac0dbc678 100644
--- a/Documentation/devicetree/bindings/usb/usb3503.txt
+++ b/Documentation/devicetree/bindings/usb/usb3503.txt
@@ -15,6 +15,14 @@ Optional properties:
 - reset-gpios: Should specify GPIO for reset.
 - initial-mode: Should specify initial mode.
 (1 for HUB mode, 2 for STANDBY mode)
+- refclk: Clock used for driving REFCLK signal (optional, if not provided
+   the driver assumes that clock signal is always available, its
+   rate is specified by REF_SEL pins and a value from the primary
+   reference clock frequencies table is used)
+- refclk-frequency: Frequency of the REFCLK signal as defined by REF_SEL
+   pins (optional, if not provided, driver will not set rate of the
+   REFCLK signal and assume that a value from the primary reference
+   clock frequencies table is used)
 
 Examples:
usb3503@08 {
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index a31641e18d19..f43c61989cef 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -18,6 +18,7 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -57,10 +58,12 @@ struct usb3503 {
enum usb3503_mode   mode;
struct regmap   *regmap;
struct device   *dev;
+   struct clk  *clk;
u8  port_off_mask;
int gpio_intn;
int gpio_reset;
int gpio_connect;
+   boolsecondary_ref_clk;
 };
 
 static int usb3503_reset(struct usb3503 *hub, int state)
@@ -184,8 +187,58 @@ static int usb3503_probe(struct usb3503 *hub)
hub->gpio_reset = pdata->gpio_reset;
hub->mode   = pdata->initial_mode;
} else if (np) {
+   struct clk *clk;
hub->port_off_mask = 0;
 
+   clk = devm_clk_get(dev, "refclk");
+   if (IS_ERR(clk) && PTR_ERR(clk) != -ENOENT) {
+   dev_err(dev, "unable to request refclk (%d)\n", err);
+   return PTR_ERR(clk);
+   }
+
+   if (!IS_ERR(clk)) {
+   u32 rate = 0;
+   hub->clk = clk;
+
+   if (!of_property_read_u32(np, "refclk-frequency",
+&rate)) {
+
+   switch (rate) {
+   case 3840:
+   case 2600:
+   case 1920:
+   case 1200:
+   hub->secondary_ref_clk = 0;
+   break;
+   case 2400:
+   case 2700:
+   case 2500:
+   case 5000:
+   hub->secondary_ref_clk = 1;
+   break;
+   default:
+   dev_err(dev,
+   "unsupported reference clock 
rate (%d)\n",
+   (int) rate);
+   return -EINVAL;
+   }
+   err = clk_set_rate(hub->clk, rate);
+   if (err) {
+   dev_err(dev,
+   "unable to set reference clock 
rate to %d\n",
+   (int) rate);
+   return err;
+   

Re: [PATCH v5 5/6] usb: musb: dsps: Add the sw_babble_control()

2014-05-22 Thread Sergei Shtylyov

Hello.

On 22-05-2014 10:29, George Cherian wrote:


Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.



Babble control register logic is implemented in the latest
revision of AM335x.



Signed-off-by: George Cherian 


   Sorry for the late comments, I probably didn't pay enough attention to 
this series before...



diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f6f3087..868caf8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,6 +536,56 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
  }

+static int sw_babble_control(struct musb *musb)


   Perhaps the result type should be *bool* instead of *int*?


+{
+   int timeout = 10;
+   u8 babble_ctl, session_restart = 0;
+
+   babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   dev_dbg(musb->controller, "babble: MUSB_BABBLE_CTL value %x\n",
+   babble_ctl);
+   /*
+* check line monitor flag to check whether babble is
+* due to noise
+*/
+   dev_dbg(musb->controller, "STUCK_J is %s\n",
+   babble_ctl & MUSB_BABBLE_STUCK_J ? "set" : "reset");
+
+   if (babble_ctl & MUSB_BABBLE_STUCK_J) {


   'timeout' could be declared here, local to the block using it.


+   /*
+* babble is due to noise, then set transmit idle (d7 bit)
+* to resume normal operation
+*/
+   babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   babble_ctl |= MUSB_BABBLE_FORCE_TXIDLE;
+   dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, babble_ctl);
+
+   /* wait till line monitor flag cleared */
+   dev_dbg(musb->controller, "Set TXIDLE, wait J to clear\n");
+   do {
+   babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   udelay(1);
+   } while ((babble_ctl & MUSB_BABBLE_STUCK_J) && timeout--);
+
+   /* check whether stuck_at_j bit cleared */
+   if (babble_ctl & MUSB_BABBLE_STUCK_J) {
+   /*
+* real babble condition is occured


   s/is occured/has occurred/.


+* restart the controller to start the
+* session again
+*/
+   dev_dbg(musb->controller, "J not cleared, misc (%x)\n",
+   babble_ctl);
+   session_restart = 1;
+   }
+


   Empty line not needed here.


+   } else {
+   session_restart = 1;
+   }
+
+   return session_restart;
+}


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 5/6] usb: musb: dsps: Add the sw_babble_control()

2014-05-22 Thread Sergei Shtylyov

On 22-05-2014 10:29, George Cherian wrote:


Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.



Babble control register logic is implemented in the latest
revision of AM335x.



Signed-off-by: George Cherian 
---
  drivers/usb/musb/musb_dsps.c | 50 
  drivers/usb/musb/musb_regs.h |  7 +++
  2 files changed, 57 insertions(+)



diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f6f3087..868caf8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,6 +536,56 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
  }

+static int sw_babble_control(struct musb *musb)
+{


   Doesn't gcc complain on this function being unused? I think you should 
have added this function along with the caller, not separately.


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 6/6] usb: musb: dsps: Enable sw babble control for newer silicon

2014-05-22 Thread Sergei Shtylyov

Hello.

On 22-05-2014 10:29, George Cherian wrote:


Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.



Signed-off-by: George Cherian 
---
  drivers/usb/musb/musb_dsps.c | 38 --
  1 file changed, 32 insertions(+), 6 deletions(-)



diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 868caf8..2ced061 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c

[...]

@@ -469,6 +470,19 @@ static int dsps_musb_init(struct musb *musb)
val &= ~(1 << wrp->otg_disable);
dsps_writel(musb->ctrl_base, wrp->phy_utmi, val);

+   /*
+*  Check whether the dsps version has babble control enabled.


   One space too many before this sentence.


+* In latest silicon revision the babble control logic is enabled.
+* If MUSB_BABBLE_CTL returns 0x4 then we have the babble control
+* logic enabled.
+*/
+   val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   if (val == MUSB_BABBLE_RCV_DISABLE) {
+   glue->sw_babble_enabled = true;
+   val |= MUSB_BABBLE_SW_SESSION_CTRL;
+   dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
+   }
+


   Hm, from the register offset that you declared in the previous patch, I 
got an impression that this is a new standard MUSB register? Shouldn't this 
check be done in the generic MUSB code then?


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] DWC2: intializes the spin_lock earlier in the probe

2014-05-22 Thread Jean-Jacques Hiblot
The spinlock hsotg->lock is intialized at the end of the probe. However it
may be used from within dwc2_hcd_init(). This patch moves the
initialization before the call to dwc2_hcd_init(). This make the locking
correctness validator happy.

Signed-off-by: Jean-Jacques Hiblot 
---
 drivers/usb/dwc2/platform.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 37a8ab0..55fb30d 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -156,6 +156,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
params.dma_desc_enable = prop;
}
 
+   spin_lock_init(&hsotg->lock);
+
if (IS_ENABLED(CONFIG_USB_DWC2_HOST)) {
retval = dwc2_hcd_init(hsotg, irq, ¶ms);
if (retval)
@@ -175,7 +177,6 @@ static int dwc2_driver_probe(struct platform_device *dev)
if (retval)
return retval;
}
-   spin_lock_init(&hsotg->lock);
 
platform_set_drvdata(dev, hsotg);
return retval;
-- 
1.9.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


use of isochronous mode

2014-05-22 Thread Yves Martens
Hello,

I read the USB spec, understand when to prefer bulk vs. isochronous pipes. 
My usecase requires controlled jitter & guaranteed bandwidth.
But when discussing this with multiple peer engineers, rumor goes isochronous 
mode has 'issues' (sic), they advise me against using it altogether.

But when I try to pinpoint, I find nothing: 'isochronous' does not require more 
patches on this mailing list or in the git history; no panic stories on forums; 
commercial devices are few but do exist.
 
Does the Linux USB implementation supports both equally well? And also the 
scheduling of a mixture of both pipe types? For both USB 2 and 3?
Do you have an idea why many commercial devices (e.g. AV applications) still 
would go for bulk?

Thanks a lot & kind regards,
Yves
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 6/6] usb: musb: dsps: Enable sw babble control for newer silicon

2014-05-22 Thread George Cherian

On 5/22/2014 5:28 PM, Sergei Shtylyov wrote:

Hello.

On 22-05-2014 10:29, George Cherian wrote:


Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.



Signed-off-by: George Cherian 
---
  drivers/usb/musb/musb_dsps.c | 38 
--

  1 file changed, 32 insertions(+), 6 deletions(-)



diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 868caf8..2ced061 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c

[...]

@@ -469,6 +470,19 @@ static int dsps_musb_init(struct musb *musb)
  val &= ~(1 << wrp->otg_disable);
  dsps_writel(musb->ctrl_base, wrp->phy_utmi, val);

+/*
+ *  Check whether the dsps version has babble control enabled.


   One space too many before this sentence.


+ * In latest silicon revision the babble control logic is enabled.
+ * If MUSB_BABBLE_CTL returns 0x4 then we have the babble control
+ * logic enabled.
+ */
+val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+if (val == MUSB_BABBLE_RCV_DISABLE) {
+glue->sw_babble_enabled = true;
+val |= MUSB_BABBLE_SW_SESSION_CTRL;
+dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
+}
+


   Hm, from the register offset that you declared in the previous 
patch, I got an impression that this is a new standard MUSB register? 

Its very AM335x MUSB specific register, not a standard one.
Unfortunately the designers put it as part of MUSB core regs.

Shouldn't this check be done in the generic MUSB code then?

WBR, Sergei




--
-George

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] MIPS: MSP71xx: remove checks for two macros

2014-05-22 Thread Ralf Baechle
On Thu, May 22, 2014 at 11:34:51AM +0200, Paul Bolle wrote:

> Since v2.6.39 there are checks for CONFIG_MSP_HAS_DUAL_USB and checks
> for CONFIG_MSP_HAS_TSMAC in the code. The related Kconfig symbols have
> never been added. These checks have evaluated to false for three years
> now. Remove them and the code they have been hiding.

Queued for 3.16.

  Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: use of isochronous mode

2014-05-22 Thread Russel Hughes
>
> Does the Linux USB implementation supports both equally well? And also the 
> scheduling of a mixture of both pipe types? For both USB 2 and 3?
> Do you have an idea why many commercial devices (e.g. AV applications) still 
> would go for bulk?
>
> Thanks a lot & kind regards,
> Yves
> --

I have a DAC that use isochronous audio and it worked fine on USB 2.0,
then I bought an intel NUC which had USB 3.0 and it still does not
work after a couple of months of trying. Intel just say its a Linux
issue, however the people here have been very helpful and say its not
a driver issue, also I have heard it reported it works on a non intel
USB 3.0 hardware. Although I cannot say for sure, it looks like the
Intel hardware has a bug and they are reluctant to admit it. See
below.

forums.presonus.com/posts/list/33427.page


It might be worth contacting this guy to see if he can help.

usb.org/developers/presentations/pres1108/SuperSpeed_USB_DevCon_Isochronous_TengFroelich.pdf



BR

Russ
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v6 10/17] ARM: mvebu: add USB3 support for Armada 38x

2014-05-22 Thread Jason Cooper
On Wed, May 21, 2014 at 03:53:22PM +0200, Gregory CLEMENT wrote:
> On 19/05/2014 13:09, Paul Bolle wrote:
> > On Fri, 2014-05-16 at 15:07 -0400, Jason Cooper wrote:
> >> On Thu, May 15, 2014 at 12:17:35PM +0200, Gregory CLEMENT wrote:
> >>> This patch adds the selection of the config symbol needed to build the
> >>> USB3 support for Armada 38x into mvebu_v7_defconfig.
> >>>
> >>> Signed-off-by: Gregory CLEMENT 
> >>> Signed-off-by: Thomas Petazzoni 
> >>> ---
> >>>  arch/arm/mach-mvebu/Kconfig | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>
> >> Patches 10 and 11 applied to mvebu/soc
> > 
> > These two just hit linux-next (in next-20140519). They're pointless, as
> > config USB_ARCH_HAS_XHCI was dropped in commit b797b76fb464 ("usb: host:
> > remove USB_ARCH_HAS_?HCI").
> 
> Right! We didn't notice it.
> 
> Jason you can simply remove them from mvebu/soc when you will submit the pull 
> request

Now dropped from mvebu/soc.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: ASMedia AS2105 interface on USB 3.0 corrupts data

2014-05-22 Thread Alan Stern
On Thu, 22 May 2014, Heinz Diehl wrote:

> On 21.05.2014, Alan Stern wrote:
> 
> > In that case, I have no idea what else could be causing the problem.
> 
> Thanks for your   efforts!
> 
> If somebody of the developers is interested in debugging this, I'm
> willing to provide/give away the device for free. Send me
> an email with your postal adress in this case, and I'll send you 
> the controller mentioned in this thread. My GPG-key is available 
> from the link given in the header.

Mathias, this sounds like a pretty good opportunity for somebody at
Intel to use a USB-3 bus analyzer to solve some of the recurring
problems that have been affecting many people using Intel's xHCI
controllers.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: some question about usb_interrupt_msg

2014-05-22 Thread Alan Stern
On Thu, 22 May 2014, vichy wrote:

> hi all:
> I see usb_interrupt_msg do nothing but call usb_bulk_msg.
> Why we still keep usb_interrupt_msg?
> for old api compatibility?

That's right.  Also because it gives an indication to the reader about 
what type of transfer is being performed.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: USB 3.0 - Synopsis DWC Host-AHB - on Linux Kernel 3.10.28

2014-05-22 Thread Felipe Balbi
Hi,

curiosity: do you have Host-only or the DRD core ?

On Wed, May 21, 2014 at 02:53:33PM +0530, krishnamurthy holla wrote:
> Hello,
> 
> I am using Linux kernel 3.10.28 - MIPS processor (BIG Endian)
> 
> I see that XHCI fails during xhci_device_alloc() because of
> wait_for_completion_interruptible_timeout () when I connect a device.
> 
> So, I thought of initializing host controller as BE as my host is BE.
> But this time, it failed much earlier, i.e in xhci_handle_event()
> itself for the check le32_to_cpu(event->event_cmd.flags) & TRB_CYCLE)
> !=  xhci->event_ring->cycle_state)
> 
> I would like to know if any of you used Synopsis DWC Host-AHB and got
> successful device detection. Also, Please let me know if XHCI needs
> special configuration on Big Endian system.

two things:

a) newer kernel, possibly v3.14 or v3.15-rc6

b) enable debug and send logs :-)

cheers

-- 
balbi


signature.asc
Description: Digital signature


Re: use of isochronous mode

2014-05-22 Thread Alan Stern
On Thu, 22 May 2014, Yves Martens wrote:

> Hello,
> 
> I read the USB spec, understand when to prefer bulk vs. isochronous pipes. 
> My usecase requires controlled jitter & guaranteed bandwidth.
> But when discussing this with multiple peer engineers, rumor goes isochronous 
> mode has 'issues' (sic), they advise me against using it altogether.
> 
> But when I try to pinpoint, I find nothing: 'isochronous' does not require 
> more patches on this mailing list or in the git history; no panic stories on 
> forums; commercial devices are few but do exist.
>  
> Does the Linux USB implementation supports both equally well? And also the 
> scheduling of a mixture of both pipe types? For both USB 2 and 3?

In general, isochronous support isn't quite as good as bulk support.  
However, it varies with the driver.

For uhci-hcd and ohci-hcd, isochronous is supported just as well as
bulk.  The same is true for high-speed transfers with ehci-hcd, but for
full-speed transfers the isochronous support is a little weak.

Isochronous support on xhci-hcd is also somewhat weak.  It hasn't been 
tested very well, and there have been repeated reports of problems on 
Intel's xHCI controllers (other controllers seem to work better).

> Do you have an idea why many commercial devices (e.g. AV applications) still 
> would go for bulk?

Because the designers don't understand the tradeoffs very well.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: ASMedia AS2105 interface on USB 3.0 corrupts data

2014-05-22 Thread David Laight
From: Alan Stern
> On Thu, 22 May 2014, Heinz Diehl wrote:
> 
> > On 21.05.2014, Alan Stern wrote:
> >
> > > In that case, I have no idea what else could be causing the problem.
> >
> > Thanks for your efforts!
> >
> > If somebody of the developers is interested in debugging this, I'm
> > willing to provide/give away the device for free. Send me
> > an email with your postal adress in this case, and I'll send you
> > the controller mentioned in this thread. My GPG-key is available
> > from the link given in the header.
> 
> Mathias, this sounds like a pretty good opportunity for somebody at
> Intel to use a USB-3 bus analyzer to solve some of the recurring
> problems that have been affecting many people using Intel's xHCI
> controllers.

I'd also suggest you look through the patches I've posted.
Some of the changes would make the code much easier to read.

In the end we decided to use PCIe ethernet to get the extra connectivity
so didn't need to get the usb3 ethernet device working - but I did
have it working 100% reliably against an Intel host controller.
The Asmedia one has other issues.

David



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: use of isochronous mode

2014-05-22 Thread Alan Stern
On Thu, 22 May 2014, Russel Hughes wrote:

> >
> > Does the Linux USB implementation supports both equally well? And also the 
> > scheduling of a mixture of both pipe types? For both USB 2 and 3?
> > Do you have an idea why many commercial devices (e.g. AV applications) 
> > still would go for bulk?
> >
> > Thanks a lot & kind regards,
> > Yves
> > --
> 
> I have a DAC that use isochronous audio and it worked fine on USB 2.0,
> then I bought an intel NUC which had USB 3.0 and it still does not
> work after a couple of months of trying. Intel just say its a Linux
> issue, however the people here have been very helpful and say its not
> a driver issue, also I have heard it reported it works on a non intel
> USB 3.0 hardware. Although I cannot say for sure, it looks like the
> Intel hardware has a bug and they are reluctant to admit it. See
> below.
> 
> forums.presonus.com/posts/list/33427.page

It's worth noting that the Intel erratum mentioned on that page applies 
to Isochronous-IN transfers only, but people report problems with 
Isochronous-OUT as well.

Of course, there could easily be other bugs in Intel's hardware that 
they aren't aware of.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Alan Stern
On Thu, 22 May 2014, Will Deacon wrote:

> Hi all,
> 
> Although I don't think this is a new issue, booting mainline on my vexpress
> a9x4 (Quad ARMv7 Cortex-A9 board) with USB and PM_RUNTIME results in each
> CPU being constantly 20-50% loaded. A bit of investigation shows that this
> is due to the runtime-pm callbacks trying to autosuspend USB, despite this
5B> being unsupported by the host-controller (isp1760, which doesn't 
have a
> ->bus_suspend callback). I've included a backtrace at the bottom of this mail.
> 
> Anyway, since ->bus_suspend is not implemented, hcd_bus_suspend returns
> -ENOENT, which propagates back up to usb_runtime_suspend via usb_suspend_both.
> At this point, we override the return value with -EBUSY:
> 
> drivers/usb/core/driver.c:usb_runtime_suspend:
> 
>   /* The PM core reacts badly unless the return code is 0,
>* -EAGAIN, or -EBUSY, so always return -EBUSY on an error.
>*/
>   if (status != 0)
>   return -EBUSY;
> 
> This then tells the runtime PM code to try again:
> 
> drivers/base/power/runtime.c
> 
>   if (retval == -EAGAIN || retval == -EBUSY) {
>   dev->power.runtime_error = 0;
> 
>   /*
>* If the callback routine failed an autosuspend, and
>* if the last_busy time has been updated so that there
>* is a new autosuspend expiration time, automatically
>* reschedule another autosuspend.
>*/
>   if ((rpmflags & RPM_AUTO) &&
>   pm_runtime_autosuspend_expiration(dev) != 0)
>   goto repeat;
> 
> Consequently, I see a kworker thread on each CPU consuming a significant
> amount of the system resources. Worse, if I enable something like kmemleak
> (which adds more work to the failed suspend operation), I end up failing
> to boot entirely (NFS bombs out).
> 
> Reverting db7c7c0aeef5 ("usb: Always return 0 or -EBUSY to the runtime
> PM core.") fixes this for me, but the commit log suggests that will break
> lsusb. That patch has also been in for three and a half years...
> 
> Any ideas on how to fix this properly? In what ways does the PM core react
> badly to -ENOENT?

Okay, this is a bad problem.

The PM core takes any error response other than -EBUSY or -EAGAIN as an 
indication that the device is in a runtime-PM error state.  While that 
is appropriate for a USB device, perhaps it's not so appropriate for a 
USB host controller.

Anyway, there are two possible ways of handling this.  One is to avoid 
changing the error code to -EBUSY when the device in question is a root 
hub.  Just let it go into a runtime-PM error state; it won't matter 
since the controller doesn't support runtime PM anyway.  You can test 
this by changing the "if (status != 0)" line in usb_runtime_suspend to

if (status != 0 && udev->parent)

The other approach is to disable runtime PM for the root hub when the 
host controller driver doesn't have a bus_suspend or bus_resume method.
This seems like a cleaner approach; the patch below implements it.

Alan Stern



Index: usb-3.15/drivers/usb/core/hub.c
===
--- usb-3.15.orig/drivers/usb/core/hub.c
+++ usb-3.15/drivers/usb/core/hub.c
@@ -1703,8 +1703,19 @@ static int hub_probe(struct usb_interfac
 */
pm_runtime_set_autosuspend_delay(&hdev->dev, 0);
 
-   /* Hubs have proper suspend/resume support. */
-   usb_enable_autosuspend(hdev);
+   /*
+* Hubs have proper suspend/resume support, except for root hubs
+* where the controller driver doesn't have bus_suspend and
+* bus_resume methods.
+*/
+   if (hdev->parent) { /* normal device */
+   usb_enable_autosuspend(hdev);
+   } else {/* root hub */
+   const struct hc_driver *drv = bus_to_hcd(hdev->bus)->driver;
+
+   if (drv->bus_suspend && drv->bus_resume)
+   usb_enable_autosuspend(hdev);
+   }
 
if (hdev->level == MAX_TOPO_LEVEL) {
dev_err(&intf->dev,

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 RESEND] PREEMPT_RT: USB serial gadget: Fix locking issue

2014-05-22 Thread Jean-Jacques Hiblot
With CONFIG_PREEMPT_RT_FULL the tty_flip_buffer_push(..) actions are executed
immeditely (same behaviour as if low_latency flag was set). We thus have to
release port_lock before callng tty_flip_buffer_push().

This issue resultst of commits:
44a0c019: USB: g_serial: don't set low_latency flag
dc0cbd1b: serial: 8250: Call flush_to_ldisc when the irq is threaded

Signed-off-by: Jean-Jacques Hiblot 
---
changes since v1:
 - fix compilation problem: use port.tty instead of port->port_tty

 drivers/usb/gadget/u_serial.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
index b369292..3d4246d 100644
--- a/drivers/usb/gadget/u_serial.c
+++ b/drivers/usb/gadget/u_serial.c
@@ -549,12 +549,25 @@ static void gs_rx_push(unsigned long _port)
port->read_started--;
}

-   /* Push from tty to ldisc; without low_latency set this is handled by
-* a workqueue, so we won't get callbacks and can hold port_lock
-*/
-   if (do_push)
+   /* Push from tty to ldisc */
+   if (do_push) {
+#ifndef CONFIG_PREEMPT_RT_FULL
+   /* without low_latency set this is handled by a workqueue, so
+* we won't get callbacks and can hold port_lock
+   */
tty_flip_buffer_push(&port->port);
-
+#else
+   /* CONFIG_PREEMPT_RT_FULL makes this a synchronous action. and
+* it may trigger synchronous callbacks to this driver. We need
+* to release the lock.
+   */
+   spin_unlock_irq(&port->port_lock);
+   tty_flip_buffer_push(&port->port);
+   spin_lock_irq(&port->port_lock);
+   /* tty may have been closed */
+   tty = port->port.tty;
+#endif
+   }

/* We want our data queue to become empty ASAP, keeping data
 * in the tty and ldisc (not here).  If we couldn't push any
--
1.9.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/7] Multiple fixes for musb and cppi41

2014-05-22 Thread Daniel Mack
I've been trying to use the musb host controller for devices other
than USB mass storage like Wifi-Sticks and USB audio cards, and ran
into a larger number of nasty issues. After staring at hexdumps for
the better part of the last couple of days, I finally fixed all of
them. I used an external hardware USB analyzer to track down lost
packets, data toggle mismatches and stream starvation.

Here are 7 patches to fix the issues I've seen. Most of them affect
the musb <-> cppi41 glue layer, and #1 is for the cppi41 DMA driver.
Vinod, you can safely merge this one through your tree, as there's no
dependency to any other patch, and it's clearly fixing a bug.

Also, I'd actually say that all but #2 are candidates for stable@, but
I leave it to Felipe to decide that :)

Please have a look. More tests on AM335x are very welcome, and so are
regression tests for any other platform.


Thank,
Daniel

Daniel Mack (7):
  dma: cppi41: handle 0-length packets
  usb: musb: remove unnecessary (void) prefix at function calls
  usb: musb: use is_host_active() to distinguish between host and gadget
mode
  usb: musb: fix bit masks for CSR in musb_h_tx_flush_fifo()
  usb: musb: introduce dma_channel.packet_done
  usb: musb/cppi41: call musb_ep_select() before accessing an endpoint's
CSR
  usb: musb/cppi41: read data toggle from right endpoint

 drivers/dma/cppi41.c   | 13 ++---
 drivers/usb/musb/musb_core.c   | 16 +++-
 drivers/usb/musb/musb_cppi41.c | 15 ---
 drivers/usb/musb/musb_dma.h|  1 +
 drivers/usb/musb/musb_host.c   | 12 +++-
 5 files changed, 37 insertions(+), 20 deletions(-)

-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/7] dma: cppi41: handle 0-length packets

2014-05-22 Thread Daniel Mack
When a 0-length packet is received on the bus, desc->pd6 contains 1, and
the current residue calculation reports back that 1 byte has been
transferred. This is not according to what the datasheet says, but it's
been the case on an AM335x board, very reproducible.

Fix this by looking at bit 19 in PD2 of the completed packet. This bit
will tell us if a zero-length packet was received on a queue. If it's
set, ignore pd2 and report a total length of 0.

Signed-off-by: Daniel Mack 
---
 drivers/dma/cppi41.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index d028f36..8f8b0b6 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -86,6 +86,9 @@
 
 #define USBSS_IRQ_PD_COMP  (1 <<  2)
 
+/* Packet Descriptor */
+#define PD2_ZERO_LENGTH(1 << 19)
+
 struct cppi41_channel {
struct dma_chan chan;
struct dma_async_tx_descriptor txd;
@@ -307,7 +310,7 @@ static irqreturn_t cppi41_irq(int irq, void *data)
__iormb();
 
while (val) {
-   u32 desc;
+   u32 desc, len;
 
q_num = __fls(val);
val &= ~(1 << q_num);
@@ -319,9 +322,13 @@ static irqreturn_t cppi41_irq(int irq, void *data)
q_num, desc);
continue;
}
-   c->residue = pd_trans_len(c->desc->pd6) -
-   pd_trans_len(c->desc->pd0);
 
+   if (c->desc->pd2 & PD2_ZERO_LENGTH)
+   len = 0;
+   else
+   len = pd_trans_len(c->desc->pd0);
+
+   c->residue = pd_trans_len(c->desc->pd6) - len;
dma_cookie_complete(&c->txd);
c->txd.callback(c->txd.callback_param);
}
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/7] usb: musb: use is_host_active() to distinguish between host and gadget mode

2014-05-22 Thread Daniel Mack
On AM33xx platforms, unplugging a device in the middle of an active
transfer leads to a drop of MUSB_DEVCTL_HM in MUSB_DEVCTL before the
system is informed about a disconnect. This consequently makes the musb
core call the gadget code to handle the interrupt request, which then
crashes the kernel because the relevant pointers haven't been set up
for gadget mode.

To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM)
in musb_interrupt() and musb_dma_completion() to detect whether the
controller is in host or peripheral mode.

Signed-off-by: Daniel Mack 
---
 drivers/usb/musb/musb_core.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 1f8b175..a496af6 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1518,7 +1518,7 @@ irqreturn_t musb_interrupt(struct musb *musb)
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
 
dev_dbg(musb->controller, "** IRQ %s usb%04x tx%04x rx%04x\n",
-   (devctl & MUSB_DEVCTL_HM) ? "host" : "peripheral",
+   is_host_active(musb) ? "host" : "peripheral",
musb->int_usb, musb->int_tx, musb->int_rx);
 
/* the core can interrupt us for multiple reasons; docs have
@@ -1532,7 +1532,7 @@ irqreturn_t musb_interrupt(struct musb *musb)
 
/* handle endpoint 0 first */
if (musb->int_tx & 1) {
-   if (devctl & MUSB_DEVCTL_HM)
+   if (is_host_active(musb))
retval |= musb_h_ep0_irq(musb);
else
retval |= musb_g_ep0_irq(musb);
@@ -1546,7 +1546,7 @@ irqreturn_t musb_interrupt(struct musb *musb)
/* musb_ep_select(musb->mregs, ep_num); */
/* REVISIT just retval = ep->rx_irq(...) */
retval = IRQ_HANDLED;
-   if (devctl & MUSB_DEVCTL_HM)
+   if (is_host_active(musb))
musb_host_rx(musb, ep_num);
else
musb_g_rx(musb, ep_num);
@@ -1564,7 +1564,7 @@ irqreturn_t musb_interrupt(struct musb *musb)
/* musb_ep_select(musb->mregs, ep_num); */
/* REVISIT just retval |= ep->tx_irq(...) */
retval = IRQ_HANDLED;
-   if (devctl & MUSB_DEVCTL_HM)
+   if (is_host_active(musb))
musb_host_tx(musb, ep_num);
else
musb_g_tx(musb, ep_num);
@@ -1586,15 +1586,13 @@ MODULE_PARM_DESC(use_dma, "enable/disable use of DMA");
 
 void musb_dma_completion(struct musb *musb, u8 epnum, u8 transmit)
 {
-   u8  devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
-
/* called with controller lock already held */
 
if (!epnum) {
 #ifndef CONFIG_USB_TUSB_OMAP_DMA
if (!is_cppi_enabled()) {
/* endpoint 0 */
-   if (devctl & MUSB_DEVCTL_HM)
+   if (is_host_active(musb))
musb_h_ep0_irq(musb);
else
musb_g_ep0_irq(musb);
@@ -1603,13 +1601,13 @@ void musb_dma_completion(struct musb *musb, u8 epnum, 
u8 transmit)
} else {
/* endpoints 1..15 */
if (transmit) {
-   if (devctl & MUSB_DEVCTL_HM)
+   if (is_host_active(musb))
musb_host_tx(musb, epnum);
else
musb_g_tx(musb, epnum);
} else {
/* receive */
-   if (devctl & MUSB_DEVCTL_HM)
+   if (is_host_active(musb))
musb_host_rx(musb, epnum);
else
musb_g_rx(musb, epnum);
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/7] usb: musb: remove unnecessary (void) prefix at function calls

2014-05-22 Thread Daniel Mack
There's no point in casting these return value to void.
Remove it.

Signed-off-by: Daniel Mack 
---
 drivers/usb/musb/musb_host.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index eb06291..f98a7c0 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1295,7 +1295,7 @@ done:
if (status) {
if (dma_channel_status(dma) == MUSB_DMA_STATUS_BUSY) {
dma->status = MUSB_DMA_STATUS_CORE_ABORT;
-   (void) musb->dma_controller->channel_abort(dma);
+   musb->dma_controller->channel_abort(dma);
}
 
/* do the proper sequence to abort the transfer in the
@@ -1640,7 +1640,7 @@ void musb_host_rx(struct musb *musb, u8 epnum)
/* clean up dma and collect transfer count */
if (dma_channel_status(dma) == MUSB_DMA_STATUS_BUSY) {
dma->status = MUSB_DMA_STATUS_CORE_ABORT;
-   (void) musb->dma_controller->channel_abort(dma);
+   musb->dma_controller->channel_abort(dma);
xfer_len = dma->actual_len;
}
musb_h_flush_rxfifo(hw_ep, MUSB_RXCSR_CLRDATATOG);
@@ -1671,7 +1671,7 @@ void musb_host_rx(struct musb *musb, u8 epnum)
 */
if (dma_channel_status(dma) == MUSB_DMA_STATUS_BUSY) {
dma->status = MUSB_DMA_STATUS_CORE_ABORT;
-   (void) musb->dma_controller->channel_abort(dma);
+   musb->dma_controller->channel_abort(dma);
xfer_len = dma->actual_len;
done = true;
}
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 4/7] usb: musb: fix bit masks for CSR in musb_h_tx_flush_fifo()

2014-05-22 Thread Daniel Mack
The datasheet says that MUSB_TXCSR_FLUSHFIFO is only valid when
MUSB_CSR0_TXPKTRDY is set as well. Also, clear the MUSB_TXCSR_H_RXSTALL
which drivers are not supposed to write, according to the docs.

With this patch applied, the warning in this function does no longer
kicks in when an USB soundcard was unplugged while the stream was active.

Signed-off-by: Daniel Mack 
---
 drivers/usb/musb/musb_host.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index f98a7c0..9d3a5b2 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -120,7 +120,8 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep)
if (csr != lastcsr)
dev_dbg(musb->controller, "Host TX FIFONOTEMPTY csr: 
%02x\n", csr);
lastcsr = csr;
-   csr |= MUSB_TXCSR_FLUSHFIFO;
+   csr &= MUSB_TXCSR_H_RXSTALL;
+   csr |= MUSB_TXCSR_FLUSHFIFO | MUSB_CSR0_TXPKTRDY;
musb_writew(epio, MUSB_TXCSR, csr);
csr = musb_readw(epio, MUSB_TXCSR);
if (WARN(retries-- < 1,
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 6/7] usb: musb/cppi41: call musb_ep_select() before accessing an endpoint's CSR

2014-05-22 Thread Daniel Mack
When a DMA request is continued and a new inbound packet is requested,
make sure we're operating on the right endpooint. Otherwise, no new
packet is requested and the stream starves.

Signed-off-by: Daniel Mack 
---
 drivers/usb/musb/musb_cppi41.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index a11bbb6..e568930 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -173,6 +173,7 @@ static void cppi41_trans_done(struct cppi41_dma_channel 
*cppi41_channel)
dma_async_issue_pending(dc);
 
if (!cppi41_channel->is_tx) {
+   musb_ep_select(musb->mregs, hw_ep->epnum);
csr = musb_readw(epio, MUSB_RXCSR);
csr |= MUSB_RXCSR_H_REQPKT;
musb_writew(epio, MUSB_RXCSR, csr);
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 7/7] usb: musb/cppi41: read data toggle from right endpoint

2014-05-22 Thread Daniel Mack
The fixup for Advisory 1.0.13 ("USB: data may be lost when USB subsystem
is operating in DMA mode and more than one endpoint is transferring
data") reads the USB data toggle each time a packet is given back from
the DMA controller. It does so in order to detect mismatches and
restoring the DATA1 toggle which might have erroneously been dropped, as
described as a workaround in the errata.

However, as the endpoint is not explictly selected before reading the
CSR register, the code operates on wrong register data and detects
mismatches where none are. By fixing up in such occasions, the toggle
mechanism is confused, and the controller drops packets that are out of
sync.

Fix this by calling musb_ep_select() in those functions.

Signed-off-by: Daniel Mack 
---
 drivers/usb/musb/musb_cppi41.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index e568930..38fd1d1 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -58,14 +58,17 @@ struct cppi41_dma_controller {
 
 static void save_rx_toggle(struct cppi41_dma_channel *cppi41_channel)
 {
+   struct musb_hw_ep *hw_ep = cppi41_channel->hw_ep;
+   struct musb *musb = hw_ep->musb;
u16 csr;
u8 toggle;
 
if (cppi41_channel->is_tx)
return;
-   if (!is_host_active(cppi41_channel->controller->musb))
+   if (!is_host_active(musb))
return;
 
+   musb_ep_select(musb->mregs, hw_ep->epnum);
csr = musb_readw(cppi41_channel->hw_ep->regs, MUSB_RXCSR);
toggle = csr & MUSB_RXCSR_H_DATATOGGLE ? 1 : 0;
 
@@ -74,15 +77,18 @@ static void save_rx_toggle(struct cppi41_dma_channel 
*cppi41_channel)
 
 static void update_rx_toggle(struct cppi41_dma_channel *cppi41_channel)
 {
+   struct musb_hw_ep *hw_ep = cppi41_channel->hw_ep;
+   struct musb *musb = hw_ep->musb;
u16 csr;
u8 toggle;
 
if (cppi41_channel->is_tx)
return;
-   if (!is_host_active(cppi41_channel->controller->musb))
+   if (!is_host_active(musb))
return;
 
-   csr = musb_readw(cppi41_channel->hw_ep->regs, MUSB_RXCSR);
+   musb_ep_select(musb->mregs, hw_ep->epnum);
+   csr = musb_readw(hw_ep->regs, MUSB_RXCSR);
toggle = csr & MUSB_RXCSR_H_DATATOGGLE ? 1 : 0;
 
/*
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 5/7] usb: musb: introduce dma_channel.packet_done

2014-05-22 Thread Daniel Mack
The musb/cppi41 glue layer is capable of handling transactions that span
over more than one USB packet by reloading the DMA descriptors
partially. An urb is considered completed when either its transfer
buffer has been filled entirely (actual_length ==
transfer_buffer_length) or if a packet in the stream has less bytes than
the endpoint's wMaxPacketSize.

Once one of the above conditions is met, musb_dma_completion() is called
from cppi41_trans_done(). However, the final decision whether or not to
return the urb to its owner is made by the core, which currently has no
way of knowing what the last packet size was, as long as DMA and a glue
layer is involved. Hence, it won't give the urb back, effectively
starving the data stream.

Fix this by introducing a new boolean flag in 'struct dma_channel'
which, and set it from musb_cppi41.c. If set, it will make the core do
what the DMA layer decided and complete the urb.

Signed-off-by: Daniel Mack 
---
 drivers/usb/musb/musb_cppi41.c | 2 ++
 drivers/usb/musb/musb_dma.h| 1 +
 drivers/usb/musb/musb_host.c   | 3 ++-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 7b8bbf5..a11bbb6 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -139,6 +139,7 @@ static void cppi41_trans_done(struct cppi41_dma_channel 
*cppi41_channel)
cppi41_channel->channel.actual_len =
cppi41_channel->transferred;
cppi41_channel->channel.status = MUSB_DMA_STATUS_FREE;
+   cppi41_channel->channel.packet_done = true;
musb_dma_completion(musb, hw_ep->epnum, cppi41_channel->is_tx);
} else {
/* next iteration, reload */
@@ -450,6 +451,7 @@ static bool cppi41_configure_channel(struct dma_channel 
*channel,
dma_desc->callback = cppi41_dma_callback;
dma_desc->callback_param = channel;
cppi41_channel->cookie = dma_desc->tx_submit(dma_desc);
+   cppi41_channel->channel.packet_done = false;
 
save_rx_toggle(cppi41_channel);
dma_async_issue_pending(dc);
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 1345a4f..7253358 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -129,6 +129,7 @@ struct dma_channel {
size_t  actual_len;
enum dma_channel_status status;
booldesired_mode;
+   boolpacket_done;
 };
 
 /*
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 9d3a5b2..6531426 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1738,7 +1738,8 @@ void musb_host_rx(struct musb *musb, u8 epnum)
/* done if urb buffer is full or short packet is recd */
done = (urb->actual_length + xfer_len >=
urb->transfer_buffer_length
-   || dma->actual_len < qh->maxpacket);
+   || dma->actual_len < qh->maxpacket
+   || dma->packet_done);
}
 
/* send IN token for next packet, without AUTOREQ */
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] usb: ehci: Enable support for 64bit EHCI host controllers in arm64

2014-05-22 Thread Catalin Marinas
On Mon, May 19, 2014 at 09:21:17AM +0100, Jon Medhurst (Tixy) wrote:
> On Fri, 2014-05-16 at 18:40 +0100, Catalin Marinas wrote:
> > On Fri, May 16, 2014 at 06:08:45PM +0100, Jon Medhurst (Tixy) wrote:
> > > On Fri, 2014-05-16 at 13:55 +0100, Catalin Marinas wrote:
> > > [...]
> > > > > It could if arm64 would restrict the DMA addresses to 32-bit, but it 
> > > > > doesn't
> > > > > and I end up on my platform with USB DMA buffers allocated >4GB 
> > > > > address.
> > > > 
> > > > dma_alloc_coherent() on arm64 should return 32-bit addresses if the
> > > > coherent_dma_mask is set to 32-bit.
> > > 
> > > Not if you have CONFIG_DMA_CMA. Unless I have misread the code, enabling
> > > CMA means memory comes from a common pool carved out at boot with no way
> > > for drivers to specify it's restrictions [1]. It's what I've spent most
> > > of the week trying to work around in a clean way, and have finally given
> > > up.
> > 
> > The easiest "hack" would be to pass a limit dma_contiguous_reserve()
> > in arm64_memblock_init(), something like this:
> 
> That is by far the easiest but I dismissed it because it affects all
> platforms built from that source tree; and if the hack were extended to
> include a kernel config option, that still may not work on a single
> kernel binary expected to work on multiple platforms. Basically, I've
> tried various was to do it 'properly' and after failing am resorting to
> truly hideous hacks to the (out-of-tree driver) code - so at least other
> platforms won't be impacted.

Can you set a specific reserved memory region in the DT to be used by
CMA (via linux,cma-default), or it's just for the default size?

On arm64 we enabled CONFIG_DMA_CMA by default but compared to swiotlb it
doesn't honour GFP_DMA. The arm32 port sets the CMA limit to
arm_dma_limit which is 32-bit or a SoC-define one. So I'm tempted to
default to 32-bit as well if it can be overridden via DT.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] usb: ehci: Enable support for 64bit EHCI host controllers in arm64

2014-05-22 Thread Jon Medhurst (Tixy)
On Thu, 2014-05-22 at 16:59 +0100, Catalin Marinas wrote:
> On Mon, May 19, 2014 at 09:21:17AM +0100, Jon Medhurst (Tixy) wrote:
> > On Fri, 2014-05-16 at 18:40 +0100, Catalin Marinas wrote:
> > > On Fri, May 16, 2014 at 06:08:45PM +0100, Jon Medhurst (Tixy) wrote:
> > > > On Fri, 2014-05-16 at 13:55 +0100, Catalin Marinas wrote:
> > > > [...]
> > > > > > It could if arm64 would restrict the DMA addresses to 32-bit, but 
> > > > > > it doesn't
> > > > > > and I end up on my platform with USB DMA buffers allocated >4GB 
> > > > > > address.
> > > > > 
> > > > > dma_alloc_coherent() on arm64 should return 32-bit addresses if the
> > > > > coherent_dma_mask is set to 32-bit.
> > > > 
> > > > Not if you have CONFIG_DMA_CMA. Unless I have misread the code, enabling
> > > > CMA means memory comes from a common pool carved out at boot with no way
> > > > for drivers to specify it's restrictions [1]. It's what I've spent most
> > > > of the week trying to work around in a clean way, and have finally given
> > > > up.
> > > 
> > > The easiest "hack" would be to pass a limit dma_contiguous_reserve()
> > > in arm64_memblock_init(), something like this:
> > 
> > That is by far the easiest but I dismissed it because it affects all
> > platforms built from that source tree; and if the hack were extended to
> > include a kernel config option, that still may not work on a single
> > kernel binary expected to work on multiple platforms. Basically, I've
> > tried various was to do it 'properly' and after failing am resorting to
> > truly hideous hacks to the (out-of-tree driver) code - so at least other
> > platforms won't be impacted.
> 
> Can you set a specific reserved memory region in the DT to be used by
> CMA (via linux,cma-default), or it's just for the default size?

The bindings and infrastructure got half merged in 3.15 but the patches
to actually make this usable in drivers are stalled...
http://lkml.org/lkml/2014/5/14/201

> On arm64 we enabled CONFIG_DMA_CMA by default but compared to swiotlb it
> doesn't honour GFP_DMA. The arm32 port sets the CMA limit to
> arm_dma_limit which is 32-bit or a SoC-define one. So I'm tempted to
> default to 32-bit as well if it can be overridden via DT.

I believe the CMA pool could have been over-ridden if the stalled
patches been accepted. I believe the specific patch for that is
http://lkml.org/lkml/2014/2/28/278

The bindings for all this CMA stuf is in
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt

-- 
Tixy

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] usb: usbtest: add pattern check on pipe in phase of unlink read

2014-05-22 Thread Alan Stern
On Thu, 22 May 2014, Huang Rui wrote:

> TEST 11 unlinks the URB read request for N times. When host and gadget
> both initialize pattern 1 (mod 63) data series to do IN transfer, the
> host side function should check the data buffer if it is as mod 63
> series, because the data packet which host receivced will follow
> pattern 1. So this patch adds this checking action.
> 
> Signed-off-by: Huang Rui 

Maybe you should also change the unlink_queued() routine, which is used 
in Test 24.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Will Deacon
Hi Alan,

On Thu, May 22, 2014 at 04:02:06PM +0100, Alan Stern wrote:
> On Thu, 22 May 2014, Will Deacon wrote:
> > Consequently, I see a kworker thread on each CPU consuming a significant
> > amount of the system resources. Worse, if I enable something like kmemleak
> > (which adds more work to the failed suspend operation), I end up failing
> > to boot entirely (NFS bombs out).
> > 
> > Reverting db7c7c0aeef5 ("usb: Always return 0 or -EBUSY to the runtime
> > PM core.") fixes this for me, but the commit log suggests that will break
> > lsusb. That patch has also been in for three and a half years...
> > 
> > Any ideas on how to fix this properly? In what ways does the PM core react
> > badly to -ENOENT?
> 
> Okay, this is a bad problem.
> 
> The PM core takes any error response other than -EBUSY or -EAGAIN as an 
> indication that the device is in a runtime-PM error state.  While that 
> is appropriate for a USB device, perhaps it's not so appropriate for a 
> USB host controller.
> 
> Anyway, there are two possible ways of handling this.  One is to avoid 
> changing the error code to -EBUSY when the device in question is a root 
> hub.  Just let it go into a runtime-PM error state; it won't matter 
> since the controller doesn't support runtime PM anyway.  You can test 
> this by changing the "if (status != 0)" line in usb_runtime_suspend to
> 
>   if (status != 0 && udev->parent)

I'd tried something like this already, but I prefer your patch below. Plus,
this hack results in a failure being logged to dmesg on the initial suspend
attempt.

> The other approach is to disable runtime PM for the root hub when the 
> host controller driver doesn't have a bus_suspend or bus_resume method.
> This seems like a cleaner approach; the patch below implements it.

Thanks for this! I can confirm that your patch below fixes the issue for me,
so:

  Reported-by: Will Deacon 
  Tested-by: Will Deacon 

Cheers,

Will

> Index: usb-3.15/drivers/usb/core/hub.c
> ===
> --- usb-3.15.orig/drivers/usb/core/hub.c
> +++ usb-3.15/drivers/usb/core/hub.c
> @@ -1703,8 +1703,19 @@ static int hub_probe(struct usb_interfac
>*/
>   pm_runtime_set_autosuspend_delay(&hdev->dev, 0);
>  
> - /* Hubs have proper suspend/resume support. */
> - usb_enable_autosuspend(hdev);
> + /*
> +  * Hubs have proper suspend/resume support, except for root hubs
> +  * where the controller driver doesn't have bus_suspend and
> +  * bus_resume methods.
> +  */
> + if (hdev->parent) { /* normal device */
> + usb_enable_autosuspend(hdev);
> + } else {/* root hub */
> + const struct hc_driver *drv = bus_to_hcd(hdev->bus)->driver;
> +
> + if (drv->bus_suspend && drv->bus_resume)
> + usb_enable_autosuspend(hdev);
> + }
>  
>   if (hdev->level == MAX_TOPO_LEVEL) {
>   dev_err(&intf->dev,
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] USB: Add LVS Test device driver

2014-05-22 Thread Alan Stern
On Thu, 22 May 2014, Pratyush Anand wrote:

> OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
> system (SS-OVS) which consists of an excersizer and analyzer.
> 
> USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
> Link Layer Validation (LVS).
> 
> Some modifications are needed for an embedded Linux USB host to pass all
> these tests.  Most of these tests require just Link to be in U0. They do
> not work with default Linux USB stack since, default stack does port
> reset and then starts sending setup packet, which is not expected by
> Link Layer Validation (LVS) device of Lecroy Compliance Suit.  Then,
> There are many Link Layer Tests which need host to generate specific
> traffic.
> 
> This patch supports specific traffic generation cases. As of now all the
> host Lecroy Link Layer-USBIF tests (except TD7.26) passes
> with this patch for single run using  Lecroy USB Compliance Suite
> Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
> Build 1603. Therefore patch seems to be a good candidate for inclusion.
> Further modification can be done on top of it.
> 
> lvstest driver will not bind to any device by default. It can bind
> manually to a super speed USB host controller root hub. Therefore, regular
> hub driver must be unbound before this driver is bound. For example, if
> 2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.
> 
>  echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind
> 
> Then to bind lvs driver write Linux Foundation's vendor ID and SS root
> hub's device ID into new_id file.
> 
>  echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id
> 
> Now connect LVS device with root hub port.

You forgot to include an example here showing how to do this:

  echo 2-0\:1.0 > /sys/bus/usb/drivers/lvs/bind

> Test case specific traffic can be generated as follows whenever needed:
> 
> 1. To issue "Get Device descriptor" command for TD.7.06:
>  echo 1 > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc
> 
> 2. To set U1 timeout to 127 for TD.7.18
>  echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout
> 
> 3. To set U2 timeout to 0 for TD.7.18
>  echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout
> 
> 4. To issue "Hot Reset" for TD.7.29
>  echo 1 > /sys/bus/usb/devices/2-0\:1.0/hot_reset
> 
> 5. To issue "U3 Entry" for TD.7.35
>  echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_entry
> 
> 6. To issue "U3 Exit" for TD.7.36
>  echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_exit

None of those example need to contain the "1".  For instance, the last 
one should be written:

  echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

> diff --git a/Documentation/ABI/testing/sysfs-bus-usb-lvstest 
> b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
> new file mode 100644
> index 000..f47e8a3
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
> @@ -0,0 +1,47 @@
> +Link Layer Validation Device is a standard device for testing of Super
> +Speed Link Layer tests. These nodes are available in sysfs only when lvs
> +driver is bound with root hub device.
> +
> +What:/sys/bus/usb/devices/.../get_dev_desc
> +Date:March 2014
> +Contact: Pratyush Anand 
> +Description:
> + Write to this node to issue "Get Device Descriptor"
> + for Link Layer Validation device. It is needed for TD.7.06.
> +
> +What:/sys/bus/usb/devices/.../u1_timeout
> +Date:March 2014
> +Contact: Pratyush Anand 
> +Description:
> + Set "U1 timeout" for the downstream port where Link Layer
> + Validation device is connected. It is needed for TD.7.18,
> + TD.7.19, TD.7.20 and TD.7.21.

This doesn't say that the value must be between 0 and 127.

> +
> +What:/sys/bus/usb/devices/.../u2_timeout
> +Date:March 2014
> +Contact: Pratyush Anand 
> +Description:
> + Set "U2 timeout" for the downstream port where Link Layer
> + Validation device is connected. It is needed for TD.7.18,
> + TD.7.19, TD.7.20 and TD.7.21.

Same here.

> +static void lvs_rh_work(struct work_struct *work)
> +{
> + struct lvs_rh *lvs = container_of(work, struct lvs_rh, rh_work);
> + struct usb_interface *intf = lvs->intf;
> + struct usb_device *hdev = interface_to_usbdev(intf);
> + struct usb_hcd *hcd = bus_to_hcd(hdev->bus);
> + struct usb_hub_descriptor *descriptor = &lvs->descriptor;
> + struct usb_port_status port_status;
> + int i, ret = 0;
> +
> + /* Examine each root port */
> + for (i = 1; i <= descriptor->bNbrPorts; i++) {
> + ret = usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),
> + USB_REQ_GET_STATUS, USB_DIR_IN | USB_RT_PORT, 0, i,
> + &port_status, sizeof(port_status), 1000);

You must not use I/O buffers allocated on the stack.  The buffer must
be allocated by kmalloc or something equivalent.

> + if (ret <

Re: Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Alan Stern
On Thu, 22 May 2014, Will Deacon wrote:

> > Anyway, there are two possible ways of handling this.  One is to avoid 
> > changing the error code to -EBUSY when the device in question is a root 
> > hub.  Just let it go into a runtime-PM error state; it won't matter 
> > since the controller doesn't support runtime PM anyway.  You can test 
> > this by changing the "if (status != 0)" line in usb_runtime_suspend to
> > 
> > if (status != 0 && udev->parent)
> 
> I'd tried something like this already, but I prefer your patch below. Plus,
> this hack results in a failure being logged to dmesg on the initial suspend
> attempt.
> 
> > The other approach is to disable runtime PM for the root hub when the 
> > host controller driver doesn't have a bus_suspend or bus_resume method.
> > This seems like a cleaner approach; the patch below implements it.
> 
> Thanks for this! I can confirm that your patch below fixes the issue for me,
> so:
> 
>   Reported-by: Will Deacon 
>   Tested-by: Will Deacon 

You know, I think it might be best to make both changes.  Even though 
runtime PM will be disabled by default, the user can always override 
this setting.  If that happens, the suspend should fail with the proper 
error code instead of going into a loop.

Do you mind if I add the change to usb_runtime_suspend() in the patch?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] DWC2: intializes the spin_lock earlier in the probe

2014-05-22 Thread Paul Zimmerman
> From: Jean-Jacques Hiblot [mailto:jjhib...@traphandler.com]
> Sent: Thursday, May 22, 2014 5:10 AM
> 
> The spinlock hsotg->lock is intialized at the end of the probe. However it
> may be used from within dwc2_hcd_init(). This patch moves the
> initialization before the call to dwc2_hcd_init(). This make the locking
> correctness validator happy.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/usb/dwc2/platform.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 37a8ab0..55fb30d 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -156,6 +156,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
>   params.dma_desc_enable = prop;
>   }
> 
> + spin_lock_init(&hsotg->lock);
> +
>   if (IS_ENABLED(CONFIG_USB_DWC2_HOST)) {
>   retval = dwc2_hcd_init(hsotg, irq, ¶ms);
>   if (retval)
> @@ -175,7 +177,6 @@ static int dwc2_driver_probe(struct platform_device *dev)
>   if (retval)
>   return retval;
>   }
> - spin_lock_init(&hsotg->lock);
> 
>   platform_set_drvdata(dev, hsotg);
>   return retval;
> --

Hmm. What tree is this against? platform.c in both Linus' tree and in
Greg's usb-next tree does not have a call to spin_lock_init().

-- 
Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


skbuff truesize incorrect.

2014-05-22 Thread Jim Baxter
Hi, I was hoping you can help me with some questions.

I have been investigating a network issue with bursts of network traffic
over USB CDC-NCM, the issue is that the kernel is dropping packets
because sk_rcvqueues_full() returns true due to skb2->truesize is always
32960 instead of SKB_TRUESIZE(skb2->len) which is about 1800.

The code I am trying to fix is this code below, it is splitting a set of
multiple network packets compressed into a single 16k packet into
individual skb's and sending them up the network stack.

skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2 == NULL)
goto err;

if (!skb_pull(skb2, index)) {
ret = -EOVERFLOW;
goto err;
}

skb_trim(skb2, dg_len - crc_len);

My questions are:

1) Which buffer size does truesize represent, is it the total buffer or
just the data related to the relevant skb?

2) If truesize is for the skb it is contained within should it be
updated during the call to skb_trim?

3) Why does the truesize default to 32960?


Thank you for any help,
Jim Baxter.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: skbuff truesize incorrect.

2014-05-22 Thread David Miller
From: Jim Baxter 
Date: Thu, 22 May 2014 20:07:41 +0100

> My questions are:
> 
> 1) Which buffer size does truesize represent, is it the total buffer or
> just the data related to the relevant skb?
> 
> 2) If truesize is for the skb it is contained within should it be
> updated during the call to skb_trim?
> 
> 3) Why does the truesize default to 32960?

skb->truesize represents the total amount of memory that the SKB
is holding up.

This is the size of the sk_buff metadata plus all of the buffer
memory.

For example, if the buffer is using 16K buffer yet only 1500 of it is
actually used for the packet, 16K is what should be plugged into the
equation to compute truesize.

Otherwise it would be easy to compromise a system by sending lots of 1
byte packets to a socket, even though the actual memory consumed by
that "1 byte" packet is significantly larger.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: skbuff truesize incorrect.

2014-05-22 Thread Vlad Yasevich
On 05/22/2014 03:07 PM, Jim Baxter wrote:
> Hi, I was hoping you can help me with some questions.
> 
> I have been investigating a network issue with bursts of network traffic
> over USB CDC-NCM, the issue is that the kernel is dropping packets
> because sk_rcvqueues_full() returns true due to skb2->truesize is always
> 32960 instead of SKB_TRUESIZE(skb2->len) which is about 1800.
> 
> The code I am trying to fix is this code below, it is splitting a set of
> multiple network packets compressed into a single 16k packet into
> individual skb's and sending them up the network stack.
> 
> skb2 = skb_clone(skb, GFP_ATOMIC);
> if (skb2 == NULL)
> goto err;
> 
> if (!skb_pull(skb2, index)) {
> ret = -EOVERFLOW;
> goto err;
> }

This assumes that you original 16K packet is linear.  Is that
always the case?

> 
> skb_trim(skb2, dg_len - crc_len);
> 
> My questions are:
> 
> 1) Which buffer size does truesize represent, is it the total buffer or
> just the data related to the relevant skb?

Total buffer size (including the struct sk_buff).

> 
> 2) If truesize is for the skb it is contained within should it be
> updated during the call to skb_trim?

No, because the the buffer/memory is still there.  skb_trim just
sets the tail pointer and adjusts skb->len.


> 
> 3) Why does the truesize default to 32960?

Probably because that's how much buffer space was actually allocated
for the original skb.  When you cloned it, you inherited the truesize
since a clone is just the struct sk_buff that points into the data
of the original.

This is the very same problem that I ran into with SCTP since it
has similar code in it.  You can play games with truesize manually,
but you have to be very careful here.

-vlad
> 
> 
> Thank you for any help,
> Jim Baxter.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: skbuff truesize incorrect.

2014-05-22 Thread Jim Baxter
On 22/05/14 20:25, Vlad Yasevich wrote:
> On 05/22/2014 03:07 PM, Jim Baxter wrote:
>>
>> skb2 = skb_clone(skb, GFP_ATOMIC);
>> if (skb2 == NULL)
>> goto err;
>>
>> if (!skb_pull(skb2, index)) {
>> ret = -EOVERFLOW;
>> goto err;
>> }
> 
> This assumes that you original 16K packet is linear.  Is that
> always the case?
The packets within the original packet are linear, however they could be
in an arbitrary order because they are just offsets from the start of
the 16k skb.


> 
> This is the very same problem that I ran into with SCTP since it
> has similar code in it.  You can play games with truesize manually,
> but you have to be very careful here.
> 
> -vlad

I now think that the correct solution here is to create a new smaller
skb and copy the data from the sub packets into it.

Jim



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: skbuff truesize incorrect.

2014-05-22 Thread Eric Dumazet
On Thu, 2014-05-22 at 20:39 +0100, Jim Baxter wrote:

> I now think that the correct solution here is to create a new smaller
> skb and copy the data from the sub packets into it.

For low speed devices, this is indeed the best way.

(this is called copybreak in some nic drivers)



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] Add can_do_streams to dummy_hcd

2014-05-22 Thread Pantelis Koukousoulas
I was puzzled why uas didn't accept to bind to tcm_usb_gadget via dummy_hcd.
Debugging showed that recent commit (14aec589327a6fc4035f5327d90ac5548f501c4c)
added the field can_do_streams to hcd structure but only set it to 1 in the
xhci driver.

dummy_hcd seems to support superspeed and streams fine, so I added
can_do_streams = 1 to dummy_hcd as well. This seems to allow uas
to bind again and as a result performance increased more than 3x :)
---
 drivers/usb/gadget/dummy_hcd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index 8c06430..67ebf90 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -2544,6 +2544,8 @@ static int dummy_hcd_probe(struct platform_device *pdev)
retval = usb_add_hcd(ss_hcd, 0, 0);
if (retval)
goto put_usb3_hcd;
+
+   ss_hcd->can_do_streams = 1;
}
return 0;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: skbuff truesize incorrect.

2014-05-22 Thread Jim Baxter
On 22/05/14 20:21, David Miller wrote:
> From: Jim Baxter 
> Date: Thu, 22 May 2014 20:07:41 +0100
> 
>> My questions are:
>>
>> 1) Which buffer size does truesize represent, is it the total buffer or
>> just the data related to the relevant skb?
>>
>> 2) If truesize is for the skb it is contained within should it be
>> updated during the call to skb_trim?
>>
>> 3) Why does the truesize default to 32960?
> 
> skb->truesize represents the total amount of memory that the SKB
> is holding up.
> 
> This is the size of the sk_buff metadata plus all of the buffer
> memory.
> 
> For example, if the buffer is using 16K buffer yet only 1500 of it is
> actually used for the packet, 16K is what should be plugged into the
> equation to compute truesize.
> 
> Otherwise it would be easy to compromise a system by sending lots of 1
> byte packets to a socket, even though the actual memory consumed by
> that "1 byte" packet is significantly larger.
> 

OK, so it is the value of the memory that has been allocated for the SKB.
If there are multiple clones for an skb all pointing at the same data,
will that distort the memory used when they all have the same truesize?

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: skbuff truesize incorrect.

2014-05-22 Thread Eric Dumazet
On Thu, 2014-05-22 at 21:21 +0100, Jim Baxter wrote:


> OK, so it is the value of the memory that has been allocated for the SKB.
> If there are multiple clones for an skb all pointing at the same data,
> will that distort the memory used when they all have the same truesize?

Its always better to over estimate memory uses, than under estimating.

Its all about guarding against OOM.

Keep in mind some parts of networking stack do not like clones.

TCP coalescing works beautifully with non cloned skbs.

Instead of cloning skb or doing copies, you could play with having frame
on a page fragment. Only headers might need to be pulled from the frame
to linear part of skb.





--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: skbuff truesize incorrect.

2014-05-22 Thread Jim Baxter
On 22/05/14 20:59, Eric Dumazet wrote:
> On Thu, 2014-05-22 at 20:39 +0100, Jim Baxter wrote:
> 
>> I now think that the correct solution here is to create a new smaller
>> skb and copy the data from the sub packets into it.
> 
> For low speed devices, this is indeed the best way.
> 
> (this is called copybreak in some nic drivers)
> 
> 
> 
Thank you Eric.

It is USB device that can handle 480Mbits/s so a middle speed device.

It looks like it is the normal trade off of speed versus memory. Either
I can use skb_clone for speed but that will impact memory with multiple
skb's of 16k or I copy the data to keep the memory usage low. Though
copying 2k of data into an skb will not likely be a massive overhead.

Jim
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 1/6] usb: musb: core: Handle Babble condition only in HOST mode

2014-05-22 Thread Bin Liu
Hi George,

On Mon, May 19, 2014 at 11:32 PM, George Cherian  wrote:
> Hi Bin,
>
> On 5/19/2014 9:24 PM, Bin Liu wrote:
>>
>> Hi,
>>
>> On Mon, May 19, 2014 at 8:39 AM, George Cherian 
>> wrote:
>>>
>>> BABBLE and RESET share the same interrupt. The interrupt
>>> is considered to be RESET if MUSB is in peripheral mode and
>>> as a BABBLE if MUSB is in HOST mode.
>>>
>>> Handle babble condition iff MUSB is in HOST mode.
>>>
>>> Signed-off-by: George Cherian 
>>> ---
>>>   drivers/usb/musb/musb_core.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>>> index 61da471..eff3c5c 100644
>>> --- a/drivers/usb/musb/musb_core.c
>>> +++ b/drivers/usb/musb/musb_core.c
>>> @@ -849,7 +849,7 @@ b_host:
>>>  }
>>>
>>>  /* handle babble condition */
>>> -   if (int_usb & MUSB_INTR_BABBLE)
>>> +   if (int_usb & MUSB_INTR_BABBLE && is_host_active(musb))
>>>  schedule_work(&musb->recover_work);
>>
>> I guess my following comments are for Daniel's patch as while which
>> initially added the babble work.
>>
>> Should this if statement be merged into the previous 'if(int_usb &
>> MUSB_INTR_RESET)' one, which handles the same interrupt and already
>> handles host and device mode respectively.
>
>
> Initially I too had the babble handling as part of  'if(int_usb &
> MUSB_INTR_RESET)'
> one. But during my tests I hit a corner case where in we hit a BABBLE
> condition
> on disconnect. In such case the babble interrupt can be handled only if we
> have a seperate
> check, else its considered as a BUS RESET.
>
> When all devices are disconnected  MUSB_DEVCTL_HM = 0 and the code always
> enter the
> else path. In this path it treats the BABBLE as a BUS RESET.

The code flow is a bit confusing, two if() handle the same interrupt.
The second one implied using 'handled = IRQ_HANDLED;' from the first
one.
Also does the switch() in else{} in the first if() cause any side effect?

Since this babble handing is AM335x specific, how about handle it in
dsps_interrupt() in musb_dsps.c, which already has an entry for babble
interrupt? TI 3.2 kernel does this way.

Regards,
-Bin.

>
>
>> Regards,
>> -Bin.
>>
>>>   #if 0
>>> --
>>> 1.8.3.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> -George
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: skbuff truesize incorrect.

2014-05-22 Thread Eric Dumazet
On Thu, 2014-05-22 at 20:07 +0100, Jim Baxter wrote:

> 
> I have been investigating a network issue with bursts of network traffic
> over USB CDC-NCM, the issue is that the kernel is dropping packets
> because sk_rcvqueues_full() returns true due to skb2->truesize is always
> 32960 instead of SKB_TRUESIZE(skb2->len) which is about 1800.
> 
> The code I am trying to fix is this code below, it is splitting a set of
> multiple network packets compressed into a single 16k packet into
> individual skb's and sending them up the network stack.

if skb are allocated with 16k = 16384 bytes, adding the struct
skb_shared_info overhead and rounding up to power of two gives 32768
bytes.

Chances to be able to allocate 32KB contiguous memory are slim after a
while.

I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not
use high order allocations.

What is the exact 'overhead' using ~4K instead of 16K exactly on this
hardware ?



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: skbuff truesize incorrect.

2014-05-22 Thread David Miller
From: Jim Baxter 
Date: Thu, 22 May 2014 21:21:55 +0100

> If there are multiple clones for an skb all pointing at the same data,
> will that distort the memory used when they all have the same truesize?

What is distorted about it?

Each clone references exactly that much backing memory.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: skbuff truesize incorrect.

2014-05-22 Thread Eric Dumazet
On Thu, 2014-05-22 at 13:58 -0700, Eric Dumazet wrote:

> I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not
> use high order allocations.

Correction, that would need SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN),
because drivers/net/usb/usbnet.c calls __netdev_alloc_skb_ip_align().



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: skbuff truesize incorrect.

2014-05-22 Thread David Miller
From: Eric Dumazet 
Date: Thu, 22 May 2014 14:03:21 -0700

> On Thu, 2014-05-22 at 13:58 -0700, Eric Dumazet wrote:
> 
>> I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not
>> use high order allocations.
> 
> Correction, that would need SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN),
> because drivers/net/usb/usbnet.c calls __netdev_alloc_skb_ip_align().

I seem to recall that this driver has a lot of strange buffering
restrictions and that Bjorn Mork was talking a lot about this
recently.

Bjorn people are getting really burnt because the driver ends up
having a skb->truesize of 32K for the buffers it allocates on receive
and this chokes up TCP and SCTP because the socket memory limits
are hitting earlier than they should.

We've just in the past few postings been discussing whether the just
copy every packet into a more appropriately sized buffer, and it isn't
clear if that's a good idea of the data rates handled here.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/7] dma: cppi41: handle 0-length packets

2014-05-22 Thread Daniel Mack
Hi,

I messed up the register names in the commit log. Will fix in v2.

On 05/22/2014 05:30 PM, Daniel Mack wrote:
> When a 0-length packet is received on the bus, desc->pd6 contains 1, and

... 'desc->pd0' ...

> the current residue calculation reports back that 1 byte has been
> transferred. This is not according to what the datasheet says, but it's
> been the case on an AM335x board, very reproducible.
> 
> Fix this by looking at bit 19 in PD2 of the completed packet. This bit
> will tell us if a zero-length packet was received on a queue. If it's
> set, ignore pd2 and report a total length of 0.

... 'ignore pd0' ...

> 
> Signed-off-by: Daniel Mack 
> ---
>  drivers/dma/cppi41.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
> index d028f36..8f8b0b6 100644
> --- a/drivers/dma/cppi41.c
> +++ b/drivers/dma/cppi41.c
> @@ -86,6 +86,9 @@
>  
>  #define USBSS_IRQ_PD_COMP(1 <<  2)
>  
> +/* Packet Descriptor */
> +#define PD2_ZERO_LENGTH  (1 << 19)
> +
>  struct cppi41_channel {
>   struct dma_chan chan;
>   struct dma_async_tx_descriptor txd;
> @@ -307,7 +310,7 @@ static irqreturn_t cppi41_irq(int irq, void *data)
>   __iormb();
>  
>   while (val) {
> - u32 desc;
> + u32 desc, len;
>  
>   q_num = __fls(val);
>   val &= ~(1 << q_num);
> @@ -319,9 +322,13 @@ static irqreturn_t cppi41_irq(int irq, void *data)
>   q_num, desc);
>   continue;
>   }
> - c->residue = pd_trans_len(c->desc->pd6) -
> - pd_trans_len(c->desc->pd0);
>  
> + if (c->desc->pd2 & PD2_ZERO_LENGTH)
> + len = 0;
> + else
> + len = pd_trans_len(c->desc->pd0);
> +
> + c->residue = pd_trans_len(c->desc->pd6) - len;
>   dma_cookie_complete(&c->txd);
>   c->txd.callback(c->txd.callback_param);
>   }
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] Staging: Media: sn9c102: Fixed a pointer declaration coding style issue

2014-05-22 Thread Chaitanya
Fixed the ERROR thrown off by checkpatch.pl.

Signed-off-by: Chaitanya Hazarey 
---
 drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
b/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
index a30bbc4..725de85 100644
--- a/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
+++ b/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
@@ -23,7 +23,7 @@
 #include "sn9c102_devtable.h"


-static int tas5130d1b_init(struct sn9c102_device* cam)
+static int tas5130d1b_init(struct sn9c102_device *cam)
 {
  int err;

@@ -36,8 +36,8 @@ static int tas5130d1b_init(struct sn9c102_device* cam)
 }


-static int tas5130d1b_set_ctrl(struct sn9c102_device* cam,
-   const struct v4l2_control* ctrl)
+static int tas5130d1b_set_ctrl(struct sn9c102_device *cam,
+   const struct v4l2_control *ctrl)
 {
  int err = 0;

@@ -56,10 +56,10 @@ static int tas5130d1b_set_ctrl(struct sn9c102_device* cam,
 }


-static int tas5130d1b_set_crop(struct sn9c102_device* cam,
-   const struct v4l2_rect* rect)
+static int tas5130d1b_set_crop(struct sn9c102_device *cam,
+   const struct v4l2_rect *rect)
 {
- struct sn9c102_sensor* s = sn9c102_get_sensor(cam);
+ struct sn9c102_sensor *s = sn9c102_get_sensor(cam);
  u8 h_start = (u8)(rect->left - s->cropcap.bounds.left) + 104,
v_start = (u8)(rect->top - s->cropcap.bounds.top) + 12;
  int err = 0;
@@ -76,8 +76,8 @@ static int tas5130d1b_set_crop(struct sn9c102_device* cam,
 }


-static int tas5130d1b_set_pix_format(struct sn9c102_device* cam,
- const struct v4l2_pix_format* pix)
+static int tas5130d1b_set_pix_format(struct sn9c102_device *cam,
+ const struct v4l2_pix_format *pix)
 {
  int err = 0;

@@ -146,7 +146,7 @@ static const struct sn9c102_sensor tas5130d1b = {
 };


-int sn9c102_probe_tas5130d1b(struct sn9c102_device* cam)
+int sn9c102_probe_tas5130d1b(struct sn9c102_device *cam)
 {
  const struct usb_device_id tas5130d1b_id_table[] = {
  { USB_DEVICE(0x0c45, 0x6024), },
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v2 0/2] Re-organize usb common

2014-05-22 Thread Peter Chen
 
> 
> Hi Greg,
> 
> This patch set creates usb/common for usb common things, and moves otg
> fsm implementation from usb/phy/ to usb/common/. I have a discussion with
> Felipe about it at below link:
> http://www.spinics.net/lists/linux-usb/msg106357.html
> 
> Thanks.
> 
> Changes for v2:
> - Fix one typo Alan pointed.
> 
> Peter Chen (2):
>   usb: move usb/usb-common.c to usb/common/usb-common.c
>   usb: common: rename phy-fsm-usb.c to usb-otg-fsm.c
> 
>  drivers/usb/Makefile   |2 +-
>  drivers/usb/common/Makefile|6 ++
>  drivers/usb/{ => common}/usb-common.c  |0
>  .../{phy/phy-fsm-usb.c => common/usb-otg-fsm.c}|0
>  drivers/usb/core/Kconfig   |9 +
>  drivers/usb/phy/Kconfig|9 -
>  drivers/usb/phy/Makefile   |1 -
>  7 files changed, 16 insertions(+), 11 deletions(-)  create mode 100644
> drivers/usb/common/Makefile  rename drivers/usb/{ => common}/usb-common.c
> (100%)  rename drivers/usb/{phy/phy-fsm-usb.c => common/usb-otg-fsm.c}
> (100%)
> 

Hi Greg, does this patch set will in your 3.16 tree? There are coming
works are related to it, thanks.

Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/3] Chipidea patches for 3.16 merge window

2014-05-22 Thread Peter Chen
Hi Greg,

No big changes for these three patches, just cleanup, refine, update
TODO list.

Besides, I haven't seen my last 3.16 patch set in your next tree, do
I need to re-send them (together with this one)?

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

Thanks.

Peter Chen (3):
  usb: chipidea: update TODO list
  usb: chipidea: udc: delete useless code
  usb: chipidea: using one inline function to cover queue work
operations

 drivers/usb/chipidea/core.c|   11 ++-
 drivers/usb/chipidea/otg.h |5 +++
 drivers/usb/chipidea/otg_fsm.c |   69 +--
 drivers/usb/chipidea/udc.c |1 -
 4 files changed, 31 insertions(+), 55 deletions(-)

-- 
1.7.8

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/3] usb: chipidea: update TODO list

2014-05-22 Thread Peter Chen
Update TODO list

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/core.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 128b92b..95b4dd7 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -23,7 +23,7 @@
  * - BUS:bus glue code, bus abstraction layer
  *
  * Compile Options
- * - CONFIG_USB_GADGET_DEBUG_FILES: enable debug facilities
+ * - CONFIG_USB_CHIPIDEA_DEBUG: enable debug facilities
  * - STALL_IN:  non-empty bulk-in pipes cannot be halted
  *  if defined mass storage compliance succeeds but with warnings
  *  => case 4: Hi >  Dn
@@ -42,9 +42,6 @@
  * - Not Supported: 15 & 16 (ISO)
  *
  * TODO List
- * - Interrupt Traffic
- * - GET_STATUS(device) - always reports 0
- * - Gadget API (majority of optional features)
  * - Suspend & Remote Wakeup
  */
 #include 
-- 
1.7.8

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/3] usb: chipidea: udc: delete useless code

2014-05-22 Thread Peter Chen
Delete useless code

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/udc.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index d683968..69425b3 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -825,7 +825,6 @@ __acquires(hwep->lock)
if ((setup->bRequestType & USB_RECIP_MASK) == USB_RECIP_DEVICE) {
/* Assume that device is bus powered for now. */
*(u16 *)req->buf = ci->remote_wakeup << 1;
-   retval = 0;
} else if ((setup->bRequestType & USB_RECIP_MASK) \
   == USB_RECIP_ENDPOINT) {
dir = (le16_to_cpu(setup->wIndex) & USB_ENDPOINT_DIR_MASK) ?
-- 
1.7.8

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/3] usb: chipidea: using one inline function to cover queue work operations

2014-05-22 Thread Peter Chen
The otg queue work include operations: one is disable interrupt,
another one is call kernel queue work API. Many codes do this
operation, using one inline function to instead of them.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/core.c|6 +--
 drivers/usb/chipidea/otg.h |5 +++
 drivers/usb/chipidea/otg_fsm.c |   69 +--
 3 files changed, 30 insertions(+), 50 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 95b4dd7..619d13e 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -425,8 +425,7 @@ static irqreturn_t ci_irq(int irq, void *data)
ci->id_event = true;
/* Clear ID change irq status */
hw_write_otgsc(ci, OTGSC_IDIS, OTGSC_IDIS);
-   disable_irq_nosync(ci->irq);
-   queue_work(ci->wq, &ci->work);
+   ci_otg_queue_work(ci);
return IRQ_HANDLED;
}
 
@@ -438,8 +437,7 @@ static irqreturn_t ci_irq(int irq, void *data)
ci->b_sess_valid_event = true;
/* Clear BSV irq */
hw_write_otgsc(ci, OTGSC_BSVIS, OTGSC_BSVIS);
-   disable_irq_nosync(ci->irq);
-   queue_work(ci->wq, &ci->work);
+   ci_otg_queue_work(ci);
return IRQ_HANDLED;
}
 
diff --git a/drivers/usb/chipidea/otg.h b/drivers/usb/chipidea/otg.h
index 7349267..9ecb598 100644
--- a/drivers/usb/chipidea/otg.h
+++ b/drivers/usb/chipidea/otg.h
@@ -17,5 +17,10 @@ int ci_hdrc_otg_init(struct ci_hdrc *ci);
 void ci_hdrc_otg_destroy(struct ci_hdrc *ci);
 enum ci_role ci_otg_role(struct ci_hdrc *ci);
 void ci_handle_vbus_change(struct ci_hdrc *ci);
+static inline void ci_otg_queue_work(struct ci_hdrc *ci)
+{
+   disable_irq_nosync(ci->irq);
+   queue_work(ci->wq, &ci->work);
+}
 
 #endif /* __DRIVERS_USB_CHIPIDEA_OTG_H */
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 8d4c33d..caaabc5 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -84,8 +84,7 @@ set_a_bus_req(struct device *dev, struct device_attribute 
*attr,
ci->fsm.a_bus_req = 1;
}
 
-   disable_irq_nosync(ci->irq);
-   queue_work(ci->wq, &ci->work);
+   ci_otg_queue_work(ci);
mutex_unlock(&ci->fsm.lock);
 
return count;
@@ -125,8 +124,7 @@ set_a_bus_drop(struct device *dev, struct device_attribute 
*attr,
ci->fsm.a_bus_req = 0;
}
 
-   disable_irq_nosync(ci->irq);
-   queue_work(ci->wq, &ci->work);
+   ci_otg_queue_work(ci);
mutex_unlock(&ci->fsm.lock);
 
return count;
@@ -165,8 +163,7 @@ set_b_bus_req(struct device *dev, struct device_attribute 
*attr,
else if (buf[0] == '1')
ci->fsm.b_bus_req = 1;
 
-   disable_irq_nosync(ci->irq);
-   queue_work(ci->wq, &ci->work);
+   ci_otg_queue_work(ci);
mutex_unlock(&ci->fsm.lock);
 
return count;
@@ -186,8 +183,7 @@ set_a_clr_err(struct device *dev, struct device_attribute 
*attr,
if (buf[0] == '1')
ci->fsm.a_clr_err = 1;
 
-   disable_irq_nosync(ci->irq);
-   queue_work(ci->wq, &ci->work);
+   ci_otg_queue_work(ci);
mutex_unlock(&ci->fsm.lock);
 
return count;
@@ -297,8 +293,7 @@ static void set_tmout_and_fsm(void *ptr, unsigned long 
indicator)
 
set_tmout(ci, indicator);
 
-   disable_irq_nosync(ci->irq);
-   queue_work(ci->wq, &ci->work);
+   ci_otg_queue_work(ci);
 }
 
 static void a_wait_vfall_tmout_func(void *ptr, unsigned long indicator)
@@ -312,8 +307,7 @@ static void a_wait_vfall_tmout_func(void *ptr, unsigned 
long indicator)
hw_write_otgsc(ci, OTGSC_DPIS, OTGSC_DPIS);
/* Enable data pulse irq */
hw_write_otgsc(ci, OTGSC_DPIE, OTGSC_DPIE);
-   disable_irq_nosync(ci->irq);
-   queue_work(ci->wq, &ci->work);
+   ci_otg_queue_work(ci);
 }
 
 static void b_ase0_brst_tmout_func(void *ptr, unsigned long indicator)
@@ -324,8 +318,7 @@ static void b_ase0_brst_tmout_func(void *ptr, unsigned long 
indicator)
if (!hw_read_otgsc(ci, OTGSC_BSV))
ci->fsm.b_sess_vld = 0;
 
-   disable_irq_nosync(ci->irq);
-   queue_work(ci->wq, &ci->work);
+   ci_otg_queue_work(ci);
 }
 
 static void b_ssend_srp_tmout_func(void *ptr, unsigned long indicator)
@@ -335,10 +328,8 @@ static void b_ssend_srp_tmout_func(void *ptr, unsigned 
long indicator)
set_tmout(ci, indicator);
 
/* only vbus fall below B_sess_vld in b_idle state */
-   if (ci->transceiver->state == OTG_STATE_B_IDLE) {
-   disable_irq_nosync(ci->irq);
-   queue_work(ci->wq, &ci->work);
-   }
+   if (ci->transceiver->state == OTG_STATE_B_IDLE)
+   ci_otg_queue_work(ci);
 }
 
 static void b_sess_vld_tmout_func(void *ptr, unsigned long indicator)
@@ -349,8 

Re: [PATCH v2 0/2] Re-organize usb common

2014-05-22 Thread gre...@linuxfoundation.org
On Fri, May 23, 2014 at 01:16:37AM +, Peter Chen wrote:
>  
> > 
> > Hi Greg,
> > 
> > This patch set creates usb/common for usb common things, and moves otg
> > fsm implementation from usb/phy/ to usb/common/. I have a discussion with
> > Felipe about it at below link:
> > http://www.spinics.net/lists/linux-usb/msg106357.html
> > 
> > Thanks.
> > 
> > Changes for v2:
> > - Fix one typo Alan pointed.
> > 
> > Peter Chen (2):
> >   usb: move usb/usb-common.c to usb/common/usb-common.c
> >   usb: common: rename phy-fsm-usb.c to usb-otg-fsm.c
> > 
> >  drivers/usb/Makefile   |2 +-
> >  drivers/usb/common/Makefile|6 ++
> >  drivers/usb/{ => common}/usb-common.c  |0
> >  .../{phy/phy-fsm-usb.c => common/usb-otg-fsm.c}|0
> >  drivers/usb/core/Kconfig   |9 +
> >  drivers/usb/phy/Kconfig|9 -
> >  drivers/usb/phy/Makefile   |1 -
> >  7 files changed, 16 insertions(+), 11 deletions(-)  create mode 100644
> > drivers/usb/common/Makefile  rename drivers/usb/{ => common}/usb-common.c
> > (100%)  rename drivers/usb/{phy/phy-fsm-usb.c => common/usb-otg-fsm.c}
> > (100%)
> > 
> 
> Hi Greg, does this patch set will in your 3.16 tree? There are coming
> works are related to it, thanks.

It's behind in my patch review queue due to my travels.  I'll be back
next week and will get to this, sorry for the delay.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: some question about usb_interrupt_msg

2014-05-22 Thread vichy
hi Alan:

2014-05-22 22:14 GMT+08:00 Alan Stern :
> On Thu, 22 May 2014, vichy wrote:
>
>> hi all:
>> I see usb_interrupt_msg do nothing but call usb_bulk_msg.
>> Why we still keep usb_interrupt_msg?
>> for old api compatibility?
>
> That's right.  Also because it gives an indication to the reader about
> what type of transfer is being performed.
I got it.
appreciate your kind reply ^^
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] USB patches for v3.16 merge window

2014-05-22 Thread Greg KH
On Wed, May 21, 2014 at 05:28:31PM -0500, Felipe Balbi wrote:
> Hi Greg,
> 
> Here's my big dump for v3.16 merge window. Even though we have a lot of
> patches, most of them are just doing cleanups and small bug fixes.
> 
> Consider merging it to your usb-next branch. There will be a conflict
> with drivers/usb/phy/phy-mv-u3d.c (deleted in your tree, modified on
> mine). I'll let you decide what you really want to do, but I don't think
> that driver should be deleted, even commented on original thread.

I like the driver removed, if no one can use it or build it, no need to
keep it around.

Now merged and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] Chipidea patches for 3.16 merge window

2014-05-22 Thread Greg KH
On Fri, May 23, 2014 at 08:12:46AM +0800, Peter Chen wrote:
> Hi Greg,
> 
> No big changes for these three patches, just cleanup, refine, update
> TODO list.
> 
> Besides, I haven't seen my last 3.16 patch set in your next tree, do
> I need to re-send them (together with this one)?
> 
> http://marc.info/?l=linux-usb&m=139917105404965&w=2

Sorry, been on the road, now both applied.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 0/3] Chipidea patches for 3.16 merge window

2014-05-22 Thread Peter Chen
 
> >
> > No big changes for these three patches, just cleanup, refine, update
> > TODO list.
> >
> > Besides, I haven't seen my last 3.16 patch set in your next tree, do I
> > need to re-send them (together with this one)?
> >
> > http://marc.info/?l=linux-usb&m=139917105404965&w=2
> 
> Sorry, been on the road, now both applied.
> 

Get it, thanks.

Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


debug info for scheduling

2014-05-22 Thread vichy
hi all:
I have some questions:
1. is it possible to know period bandwidth for ehci controller from
sys or other additional configuration?
2. is it possible to know S/C bit in QHs which are linked in a frame?
thanks for your help in advance,
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] USB: Add LVS Test device driver

2014-05-22 Thread Pratyush Anand
Hi Alan,

On Fri, May 23, 2014 at 01:54:01AM +0800, Alan Stern wrote:
> On Thu, 22 May 2014, Pratyush Anand wrote:
> 
> > OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
> > system (SS-OVS) which consists of an excersizer and analyzer.
> > 
> > USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
> > Link Layer Validation (LVS).
> > 
> > Some modifications are needed for an embedded Linux USB host to pass all
> > these tests.  Most of these tests require just Link to be in U0. They do
> > not work with default Linux USB stack since, default stack does port
> > reset and then starts sending setup packet, which is not expected by
> > Link Layer Validation (LVS) device of Lecroy Compliance Suit.  Then,
> > There are many Link Layer Tests which need host to generate specific
> > traffic.
> > 
> > This patch supports specific traffic generation cases. As of now all the
> > host Lecroy Link Layer-USBIF tests (except TD7.26) passes
> > with this patch for single run using  Lecroy USB Compliance Suite
> > Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
> > Build 1603. Therefore patch seems to be a good candidate for inclusion.
> > Further modification can be done on top of it.
> > 
> > lvstest driver will not bind to any device by default. It can bind
> > manually to a super speed USB host controller root hub. Therefore, regular
> > hub driver must be unbound before this driver is bound. For example, if
> > 2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.
> > 
> >  echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind
> > 
> > Then to bind lvs driver write Linux Foundation's vendor ID and SS root
> > hub's device ID into new_id file.
> > 
> >  echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id
> > 
> > Now connect LVS device with root hub port.
> 
> You forgot to include an example here showing how to do this:
> 
>   echo 2-0\:1.0 > /sys/bus/usb/drivers/lvs/bind
> 

We do not need to write into bind file. Writing a valid VID and PID
of SS root hub into new_id file does the binding also.

> > Test case specific traffic can be generated as follows whenever needed:
> > 
> > 1. To issue "Get Device descriptor" command for TD.7.06:
> >  echo 1 > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc
> > 
> > 2. To set U1 timeout to 127 for TD.7.18
> >  echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout
> > 
> > 3. To set U2 timeout to 0 for TD.7.18
> >  echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout
> > 
> > 4. To issue "Hot Reset" for TD.7.29
> >  echo 1 > /sys/bus/usb/devices/2-0\:1.0/hot_reset
> > 
> > 5. To issue "U3 Entry" for TD.7.35
> >  echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_entry
> > 
> > 6. To issue "U3 Exit" for TD.7.36
> >  echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_exit
> 
> None of those example need to contain the "1".  For instance, the last 
> one should be written:
> 
>   echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit

Yes, any write will do except for ux_timeout.

> 
> > diff --git a/Documentation/ABI/testing/sysfs-bus-usb-lvstest 
> > b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
> > new file mode 100644
> > index 000..f47e8a3
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
> > @@ -0,0 +1,47 @@
> > +Link Layer Validation Device is a standard device for testing of Super
> > +Speed Link Layer tests. These nodes are available in sysfs only when lvs
> > +driver is bound with root hub device.
> > +
> > +What:  /sys/bus/usb/devices/.../get_dev_desc
> > +Date:  March 2014
> > +Contact:   Pratyush Anand 
> > +Description:
> > +   Write to this node to issue "Get Device Descriptor"
> > +   for Link Layer Validation device. It is needed for TD.7.06.
> > +
> > +What:  /sys/bus/usb/devices/.../u1_timeout
> > +Date:  March 2014
> > +Contact:   Pratyush Anand 
> > +Description:
> > +   Set "U1 timeout" for the downstream port where Link Layer
> > +   Validation device is connected. It is needed for TD.7.18,
> > +   TD.7.19, TD.7.20 and TD.7.21.
> 
> This doesn't say that the value must be between 0 and 127.

OK, that I will specify.

> 
> > +
> > +What:  /sys/bus/usb/devices/.../u2_timeout
> > +Date:  March 2014
> > +Contact:   Pratyush Anand 
> > +Description:
> > +   Set "U2 timeout" for the downstream port where Link Layer
> > +   Validation device is connected. It is needed for TD.7.18,
> > +   TD.7.19, TD.7.20 and TD.7.21.
> 
> Same here.

OK.

> 
> > +static void lvs_rh_work(struct work_struct *work)
> > +{
> > +   struct lvs_rh *lvs = container_of(work, struct lvs_rh, rh_work);
> > +   struct usb_interface *intf = lvs->intf;
> > +   struct usb_device *hdev = interface_to_usbdev(intf);
> > +   struct usb_hcd *hcd = bus_to_hcd(hdev->bus);
> > +   struct usb_hub_descriptor *descriptor = &lvs->descriptor;
> > +   struct usb_port_status port_status;
> > +   int i, ret = 0

[Patch V3 0/2] usb: gadget: zero: Add support for interrupt EP

2014-05-22 Thread Amit Virdi
This patchset adds support for interrupt EP and the corresponding test cases to
gadget zero. The code has been rebased and tested on Kernel v3.15-rc5

V2 -> V3
 - Rectified wMaxPacketSize for FS from 1023 to 64
 - Modified default value of interrupt interval for FS to 1 ms

V1 -> V2
 - Modified the alternate interface from having 6 EPs (2 - Interrupt, 2 Bulk, 2
   Isoc) to 2 EPs (Interrupt only)

RFC -> V1
 - Added support for configuring interrupt EP attributes from configfs interface

Amit Virdi (2):
  usb: gadget: zero: Add support for interrupt EP
  usbtest: Add interrupt EP testcases

 drivers/usb/gadget/f_loopback.c   |   3 +-
 drivers/usb/gadget/f_sourcesink.c | 511 --
 drivers/usb/gadget/g_zero.h   |  13 +-
 drivers/usb/gadget/zero.c |  21 ++
 drivers/usb/misc/usbtest.c| 113 +++--
 5 files changed, 624 insertions(+), 37 deletions(-)

-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Patch V3 1/2] usb: gadget: zero: Add support for interrupt EP

2014-05-22 Thread Amit Virdi
Interrupt endpoints behave quite similar to the bulk endpoints with the
difference that the endpoints expect data sending/reception request at
particular intervals till the whole data has not been transmitted.

The interrupt EP support is added to gadget zero. A new alternate setting (=2)
has been added. It has 2 interrupt endpoints. The default parameters are set as:
bInterval: 1 ms for FS and 8 uFrames (implying 1 ms) for HS/SS
wMaxPacketSize: 64 bytes for FS and 1024 bytes for HS/SS
However, the same can be overridden through the module parameter interface.

The code is tested for HS and SS on a platform having DWC3 controller.

Signed-off-by: Amit Virdi 
---
 drivers/usb/gadget/f_loopback.c   |   3 +-
 drivers/usb/gadget/f_sourcesink.c | 511 --
 drivers/usb/gadget/g_zero.h   |  13 +-
 drivers/usb/gadget/zero.c |  21 ++
 4 files changed, 526 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/gadget/f_loopback.c b/drivers/usb/gadget/f_loopback.c
index 4557cd0..bf04389 100644
--- a/drivers/usb/gadget/f_loopback.c
+++ b/drivers/usb/gadget/f_loopback.c
@@ -298,7 +298,8 @@ static void disable_loopback(struct f_loopback *loop)
struct usb_composite_dev*cdev;
 
cdev = loop->function.config->cdev;
-   disable_endpoints(cdev, loop->in_ep, loop->out_ep, NULL, NULL);
+   disable_endpoints(cdev, loop->in_ep, loop->out_ep, NULL, NULL, NULL,
+   NULL);
VDBG(cdev, "%s disabled\n", loop->function.name);
 }
 
diff --git a/drivers/usb/gadget/f_sourcesink.c 
b/drivers/usb/gadget/f_sourcesink.c
index d3cd52d..7c091a3 100644
--- a/drivers/usb/gadget/f_sourcesink.c
+++ b/drivers/usb/gadget/f_sourcesink.c
@@ -23,6 +23,15 @@
 #include "gadget_chips.h"
 #include "u_f.h"
 
+#define USB_MS_TO_SS_INTERVAL(x) USB_MS_TO_HS_INTERVAL(x)
+
+enum eptype {
+   EP_CONTROL = 0,
+   EP_BULK,
+   EP_ISOC,
+   EP_INTERRUPT,
+};
+
 /*
  * SOURCE/SINK FUNCTION ... a primary testing vehicle for USB peripheral
  * controller drivers.
@@ -55,6 +64,8 @@ struct f_sourcesink {
struct usb_ep   *out_ep;
struct usb_ep   *iso_in_ep;
struct usb_ep   *iso_out_ep;
+   struct usb_ep   *int_in_ep;
+   struct usb_ep   *int_out_ep;
int cur_alt;
 };
 
@@ -68,6 +79,10 @@ static unsigned isoc_interval;
 static unsigned isoc_maxpacket;
 static unsigned isoc_mult;
 static unsigned isoc_maxburst;
+static unsigned int_interval; /* In ms */
+static unsigned int_maxpacket;
+static unsigned int_mult;
+static unsigned int_maxburst;
 static unsigned buflen;
 
 /*-*/
@@ -92,6 +107,16 @@ static struct usb_interface_descriptor 
source_sink_intf_alt1 = {
/* .iInterface  = DYNAMIC */
 };
 
+static struct usb_interface_descriptor source_sink_intf_alt2 = {
+   .bLength =  USB_DT_INTERFACE_SIZE,
+   .bDescriptorType =  USB_DT_INTERFACE,
+
+   .bAlternateSetting =2,
+   .bNumEndpoints =2,
+   .bInterfaceClass =  USB_CLASS_VENDOR_SPEC,
+   /* .iInterface  = DYNAMIC */
+};
+
 /* full speed support: */
 
 static struct usb_endpoint_descriptor fs_source_desc = {
@@ -130,6 +155,26 @@ static struct usb_endpoint_descriptor fs_iso_sink_desc = {
.bInterval =4,
 };
 
+static struct usb_endpoint_descriptor fs_int_source_desc = {
+   .bLength =  USB_DT_ENDPOINT_SIZE,
+   .bDescriptorType =  USB_DT_ENDPOINT,
+
+   .bEndpointAddress = USB_DIR_IN,
+   .bmAttributes = USB_ENDPOINT_XFER_INT,
+   .wMaxPacketSize =   cpu_to_le16(64),
+   .bInterval =GZERO_INT_INTERVAL,
+};
+
+static struct usb_endpoint_descriptor fs_int_sink_desc = {
+   .bLength =  USB_DT_ENDPOINT_SIZE,
+   .bDescriptorType =  USB_DT_ENDPOINT,
+
+   .bEndpointAddress = USB_DIR_OUT,
+   .bmAttributes = USB_ENDPOINT_XFER_INT,
+   .wMaxPacketSize =   cpu_to_le16(64),
+   .bInterval =GZERO_INT_INTERVAL,
+};
+
 static struct usb_descriptor_header *fs_source_sink_descs[] = {
(struct usb_descriptor_header *) &source_sink_intf_alt0,
(struct usb_descriptor_header *) &fs_sink_desc,
@@ -140,6 +185,10 @@ static struct usb_descriptor_header 
*fs_source_sink_descs[] = {
(struct usb_descriptor_header *) &fs_source_desc,
(struct usb_descriptor_header *) &fs_iso_sink_desc,
(struct usb_descriptor_header *) &fs_iso_source_desc,
+   (struct usb_descriptor_header *) &source_sink_intf_alt2,
+#define FS_ALT_IFC_2_OFFSET8
+   (struct usb_descriptor_header *) &fs_int_sink_desc,
+   (struct usb_descriptor_header *) &fs_int_source_desc,
NULL,
 };
 
@@ -179,6 +228,24 @@ static struct usb_endpoint_descriptor hs_iso_sink_desc = {
.bInterval =   

[Patch V3 2/2] usbtest: Add interrupt EP testcases

2014-05-22 Thread Amit Virdi
Two simple test cases for interrupt endpoints are added to the usbtest.c file.
These are simple non-queued interrupt IN and interrupt OUT transfers. Currently,
only gadget zero is capable of executing the interrupt EP test cases. However,
extending the same to other gadgets is extremely simple and can be done
on-demand.

This code has been tested only with gadget zero and care has been taken so as to
not break the existing functionality. However, if anyone can test with other
gadgets then that would be great!

Signed-off-by: Amit Virdi 
---
 drivers/usb/misc/usbtest.c | 113 +++--
 1 file changed, 98 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index f6568b5..5c6baaa 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -54,6 +54,7 @@ struct usbtest_info {
unsignedautoconf:1;
unsignedctrl_out:1;
unsignediso:1;  /* try iso in/out */
+   unsignedintr:1; /* try interrupt in/out */
int alt;
 };
 
@@ -70,7 +71,10 @@ struct usbtest_dev {
int out_pipe;
int in_iso_pipe;
int out_iso_pipe;
+   int in_int_pipe;
+   int out_int_pipe;
struct usb_endpoint_descriptor  *iso_in, *iso_out;
+   struct usb_endpoint_descriptor  *int_in, *int_out;
struct mutexlock;
 
 #define TBUF_SIZE  256
@@ -101,6 +105,7 @@ get_endpoints(struct usbtest_dev *dev, struct usb_interface 
*intf)
struct usb_host_interface   *alt;
struct usb_host_endpoint*in, *out;
struct usb_host_endpoint*iso_in, *iso_out;
+   struct usb_host_endpoint*int_in, *int_out;
struct usb_device   *udev;
 
for (tmp = 0; tmp < intf->num_altsetting; tmp++) {
@@ -108,6 +113,7 @@ get_endpoints(struct usbtest_dev *dev, struct usb_interface 
*intf)
 
in = out = NULL;
iso_in = iso_out = NULL;
+   int_in = int_out = NULL;
alt = intf->altsetting + tmp;
 
if (override_alt >= 0 &&
@@ -124,6 +130,9 @@ get_endpoints(struct usbtest_dev *dev, struct usb_interface 
*intf)
switch (usb_endpoint_type(&e->desc)) {
case USB_ENDPOINT_XFER_BULK:
break;
+   case USB_ENDPOINT_XFER_INT:
+   if (dev->info->intr)
+   goto try_intr;
case USB_ENDPOINT_XFER_ISOC:
if (dev->info->iso)
goto try_iso;
@@ -139,6 +148,15 @@ get_endpoints(struct usbtest_dev *dev, struct 
usb_interface *intf)
out = e;
}
continue;
+try_intr:
+   if (usb_endpoint_dir_in(&e->desc)) {
+   if (!int_in)
+   int_in = e;
+   } else {
+   if (!int_out)
+   int_out = e;
+   }
+   continue;
 try_iso:
if (usb_endpoint_dir_in(&e->desc)) {
if (!iso_in)
@@ -148,7 +166,7 @@ try_iso:
iso_out = e;
}
}
-   if ((in && out)  ||  iso_in || iso_out)
+   if ((in && out)  ||  iso_in || iso_out || int_in || int_out)
goto found;
}
return -EINVAL;
@@ -183,6 +201,20 @@ found:
iso_out->desc.bEndpointAddress
& USB_ENDPOINT_NUMBER_MASK);
}
+
+   if (int_in) {
+   dev->int_in = &int_in->desc;
+   dev->in_int_pipe = usb_rcvintpipe(udev,
+   int_in->desc.bEndpointAddress
+   & USB_ENDPOINT_NUMBER_MASK);
+   }
+
+   if (int_out) {
+   dev->int_out = &int_out->desc;
+   dev->out_int_pipe = usb_sndintpipe(udev,
+   int_out->desc.bEndpointAddress
+   & USB_ENDPOINT_NUMBER_MASK);
+   }
return 0;
 }
 
@@ -205,14 +237,22 @@ static struct urb *usbtest_alloc_urb(
int pipe,
unsigned long   bytes,
unsignedtransfer_flags,
-   unsignedoffset)
+   unsignedoffset,
+   u8  bInterval)
 {
struct urb  *urb;
 
urb = usb_alloc_urb(0, GFP_KER