Commit d173a137 authored by Luis R. Rodriguez's avatar Luis R. Rodriguez Committed by Greg Kroah-Hartman

driver-core: enable drivers to opt-out of async probe

There are drivers that can not be probed asynchronously. One such group
is platform drivers registered with platform_driver_probe(), which
expects driver's probe routine be discarded after the driver has been
registered and initial binding attempt executed. Also
platform_driver_probe() an error when no devices were bound to the
driver, allowing failing to load such driver module altogether.

Other drivers do not work well with asynchronous probing because of
driver bug or not optimal driver organization.

To allow using such drivers even when user requests asynchronous probing
as default boot strategy, let's allow them to opt out.
Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
parent f2411da7
...@@ -419,13 +419,19 @@ int driver_probe_device(struct device_driver *drv, struct device *dev) ...@@ -419,13 +419,19 @@ int driver_probe_device(struct device_driver *drv, struct device *dev)
bool driver_allows_async_probing(struct device_driver *drv) bool driver_allows_async_probing(struct device_driver *drv)
{ {
if (drv->probe_type == PROBE_PREFER_ASYNCHRONOUS) switch (drv->probe_type) {
case PROBE_PREFER_ASYNCHRONOUS:
return true; return true;
case PROBE_FORCE_SYNCHRONOUS:
return false;
default:
if (drv->owner && drv->owner->async_probe_requested) if (drv->owner && drv->owner->async_probe_requested)
return true; return true;
return false; return false;
}
} }
struct device_attach_data { struct device_attach_data {
......
...@@ -201,15 +201,15 @@ extern struct klist *bus_get_device_klist(struct bus_type *bus); ...@@ -201,15 +201,15 @@ extern struct klist *bus_get_device_klist(struct bus_type *bus);
* respective probe routines. This tells the core what to * respective probe routines. This tells the core what to
* expect and prefer. * expect and prefer.
* *
* @PROBE_DEFAULT_STRATEGY: Drivers expect their probe routines * @PROBE_DEFAULT_STRATEGY: Used by drivers that work equally well
* to run synchronously with driver and device registration * whether probed synchronously or asynchronously.
* (with the exception of -EPROBE_DEFER handling - re-probing
* always ends up being done asynchronously) unless user
* explicitly requested asynchronous probing via module
* parameter.
* @PROBE_PREFER_ASYNCHRONOUS: Drivers for "slow" devices which * @PROBE_PREFER_ASYNCHRONOUS: Drivers for "slow" devices which
* probing order is not essential for booting the system may * probing order is not essential for booting the system may
* opt into executing their probes asynchronously. * opt into executing their probes asynchronously.
* @PROBE_FORCE_SYNCHRONOUS: Use this to annotate drivers that need
* their probe routines to run synchronously with driver and
* device registration (with the exception of -EPROBE_DEFER
* handling - re-probing always ends up being done asynchronously).
* *
* Note that the end goal is to switch the kernel to use asynchronous * Note that the end goal is to switch the kernel to use asynchronous
* probing by default, so annotating drivers with * probing by default, so annotating drivers with
...@@ -220,6 +220,7 @@ extern struct klist *bus_get_device_klist(struct bus_type *bus); ...@@ -220,6 +220,7 @@ extern struct klist *bus_get_device_klist(struct bus_type *bus);
enum probe_type { enum probe_type {
PROBE_DEFAULT_STRATEGY, PROBE_DEFAULT_STRATEGY,
PROBE_PREFER_ASYNCHRONOUS, PROBE_PREFER_ASYNCHRONOUS,
PROBE_FORCE_SYNCHRONOUS,
}; };
/** /**
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment