drivercore: Fix ordering between deferred_probe and exiting initcalls
authorGrant Likely <grant.likely@secretlab.ca>
Thu, 14 Feb 2013 18:14:27 +0000 (18:14 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 15 Feb 2013 18:50:33 +0000 (10:50 -0800)
One of the side effects of deferred probe is that some drivers which
used to be probed before initcalls completed are now happening slightly
later. This causes two problems.
- If a console driver gets deferred, then it may not be ready when
  userspace starts. For example, if a uart depends on pinctrl, then the
  uart will get deferred and /dev/console will not be available
- __init sections will be discarded before built-in drivers are probed.
  Strictly speaking, __init functions should not be called in a drivers
  __probe path, but there are a lot of drivers (console stuff again)
  that do anyway. In the past it was perfectly safe to do so because all
  built-in drivers got probed before the end of initcalls.

This patch fixes the problem by forcing the first pass of the deferred
list to complete at late_initcall time. This is late enough to catch the
drivers that are known to have the above issues.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable <stable@vger.kernel.org> # 3.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/base/dd.c

index e3bbed8a617c257373a1fa2d75318d9ff930601a..61d3e1b4069487c700b18f210601f628917f1ec4 100644 (file)
@@ -172,6 +172,8 @@ static int deferred_probe_initcall(void)
 
        driver_deferred_probe_enable = true;
        driver_deferred_probe_trigger();
+       /* Sort as many dependencies as possible before exiting initcalls */
+       flush_workqueue(deferred_wq);
        return 0;
 }
 late_initcall(deferred_probe_initcall);