summaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
Diffstat (limited to 'drivers')
-rw-r--r--drivers/base/core.c15
-rw-r--r--drivers/base/dd.c20
2 files changed, 35 insertions, 0 deletions
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 09b98f02f559..984d6bfbd6e4 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3688,6 +3688,21 @@ int device_add(struct device *dev)
fw_devlink_link_device(dev);
}
+ /*
+ * The moment the device was linked into the bus's "klist_devices" in
+ * bus_add_device() then it's possible that probe could have been
+ * attempted in a different thread via userspace loading a driver
+ * matching the device. "ready_to_probe" being unset would have
+ * blocked those attempts. Now that all of the above initialization has
+ * happened, unblock probe. If probe happens through another thread
+ * after this point but before bus_probe_device() runs then it's fine.
+ * bus_probe_device() -> device_initial_probe() -> __device_attach()
+ * will notice (under device_lock) that the device is already bound.
+ */
+ device_lock(dev);
+ dev_set_ready_to_probe(dev);
+ device_unlock(dev);
+
bus_probe_device(dev);
/*
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 37c7e54e0e4c..ec7ef9c5d62e 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -848,6 +848,26 @@ static int __driver_probe_device(const struct device_driver *drv, struct device
if (dev->driver)
return -EBUSY;
+ /*
+ * In device_add(), the "struct device" gets linked into the subsystem's
+ * list of devices and broadcast to userspace (via uevent) before we're
+ * quite ready to probe. Those open pathways to driver probe before
+ * we've finished enough of device_add() to reliably support probe.
+ * Detect this and tell other pathways to try again later. device_add()
+ * itself will also try to probe immediately after setting
+ * "ready_to_probe".
+ */
+ if (!dev_ready_to_probe(dev))
+ return dev_err_probe(dev, -EPROBE_DEFER, "Device not ready to probe\n");
+
+ /*
+ * Set can_match = true after calling dev_ready_to_probe(), so
+ * driver_deferred_probe_add() won't actually add the device to the
+ * deferred probe list when dev_ready_to_probe() returns false.
+ *
+ * When dev_ready_to_probe() returns false, it means that device_add()
+ * will do another probe() attempt for us.
+ */
dev->can_match = true;
dev_dbg(dev, "bus: '%s': %s: matched device with driver %s\n",
drv->bus->name, __func__, drv->name);