Re: [RFC PATCH 0/4] device_schedule_reprobe(): core helper and conversions

[Daniel Golle <daniel@makrotopia.org>]

On Tue, Aug 11, 2026 at 05:07:47PM +0900, Greg Kroah-Hartman wrote:
> That feels a bit better, as long as this code really is "safe" :)
>
> So, how can this be tested and fixed up so it isn't an RFC anymore?

The helper went out as v2 [1] and v3 [2] on its own, and it now travels
as patch 3 of the mxl862xx devlink flash series [3], whose driver is
its first user: that driver reflashes a DSA switch over MDIO and has no
in-place path back, so it reinitialises through a deferred detach and
re-probe. Patch 4 of that series does not link without the helper and
the series cannot be split around it, so what it needs from the driver
core is an ack on that patch.

On testing. Every firmware flash and every recovery in that series ends
in device_schedule_reprobe(), so the helper is on the path of all of
the following, run on an MxL86252C switch of the BananaPi R4 Pro 8X: an
upgrade through fwupd; a reboot issued while a flash was running, which
waits for the transfer to finish; a host crash in the middle of a
transfer, whose wedged download the driver drains in the background
before re-probing; and a power cut in the middle of a transfer, after
which the bootloader came up ready and fwupd flashed the switch back to
a released firmware. That kernel was built with PROVE_LOCKING,
PROVE_RCU, DEBUG_LOCK_ALLOC, DEBUG_MUTEXES, DEBUG_SPINLOCK,
DEBUG_RT_MUTEXES, DEBUG_WW_MUTEX_SLOWPATH, DEBUG_ATOMIC_SLEEP, KASAN
(generic), UBSAN, DETECT_HUNG_TASK and SOFTLOCKUP_DETECTOR, on PREEMPT,
and the logs were clean.

On the fixing up, since the version in this thread:

The helper adds no state to the driver core. That version grew a
shutdown_done bit in struct device_private, set from device_shutdown();
the work now tests defer_all_probes instead, which device_shutdown()
and dpm_prepare() both set before they touch any device. base.h and
core.c are untouched, so the patch is dd.c and device.h only.

Nothing is locked in the caller's context, and the parent is neither
pinned nor locked. Recording dev->parent and taking
__device_driver_lock() meant the device lock was taken where the caller
stands, which inverted against the devlink instance lock that a devlink
flash holds across the call, and a pinned parent can be replaced by
device_move() without any device lock held. The work now takes
device_lock(dev) alone, and a bus that sets need_parent_lock is refused
with -EINVAL when the re-probe is scheduled. usb_bus_type is the only
such bus in the tree, and the three conversions re-probe PCI and serdev
devices, so none of them is refused.

__device_release_driver() reports whether it released the driver, and
takes an abort_if_blocked flag. It drops the device lock while busy
consumer links are unbound; on re-acquisition it re-checks
defer_all_probes and abandons the release, which closes the window
where a ->remove() could follow a ->shutdown() on the same device. Only
the deferred re-probe passes true, since an administrative unbind has
to complete and driver_detach() would spin on a device it never
released. Because the work learns whether it was the call that released
the driver, an unbind winning that race is no longer undone by the
re-attach.

The work runs on system_freezable_wq rather than the unbound queue
Marco commented on, so a re-probe pending across system suspend runs
once the system has resumed, instead of detaching a suspended device or
racing its late suspend callbacks.

-EPROBE_DEFER is kept out of the re-probe error path, where
dev_err_probe() would have recorded it as the device's deferred probe
reason. The kernel-doc no longer promises that an administrative unbind
is never undone, which unbind_store() does not guarantee, and it now
states the calling context and the freezable behaviour.

The conversions of the open-coded users in iwlwifi, hci_h5 and
btintel_pcie follow once the helper is merged, which is the part that
removes the module_get(THIS_MODULE) you objected to. Hans reviewed and
tested the helper and the hci_h5 conversion on RTL8723BS hardware
[4][5]; the helper has changed materially since, so I have not carried
those tags over.

[1] https://lore.kernel.org/all/cover.1787185594.git.daniel@makrotopia.org/
[2] https://lore.kernel.org/all/cover.1787281239.git.daniel@makrotopia.org/
[3] https://lore.kernel.org/all/cover.1789175618.git.daniel@makrotopia.org/
[4] https://lore.kernel.org/all/c461462f-de0b-43e8-ac9e-541013f5f8da@oss.qualcomm.com/
[5] https://lore.kernel.org/all/7ffe0c2e-0742-488a-ab6c-1dc2fabc049c@oss.qualcomm.com/

Thanks,


Daniel