All types in `bindings` implement `Zeroable` if they can, so use
`pin_init::zeroed` instead of relying on `unsafe` code.
If this ends up not compiling in the future, something in bindgen or on
the C side changed and is most likely incorrect.
Suggested-by: Benno Lossin <lossin@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1189
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Michal Wilczynski <m.wilczynski@samsung.com>
Signed-off-by: Francis Laniel <laniel_francis@privacyrequired.com>
Link: https://patch.msgid.link/20260603160910.159307-1-laniel_francis@privacyrequired.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
`SpinLockIrq` and `SpinLock` use the exact same underlying C structure,
with the only real difference being that the former uses the
irq_disable() and irq_enable() variants for locking/unlocking. These
variants can introduce some minor overhead in contexts where we already
know that local processor interrupts are disabled, and as such we want a
way to be able to skip modifying processor interrupt state in said
contexts in order to avoid some overhead - just like the current C API
allows us to do.
In order to do this, we add some special functions for SpinLockIrq:
lock_with() and try_lock_with(), which allow acquiring the lock without
changing the interrupt state - as long as the caller can provide a
LocalInterruptDisabled reference to prove that local processor
interrupts have been disabled.
In some hacked-together benchmarks we ran, most of the time this did
actually seem to lead to a noticeable difference in overhead:
From an aarch64 VM running on a MacBook M4:
lock() when irq is disabled, 100 times cost Delta { nanos: 500 }
lock_with() when irq is disabled, 100 times cost Delta { nanos: 292 }
lock() when irq is enabled, 100 times cost Delta { nanos: 834 }
lock() when irq is disabled, 100 times cost Delta { nanos: 459 }
lock_with() when irq is disabled, 100 times cost Delta { nanos: 291 }
lock() when irq is enabled, 100 times cost Delta { nanos: 709 }
From an x86_64 VM (qemu/kvm) running on a i7-13700H
lock() when irq is disabled, 100 times cost Delta { nanos: 1002 }
lock_with() when irq is disabled, 100 times cost Delta { nanos: 729 }
lock() when irq is enabled, 100 times cost Delta { nanos: 1516 }
lock() when irq is disabled, 100 times cost Delta { nanos: 754 }
lock_with() when irq is disabled, 100 times cost Delta { nanos: 966 }
lock() when irq is enabled, 100 times cost Delta { nanos: 1227 }
(note that there were some runs on x86_64 where lock() on irq
disabled vs. lock_with() on irq disabled had equivalent benchmarks,
but it very much appeared to be a minority of test runs.)
While it's not clear how this affects real-world workloads yet, let's
add this for the time being so we can find out.
This makes it so that a `SpinLockIrq` will work like a `SpinLock` if
interrupts are disabled. So a function:
(&'a SpinLockIrq, &'a LocalInterruptDisabled) -> Guard<'a, .., SpinLockBackend>
makes sense. Note that due to `Guard` and `LocalInterruptDisabled`
having the same lifetime, interrupts cannot be enabled while the Guard
exists.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Boqun Feng <boqun@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260807070218.27144-19-boqun@kernel.org
A variant of `SpinLock` that ensures interrupts are disabled in the
critical section. `lock()` will ensure that either interrupts are
already disabled or disable them. `unlock()` will reverse the respective
operation.
[Boqun: Port to use spin_lock_irq_disable() and
spin_unlock_irq_enable()]
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Boqun Feng <boqun@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260807070218.27144-18-boqun@kernel.org
This introduces a module for dealing with interrupt-disabled contexts,
including the ability to enable and disable interrupts along with the
ability to annotate functions as expecting that IRQs are already
disabled on the local CPU.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Boqun Feng <boqun@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260807070218.27144-15-boqun@kernel.org
rcu_barrier() is a frequently used C function which is always safe to be
called.
Add a safe abstraction for rcu_barrier().
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Acked-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260805145949.938505-5-phasta@kernel.org
[ Formatted documentation. Sorted tags. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Implement ForeignOwnable for ARef<T>, making it possible for C code to
own an ARef<T>.
Since ARef represents shared ownership, BorrowedMut is &T rather than
&mut T, matching the semantics of the underlying reference-counted type.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260805145949.938505-4-phasta@kernel.org
[ Relaxed `'static` bound and added `#[inline]` as discussed. Added
the submitter's Signed-off-by tag. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add all of the remaining error codes from include/uapi/asm-generic/errno.h.
Previous updates to error.rs have been piecemeal -- adding single error
codes as needed. Instead, we can avoid future problems by adding all
the remaining error code in one swoop.
EDEADLOCK and EWOULDBLOCK are intentionally left out: they are just
deprecated compatibility aliases of EDEADLK and EAGAIN, kept around for
non-Linux/POSIX code, and have no use in new kernel code.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20260805145949.938505-3-phasta@kernel.org
[ Formatted comments. Added the submitter's Signed-off-by tag. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Callers that go through `kernel::prelude` have `CStrExt` in scope, but
code inside the `kernel` crate imports explicitly and may not. Using
`warn_on!` from such a module fails to build on UML, which is the only
configuration where `warn_flags!` needs a C string pointer rather than an
inline asm bug entry:
error[E0599]: no method named `as_char_ptr` found for reference `&ffi::CStr` in the current scope
--> linux/rust/kernel/bug.rs:83:49
|
83 | $crate::c_str!(::core::file!()).as_char_ptr(),
| ^^^^^^^^^^^
|
::: linux/rust/kernel/time.rs:427:9
|
427 | warn_on!(self.nanos < 0);
| ------------------------ in this macro invocation
|
= help: items from traits can only be used if the trait is in scope
= note: this error originates in the macro `$crate::warn_flags` which comes from the expansion of the macro `warn_on` (in Nightly builds, run with -Z mac)
help: trait `CStrExt` which provides `as_char_ptr` is implemented but not in scope; perhaps you want to import it
--> linux/rust/kernel/time.rs:27:1
|
27 + use crate::str::CStrExt;
Call the method through its fully qualified path, which resolves
without any import at the expansion site.
Cc: stable@vger.kernel.org
Fixes: dff64b0727 ("rust: Add warn_on macro")
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://patch.msgid.link/20260807112427.1039056-1-tomo@flapping.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Running `make rusttest` with `ARCH=` set to an architecture other than
the host's fails, e.g. `ARCH=arm64` on an x86_64 host:
error: invalid instruction mnemonic 'brk'
--> rust/kernel/bug.rs:63:17
|
63 | / concat!(
64 | | "/* {size} */",
65 | | include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_warn_asm.rs")),
66 | | include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_reachable_asm.rs")));
| |_______________________________________________________________________________________________________^
|
note: instantiated into assembly here
--> <inline asm>:1:115
|
1 | /* 8 */.pushsection __bug_table,"aw"; .align 2; 14470: .long 14471f - .;.short 2305;.align 2; .popsection; 14471:brk 0x800
| ^^^
The reason is that `rusttest` builds the `kernel` crate as a host
library: it passes the `CONFIG_*` cfgs of the configured architecture,
but not `--target`, so code generation happens for the
host. `warn_flags!` then selects the arch-specific inline asm arm
based on `CONFIG_*`, and the host assembler rejects it.
This does not happen with the current `master` because `warn_on!` has
no user inside the `kernel` crate itself yet, but it will as soon as
one is added.
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://lore.kernel.org/all/CANiq72n4=fz=JNKY0Jdm8BnLa=RmHB2B7s0bO47YTJ7hygqBZg@mail.gmail.com/
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: stable@vger.kernel.org
Fixes: dff64b0727 ("rust: Add warn_on macro")
Link: https://patch.msgid.link/20260808022608.1125174-1-tomo@flapping.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Fix the following dead_code warning on some configurations in an
atomic development branch:
warning: constant `WARN_ON_FLAGS` is never used
--> linux/rust/kernel/bug.rs:126:19
|
126 | const WARN_ON_FLAGS: u32 = $crate:🐛:bugflag_taint($crate::bindings::TAINT_WARN);
| ^^^^^^^^^^^^^
|
::: linux/rust/kernel/sync/srcu.rs:106:12
|
106 | if crate::warn_on!(
| ____________-
107 | | // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
108 | | // and `srcu_readers_active()` only checks the active reader count.
109 | | unsafe { bindings::srcu_readers_active(ptr) }
110 | | ) {
| |_________- in this macro invocation
|
= note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default
= note: this warning originates in the macro `crate::warn_on` (in Nightly builds, run with -Z macro-backtrace for more info)
The warn_on! macro always defines a WARN_ON_FLAGS constant and hands it
to warn_flags!. On configurations where warn_flags! does not reference
its flags argument (the LOONGARCH/ARM variant, which only calls
WARN_ON(), and the !CONFIG_BUG no-op variant), the constant is left
unused and triggers a dead_code warning.
warn_flags! is the macro that accepts (and here discards) the flags
argument, so make it responsible for the argument it drops.
Also rename `_COND_STR` to `COND_STR` and consume `$file` for consistency.
Fixes: dff64b0727 ("rust: Add warn_on macro")
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260801024841.786664-1-tomo@flapping.org
[ Added newlines. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
When using the Rust GCC backend (i.e. `rustc_codegen_gcc`), GCC does not
inline enough these `Bounded::from_expr` calls:
/usr/bin/x86_64-linux-gnu-ld.bfd: rust/kernel.o: in function `<kernel::num::bounded::Bounded<u16, 2> as core::convert::From<kernel::bitfield::tests::Priority>>::from':
fake.c:(.text.unlikely+0x7be): undefined reference to `rust_build_error'
/usr/bin/x86_64-linux-gnu-ld.bfd: rust/kernel.o: in function `<kernel::num::bounded::Bounded<u64, 4> as core::convert::From<kernel::bitfield::tests::MemoryType>>::from':
fake.c:(.text.unlikely+0x90d): undefined reference to `rust_build_error'
Thus, similar to commit bc197e24a3 ("rust: num: bounded: Always inline
fits_within and from_expr"), mark them as `#[inline(always)]`.
[ Reworded to add the error and to follow our usual style and sent on
behalf of Antoni, who found this during his work to support Rust for
Linux with the GCC backend, i.e. with `rustc_codegen_gcc`. - Miguel ]
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Antoni Boucher <bouanto@zoho.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260807175012.142083-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The `Arc` documentation has a few mentions that do not follow the
surrounding style: a plain `Arc` without an intra-doc link and a
lower-case "arc".
Use intra-doc links for rustdoc references to `Arc` and spell internal
comments consistently as `Arc`, matching nearby docs.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1240
Signed-off-by: Harish C S <harish.cs.ss24@gmail.com>
Acked-by: Boqun Feng <boqun@kernel.org>
Link: https://patch.msgid.link/20260711145033.39649-1-harish.cs.ss24@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
- Merge the `__pinned_init` and `__init` methods and make `Init` become a marker trait.
- Introduce public APIs `raw_init` and `raw_try_init` to prevent user from needing to invoke the internal `__pinned_init`/`__init` methods.
- Emit errors for duplicate `#[pin]` attributes.
- Link `Zeroable::zeroed` and `pin_init::zeroed` in documentation.
Other changes:
- Fix unwind safety issues.
- Clean up lint `allow` and `expect`s.
- Overhaul `#[cfg]` handling to pave the way for tuple struct and self referential structs.
- Mark many functions are `#[inline]` for better codegen with `-C opt-level=s` (CC_OPTIMIZE_FOR_SIZE).
-----BEGIN PGP SIGNATURE-----
iIcEABYKAC8WIQRIiwFmsgGbHdMqd+kPoQF7f9ATtgUCanMafBEcZ2FyeUBnYXJ5
Z3VvLm5ldAAKCRAPoQF7f9ATtlEGAQCNKDAMTM+DWL02l2jQu22HJ5XohUgiN7m4
VfIYjcPVxQD6A8n1Jyw7DmIF+hTBR6aAK+vH0iIqKKvWdVgvsNswKw0=
=LSdN
-----END PGP SIGNATURE-----
Merge tag 'pin-init-v7.3' of https://github.com/Rust-for-Linux/linux into rust-next
Pull pin-init updates from Gary Guo:
"User-visible changes:
- Merge the '__pinned_init' and '__init' methods and make 'Init'
a marker trait.
- Introduce public APIs 'raw_init' and 'raw_try_init' to prevent users
from needing to invoke the internal '__pinned_init'/'__init' methods.
- Emit errors for duplicate '#[pin]' attributes.
- Link 'Zeroable::zeroed' and 'pin_init::zeroed' in documentation.
Other changes:
- Fix unwind safety issues.
- Clean up lint 'allow' and 'expect's.
- Overhaul '#[cfg]' handling to pave the way for tuple structs and
self-referential structs.
- Mark many functions as '#[inline]' for better codegen with '-C
opt-level=s' ('CC_OPTIMIZE_FOR_SIZE')."
* tag 'pin-init-v7.3' of https://github.com/Rust-for-Linux/linux:
rust: pin-init: add `#[inline]` to small functions
rust: pin-init: remove `__pinned_init` method for `cfg(kernel)`
rust: treewide: replace `__pinned_init` with `raw_[try_]init`
rust: pin-init: add `raw_init` and `raw_try_init` and recommend over `__init`
rust: pin-init: merge `__pinned_init` and `__init`
rust: pin-init: examples: use `Wrapper::pin_init` instead of manual reimplementation
rust: pin-init: mark `pin_init::zeroed` and `Zeroable::zeroed` as `#[inline]`
rust: pin-init: docs: link `Zeroable::zeroed` and `pin_init::zeroed` in documentation
rust: pin-init: internal: rework how `#[pin_data]` handles cfg
rust: pin-init: make `[pin_]chain` unwind safe
rust: pin-init: make `[pin_]init_array_from_fn` unwind safe
rust: pin-init: internal: generate brace in macro for init code blocks
rust: pin-init: internal: remove `allow` and `expect`s that don't fire
rust: pin-init: remove redundant clippy expects in doc tests
rust: pin-init: examples: fix incorrect drop
rust: pin-init: internal: error on duplicate `#[pin]` attribute
-----BEGIN PGP SIGNATURE-----
iQFSBAABCgA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmp49yoeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG1WIH/1SD1rNIb4Prf0C7
Rk9Hz0IZ3uYNe1Xi+Ozv3zQUuLB6d7ewl9e4zyHHYT4eeIKvBZv9jtIF3QH4ty5X
JB9Gy62WICtqIEkzzt2bkcV1byFmKz2+BLv04fgcyTXEGOEByCDiZ3/N3kSJOqvg
YxsGOmKkQSTavFLSe96Gj2pgchJqZ6j3qucDO6GrPOo8depP2kfzxfaJbXix0HEZ
ln08X9hgZDxy4I98PmSaaJsK2R/i6T6jQdA3i8DnSbbyNhLn+3FK6gkP08ZEpaor
82WwJf+MVCLHXLYDy0aYOUDHpkNkkJWOj45A2Hv9JkOupGcUpyPGr82l4yh/MrxC
+kM28xs=
=rIbd
-----END PGP SIGNATURE-----
Merge tag 'v7.2-rc7' into driver-core-next
We need the driver-core fixes in here as well to build on top of.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
- Fix Rust build failure on s390 by gating ioremap() / iounmap() helpers
and the io::mem module on CONFIG_HAS_IOMEM; gate affected doctests as
well.
- Add missing kernel-doc for show_const / store_const union members in
struct device_attribute.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS2q/xV6QjXAdC7k+1FlHeO1qrKLgUCancYdAAKCRBFlHeO1qrK
LneZAQD9bhMwOb9C8t+fLXEYd6WR+1n932bmKTBSscZ1evnojwD+M4MqTWDBDgal
Mc8wasHQsQc7pqVFFHtFEUIAZjRlpAc=
=KHk2
-----END PGP SIGNATURE-----
Merge tag 'driver-core-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core
Pull driver core fixes from Danilo Krummrich:
- Fix Rust build failure on s390 by gating ioremap() / iounmap()
helpers and the io::mem module on CONFIG_HAS_IOMEM; gate affected
doctests as well.
- Add missing kernel-doc for show_const / store_const union members in
struct device_attribute.
* tag 'driver-core-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core:
rust: io: gate ioremap doctests on CONFIG_HAS_IOMEM
rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEM
driver core: add missing kernel-doc for union members
Merge cpufreq updates for 7.3-rc1:
- Minor fixes and cleanups in assorted cpufreq drivers (Dan Carpenter,
Guru Das Srinagesh, Haoxiang Li, Karl Mehltretter, Sasha Finkelstein,
and Pan Chuang)
- Fix cpufreq table creation and bios_limits() callback in the Rust
bindings (Priya Bala Govindasamy)
- Add IPQ5210 support to qcom-nvmem driver (Varadarajan Narayanan)
- Adjust the .adjust_perf() cpufreq driver callback to allow the
maximum performance value to be passed to drivers and update the
intel_pstate driver to use it (Rafael Wysocki)
- Set policy->cur to the actual requested frequency in the intel_pstate
driver when the performance policy is used (Rafael Wysocki)
- Simplify HWP handling on Broadwell processors in intel_pstate (Rafael
Wysocki)
- Fix setting minimum P-state at init time in intel_pstate (Rafael
Wysocki)
- Consolidate frequency values computation in intel_pstate and clean up
code in that driver (Rafael Wysocki)
- Add missing kernel-doc desciptions for structure and union members in
the amd-pstate driver (David Vernet)
- Handle missing policy in dynamic EPP callbacks in the amd-pstate
driver (EDAMAMEX)
- Introduce EXPORT_SYMBOL_FOR_PSTATE_UT() to export amd-pstate driver
symbols to the amd-pstate-ut subdriver (K Prateek Nayak)
- Add dynamic EPP as an "energy_performance_preference" mode in
amd-pstate, remove the "amd_dynamic_epp" kernel command line option
and the "dynamic_epp" sysfs attribute, and update the dynamic_epp
documentation accordingly (K Prateek Nayak)
- Add unit tests for CPPC Performance Priority and the "dynamic" EPP
mode in the amd-pstate driver (K Prateek Nayak)
- Set min_limit_freq based on bios_min_perf in amd-pstate and remove
the defensive check for bios_min_perf from it (K Prateek Nayak)
- Fix EPP return type and handle errors in amd-pstate during
initialization, toggle auto_sel in active mode on shared memory
systems, and cache the firmware programmed EPP value (Marco Scardovi)
- Skip tests in amd-pstate-ut if the amd-pstate driver is not in active
use (Qianheng Peng)
- Replace sprintf() with sysfs_emit() in sysfs show in the cpufreq
schedutil governor and fix a self-contradictory comment in
sugov_iowait_apply() (Zhongqiu Han)
- Fix the usage example for the sampling_rate tunable of the ondemand
cpufreq governor in admin-guide (wangxiaodong)
* pm-cpufreq: (40 commits)
cpufreq: imx6q: fix out-of-bounds write when probed more than once
cpufreq: imx6q: fix devres accumulation across driver rebind
rust: cpufreq: Fix temporary write in Registration::bios_limit_callback
rust: cpufreq: Add CPUFREQ_TABLE_END as last table entry in TableBuilder::to_table
cpufreq: intel_pstate: Adjust policy->cur in active mode to policy
cpufreq/amd-pstate: Document missing kernel-doc members
cpufreq/amd-pstate-ut: Add unit test for CPPC Performance Priority
cpufreq/amd-pstate-ut: Add unit test for "dynamic" EPP mode
cpufreq/amd-pstate: Reduce the scope of exported symbols
Documentation/amd-pstate: Update dynamic_epp documentation with new behavior
cpufreq/amd-pstate: Remove "amd_dynamic_epp" cmdline and "dynamic_epp" sysfs
cpufreq/amd-pstate: Add dynamic EPP as an "energy_performance_preference" mode
cpufreq/amd-pstate: Extract platform profile to EPP conversion into a helper
cpufreq/amd-pstate: Remove the defensive check for bios_min_perf
cpufreq/amd-pstate: Set min_limit_freq based on bios_min_perf
cpufreq: apple-soc: Calculate frequency as a 64-bit value
kselftest: cpufreq: Backup and restore governor for sptests
selftests/cpufreq: Remove unnecessary sudo from quick_shuffle()
selftests/cpufreq: Remove unused local variables from switch_show_governor()
cpufreq/amd-pstate: handle missing policy in dynamic EPP callbacks
...
When building the kernel, the following Rust symbols are generated:
$ nm vmlinux | grep ' _R' | rustfilt | grep -E 'pci::Device.*(inc_ref|dec_ref)'
... T <kernel::pci::Device as kernel::sync::aref::AlwaysRefCounted>::dec_ref
... T <kernel::pci::Device as kernel::sync::aref::AlwaysRefCounted>::inc_ref
These Rust symbols are trivial wrappers around pci_dev_put() and
pci_dev_get(), respectively. It doesn't make sense to go through a
trivial wrapper for these functions, so mark them inline.
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Link: https://github.com/Rust-for-Linux/linux/issues/1145
Signed-off-by: Ethan Plant <plant.ethan@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260804-inline-wrappers-v1-1-16916db867e5@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The `dma_handle` naming is inherited from the C API, but what this
really describes is the device DMA address; everything named
`dma_handle` is actually a `dma_addr_t`.
This naming introduces some confusion on the Rust API side, as handles
are supposed to be opaque tokens, yet we were doing address computation
on values returned by `dma_handle`.
Rename `dma_handle` to `dma_address` while nova-core is still its only
user.
Suggested-by: John Hubbard <jhubbard@nvidia.com>
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/all/DK75LUA4NLGI.3P29AIZQE20V2@kernel.org/
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Link: https://patch.msgid.link/20260805-falcon-dma-projections-v2-2-4cc9f3f13ee9@nvidia.com
[ Rebase and fix up build failures due to newly introduced dma_handle()
calls. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The doc examples in io.rs and devres.rs directly call
bindings::ioremap() and bindings::iounmap(), which do not exist when
CONFIG_HAS_IOMEM is not set. This causes build failures with
CONFIG_RUST_KERNEL_DOCTESTS=y on such configurations (e.g. s390
allnoconfig).
Gate the affected doctests with `#![cfg(CONFIG_HAS_IOMEM)]` so they are
skipped when IOMEM is unavailable.
Fixes: 3f70ebe638 ("s390: Enable Rust support")
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260805212920.1996937-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
s390 does not provide ioremap()/iounmap() when CONFIG_HAS_IOMEM is not
set (which requires CONFIG_PCI on that architecture). This causes a
build failure with Rust enabled on e.g. s390 allnoconfig:
In file included from rust/helpers/helpers.c:68:
rust/helpers/io.c:8:9: error: call to undeclared function 'ioremap'; ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
8 | return ioremap(offset, size);
| ^
rust/helpers/io.c:19:2: error: call to undeclared function 'iounmap'; ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
19 | iounmap(addr);
Guard the C helpers behind #ifdef CONFIG_HAS_IOMEM and cfg-gate the Rust
io::mem module, such that IoMem, ExclusiveIoMem and IoRequest are not
available without CONFIG_HAS_IOMEM.
Note that the C API is inconsistent about this. For instance,
devm_ioremap() has no stub and produces a link failure without
CONFIG_HAS_IOMEM, whereas devm_platform_ioremap_resource() provides an
inline stub returning -EINVAL.
The approach taken here (compile-time gating) matches the former, which
is slightly more appropriate since any driver performing MMIO currently
requires CONFIG_HAS_IOMEM.
Ideally, s390 should provide ioremap()/iounmap() stubs unconditionally
(as UML already does), removing the need for any config gating as
discussed in [1]; a follow-up patch for s390 is expected.
Cc: Arnd Bergmann <arnd@arndb.de>
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://lore.kernel.org/all/20260803180931.97202-1-ojeda@kernel.org [1]
Fixes: 3f70ebe638 ("s390: Enable Rust support")
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260805212920.1996937-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add support for parsing boolean module parameters in the Rust
module! macro.
Currently, only integer types are supported by the `module_param!`
macros. This patch implements the `ModuleParam` trait for `bool`
by delegating the string parsing to the existing C implementation
via `kstrtobool_bytes()`. It also wires up `PARAM_OPS_BOOL` so that
the Rust parameter system correctly links to the C `param_ops_bool`
structure.
For demonstration and verification, a boolean parameter is added
to `samples/rust/rust_minimal.rs`.
Support for boolean parameters will initially be used by the Rust
null block driver [1].
Link: https://lore.kernel.org/all/20260609-rnull-v6-19-rc5-send-v2-4-82c7404542e2@kernel.org/ [1]
Assisted-by: Codex:GPT-5
Signed-off-by: Wenzhao Liao <wenzhaoliao@ruc.edu.cn>
Tested-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://lore.kernel.org/linux-modules/20260411130254.3510128-1-wenzhaoliao@ruc.edu.cn/
[ppavlu: add motivation to the commit message and rebase the patch]
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
For `Copy` parameter types it is more ergonomic to retrieve the
parameter value by copy than through a shared reference. Change
`ModuleParamAccess::value` to return `T` by copy when `T: Copy`,
and rename the previous reference-returning accessor to
`value_ref`. Update the in-tree caller in `rust_minimal`.
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
- Minor fixes / cleanups in cpufreq drivers (Dan Carpenter, Guru Das
Srinagesh, Haoxiang Li, Karl Mehltretter, Sasha Finkelstein, and Pan
Chuang).
- Fix cpufreq table creation and bios_limits() callback in the Rust
bindings (Priya Bala Govindasamy).
- Add IPQ5210 support to qcom-nvmem driver (Varadarajan Narayanan).
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEx73Crsp7f6M6scA70rkcPK6BEhwFAmp0KYAACgkQ0rkcPK6B
Ehxsow/+IrqGfGqroec6PCnK+oCSCgRTcgoXDk01A8lHH2yS9wHv08sW9r1yxCrY
DVCgV5M8u2w/Q5/6Zop9JalliV8MVom5zlbeMnc5kgybH9ZRZWI0KhkMH9pNIBaI
ZLlNjcldt7k/pZoRUhJSDEbMKAUZvb2t607UzcPLjBsibHdUil+KGrwT5GkaUnCu
AkjXNRd3Tjt39NgRBzUhHvMAx4pUftw80G7ic+leKL+D9OAWsZUTMy9wyv/NoMIj
jZwWr5knrYJn7nYiMgcc0+GCGsALOfwKCqsYscfhA6KoHmkkLxvyW/xH1e5uIUPT
S3h6SDKzarTYfA5rTkxY0OD+ZacYrxGsXSvnakBWxqR4IW82XDIdWom66HteKJPE
6bDFTnzOsdDpmTVJZVhZ2WljxcKrgQW95q8tNS3TuQOYHQNmtD4LnV11Zjvwwt5w
pEL9QghiCfLg76Yf5pOafvifK+LYCCdteCYygImPBWc2Ih0XJX5KdV7fhTIPbSyS
iaH/4bVgec7Sdkt8/bgW5qCyd/nXJpqx4KV9akp6lBMfEQtSiZ5fGOzAMtAOTaLS
k03UC3H983uAVHzwD4d+nb5yeKm/0Xi7vxx9Lz9gCncyo+V6Oj2FefB38wkgO1Ou
wu+CpqeOSBTjEEwR2HoL3Js6/cFKqGtP9RwsJC0eimBhJNNntr8=
=9e9M
-----END PGP SIGNATURE-----
Merge tag 'cpufreq-arm-updates-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm
Pull CPUFreq Arm updates for 7.3 from Viresh Kumar:
"- Minor fixes / cleanups in cpufreq drivers (Dan Carpenter, Guru Das
Srinagesh, Haoxiang Li, Karl Mehltretter, Sasha Finkelstein, and Pan
Chuang).
- Fix cpufreq table creation and bios_limits() callback in the Rust
bindings (Priya Bala Govindasamy).
- Add IPQ5210 support to qcom-nvmem driver (Varadarajan Narayanan)."
* tag 'cpufreq-arm-updates-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
cpufreq: imx6q: fix out-of-bounds write when probed more than once
cpufreq: imx6q: fix devres accumulation across driver rebind
rust: cpufreq: Fix temporary write in Registration::bios_limit_callback
rust: cpufreq: Add CPUFREQ_TABLE_END as last table entry in TableBuilder::to_table
cpufreq: apple-soc: Calculate frequency as a 64-bit value
cpufreq: spear: Fix an IS_ERR() vs NULL bug in spear1340_set_cpu_rate()
cpufreq: brcmstb-avs: Remove redundant dev_err()
rust: rcpufreq_dt: use vertical import style
cpufreq: apple-soc: Fix OPP table cleanup
cpufreq: qcom-nvmem: Add IPQ5210 support
In `Registration::bios_limit_callback`, the expression
`&mut (unsafe { *limit })` creates a reference to a temporary copy
of the value pointed to by `limit` on the stack.
Therefore, writes made by `T::bios_limit` go to this temporary
instead of the memory location pointed to by `limit`.
Additionally, `limit` may be uninitialized, such as when
`Registration::bios_limit_callback` is invoked by `show_bios_limit`
in drivers/cpufreq/cpufreq.c. Therefore creating a reference to
`limit` is unsound.
Fix this by changing the signature of `T::bios_limit` to return the limit
value.
`Registration::bios_limit_callback` can then update `limit` directly.
Fixes: c6af9a1191 ("rust: cpufreq: Extend abstractions for driver registration")
Reported-by: Dylan Zueck<dzueck@uci.edu>
Reported-by: Yuan Tan<ytan089@ucr.edu>
Assisted-by: ChatGPT:gpt-5.4
Signed-off-by: Priya Bala Govindasamy<pgovind2@uci.edu>
[ Viresh: Fix rustfmtcheck warning ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
The `TableBuilder::to_table` function adds `Hertz(c_ulong::MAX).as_khz()`
as the last frequency entry in the frequency table.
But the C API expects the last entry to have frequency set to
`CPUFREQ_TABLE_END` which is `~1u` as per include/linux/cpufreq.h.
Fix this by setting the last frequency entry to `CPUFREQ_TABLE_END`
instead of `Hertz(c_ulong::MAX).as_khz()`.
Fixes: 2207856ff0 ("rust: cpufreq: Add initial abstractions for cpufreq framework")
Reported-by: Dylan Zueck<dzueck@uci.edu>
Reported-by: Yuan Tan<ytan089@ucr.edu>
Assisted-by: ChatGPT:gpt-5.6-terra
Signed-off-by: Priya Bala Govindasamy<pgovind2@uci.edu>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Add request_into_buf(), a Rust wrapper around the
request_firmware_into_buf() function. This variant loads the firmware
image directly into a caller-provided buffer rather than a
kernel-allocated one.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260731201017.2580713-3-ttabi@nvidia.com
[ Declare fw as *const to match the FFI out-parameter type and pass
&raw mut directly, removing the redundant cast chain. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a constructor for kernel Vec that allocates a vector of a given length
with all elements zero-initialized. Memory is allocated with the __GFP_ZERO
flag, matching the existing KBox::zeroed() pattern.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260731201017.2580713-2-ttabi@nvidia.com
Co-developed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The `__init` method is not designed to be a public API (existence of "__"
is a hint for this); replace users with `pin_init::raw_[try_]init` which
does the same thing.
There are a few users of `__init` which are replaced as well.
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260729-merge-init-v2-4-26adf47109e7@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
Adapt the IRQ registration to work with the Higher-Ranked Lifetime Types
(HRT) device driver architecture introduced in commit 2c7c659336
("Merge patch series "rust: device: Higher-Ranked Lifetime Types for
device drivers"").
With HRT, driver structs carry a lifetime parameter tied to the device
binding scope, allowing device resources such as pci::Bar<'bar> to be
held directly rather than through Devres indirection. However, the IRQ
abstraction required Handler: Sync + 'static, preventing handlers from
embedding lifetime-parameterized resources.
Remove the 'static bound from Handler and ThreadedHandler and replace
the Devres<RegistrationInner> indirection with direct request_irq() /
free_irq() calls in the constructor and PinnedDrop. Registration<'a, T>
stores the IrqRequest<'a>, which structurally ties it to the device
binding scope.
Also remove the &Device<Bound> parameter from the handler callbacks,
since handlers that need device access can embed it in their own type.
IRQ handlers can now directly own device resources:
struct IrqHandler<'irq> {
bar: pci::Bar<'irq, BAR_SIZE>,
}
impl irq::Handler for IrqHandler<'_> {
fn handle(&self) -> IrqReturn {
let stat = self.bar.read(regs::STAT);
...
}
}
This eliminates the indirection previously required for IRQ handlers to
access device resources and aligns with the broader goal of expressing
every registration scoped to a driver binding through compile-time
lifetime bounds.
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260719153631.559341-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Kernel code should use LKMM atomics. The existing code is `AtomicBool`
with the need to use `xchg`, so convert it to `AtomicFlag`.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Signed-off-by: Boqun Feng <boqun@kernel.org>
Link: https://patch.msgid.link/20260716145536.3681630-1-gary@kernel.org
Implement a generic interface for memory barriers (full system/DMA/SMP).
The interface uses a parameter to force user to specify their intent
with barriers.
Provide `Read`, `Write`, `Full` orderings which map to the existing
`rmb()`, `wmb()` and `mb()`. Generic is used here instead of providing
individual standalone functions to reduce code duplication; for example,
the `CONFIG_SMP` check in `smp_mb` is uniformly implemented for all SMP
barriers. This could extend to `virt_mb`'s if they're introduced in the
future. It would also make it easier if new ordering types are
introduced in the future (e.g. `Acquire`, `Release`).
Signed-off-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Boqun Feng <boqun@kernel.org>
Link: https://patch.msgid.link/20260609-rust-barrier-v2-2-30fcc48e1cd0@garyguo.net
We now have a safe wrapper for the foreign function synchronize_rcu().
Use it in poll.rs.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Boqun Feng <boqun@kernel.org>
Link: https://patch.msgid.link/20260624150704.1504001-5-phasta@kernel.org
We now have a safe wrapper for the foreign function synchronize_rcu().
Use it in revocable.rs.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Boqun Feng <boqun@kernel.org>
Link: https://patch.msgid.link/20260624150704.1504001-4-phasta@kernel.org
synchronize_rcu() is a frequently used C function which is always safe
to be called.
Add a safe abstraction for synchronize_rcu().
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
[boqun: Fix rustdoc reported by kernel test robot <lkp@intel.com>]
Signed-off-by: Boqun Feng <boqun@kernel.org>
Link: https://patch.msgid.link/20260624150704.1504001-3-phasta@kernel.org
The expansion serves little purpose and it can easily diverge.
Acked-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260629-id_info-v2-5-56fccbe9c5ef@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The destination of an alias is always another register, i.e. a `struct`
type. Replace the `ident` fragment with a `path` one in the internal
rules: `path` is more accurate, and allows referencing registers using a
qualified path instead of only identifiers visible from the current
module.
This covers all aliases, except the relative register ones which are to
be removed soon.
The public rule cannot be updated yet because a `+` can still be matched
after the alias; add a TODO item to update it after relative registers
are removed.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260724-registers_fix-v2-3-a0fb58b02185@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
A few arguments passed to internal rules are never used and just add
unneeded complexity. Remove them to simplify the rules a bit.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260724-registers_fix-v2-2-a0fb58b02185@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
A couple of shortcut rules redispatch an already normalized declaration
through the public register! entry point. This is unneeded - the public
rule should only be invoked by users.
Dispatch directly to the appropriate internal @reg rule instead.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260724-registers_fix-v2-1-a0fb58b02185@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The previous implementation used an `unsafe` block to manually cast Vec's
slice to a &[u8] using `core::slice::from_raw_parts`. Instead, the
implementation can be implemented in safe rust using zerocopy's trait
functions `as_bytes()` and `as_mut_bytes()`, respectively, and making use
of deref coercion to implicitly cast Vec to &[T] as `FromBytes` and
`IntoBytes` automatically are implemented on [T] when they are implemented
on T.
Signed-off-by: Josef Ippisch <josef.ippisch.dev@mailbox.org>
Link: https://patch.msgid.link/20260728-migrate-binarywriter-to-zerocopy-intobytes-v2-2-0a4ec1d3ead4@mailbox.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Migrate `BinaryWriter` and `BinaryReaderMut`'s default implementation's
requirements on T from `kernel::transmute` traits to `zerocopy` traits.
The additional `zerocopy::Immutable` requirement on `BinaryWriter` does not
further restrict the types in practice but is rather a more explicit
requirement (that the type does not have interior mutability) and is
required by zerocopy for the `as_bytes()` function.
Suggested-by: Joshua Liebow-Feeser <joshlf@google.com>
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/975
Link: https://github.com/Rust-for-Linux/linux/issues/1241
Signed-off-by: Josef Ippisch <josef.ippisch.dev@mailbox.org>
Link: https://patch.msgid.link/20260728-migrate-binarywriter-to-zerocopy-intobytes-v2-1-0a4ec1d3ead4@mailbox.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Previously, `IdArray` contains both device ID table and info table so we
keep a separate copy for MODULE_DEVICE_TABLE for hotplug (which needs to be
just the device ID table). With the info being changed to be carried via
pointers, `IdArray` is now layout compatible with raw ID table and hence
there is no longer a need to keep the distinction.
Deduplicate the code, and remove the redundant copy for hotplug purpose by
just giving the `IdArray` instance a proper symbol name.
While at it, also update the macro to use `::core::line!()` instead of just
`line!()`.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260629-id_info-v2-10-56fccbe9c5ef@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
With device ID info now including pointers instead of indices, the
open-coded ACPI/OF matching is no longer needed and can be replaced with
`device_get_match_data`.
With the removal of open-coded matching, the exposed functions and helpers
are also removed; this effectively reverts most of commit 2690d07158
("rust: ACPI: fix missing match data for PRP0001").
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260629-id_info-v2-9-56fccbe9c5ef@garyguo.net
[ Consider the serdev code merged in the meantime. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The common practice in C drivers is to store pointers into `driver_data`
field of device IDs. The Rust code is however currently storing indices
into the fields and then carry a side table that maps the index to
pointers.
It is much simpler to just have `DeviceId` carry the pointer like C code
does. However, just doing so naively would cause a "pointers cannot be cast
to integers during const eval" error, as kernel_ulong_t does not have
provenance while pointers do, and Rust forbids `expose_provenance` during
consteval.
Work around this limitation by wrapping raw IDs in `MaybeUninit`.
`MaybeUninit` is allowed to host arbitrary bytes with or without
provenance, so we can just then use `unsafe` to store a pointer with
provenance there. This has the same effect as changing the C-side
definition to use `void*` instead of `kernel_ulong_t`, but without actually
changing the C side.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260629-id_info-v2-8-56fccbe9c5ef@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Wrap the generated code in a `const _: ()` block to avoid symbol conflict.
This removes the need of creating a new identifier.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260629-id_info-v2-7-56fccbe9c5ef@garyguo.net
[ Consider the serdev code merged in the meantime. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Move the `IdArray` creation from individual buses to be handled by shared
code in `device_id.rs`.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260629-id_info-v2-6-56fccbe9c5ef@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
It is possible that ID without driver_data will be passed to the driver,
e.g. `new_id` is used to dynamically create a new ID without data.
Therefore, the driver must be able to handle the case where `driver_data`
is 0. Thus, update the `probe` functions to get `Option`.
The current code cannot tell if the info does not exist or is the first
entry; however this will be achievable once the code is updated to use a
`&'static IdInfo` pointer instead of indices.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260629-id_info-v2-4-56fccbe9c5ef@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
It is possible that `pci_device_id_any` will be passed to the driver, e.g.
`driver_override` is used on the device. Therefore, the driver must be able
to handle the case where `driver_data` is 0. Thus, update the `probe`
functions to get `Option`.
The current code cannot tell if the info does not exist or is the first
entry; however this will be achievable once the code is updated to use a
`&'static IdInfo` pointer instead of indices.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260629-id_info-v2-3-56fccbe9c5ef@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
This method can very easily construct the `IdArray` on its own without
delegating to `Self::build`. Doing so also simplifies the phy device table
macro because it does not need to construct tuples anymore.
This also allows simplification of `new` and `build` which removes the
`unsafe`.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260629-id_info-v2-2-56fccbe9c5ef@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Currently, using a raw IoPageTable is unsafe because the returned
IoPageTable is not tied to the device driver binding lifetime.
Since device drivers now receive a lifetime parameter <'bound>
representing the interval during which a device driver is bound to its bus
device, add a lifetime parameter to IoPageTable. This ensures that
the returned IoPageTable cannot outlive the bus device binding.
Also remove the option to create a page table as a device resource since
currently Devres is not compatible with resources that have a lifetime
parameter. This option can be restored once the lifetime-aware
wrapper for devres is available and if a use-case appears for it.
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Joerg Roedel <joerg.roedel@amd.com>
Link: https://patch.msgid.link/20260703-pgtable_lt_b4-v3-1-e738e1f513a4@collabora.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
We need the char/misc fixes AND this resolves two merge conflicts in:
drivers/android/binder/thread.rs
drivers/misc/nsm.c
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Implement the basic serial device bus abstractions required to write a
serial device bus device driver with or without the need for initial device
data. This includes the following data structures:
The `serdev::Driver` trait represents the interface to the driver.
The `serdev::Device` abstraction represents a `struct serdev_device`.
In order to provide the Serdev specific parts to a generic
`driver::Registration` the `driver::RegistrationOps` trait is
implemented by `serdev::Adapter`.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Markus Probst <markus.probst@posteo.de>
Link: https://patch.msgid.link/20260718-rust_serdev-v16-1-5809384d2e1b@posteo.de
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Expose pci_sriov_get_totalvfs() to Rust PCI drivers so they can query
how many SR-IOV VFs a device supports.
Use a conditional C helper because the !CONFIG_PCI_IOV version of
pci_sriov_get_totalvfs() is a static inline function and is therefore
not emitted into the Rust bindings. Return Option<NonZero<u16>> so Rust
callers must handle the zero value that represents unavailable SR-IOV.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: David Laight <david.laight.linux@gmail.com>
Cc: Gary Guo <gary@garyguo.net>
Cc: linux-pci@vger.kernel.org
Link: https://lore.kernel.org/all/DJHPRE4TGGT8.BUTMYOF5YE05@nvidia.com/
Signed-off-by: Zhi Wang <zhiw@nvidia.com>
Link: https://patch.msgid.link/20260722073913.1807677-3-zhiw@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Due to the usage of `build_assert!` for address validity checking, these
accessors want constant offsets. Non-constant offsets can work but it
depend on compiler optimization levels, so it should be avoided.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260716142545.3622278-1-gary@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Currently the lifetime on `Core` and `CoreInternal` is covariant. This
means that they can be coerced into shorter living lifetimes. On `probe`
function, signature has `&'bound Device<Core<'a>>`; the type's wellformness
would imply `'a: 'bound` and thus the type can be coerced `&'bound
Device<Core<'bound>>`, defeating the purpose of having the lifetime bound
to prevent users of the `Core` type to escape the function.
Fix this by making the lifetime invariant, so the coercion is impossible.
The lifetime here only needs to be "branded" so it does not coerce or unify
with other lifetimes, so we do not need to ensure `'bound: 'a`.
This requires modifying `nova-core` which relies on this implied bound due
to pre-2024 capture rule. The "use" bound can be removed if built with
edition 2024.
Fixes: 24799831d6 ("rust: device: make Core and CoreInternal lifetime-parameterized")
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260713201455.640151-1-gary@kernel.org
[ Fixup the debugfs sample to use an explicit lifetime instead of
Core<'_>. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
With CONFIG_CC_OPTIMIZE_FOR_SIZE, the address validity check in non-const
`read8` invocaction is not optimized away, leading to build failure.
Fixes: d055768429 ("rust: drm: gem: shmem: Add vmap functions")
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260716142545.3622278-2-gary@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The ceiling-division idiom `(n + d - 1) / d` only produces the
correct result when `n` is non-negative.
For example, if n = -1000 (exactly -1us), the old code computed (-1000
+ 999) / 1000 == 0 instead of -1.
For negative n, truncating division already rounds towards positive
infinity, so no bias is needed in that case.
Fixes: fae0cdc123 ("rust: time: Introduce Delta type")
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260713225235.3243480-1-tomo@flapping.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Move drvdata_borrow() from impl Device<CoreInternal<'a>> to
impl<Ctx: InternalBoundContext> Device<Ctx>, making it available from
both CoreInternal and BoundInternal contexts.
Fold drvdata_unchecked() (previously on Device<Bound>) directly into
drvdata_borrow(), since it was only called from there and the generic
context cannot resolve methods through the deref chain.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-By: Markus Probst <markus.probst@posteo.de>
Link: https://patch.msgid.link/20260530132736.3298549-2-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a new BoundInternal device context type for cases where bus
abstractions need access to internal device infrastructure, where
CoreInternal would not be justified.
Introduce the InternalBoundContext marker trait, implemented by both
CoreInternal and BoundInternal, to allow methods that require internal
bus abstraction access to a bound device to be generic over both
contexts.
The deref hierarchy now has two branches:
- CoreInternal<'a> => Core<'a> => Bound => Normal
- BoundInternal => Bound => Normal
Update impl_device_context_deref! and impl_device_context_into_aref!
macros to emit the BoundInternal => Bound deref and the corresponding
ARef conversion.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-By: Markus Probst <markus.probst@posteo.de>
Link: https://patch.msgid.link/20260530132736.3298549-1-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The `Firmware` example crafts an `ARef<Device>` using a null pointer,
which breaks the safety requirements of `Device::get_device()`.
Instead, pass an `ARef` via a parameter, which is simpler, avoids UB
and removes an `unsafe` block.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260711180231.229525-1-ojeda@kernel.org
[ Also drop the second superfluous empty line. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The write_iter callback consumes data from the supplied iov_iter and
wraps it as an IovIterSource.
Its Safety docs required a valid iov_iter for writing, but the
implementation and the IovIterSource contract require one that is valid
for reading. Update the docs to match that direction.
Assisted-by: Codex:GPT-5
Signed-off-by: Yilin Chen <1479826151@qq.com>
Link: https://patch.msgid.link/tencent_8CD671E0F35223030143524D045F3BCAD506@qq.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rust Binder currently uses PollCondVar, but it calls synchronize_rcu()
in the destructor, which we would like to avoid. Add a variation of
PollCondVar that kfree_rcu() instead.
One could avoid the `rcu` field and allocate the rcu_head on drop using
a fallback to synchronize_rcu() on ENOMEM. However, I'd prefer to avoid
the potential for synchronize_rcu(), and Binder will only use this for a
small fraction of processes, so even if it changes which kmalloc bucket
it falls into, the extra memory is not a problem.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Boqun Feng <boqun@kernel.org>
Link: https://patch.msgid.link/20260707-upgrade-poll-v6-1-4b8fae7bf1d9@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This implements a safe and relatively simple API over the netlink API,
that allows you to add different attributes to a netlink message and
broadcast it. As the first user of this API only makes use of broadcast,
only broadcast messages are supported here.
This API is intended to be safe and to be easy to use in *generated*
code. This is because netlink is generally used with yaml files that
describe the underlying API, and the python generator outputs C code
(or, soon, Rust code) that lets you use the API more easily. So for
example, if there is a string field, the code generator will output a
method that internall calls `put_string()` with the right attr type.
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Carlos Llamas <cmllamas@google.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260707-binder-netlink-v7-2-42b40e4b1ac8@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To ensure that networking code can be found in a single shared place,
add it to the relevant NETWORKING entry. The net.rs file is moved into
the net/ directory so that it's included under the MAINTAINERS entry
without needing a separate rust/kernel/net.rs entry.
Reviewed-by: Carlos Llamas <cmllamas@google.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260707-binder-netlink-v7-1-42b40e4b1ac8@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Implement a dynamic debug logging mask (`debug_mask`) for the
`rust_binder` module to allow dynamic runtime configuration of log
levels. This enables parity with the legacy C driver's debug mask.
Since the Rust `module!` macro in the current kernel build does not
yet support declaring module parameters directly in Rust, we define
the `debug_mask` variable in Rust as an `Atomic<u32>` exported via
FFI using `#[no_mangle]`, and link to it as `extern` in a C companion
file to expose it to the kernel runtime.
To verify the setup, instrument process lifecycle events (open, flush,
and release) in `process.rs` under the new `BINDER_DEBUG_OPEN_CLOSE`
logging mask. These entry-point events are chosen for initial validation
because they represent the start of the Binder lifecycle and occur
at low frequency, allowing simple runtime verification of the dynamic
toggle without log noise.
Reviewed-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Jahnavi MN <jahnavimn@google.com>
Link: https://patch.msgid.link/20260716-rust_binder_debug_mask-v4-1-3d7436c2d2f2@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When building the kernel using llvm-19.1.7-rust-1.85.1-x86_64, the
following symbols are generated:
$ nm vmlinux | grep ' _R'.*usb.*Device | rustfilt
...
ffffffff823f2490 T <kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::dec_ref
ffffffff823f2470 T <kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::inc_ref
...
$ nm vmlinux | grep ' _R'.*usb.*Interface | rustfilt
ffffffff823f2450 T <kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::dec_ref
ffffffff823f2430 T <kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::inc_ref
...
However, these Rust symbols are trivial wrappers around the
`usb_get_dev`, `usb_put_dev`, `usb_get_intf` and `usb_put_intf`
functions. It doesn't make sense to go through a trivial wrapper
for these functions.
Link: https://github.com/Rust-for-Linux/linux/issues/1145
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260616223614.16444-1-nico.antinori.7@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These macros are used like expressions, so they should not emit a
semicolon. This is being turned into a hard error in a future release of
Rust.
error: trailing semicolon in macro used in expression position
--> drivers/gpu/nova-core/firmware/fsp.rs:79:34
|
79 | .inspect_err(|_| dev_err!(dev, "FMC firmware missing '{}' section\n", name))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
= note: this error originates in the macro `dev_err` (in Nightly builds, run with -Z macro-backtrace for more info)
[ I was doubly surprised since upstream made it a deny-by-default lint
a year ago for Rust 1.91.0, and yet we didn't see it; plus I hadn't
seen this in my CI even yesterday.
It turns out this just landed into today's nightly (nightly-2026-07-16,
using upstream commit d0babd8b6):
Link: https://github.com/rust-lang/rust/pull/159222
which says:
"The `semicolon_in_expressions_from_macros` lint previously
suppressed warnings about non-local macros. This masks
a lint that will subsequently become a hard error."
So that explains it. And this is the PR that will make it a hard error
at some point in the future:
Link: https://github.com/rust-lang/rust/pull/159218
Thus starting with Rust 1.99.0 (expected 2026-10-01), we will be
seeing the deny-by-default lint above, so clean it up already.
- Miguel ]
Cc: stable@vger.kernel.org # Needed in 6.18.y and later.
Link: https://github.com/rust-lang/rust/issues/79813
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://github.com/rust-lang/rust/pull/159218
Link: https://github.com/rust-lang/rust/pull/159222
Link: https://patch.msgid.link/20260716-device-trail-semicolon-v1-1-f48e9dcfae15@google.com
[ Fixed typo. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add a Rust abstraction for sleepable RCU (SRCU), backed by C srcu_struct.
Provide FFI helpers and a safe wrapper with a guard-based API for read-side
critical sections.
Cleanup is handled via `PinnedDrop`. It first checks for active read-side
sections and emits a warning if any guards were leaked. In that case, it
waits in `synchronize_srcu()` rather than risking a UAF by freeing the
`srcu_struct` that is still reachable from the C side. It then uses
`srcu_barrier()` to drain pending callbacks before finally calling
`cleanup_srcu_struct()`.
Signed-off-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Boqun Feng <boqun@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
In some cases, the processor may not actually stick to the "desired"
performance level programmed through the driver's .adjust_perf()
callback and may go above it, which may not be desirable (for instance,
there may be a UCLAMP_MAX limit set for the task currently running on
the given CPU which should be respected).
Address that by adjusting the .adjust_perf() callback to take an
additional argument, max_perf, representing the maximum allowed
performance level of the CPU and update the intel_pstate driver to
take that argument into account as appropriate.
Accordingly, adjust cpufreq_driver_adjust_perf() and the other existing
user of .adjust_perf(), which is the amd-pstate driver (but the behavior
of that driver is not changed).
While at it, also update the cpufreq_driver_adjust_perf()
documentation to reflect this change and some previous code
changes that have not been taken into account in it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/6277654.lOV4Wx5bFT@rafael.j.wysocki
[ rjw: Adjusted Rust function formatting ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Now that the revocation Completion is in place, also address the
symmetric case. When Devres::drop() wins the is_available swap and the
devres callback loses, the callback returns to devres_release_all()
without waiting. This means device unbinding can complete while
Devres::drop() is still executing drop_in_place() on another CPU, which
is a problem if T's destructor accesses device state.
Make the synchronization bidirectional. Whichever side performs
drop_in_place() signals the Completion, and the other side waits.
This does not reintroduce the nested Devres deadlock fixed by commit
ba268514ea ("rust: devres: fix race condition due to nesting"),
because that deadlock was caused by drop waiting for the release
callback to return (the old 'devm' Completion). Here, both sides only
wait for drop_in_place() to finish, which completes within the current
call chain. The Arc<Inner<T>> keeps the Inner allocation alive
independently.
Cc: stable@vger.kernel.org
Fixes: ba268514ea ("rust: devres: fix race condition due to nesting")
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260628200304.2365598-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
There is a potential race condition when two paths try to revoke a
Devres concurrently.
The driver core's devres_release_all() calls Revocable::revoke() via the
release callback, while Devres::drop() calls revoke_nosync() on another
CPU.
The revoker that does not claim the is_available swap returns
immediately, but the revoker that did may still be executing
drop_in_place() on the inner data. This can cause a use-after-free when
the other revoker's caller proceeds to drop adjacent resources that
drop_in_place() still references (e.g., Devres<DmaMappedSgt> racing with
SGTable freeing the backing sg_table and pages).
Fix this by adding a Completion. The release callback signals the
Completion after revoke() finishes, and Devres::drop() waits for it when
it loses the is_available swap. This ensures the wrapped object is fully
torn down before Devres::drop() returns.
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/dri-devel/20260612202841.2577C1F000E9@smtp.kernel.org/
Fixes: 05aa6fb1c2 ("rust: scatterlist: Add abstraction for sg_table")
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260628174451.2275679-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
This series presents a major rework of I/O types, as a summary:
- Make I/O regions typed. The existing untyped region still exists
with a dynamically sized `Region` type.
- Create I/O view types to represent subregion of a full I/O region mapped.
A projection macro is added to allow safely create such subviews.
- Split I/O traits, make I/O views play a central role, avoid
duplicate monomorphization and less `unsafe` code.
- Add a `SysMem` backend, and make `Coherent` implement `Io`.
- Add copying methods (memcpy_{from,to}io and friends).
This series generalize `Mmio` type from just an untyped region to typed
representations (so `MmioRaw<T>` is `__iomem *T`). This allows us to remove
the `IoKnownSize` trait; the information is sourced from just the pointer
from the `KnownSize` trait instead.
Building on top of that, `Mmio` and `ConfigSpace` have been converted to
typed views of I/O regions rather than just a big chunk of untyped I/O
memory. These changes made it possible to implement `Io` trait for
`Coherent<T>`.
Shared system memory, `SysMem` is also added to the series, given it
similarity in implementation compared to `Coherent`. In fact, the series
use `SysMem` to implement `Coherent`'s I/O methods.
Built on these generalization, this series add `io_project!()`.
`io_project!()` performs a safe way to project a bigger view to a small
subviews, and some Nova code has been converted in this series to
demonstrate cleanups possible with this addition.
New `io_read!()`, `io_write!()` has been added that supersedes
`dma_read!()`, `dma_write!()` macro. Although, they work for primitives
only (to be exact, types that the backend is `IoCapable` of).
One feature that was lost from the old `dma_read!()` and `dma_write!()`
series was the ability to read/write a large structs. However, the
semantics was unclear to begin with, as there was no guarantee about their
atomicity even for structs that were small enough to fit in u32.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Generic.20I.2FO.20backends/near/571198078
This is a stable tag for other trees to merge.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS2q/xV6QjXAdC7k+1FlHeO1qrKLgUCalVZTQAKCRBFlHeO1qrK
LtfZAP90BcixGO6G0L0UkyJ/f2yJz9wa2xD2lCwTvEnAxDa0EwEAzRxi9a/4CVOx
y5lnqkmV+ViRYDrSihy8r994+ADI8w0=
=+R8A
-----END PGP SIGNATURE-----
Merge tag 'rust-io-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core into drm-rust-next
I/O type generalization and projection
This series presents a major rework of I/O types, as a summary:
- Make I/O regions typed. The existing untyped region still exists
with a dynamically sized `Region` type.
- Create I/O view types to represent subregion of a full I/O region mapped.
A projection macro is added to allow safely create such subviews.
- Split I/O traits, make I/O views play a central role, avoid
duplicate monomorphization and less `unsafe` code.
- Add a `SysMem` backend, and make `Coherent` implement `Io`.
- Add copying methods (memcpy_{from,to}io and friends).
This series generalize `Mmio` type from just an untyped region to typed
representations (so `MmioRaw<T>` is `__iomem *T`). This allows us to remove
the `IoKnownSize` trait; the information is sourced from just the pointer
from the `KnownSize` trait instead.
Building on top of that, `Mmio` and `ConfigSpace` have been converted to
typed views of I/O regions rather than just a big chunk of untyped I/O
memory. These changes made it possible to implement `Io` trait for
`Coherent<T>`.
Shared system memory, `SysMem` is also added to the series, given it
similarity in implementation compared to `Coherent`. In fact, the series
use `SysMem` to implement `Coherent`'s I/O methods.
Built on these generalization, this series add `io_project!()`.
`io_project!()` performs a safe way to project a bigger view to a small
subviews, and some Nova code has been converted in this series to
demonstrate cleanups possible with this addition.
New `io_read!()`, `io_write!()` has been added that supersedes
`dma_read!()`, `dma_write!()` macro. Although, they work for primitives
only (to be exact, types that the backend is `IoCapable` of).
One feature that was lost from the old `dma_read!()` and `dma_write!()`
series was the ability to read/write a large structs. However, the
semantics was unclear to begin with, as there was no guarantee about their
atomicity even for structs that were small enough to fit in u32.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Generic.20I.2FO.20backends/near/571198078
This is a stable tag for other trees to merge.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
This series presents a major rework of I/O types, as a summary:
- Make I/O regions typed. The existing untyped region still exists
with a dynamically sized `Region` type.
- Create I/O view types to represent subregion of a full I/O region mapped.
A projection macro is added to allow safely create such subviews.
- Split I/O traits, make I/O views play a central role, avoid
duplicate monomorphization and less `unsafe` code.
- Add a `SysMem` backend, and make `Coherent` implement `Io`.
- Add copying methods (memcpy_{from,to}io and friends).
This series generalize `Mmio` type from just an untyped region to typed
representations (so `MmioRaw<T>` is `__iomem *T`). This allows us to remove
the `IoKnownSize` trait; the information is sourced from just the pointer
from the `KnownSize` trait instead.
Building on top of that, `Mmio` and `ConfigSpace` have been converted to
typed views of I/O regions rather than just a big chunk of untyped I/O
memory. These changes made it possible to implement `Io` trait for
`Coherent<T>`.
Shared system memory, `SysMem` is also added to the series, given it
similarity in implementation compared to `Coherent`. In fact, the series
use `SysMem` to implement `Coherent`'s I/O methods.
Built on these generalization, this series add `io_project!()`.
`io_project!()` performs a safe way to project a bigger view to a small
subviews, and some Nova code has been converted in this series to
demonstrate cleanups possible with this addition.
New `io_read!()`, `io_write!()` has been added that supersedes
`dma_read!()`, `dma_write!()` macro. Although, they work for primitives
only (to be exact, types that the backend is `IoCapable` of).
One feature that was lost from the old `dma_read!()` and `dma_write!()`
series was the ability to read/write a large structs. However, the
semantics was unclear to begin with, as there was no guarantee about their
atomicity even for structs that were small enough to fit in u32.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Generic.20I.2FO.20backends/near/571198078
This is a stable tag for other trees to merge.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS2q/xV6QjXAdC7k+1FlHeO1qrKLgUCalVZTQAKCRBFlHeO1qrK
LtfZAP90BcixGO6G0L0UkyJ/f2yJz9wa2xD2lCwTvEnAxDa0EwEAzRxi9a/4CVOx
y5lnqkmV+ViRYDrSihy8r994+ADI8w0=
=+R8A
-----END PGP SIGNATURE-----
Merge patch series "rust: I/O type generalization and projection"
Gary Guo <gary@garyguo.net> says:
This series presents a major rework of I/O types, as a summary:
- Make I/O regions typed. The existing untyped region still exists
with a dynamically sized `Region` type.
- Create I/O view types to represent subregion of a full I/O region mapped.
A projection macro is added to allow safely create such subviews.
- Split I/O traits, make I/O views play a central role, avoid
duplicate monomorphization and less `unsafe` code.
- Add a `SysMem` backend, and make `Coherent` implement `Io`.
- Add copying methods (memcpy_{from,to}io and friends).
This series generalize `Mmio` type from just an untyped region to typed
representations (so `MmioRaw<T>` is `__iomem *T`). This allows us to remove
the `IoKnownSize` trait; the information is sourced from just the pointer
from the `KnownSize` trait instead.
Building on top of that, `Mmio` and `ConfigSpace` have been converted to
typed views of I/O regions rather than just a big chunk of untyped I/O
memory. These changes made it possible to implement `Io` trait for
`Coherent<T>`.
Shared system memory, `SysMem` is also added to the series, given it
similarity in implementation compared to `Coherent`. In fact, the series
use `SysMem` to implement `Coherent`'s I/O methods.
Built on these generalization, this series add `io_project!()`.
`io_project!()` performs a safe way to project a bigger view to a small
subviews, and some Nova code has been converted in this series to
demonstrate cleanups possible with this addition.
New `io_read!()`, `io_write!()` has been added that supersedes
`dma_read!()`, `dma_write!()` macro. Although, they work for primitives
only (to be exact, types that the backend is `IoCapable` of).
One feature that was lost from the old `dma_read!()` and `dma_write!()`
series was the ability to read/write a large structs. However, the
semantics was unclear to begin with, as there was no guarantee about their
atomicity even for structs that were small enough to fit in u32.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Generic.20I.2FO.20backends/near/571198078
Link: https://patch.msgid.link/20260706-io_projection-v6-0-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The ForLt trait currently guarantees covariance, which allows safe
lifetime shortening via cast_ref(). However, some types (e.g. those
containing Mutex<&'bound T>) are invariant over their lifetime parameter
and cannot safely use cast_ref().
This series splits ForLt into two traits:
- ForLt: base trait for all lifetime-parameterized types, providing
only the Of<'a> GAT.
- CovariantForLt: unsafe subtrait that guarantees covariance,
providing a safe cast_ref() method.
For invariant types, a closure-based API (registration_data_with()) is
added to the auxiliary subsystem. The closure's HRTB prevents the caller
from choosing a concrete lifetime, which would be unsound for invariant
types.
On top of that, this series adds DevresLt<F: ForLt>, a thin wrapper
around Devres<F::Of<'static>> that shortens the stored 'static lifetime
back to the caller's borrow scope. DevresLt provides both closure-based
access (access_with/try_access_with for ForLt types) and direct
reference access (access/try_access for CovariantForLt types).
Also implement ForLt and CovariantForLt for Bar, IoMem and
ExclusiveIoMem, and update their into_devres() methods to return
DevresLt. Provide convenience type aliases DevresBar, DevresIoMem and
DevresExclusiveIoMem.
This is a stable tag for other trees to merge.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS2q/xV6QjXAdC7k+1FlHeO1qrKLgUCalVYCAAKCRBFlHeO1qrK
Lv66AQCcu91WcBr1jpsMOptgN6rfg9WRqzn4Z69X2dKRz4XZKwD/Z3ihPBAuoDr8
eqKjYG6cCV/qhEVgr0SctOO2xHVTVAE=
=iqDJ
-----END PGP SIGNATURE-----
Merge patch series "ForLt/CovariantForLt split, auxiliary closure API and DevresLt"
Danilo Krummrich <dakr@kernel.org> says:
The ForLt trait currently guarantees covariance, which allows safe
lifetime shortening via cast_ref(). However, some types (e.g. those
containing Mutex<&'bound T>) are invariant over their lifetime parameter
and cannot safely use cast_ref().
This series splits ForLt into two traits:
- ForLt: base trait for all lifetime-parameterized types, providing
only the Of<'a> GAT.
- CovariantForLt: unsafe subtrait that guarantees covariance,
providing a safe cast_ref() method.
For invariant types, a closure-based API (registration_data_with()) is
added to the auxiliary subsystem. The closure's HRTB prevents the caller
from choosing a concrete lifetime, which would be unsound for invariant
types.
On top of that, this series adds DevresLt<F: ForLt>, a thin wrapper
around Devres<F::Of<'static>> that shortens the stored 'static lifetime
back to the caller's borrow scope. DevresLt provides both closure-based
access (access_with/try_access_with for ForLt types) and direct
reference access (access/try_access for CovariantForLt types).
Also implement ForLt and CovariantForLt for Bar, IoMem and
ExclusiveIoMem, and update their into_devres() methods to return
DevresLt. Provide convenience type aliases DevresBar, DevresIoMem and
DevresExclusiveIoMem.
Link: https://patch.msgid.link/20260626183630.2585057-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Moving a GpuVaAlloc or GpuVmBo between threads currently forces drivers
to write their own unsafe Send and Sync impls. Provide the markers in
the abstraction instead.
GpuVaAlloc wraps only uninitialised memory and exposes none of it.
GpuVmBo hands out the driver data and GEM object by shared reference and
drops them in its deferred put; the DriverGpuVm trait already guarantees
both are Send + Sync, so both impls are unconditional.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://patch.msgid.link/20260611-gpuvm-sync-send-v4-2-6c7f4ab2778a@google.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
DriverGpuVm permitted !Send/!Sync associated data on an abstraction whose
handles are shared and dropped across threads: obtain() runs from many
threads and the VA API performs deferred cross-thread drops. That is
unsound.
Require Send + Sync on the trait and its associated data so the GpuVm and
UniqueRefGpuVm handle impls need no per-impl bounds.
Fixes: 82b78182ea ("rust: drm: add base GPUVM immediate mode abstraction")
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://patch.msgid.link/20260611-gpuvm-sync-send-v4-1-6c7f4ab2778a@google.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
IntoGEMObject::from_raw() receives a pointer to struct drm_gem_object,
not a pointer to Self. The previous documentation used Self even though
the function argument is the embedded GEM object pointer.
However, the pointer must not be any arbitrary valid drm_gem_object. The
implementations recover Self with container_of(), so the GEM object must
be embedded in a valid Self instance. This patch documents that requirement
explicitly.
Assisted-by: Codex:GPT-5
Signed-off-by: Yilin Chen <1479826151@qq.com>
Link: https://patch.msgid.link/tencent_4426892E62B77DEA2AE898E899A871940005@qq.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Pass registration data to ioctl handlers via
drm::Device<Registered>::registration_data_with(). The closure's HRTB
ties the lifetime to the closure scope, and the pointer cast shortens it
from 'static internally. The reference is valid for the duration of the
drm_dev_enter/exit critical section held by RegistrationGuard.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-19-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a RegistrationData GAT (Generic Associated Type) to drm::Driver.
The lifetime parameter is tied to the parent bus device binding scope.
Registration<'a, T> takes ownership of the data via Pin<KBox<_>>,
storing it with its real lifetime. The pointer is written to drm::Device
before drm_dev_register() to ensure it is already in place when ioctls
arrive.
Device<T, Registered>::registration_data_with() provides access with the
lifetime shortened from 'static via a pointer cast. Since
Registration::drop() calls drm_dev_unplug(), which performs an SRCU
barrier waiting for all drm_dev_enter() critical sections to complete,
the data is guaranteed to remain valid for the duration of any
RegistrationGuard.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-18-dakr@kernel.org
[ Move registration_data_unchecked() to Device<T, Registered> impl
block. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Implement AsRef<T::ParentDevice<Bound>> for Device<T, Registered>,
providing access to the bound parent bus device for registered DRM
devices.
Since a Device<T, Registered> guarantees that the parent bus device is
bound, the conversion to T::ParentDevice<Bound> is safe.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-16-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Change AsRef for drm::Device to return &T::ParentDevice<device::Normal>
instead of &device::Device, and restrict it to the Normal context.
Device<T, Registered> still gets this through Deref coercion.
This provides access to the typed parent bus device rather than the raw
base device.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-15-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Make Ioctl handlers receive a &Device<T, Registered> reference, proving
at the type level that the device is registered and its parent bus
device is bound.
This is achieved by calling registration_guard() on the Device<T, Ioctl>
obtained in ioctl dispatch context. If the device has been unplugged,
the ioctl returns -ENODEV without calling the handler.
To resolve the driver type parameter T for type inference, which the
compiler cannot propagate through method resolution and associated-type
projections alone, a dead-code closure and a helper function are used as
a type-inference anchor.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-14-dakr@kernel.org
[ Use imperative mood in commit message; clarify __dev_ctx_cast() doc
comment to reflect Ioctl-to-Registered cast. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
DRM ioctls do not guarantee that the parent bus device is still bound.
However, since DRM device registration is managed through Devres, using
drm_dev_unplug() on unregistration ensures that between drm_dev_enter()
and drm_dev_exit() the parent device must be bound.
Add RegistrationGuard, a guard object representing a drm_dev_enter/exit
SRCU critical section that dereferences to &Device<T, Registered>. The
guard is obtained from Device<T, Ioctl> and proves at runtime that the
device is still registered.
Switch Registration::drop from drm_dev_unregister() to drm_dev_unplug()
to provide the SRCU barrier that RegistrationGuard's safety argument
relies on.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-13-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add the Ioctl DeviceContext for DRM devices that have been registered
with userspace previously.
A Device<T, Ioctl> has been registered at some point, but may be
concurrently unregistering or already unregistered. drm_dev_enter() can
guard against this, ensuring the device remains registered for the
duration of the critical section.
This typestate will be used in ioctl dispatch context where registration
is guaranteed by the DRM core, and RegistrationGuard can safely be
acquired.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-12-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Explicitly annotate the Device reference produced by from_raw() in the
ioctl dispatch macro as Device<_, Normal>. Without this annotation, the
context is inferred from the handler's first parameter type, which would
allow a handler declaring &Device<T, Registered> to obtain a Registered
reference without runtime proof via RegistrationGuard.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-11-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Now that AlwaysRefCounted is restricted to the Normal GEM Object
context, there is no use for instantiating Object<T, C> with a
non-Normal context. Remove the DeviceContext generic parameter from
shmem::Object and all associated types (VMap, VMapRef, VMapOwned,
DmaResvGuard, SGTableMap), simplifying the API.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-9-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Restrict AlwaysRefCounted for gem::Object and gem::shmem::Object to the
Normal context, since only Normal objects should be independently
reference-counted.
To avoid cascading through IntoGEMObject (which had AlwaysRefCounted as
a supertrait), remove AlwaysRefCounted from IntoGEMObject's supertraits
and instead add it as an explicit bound on lookup_handle(), which is the
only BaseObject method that returns an ARef.
Since Object::new() and shmem::Object::new() return ARef<Self>, move
them to Normal-only impl blocks. Similarly, simplify ObjectConfig and
shmem's parent_resv_obj field to the Normal context.
Remove the DeviceContext generic from DriverObject::new() and
Driver::Object, since GEM objects can only be constructed in the Normal
context. Simplify DriverAllocImpl accordingly.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-8-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Restrict the AlwaysRefCounted implementation for drm::Device to the
Normal context. Registered devices represent a non-owning view of a
device within a RegistrationGuard scope and must not be independently
reference-counted.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-7-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Change the default DeviceContext from Registered to Normal for
drm::Device, gem::Object, gem::shmem::Object and
gem::shmem::ObjectConfig.
Normal is the general-purpose, reference-counted context suitable for
most uses; Registered represents a device that was registered with
userspace and will become a non-owning context obtained through a
RegistrationGuard.
Update the create_handle/lookup_handle bounds from Object<Registered> to
Object<Normal> to match the new default context of GEM objects, and
update the driver device type aliases (NovaDevice, TyrDrmDevice) to
default to Normal.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-6-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a ParentDevice associated type to the Driver trait, allowing each
DRM driver to declare its parent bus device type (e.g.
auxiliary::Device, platform::Device).
Change UnregisteredDevice::new() to take &T::ParentDevice<Bound>,
ensuring at the type level that the DRM device's parent matches the
declared bus device type.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a faux::Device type that wraps struct faux_device and implements
AsBusDevice, enabling faux devices to be used as parent devices for
subsystems that require a bus device, such as DRM.
Update Registration to return &faux::Device<Bound> via AsRef.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260628145406.2107056-4-dakr@kernel.org
[ Drop redundant 'struct device' invariant; implied by valid
struct faux_device. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
