linux-rng/include/linux/device, branch master

Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux

2026-10-30T16:18:43Z

Pull clk updates from Stephen Boyd: "Here's the clk changes for the merge window which is dominated in the diffstat by Qualcomm churning out new SoCs that need clk drivers. Looking beyond the sheer amount of lines of mostly data there we have a clk nexus DT binding change in the core clk framework and a driver core patch to add a subsys driver macro. The clock nexus support is useful for devices that map clks internally or for connectors on a board that route clock signals to another board. I suspect the use of this will expand in the future, so we have unit tests to make sure it doesn't break. The driver core change adds subsys_driver() and subsys_platform_driver() so we can register early drivers without open-coding that all (module_platform_driver() is at device initcall level so it isn't be used). Beyond the core framework bits we have lots of changes all over the tree to initialize 'struct clk_init_data'. The potential risk here is that someone forgets to initialize all the members of that structure and either the clk flags cause weird behavior later on or the parents are pointing at junk and the clk is orphaned forever. The patches just initialize the thing with zeroes to be safe. Longer term we should probably move this struct out of 'struct clk_hw' and pass it during clk registration time. That's a much bigger change and would require restructuring entire drivers that rely on the pointer being there. Finally, we have the usual fixes like calculation updates for dividers, handling error paths during clk registration, or fixing clk data now that drivers are using them. Those patches are dwarfed by the amount of new SoC support and only affect those SoCs and the consumers of those clks. Overall I'm more concerned the clk_init_data patches are going to expose some latent bugs that we didn't notice before because something was relying on clks being orphaned and now they're not. Core: - subsys_driver() / subsys_platform_driver() macros - Clock nexus DT binding support (with KUnit tests) - Spread-spectrum configuration validation - Fully initialize struct clk_init_data across many drivers New Drivers: - Anlogic DR1V90 CRU - ZTE zx297520v3 top, matrix, and LSP clocks - Samsung Exynos5515 and ACPM driver extended to Exynos850. - Qualcomm Eliza camera, camera-BIST, GPU, and video clks - Qualcomm Hawi / Maili camera and GPU controllers - Qualcomm Kuno global, RPMh - Qualcomm MSM8952 global, RPM - Qualcomm Nord camera/video clocks, EMAC interconnect, PHY resets - Qualcomm IPQ5210 / IPQ9650 network clocks - i.MX93 350 MHz fractional-N GP-PLL for display - i.MX pll14xx spread-spectrum clock generation - Amlogic A9 SCMI clock controller - Allwinner single-divider "update bit" support - EN7523 Serdes port selection" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (316 commits) clk: imx: pll14xx: support spread spectrum clock generation clk: cdce925: Size the PLL child name buffer for any int clk: stm32: fix clock array size for STM32MP21 dt-bindings: clock: Convert HiSilicon clocks to DT schema clk: lmk04832: Handle reset GPIO lookup errors dt-bindings: clock: anlogic,dr1v90-cru: make external clocks optional clk: tegra: bpmp: remove kcalloc clk: mmp2-audio: add missing PM_CLK dependency clk: zte: Introduce a driver for zx297520v3 LSP clocks clk: zte: Introduce a driver for zx297520v3 matrix clocks clk: zte: Introduce a driver for zx297520v3 top clocks clk: zte: Add zx PLL support infrastructure clk: zte: Add regmap-based clocks clk: zte: Add Clock registration infrastructure dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset controller dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset controller dt-bindings: clk: zte: Add zx297520v3 top clock and reset controller clk: nuvoton: ma35d1: Add missing WDT/WWDT parent clocks dt-bindings: clock: ma35d1: Add missing WDT/WWDT parent clocks dt-bindings: clock: ma35d1: Drop CLK_MAX_IDX define ...

Merge tag 'driver-core-7.4-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core

2026-10-26T17:04:41Z

Pull driver core fixes from Danilo Krummrich: - Make parent-lock requirements per device type instead of per bus, fixing a use-after-free on USB disconnect by limiting the requirement to USB interfaces, which retain a reference to their parent - Honor parent-lock requirements during deferred and asynchronous probing, fixing USB interface probe races, including duplicate endpoint creation attempts in sysfs * tag 'driver-core-7.4-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: driver core: take parent lock in async device attach driver core: take parent lock on deferred probe driver core: fix parent lock use-after-free on USB disconnect

Merge tag 'hardening-v7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2026-10-23T01:01:57Z

Pull hardening updates from Kees Cook: - Provide kmalloc_obj*-style API for devm_kmalloc() - Improve seq_buf API for saner C String handling with several bug fixes along the way (Kees Cook, Bill Wendling) - Overflow helper readability improvements (Bill Wendling) - Unexport native_write_cr4() (Dennis Chen) - um: fix CONFIG_GCOV for built-in code (Johannes Berg) - Improve stackinit test coverage (Justin Stitt) - KMSAN: fix memset() when using fortify-source, again (Arnd Bergmann) - lkdtm: use kmalloc() instead of __get_free_page (Mahad Ibrahim) - signalfd: don't dequeue the forced fatal signals (Oleg Nesterov) - Fix randstruct to recognize new container_of() behavior - coccinelle: kmalloc_obj: Convert multi-byte integral allocations too - Fix a couple remaining allocation return type mismatches * tag 'hardening-v7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: (29 commits) overflow: Match arithmetic in both parts of __builtin_choose_expr lkdtm: Make UNSET_SMEP built-in-only and unexport native_write_cr4() extcon: realtek: Remove const from type_c_cfg allocation type coresight: cti: Add const to con_groups allocation type docs: core-api: Document the seq_buf API nvdimm: ndtest: Return the string length from flags_show() powerpc/papr_scm: Return the string length from the sysfs show functions seq_buf: Add seq_buf_init_append() bpf: Remove dead newline stripping from format_disasm_line() seq_buf: Add seq_buf_terminate() seq_buf: Add seq_buf_strlen() seq_buf: Clear what a writer did not claim when a seq_buf overflows seq_buf: Copy what fits when seq_buf_puts() and seq_buf_putmem() overflow scsi: lpfc: Print rx monitor records straight into the seq_buf seq_buf: Do not pop from an overflowed seq_buf seq_buf: Do not print an empty line from an overflowed seq_buf_do_printk() .get_maintainer.ignore: Add Kees Cook devres: Provide kmalloc_obj*-style API for devm_kmalloc mm: Move default_gfp() into gfp_types.h kunit/stackinit: Clean up XFAIL under instrumentation ...

driver core: fix parent lock use-after-free on USB disconnect

2026-10-16T20:35:48Z

USB interfaces should be probed with their parent USB device lock held and the USB bus therefore sets the need_parent_lock bus flag so that driver core takes the parent lock when needed. Driver core is only guaranteed to hold a reference to the parent device during initial probe however and nothing prevents the device and its parent from being deregistered and the parent potentially freed, for example, while iterating over devices in driver_attach() or bus_rescan_devices_helper(). Since commit 524134d42231 ("USB: don't cancel queued resets when unbinding drivers") USB interfaces hold a reference to their parent USB device, but a parent hub may still go away while probing a USB device (e.g. via the drivers_probe sysfs interface). This can lead to a use-after-free when taking the parent device lock before checking the device->p->dead flag of the device being probed. As only USB interfaces actually need the parent lock, make the need_parent_lock feature even more fine grained by making it a device type rather than bus feature. By requiring that any users also make sure that their devices hold a reference to their parents (like USB does), driver core can lock a device and its parent without first checking if the device has been deregistered. Note that this will also increase parallelism when using asynchronous probe as USB devices connected to the same hub can now be probed in parallel. Fixes: bf74ad5bc417 ("[PATCH] Hold the device's parent's lock during probe and remove") Cc: stable@vger.kernel.org # 2.6.16: 524134d42231: USB: don't cancel queued resets when unbinding drivers Cc: stable@vger.kernel.org # 2.6.16 Cc: Alan Stern Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20261014133109.1392265-2-johan@kernel.org [ Fix mention of bus vs. device type in __device_driver_{un}lock(). - Danilo ] Signed-off-by: Danilo Krummrich

devres: Provide kmalloc_obj*-style API for devm_kmalloc

2026-10-06T00:50:53Z

Mirroring the type-based allocation now in use for the kmalloc family of APIs, provide the same for the devm_kmalloc family of APIs. This will allow for future plumbing of type information (e.g. alignment) into the underlying allocations. This immediately gains type check on return values (instead of the prior "void *" return type). Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260914223219.901347-2-kees@kernel.org Signed-off-by: Kees Cook

driver core/ACPI: Introduce companion_bus_register()

2026-09-25T16:41:48Z

The ACPI bus type does not allow drivers to be matched to devices, so the sysfs attributes related to drivers created for it are useless and their existence is confusing. Moreover, it is better to prevent drivers from being registered and looked up for a bus like that. To allow skipping the creation of those sysfs attributes and preventing driver registration and lookup for the ACPI bus type, introduce a "companion" bus type concept and add a special registration function for registering "companion" bus types, companion_bus_register(). The "drivers" directory under the ACPI bus type is still needed because there are versions of systemd that depend on it [1]. Link: https://lore.kernel.org/linux-acpi/SN6PR02MB41575266A4580339E186E5D9D4812@SN6PR02MB4157.namprd02.prod.outlook.com/ [1] Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman Reviewed-by: Danilo Krummrich Tested-by: Michael Kelley Reviewed-by: Michael Kelley [ rjw: Add comment regarding drivers_kset creation in bus_register_internal() ] Link: https://patch.msgid.link/12985239.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki

driver: core: add subsys_driver() macro

2026-09-23T23:24:30Z

Add a new macro subsys_driver() to eliminate some boilerplate code in drivers that need to register earlier in the boot at the subsys_initcall level. Signed-off-by: Brian Masney Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Geert Uytterhoeven Reviewed-by: Abel Vesa Tested-by: Pankaj Patil Link: https://lore.kernel.org/r/20260908-subsys_initcall-v1-1-cbccf4cd4288@redhat.com Signed-off-by: Bjorn Andersson

driver: core: Include headers for acpi_device_id and of_device_id for struct device_driver

2026-07-03T05:38:14Z

struct device_driver contains pointers of type struct of_device_id* and struct acpi_device_id* but doesn't ensure these are defined. To make the header self-contained add the (very lightweight) includes that contain the respective definitions. Acked-by: Greg Kroah-Hartman Acked-by: Danilo Krummrich Acked-by: Rafael J. Wysocki (Intel) Acked-by: Takashi Sakamoto Link: https://patch.msgid.link/199ba71b4ac73f4b4d9f5d2be635c96eec73c70e.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub)

driver core: remove driver_set_override()

2026-05-30T20:25:50Z

All buses have been converted from driver_set_override() to the generic driver_override infrastructure introduced in commit cb3d1049f4ea ("driver core: generalize driver_override in struct device"). Buses now either opt into the generic sysfs callbacks via the bus_type::driver_override flag, or use device_set_driver_override() / __device_set_driver_override() directly. Thus, remove the now-unused driver_set_override() helper. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260505133935.3772495-6-dakr@kernel.org Signed-off-by: Danilo Krummrich

Merge patch series "rust: device: Higher-Ranked Lifetime Types for device drivers"

2026-05-28T22:38:54Z

Danilo Krummrich says: Currently, Rust device drivers access device resources such as PCI BAR mappings and I/O memory regions through Devres. Devres::access() provides zero-overhead access by taking a &Device reference as proof that the device is still bound. Since a &Device is available in almost all contexts by design, Devres is mostly a type-system level proof that the resource is valid, but it can also be used from scopes without this guarantee through its try_access() accessor. This works well in general, but has a few limitations: - Every access to a device resource goes through Devres::access(), which despite zero cost, adds boilerplate to every access site. - Destructors do not receive a &Device, so they must use try_access(), which can fail. In practice the access succeeds if teardown ordering is correct, but the type system can't express this, forcing drivers to handle a failure path that should never be taken. - Sharing a resource across components (e.g. passing a BAR to a sub-component) requires Arc>. - Device references must be stored as ARef rather than plain &Device borrows. These limitations stem from the driver's bus device private data being 'static -- the driver struct cannot borrow from the device reference it receives in probe(), even though it structurally cannot outlive the device binding. This series introduces Higher-Ranked Lifetime Types (HRT) for Rust device drivers. An HRT is a type that is generic over a lifetime -- it does not have a fixed lifetime, but can be instantiated with any lifetime chosen by the caller. Bus driver traits use a Generic Associated Type (GAT) type Data<'bound> to introduce the lifetime on the private data, rather than parameterizing the Driver trait itself. This avoids a driver trait global lifetime and avoids the need for ForLt for bus device private data, making the bus implementations much simpler. ForLt is only needed for auxiliary registration data, where the lifetime is not introduced by a trait callback but must be threaded through Registration. With HRT, driver structs carry a lifetime parameter tied to the device binding scope -- the interval of a bus device being bound to a driver. Device resources like pci::Bar<'bound> and IoMem<'bound> are handed out with this lifetime, so the compiler enforces at build time that they do not escape the binding scope. Before: struct MyDriver { pdev: ARef, bar: Devres>, } let io = self.bar.access(dev)?; io.read32(OFFSET); After: struct MyDriver<'bound> { pdev: &'bound pci::Device, bar: pci::Bar<'bound, BAR_SIZE>, } self.bar.read32(OFFSET); Lifetime-parameterized device resources can be put into a Devres at any point via Bar::into_devres() / IoMem::into_devres(), providing the exact same semantics as before. This is useful for resources shared across subsystem boundaries where revocation is needed. This also synergizes with the upcoming self-referential initialization support in pin-init, which allows one field of the driver struct to borrow another during initialization without unsafe code. The same pattern is applied to auxiliary device registration data as a first example beyond bus device private data. Registration can hold lifetime-parameterized data tied to the parent driver's binding scope. Since the auxiliary bus guarantees that the parent remains bound while the auxiliary device is registered, the registration data can safely borrow the parent's device resources. More generally, binding resource lifetimes to a registration scope applies to every registration that is scoped to a driver binding -- auxiliary devices, class devices, IRQ handlers, workqueues. A follow-up series extends this to class device registrations, starting with DRM, so that class device callbacks (IOCTLs, etc.) can safely access device resources through the separate registration data bound to the registration's lifetime without Devres indirection. Thanks to Gary for coming up with the ForLt implementation; thanks to Alice for the early discussions around lifetime-parameterized private data that helped shape the direction of this work. Link: https://patch.msgid.link/20260525202921.124698-1-dakr@kernel.org Signed-off-by: Danilo Krummrich