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

Merge branch 'kunit' of https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git

2026-07-06T14:08:58+00:00

Merge branch 'driver-core-next' of https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git

2026-07-06T13:54:17+00:00

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

2026-07-06T13:53:17+00:00

Merge branch 'rust-i2c-next' of https://github.com/ikrtn/rust-for-linux

2026-07-06T13:34:39+00:00

rust: io: fix example in `register!` macro

2026-07-03T21:22:19+00:00

In this example, an u32 register is split in two u8 in big-endian order, but the high byte is actually defined as taking nine bits instead of eight. This is completely inconsequential, as I expect most users will just copy the bit ranges from their datasheets, but it doesn’t hurt to fix that typo. Signed-off-by: Link Mauve Acked-by: Alexandre Courbot Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260701160357.29031-1-linkmauve@linkmauve.fr Signed-off-by: Danilo Krummrich

kunit,rust: Add ability to skip entire test suites

2026-06-29T21:48:26+00:00

Currently, KUnit provides mechanisms to skip individual test cases, but there is no way to skip an entire test suite based on runtime conditions checked during suite initialization. This limitation forces test suites to either fail or skip tests individually when certain prerequisites are not available. To address this limitation, the patch adds a 'status' field to struct kunit_suite that allows suite_init callbacks to mark the entire suite as KUNIT_SKIPPED. When a suite is marked as skipped, all test cases within that suite are bypassed without execution. The patch proposed changes to kunit_suite_has_succeeded() to Check suite status before evaluating individual test case results. Also kunit_run_tests() is updated to skip suite execution if kunit_suite's 'status' is KUNIT_SKIPPED, thats either set before suite_init or by the suite_init callback itself. kunit_init_suite() is updated to initialize the 'status' of kunit_suite to KUNIT_SUCCESS so that any skipped suite's can be restarted from debugfs. This enables test suites to perform runtime capability checks in their 'suite_init' callback and gracefully skip all tests when prerequisites are not met, rather than reporting failures or requiring each test case to perform redundant checks. In case a kunit-suite is skipped it can be re-run from the kunit's debugfs interface. Also update debugfs_print_results() to clearly log the kunit-suite as 'SKIP'. kunit_suite_has_succeeded() is also updated on which debugfs_print_results() depends to update 'kunit_suite.status' in case any of the kunit_case has failed. Finally, update KUnit Rust binding macro-rule 'kunit_unsafe_test_suite' to add and initialize the newly introduced 'kunit_suite.status'. Without this 'kunit_suite.status' field is never initialized which is an error for the Rust compiler. Link: https://patchwork.kernel.org/project/linux-kselftest/patch/20260626085811.151133-2-vaibhav@linux.ibm.com/mbox/ Reviewed-by: David Gow Signed-off-by: Vaibhav Jain Signed-off-by: Shuah Khan

rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >= 1.98

2026-06-29T11:02:15+00:00

Starting with Rust 1.98.0 (expected 2026-08-20), Rust is introducing a couple new lints, `invalid_runtime_symbol_definitions` (deny-by-default) and `suspicious_runtime_symbol_definitions` (warn-by-default), which check the signature of items whose symbol name is a runtime symbol expected by `core`. Our build hits the second one, i.e. the warning: error: suspicious definition of the runtime `strlen` symbol used by the standard library --> rust/bindings/bindings_generated.rs:20018:5 | 20018 | pub fn strlen(s: *const ffi::c_char) -> usize; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: expected `unsafe extern "C" fn(*const i8) -> usize` found `unsafe extern "C" fn(*const u8) -> usize` = help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]` = help: allow this lint if the signature is compatible = note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]` error: suspicious definition of the runtime `strlen` symbol used by the standard library --> rust/uapi/uapi_generated.rs:14236:5 | 14236 | pub fn strlen(s: *const ffi::c_char) -> usize; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: expected `unsafe extern "C" fn(*const i8) -> usize` found `unsafe extern "C" fn(*const u8) -> usize` = help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]` = help: allow this lint if the signature is compatible = note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]` Thus `allow` the lint in `bindings` and `uapi`. A more targeted alternative to avoid `allow`ing it would be to pass `--blocklist-function strlen` to `bindgen`, but we would perhaps need to adjust if other C headers end up adding more (or Rust checking more). Since it is just the less critical one that we hit, and since eventually this should be properly fixed by getting upstream Rust to provide a flag like GCC/Clang's `-funsigned-char` [2][3], just `allow` it for now. Cc: Urgau Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/155521 [1] Link: https://github.com/rust-lang/rust/issues/138446 [2] Link: https://github.com/Rust-for-Linux/linux/issues/355 [3] Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Reviewed-by: Tamir Duberstein Link: https://patch.msgid.link/20260615143225.471756-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda

Merge tag 'v7.2-rc1' into drm-rust-next

2026-06-28T21:02:51+00:00

Merge v7.2-rc1 into drm-rust-next to start the next cycle. Devres now requires T: 'static, which conflicts with shmem::Object using Devres> without that bound. Resolve by adding 'static as a supertrait to DriverObject and DeviceContext, which does not restrict any current use cases since DriverObject is always implemented on owned, refcounted types and DeviceContext is a sealed marker trait with only unit-type implementors. If DriverObject (or DeviceContext) ever becomes lifetime-parameterized (e.g. via a GAT for TTM backed objects), the 'static supertrait can be relaxed at that point. Signed-off-by: Danilo Krummrich

rust: faux: Allow retrieving a bound Device

2026-06-25T21:13:20+00:00

When writing up some rust code that used faux devices for unit testing, I noticed that we never actually added the Bound device context to faux::Registration's AsRef implementation. This being said: the Registration object itself is proof that a driver is bound to the device - so this should be safe. Signed-off-by: Lyude Paul Reviewed-by: Alexandre Courbot Reviewed-by: Alice Ryhl Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260612194436.585385-4-lyude@redhat.com Signed-off-by: Danilo Krummrich

rust: drm: gem: Introduce shmem::Object::sg_table()

2026-06-25T18:25:54+00:00

In order to do this, we need to be careful to ensure that any interface we expose for scatterlists ensures that any mappings created from one are destroyed on driver-unbind. To do this, we introduce a Devres resource into shmem::Object that we use in order to ensure that we release any SGTable mappings on driver-unbind. There's some other slightly unfortunate caveats of this: * Drivers don't have explicit control at the moment over when unmapping happens (which is exactly the same as the C side atm, so it might not be a problem). * We can't just return `SGTableMap` to the user through an Arc to attempt to fix the last caveat - because that implies the gem object would need to hold a reference count to the scatterlist mapping, which just leaves us with the same problem. Signed-off-by: Lyude Paul Reviewed-by: Alexandre Courbot Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260612194436.585385-5-lyude@redhat.com