Currently, on gadget removal path, dummy_pullup() gets called after
gadget's disconnect(). Now, dummy_pullup() decides that it needs to
disconnect again, resulting in a crash. IOW, rmmod g_zero will crash
with dummy_hcd.
After aa0747394337e50533badd46e8fb7106bad3311e (usb: gadget: dummy_hcd:
convert to new-style udc-probe) this problem should be reproducible, so
from v3.1 on.
I can't pretend to fully comprehend the logic around set_link_state(),
but I'm fairly sure it shouldn't end up calling disconnect twice.
Signed-off-by: Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx>
---
drivers/usb/gadget/dummy_hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index a6dfd21..66fce0e 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -371,7 +371,7 @@ static void set_link_state(struct dummy_hcd *dum_hcd)
* We're connected and not reset (reset occurred now),
* and driver attached - disconnect!
*/
- if ((dum_hcd->old_status & USB_PORT_STAT_CONNECTION) != 0 &&
+ if ((dum_hcd->port_status & USB_PORT_STAT_CONNECTION) != 0 &&
(dum_hcd->old_status & USB_PORT_STAT_RESET) == 0 &&
dum->driver) {
stop_activity(dum);
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
