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 <lee.jones@linaro.org>
Tested-by: Tom Rini <trini@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>