[PATCH] ARM: OMAP2+: omap-device: remove omap_device_late_init call completely

[Tony Lindgren]

* Grygorii Strashko <grygorii.strashko at ti.com> [150826 11:01]:
> Now Kernel fails to boot 50% of times (form build to build) with
> RT-patchset applied due to the following race - on late boot
> stages deferred_probe_work_func races with omap_device_late_ini
> 
> late_initcall
>  - deferred_probe_initcal() tries to re-probe all pending driver's probe.
>    [In general, It's NOT expected to probe any other built-in drivers after
>    deferred_probe_initcal() is finished, because most of
>    late_initcall_sync/late_initcall functions expected that all driver
>    or probed or deferred already.]
> 
> - later on, some driver is probing in this case It's could cpsw.c
>   (but could be any other drivers)
>   cpsw_init
>   - platform_driver_register
>     - really_probe
>        - driver_bound
>          - driver_deferred_probe_trigger
>   and boot proceed.
>   So, at this moment we have  deferred_probe_work_func scheduled.
> 
> late_initcall_sync
>   - omap_device_late_init
>     - omap_device_idle
> 
> CPU1					CPU2
>   - deferred_probe_work_func
>     - really_probe
>       - omap_hsmmc_probe
> 	- pm_runtime_get_sync
> 					late_initcall_sync
> 					- omap_device_late_init
> 						if (od->_driver_status != BUS_NOTIFY_BOUND_DRIVER) {
> 							if (od->_state == OMAP_DEVICE_STATE_ENABLED) {
> 								- omap_device_idle [ops - IP is disabled, ]
> 	- [fail]
> 	- pm_runtime_put_sync
>           - omap_hsmmc_runtime_suspend [ooops!]

OK idling of unclaimed devices should not happen for deferred probe,
it should only happen when there's no driver and no probing happening. 
 
> Lets remove just remove omap_device_late_init completely as suggested
> by Tero Kristo:
> 
> "How about remove omap_device_late_init call completely. I don't think
> it does anything useful at the moment; none of the omap devices get
> enabled outside runtime_pm, so there should be no need to explicitly
> disable the devices."

I think this is still needed from PM point of view as otherwise we
don't idle any devices that don't have a driver available. Or am I
missing something?

To me it seems the bug is relying on the BUS_NOTIFY_BOUND_DRIVER is
not set in the deferred probe case.

Regards,

Tony