Re: [PATCH net-next v15 3/6] driver core: add device_schedule_reprobe()

Re: [PATCH net-next v15 3/6] driver core: add device_schedule_reprobe()

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 7 potential
issue(s) to consider:

Critical: 0 · High: 1 · Medium: 4 · Low: 2

- [High] The '!defer_all_probes' test in device_reprobe_work_fn()
  (drivers/base/dd.c:1473) does not serialize the deferred detach…
- [Medium] The commit message justifies the new helper entirely with live
  bugs in three named in-tree drivers (iwlwifi iwl_trans_reprobe_wk(),…
- [Medium] device_schedule_reprobe() acquires device_lock(dev)
  synchronously in the caller's context (drivers/base/dd.c:1539) to…
- [Medium] device_schedule_reprobe() snapshots dev->parent and pins it
  under the device lock (drivers/base/dd.c:1540-1550), relying on the…
- [Medium] The deferred detach checks defer_all_probes only once
  (drivers/base/dd.c:1473), but __device_release_driver() transiently…
- [Low] device_schedule_reprobe() records the bound driver as a raw
  pointer (rp->drv = dev->driver, drivers/base/dd.c:1551) and…
- [Low] The kernel-doc states 'In particular a device left unbound by an
  administrative unbind stays unbound', but device_reprobe_work_fn()…

--

driver core: add device_schedule_reprobe()

This adds a driver core helper that schedules a delayed detach and
re-probe of a device on system_freezable_wq, recording the bound driver
and parent under the device lock at scheduling time.  It also changes
__device_release_driver() to report whether it was the caller that
released the driver.

A few questions below.

The first one is about the commit message rather than the diff.

[Severity: Medium]

The message opens with three named in-tree drivers:

  "Three in-tree drivers schedule a deferred re-probe of their own device
   from a work item whose work function lives in module text: iwlwifi
   [...] hci_h5 (h5_btrtl_resume(), ...) and btintel_pcie ..."

and then concludes:

  "Both classes disappear when the driver core owns the deferred work."

None of the three drivers is converted here, and there is no Fixes: tag,
so both bug classes remain live in the tree at this commit.  In
drivers/bluetooth/hci_h5.c the reprobe worker still ends with

    put_device(reprobe->dev);
    kfree(reprobe);
    module_put(THIS_MODULE);

and btintel_pcie still calls device_reprobe() synchronously from its own
reset work.

Can the last two actually use the new helper as written?  h5_btrtl_resume()
is reached from the serdev ->resume callback, which the PM core invokes
with device_lock(dev) held (device_resume() in
drivers/base/power/main.c), while device_schedule_reprobe() takes
device_lock(dev) itself.  btintel_pcie needs the detach to have completed
by the time its FLR path returns, which a fire-and-forget delayed work
with no completion or result cannot express.

Could the rationale be reworded to describe what this patch actually
changes, or the conversions be included?

Also, the actual user of the new export is not named anywhere above the
line; it arrives later in the series as "net: dsa: mxl862xx: add devlink
flash_update and info_get", so the no-in-tree-caller half of this is
resolved there.  Only the overstated motivation is at issue here.

> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index f6525a7ee8c54..aa1f278d0ee29 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -1315,7 +1315,7 @@ EXPORT_SYMBOL_GPL(driver_attach);
>   * __device_release_driver() must be called with @dev lock held.
>   * When called for a USB interface, @dev->parent lock must be held as well.
>   */
> -static void __device_release_driver(struct device *dev, struct device *parent)
> +static bool __device_release_driver(struct device *dev, struct device *parent)
>  {
>  	struct device_driver *drv;
>  
> @@ -1336,7 +1336,7 @@ static void __device_release_driver(struct device *dev, struct device *parent)
>  			 */
>  			if (dev->driver != drv) {
>  				pm_runtime_put(dev);
> -				return;
> +				return false;
>  			}
>  		}

[Severity: Medium]

The loop this return sits in drops both locks and, on re-acquisition,
only re-validates dev->driver:

drivers/base/dd.c:__device_release_driver() {
	while (device_links_busy(dev)) {
		__device_driver_unlock(dev, parent);
		device_links_unbind_consumers(dev);
		__device_driver_lock(dev, parent);
		if (dev->driver != drv) {
			pm_runtime_put(dev);
			return false;
		}
	}

The new caller checks defer_all_probes exactly once, before entering
here.  Can device_shutdown() take device_lock(parent)/device_lock(dev) in
that unlocked window and run ->shutdown()?  ->shutdown() does not change
dev->driver, so the release then resumes and calls device_remove(), i.e.
->remove() against already-quiesced state.

For the driver class the commit message names, "drivers which clear their
drvdata in ->shutdown() so that a subsequent ->remove() becomes a no-op",
that is the use-after-free of driver state the helper is introduced to
prevent.

The message describes this window as pre-existing and

  "not made worse by this helper."

Is that accurate?  Every pre-existing unbind path with this window needs
an administrator action, whereas this helper turns an asynchronous
in-kernel event (firmware crash recovery, a devlink flash) into an unbind
that can coincide with an unattended reboot.  Would re-checking
defer_all_probes after the device links loop re-acquires the locks close
it?

[ ... ]

> @@ -1436,3 +1439,122 @@ void driver_detach(const struct device_driver *drv)
>  		put_device(dev);
>  	}
>  }
> +
> +struct device_reprobe {
> +	struct delayed_work work;
> +	struct device *dev;
> +	struct device *parent;
> +	const struct device_driver *drv;
> +	bool parent_lock;
> +};
> +
> +static void device_reprobe_work_fn(struct work_struct *work)
> +{
> +	struct device_reprobe *rp = container_of(work, struct device_reprobe,
> +						 work.work);
> +	struct device *parent = rp->parent;
> +	struct device *dev = rp->dev;
> +	bool detached = false;
> +	int ret;
> +
> +	/*
> +	 * A device unregistered before the work runs may have outlived the
> +	 * module providing its bus type, so dev->bus is not read until the
> +	 * device is known to be live.
> +	 */
> +	if (rp->parent_lock)
> +		device_lock(parent);
> +	device_lock(dev);
> +	/*
> +	 * rp->drv is only ever compared, never dereferenced: the driver it
> +	 * points to may have been unregistered and freed by now.
> +	 * device_shutdown() blocks probing before its walk reaches @dev.
> +	 */
> +	if (!defer_all_probes && !dev->p->dead && dev->driver == rp->drv)
> +		detached = __device_release_driver(dev, parent);

[Severity: High]

Is this plain read of defer_all_probes enough to order the deferred
detach against device_shutdown()?  Nothing registers, cancels, flushes or
waits for this delayed work, and device_shutdown() only does:

drivers/base/core.c:device_shutdown() {
	wait_for_device_probe();
	device_block_probing();

wait_for_device_probe() waits on deferred_probe_work, probe_count and
async probes, none of which covers this work item.  So:

CPU0 device_reprobe_work_fn()
	device_lock(dev);
	/* reads defer_all_probes == false */

CPU1 device_shutdown()
	wait_for_device_probe();	/* does not see this work */
	device_block_probing();		/* defer_all_probes = true */
	/* walk reaches dev, blocks on device_lock(dev) */

CPU0 continues
	__device_release_driver(dev, parent);	/* ->remove(), driver = NULL */
	device_unlock(dev);

CPU1 then finds dev->driver == NULL, so neither dev->bus->shutdown nor
dev->driver->shutdown is invoked for this device, and CPU0's subsequent
device_attach() returns -EPROBE_DEFER from really_probe() because
defer_all_probes is now set, which the error filter below drops silently.

Does that leave the device neither shut down nor bound, which is the
class 2 behaviour the message says is closed:

  "The detach half is skipped while probing is blocked, which
   device_shutdown() does before its walk reaches any device. A re-probe
   firing during shutdown therefore leaves the device bound, and its
   ->shutdown() callback still runs."

The freezable workqueue does not help on this path: kernel_restart() and
kernel_power_off() reach device_shutdown() without freezing processes or
workqueues, unlike dpm_prepare().

> +	device_unlock(dev);
> +	if (rp->parent_lock)
> +		device_unlock(parent);
> +
> +	if (detached) {
> +		/*
> +		 * device_attach() must run with the parent locked on buses
> +		 * that require it, mirroring bus_rescan_devices_helper().
> +		 */
> +		if (rp->parent_lock)
> +			device_lock(parent);
> +		ret = device_attach(dev);

[Severity: Low]

The kernel-doc below promises "In particular a device left unbound by an
administrative unbind stays unbound", but the device and parent locks are
dropped between the detach above and this device_attach().  Can an unbind
landing in that gap be silently undone?

drivers/base/bus.c:unbind_store() {
	if (dev && dev->driver == drv) {
		device_driver_detach(dev);
		err = count;
	}

The dev->driver == drv test runs without the device lock, so if it passes
just before the work detaches, device_driver_detach() ->
device_release_driver_internal() finds dev->driver == NULL,
__device_release_driver() returns false, unbind_store() still returns
count, and this device_attach() re-binds the device.  In-kernel callers of
device_release_driver() see the same no-op.

The new __device_release_driver() return value covers the narrower race
inside the device_links_busy() loop, where the competing unbinder did
perform the release; it cannot detect an unbind that released nothing
because the work got there first.

> +		if (ret < 0 && ret != -EPROBE_DEFER)
> +			dev_err_probe(dev, ret,
> +				      "re-probe failed, device left unbound\n");
> +		if (rp->parent_lock)
> +			device_unlock(parent);
> +	}
> +
> +	put_device(dev);
> +	put_device(parent);
> +	kfree(rp);
> +}
> +
> +/**
> + * device_schedule_reprobe - schedule a deferred detach and re-probe
> + * @dev: device to detach and re-probe
> + * @delay_ms: delay in milliseconds before the re-probe runs
> + *
> + * Schedule a detach and re-probe of @dev after @delay_ms milliseconds.
> + * The re-probe is skipped if, by the time the scheduled work runs, the
> + * device has been removed, probing has been blocked for a system
> + * shutdown, or @dev is no longer bound to the driver that was bound at
> + * scheduling time. In particular a device left unbound by an
> + * administrative unbind stays unbound.
> + *
> + * The work function is built-in text, so the bound driver may call this
> + * from its own code without holding a module reference. If the driver
> + * module is unloaded before the work runs, driver unregistration unbinds
> + * @dev first and the scheduled work does nothing.
> + *

[ ... ]

> + * The work is freezable: a re-probe pending across system suspend runs
> + * once the system has resumed.
> + *
> + * May only be called from process context, and not from @dev's own
> + * ->probe(), which is called with the device lock held.
> + *
> + * Returns: 0 on success, -EINVAL if @dev is not a registered device
> + * bound to a driver, -ENOMEM on allocation failure.
> + */
> +int device_schedule_reprobe(struct device *dev, unsigned int delay_ms)
> +{
> +	struct device_reprobe *rp;
> +	struct device *parent;
> +
> +	rp = kzalloc_obj(*rp);
> +	if (!rp)
> +		return -ENOMEM;
> +
> +	/* device_del() drops @dev's own reference to the parent. */
> +	device_lock(dev);

[Severity: Medium]

device_lock() is a plain mutex_lock(&dev->mutex) and is not recursive, so
does this hang any caller that already holds @dev's lock, rather than
just the ->probe() case the kernel-doc mentions?

The PM core holds the device lock across the driver sleep callbacks:

drivers/base/power/main.c:device_resume() {
	device_lock(dev);
	...
	error = dpm_run_callback(callback, dev, state, info);

	device_unlock(dev);
}

The same applies to ->suspend, ->prepare and ->complete, and to ->remove
via __device_release_driver() and ->shutdown via device_shutdown().

One of the three call sites this helper is written to replace is exactly
such a context: h5_btrtl_resume() is reached from h5_serdev_resume(), the
serdev ->resume, and it defers device_reprobe() into its own work item
because the device lock is held there.  Would moving the validation and
snapshot into the work function, as those drivers do, avoid this?  If not,
could the documented contract name the PM callbacks, ->remove() and
->shutdown() as well?

> +	parent = dev->parent;
> +	if (!dev->bus || !dev->p || dev->p->dead ||
> +	    !device_is_registered(dev) || !dev->driver) {
> +		device_unlock(dev);
> +		kfree(rp);
> +		return -EINVAL;
> +	}
> +
> +	rp->dev = get_device(dev);
> +	rp->parent = get_device(parent);

[Severity: Medium]

The comment above says device_del() takes the device lock before dropping
@dev's reference to the parent, but device_move() also reassigns
dev->parent while holding only device_pm_lock():

drivers/base/core.c:device_move() {
	old_parent = dev->parent;
	dev->parent = new_parent;
	...
	put_device(old_parent);
}

It never takes device_lock(dev), and the device stays registered and
non-dead throughout, so all the checks just above pass.

Can that put_device(old_parent) free the parent between the read of
dev->parent and this get_device(parent) when the child held the last
reference, making the get_device() a kobject_get() on freed memory and
the later device_lock()/device_unlock()/put_device() in
device_reprobe_work_fn() operate on it too?

And even when the old parent survives, rp->parent is stale for the
lifetime of the work, so the work pins and locks a device that is no
longer dev->parent on buses that set need_parent_lock.

No in-tree caller combines the two today: the user added later in this
series operates on an mdio_device, and the device_move() callers (ccw,
dasd, rfcomm, pvrusb2, u_ether, hci_sysfs) do not use this helper.

> +	rp->parent_lock = parent && dev->bus->need_parent_lock;
> +	rp->drv = dev->driver;

[Severity: Low]

Since rp->drv is a raw pointer used only for address equality in the
work, and the comment there accepts that it may point to freed module
data, can address reuse make the comparison match a different driver?

If the driver module is unloaded and another module is loaded during the
caller-chosen delay, a new struct device_driver can land at the same
address; if the pinned device is then bound to that driver (driver_override
or a matching bus id), dev->driver == rp->drv passes and the work unbinds
and re-probes a device the administrator deliberately bound elsewhere.

That contradicts the kernel-doc statements that the work is skipped when
@dev "is no longer bound to the driver that was bound at scheduling time"
and that "a device left unbound by an administrative unbind stays
unbound".  Would a generation counter, or additionally comparing the
driver name, close it?

> +	device_unlock(dev);
> +
> +	INIT_DELAYED_WORK(&rp->work, device_reprobe_work_fn);
> +	queue_delayed_work(system_freezable_wq, &rp->work,
> +			   msecs_to_jiffies(delay_ms));
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(device_schedule_reprobe);

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/cover.1789175618.git.daniel%40makrotopia.org

[PATCH net-next v15 3/6] driver core: add device_schedule_reprobe()

[Daniel Golle]

Three in-tree drivers schedule a deferred re-probe of their own device
from a work item whose work function lives in module text: iwlwifi
(iwl_trans_schedule_reprobe(), firmware crash recovery when a lighter
restart is not sufficient), hci_h5 (h5_btrtl_resume(), RTL devices
lose their firmware state over suspend) and btintel_pcie (synchronous
device_reprobe() from its own reset work, with a hand-rolled locking
contract spanning several comments).

Two bug classes affect the hand-rolled implementations:

1. The work function ends with put_device(); kfree();
   module_put(THIS_MODULE); in module text. After the atomic decrement
   a concurrent rmmod can free the module text before the function
   epilogue has finished executing. This is exactly the race
   module_put_and_kthread_exit() exists to close for kthreads; there
   is no work-item equivalent.

2. There is no synchronization between the deferred device_reprobe()
   and device_shutdown() or a driver unbind. The drivers do not check
   any bound state before calling device_reprobe(), so a stale
   re-probe can undo an administrative unbind, and the detach half can
   run against a device whose ->shutdown() callback has already run.
   The core already blocks the attach half during shutdown
   (device_shutdown() calls device_block_probing() before any
   callback, and really_probe() honors defer_all_probes), but nothing
   blocks the detach half. For drivers which clear their drvdata in
   ->shutdown() so that a subsequent ->remove() becomes a no-op this
   escalates to use-after-free of driver state which other subsystem
   structures still reference.

Both classes disappear when the driver core owns the deferred work.
Add device_schedule_reprobe(), which schedules a detach and re-probe
of a device after a caller-specified delay:

- The work function is builtin text, so callers do not need to hold a
  module reference. If the driver module is unloaded before the work
  runs, driver_unregister() has already unbound the device, the bound
  driver no longer matches the driver recorded at scheduling time and
  the work does nothing.

- The recorded driver pointer is only ever compared, never
  dereferenced, so it may legitimately point to freed memory.

- The bound-state check and __device_release_driver() run under a
  single hold of the device lock and, where the bus needs it, the
  parent lock, the same lock dance device_release_driver_internal()
  uses. This closes the check-vs-detach TOCTOU that drivers cannot
  close themselves, because device_reprobe() takes the device lock
  internally. __device_release_driver() reports whether this call was
  the one to release the driver, so an unbind that wins the race while
  busy consumer links are being unbound is not followed by a re-attach.

- Both @dev and its parent are pinned for the lifetime of the work. The
  parent, whether it needs locking and the bound driver are recorded
  under the device lock, which device_del() takes before it drops @dev's
  reference to the parent. A device that was unregistered before the
  work runs may have outlived the module providing its bus type, so
  dev->bus is not read once the work is scheduled.

- The detach half is skipped while probing is blocked, which
  device_shutdown() does before its walk reaches any device. A re-probe
  firing during shutdown therefore leaves the device bound, and its
  ->shutdown() callback still runs.

- The work is queued on system_freezable_wq. A re-probe pending across
  system suspend therefore runs once the devices have resumed and
  probing is unblocked again, instead of detaching a device the PM core
  has already suspended or running concurrently with its late suspend
  callbacks, which the PM core invokes without the device lock. The
  attach half is plain device_attach(), which checks the dead flag, and
  it takes the parent lock on buses that set need_parent_lock,
  mirroring bus_rescan_devices_helper().

One pre-existing window remains: __device_release_driver()
transiently drops the locks while consumer device links are busy, so
for devices with busy consumers a ->shutdown() can still interleave
in the middle of the release. That window exists identically for
every unbind path in the kernel, sysfs unbind included, and is not
made worse by this helper.

Assisted-by: LLM
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v15:
 - skip the detach while probing is blocked instead of adding a
   per-device shutdown_done flag: device_shutdown() blocks probing
   before its walk starts, so the flag left a window where the work
   detached a device that then neither re-attached nor got its
   ->shutdown() call (found by Sashiko AI review)
 - validate the device and snapshot the parent, its locking requirement
   and the bound driver under the device lock, so an unregister racing
   the allocation can neither leave a freed parent pinned nor pair a
   NULL parent with a request to lock it (found by Sashiko AI review)
 - keep -EPROBE_DEFER out of the re-probe error path, where
   dev_err_probe() would record the message as the device's deferred
   probe reason (found by Sashiko AI review)
 - kernel-doc: a stale re-probe leaves an unbound device unbound, which
   an unbind followed by a rebind within the delay does not (found by
   Sashiko AI review)
v14: no changes
v13:
 - queue the work on system_freezable_wq, so a re-probe pending across
   system suspend can neither detach a device the PM core has suspended
   nor race its late suspend callbacks; it runs after resume instead
   (found by Sashiko AI review)
 - record at scheduling time whether the parent needs locking, instead
   of reading dev->bus in the work, which may be gone with its module
   once the device has been unregistered (found by Sashiko AI review)
 - let __device_release_driver() report whether it released the driver,
   so an administrative unbind that wins the race inside the device
   links loop is not undone by the re-attach (found by Sashiko AI
   review)
 - use dev_err_probe() for the re-probe error path, so a re-probe
   deferred at resume no longer logs a spurious error (Hans de Goede,
   on the standalone posting of this helper)
 - describe the parent pinning and locking in the commit message, as in
   the standalone posting

v12:
 - pin the parent device across the deferred work; a reference on the
   child alone left device_reprobe_work_fn() dereferencing a freed
   dev->parent under __device_driver_lock() when the device was
   unregistered before the work ran (found by Sashiko AI review)
 - take the parent lock across device_attach() on buses that require
   it, matching bus_rescan_devices_helper() (found by Sashiko AI review)

v11: new patch: add device_schedule_reprobe() to the driver core (posted
     earlier as an RFC) so mxl862xx can schedule its post-flash and
     post-drain re-probe through the core instead of open-coding a work
     item

 drivers/base/dd.c      | 126 ++++++++++++++++++++++++++++++++++++++++-
 include/linux/device.h |   2 +
 2 files changed, 126 insertions(+), 2 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index f6525a7ee8c5..aa1f278d0ee2 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -1315,7 +1315,7 @@ EXPORT_SYMBOL_GPL(driver_attach);
  * __device_release_driver() must be called with @dev lock held.
  * When called for a USB interface, @dev->parent lock must be held as well.
  */
-static void __device_release_driver(struct device *dev, struct device *parent)
+static bool __device_release_driver(struct device *dev, struct device *parent)
 {
 	struct device_driver *drv;
 
@@ -1336,7 +1336,7 @@ static void __device_release_driver(struct device *dev, struct device *parent)
 			 */
 			if (dev->driver != drv) {
 				pm_runtime_put(dev);
-				return;
+				return false;
 			}
 		}
 
@@ -1359,7 +1359,10 @@ static void __device_release_driver(struct device *dev, struct device *parent)
 
 		bus_notify(dev, BUS_NOTIFY_UNBOUND_DRIVER);
 		kobject_uevent(&dev->kobj, KOBJ_UNBIND);
+		return true;
 	}
+
+	return false;
 }
 
 void device_release_driver_internal(struct device *dev,
@@ -1436,3 +1439,122 @@ void driver_detach(const struct device_driver *drv)
 		put_device(dev);
 	}
 }
+
+struct device_reprobe {
+	struct delayed_work work;
+	struct device *dev;
+	struct device *parent;
+	const struct device_driver *drv;
+	bool parent_lock;
+};
+
+static void device_reprobe_work_fn(struct work_struct *work)
+{
+	struct device_reprobe *rp = container_of(work, struct device_reprobe,
+						 work.work);
+	struct device *parent = rp->parent;
+	struct device *dev = rp->dev;
+	bool detached = false;
+	int ret;
+
+	/*
+	 * A device unregistered before the work runs may have outlived the
+	 * module providing its bus type, so dev->bus is not read until the
+	 * device is known to be live.
+	 */
+	if (rp->parent_lock)
+		device_lock(parent);
+	device_lock(dev);
+	/*
+	 * rp->drv is only ever compared, never dereferenced: the driver it
+	 * points to may have been unregistered and freed by now.
+	 * device_shutdown() blocks probing before its walk reaches @dev.
+	 */
+	if (!defer_all_probes && !dev->p->dead && dev->driver == rp->drv)
+		detached = __device_release_driver(dev, parent);
+	device_unlock(dev);
+	if (rp->parent_lock)
+		device_unlock(parent);
+
+	if (detached) {
+		/*
+		 * device_attach() must run with the parent locked on buses
+		 * that require it, mirroring bus_rescan_devices_helper().
+		 */
+		if (rp->parent_lock)
+			device_lock(parent);
+		ret = device_attach(dev);
+		if (ret < 0 && ret != -EPROBE_DEFER)
+			dev_err_probe(dev, ret,
+				      "re-probe failed, device left unbound\n");
+		if (rp->parent_lock)
+			device_unlock(parent);
+	}
+
+	put_device(dev);
+	put_device(parent);
+	kfree(rp);
+}
+
+/**
+ * device_schedule_reprobe - schedule a deferred detach and re-probe
+ * @dev: device to detach and re-probe
+ * @delay_ms: delay in milliseconds before the re-probe runs
+ *
+ * Schedule a detach and re-probe of @dev after @delay_ms milliseconds.
+ * The re-probe is skipped if, by the time the scheduled work runs, the
+ * device has been removed, probing has been blocked for a system
+ * shutdown, or @dev is no longer bound to the driver that was bound at
+ * scheduling time. In particular a device left unbound by an
+ * administrative unbind stays unbound.
+ *
+ * The work function is built-in text, so the bound driver may call this
+ * from its own code without holding a module reference. If the driver
+ * module is unloaded before the work runs, driver unregistration unbinds
+ * @dev first and the scheduled work does nothing.
+ *
+ * Multiple pending re-probes for the same device are individually safe;
+ * a caller that wants at most one pending re-probe must gate scheduling
+ * itself.
+ *
+ * The work is freezable: a re-probe pending across system suspend runs
+ * once the system has resumed.
+ *
+ * May only be called from process context, and not from @dev's own
+ * ->probe(), which is called with the device lock held.
+ *
+ * Returns: 0 on success, -EINVAL if @dev is not a registered device
+ * bound to a driver, -ENOMEM on allocation failure.
+ */
+int device_schedule_reprobe(struct device *dev, unsigned int delay_ms)
+{
+	struct device_reprobe *rp;
+	struct device *parent;
+
+	rp = kzalloc_obj(*rp);
+	if (!rp)
+		return -ENOMEM;
+
+	/* device_del() drops @dev's own reference to the parent. */
+	device_lock(dev);
+	parent = dev->parent;
+	if (!dev->bus || !dev->p || dev->p->dead ||
+	    !device_is_registered(dev) || !dev->driver) {
+		device_unlock(dev);
+		kfree(rp);
+		return -EINVAL;
+	}
+
+	rp->dev = get_device(dev);
+	rp->parent = get_device(parent);
+	rp->parent_lock = parent && dev->bus->need_parent_lock;
+	rp->drv = dev->driver;
+	device_unlock(dev);
+
+	INIT_DELAYED_WORK(&rp->work, device_reprobe_work_fn);
+	queue_delayed_work(system_freezable_wq, &rp->work,
+			   msecs_to_jiffies(delay_ms));
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(device_schedule_reprobe);
diff --git a/include/linux/device.h b/include/linux/device.h
index aee79fd6b32b..7a9916950577 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1314,6 +1314,8 @@ int  __must_check device_attach(struct device *dev);
 int __must_check driver_attach(const struct device_driver *drv);
 void device_initial_probe(struct device *dev);
 int __must_check device_reprobe(struct device *dev);
+int __must_check device_schedule_reprobe(struct device *dev,
+					 unsigned int delay_ms);
 
 bool device_is_bound(struct device *dev);
 
-- 
2.55.0