| Message ID | 1441628627-5143-22-git-send-email-tomeu.vizoso@collabora.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Sep 07, 2015 at 02:23:46PM +0200, Tomeu Vizoso wrote: > Some initcalls in the late level assume that some devices will have > already probed without explicitly checking for that. > > After the recent move to defer most device probes when they are > registered, pressure increased in the late initcall level. > > By starting the processing of the deferred queue in device_initcall_sync > we increase the chances that the initcalls mentioned before will find > the devices they depend on to have already probed. Which cases do we have that are outside the driver model and thus affected by this? USB gadgets are one case I'm aware of, and cpufreq is still problematic. I'm wondering if it might be tractable to address the actual problems with the remaining reliance on init ordering here. I'm also wondering if we might end up running into situations where this makes the problem with havinng to defer probes more of an issue on some systems - since we start trying earlier while we are still doing our first pass initialisation we could end up deferring some device then retrying it a bunch of times while going through the earlier phases of init as we continue to register more devices.
On 11 September 2015 at 14:24, Mark Brown <broonie@kernel.org> wrote: > On Mon, Sep 07, 2015 at 02:23:46PM +0200, Tomeu Vizoso wrote: >> Some initcalls in the late level assume that some devices will have >> already probed without explicitly checking for that. >> >> After the recent move to defer most device probes when they are >> registered, pressure increased in the late initcall level. >> >> By starting the processing of the deferred queue in device_initcall_sync >> we increase the chances that the initcalls mentioned before will find >> the devices they depend on to have already probed. > > Which cases do we have that are outside the driver model and thus > affected by this? USB gadgets are one case I'm aware of, and cpufreq is > still problematic. I'm wondering if it might be tractable to address > the actual problems with the remaining reliance on init ordering here. Actually, I don't know of any specific case that needs this commit. The present series without this patch passes on all the boards in kernelci, but Grygorii Strashko argued for it during the review of the earlier version of this series: http://lkml.kernel.org/g/55CE3D04.8000607@ti.com IMO it would be better to not apply this patch until the need arises, and even then, it may be better to make the dependencies explicit instead of relying on implicit ordering and messing with the link order. > I'm also wondering if we might end up running into situations where this > makes the problem with havinng to defer probes more of an issue on some > systems - since we start trying earlier while we are still doing our > first pass initialisation we could end up deferring some device then > retrying it a bunch of times while going through the earlier phases of > init as we continue to register more devices. With the rest of the series this shouldn't happen as all/most deferred probes should be avoided. Regards, Tomeu
diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 0654fb771a53..b6a22cff78cf 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -176,7 +176,7 @@ static void driver_deferred_probe_trigger(void) * * We don't want to get in the way when the bulk of drivers are getting probed. * Instead, this initcall makes sure that deferred probing is delayed until - * late_initcall time. + * device_initcall_sync time. */ static int deferred_probe_initcall(void) { @@ -190,7 +190,7 @@ static int deferred_probe_initcall(void) flush_workqueue(deferred_wq); return 0; } -late_initcall(deferred_probe_initcall); +device_initcall_sync(deferred_probe_initcall); static void driver_bound(struct device *dev) {
Some initcalls in the late level assume that some devices will have already probed without explicitly checking for that. After the recent move to defer most device probes when they are registered, pressure increased in the late initcall level. By starting the processing of the deferred queue in device_initcall_sync we increase the chances that the initcalls mentioned before will find the devices they depend on to have already probed. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> --- Changes in v4: - Start processing deferred probes in device_initcall_sync Changes in v3: None Changes in v2: None drivers/base/dd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)