On Tue, Oct 01, 2013 at 02:31:53PM +0200, Sebastian Andrzej Siewior wrote:
> This went unnoticed in durin the merge window:
> The dsps driver creates a child device for the musb core driver _and_
> attaches the of_node to it so devm_usb_get_phy_by_phandle() grabs the
> correct phy and attaches the devm resources to the proper device. We
> could also use the parent device but then devm would attach the
> resource to the wrong device and it would be destroyed once the parent
> device is gone - not the device that is used by the musb core driver.
> If the phy is now not available then dsps_musb_init() /
> devm_usb_get_phy_by_phandle() returns with EPROBE_DEFER. Since the
> of_node is attached it tries OF drivers as well and matches the driver
> against DSPS. That one creates a new child device for the musb core
> driver which gets probed immediately.
> The whole thing repeats itself until the stack overflows.
>
> I belive the same problem exists in ux500 glue code (since 313bdb11
> ("usb: musb: ux500: add device tree probing support") but the drivers are
> now probed in the right order so they don't see it.
>
> The problem is that the dsps driver gets bound to the musb-child device
> due to the same of_node / matching binding. I don't really agree with
> having yet another child node in DT to fix this. Ideally we would have
> musb core driver with DT bindings and according to the binding we would
> select the few extra hacks / gleue layer.
>
> Therefore I suggest the driver to reject the musb-core device.
>
> Cc: Lee Jones <[email protected]>
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Tested-by: Tom Rini <[email protected]>
--
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
