Commit 622859634a663c5e55d0e2a2cdbb55ac058d97b3 removed a bunch of
#ifdefs from the musb code, including this change:
@@ -1901,11 +1844,7 @@ static void musb_free(struct musb *musb)
dma_controller_destroy(c);
}
-#ifdef CONFIG_USB_MUSB_HDRC_HCD
- usb_put_hcd(musb_to_hcd(musb));
-#else
kfree(musb);
-#endif
}
/*
Since musb comes from struct usb_hcd's hcd_priv, which is allocated on
the end of that struct, kfree'ing it is not going to work. Replace
kfree(musb) with usb_put_hcd(musb_to_hcd(musb)), which appears to be
the right thing to do here.
Signed-off-by: Brian Downing <bdowning@xxxxxxxxx>
---
Note that this patch is not sufficient to make musb device removal
work, though it helps. The way that resources are passed between
the glue and core drivers does not seem to be okay; since they
both acquire the same resources, when they get inserted into
the resource tree what actually winds up happening is that the
musb core's resources become the parent of the glue driver's.
When platform_device_del'ing the musb core (which happens first) it
winds up orphaning the glue driver's resources. With kernel memory
debugging on, you can see the glue driver's resource releasing hit
upon a 0x6b6b6b6b pointer.
I have not figured out a way to fix this resource problem that
wouldn't be incredibly intrusive (modifying all glue drivers and all
devices that create musb devices), but I managed to locally kludge
around it for my purposes in the glue driver by explicitly releasing
pdev->resource[0] before platform_device_add'ing the musb core,
then re-inserting it after deleting the core. Nasty!
In case anyone's wondering, the reason I care about removing musb
devices is that my board, using an AM1705 (a da8xx-based chip),
appears to have a hardware problem wherein inserting some particular
USB devices will occasionally cause the DRVVBUS register from the
controller to go low, like it thinks it wants to be a device instead
of a host. (I have the PHY configured to force being a host; the
AM1705 is missing a bunch of USB pins, including the ID and DRVVBUS
pins, and I had to hack in some code driving a GPIO for DRVVBUS based
on the above register.) This situation appears to be unrecoverable
except by resetting the controller, and removing and re-adding the
device is a quick and reliable way of doing so.
I am pretty confident in the nasty-hardware nature of the above bug
because adding an six foot extension cable (not a hub!) makes one
of my fail-one-in-ten-times-or-so devices work a lot better!
drivers/usb/musb/musb_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 26f1bef..cac54f7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1862,7 +1862,7 @@ static void musb_free(struct musb *musb)
dma_controller_destroy(c);
}
- kfree(musb);
+ usb_put_hcd(musb_to_hcd(musb));
}
/*
--
1.7.11.4
--
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
