kernel/git/next/linux-next.git/rust/bindings, branch master

Merge branch 'for-linux-next' of https://gitlab.freedesktop.org/drm/rust/kernel.git

2026-09-09T13:05:24+00:00

Merge branch 'mm-nonmm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-09-09T11:39:28+00:00

module: extend module_blacklist parameter to built-in modules

2026-09-09T06:32:19+00:00

Currently, the "module_blacklist=" command-line parameter only applies to loadable modules. If a module is built-in, the parameter is silently ignored. This patch extends the blacklisting functionality to built-in modules by intercepting their initialisation routines during early boot. To achieve this, we introduce a new ".initcall.modnames" memory section. For each built-in module, we use a standard C structure (i.e., struct initcall_modname) to map its initcall function pointer to its associated KBUILD_MODNAME string. This mapping is restricted only to files implementing built-in modules via module_init() to avoid mapping core kernel subsystems and save memory. During boot, built-in initcalls are executed sequentially via do_initcall_level() and do_pre_smp_initcalls(). We introduce a new wrapper function, do_one_initcall_builtin(), to cross-reference the initcall function pointer against the ".initcall.modnames" table. If a match is found and the module is present in the blacklist, the initcall is skipped. To make the blacklist functional on monolithic kernels, the command-line parameter parsing and the module_is_blacklisted() lookup function are decoupled from the loadable module subsystem and moved to init/main.c. This enables "module_blacklist=" to intercept built-in modules even on kernels built with CONFIG_MODULES=n. Link: https://lore.kernel.org/20260908203230.401020-3-atomlin@atomlin.com Signed-off-by: Aaron Tomlin Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Luis Chamberalin Cc: "Masami Hiramatsu (Google)" Cc: Miguel Ojeda Cc: Peter Zijlstra Cc: Petr Pavlu Cc: Sami Tolvanen Signed-off-by: Andrew Morton

rust: allow `unknown_lints` in generated bindings for Rust < 1.88

2026-09-08T21:29:18+00:00

Starting with bindgen 0.73.2 [1], `#[allow(unnecessary_transmutes)]` are used, even when `--rust-target 1.85` is passed. However, the lint was introduced in Rust 1.88.0. Thus building with older Rust versions warns like: error: unknown lint: `unnecessary_transmutes` --> rust/uapi/uapi_generated.rs:26294:13 | 26294 | #[allow(unnecessary_transmutes)] | ^^^^^^^^^^^^^^^^^^^^^^ | = note: `-D unknown-lints` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unknown_lints)]` Thus allow `unknown_lints` in the generated bindings -- only when building with older Rust versions. I have asked upstream if this is intentional [1], i.e. if we are supposed to always allow unknown lints in case `bindgen` uses such attributes, or whether it is an oversight. [ Emilio said it wasn't intentional -- we will work around it for now on the kernel side. - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Emilio Cobos Álvarez Link: https://github.com/rust-lang/rust-bindgen/pull/3455#issuecomment-5588526559 [1] Assisted-by: LLM Link: https://patch.msgid.link/20260908170539.345207-1-ojeda@kernel.org [ Removed the `cfg` for `allow(unnecessary_transmutes)` as suggested by Gary. - Miguel ] Signed-off-by: Miguel Ojeda

rust: Add dma_fence abstractions

2026-09-07T17:43:43+00:00

DMA fences are synchronisation primitives that will be needed by all Rust GPU drivers. The dma_fence framework sets a number of rules, notably: - fences must only be signaled once - all fences must be signaled at some point - fence error codes must only be set before signaling - every pointer to a fence must be backed by a reference All those rules are being addressed by these abstractions. To cleanly decouple fence issuers and consumers, two types are provided: - DriverFence: the only fence type that can be signaled and that carries driver-specific data. - Fence: the fence type to be shared with other drivers and / or userspace. The only type callbacks can be registered on. Cannot be signaled. Hereby, a Fence lives in the same chunk of memory as a DriverFence. Both share the refcount of the underlying C dma_fence. Since this implementation does not provide a custom dma_fence_backend_ops.release() function, the memory is freed by the dma_fence backend once the refcount drops to 0. To create a DriverFence, the user must first allocate a DriverFenceAllocation, so that the creation of the DriverFence later on can always succeed. Otherwise, deadlocks could occur if fences need to be created in a GPU job submission path. Synchronization is ensured by the dma_fence backend. All DriverFence's created through this abstraction must be signaled by the creator with an error code. In case a DriverFence drops without being signaled beforehand, it is signaled with -ECANCELLED as its error and a warning is printed. This allows the Rust abstraction to very cleanly decouple fence issuer and consumer by relying on the decoupling mechanisms in the C backend, which ensures through RCU and the 'signaled' fence-flag that dma_fence_backend_ops functions cannot access the potentially unloaded driver code anymore. Signalling fences on drop thus grants many advantages. Not signaling fences on drop would risk deadlock and does not grant real advantages: By definition only the drivers can ensure that a fence always represents the hardware's state correctly. This implementation models a DmaFenceContext object on which fences are to be created, thereby ensuring correct sequence numbering according to the timeline. dma_fence supports a variety of callbacks. The mandatory callbacks (get_timeline_name() and get_driver_name()) are implemented in this patch. For convenience, they store those name parameters in the fence context, saving the driver from implementing these two callbacks. Support for other callbacks (like for hardware signaling) is prepared for through the fact that both DriverFence and Fence live in the same allocation, allowing for usage of container_of from the callback to access the driver-specific data. It is expected that other callbacks, added in the future, also mostly operate on the generic data in the FenceContext. To make this safe, the implementation ensures through a lifetime that a DriverFence cannot outlive its FenceContext. Synchronization for dma_fence_ops callbacks is ensured by only running the Rust deconstructor delayed with call_rcu(), which prevents UAF-bugs should a DriverFence drop while a Fence callback is currently operating on the associated driver data. Since they can also operate on the FenceContext's data, its drop implementation also performs the necessary delay with rcu_barrier(). An additional issue discovered during the review process of this code is that there is (currently) no mechanism in Rust to prevent someone from circumventing the DriverFence's FenceContext-reference's lifetime by "forgetting" the fence, e.g. with core::mem::forget(). This would enable UAF bugs on the FenceContext. Throw a panic if this happens and document a path towards a more robust solution. Add abstractions for dma_fence in Rust. Signed-off-by: Philipp Stanner Tested-by: Daniel Almeida Reviewed-by: Daniel Almeida Link: https://patch.msgid.link/20260905085343.1827305-3-phasta@kernel.org [ In dma_fence_callback(), split combined unsafe block into separate blocks for container_of!() and pointer dereference. - Danilo ] Signed-off-by: Danilo Krummrich

rust: allow `clippy::as_underscore` in the generated bindings

2026-09-06T23:06:23+00:00

A CLIPPY=1 build emitted about 15000 `as _` conversion warnings, all of them in bindgen's generated output and none in hand-written code. [ The lint messages look like: error: using `as _` conversion --> rust/bindings/bindings_generated.rs:18947:9 | 18947 | self._bitfield_1.get_const::<0usize, 16u8>() as u32 as _ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- | | | help: consider giving the type explicitly: `u32` | = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.98.0/index.html#as_underscore = note: `-D clippy::as-underscore` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::as_underscore)]` - Miguel ] bindgen 0.73 returns each bitfield read through a trailing `as _`, and 0.72 returns it through a transmute, which the lint ignores. The bindings and uapi crates allow `clippy::all` over the generated code. That group does not cover `clippy::as_underscore`, a restriction lint. Allow `clippy::as_underscore` by name in the bindings and uapi crates. Assisted-by: LLM Signed-off-by: John Hubbard Link: https://patch.msgid.link/20260906215822.1201022-1-jhubbard@nvidia.com Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). [ Removed CI sentence. - Miguel ] Signed-off-by: Miguel Ojeda

Merge tag 'char-misc-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2026-08-25T16:38:50+00:00

Pull char/misc/IIO/etc driver updates from Greg KH: "Here is the big set of char, misc, iio, counter, fpga, and other small driver subsystems for 7.3-rc1. Overall, due to some driver removals we only added a bit more code than removed, which was a nice change. Highlights in this merge request are: - Loads of IIO driver updates and additions - binder driver updates (more on that below...) - Removal of the SGI XP and GRU drivers as they are not used anymore and turn out to be pretty insecure overall - Removal of the obsolete ibmasm driver as it's not being used anymore - Coresight driver updates and additions - Mei driver udpates - Counter driver updates - FPGA driver updates - ICC driver updates - lots and lots of other tiny driver updates to resolve reported issues All of these have been in linux-next for a while" * tag 'char-misc-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (513 commits) iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF iio: adc: pac1921: fix wrong channel used in trigger handler read iio: light: gp2ap002: re-enable irq if runtime suspend fails iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes iio: light: apds9306: fix PM reference leak in apds9306_read_data() iio: gyro: mpu3050: fix sign of raw angular velocity readings iio: srf04: fix pm_runtime handling on probe error path iio: adc: ad4080: configure backend data size iio: adc: adi-axi-adc: add data size support for AD408X backend iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable iio: dac: ad5446: fix OF module device table iio: light: opt4001: Fix reversed GENMASK() arguments in fault count mask iio: light: opt4001: Reject integration times with a non-zero seconds part iio: light: opt4001: Fix incompatible pointer type passed to div_u64_rem() iio: light: opt4001: Fix power down clearing bits of the wrong register iio: light: opt4060: Fix incorrect register name in threshold read error message iio: light: opt4060: Fix pointer type passed to div_u64_rem() iio: light: opt4060: Reject integration times with a non-zero seconds part iio: light: ltrf216a: fix runtime PM reference leak in error path iio: pressure: dps310: fix NULL pointer dereference on ACPI probe ...

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

2026-08-19T19:51:36+00:00

Pull fwctl updates from Jason Gunthorpe: - Support more commands in bnxt, this completes what they originally wanted to do - Rust bindings for fwctl. The Nova GPU is expected to use them next cycle * tag 'for-linus-fwctl' of git://git.kernel.org/pub/scm/linux/kernel/git/fwctl/fwctl: rust: introduce abstractions for fwctl fwctl/bnxt: Add DMA buffer support for HWRM commands bnxt_en: Update bnxt firmware spec

rust: introduce abstractions for fwctl

2026-08-14T22:21:17+00:00

Introduce safe Rust wrappers around struct fwctl_device and struct fwctl_uctx. This lets Rust drivers register fwctl devices and implement firmware RPC callbacks through a typed trait interface. The abstraction keeps lifetime and reference-count handling inside the wrapper, exposes pinned per-FD user contexts to drivers, and validates the layout assumptions required by the C fwctl allocation model. Allocation sizes are padded so the kmalloc-backed C allocations also satisfy Rust alignment requirements. Registration owns driver private data with a lifetime tied to the bound parent device and verifies the parent identity before registration. Callbacks access that data through a higher-ranked closure, preventing its erased lifetime from escaping, while Device remains only the refcounted fwctl object. This avoids requiring Rust drop glue from the fwctl_device release path after unregister or module teardown. RPC callbacks receive typed scope information, a mutable request/response buffer, and the userspace output-buffer size. Response pointer conversion, length validation, and raw output-length handling remain inside the abstraction. Add the Rust sources to the FWCTL MAINTAINERS entry and add myself as the maintainer for the Rust abstractions. Link: https://patch.msgid.link/r/20260813152312.1311142-2-zhiw@nvidia.com Co-developed-by: Danilo Krummrich Signed-off-by: Danilo Krummrich Signed-off-by: Zhi Wang Reviewed-by: Alexandre Courbot Signed-off-by: Jason Gunthorpe

Merge tag 'v7.2-rc7' into driver-core-next

2026-08-09T23:20:05+00:00

We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich