* [PATCH 0/1] usb: dwc2: Fix NULL qh in dwc2_queue_transaction
@ 2015-09-22 20:10 Alexandru M Stan
2015-09-22 20:10 ` [PATCH] " Alexandru M Stan
0 siblings, 1 reply; 2+ messages in thread
From: Alexandru M Stan @ 2015-09-22 20:10 UTC (permalink / raw)
To: John Youn, Paul Zimmerman
Cc: Heiko Stuebner, Douglas Anderson, Jonathan Dixon,
Mian Yousaf Kaukab, linux-usb, linux-kernel, linux-rockchip,
linux-arm-kernel, Alexandru M Stan, gregkh
I have a weird usb device which doesn't a normal connector, so there's
no guarantee that the pins will get removed in the correct order (data
pins first, then ground and vcc). I wouldn't be mad if there was a
weird error or something at connect/disconnect, but in this case I can
actually get a kernel panic.
Part of the panic text:
[ 143.654956] [<c044e818>] (dwc2_queue_transaction) from [<c044f3b4>] (dwc2_hcd_queue_transactions+0x24c/0x31c)
[ 143.664868] [<c044f3b4>] (dwc2_hcd_queue_transactions) from [<c044f4dc>] (_dwc2_hcd_clear_tt_buffer_complete+0x58/0x68)
[ 143.675648] [<c044f4dc>] (_dwc2_hcd_clear_tt_buffer_complete) from [<c04347ec>] (hub_tt_work+0x130/0x164)
[ 143.685214] [<c04347ec>] (hub_tt_work) from [<c013768c>] (process_one_work+0x258/0x3c0)
[ 143.693217] [<c013768c>] (process_one_work) from [<c0138848>] (worker_thread+0x234/0x38c)
[ 143.701394] [<c0138848>] (worker_thread) from [<c013e3dc>] (kthread+0xe4/0xfc)
[ 143.708618] [<c013e3dc>] (kthread) from [<c0106278>] (ret_from_fork+0x14/0x20)
I traced it down to a dereference of qh(chan->qh->ping_state) in
dwc2_queue_transaction.
At usb device disconnect, dwc2_hcd_cleanup_channels gets called,
which sets qh to NULL, but dwc2_queue_transaction still manages to
get called after that.
I can reproduce this in an isolated manner on my rk3288 board
with an FTDI/prolific device, having the usb pins easily
disconnectable(independently), then playing with the vcc pin while
leaving the data lines connected.
While my patch is probably not a proper fix for this issue, it's pretty
harmless where it is (and it's consistent with other checks in there).
I also hope this opens up discussions on this issue.
Alexandru M Stan (1):
usb: dwc2: Fix NULL qh in dwc2_queue_transaction
drivers/usb/dwc2/hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.6.0.rc0.131.gf624c3d
^ permalink raw reply [flat|nested] 2+ messages in thread
* [PATCH] usb: dwc2: Fix NULL qh in dwc2_queue_transaction
2015-09-22 20:10 [PATCH 0/1] usb: dwc2: Fix NULL qh in dwc2_queue_transaction Alexandru M Stan
@ 2015-09-22 20:10 ` Alexandru M Stan
0 siblings, 0 replies; 2+ messages in thread
From: Alexandru M Stan @ 2015-09-22 20:10 UTC (permalink / raw)
To: John Youn, Paul Zimmerman
Cc: Heiko Stuebner, Douglas Anderson, Jonathan Dixon,
Mian Yousaf Kaukab, linux-usb, linux-kernel, linux-rockchip,
linux-arm-kernel, Alexandru M Stan, gregkh
When a usb device disconnects in a certain way, dwc2_queue_transaction
still gets called after dwc2_hcd_cleanup_channels.
dwc2_hcd_cleanup_channels does "channel->qh = NULL;" but
dwc2_queue_transaction still wants to dereference qh.
This adds a check for a null qh.
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
---
drivers/usb/dwc2/hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index f845c41..d745128 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1004,7 +1004,7 @@ static int dwc2_queue_transaction(struct dwc2_hsotg *hsotg,
{
int retval = 0;
- if (hsotg->core_params->dma_enable > 0) {
+ if (hsotg->core_params->dma_enable > 0 && chan->qh) {
if (hsotg->core_params->dma_desc_enable > 0) {
if (!chan->xfer_started ||
chan->ep_type == USB_ENDPOINT_XFER_ISOC) {
--
2.6.0.rc0.131.gf624c3d
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-09-22 20:11 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-22 20:10 [PATCH 0/1] usb: dwc2: Fix NULL qh in dwc2_queue_transaction Alexandru M Stan
2015-09-22 20:10 ` [PATCH] " Alexandru M Stan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®