kernel/linux.git/drivers/base/base.h, branch v7.0-rc7

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

2026-03-03T12:12:42+00:00

This reverts commit dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()") and commit 289b14592cef ("driver core: fix inverted "locked" suffix of driver_match_device()"). While technically correct, there is a major downside to this approach: When a device is already present in the system and a driver is registered on the same bus, we iterate over all devices registered on this bus to see if one of them matches. If we come across an already bound one where the corresponding driver crashed while holding the device lock (e.g. in probe()) we can't make any progress anymore. However, drivers are typically the least tested code in the kernel and hence it is a case that is likely to happen regularly. Besides hurting developer ergonomics, it potentially decreases chances of shutting things down cleanly and obtaining logs in production environments as well [1]. This came up in the context of a firewire bug, which only in combination with the reverted commit, caused the machine to hang [2]. Additionally, it was observed in [3]. Thus, revert commit dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()") and add a brief note clarifying that an implementer of struct bus_type must not expect match() to be called with the device lock held. Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Link: https://lore.kernel.org/all/67f655bb-4d81-4609-b008-68d200255dd2@davidgow.net/ [2] Link: https://lore.kernel.org/lkml/CALbr=LZ4v7N=tO1vgOsyj9AS+XuNbn6kG-QcF+PacdMjSo0iyw@mail.gmail.com/ [3] Reported-by: Linus Torvalds Closes: https://lore.kernel.org/driver-core/CAHk-=wgJ_L1C=HjcYJotg_zrZEmiLFJaoic+PWthjuQrutrfJw@mail.gmail.com/ Reviewed-by: Gui-Dong Han Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260302002545.19389-1-dakr@kernel.org [ Add additional Link: reference. - Danilo ] Signed-off-by: Danilo Krummrich

Merge tag 'pinctrl-v7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

2026-02-16T17:35:24+00:00

Pull pin control updates from Linus Walleij: "Core changes: - Drop the unused devm_pinctrl_unregister() function - Move pretended generic pin control functionality out of the core and into the Amlogic AM4 driver. We have something better coming (hopefully) New hardware support: - Spacemit K3 (RISC-V) pin control support - Atmel AT91 PIO4 (ARM32) SAMA7D65 pin control support - Exynos9610 (ARM64) pin control support - Qualcomm Mahua TLMM (ARM64) pin control support - Microchip Polarfire MSSIO (RISC-V) pin control support - Ocelot LAN9645XF (multiplatform) pin control support Improvements: - Using a few more guards for locking - Various nonurgent fixes and tweaks" * tag 'pinctrl-v7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (73 commits) pinctrl: generic: move function to amlogic-am4 driver pinctrl: intel: Align Copyright note with corporate guidelines pinctrl: mediatek: remove unused drv_offset field pinctrl: canaan: k230: Fix NULL pointer dereference when parsing devicetree pinctrl: single: fix refcount leak in pcs_add_gpio_func() pinctrl: meson: amlogic-a4: Fix device node reference leak in bank helpers pinctrl: qcom: sm8250-lpass-lpi: Fix i2s2_data_groups definition pinctrl: core: Remove duplicate error messages pinctrl: core: Simplify devm_pinctrl_*() pinctrl: core: Remove unused devm_pinctrl_unregister() dt-bindings: pinctrl: spacemit: fix drive-strength check warning pinctrl: fix kismet issues with GENERIC_PINCTRL pinctrl: tangier: Join tng_pinctrl_probe() into its wrapper pinctrl: tangier: Remove duplicate error messages pinctrl: lynxpoint: Remove duplicate error messages pinctrl: cherryview: Remove duplicate error messages pinctrl: baytrail: Remove duplicate error messages pinctrl: intel: Remove duplicate error messages pinctrl: equilibrium: Fix device node reference leak in pinbank_init() dt-bindings: pinctrl: pinctrl-microchip-sgpio: add LAN969x ...

driver core: fix inverted "locked" suffix of driver_match_device()

2026-02-01T21:24:25+00:00

In the current implementation driver_match_device() expects the device lock to be held, while driver_match_device_locked() acquires the device lock. By convention it should be the other way around, hence swap the name of both functions. Fixes: dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()") Reviewed-by: Greg Kroah-Hartman Reviewed-by: Gui-Dong Han Link: https://patch.msgid.link/20260131014211.12841-1-dakr@kernel.org Signed-off-by: Danilo Krummrich

Merge tag 'driver-core-6.19-rc7-deferred' into driver-core-next

2026-01-26T13:12:02+00:00

Driver core fixes deferred from 6.19-rc7 [1, 2] were originally intended for -rc7. Patch [1] uncovered potential deadlocks that require a few driver fixes; [2] is one such fix. [1] https://patch.msgid.link/20260113162843.12712-1-hanguidong02@gmail.com [2] https://patch.msgid.link/20260121141215.29658-1-dakr@kernel.org Signed-off-by: Danilo Krummrich

driver-core: move devres_for_each_res() to base.h

2026-01-22T16:13:36+00:00

devres_for_each_res() is only used by .../firmware_loader/main.c, which already includes base.h. The usage of devres_for_each_res() by code outside of driver-core is questionable, hence move it to base.h. Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260119162920.77189-1-dakr@kernel.org Signed-off-by: Danilo Krummrich

driver core: make pinctrl_bind_pins() private

2026-01-18T23:34:44+00:00

pinctrl_bind_pins() is only used by driver core (as it should). Move it out of the public header into base.h. Signed-off-by: Bartosz Golaszewski Reviewed-by: Greg Kroah-Hartman Acked-by: Danilo Krummrich Signed-off-by: Linus Walleij

driver core: enforce device_lock for driver_match_device()

2026-01-16T11:40:58+00:00

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

rust: device: introduce Device::drvdata()

2025-10-29T17:18:02+00:00

In C dev_get_drvdata() has specific requirements under which it is valid to access the returned pointer. That is, drivers have to ensure that (1) for the duration the returned pointer is accessed the driver is bound and remains to be bound to the corresponding device, (2) the returned void * is treated according to the driver's private data type, i.e. according to what has been passed to dev_set_drvdata(). In Rust, (1) can be ensured by simply requiring the Bound device context, i.e. provide the drvdata() method for Device only. For (2) we would usually make the device type generic over the driver type, e.g. Device, where ::Data is the type of the driver's private data. However, a device does not have a driver type known at compile time and may be bound to multiple drivers throughout its lifetime. Hence, in order to be able to provide a safe accessor for the driver's device private data, we have to do the type check on runtime. This is achieved by letting a driver assert the expected type, which is then compared to a type hash stored in struct device_private when dev_set_drvdata() is called. Example: // `dev` is a `&Device`. let data = dev.drvdata::()?; There are two aspects to note: (1) Technically, the same check could be achieved by comparing the struct device_driver pointer of struct device with the struct device_driver pointer of the driver struct (e.g. struct pci_driver). However, this would - in addition the pointer comparison - require to tie back the private driver data type to the struct device_driver pointer of the driver struct to prove correctness. Besides that, accessing the driver struct (stored in the module structure) isn't trivial and would result into horrible code and API ergonomics. (2) Having a direct accessor to the driver's private data is not commonly required (at least in Rust): Bus callback methods already provide access to the driver's device private data through a &self argument, while other driver entry points such as IRQs, workqueues, timers, IOCTLs, etc. have their own private data with separate ownership and lifetime. In other words, a driver's device private data is only relevant for driver model contexts (such a file private is only relevant for file contexts). Having that said, the motivation for accessing the driver's device private data with Device::drvdata() are interactions between drivers. For instance, when an auxiliary driver calls back into its parent, the parent has to be capable to derive its private data from the corresponding device (i.e. the parent of the auxiliary device). Reviewed-by: Alice Ryhl Reviewed-by: Greg Kroah-Hartman [ * Remove unnecessary `const _: ()` block, * rename type_id_{store,match}() to {set,match}_type_id(), * assert size_of::() >= size_of::(), * add missing check in case Device::drvdata() is called from probe(). - Danilo ] Signed-off-by: Danilo Krummrich

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