user/sven/linux.git/rust, branch v6.15.1

rust: clean Rust 1.88.0's `clippy::uninlined_format_args` lint

2025-05-06T22:11:47Z

Starting with Rust 1.88.0 (expected 2025-06-26) [1], `rustc` may move back the `uninlined_format_args` to `style` from `pedantic` (it was there waiting for rust-analyzer suppotr), and thus we will start to see lints like: warning: variables can be used directly in the `format!` string --> rust/macros/kunit.rs:105:37 | 105 | let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args help: change this to | 105 - let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test); 105 + let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{test}"); There is even a case that is a pure removal: warning: variables can be used directly in the `format!` string --> rust/macros/module.rs:51:13 | 51 | format!("{field}={content}\0", field = field, content = content) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args help: change this to | 51 - format!("{field}={content}\0", field = field, content = content) 51 + format!("{field}={content}\0") The lints all seem like nice cleanups, thus just apply them. We may want to disable `allow-mixed-uninlined-format-args` in the future. 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-clippy/pull/14160 [1] Acked-by: Benno Lossin Reviewed-by: Tamir Duberstein Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250502140237.1659624-6-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: clean Rust 1.88.0's `unnecessary_transmutes` lint

2025-05-06T22:11:47Z

Starting with Rust 1.88.0 (expected 2025-06-26) [1][2], `rustc` may introduce a new lint that catches unnecessary transmutes, e.g.: error: unnecessary transmute --> rust/uapi/uapi_generated.rs:23242:18 | 23242 | unsafe { ::core::mem::transmute(self._bitfield_1.get(0usize, 1u8) as u8) } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this with: `(self._bitfield_1.get(0usize, 1u8) as u8 == 1)` | = note: `-D unnecessary-transmutes` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unnecessary_transmutes)]` There are a lot of them (at least 300), but luckily they are all in `bindgen`-generated code. Thus clean all up by allowing it there. Since unknown lints trigger a lint itself in older compilers, do it conditionally so that we can keep the `unknown_lints` lint enabled. 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/136083 [1] Link: https://github.com/rust-lang/rust/issues/136067 [2] Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250502140237.1659624-4-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: allow Rust 1.87.0's `clippy::ptr_eq` lint

2025-05-06T22:11:02Z

Starting with Rust 1.87.0 (expected 2025-05-15) [1], Clippy may expand the `ptr_eq` lint, e.g.: error: use `core::ptr::eq` when comparing raw pointers --> rust/kernel/list.rs:438:12 | 438 | if self.first == item { | ^^^^^^^^^^^^^^^^^^ help: try: `core::ptr::eq(self.first, item)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_eq = note: `-D clippy::ptr-eq` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::ptr_eq)]` It is expected that a PR to relax the lint will be backported [2] by the time Rust 1.87.0 releases, since the lint was considered too eager (at least by default) [3]. Thus allow the lint temporarily just in case. 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-clippy/pull/14339 [1] Link: https://github.com/rust-lang/rust-clippy/pull/14526 [2] Link: https://github.com/rust-lang/rust-clippy/issues/14525 [3] Link: https://lore.kernel.org/r/20250502140237.1659624-3-ojeda@kernel.org [ Converted to `allow`s since backport was confirmed. - Miguel ] Signed-off-by: Miguel Ojeda

Merge tag 'driver-core-6.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core

2025-04-25T17:02:59Z

Pull driver core fixes from Greg KH: "Here are some small driver core fixes to resolve a number of reported problems. Included in here are: - driver core sync fix revert to resolve a much reported problem, hopefully this is finally resolved - MAINTAINERS file update, documenting that the driver-core tree is now under a "shared" maintainership model, thanks to Rafael and Danilo for offering to do this! - auxbus documentation and MAINTAINERS file update - MAINTAINERS file update for Rust PCI code - firmware rust binding fixup - software node link fix All of these have been in linux-next for over a week with no reported issues" * tag 'driver-core-6.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: drivers/base/memory: Avoid overhead from for_each_present_section_nr() software node: Prevent link creation failure from causing kobj reference count imbalance device property: Add a note to the fwnode.h drivers/base: Add myself as auxiliary bus reviewer drivers/base: Extend documentation with preferred way to use auxbus driver core: fix potential NULL pointer dereference in dev_uevent() driver core: introduce device_set_driver() helper Revert "drivers: core: synchronize really_probe() and dev_uevent()" MAINTAINERS: update the location of the driver-core git tree rust: firmware: Use `ffi::c_char` type in `FwFunc` MAINTAINERS: pci: add entry for Rust PCI code

rust: helpers: Add dma_alloc_attrs() and dma_free_attrs()

2025-04-15T21:06:03Z

Add dma_alloc_attrs() and dma_free_attrs() helpers to fix a build error when CONFIG_HAS_DMA is not enabled. Note that when CONFIG_HAS_DMA is enabled, dma_alloc_attrs() and dma_free_attrs() are included in both bindings_generated.rs and bindings_helpers_generated.rs. The former takes precedence so behavior remains unchanged in that case. This fixes the following build error on UML: error[E0425]: cannot find function `dma_alloc_attrs` in crate `bindings` --> rust/kernel/dma.rs:171:23 | 171 | bindings::dma_alloc_attrs( | ^^^^^^^^^^^^^^^ help: a function with a similar name exists: `dma_alloc_pages` | ::: rust/bindings/bindings_generated.rs:44568:5 | 44568 | / pub fn dma_alloc_pages( 44569 | | dev: *mut device, 44570 | | size: usize, 44571 | | dma_handle: *mut dma_addr_t, 44572 | | dir: dma_data_direction, 44573 | | gfp: gfp_t, 44574 | | ) -> *mut page; | |___________________- similarly named function `dma_alloc_pages` defined here error[E0425]: cannot find function `dma_free_attrs` in crate `bindings` --> rust/kernel/dma.rs:293:23 | 293 | bindings::dma_free_attrs( | ^^^^^^^^^^^^^^ help: a function with a similar name exists: `dma_free_pages` | ::: rust/bindings/bindings_generated.rs:44577:5 | 44577 | / pub fn dma_free_pages( 44578 | | dev: *mut device, 44579 | | size: usize, 44580 | | page: *mut page, 44581 | | dma_handle: dma_addr_t, 44582 | | dir: dma_data_direction, 44583 | | ); | |______- similarly named function `dma_free_pages` defined here Fixes: ad2907b4e308 ("rust: add dma coherent allocator abstraction") Signed-off-by: FUJITA Tomonori Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20250412000507.157000-1-fujita.tomonori@gmail.com [ Reworded for relative paths. - Miguel ] Signed-off-by: Miguel Ojeda

rust: helpers: Remove volatile qualifier from io helpers

2025-04-15T21:03:00Z

Remove the `volatile` qualifier used with __iomem in helper functions in io.c. These helper functions are just wrappers around the corresponding accessors so they are unnecessary. This fixes the following UML build error with CONFIG_RUST enabled: In file included from rust/helpers/helpers.c:19: rust/helpers/io.c:12:10: error: passing 'volatile void *' to parameter of type 'void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] 12 | iounmap(addr); | ^~~~ arch/um/include/asm/io.h:19:42: note: passing argument to parameter 'addr' here 19 | static inline void iounmap(void __iomem *addr) | ^ 1 error generated. [ Arnd explains [1] that removing the qualifier is the way forward (thanks!): Rihgt, I tried this last week when it came up first, removing the 'volatile' annotations in the asm-generic/io.h header and then all the ones that caused build regressions on arm/arm64/x86 randconfig and allmodconfig builds. This patch is a little longer than my original version as I did run into a few regressions later. As far as I can tell, none of these volatile annotations have any actual effect, and most of them date back to ancient kernels where this may have been required. Leaving it out of the rust interface is clearly the right way, and it shouldn't be too hard to upstream the changes below when we need to, but I also don't see any priority to send these. If anyone wants to help out, I can send them the whole patch. I created an issue [2] in case someone wants to help. - Miguel ] Fixes: ce30d94e6855 ("rust: add `io::{Io, IoRaw}` base types") Signed-off-by: FUJITA Tomonori Cc: stable@vger.kernel.org Reviewed-by: Danilo Krummrich Link: https://lore.kernel.org/rust-for-linux/0c844b70-19c7-4b14-ba29-fc99ae0d69f0@app.fastmail.com/ [1] Link: https://github.com/Rust-for-Linux/linux/issues/1156 [2] Link: https://lore.kernel.org/r/20250412005341.157150-1-fujita.tomonori@gmail.com [ Reworded for relative paths. - Miguel ] Signed-off-by: Miguel Ojeda

rust: firmware: Use `ffi::c_char` type in `FwFunc`

2025-04-14T12:13:23Z

The `FwFunc` struct contains an function with a char pointer argument, for which a `*const u8` pointer was used. This is not really the "proper" type for this, so use a `*const kernel::ffi::c_char` pointer instead. This has no real functionality changes, since now `kernel::ffi::c_char` (which bindgen uses for `char`) is now a type alias to `u8` anyways, but before commit 1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`") the concrete type of `kernel::ffi::c_char` depended on the architecture (However all supported architectures at the time mapped to `i8`). This caused problems on the v6.13 tag when building for 32 bit arm (with my patches), since back then `*const i8` was used in the function argument and the function that bindgen generated used `*const core::ffi::c_char` which Rust mapped to `*const u8` on 32 bit arm. The stable v6.13.y branch does not have this issue since commit 1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`") was backported. This caused the following build error: ``` error[E0308]: mismatched types --> rust/kernel/firmware.rs:20:4 | 20 | Self(bindings::request_firmware) | ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item | | | arguments to this function are incorrect | = note: expected fn pointer `unsafe extern "C" fn(_, *const i8, _) -> _` found fn item `unsafe extern "C" fn(_, *const u8, _) -> _ {request_firmware}` note: tuple struct defined here --> rust/kernel/firmware.rs:14:8 | 14 | struct FwFunc( | ^^^^^^ error[E0308]: mismatched types --> rust/kernel/firmware.rs:24:14 | 24 | Self(bindings::firmware_request_nowarn) | ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item | | | arguments to this function are incorrect | = note: expected fn pointer `unsafe extern "C" fn(_, *const i8, _) -> _` found fn item `unsafe extern "C" fn(_, *const u8, _) -> _ {firmware_request_nowarn}` note: tuple struct defined here --> rust/kernel/firmware.rs:14:8 | 14 | struct FwFunc( | ^^^^^^ error[E0308]: mismatched types --> rust/kernel/firmware.rs:64:45 | 64 | let ret = unsafe { func.0(pfw as _, name.as_char_ptr(), dev.as_raw()) }; | ------ ^^^^^^^^^^^^^^^^^^ expected `*const i8`, found `*const u8` | | | arguments to this function are incorrect | = note: expected raw pointer `*const i8` found raw pointer `*const u8` error: aborting due to 3 previous errors ``` Fixes: de6582833db0 ("rust: add firmware abstractions") Cc: stable@vger.kernel.org Reviewed-by: Benno Lossin Signed-off-by: Christian Schrefl Acked-by: Miguel Ojeda Link: https://lore.kernel.org/r/20250413-rust_arm_fix_fw_abstaction-v3-1-8dd7c0bbcd47@gmail.com [ Add firmware prefix to commit subject. - Danilo ] Signed-off-by: Danilo Krummrich

rust: kbuild: Don't export __pfx symbols

2025-04-08T19:44:20Z

With CONFIG_PREFIX_SYMBOLS, objtool adds __pfx prefix symbols to claim the compiler emitted call padding bytes. When CONFIG_X86_KERNEL_IBT is not selected, the symbols are added to individual object files and for Rust objects, they end up being exported, resulting in warnings with CONFIG_GENDWARFKSYMS as the symbols have no debugging information: warning: gendwarfksyms: symbol_print_versions: no information for symbol __pfx_rust_helper_put_task_struct warning: gendwarfksyms: symbol_print_versions: no information for symbol __pfx_rust_helper_task_euid warning: gendwarfksyms: symbol_print_versions: no information for symbol __pfx_rust_helper_readq_relaxed ... Filter out the __pfx prefix from exported symbols similarly to the existing __cfi and __odr_asan prefixes. Signed-off-by: Sami Tolvanen Reviewed-by: Alice Ryhl Cc: stable@vger.kernel.org Fixes: ac61506bf2d1 ("rust: Use gendwarfksyms + extended modversions for CONFIG_MODVERSIONS") Link: https://lore.kernel.org/r/20250318231815.917621-2-samitolvanen@google.com Signed-off-by: Miguel Ojeda

rust: pin-init: use Markdown autolinks in Rust comments

2025-04-08T19:12:58Z

"Normal" comments in Rust (`//`) are also formatted in Markdown, like the documentation (`///` and `//!`), see Documentation/rust/coding-guidelines.rst Thus use Markdown autolinks for a couple links that were missing it. It also helps to get proper linking in some software like kitty [1]. Suggested-by: Benno Lossin Link: https://github.com/Rust-for-Linux/pin-init/pull/32#discussion_r2023103712 [1] Signed-off-by: Miguel Ojeda Link: https://github.com/Rust-for-Linux/pin-init/pull/32/commits/dd230d61bf0538281072fbff4bb71efc58f3420c Fixes: 84837cf6fa54 ("rust: pin-init: change examples to the user-space version") Cc: stable@vger.kernel.org [ Change case in title. Reworded commit message. - Benno ] Signed-off-by: Benno Lossin Link: https://lore.kernel.org/r/20250407201755.649153-3-benno.lossin@proton.me Signed-off-by: Miguel Ojeda

rust: pin-init: alloc: restrict `impl ZeroableOption` for `Box` to `T: Sized`

2025-04-08T19:12:58Z

Similar to what was done for `Zeroable>` in commit df27cef15360 ("rust: init: fix `Zeroable` implementation for `Option>` and `Option>`"), the latest Rust documentation [1] says it guarantees that `transmute::<_, Option>([0u8; size_of::()])` is sound and produces `Option::::None` only in some cases. In particular, it says: `Box` (specifically, only `Box`) when `U: Sized` Thus restrict the `impl` to `Sized`, and use similar wording as in that commit too. Link: https://doc.rust-lang.org/stable/std/option/index.html#representation [1] Signed-off-by: Miguel Ojeda Link: https://github.com/Rust-for-Linux/pin-init/pull/32/commits/a6007cf555e5946bcbfafe93a6468c329078acd8 Fixes: 9b2299af3b92 ("rust: pin-init: add `std` and `alloc` support from the user-space version") Cc: stable@vger.kernel.org [ Adjust mentioned commit to the one from the kernel. - Benno ] Signed-off-by: Benno Lossin Link: https://lore.kernel.org/r/20250407201755.649153-2-benno.lossin@proton.me Signed-off-by: Miguel Ojeda