kernel/linux.git/drivers/usb/musb, branch v5.4.151

usb: musb: tusb6010: uninitialized data in tusb_fifo_write_unaligned()

2021-09-30T08:09:20+00:00

commit 517c7bf99bad3d6b9360558414aae634b7472d80 upstream. This is writing to the first 1 - 3 bytes of "val" and then writing all four bytes to musb_writel(). The last byte is always going to be garbage. Zero out the last bytes instead. Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support") Signed-off-by: Dan Carpenter Cc: stable Link: https://lore.kernel.org/r/20210916135737.GI25094@kili Signed-off-by: Greg Kroah-Hartman

usb: musb: musb_dsps: request_irq() after initializing musb

2021-09-22T10:26:35+00:00

[ Upstream commit 7c75bde329d7e2a93cf86a5c15c61f96f1446cdc ] If IRQ occurs between calling dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev(), then null pointer dereference occurs since glue->musb wasn't initialized yet. The patch puts initializing of neccesery data before registration of the interrupt handler. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Nadezda Lutovinova Link: https://lore.kernel.org/r/20210819163323.17714-1-lutovinova@ispras.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: musb: fix MUSB_QUIRK_B_DISCONNECT_99 handling

2021-06-16T09:59:41+00:00

commit b65ba0c362be665192381cc59e3ac3ef6f0dd1e1 upstream. In commit 92af4fc6ec33 ("usb: musb: Fix suspend with devices connected for a64"), the logic to support the MUSB_QUIRK_B_DISCONNECT_99 quirk was modified to only conditionally schedule the musb->irq_work delayed work. This commit badly breaks ECM Gadget on AM335X. Indeed, with this commit, one can observe massive packet loss: $ ping 192.168.0.100 ... 15 packets transmitted, 3 received, 80% packet loss, time 14316ms Reverting this commit brings back a properly functioning ECM Gadget. An analysis of the commit seems to indicate that a mistake was made: the previous code was not falling through into the MUSB_QUIRK_B_INVALID_VBUS_91, but now it is, unless the condition is taken. Changing the logic to be as it was before the problematic commit *and* only conditionally scheduling musb->irq_work resolves the regression: $ ping 192.168.0.100 ... 64 packets transmitted, 64 received, 0% packet loss, time 64475ms Fixes: 92af4fc6ec33 ("usb: musb: Fix suspend with devices connected for a64") Cc: stable@vger.kernel.org Tested-by: Alexandre Belloni Tested-by: Drew Fustini Acked-by: Tony Lindgren Signed-off-by: Thomas Petazzoni Link: https://lore.kernel.org/r/20210528140446.278076-1-thomas.petazzoni@bootlin.com Signed-off-by: Greg Kroah-Hartman

usb: musb: fix PM reference leak in musb_irq_work()

2021-05-11T12:04:07+00:00

[ Upstream commit 9535b99533904e9bc1607575aa8e9539a55435d7 ] pm_runtime_get_sync will increment pm usage counter even it failed. thus a pairing decrement is needed. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Bixuan Cui Link: https://lore.kernel.org/r/20210408091836.55227-1-cuibixuan@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: musb: Fix suspend with devices connected for a64

2021-04-07T12:47:43+00:00

commit 92af4fc6ec331228aca322ca37c8aea7b150a151 upstream. Pinephone running on Allwinner A64 fails to suspend with USB devices connected as reported by Bhushan Shah . Reverting commit 5fbf7a253470 ("usb: musb: fix idling for suspend after disconnect interrupt") fixes the issue. Let's add suspend checks also for suspend after disconnect interrupt quirk handling like we already do elsewhere. Fixes: 5fbf7a253470 ("usb: musb: fix idling for suspend after disconnect interrupt") Reported-by: Bhushan Shah Tested-by: Bhushan Shah Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210324071142.42264-1-tony@atomide.com Cc: stable Signed-off-by: Greg Kroah-Hartman

usb: musb: Fix runtime PM race in musb_queue_resume_work

2021-03-04T09:26:41+00:00

commit 0eaa1a3714db34a59ce121de5733c3909c529463 upstream. musb_queue_resume_work() would call the provided callback if the runtime PM status was 'active'. Otherwise, it would enqueue the request if the hardware was still suspended (musb->is_runtime_suspended is true). This causes a race with the runtime PM handlers, as it is possible to be in the case where the runtime PM status is not yet 'active', but the hardware has been awaken (PM resume function has been called). When hitting the race, the resume work was not enqueued, which probably triggered other bugs further down the stack. For instance, a telnet connection on Ingenic SoCs would result in a 50/50 chance of a segmentation fault somewhere in the musb code. Rework the code so that either we call the callback directly if (musb->is_runtime_suspended == 0), or enqueue the query otherwise. Fixes: ea2f35c01d5e ("usb: musb: Fix sleeping function called from invalid context for hdrc glue") Cc: stable@vger.kernel.org # v4.9+ Tested-by: Tony Lindgren Reviewed-by: Tony Lindgren Signed-off-by: Paul Cercueil Link: https://lore.kernel.org/r/20210123142502.16980-1-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman

usb: musb: Fix runtime PM imbalance on error

2020-06-10T18:24:56+00:00

commit e4befc121df03dc8ed2ac1031c98f9538e244bae upstream. When copy_from_user() returns an error code, there is a runtime PM usage counter imbalance. Fix this by moving copy_from_user() to the beginning of this function. Fixes: 7b6c1b4c0e1e ("usb: musb: fix runtime PM in debugfs") Signed-off-by: Dinghao Liu Cc: stable@vger.kernel.org Signed-off-by: Bin Liu Link: https://lore.kernel.org/r/20200525025049.3400-7-b-liu@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

usb: musb: start session in resume for host port

2020-06-10T18:24:56+00:00

commit 7f88a5ac393f39319f69b8b20cc8d5759878d1a1 upstream. Commit 17539f2f4f0b ("usb: musb: fix enumeration after resume") replaced musb_start() in musb_resume() to not override softconnect bit, but it doesn't restart the session for host port which was done in musb_start(). The session could be disabled in musb_suspend(), which leads the host port doesn't stay in host mode. So let's start the session specifically for host port in musb_resume(). Fixes: 17539f2f4f0b ("usb: musb: fix enumeration after resume") Cc: stable@vger.kernel.org Signed-off-by: Bin Liu Link: https://lore.kernel.org/r/20200525025049.3400-3-b-liu@ti.com Signed-off-by: Greg Kroah-Hartman

usb: musb: fix crash with highmen PIO and usbmon

2020-04-01T09:02:15+00:00

commit 52974d94a206ce428d9d9b6eaa208238024be82a upstream. When handling a PIO bulk transfer with highmem buffer, a temporary mapping is assigned to urb->transfer_buffer. After the transfer is complete, an invalid address is left behind in this pointer. This is not ordinarily a problem since nothing touches that buffer before the urb is released. However, when usbmon is active, usbmon_urb_complete() calls (indirectly) mon_bin_get_data() which does access the transfer buffer if it is set. To prevent an invalid memory access here, reset urb->transfer_buffer to NULL when finished (musb_host_rx()), or do not set it at all (musb_host_tx()). Fixes: 8e8a55165469 ("usb: musb: host: Handle highmem in PIO mode") Signed-off-by: Mans Rullgard Cc: stable@vger.kernel.org Signed-off-by: Bin Liu Link: https://lore.kernel.org/r/20200316211136.2274-8-b-liu@ti.com Signed-off-by: Greg Kroah-Hartman

usb: musb: omap2430: Get rid of musb .set_vbus for omap2430 glue

2020-02-24T07:36:49+00:00

[ Upstream commit 91b6dec32e5c25fbdbb564d1e5af23764ec17ef1 ] We currently have musb_set_vbus() called from two different paths. Mostly it gets called from the USB PHY via omap_musb_set_mailbox(), but in some cases it can get also called from musb_stage0_irq() rather via .set_vbus: (musb_set_host [musb_hdrc]) (omap2430_musb_set_vbus [omap2430]) (musb_stage0_irq [musb_hdrc]) (musb_interrupt [musb_hdrc]) (omap2430_musb_interrupt [omap2430]) This is racy and will not work with introducing generic helper functions for musb_set_host() and musb_set_peripheral(). We want to get rid of the busy loops in favor of usleep_range(). Let's just get rid of .set_vbus for omap2430 glue layer and let the PHY code handle VBUS with musb_set_vbus(). Note that in the follow-up patch we can completely remove omap2430_musb_set_vbus(), but let's do it in a separate patch as this change may actually turn out to be needed as a fix. Reported-by: Pavel Machek Acked-by: Pavel Machek Signed-off-by: Tony Lindgren Signed-off-by: Bin Liu Link: https://lore.kernel.org/r/20200115132547.364-5-b-liu@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin