summaryrefslogtreecommitdiff
path: root/rust
AgeCommit message (Collapse)Author
2026-10-02rust: scatterlist: return u32 from SGEntry::dma_len()Lorenzo Delgado
`SGEntry::dma_len()` returns `ResourceSize`, but the length of a DMA segment is not the size of a resource. The C side stores it as an `unsigned int` (`dma_length` in `struct scatterlist`), the helper returns `unsigned int`, and a single segment is bounded by the device's `max_segment_size`, which is an `unsigned int` as well. The method only widens the value to `resource_size_t`. Return `u32`, which is what the binding already produces, and drop the `.into()` along with its `clippy::useless_conversion` allow. Tyr widens the length to `u64`, which is now a real conversion on every architecture, so drop its `useless_conversion` allow too. nova-core converts it to `usize` through `FromSafeCast`, which already covers `u32`, so it needs no change. Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/DLNPXJ4WPH4L.2MBUGV1TAESYY@kernel.org Signed-off-by: Lorenzo Delgado <lnsdev@proton.me> Link: https://patch.msgid.link/20260927-resource-size-newtype-v4-1-447a08af23fb@proton.me Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-10-01rust: bitfield: remove unnecessary `#[allow]`Gary Guo
The `#[allow(non_camel_case_types)]` was there because register names can be commonly SCREAMING_CASE and thus not CamelCase. However, when a bitfield type is created by itself, this justification does not apply. Thus, remove it. Users that want to use non-standard styles can add the `#[allow]` themselves. For example, the invocation of `bitfield!` inside `register!` macro carry this annotation. Signed-off-by: Gary Guo <gary@garyguo.net> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260910170542.92010-1-gary@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-10-01rust: bug: add a KUnit test for warn_on!FUJITA Tomonori
The test runs warn_on!(false) and warn_on!(true) inside a KUnit warning suppression block, then checks that one warning was counted. The counter is incremented by the kernel warning path, not by warn_on! itself, so a count of one means the warning was really reported. warn_flags! has a different definition per architecture. The test does not look at any of them, so it runs on every architecture that supports Rust. The new CONFIG_RUST_BUG_KUNIT_TEST depends on BUG. With CONFIG_BUG=n, warn_on! does nothing and no warning is counted. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://patch.msgid.link/20260916140952.3290924-1-tomo@flapping.org [ Added newlines for clarity. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-10-01rust: bug: pass TAINT_WARN to warn_slowpath_fmt() on UMLFUJITA Tomonori
On UML, `warn_flags!` calls `warn_slowpath_fmt()` directly. Its third argument is a taint number, but `warn_on!` passes its bug flags there. As a result, `add_taint()` gets 2304 instead of 9 (`TAINT_WARN`). The warning is not recorded: `/proc/sys/kernel/tainted` stays 0 after `warn_on!` fires, where it should be 512. It also causes an out-of-bounds write in `add_taint()`. Pass `TAINT_WARN` directly, as C does on UML. Cc: stable@vger.kernel.org Fixes: dff64b072708 ("rust: Add warn_on macro") Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://patch.msgid.link/20261001123103.2198104-1-tomo@flapping.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-10-01rust: macros: allow non-ASCII characters in `authors`Thiébaud Weksteen
Module authors may have non-ASCII characters in their names. In C, `MODULE_AUTHOR` allows arbitrary string literals which are emitted as raw UTF-8 bytes into the `.modinfo` section, and multiple in-tree modules use non-ASCII author names. Originally, the single `author` field permitted arbitrary string literals including non-ASCII characters. When support for multiple authors was introduced in commit 38559da6afb2 ("rust: module: introduce `authors` key"), it reused the `expect_string_array` helper that had originally been added for module aliases. Because that helper enforced an ASCII check, `authors` inadvertently became restricted to ASCII-only string literals. Later, when the macro parsing was rewritten to use `syn` in commit c578ad703ae9 ("rust: macros: use `syn` to parse `module!` macro"), this restriction was carried over by using AsciiLitStr in `authors` type. Change the element type of `authors` in `ModuleInfo` from `AsciiLitStr` to `LitStr` so that UTF-8 author names are permitted. Fixes: 38559da6afb2 ("rust: module: introduce `authors` key") Signed-off-by: Thiébaud Weksteen <tweek@google.com> Acked-by: Petr Pavlu <petr.pavlu@suse.com> Link: https://patch.msgid.link/20260917051147.98775-1-tweek@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-10-01Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.3-rc6). Conflicts: net/mac80211/tx.c net/mac80211/ieee80211_i.h 8effab902fa34 ("wifi: mac80211: prevent AP VLAN tx from other interfaces") 78b843974fb83 ("wifi: mac80211: report multicast transmission from lookup_ra_sta()") https://lore.kernel.org/arJmcuhpJ69wAvYK@sirena.co.uk drivers/net/ethernet/realtek/r8169_main.c 3cdeaef1754ab ("r8169: disable EEE on RTL8168h/8111h") 8a3c76523e449 ("r8169: add support for phylink") https://lore.kernel.org/ar5vAxEqS8tO8aVT@sirena.org.uk Adjacent changes: rust/kernel/net/netlink.rs 5e5916923759 ("rust: net: netlink: Migrate to zerocopy's IntoBytes") 0923198be4ae ("rust: net: netlink: validate attribute length before casting to `c_int`") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-10-01rust: block: implement `Send` and `Sync` for `TagSet`Andreas Hindborg
`TagSet` never implemented `Send` or `Sync`. This did not matter until commit "rust: block: fix `Send` bound for `GenDisk`" made `GenDisk: Send` depend on `Arc<TagSet<T>>: Send`, which in turn requires `TagSet<T>: Send + Sync`. With that bound unsatisfiable, `GenDisk` is never `Send`, and the rnull driver fails to build once configfs requires `GroupOperations::Child: Send`. `TagSet` owns no data typed by `T`. It only wraps the C `struct blk_mq_tag_set`, which can be dropped from any thread by calling `blk_mq_free_tag_set`. Thus, implement `Send` and `Sync` for `TagSet` unconditionally. Reported-by: Thorsten Leemhuis <linux@leemhuis.info> Closes: https://lore.kernel.org/r/d1381ed8-eab8-4fd7-8b15-1e94876d7099@leemhuis.info Suggested-by: Gary Guo <gary@garyguo.net> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Thorsten Leemhuis <linux@leemhuis.info> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260930-tag-set-send-sync-v1-1-51acdb36f4bb@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-30rust: proc-macro2: enable `proc_macro_span` featureGary Guo
The `Span::join` function is very important in generating useful diagnostics. When invoking `syn::Spanned::span`, it attempts to return an overall span that covers the whole expression. If the `join` function is unavailable, however, only the span of the first token is generated. This causes worse diagnostics quality for all macros, notably pin-init, when compared to the pin-init's own diagnostics test suite with the feature enabled. For example, this diagnostic covers only part of the text where replacement is suggested: error: expected nothing or `..Zeroable::init_zeroed()`. --> tests/ui/compile-fail/zeroable/invalid_spread.rs:15:11 | 15 | ..MyZeroable::init_zeroed() | ^^^^^^^^^^ In the upcoming pin-init self-reference series, spans of full types or expressions are used quite heavily to make diagnostics not confusing. Thus, enable the `proc_macro_span` feature. This does make use of the unstable `Span::join` function, but this is for producing diagnostics only, so we do not have a hard reliance on the feature. A very small tweak of proc-macro2 vendored code is needed to make the code compile for 1.85. Link: https://github.com/rust-lang/rust/issues/54725 Link: https://github.com/dtolnay/proc-macro2/pull/542 Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://patch.msgid.link/20260921115708.4009754-1-gary@kernel.org/ [ Updated example diagnostics, removed unused PathBuf import. - Gary ] Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-30rust: pin-init: internal: init: use span of `<-` or `:` for the init/write call.Gary Guo
Currently we use the full span of the field initializer as the span of the generated init call. This produces overlapping spans for type mismatch errors, which is hard to read. Use the span of `<-` or `:` for the method name, which wll cause type mismatch errors or trait bound not implemented error to be appear from the `<-` or `:` token, which declutter the output a bit and make it easier to read. Before the change: error[E0277]: `impl pin_init::PinInit<Bar>` cannot be used to movably initialize `Bar` with error `_` --> tests/ui/compile-fail/init/invalid_init.rs:19:16 | 19 | bar <- Bar::new(), | -------^^^^^^^^^^ | | | | | the trait `Init<Bar, _>` is not implemented for `impl pin_init::PinInit<Bar>` | required by a bound introduced by this call | = note: if your type implements `PinInit` but not `Init`, you might be forgetting a `#[pin]` annotation on fields After the change: error[E0277]: `impl pin_init::PinInit<Bar>` cannot be used to movably initialize `Bar` with error `_` --> tests/ui/compile-fail/init/invalid_init.rs:19:16 | 19 | bar <- Bar::new(), | -- ^^^^^^^^^^ the trait `Init<Bar, _>` is not implemented for `impl pin_init::PinInit<Bar>` | | | required by a bound introduced by this call | = note: if your type implements `PinInit` but not `Init`, you might be forgetting a `#[pin]` annotation on fields Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://patch.msgid.link/20260928-dev-pin-init-sync-v1-3-e591c8e9cf0e@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-30rust: pin-init: internal: init: improve diagnostics from field checksGary Guo
Use span of the field name for generated alignment and field duplication checks. This avoids pointing diagnostics to the full macro invocation, but just the part of it going wrong. Before the change: error[E0062]: field `0` specified more than once --> tests/ui/compile-fail/init/tuple_duplicate_field.rs:7:37 | 7 | let _ = pin_init!(Tuple { 0: 1, 0: 2, 1: 3 }); | ------------------------^------------ | | | | | used more than once | first use of `0` After the change: error[E0062]: field `0` specified more than once --> tests/ui/compile-fail/init/tuple_duplicate_field.rs:7:37 | 7 | let _ = pin_init!(Tuple { 0: 1, 0: 2, 1: 3 }); | - ^ used more than once | | | first use of `0` Link: https://patch.msgid.link/20260928-dev-pin-init-sync-v1-2-e591c8e9cf0e@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-30rust: pin-init: internal: init: allow reborrow of `Pin<&mut T>` bindingsGary Guo
Use `let mut` for created bindings of initialized field, so `Pin<&mut T>` bindings may be reborrowed in subsequent initializers or code blocks. Without `let mut`, attempt to reborrow can produce error (and also a confusing fix): error[E0596]: cannot borrow `gpu` as mutable, as it is not declared as mutable --> drivers/gpu/nova-core/driver.rs:129:17 | 129 | gpu.as_mut().run_selftests(pdev); | ^^^ cannot borrow as mutable | help: consider changing this to be mutable | 119 | mut gpu <- Gpu::new( | +++ error: aborting due to 1 previous error Reported-by: Danilo Krummrich <dakr@kernel.org> Closes: https://lore.kernel.org/nova-gpu/DLQXWXRP3P1J.28SLFOJJQ2EDK@kernel.org/ Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260928-dev-pin-init-sync-v1-1-e591c8e9cf0e@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-30rust: bindings: fix `VM_MAYSHARE` blocklist entryMiguel Ojeda
Commit 2b6a3f061f11 ("mm: declare VMA flags by bit") added constant helpers for the VMA flags and blocklist entries to suppress their direct bindings. However, it listed `VM_MAYEXEC` twice and omitted `VM_MAYSHARE`. Thus fix it. Fixes: 2b6a3f061f11 ("mm: declare VMA flags by bit") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Vishal Moola (Fractile) <vishal.moola@gmail.com> Link: https://patch.msgid.link/20260930123645.302318-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-09-30rust: bindings: fix VM_MAYSHARE valueLorenzo Stoakes
Commit 2b6a3f061f11 ("mm: declare VMA flags by bit") added a number of overrides to the rust bindings helper as the change performed in the commit caused rust bindgen to not be able to automatically determine values of VMA flags. However a typo was introduced leaving VM_MAYSHARE to be incorrectly interpreted as VM_MAYEXEC in rust code. This patch fixes the typo. Fixes: 2b6a3f061f11 ("mm: declare VMA flags by bit") Reported-by: Chris Mason <clm@meta.com> Closes: https://lore.kernel.org/all/20260113185142.254821-1-clm@meta.com/ Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: wang lian <lianux.mm@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260113192949.689834-1-lorenzo.stoakes@oracle.com [ Reworded to improve title and to fix typo. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-09-29rust: alloc: add `NumaNode::id()` accessorAndreas Hindborg
`NumaNode` wraps an `i32` but offers no way to read it back. Add a trivial `id()` getter so callers that need to pass the node id to a C binding can recover the underlying `c_int` without reaching into the private field. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260929-numa-node-id-v2-1-fdd2c0a49412@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-29rust: alloc: allow different error types in `KBox::pin_slice`Andreas Hindborg
Previously, `KBox::pin_slice` required the initializer error type to match the return error type via `E: From<AllocError>`. This prevented using infallible initializers like `new_mutex!` inside `pin_slice`, because `Infallible` does not implement `From<AllocError>`. Introduce a separate type parameter `E2` for the initializer error type and require `E: From<AllocError>` and `E: From<E2>` instead. This allows the initializer to return a different error type that can be converted into the final error type, enabling use of infallible pin initializers in fallible allocation contexts. Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/.E2.9C.94.20Constructing.20Mutex.20from.20PinInit.3CT.2C.20Error.3E Co-developed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260605-pin-slice-init-v2-1-b197e84040ba@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-29rust: block: require `Sync` for `Operations::QueueData`Andreas Hindborg
The queue data installed in a `GenDisk` is stored in the request queue and handed back to the driver as a shared borrow through the `queue_rq` and `commit_rqs` callbacks. Both callbacks obtain that borrow via `ForeignOwnable::borrow` and may execute concurrently on several CPUs, since the block layer runs one hardware queue per CPU. That means a shared reference to the same queue data can be live on multiple threads at once, which is only sound when the referent is `Sync`. The initial `GenDisk` private data support omitted this bound, so a driver could install a non-`Sync` type as queue data and then access it concurrently from multiple CPUs without synchronization. Add a `Sync` bound to the `QueueData` associated type to rule that out. Fixes: 90d952fac8ac ("rust: block: add `GenDisk` private data support") Cc: stable@vger.kernel.org Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://msgid.link/20260608-queue-data-sync-v1-1-0efff051aaf3@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-9-642a4c1aebd7@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-29rust: block: Fix GenDiskBuilder block size documentationSophon Z
GenDiskBuilder::validate_block_size() accepts powers of two from 512 through PAGE_SIZE, but the documentation for logical_block_size() and physical_block_size() states that the maximum is 4096. Use PAGE_SIZE for both documented upper bounds so that the documentation matches validation on architectures with larger page sizes. Signed-off-by: Sophon Z <aiqubits@hotmail.com> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://msgid.link/20260831-fix-gendisk-block-size-docs-v1-1-900546005799@hotmail.com Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-6-642a4c1aebd7@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-29rust: block: gen_disk: set fops.owner from driver module pointerAlvin Sun
Set `fops.owner` from the driver module pointer via `this_module::<T::OwnerModule>().as_ptr()` instead of defaulting to null, so the module cannot be unloaded while a block device is still in use. Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://msgid.link/20260811-fix-gendisk-owner-v1-1-c0fe4a449ecb@linux.dev Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-5-642a4c1aebd7@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-29rust: block: fix `Send` bound for `GenDisk`Andreas Hindborg
The `Send` implementation for `GenDisk<T>` was conditioned on `T: Send`. This constrains the wrong type. `T` is the `Operations` implementation, which is typically a zero-sized marker type that carries no data, so `T: Send` says nothing about whether the data a `GenDisk` actually owns can be moved to another thread. A `GenDisk<T>` owns the queue data `T::QueueData` (stored as the `gendisk`'s `queuedata` and dropped when the `GenDisk` is dropped) and an `Arc<TagSet<T>>`. These are the values transferred when a `GenDisk` is sent across a thread boundary, so the `Send` bound must constrain exactly them. Bound `T::QueueData: Send` and `Arc<TagSet<T>>: Send` instead. Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Cc: stable@vger.kernel.org Reported-by: Priya Bala Govindasamy <pgovind2@uci.edu>, Dylan Zueck <dzueck@uci.edu>, Yuan Tan <ytan089@ucr.edu> Closes: https://lore.kernel.org/all/cover.1780633578.git.ytan089@ucr.edu Signed-off-by: Yuan Tan <ytan089@ucr.edu> Link: https://msgid.link/20260709100100.604252-1-yuantan098@gmail.com [ Andreas: Fix tags to make checkpatch happy. Change summary line. ] Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-4-642a4c1aebd7@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-29rust: block: mq: remove redundant imports and formatAlvin Sun
Drop `Result`, `Pin`, `pin_data`, `pinned_drop`, `PinInit`, and `try_pin_init` imports already provided by `kernel::prelude`. Simplify `error` imports and flatten parameters formatting. Reviewed-by: Onur Özkan <work@onurozkan.dev> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://msgid.link/20260521-miscdev-use-format-v3-5-56240ca70d0c@linux.dev Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-2-642a4c1aebd7@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-29rust: block: mq: use vertical import styleAlvin Sun
Convert `use` imports to vertical layout for better readability and maintainability. Reviewed-by: Onur Özkan <work@onurozkan.dev> Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Link: https://msgid.link/20260521-miscdev-use-format-v3-4-56240ca70d0c@linux.dev Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-1-642a4c1aebd7@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-29rust: net: netlink: validate attribute length before casting to `c_int`Sagar Taunk
`put()` trusted an unchecked `as` cast from `usize` to `c_int`. When the length exceeds `i32::MAX` that cast wraps around to a negative value. This ultimately resulted in a kernel panic when the reinterpreted value via `__nla_reserve()` and `skb_put()` became enormous. Validate payload and header both fit together in a `u16`, rejecting any payload that wouldn't leave room for `NLA_HDRLEN`. Fixes: 5eaa5fbb6e6c ("rust: netlink: add raw netlink abstraction") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Carlos Llamas <cmllamas@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Sagar Taunk <sagartaunk@proton.me> Link: https://patch.msgid.link/20260925085449.22553-1-sagartaunk@proton.me Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-09-29rust: configfs: fix data offset calculation for subsystem callbacksAndreas Hindborg
`get_group_data()` chooses between `Group::<Parent>::container_of()` and `Subsystem::<Parent>::container_of()` based on whether `this` represents the root group of a configfs subsystem. It detects this by checking `(*this).cg_subsys.is_null()`, but `link_group()` in `fs/configfs/dir.c` unconditionally sets `cg_subsys` for every `config_group` attached anywhere in a registered subsystem, including the subsystem's own `su_group`. The only `config_group` with a NULL `cg_subsys` is the configfs root, on which userspace cannot trigger callbacks. The check is therefore always false at runtime, and the `Subsystem` branch is dead. Subsystem-level callbacks reach the `Group` branch and may read `data` at the wrong offset. Thus change the `is_root` check to correctly identify whether a group is a root group by comparing `this` to `subsys.su_group`. Cc: stable@vger.kernel.org Fixes: 446cafc295bf ("rust: configfs: introduce rust support for configfs") Link: https://msgid.link/20260608-configfs-fix-offset-v1-1-7f01b8fb9e5f@kernel.org [ Andreas: Fix clippy warning on 1.85.0 by moving safety comment. ] Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-09-29rust: hrtimer: document handle based design rationaleAndreas Hindborg
Add implementation notes explaining why the hrtimer abstraction uses a handle based approach. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun@kernel.org> Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://msgid.link/20260215-hrtimer-docs-v1-1-bff6a6c0d923@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-09-28rust: time: add Delta::to_jiffies_timeout() for timeout conversionFUJITA Tomonori
The boundaries of __msecs_to_jiffies() and nsecs_to_jiffies64() depend on which HZ branch is compiled. With CONFIG_HZ_300 nsecs_to_jiffies64() overflows after 64.99 years, which is less than the 292 years a Delta can hold. With HZ=1000 a jiffy is a millisecond, so __msecs_to_jiffies() returns its argument unchanged and never caps it at MAX_JIFFY_OFFSET. Compute the conversion in Rust with mul_u64_add_u64_div_u64() instead. It returns (a * b + c) / d, computing a * b internally in 128 bits, so ceil(nanos * HZ / NSEC_PER_SEC) needs no input clamp and rounds once. The bound then follows from the arithmetic: with HZ <= NSEC_PER_SEC, which a static_assert() checks, the result is at most the nanosecond count. Unless the result saturates, the value is rounded up, so the timeout is never shorter than the requested span. It saturates at zero jiffies for a negative span, i.e. an immediate timeout, and at MAX_JIFFY_OFFSET, the upper bound the kernel uses for a jiffies span. Since MAX_JIFFY_OFFSET is derived from long, only 32 bit can reach it, and a saturated timeout there is finite, so it can be shorter than the requested span. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://msgid.link/20260924232530.446588-3-tomo@flapping.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-09-28rust: bindings: set HZ to CONFIG_HZFUJITA Tomonori
include/uapi/asm-generic/param.h defines HZ as __USER_HZ and include/asm-generic/param.h then sets it to CONFIG_HZ. bindgen keeps the first definition of a macro and ignores a later #undef, so the generated binding is __USER_HZ. Redefine HZ in rust/bindings/lib.rs, the same way compat_ptr_ioctl is redefined there. Nothing in the tree reads bindings::HZ today, so this prevents accidental misuse rather than fixing a bug. Suggested-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://msgid.link/20260924232530.446588-2-tomo@flapping.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-09-28rust: configfs: require thread-safe callback dataYilin Chen
The Rust configfs abstractions do not fully constrain callback data for cross-thread use. Add the missing `Send` and `Sync` requirements. Specifically, make the following changes: 1. Require `Data: Send` when implementing `Send` for `Subsystem<Data>`, since the subsystem stores its data by value. 2. Make `GroupOperations` a `Sync` supertrait because `make_group` and `drop_item` receive `&self` from foreign threads. Require `Child: Send` because configfs may release child groups on an arbitrary thread. 3. Require `AttributeOperations::Data: Sync` because its callbacks receive `&Data` from foreign threads. 4. Update the safety comments in FFI callbacks that call `get_group_data` to cite these bounds as justification for sharing the returned references with the callback thread. 5. Remove redundant `Child: 'static` bounds from `GroupOperationsVTable` and `new_with_child_ctor`. Fixes: 446cafc295bf ("rust: configfs: introduce rust support for configfs") Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Should.20add.20Data.3A.20Send.2FSync.20bounds.20in.20configfs.3A.3ASubsystem.3F/with/623719979 Assisted-by: Gpt-5.6 Sol Signed-off-by: Yilin Chen <1479826151@qq.com> Link: https://msgid.link/tencent_5449081195EDDF5726C709CF648DD4044A08@qq.com [ Andreas: Add Send/Sync bounds for `Group<Data>`, add `Send` bounds to `GroupOperationsVTable`, `ItemOperationsVTable` and `ItemType` macro implementation. ] Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-09-28rust: pin-init: internal: improve diagnostics robustness against panickingGary Guo
Currently, if proc macro panicked, the diagnostics clean up is not executed, and further invocation will cause the "DiagCtxt cannot be nested" error. While we should aim to have no panics inside proc macros, producing a sensible diagnostics message even when macro panicked is very useful for developing. Thus, catch proc macro panics and convert them to errors, and emit them together with all diagnostics accumulated so far. Ideally we would like panic location w/ line numbers being available as well; however this is not currently implementable without overriding the global panic hook. Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://patch.msgid.link/20260923140618.1978181-3-gary@kernel.org Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-28rust: pin-init: internal: make `DiagCtxt` available inside parserGary Guo
Currently, there is a split between `syn::Error` and pin-init's custom `DiagCtxt`. Parsing has no access to `DiagCtxt` and therefore cannot report diagnostics without failing the parse. Bridge the gap by making the `DiagCtxt` available inside parsers using `thread_local!`. `parse_macro_input!` returns error as token stream directly, so it is no longer suitable when the parsing is moved inside `DiagCtxt` closure. Add a `From<syn::Error> for ErrorGuaranteed` implementation so `?` can be used to add a `syn::Error` into the current diagnostic context and obtain a `ErrorGuaranteed`. Clean up the handler of using `<-` inside tuple expression as a demonstration of the usefulness of having `DiagCtxt` access inside `Parse`. Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://patch.msgid.link/20260923140618.1978181-2-gary@kernel.org Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-28rust: pin-init: internal: handle item and expr diagnostics differentlyGary Guo
Currently `DiagCtxt` is used to allow error recovery in the pin-init macros, by generating both a `compile_error!()` macro item and continue expansion, and then merge token streams together. This works very well for items, however for expressions, this will produce invalid expression and result in a confusing error message. error: macro expansion ignores `::` and any tokens following --> tests/ui/compile-fail/zeroable/invalid_spread.rs:15:9 | 13 | let _ = init!(Foo { | _____________- 14 | | a: 0, 15 | | ..MyZeroable::init_zeroed() | | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 16 | | }); | |______- caused by the macro expansion here | = note: the usage of `init!` is likely invalid in expression context Fix this by wrap the concatenated diagnostics in a block, with the generated expression in its tail position. This results in the desired error message. error: expected nothing or `..Zeroable::init_zeroed()`. --> tests/ui/compile-fail/zeroable/invalid_spread.rs:15:9 | 15 | ..MyZeroable::init_zeroed() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://patch.msgid.link/20260923140618.1978181-1-gary@kernel.org Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-28Merge tag 'v7.3-rc5' into driver-core-nextDanilo Krummrich
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-27rust: uaccess: add UserSliceWriter::write_truncated()Alistair Popple
Add a helper that writes as much of an AsBytes value as fits in the remaining userspace buffer and returns the number of bytes copied. This avoids requiring callers of versioned UAPIs to convert values to byte slices and truncate them manually. Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/nova-gpu/DKC6T1DQX2L3.HTHPB2L167TC@kernel.org/ Signed-off-by: Alistair Popple <apopple@nvidia.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://patch.msgid.link/20260909064506.910162-7-apopple@nvidia.com [ Inline write_slice_partial() and use it to simplify write_truncated(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-27rust: auxiliary: let registration_data_with() closures return covariant ↵Alistair Popple
sub-fields The closure passed to registration_data_with() currently receives `Pin<&'a F::Of<'a>>` with `'a` universally quantified. This prevents the closure from returning references derived from the registration data, even for sub-fields that are covariant in their lifetime, because the compiler cannot relate `'a` to any lifetime the caller knows about. Tie the outer reference to the `&self` lifetime instead, i.e. pass `Pin<&'this F::Of<'a>>`. This gives the closure the implied bound `'a: 'this`, so covariant sub-fields such as `&'a T` can be coerced to `'this` and returned directly, while invariant fields still cannot be coerced and therefore cannot escape with an incorrect lifetime. This allows auxiliary child drivers to project covariant data out of invariant registration data without having to wrap every use in a closure. Link: https://lore.kernel.org/nova-gpu/DL3WPTVM033J.33RWYCZOC67Z1@kernel.org/ Suggested-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alistair Popple <apopple@nvidia.com> Link: https://patch.msgid.link/20260909064506.910162-2-apopple@nvidia.com Co-developed-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-25rust: pin-init: add diagnostic attribute for `PinInit` and `Init`Gary Guo
Give a slightly more useful error message when these traits are not implemented. Before this change: error[E0277]: the trait bound `impl pin_init::PinInit<Bar>: Init<Bar, _>` is not satisfied --> tests/ui/compile-fail/init/invalid_init.rs:19:16 | 19 | bar <- Bar::new(), | -------^^^^^^^^^^ | | | | | the trait `Init<Bar, _>` is not implemented for `impl pin_init::PinInit<Bar>` | required by a bound introduced by this call After this change: error[E0277]: `impl pin_init::PinInit<Bar>` cannot be used to movably initialize `Bar` with error `_` --> tests/ui/compile-fail/init/invalid_init.rs:19:16 | 19 | bar <- Bar::new(), | -------^^^^^^^^^^ | | | | | the trait `Init<Bar, _>` is not implemented for `impl pin_init::PinInit<Bar>` | required by a bound introduced by this call | = note: if your type implements `PinInit` but not `Init`, you might be forgetting a `#[pin]` annotation on fields Ideally, we would generate differnet message when `PinInit` is implemented but not `Init`; that is not feasible with today's `diagnostics::on_unimplemented` attribute. However, the added note is worth it because in `init!()` is more rarely used compared to `pin_init!()`; in most cases `Init` being unimplemented is the result of missing `#[pin]`. Link: https://patch.msgid.link/20260923-dev-pin-data-diag-v1-5-e4d7193569e5@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-25rust: pin-init: internal: add custom diagnostic when `#[pin_data]` is not ↵Gary Guo
implemented Produce a more helpful error message when `#[pin_data]` is omitted. The error message changes from error[E0277]: the trait bound `Foo: pin_init::__internal::HasPinData` is not satisfied --> tests/ui/compile-fail/init/missing_pin_data.rs:9:19 | 9 | pin_init!(Self { a: 42 }) | ^^^^ unsatisfied trait bound | help: the trait `pin_init::__internal::HasPinData` is not implemented for `Foo` --> tests/ui/compile-fail/init/missing_pin_data.rs:3:1 | 3 | struct Foo { | ^^^^^^^^^^ to error[E0277]: `Foo` cannot be used with `pin_init!` macro --> tests/ui/compile-fail/init/missing_pin_data.rs:9:19 | 9 | pin_init!(Self { a: 42 }) | ^^^^ unsatisfied trait bound | help: the trait `pin_init::__internal::HasPinData` is not implemented for `Foo` --> tests/ui/compile-fail/init/missing_pin_data.rs:3:1 | 3 | struct Foo { | ^^^^^^^^^^ = note: did you forget to add `#[pin_data]` attribute to the struct? Link: https://patch.msgid.link/20260923-dev-pin-data-diag-v1-4-e4d7193569e5@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-25rust: pin-init: internal: use `HasInitData` to provide inference help onlyGary Guo
Currently, type inference of the initialized type is done by use the function calling syntax `PATH::__pin_data` or `PATH::__init_data` to obtain the required init data type, without needing the user to explicitly mention all generics. Switch to always use `HasInitData::__init_data` to provide that inference, which will not produce method-not-found errors as it is always available. Change `__pin_data` to take `InitData<Self>` as the receiver, so for types that require `HasPinData`, `HasPinData::__pin_data(data)` can be used to obtain the needed type without having to mention the user-provided path again. The expanded code also uses the span of the type, so diagnostics will hint to user that the type is causing the issue. With this change, the error message when `HasPinData` is not implemented changes from error[E0599]: no associated function or constant named `__pin_data` found for struct `Foo` in the current scope --> tests/ui/compile-fail/init/missing_pin_data.rs:9:9 | 3 | struct Foo { | ---------- associated function or constant `__pin_data` not found for this struct ... 9 | pin_init!(Self { a: 42 }) | ^^^^^^^^^^^^^^^^^^^^^^^^^ associated function or constant not found in `Foo` | = help: items from traits can only be used if the trait is implemented and in scope = note: the following trait defines an item `__pin_data`, perhaps you need to implement it: candidate #1: `pin_init::__internal::HasPinData` to error[E0277]: the trait bound `Foo: pin_init::__internal::HasPinData` is not satisfied --> tests/ui/compile-fail/init/missing_pin_data.rs:9:19 | 9 | pin_init!(Self { a: 42 }) | ^^^^ unsatisfied trait bound | help: the trait `pin_init::__internal::HasPinData` is not implemented for `Foo` --> tests/ui/compile-fail/init/missing_pin_data.rs:3:1 | 3 | struct Foo { | ^^^^^^^^^^ Link: https://patch.msgid.link/20260923-dev-pin-data-diag-v1-3-e4d7193569e5@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-25rust: pin-init: internal: remove associated type of `HasInitData`Gary Guo
There is only a single implementation, the associated type is not necessary. Remove it, and rename `AllData` to `InitData` to be a more meaningful name. The single implementation also means that "unsafe" is redundant, so remove it as well. Link: https://patch.msgid.link/20260923-dev-pin-data-diag-v1-2-e4d7193569e5@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-25rust: pin-init: internal: make `__init_data` and `__pin_data` safeGary Guo
Remove the unsafe markers of `__init_data` and `__pin_data`. These methods are for inference help and does not need to be unsafe. The `HasInitData` cannot be implemented outside pin-init, so the `unsafe trait` marker is not necessary. Link: https://patch.msgid.link/20260923-dev-pin-data-diag-v1-1-e4d7193569e5@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-25rust: pin-init: internal: pin_data: use HRTB to work around `trivial_bounds` ↵Gary Guo
for `Unpin` `#[pin_data]` generates a `Unpin` implementation for the user, which requires reasoning using field types. This is rejected by rustc as "trivial bounds", which can only be specified using the `#![feature(trivial_bounds)]`. Currently we use an extra lifetime in `__Unpin` to work around this; use HRTB to introduce a dummy lifetime can achieve the same, which the `Zeroable` implementation already uses. Unify the `Unpin` impl to also use the same HRTB trick that `Zeroable` uses. This produces slightly better error message and slightly shorter expansion. Link: https://patch.msgid.link/20260922211320.1390159-1-gary@kernel.org Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-24rust: scatterlist: honor the device's maximum segment sizeMatteo Kloiber
SGTable::new() caps segment length at dma_max_mapping_size() only, which limits the DMA mapping path (e.g. swiotlb), not the device itself. The per-device limit from dma_set_max_seg_size() is ignored, so contiguous page segments can be longer than the declared max segment size, potentially causing problems for future drivers that use this abstraction. Fixes: 05aa6fb1c21d ("rust: scatterlist: Add abstraction for sg_table") Signed-off-by: Matteo Kloiber <kernel@matt3o12.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260913210828.125655-3-kernel@matt3o12.de Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-23rust: clk: document overflow panics in `Hertz` constructorsGeorgios Androutsopoulos
`Hertz::from_khz()`, `from_mhz()` and `from_ghz()` multiply their argument by 1_000, 1_000_000 and 1_000_000_000 respectively without checking for overflow. When `CONFIG_RUST_OVERFLOW_CHECKS` is enabled, each panics once its argument exceeds `c_ulong::MAX` divided by that factor. None of the three documents this. The panic occurs only at runtime, when the argument is not a constant expression. Add the missing `# Panics` sections stating the bound for each unit. Fixes: d01d70205601 ("rust: clk: Add initial abstractions") Signed-off-by: Georgios Androutsopoulos <georgeandrout13@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-09-22rust: time: rename ClockSource trait to ClockIdFUJITA Tomonori
The `ClockSource` trait has nothing to do with the C `struct clocksource` in `include/linux/clocksource.h`, which abstracts the hardware counter used as a source of time for the majority of the clockids. The trait instead carries a `clockid_t` `ID`, i.e. one of the IDs of "the various system clocks (for POSIX.1b interval timers)" as described in include/uapi/linux/time.h (CLOCK_MONOTONIC, CLOCK_REALTIME, ...). It thus plays the role of a `clockid_t`, and the `ClockSource` name overlaps confusingly with the C `clocksource` concept when reading across C and Rust code. Rename the trait to `ClockId` to reflect that it represents a `clockid_t`. This is a pure rename; there is no functional change. Suggested-by: John Stultz <jstultz@google.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://lore.kernel.org/rust-for-linux/CANDhNCrKMdHCmL76LWCROVF2Ly-9NxmfmQ2T+P=iv34aVkO2uQ@mail.gmail.com/ Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://msgid.link/20260722001050.4115708-1-tomo@flapping.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-09-22rust: configfs: fix release safety documentationYilin Chen
ItemOperationsVTable<Group<Data>, Data>::release() receives a pointer to a config_item, not a config_group. The old Safety docs described the pointer as a config_group embedded in Group<Parent>. Update them to state that the pointer must be the cg_item field of a config_group embedded in a valid Group<Data>. Assisted-by: Codex:GPT-5 Signed-off-by: Yilin Chen <1479826151@qq.com> Link: https://msgid.link/tencent_9FAFC60382D724C608F0F6BFABFC63BB6707@qq.com Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-09-22rust: time: warn and assert out-of-range input in fsleep() and udelay()Sang-Heon Jeon
fsleep() documents out-of-range input as a bug but does not check it, unlike udelay(). Add `debug_assert!` calls to catch it in debug builds. Also add `pr_warn_once!` calls in both fsleep() and udelay() so the clamped path is observable at runtime. Reviewed-by: Onur Özkan <work@onurozkan.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Link: https://msgid.link/20260621105909.4055210-1-ekffu200098@gmail.com Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-09-22Backmerge tag 'v7.3-rc4' into drm-nextDave Airlie
Linux 7.3-rc4 Requested by Philipp Stanner for 2ab510e63197360945f915dd5631a77c63ac6b27 would be needed as a groundlayer for further patches that extend the locking in drm_sched Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-09-18rust: pin-init: internal: use span of `Index` for generated identifiersGary Guo
Use the span of `Index` for generated identifiers, so diagnostics can point to the span of the index. Link: https://patch.msgid.link/20260916184131.435059-1-gary@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-18rust: pin-init: internal: init: provide span for slot projectionGary Guo
When initializing a field, pin-init first projects the full slot to a slot of the field, then initialize it by invoking a method. Currently the span location is not explicitly set, so the error message points to the full macro invocation. Improve it by provide a span, so Rust will point to the specific fields causing the error when type check fails. Old error message: error[E0308]: mismatched types --> tests/ui/compile-fail/init/field_value_wrong_type.rs:8:28 | 8 | let _ = init!(Foo { a: () }); | ---------------^^--- | | | | | expected `usize`, found `()` | arguments to this method are incorrect New error message: error[E0308]: mismatched types --> tests/ui/compile-fail/init/field_value_wrong_type.rs:8:28 | 8 | let _ = init!(Foo { a: () }); | ---^^ | | | | | expected `usize`, found `()` | arguments to this method are incorrect Link: https://patch.msgid.link/20260916-dev-hygiene-v1-3-dfb6ae2588ba@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-18rust: pin-init: internal: init: use `slot` identifier directly with mixed siteGary Guo
Use `quote_spanned!(Span::mixed_site() => ...)` directly instead of creating `slot` identifier and interpolate it later. Do the same for `__data`, too. This is needed so that we can customize the location of the span without having the `slot` identifier getting in the way. For example: quote_spanned!(Span::mixed_site().located_at(loc) => ...) with `slot` mentioned directly will have the diagnostic pointing to the desired location, while `#slot` won't. Link: https://patch.msgid.link/20260916-dev-hygiene-v1-2-dfb6ae2588ba@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-18rust: pin-init: internal: init: emit `slot` using mixed site hygieneGary Guo
Syn/quote's default is the call site hygiene. If user provides a field named `slot`, it will conflict with pin-init generated `slot` identifier. Change it to use mixed site hygiene instead. Fixes: 4883830e9784 ("rust: pin-init: rewrite the initializer macros using `syn`") Link: https://patch.msgid.link/20260916-dev-hygiene-v1-1-dfb6ae2588ba@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-09-18Merge tag 'drm-misc-next-2026-09-17' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.4: UAPI Changes: ivpu: - add DRM_IVPU_CAP_CMDQ_SET_PRIORITY Cross-subsystem Changes: dma-fence: - fix documentation vga_switcheroo: - disconnect from fbcon; update fbcon from within DRM fbdev emulation Core Changes: atomic: - replace state reset callback with create_state throughout DRM core and drivers panic: - split into core and helpers sched: - clean up interface sysfs: - drop drm_class_device_register() Driver Changes: amdxdna: - fix BO handling arcpgu: - replace simple-display pipeline with regular atomic helpers aspeed: - replace simple-display pipeline with regular atomic helpers gm12u320: - replace simple-display pipeline with regular atomic helpers imagination: - various improvement to firmware interaction ivpu: - support command-queue priority ioctl mcde: - replace simple-display pipeline with regular atomic helpers p111: - replace simple-display pipeline with regular atomic helpers - drop unsupported alpha formats from primary plane panel: - edp: Add support for BOE NV140FHM-T0A - samsung: Share test-key helpers rcar-du: - support Renesas R-Car V4H DSC - dsi: Support larger transfers with AXI memory repaper: - replace simple-display pipeline with regular atomic helpers rockchip: - dsi: improve PHY timings ssd130x: - support Solomon SSD1351 OLED plus DT bindings - ssd133x: upgrade color format to RGB565 tve200: - replace simple-display pipeline with regular atomic helpers xen: - replace simple-display pipeline with regular atomic helpers Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260917090534.GA420415@2a02-2455-9062-2500-ec39-e8a6-193-9c05.dyn6.pyur.net
generated by cgit v1.2.3 (git 2.0.4) at 2026-11-07 23:15:57 +0000