linux/rust/kernel/firmware.rs, branch v6.16

rust: use `#[used(compiler)]` to fix build and `modpost` with Rust >= 1.89.0

2025-07-14T21:30:44Z

Starting with Rust 1.89.0 (expected 2025-08-07), the Rust compiler fails to build the `rusttest` target due to undefined references such as: kernel...-cgu.0:(.text....+0x116): undefined reference to `rust_helper_kunit_get_current_test' Moreover, tooling like `modpost` gets confused: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/nova/nova.o ERROR: modpost: missing MODULE_LICENSE() in drivers/gpu/nova-core/nova_core.o The reason behind both issues is that the Rust compiler will now [1] treat `#[used]` as `#[used(linker)]` instead of `#[used(compiler)]` for our targets. This means that the retain section flag (`R`, `SHF_GNU_RETAIN`) will be used and that they will be marked as `unique` too, with different IDs. In turn, that means we end up with undefined references that did not get discarded in `rusttest` and that multiple `.modinfo` sections are generated, which confuse tooling like `modpost` because they only expect one. Thus start using `#[used(compiler)]` to keep the previous behavior and to be explicit about what we want. Sadly, it is an unstable feature (`used_with_arg`) [2] -- we will talk to upstream Rust about it. The good news is that it has been available for a long time (Rust >= 1.60) [3]. The changes should also be fine for previous Rust versions, since they behave the same way as before [4]. Alternatively, we could use `#[no_mangle]` or `#[export_name = ...]` since those still behave like `#[used(compiler)]`, but of course it is not really what we want to express, and it requires other changes to avoid symbol conflicts. Cc: David Wood Cc: Wesley Wiser 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/140872 [1] Link: https://github.com/rust-lang/rust/issues/93798 [2] Link: https://github.com/rust-lang/rust/pull/91504 [3] Link: https://godbolt.org/z/sxzWTMfzW [4] Reviewed-by: Alice Ryhl Acked-by: Björn Roy Baron Link: https://lore.kernel.org/r/20250712160103.1244945-3-ojeda@kernel.org 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: firmware: add `module_firmware!` macro

2025-03-09T18:23:31Z

Analogous to the `module!` macro `module_firmware!` adds additional firmware path strings to the .modinfo section. In contrast to `module!`, where path strings need to be string literals, path strings can be composed with the `firmware::ModInfoBuilder`. Some drivers require a lot of firmware files (such as nova-core) and hence benefit from more flexibility composing firmware path strings. Acked-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20250306222336.23482-4-dakr@kernel.org Signed-off-by: Danilo Krummrich

rust: firmware: introduce `firmware::ModInfoBuilder`

2025-03-09T18:21:08Z

The `firmware` field of the `module!` only accepts literal strings, which is due to the fact that it is implemented as a proc macro. Some drivers require a lot of firmware files (such as nova-core) and hence benefit from more flexibility composing firmware path strings. The `firmware::ModInfoBuilder` is a helper component to flexibly compose firmware path strings for the .modinfo section in const context. It is meant to be used in combination with `kernel::module_firmware!`. Co-developed-by: Alice Ryhl Signed-off-by: Alice Ryhl Link: https://lore.kernel.org/r/20250306222336.23482-3-dakr@kernel.org Signed-off-by: Danilo Krummrich

rust: map `long` to `isize` and `char` to `u8`

2024-12-16T20:49:33Z

The following FFI types are replaced compared to `core::ffi`: 1. `char` type is now always mapped to `u8`, since kernel uses `-funsigned-char` on the C code. `core::ffi` maps it to platform default ABI, which can be either signed or unsigned. 2. `long` is now always mapped to `isize`. It's very common in the kernel to use `long` to represent a pointer-sized integer, and in fact `intptr_t` is a typedef of `long` in the kernel. Enforce this mapping rather than mapping to `i32/i64` depending on platform can save us a lot of unnecessary casts. Signed-off-by: Gary Guo Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20240913213041.395655-5-gary@garyguo.net [ Moved `uaccess` changes from the next commit, since they were irrefutable patterns that Rust >= 1.82.0 warns about. Reworded slightly and reformatted a few documentation comments. Rebased on top of `rust-next`. Added the removal of two casts to avoid Clippy warnings. - Miguel ] Signed-off-by: Miguel Ojeda

rust: device: change the from_raw() function

2024-10-03T11:54:48Z

The function Device::from_raw() increments a refcount by a call to bindings::get_device(ptr). This can be confused because usually from_raw() functions don't increment a refcount. Hence, rename Device::from_raw() to avoid confuion with other "from_raw" semantics. The new name of function should be "get_device" to be consistent with the function get_device() already exist in .c files. This function body also changed, because the `into()` will convert the `&'a Device` into `ARef` and also call `inc_ref` from the `AlwaysRefCounted` trait implemented for Device. Signed-off-by: Guilherme Giacomo Simoes Acked-by: Danilo Krummrich Closes: https://github.com/Rust-for-Linux/linux/issues/1088 Reviewed-by: Boqun Feng Link: https://lore.kernel.org/r/20241001205603.106278-1-trintaeoitogc@gmail.com Signed-off-by: Greg Kroah-Hartman

rust: firmware: fix invalid rustdoc link

2024-07-31T11:24:29Z

remove an extra quote from the doc comment so that rustdoc no longer genertes a link to a nonexistent file. Signed-off-by: Andrew Ballance Reviewed-by: Danilo Krummrich Acked-by: Miguel Ojeda Fixes: de6582833db0 ("rust: add firmware abstractions") Link: https://lore.kernel.org/r/20240709004426.44854-1-andrewjballance@gmail.com Signed-off-by: Greg Kroah-Hartman

firmware_loader: fix soundness issue in `request_internal`

2024-07-10T07:35:09Z

`request_internal` must be called with one of the following function pointers: request_firmware(), firmware_request_nowarn(), firmware_request_platform() or request_firmware_direct(). The previous `FwFunc` alias did not guarantee this, which is unsound. In order to fix this up, implement `FwFunc` as new type with a corresponding type invariant. Reported-by: Gary Guo Closes: https://lore.kernel.org/lkml/20240620143611.7995e0bb@eugeo/ Signed-off-by: Danilo Krummrich Reviewed-by: Christian Schrefl Link: https://lore.kernel.org/r/20240708200724.3203-2-dakr@redhat.com Signed-off-by: Greg Kroah-Hartman

firmware_loader: annotate doctests as `no_run`

2024-07-10T07:35:09Z

The doctests of `Firmware` are compile-time only tests, since they require a proper `Device` and a valid path to a (firmware) blob in order to do something sane on runtime - we can't satisfy both of those requirements. Hence, configure the example as `no_run`. Unfortunately, the kernel's Rust build system can't consider the `no_run` attribute yet. Hence, for the meantime, wrap the example code into a new function and never actually call it. Fixes: de6582833db0 ("rust: add firmware abstractions") Signed-off-by: Danilo Krummrich Link: https://lore.kernel.org/r/20240708200724.3203-1-dakr@redhat.com Signed-off-by: Greg Kroah-Hartman

firmware: rust: improve safety comments

2024-06-20T14:14:54Z

Improve the wording of safety comments to be more explicit about what exactly is guaranteed to be valid. Suggested-by: Benno Lossin Signed-off-by: Danilo Krummrich Link: https://lore.kernel.org/r/20240619132029.59296-1-dakr@redhat.com Signed-off-by: Greg Kroah-Hartman