kernel.git/drivers/usb/musb, branch linux-4.1.y

usb: musb: host: fix potential NULL pointer dereference

2018-05-23T01:36:40Z

[ Upstream commit 2b63f1329df2cd814c1f8353fae4853ace6521d1 ] musb_start_urb() doesn't check the pass-in parameter if it is NULL. But in musb_bulk_nak_timeout() the parameter passed to musb_start_urb() is returned from first_qh(), which could be NULL. So wrap the musb_start_urb() call here with a if condition check to avoid the potential NULL pointer dereference. Fixes: f283862f3b5c ("usb: musb: NAK timeout scheme on bulk TX endpoint") Cc: stable@vger.kernel.org # v3.7+ Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: musb: gadget: misplaced out of bounds check

2018-05-23T01:36:32Z

[ Upstream commit af6f8529098aeb0e56a68671b450cf74e7a64fcd ] musb->endpoints[] has array size MUSB_C_NUM_EPS. We must check array bounds before accessing the array and not afterwards. Signed-off-by: Heinrich Schuchardt Signed-off-by: Bin Liu Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: musb/ux500: remove duplicate check for dma_is_compatible

2018-03-04T15:28:30Z

[ Upstream commit 62a6abdd427b5fc4d8aad5dac874904e96273e6d ] When dma_addr_t is 64-bit, we get a warning about an invalid cast in the call to ux500_dma_is_compatible() from ux500_dma_channel_program(): drivers/usb/musb/ux500_dma.c: In function 'ux500_dma_channel_program': drivers/usb/musb/ux500_dma.c:210:51: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] if (!ux500_dma_is_compatible(channel, packet_sz, (void *)dma_addr, len)) The problem is that ux500_dma_is_compatible() is called from the main musb driver on the virtual address, but here we pass in a DMA address, so the types are fundamentally different but it works because the function only checks the alignment of the buffer and that is the same. We could work around this by adding another cast, but I have checked that the buffer we get passed here is already checked before it gets mapped, so the second check seems completely unnecessary and removing it must be the cleanest solution. Signed-off-by: Arnd Bergmann Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin

usb: musb: da8xx: fix babble condition handling

2018-01-17T17:55:40Z

[ Upstream commit bd3486ded7a0c313a6575343e6c2b21d14476645 ] When babble condition happens, the musb controller might automatically turns off VBUS. On DA8xx platform, the controller generates drvvbus interrupt for turning off VBUS along with the babble interrupt. In this case, we should handle the babble interrupt first and recover from the babble condition. This change ignores the drvvbus interrupt if babble interrupt is also generated at the same time, so the babble recovery routine works properly. Cc: stable@vger.kernel.org # v3.16+ Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: musb: Check for host-mode using is_host_active() on reset interrupt

2017-11-06T04:54:35Z

[ Upstream commit 445ef61543da3db5b699f87fb0aa4f227165f6ed ] The sunxi musb has a bug where sometimes it will generate a babble error on device disconnect instead of a disconnect IRQ. When this happens the musb controller switches from host mode to device mode (it clears MUSB_DEVCTL_HM/MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and gets stuck in this state. The babble error is misdetected as a bus reset because MUSB_DEVCTL_HM was cleared. To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM) to detect babble error so that sunxi musb babble recovery can handle it by restoring the mode. This information is provided by the driver logic and does not rely on register contents. Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Jonathan Liu Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: musb: tusb6010_omap: Do not reset the other direction's packet size

2017-06-08T10:12:47Z

[ Upstream commit 6df2b42f7c040d57d9ecb67244e04e905ab87ac6 ] We have one register for each EP to set the maximum packet size for both TX and RX. If for example an RX programming would happen before the previous TX transfer finishes we would reset the TX packet side. To fix this issue, only modify the TX or RX part of the register. Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support") Signed-off-by: Peter Ujfalusi Tested-by: Tony Lindgren Signed-off-by: Bin Liu Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: musb: cppi41: don't check early-TX-interrupt for Isoch transfer

2017-05-17T19:07:01Z

[ Upstream commit 0090114d336a9604aa2d90bc83f20f7cd121b76c ] The CPPI 4.1 driver polls register to workaround the premature TX interrupt issue, but it causes audio playback underrun when triggered in Isoch transfers. Isoch doesn't do back-to-back transfers, the TX should be done by the time the next transfer is scheduled. So skip this polling workaround for Isoch transfer. Fixes: a655f481d83d6 ("usb: musb: musb_cppi41: handle pre-mature TX complete interrupt") Cc: #4.1+ Reported-by: Alexandre Bailon Acked-by: Sebastian Andrzej Siewior Tested-by: Alexandre Bailon Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: musb: dsps: implement clear_ep_rxintr() callback

2017-03-06T22:29:08Z

[ Upstream commit c48400baa02155a5ddad63e8554602e48782278c ] During dma teardown for dequque urb, if musb load is high, musb might generate bogus rx ep interrupt even when the rx fifo is flushed. In such case any of the follow log messages could happen. musb_host_rx 1853: BOGUS RX2 ready, csr 0000, count 0 musb_host_rx 1936: RX3 dma busy, csr 2020 As mentioned in the current inline comment, clearing ep interrupt in the teardown path avoids the bogus interrupt, so implement clear_ep_rxintr() callback. This bug seems to be existing since the initial driver for musb support, but I only validated the fix back to v4.1, so only cc stable for v4.1+. cc: stable@vger.kernel.org # 4.1+ Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: musb: core: add clear_ep_rxintr() to musb_platform_ops

2017-03-06T22:29:03Z

[ Upstream commit 6def85a396ce7796bd9f4561c6ae8138833f7a52 ] During dma teardown for dequque urb, if musb load is high, musb might generate bogus rx ep interrupt even when the rx fifo is flushed. In such case any of the follow log messages could happen. musb_host_rx 1853: BOGUS RX2 ready, csr 0000, count 0 musb_host_rx 1936: RX3 dma busy, csr 2020 As mentioned in the current inline comment, clearing ep interrupt in the teardown path avoids the bogus interrupt. Clearing ep interrupt is platform dependent, so this patch adds a platform callback to allow glue driver to clear the ep interrupt. This bug seems to be existing since the initial driver for musb support, but I only validated the fix back to v4.1, so only cc stable for v4.1+. cc: stable@vger.kernel.org # 4.1+ Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: musb: Stop bulk endpoint while queue is rotated

2016-07-11T00:19:53Z

[ Upstream commit 7b2c17f829545df27a910e8d82e133c21c9a8c9c ] Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was reprogrammed resulting in a warning about such data from musb_rx_reinit before it was thrown away. The data thrown away was a valid packet that had been correctly ACKed which meant the host and device got out of sync. Signed-off-by: Andrew Goodbody Cc: stable@vger.kernel.org Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin