kernel.git/drivers/usb/chipidea/udc.c, branch linux-3.9.y

usb: chipidea: udc: fix memory leak in _ep_nuke

2013-05-08T03:33:06Z

commit 7ca2cd291fd84ae499390f227a255ccba2780a81 upstream. In hardware_enqueue code adds one extra td with dma_pool_alloc if mReq->req.zero is true. When _ep_nuke will be called for that endpoint, dma_pool_free will not be called to free that memory again. That patch fixes this. Signed-off-by: Michael Grzeschik Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: fix memory access of shared memory on armv5 machines

2013-05-08T03:33:06Z

commit a9c174302b1590ef3ead485d804a303c5f89174b upstream. The udc uses an shared dma memory space between hard and software. This memory layout is described in ci13xxx_qh and ci13xxx_td which are marked with the attribute ((packed)). The compiler currently does not know about the alignment of the memory layout, and will create strb and ldrb operations. The Datasheet of the synopsys core describes, that some operations on the mapped memory need to be atomic double word operations. I.e. the next pointer addressing in the qhead, as otherwise the hardware will read wrong data and totally stuck. This is also possible while working with the current active td queue, and preparing the td->ptr.next in software while the hardware is still working with the current active td which is supposed to be changed: writeb(0xde, &td->ptr.next + 0x0); /* strb */ writeb(0xad, &td->ptr.next + 0x1); /* strb */ <----- hardware reads value of td->ptr.next and get stuck! writeb(0xbe, &td->ptr.next + 0x2); /* strb */ writeb(0xef, &td->ptr.next + 0x3); /* strb */ This appeares on armv5 machines where the hardware does not support unaligned 32bit operations. This patch adds the attribute ((aligned(4))) to the structures to tell the compiler to use 32bit operations. It also adds an wmb() for the prepared TD data before it gets enqueued into the qhead. Signed-off-by: Michael Grzeschik Reviewed-by: Felipe Balbi Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

usb: chipidea: register debugging sysfs on our device

2013-03-04T07:33:25Z

Don't register anything non-generic under the gadget's device as we don't really *own* it. Signed-off-by: Felipe Balbi

USB: chipidea: add vbus detect for udc

2012-09-12T18:20:38Z

Using vbus valid interrupt to detect vbus. Tested-by: Michael Grzeschik Tested-by: Marc Kleine-Budde Signed-off-by: Richard Zhao Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: don't stall endpoint if request list is empty in isr_tr_complete_low

2012-09-12T17:58:38Z

When attaching an imx28 or imx53 in USB gadget mode to a Windows host and starting a rndis connection we see this message every 4-10 seconds: g_ether gadget: high speed config #2: RNDIS Analysis shows that each time this message is printed, the rndis connection is re-establish due to a reset because of a stalled endpoint (ep 0, dir 1). The endpoint is stalled because the reqeust complete bit on that endpoint is set, but in isr_tr_complete_low() the endpoint request list (mEp->qh.queue) is empty. This patch removed this check, because the code doesn't take the following situation into account: The loop over all endpoints in isr_tr_complete_handler() will call ep_nuke() on both ep0/dir0 and ep/dir1 in the first loop. Pending reqeusts will be flushed and completed here. There seems to be a race condition, the request is nuked, but the request complete bit will be set, too. The subsequent check (in ep0/dir1's loop cycle) for endpoint request list (mEp->qh.queue) empty will fail. Both other mainline chipidea drivers (mv_udc_core.c and fsl_udc_core.c) don't have this check. Cc: stable Signed-off-by: Michael Grzeschik Signed-off-by: Marc Kleine-Budde Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

usb: chipidea: cleanup dma_pool if udc_start() fails

2012-09-12T17:58:38Z

If udc_start() fails the qh_pool dma-pool cannot be closed because it's still in use. This patch factors out the dma_pool_free() loop into destroy_eps() and calls it in the error path of udc_start(), too. Cc: stable Reviewed-by: Richard Zhao Signed-off-by: Marc Kleine-Budde Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: fix error path in udc_start()

2012-09-12T17:58:38Z

This patch fixes the error path of udc_start(). Now NULL is used to unset the peripheral with otg_set_peripheral(). Cc: stable Reviewed-by: Richard Zhao Signed-off-by: Marc Kleine-Budde Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: add pullup fuction, needed by the uvc gadget

2012-09-12T17:58:38Z

Add function to physicaly enable or disable of pullup connection on the USB-D+ line. The uvc gaget will fail, if this function is not implemented. Cc: stable Signed-off-by: Michael Grzeschik Acked-by: Felipe Balbi Signed-off-by: Marc Kleine-Budde Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: fix setup of endpoint maxpacket size

2012-09-12T17:58:37Z

This patch changes the setup of the endpoint maxpacket size. All non control endpoints are initialized with an undefined ((unsigned short)~0) maxpacket size. The maxpacket size of Endpoint 0 will be kept at CTRL_PAYLOAD_MAX. Some gadget drivers check for the maxpacket size before they enable the endpoint, which leads to a wrong state in these drivers. Cc: stable Signed-off-by: Michael Grzeschik Acked-by: Felipe Balbi Signed-off-by: Marc Kleine-Budde Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

usb: chipidea: permit driver bindings pass phy pointer

2012-07-09T16:59:23Z

Sometimes, the driver bindings may know what phy they use. For example, when using device tree, the usb controller may have a phandler pointing to usb phy. Signed-off-by: Richard Zhao Reviewed-by: Marek Vasut Acked-by: Felipe Balbi Tested-by: Subodh Nijsure Signed-off-by: Greg Kroah-Hartman