Hi,
Le lun. 25 févr. 2019 à 15:05, Stephen Boyd <sboyd@xxxxxxxxxx> a
écrit :
Quoting Paul Cercueil (2019-02-22 19:17:25)
Hi,
Anything new on this? It still happens on 5.0-rc7.
It probes with late_initcall, and not with device_initcall.
I have no clue what's going on.
I'm not sure what's going on either. You'll probably have to debug
when
the device is created and when it is probed by enabling the debug
printing in the driver core or by adding in extra debug prints to
narrow
down the problem. For example, add a '#define DEBUG 1' at the top of
drivers/base/dd.c and see if that helps give some info on what's going
on with the drivers and devices.
The doc of __platform_driver_probe says:
"Use this instead of platform_driver_register() when you know the device
is not hotpluggable and has already been registered".
When the parent device and child device are both probed with
builtin_platform_driver_probe(), and the parent calls
devm_of_platform_populate(), it is not certain that the parent's
probe will happen before the child's, and if it does not, the child
device has not been registered and its probe is not allowed to defer.
So it turned out not to be a core bug, rather a misuse of the API.
So I will keep the builtin_platform_driver_probe() in the child, and
use a
subsys_initcall() in the parent. That works fine.
Regards,
-Paul
