summaryrefslogtreecommitdiff
path: root/rust
AgeCommit message (Collapse)Author
2025-03-17rust: device: implement device context markerDanilo Krummrich
Some bus device functions should only be called from bus callbacks, such as probe(), remove(), resume(), suspend(), etc. To ensure this add device context marker structs, that can be used as generics for bus device implementations. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Suggested-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20250314160932.100165-3-dakr@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-17rust: pci: use to_result() in enable_device_mem()Danilo Krummrich
Simplify enable_device_mem() by using to_result() to handle the return value of the corresponding FFI call. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20250314160932.100165-2-dakr@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-16rust: pin-init: re-enable doctestsBenno Lossin
The pin-init crate is now compiled in a standalone fashion, so revert the earlier commit that disabled the doctests in pin-init in order to avoid build errors while transitioning the crate into a standalone version. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-22-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: add miscellaneous files from the user-space versionBenno Lossin
Add readme and contribution guidelines of the user-space version of pin-init. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-21-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: miscellaneous synchronization with the user-space versionBenno Lossin
Remove the last differences between the kernel version and the user-space version. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Fiona Behrens <me@kloenk.dev> Link: https://lore.kernel.org/r/20250308110339.2997091-20-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: internal: synchronize with user-space versionBenno Lossin
Synchronize the internal macros crate with the user-space version that uses the quote crate [1] instead of a custom `quote!` macro. The imports in the different version are achieved using `cfg` on the kernel config value. This cfg is always set in the kernel and never set in the user-space version. Since the quote crate requires the proc_macro2 crate, imports also need to be adjusted and `.into()` calls have to be inserted. Link: https://crates.io/crates/quote [1] Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Fiona Behrens <me@Kloenk.dev> Link: https://lore.kernel.org/r/20250308110339.2997091-19-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: synchronize documentation with the user-space versionBenno Lossin
Synchronize documentation and examples with the user-space version. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-18-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: add `std` and `alloc` support from the user-space versionBenno Lossin
To synchronize the kernel's version of pin-init with the user-space version, introduce support for `std` and `alloc`. While the kernel uses neither, the user-space version has to support both. Thus include the required `#[cfg]`s and additional code. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-17-benno.lossin@proton.me [ Undo the temporary `--extern force:alloc` since now we have contents for `alloc` here. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: make pin-init its own crateBenno Lossin
Rename relative paths inside of the crate to still refer to the same items, also rename paths inside of the kernel crate and adjust the build system to build the crate. [ Remove the `expect` (and thus the `lint_reasons` feature) since the tree now uses `quote!` from `rust/macros/export.rs`. Remove the `TokenStream` import removal, since it is now used as well. In addition, temporarily (i.e. just for this commit) use an `--extern force:alloc` to prevent an unknown `new_uninit` error in the `rustdoc` target. For context, please see a similar case in: https://lore.kernel.org/lkml/20240422090644.525520-1-ojeda@kernel.org/ And adjusted the message above. - Miguel ] Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-16-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: add pin-init crate build infrastructureMiguel Ojeda
Add infrastructure for moving the initialization API to its own crate. Covers all make targets such as `rust-analyzer` and `rustdoc`. The tests of pin-init are not added to `rusttest`, as they are already tested in the user-space repository [1]. Link: https://github.com/Rust-for-Linux/pin-init [1] Co-developed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-15-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: change the way the `paste!` macro is calledBenno Lossin
Change the paste macro path from `::kernel::macros::paste!` to use `$crate::init::macros::paste!` instead, which links to `::macros::paste!`. This is because the pin-init crate will be a dependency of the kernel, so it itself cannot have the kernel as a dependency. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-14-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: remove kernel-crate dependencyBenno Lossin
In order to make pin-init a standalone crate, remove dependencies on kernel-specific code such as `ScopeGuard` and `KBox`. `ScopeGuard` is only used in the `[pin_]init_array_from_fn` functions and can easily be replaced by a primitive construct. `KBox` is only used for type variance of unsized types and can also easily be replaced. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-13-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: fix documentation linksBenno Lossin
Before switching to compile the `pin-init` crate directly, change any links that would be invalid to links that are valid both before and after the switch. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-12-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: add `ZeroableOption` and implement it instead of `Zeroable` for ↵Benno Lossin
`Option<Box<T, A>>` When making pin-init its own crate, `Zeroable` will no longer be defined by the kernel crate and thus implementing it for `Option<Box<T, A>>` is no longer possible due to the orphan rule. For this reason introduce a new `ZeroableOption` trait that circumvents this problem. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-11-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: move impl `Zeroable` for `Opaque` and `Option<KBox<T>>` into ↵Benno Lossin
the kernel crate In order to make pin-init a standalone crate, move kernel-specific code directly into the kernel crate. Since `Opaque<T>` and `KBox<T>` are part of the kernel, move their `Zeroable` implementation into the kernel crate. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Fiona Behrens <me@kloenk.dev> Link: https://lore.kernel.org/r/20250308110339.2997091-10-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: move `InPlaceInit` and impls of `InPlaceWrite` into the ↵Benno Lossin
kernel crate In order to make pin-init a standalone crate, move kernel-specific code directly into the kernel crate. This includes the `InPlaceInit<T>` trait, its implementations and the implementations of `InPlaceWrite` for `Arc` and `UniqueArc`. All of these use the kernel's error type which will become unavailable in pin-init. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-9-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: move the default error behavior of `try_[pin_]init`Benno Lossin
Move the ability to just write `try_pin_init!(Foo { a <- a_init })` (note the missing `? Error` at the end) into the kernel crate. Remove this notation from the pin-init crate, since the default when no error is specified is the kernel-internal `Error` type. Instead add two macros in the kernel crate that serve this default and are used instead of the ones from `pin-init`. This is done, because the `Error` type that is used as the default is from the kernel crate and it thus prevents making the pin-init crate standalone. In order to not cause a build error due to a name overlap, the macros in the pin-init crate are renamed, but this change is reverted in a future commit when it is a standalone crate. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-8-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: call `try_[pin_]init!` from `[pin_]init!` instead of ↵Benno Lossin
`__init_internal!` The `[pin_]init!` macros have the same behavior as the `try_[pin_]init!` macros, except that they set the error type to `Infallible`. Instead of calling the primitive `__init_internal!` with the correct parameters, the same can thus be achieved by calling `try_[pin_]init!`. Since this makes it more clear what their behavior is, simplify the implementations of `[pin_]init!`. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-7-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: change examples to the user-space versionBenno Lossin
Replace the examples in the documentation by the ones from the user-space version and introduce the standalone examples from the user-space version such as the `CMutex<T>` type. The `CMutex<T>` example from the pinned-init repository [1] is used in several documentation examples in the user-space version instead of the kernel `Mutex<T>` type (as it's not available). In order to split off the pin-init crate, all examples need to be free of kernel-specific types. Link: https://github.com/rust-for-Linux/pinned-init [1] Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-6-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: pin-init: move proc-macro documentation into pin-init crateBenno Lossin
Move the documentation of proc-macros from pin-init-internal into pin-init. This is because documentation can only reference types from dependencies and pin-init-internal cannot have pin-init as a dependency, as that would be cyclic. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-5-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: add extensions to the pin-init crate and move relevant documentation thereBenno Lossin
In preparation of splitting off the pin-init crate from the kernel crate, move all kernel-specific documentation from pin-init back into the kernel crate. Also include an example from the user-space version [1] adapted to the kernel. The new `init.rs` file will also be populated by kernel-specific extensions to the pin-init crate by the next commits. Link: https://github.com/Rust-for-Linux/pin-init/blob/c1417c64c71229f0fd444d75e88f33e3c547c829/src/lib.rs#L161 [1] Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-4-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: move pin-init API into its own directoryBenno Lossin
In preparation of splitting off the pin-init crate from the kernel crate, move all pin-init API code (including proc-macros) into `rust/pin-init`. Moved modules have their import path adjusted via the `#[path = "..."]` attribute. This allows the files to still be imported in the kernel crate even though the files are in different directories. Code that is moved out of files (but the file itself stays where it is) is imported via the `include!` macro. This also allows the code to be moved while still being part of the kernel crate. Note that this commit moves the generics parsing code out of the GPL-2.0 file `rust/macros/helpers.rs` into the Apache-2.0 OR MIT file `rust/pin_init/internal/src/helpers.rs`. I am the sole author of that code and it already is available with that license at [1]. The same is true for the entry-points of the proc-macros `pin_data`, `pinned_drop` and `derive_zeroable` in `rust/macros/lib.rs` that are moved to `rust/pin_data/internal/src/lib.rs`. Although there are some smaller patches that fix the doctests. Link: https://github.com/Rust-for-Linux/pinned-init [1] Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Fiona Behrens <me@kloenk.dev> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-3-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: init: disable doctestsBenno Lossin
The build system cannot handle doctests in the kernel crate in files outside of `rust/kernel/`. Subsequent commits will move files out of that directory, but will still compile them as part of the kernel crate. Thus ignore all doctests in the to-be-moved files. Leave tests disabled until they are separated into their own crate and they stop causing breakage. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250308110339.2997091-2-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-16rust: error: extend the Result documentationDirk Behme
Extend the Result documentation by some guidelines and examples how to handle Result error cases gracefully. And how to not handle them. While at it fix one missing `Result` link in the existing documentation. [ Moved links out-of-line for improved readability. Fixed `srctree` link. Sorted out-of-line links. Added newlines for consistency with other docs. Applied paragraph break suggestion. Reworded slightly the docs in a couple places. Added Markdown. In addition, added `#[allow(clippy::single_match)` for the first example. It cannot be an `expect` since due to a difference introduced in Rust 1.85.0 when there are comments in the arms of the `match`. Reported it upstream, but it was intended: https://github.com/rust-lang/rust-clippy/issues/14418 Perhaps Clippy will lint about it in the future, but without autofix: https://github.com/rust-lang/rust-clippy/pull/14420 - Miguel ] Link: https://lore.kernel.org/rust-for-linux/CANiq72keOdXy0LFKk9SzYWwSjiD710v=hQO4xi+5E4xNALa6cA@mail.gmail.com/ Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> Reviewed-by: Fiona Behrens <me@kloenk.dev> Link: https://lore.kernel.org/r/20250122054719.595878-1-dirk.behme@de.bosch.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-15Merge tag 'rust-fixes-6.14-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Disallow BTF generation with Rust + LTO - Improve rust-analyzer support 'kernel' crate: - 'init' module: remove 'Zeroable' implementation for a couple types that should not have it - 'alloc' module: fix macOS failure in host test by satisfying POSIX alignment requirement - Add missing '\n's to 'pr_*!()' calls And a couple other minor cleanups" * tag 'rust-fixes-6.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: scripts: generate_rust_analyzer: add uapi crate scripts: generate_rust_analyzer: add missing include_dirs scripts: generate_rust_analyzer: add missing macros deps rust: Disallow BTF generation with Rust + LTO rust: task: fix `SAFETY` comment in `Task::wake_up` rust: workqueue: add missing newline to pr_info! examples rust: sync: add missing newline in locked_by log example rust: init: add missing newline to pr_info! calls rust: error: add missing newline to pr_warn! calls rust: docs: add missing newline to printing macro examples rust: alloc: satisfy POSIX alignment requirement rust: init: fix `Zeroable` implementation for `Option<NonNull<T>>` and `Option<KBox<T>>` rust: remove leftover mentions of the `alloc` crate
2025-03-11rust: hrtimer: implement `HrTimerPointer` for `Arc`Andreas Hindborg
Allow the use of intrusive `hrtimer` fields in structs that are managed by an `Arc` by implementing `HrTimerPointer` and `RawTimerCallbck` for `Arc`. Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-3-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-11rust: sync: add `Arc::as_ptr`Andreas Hindborg
Add a method to get a pointer to the data contained in an `Arc`. Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-2-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-11rust: hrtimer: introduce hrtimer supportAndreas Hindborg
Add support for intrusive use of the hrtimer system. For now, only add support for embedding one timer per Rust struct. The hrtimer Rust API is based on the intrusive style pattern introduced by the Rust workqueue API. Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-1-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-11rust/kernel/faux: mark Registration methods inlineEthan Carter Edwards
When building the kernel on Arch Linux using on x86_64 with tools: $ rustc --version rustc 1.84.0 (9fc6b4312 2025-01-07) $ clang --version clang version 19.1.7 Target: x86_64-pc-linux-gnu The following symbols are generated: $ nm vmlinux | rg ' _R' | rustfilt | rg faux ffffffff81959ae0 T <kernel::faux::Registration>::new ffffffff81959b40 T <kernel::faux::Registration as core::ops::drop::Drop>::drop However, these Rust symbols are wrappers around bindings in the C faux code. Inlining these functions removes the middle-man wrapper function After applying this patch, the above function signatures disappear. Link: https://github.com/Rust-for-Linux/linux/issues/1145 Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/jesg4yu7m6fvzmgg5tlsktrrjm36l4qsranto5mdmnucx4pvf3@nhvt4juw5es3 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-10rust: task: fix `SAFETY` comment in `Task::wake_up`Panagiotis Foliadis
The `SAFETY` comment inside the `wake_up` method references erroneously the `signal_pending` C function instead of the `wake_up_process` which is actually called. Fix the comment to reference the correct C function. Fixes: fe95f58320e6 ("rust: task: adjust safety comments in Task methods") Signed-off-by: Panagiotis Foliadis <pfoliadis@posteo.net> Reviewed-by: Charalampos Mitrodimas <charmitro@posteo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250308-comment-fix-v1-1-4bba709fd36d@posteo.net [ Slightly reworded. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-10rust: types: add intra-doc links for `Opaque<T>`Dirk Behme
We use intra-doc links wherever possible. Thus add a couple missing ones for `Opaque<T>`. Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250305053438.1532397-1-dirk.behme@de.bosch.com [ Reworded. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-10rust: module: introduce `authors` keyGuilherme Giacomo Simoes
In the `module!` macro, the `author` field is currently of type `String`. Since modules can have multiple authors, this limitation prevents specifying more than one. Add an `authors` field as `Option<Vec<String>>` to allow creating modules with multiple authors, and change the documentation and all current users to use it. Eventually, the single `author` field may be removed. [ The `modinfo` key needs to still be `author`; otherwise, tooling may not work properly, e.g.: $ modinfo --author samples/rust/rust_print.ko Rust for Linux Contributors I have also kept the original `author` field (undocumented), so that we can drop it more easily in a kernel cycle or two. - Miguel ] Suggested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/244 Reviewed-by: Charalampos Mitrodimas <charmitro@posteo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com> Link: https://lore.kernel.org/r/20250309175712.845622-2-trintaeoitogc@gmail.com [ Fixed `modinfo` key. Kept `author` field. Reworded message accordingly. Updated my email. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-10Merge 6.14-rc6 into char-misc-nextGreg Kroah-Hartman
We need the fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-09panic_qr: use new #[export] macroAlice Ryhl
This validates at compile time that the signatures match what is in the header file. It highlights one annoyance with the compile-time check, which is that it can only be used with functions marked unsafe. If the function is not unsafe, then this error is emitted: error[E0308]: `if` and `else` have incompatible types --> <linux>/drivers/gpu/drm/drm_panic_qr.rs:987:19 | 986 | #[export] | --------- expected because of this 987 | pub extern "C" fn drm_panic_qr_max_data_size(version: u8, url_len: usize) -> usize { | ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected unsafe fn, found safe fn | = note: expected fn item `unsafe extern "C" fn(_, _) -> _ {kernel::bindings::drm_panic_qr_max_data_size}` found fn item `extern "C" fn(_, _) -> _ {drm_panic_qr_max_data_size}` The signature declarations are moved to a header file so it can be included in the Rust bindings helper, and the extern keyword is removed as it is unnecessary. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250303-export-macro-v3-5-41fbad85a27f@google.com [ Fixed `rustfmt`. Moved on top the unsafe requirement comment to follow the usual style, and slightly reworded it for clarity. Formatted bindings helper comment. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-09print: use new #[export] macro for rust_fmt_argumentAlice Ryhl
This moves the rust_fmt_argument function over to use the new #[export] macro, which will verify at compile-time that the function signature matches what is in the header file. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20250303-export-macro-v3-4-41fbad85a27f@google.com [ Removed period as requested by Andy. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-09rust: add #[export] macroAlice Ryhl
Rust has two different tools for generating function declarations to call across the FFI boundary: * bindgen. Generates Rust declarations from a C header. * cbindgen. Generates C headers from Rust declarations. However, we only use bindgen in the kernel. This means that when C code calls a Rust function by name, its signature must be duplicated in both Rust code and a C header, and the signature needs to be kept in sync manually. Introducing cbindgen as a mandatory dependency to build the kernel would be a rather complex and large change, so we do not consider that at this time. Instead, to eliminate this manual checking, introduce a new macro that verifies at compile time that the two function declarations use the same signature. The idea is to run the C declaration through bindgen, and then have rustc verify that the function pointers have the same type. The signature must still be written twice, but at least you can no longer get it wrong. If the signatures don't match, you will get errors that look like this: error[E0308]: `if` and `else` have incompatible types --> <linux>/rust/kernel/print.rs:22:22 | 21 | #[export] | --------- expected because of this 22 | unsafe extern "C" fn rust_fmt_argument( | ^^^^^^^^^^^^^^^^^ expected `u8`, found `i8` | = note: expected fn item `unsafe extern "C" fn(*mut u8, *mut u8, *mut c_void) -> *mut u8 {bindings::rust_fmt_argument}` found fn item `unsafe extern "C" fn(*mut i8, *mut i8, *const c_void) -> *mut i8 {print::rust_fmt_argument}` It is unfortunate that the error message starts out by saying "`if` and `else` have incompatible types", but I believe the rest of the error message is reasonably clear and not too confusing. Reviewed-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250303-export-macro-v3-3-41fbad85a27f@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-09rust: macros: support additional tokens in quote!Alice Ryhl
This gives the quote! macro support for the following additional tokens: * The = token. * The _ token. * The # token. (when not followed by an identifier) * Using #my_var with variables of type Ident. Additionally, some type annotations are added to allow cases where groups are empty. For example, quote! does support () in the input, but only when it is *not* empty. When it is empty, there are zero `.push` calls, so the compiler can't infer the item type and also emits a warning about it not needing to be mutable. These additional quote! features are used by a new proc macro that generates code looking like this: const _: () = { if true { ::kernel::bindings::#name } else { #name }; }; where #name has type Ident. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250303-export-macro-v3-2-41fbad85a27f@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-09rust: fix signature of rust_fmt_argumentAlice Ryhl
Without this change, the rest of this series will emit the following error message: error[E0308]: `if` and `else` have incompatible types --> <linux>/rust/kernel/print.rs:22:22 | 21 | #[export] | --------- expected because of this 22 | unsafe extern "C" fn rust_fmt_argument( | ^^^^^^^^^^^^^^^^^ expected `u8`, found `i8` | = note: expected fn item `unsafe extern "C" fn(*mut u8, *mut u8, *mut c_void) -> *mut u8 {bindings::rust_fmt_argument}` found fn item `unsafe extern "C" fn(*mut i8, *mut i8, *const c_void) -> *mut i8 {print::rust_fmt_argument}` The error may be different depending on the architecture. To fix this, change the void pointer argument to use a const pointer, and change the imports to use crate::ffi instead of core::ffi for integer types. Fixes: 787983da7718 ("vsprintf: add new `%pA` format specifier") Reviewed-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20250303-export-macro-v3-1-41fbad85a27f@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-09rust: firmware: add `module_firmware!` macroDanilo Krummrich
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 <jarkko@kernel.org> Link: https://lore.kernel.org/r/20250306222336.23482-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-03-09rust: firmware: introduce `firmware::ModInfoBuilder`Danilo Krummrich
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 <aliceryhl@google.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250306222336.23482-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-03-09rust: module: add type `LocalModule`Danilo Krummrich
The `LocalModule` type is the type of the module created by `module!`, `module_pci_driver!`, `module_platform_driver!`, etc. Since the exact type of the module is sometimes generated on the fly by the listed macros, provide an alias. This is first used by the `module_firmware!` macro. Acked-by: Miguel Ojeda <ojeda@kernel.org> Suggested-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250306222336.23482-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-03-08rust: improve lifetimes markupBorys Tyran
Improve lifetimes markup; e.g. from: /// ... 'a ... to: /// ... `'a` ... This will make lifetimes display as code span with Markdown and make it more consistent with rest of the docs. Link: https://github.com/Rust-for-Linux/linux/issues/1138 Signed-off-by: Borys Tyran <borys.tyran@protonmail.com> Link: https://lore.kernel.org/r/20250207142437.112435-1-borys.tyran@protonmail.com [ Reworded and changed Closes tag to Link. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-08rust: list: make the cursor point between elementsAlice Ryhl
I've been using the linked list cursor for a few different things, and I find it inconvenient to use because all of the functions have signatures along the lines of `Self -> Option<Self>`. The root cause of these signatures is that the cursor points *at* an element, rather than *between* two elements. Thus, change the cursor API to point between two elements. This is inspired by the stdlib linked list (well, really by this guy [1]), which also uses cursors that point between elements. The `peek_next` method returns a helper that lets you look at and optionally remove the element, as one common use-case of cursors is to iterate a list to look for an element, then remove that element. For many of the methods, this will reduce how many we need since they now just need a prev/next method, instead of the current state where you may end up needing all of curr/prev/next. Also, if we decide to add a function for splitting a list into two lists at the cursor, then a cursor that points between elements is exactly what makes the most sense. Another advantage is that this means you can now have a cursor into an empty list. Link: https://rust-unofficial.github.io/too-many-lists/sixth-cursors-intro.html [1] Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250210-cursor-between-v7-2-36f0215181ed@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-08rust: list: extract common code for insertionAlice Ryhl
To prepare for a new cursor API that has the ability to insert elements into the list, extract the common code needed for this operation into a new `insert_inner` method. Both `push_back` and `push_front` are updated to use the new function. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250210-cursor-between-v7-1-36f0215181ed@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-08rust: lockdep: Use Pin for all LockClassKey usagesMitchell Levy
Reintroduce dynamically-allocated LockClassKeys such that they are automatically (de)registered. Require that all usages of LockClassKeys ensure that they are Pin'd. Currently, only `'static` LockClassKeys are supported, so Pin is redundant. However, it is intended that dynamically-allocated LockClassKeys will eventually be supported, so using Pin from the outset will make that change simpler. Closes: https://github.com/Rust-for-Linux/linux/issues/1102 Suggested-by: Benno Lossin <benno.lossin@proton.me> Suggested-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Mitchell Levy <levymitchell0@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250307232717.1759087-12-boqun.feng@gmail.com
2025-03-08rust: sync: condvar: Add wait_interruptible_freezable()Alice Ryhl
To support waiting for a `CondVar` as a freezable process, add a wait_interruptible_freezable() function. Binder needs this function in the appropriate places to freeze a process where some of its threads are blocked on the Binder driver. [ Boqun: Cleaned up the changelog and documentation. ] Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250307232717.1759087-10-boqun.feng@gmail.com
2025-03-08rust: sync: lock: Add an example for Guard:: Lock_ref()Boqun Feng
To provide examples on usage of `Guard::lock_ref()` along with the unit test, an "assert a lock is held by a guard" example is added. (Also apply feedback from Benno.) Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250223072114.3715-1-boqun.feng@gmail.com Link: https://lore.kernel.org/r/20250307232717.1759087-9-boqun.feng@gmail.com
2025-03-08rust: sync: Add accessor for the lock behind a given guardAlice Ryhl
In order to assert a particular `Guard` is associated with a particular `Lock`, add an accessor to obtain a reference to the underlying `Lock` of a `Guard`. Binder needs this assertion to ensure unsafe list operations are done with the correct lock held. [Boqun: Capitalize the title and reword the commit log] Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Fiona Behrens <me@kloenk.dev> Link: https://lore.kernel.org/r/20250205-guard-get-lock-v2-1-ba32a8c1d5b7@google.com Link: https://lore.kernel.org/r/20250307232717.1759087-8-boqun.feng@gmail.com
2025-03-08rust: lockdep: Remove support for dynamically allocated LockClassKeysMitchell Levy
Currently, dynamically allocated LockCLassKeys can be used from the Rust side without having them registered. This is a soundness issue, so remove them. Fixes: 6ea5aa08857a ("rust: sync: introduce `LockClassKey`") Suggested-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Mitchell Levy <levymitchell0@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250307232717.1759087-11-boqun.feng@gmail.com
2025-03-07rust: miscdevice: change how f_ops vtable is constructedAlice Ryhl
I was helping someone with writing a new Rust abstraction, and we were using the miscdevice abstraction as an example. While doing this, it became clear to me that the way I implemented the f_ops vtable is confusing to new Rust users, and that the approach used by the block abstractions is less confusing. Thus, update the miscdevice abstractions to use the same approach as rust/kernel/block/mq/operations.rs. Sorry about the large diff. This changes the indentation of a large amount of code. Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250227-miscdevice-fops-change-v1-1-c9e9b75d67eb@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-05-10 00:14:45 +0000