linux.git/drivers/base/base.h, branch v6.18.21

Revert "driver core: enforce device_lock for driver_match_device()"

2026-02-16T16:10:28+00:00

This reverts commit 8d76b2488eb3cc0717ab81b60622cff4a5f90f79 which is
commit dc23806a7c47ec5f1293aba407fb69519f976ee0 upstream.

It causes boot regressions on some systems as all of the "fixes" for
drivers are not properly backported yet.  Once that is completed, only
then can this be applied, if really necessary given the potential for
explosions, perhaps we might want to wait a few -rc releases first...

Cc: Danilo Krummrich 
Cc: Rafael J. Wysocki (Intel) 
Cc: Danilo Krummrich 
Cc: Gui-Dong Han 
Cc: Qiu-ji Chen 
Reported-by: Mark Brown 
Link: https://lore.kernel.org/r/7dfd0e63-a725-4fac-b2a0-f2e621d99d1b@sirena.org.uk
Signed-off-by: Greg Kroah-Hartman

driver core: enforce device_lock for driver_match_device()

2026-02-16T09:19:43+00:00

commit dc23806a7c47ec5f1293aba407fb69519f976ee0 upstream.

Currently, driver_match_device() is called from three sites. One site
(__device_attach_driver) holds device_lock(dev), but the other two
(bind_store and __driver_attach) do not. This inconsistency means that
bus match() callbacks are not guaranteed to be called with the lock
held.

Fix this by introducing driver_match_device_locked(), which guarantees
holding the device lock using a scoped guard. Replace the unlocked calls
in bind_store() and __driver_attach() with this new helper. Also add a
lock assertion to driver_match_device() to enforce this guarantee.

This consistency also fixes a known race condition. The driver_override
implementation relies on the device_lock, so the missing lock led to the
use-after-free (UAF) reported in Bugzilla for buses using this field.

Stress testing the two newly locked paths for 24 hours with
CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled showed no UAF recurrence
and no lockdep warnings.

Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
Suggested-by: Qiu-ji Chen 
Signed-off-by: Gui-Dong Han 
Fixes: 49b420a13ff9 ("driver core: check bus->match without holding device lock")
Reviewed-by: Danilo Krummrich 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Rafael J. Wysocki (Intel) 
Link: https://patch.msgid.link/20260113162843.12712-1-hanguidong02@gmail.com
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

PM: sleep: Do not wait on SYNC_STATE_ONLY device links

2025-09-27T12:10:51+00:00

Device links with DL_FLAG_SYNC_STATE_ONLY should not affect system
suspend and resume, and functions like device_reorder_to_tail() and
device_link_add() don't try to reorder the consumers with that flag.

However, dpm_wait_for_consumers() and dpm_wait_for_suppliers() don't
check thas flag before triggering dpm_wait(), leading to potential hang
during suspend/resume.

This can be reproduced on MT8186 Corsola Chromebook with devicetree like:

usb-a-connector {
        compatible = "usb-a-connector";
        port {
                usb_a_con: endpoint {
                        remote-endpoint = <&usb_hs>;
                };
        };
};

usb_host {
        compatible = "mediatek,mt8186-xhci", "mediatek,mtk-xhci";
        port {
                usb_hs: endpoint {
                        remote-endpoint = <&usb_a_con>;
                };
        };
};

In this case, the two nodes form a cycle and a SYNC_STATE_ONLY devlink
between usb_host (supplier) and usb-a-connector (consumer) is created.

Address this by exporting device_link_flag_is_sync_state_only() and
making dpm_wait_for_consumers() and dpm_wait_for_suppliers() use it
when deciding if dpm_wait() should be called.

Fixes: 05ef983e0d65a ("driver core: Add device link support for SYNC_STATE_ONLY flag")
Signed-off-by: Pin-yen Lin 
Link: https://patch.msgid.link/20250926102320.4053167-1-treapking@chromium.org
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki

PM: core: Add two macros for walking device links

2025-09-06T15:16:32+00:00

Add separate macros for walking links to suppliers and consumers of a
device to help device links users to avoid exposing the internals of
struct dev_links_info in their code and possible coding mistakes related
to that.

Accordingly, use the new macros to replace open-coded device links list
walks in the core power management code.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Ulf Hansson 
Acked-by: Greg Kroah-Hartman 
Link: https://patch.msgid.link/1944671.tdWV9SEqCh@rafael.j.wysocki

driver core: fix potential NULL pointer dereference in dev_uevent()

2025-04-15T15:04:35+00:00

If userspace reads "uevent" device attribute at the same time as another
threads unbinds the device from its driver, change to dev->driver from a
valid pointer to NULL may result in crash. Fix this by using READ_ONCE()
when fetching the pointer, and take bus' drivers klist lock to make sure
driver instance will not disappear while we access it.

Use WRITE_ONCE() when setting the driver pointer to ensure there is no
tearing.

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Masami Hiramatsu (Google) 
Link: https://lore.kernel.org/r/20250311052417.1846985-3-dmitry.torokhov@gmail.com
Signed-off-by: Greg Kroah-Hartman

driver core: introduce device_set_driver() helper

2025-04-15T15:04:35+00:00

In preparation to closing a race when reading driver pointer in
dev_uevent() code, instead of setting device->driver pointer directly
introduce device_set_driver() helper.

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Masami Hiramatsu (Google) 
Link: https://lore.kernel.org/r/20250311052417.1846985-2-dmitry.torokhov@gmail.com
Signed-off-by: Greg Kroah-Hartman

driver core: add a faux bus for use when a simple device/bus is needed

2025-02-13T15:58:51+00:00

Many drivers abuse the platform driver/bus system as it provides a
simple way to create and bind a device to a driver-specific set of
probe/release functions.  Instead of doing that, and wasting all of the
memory associated with a platform device, here is a "faux" bus that
can be used instead.

Reviewed-by: Jonathan Cameron 
Reviewed-by: Danilo Krummrich 
Reviewed-by: Lyude Paul 
Reviewed-by: Thomas Weißschuh 
Reviewed-by: Zijun Hu 
Link: https://lore.kernel.org/r/2025021026-atlantic-gibberish-3f0c@gregkh
Signed-off-by: Greg Kroah-Hartman

Revert "driver core: shut down devices asynchronously"

2024-09-25T09:01:27+00:00

This reverts commit 8064952c65045f05ee2671fe437770e50c151776.

The series is being reverted before -rc1 as there are still reports of
lockups on shutdown, so it's not quite ready for "prime time."

Reported-by: Andrey Skvortsov 
Link: https://lore.kernel.org/r/ZvMkkhyJrohaajuk@skv.local
Cc: Christoph Hellwig 
Cc: David Jeffery 
Cc: Keith Busch 
Cc: Laurence Oberman 
Cc: Nathan Chancellor 
Cc: Sagi Grimberg 
Cc: Stuart Hayes 
Signed-off-by: Greg Kroah-Hartman

driver core: shut down devices asynchronously

2024-09-03T11:06:43+00:00

Add code to allow asynchronous shutdown of devices, ensuring that each
device is shut down before its parents & suppliers.

Only devices with drivers that have async_shutdown_enable enabled will be
shut down asynchronously.

This can dramatically reduce system shutdown/reboot time on systems that
have multiple devices that take many seconds to shut down (like certain
NVMe drives). On one system tested, the shutdown time went from 11 minutes
without this patch to 55 seconds with the patch.

Signed-off-by: Stuart Hayes 
Signed-off-by: David Jeffery 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Keith Busch 
Tested-by: Keith Busch 
Link: https://lore.kernel.org/r/20240822202805.6379-4-stuart.w.hayes@gmail.com
Signed-off-by: Greg Kroah-Hartman

driver core: Remove unused parameter for virtual_device_parent()

2024-07-31T12:55:13+00:00

Function struct kobject *virtual_device_parent(struct device *dev)
does not use its parameter @dev, and the kobject returned also has
nothing deal with specific device, so remove the unused parameter.

Signed-off-by: Zijun Hu 
Link: https://lore.kernel.org/r/20240725-virtual_kobj_fix-v1-1-36335cae4544@quicinc.com
Signed-off-by: Greg Kroah-Hartman