aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/rust/kernel
AgeCommit message (Collapse)AuthorFilesLines
2026-08-10rust: bug: skip arch-specific asm in `testlib` buildsFUJITA Tomonori1-1/+5
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: dff64b072708 ("rust: Add warn_on macro") Link: https://patch.msgid.link/20260808022608.1125174-1-tomo@flapping.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-10rust: bug: prevent dead_code warning from warn_on!'s flags constantFUJITA Tomonori1-4/+22
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::bug::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: dff64b072708 ("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>
2026-08-10rust: bitfield: always inline test conversionsAntoni Boucher1-0/+2
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 bc197e24a3ac ("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>
2026-08-10rust: impl_flags: use bit helper in exampleKosumi Chan1-4/+7
Use bit_u32() instead of open-coding shifts in the impl_flags! example. This demonstrates the checked bit helper and ensures that bit positions remain within the underlying u32 type. Suggested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1244 Assisted-by: OpenCode:openai/gpt-5.6-sol Signed-off-by: Kosumi Chan <chankocyo@gmail.com> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/rust-for-linux/2026071054-hazing-antirust-8e40@gregkh/ Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260711082327.3062227-1-chankocyo@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-08-10rust: sync: improve `Arc` documentation linksHarish C S1-6/+6
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>
2026-08-10Merge tag 'pin-init-v7.3' of https://github.com/Rust-for-Linux/linux into rust-nextMiguel Ojeda9-23/+25
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
2026-08-10Merge tag 'v7.2-rc7' into driver-core-nextDanilo Krummrich5-17/+25
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-08-08Merge tag 'driver-core-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-coreLinus Torvalds3-4/+8
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
2026-08-07Merge branch 'pm-cpufreq'Rafael J. Wysocki1-9/+26
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 ...
2026-08-06rust: pci: Mark Device refcount methods inlineEthan Plant1-0/+2
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>
2026-08-06rust: dma: rename dma_handle to dma_addressAlexandre Courbot1-35/+35
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>
2026-08-06rust: io: gate ioremap doctests on CONFIG_HAS_IOMEMDanilo Krummrich2-0/+2
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: 3f70ebe63858 ("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>
2026-08-06rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEMDanilo Krummrich2-4/+6
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: 3f70ebe63858 ("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>
2026-08-06rust: module_param: support bool parametersWenzhao Liao1-1/+8
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>
2026-08-06rust: module_param: return value by copy from `value`Andreas Hindborg1-1/+17
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>
2026-08-06Merge tag 'cpufreq-arm-updates-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pmRafael J. Wysocki1-7/+17
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
2026-08-06rust: cpufreq: Fix temporary write in Registration::bios_limit_callbackPriya Bala Govindasamy1-3/+8
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: c6af9a1191d042839e56abff69e8b0302d117988 ("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>
2026-08-06rust: cpufreq: Add CPUFREQ_TABLE_END as last table entry in TableBuilder::to_tablePriya Bala Govindasamy1-4/+9
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: 2207856ff0bc8d953d6e89bda70b8978c2de8bab ("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>
2026-08-06rust: firmware: add request_into_buf()Timur Tabi1-2/+44
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>
2026-08-06rust: alloc: add Vec::zeroed methodTimur Tabi1-0/+27
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>
2026-08-05rust: treewide: replace `__pinned_init` with `raw_[try_]init`Gary Guo9-23/+25
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>
2026-08-04rust: irq: make Registration compatible with lifetime-bound driversDanilo Krummrich3-250/+254
Adapt the IRQ registration to work with the Higher-Ranked Lifetime Types (HRT) device driver architecture introduced in commit 2c7c65933600 ("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>
2026-08-04rust: revocable: Use LKMM atomics instead of Rust atomicsGary Guo1-8/+13
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
2026-08-04rust: sync: Add generic memory barriersGary Guo2-29/+100
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
2026-08-04rust: sync: Use safe synchronize_rcu() abstraction in pollPhilipp Stanner1-4/+6
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
2026-08-04rust: revocable: Use safe synchronize_rcu() abstractionPhilipp Stanner1-3/+6
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
2026-08-04rust: sync: Add abstraction for synchronize_rcu()Philipp Stanner1-0/+16
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
2026-08-03rust: net/phy: remove expansion from docGary Guo1-56/+0
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>
2026-08-03rust: dma: return zero for Coherent reads past EOFYounes Akhouayri1-1/+5
Coherent<T>::write_to_slice() calculates a zero-byte copy when the file offset is beyond the allocation, but still calls UserSliceWriter::write_dma(). The latter rejects offsets beyond the allocation even when the copy length is zero, so a debugfs read past EOF returns -ERANGE. Return before calling write_dma() when the offset is at or beyond the allocation, matching simple_read_from_buffer() EOF semantics. Fixes: 016818513936 ("rust: dma: implement BinaryWriter for Coherent<[u8]>") Cc: stable@vger.kernel.org Link: https://rust-for-linux.zulipchat.com/#narrow/channel/291566-Library/topic/.E2.9C.94.20Possible.20past-EOF.20bug.20in.20Coherent.3CT.3E.3A.3Awrite_to_slice/near/611677095 Signed-off-by: Younes Akhouayri <git@younes.io> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Onur Özkan <work@onurozkan.dev> Link: https://patch.msgid.link/20260730-fix-dma-coherent-eof-v2-1-8aff21054afa@younes.io Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-08-03rust: io: register: use path fragment for alias destinationAlexandre Courbot1-2/+5
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>
2026-08-03rust: io: register: remove unused rule argumentsAlexandre Courbot1-15/+12
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>
2026-08-03rust: io: register: dispatch shortcut rules internallyAlexandre Courbot1-2/+4
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>
2026-08-03rust: print: fix broken `_printk` Rustdoc linkYounes Akhouayri1-1/+1
The Rustdoc link for `_printk` points to `include/linux/_printk.h`, which does not exist. Point it to `include/linux/printk.h`, where `_printk` is declared. Fixes: 247b365dc8dc ("rust: add `kernel` crate") Signed-off-by: Younes Akhouayri <git@younes.io> Link: https://github.com/Rust-for-Linux/linux/issues/1246 Reviewed-by: Onur Özkan <work@onurozkan.dev> Link: https://patch.msgid.link/20260717-docs-printk-rustdoc-link-v1-1-892074948f75@younes.io Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-07-31rust: debugfs: remove unsafe blocks from traits impl for VecJosef Ippisch1-19/+2
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>
2026-07-31rust: debugfs: migrate debugfs traits requirements to zerocopyJosef Ippisch1-13/+11
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>
2026-07-30rust: driver: remove duplicate ID tableGary Guo1-49/+27
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>
2026-07-30rust: driver: remove open-coded matching logicGary Guo4-129/+18
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 2690d071584e ("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>
2026-07-30rust: driver: store pointers in `DeviceId`Gary Guo8-71/+77
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>
2026-07-30rust: driver: remove `$module_table_name` from `module_device_table`Gary Guo7-24/+17
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>
2026-07-30rust: driver: centralize device ID handlingGary Guo8-55/+46
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>
2026-07-30rust: usb: use `Option<&IdInfo>` for device ID infoGary Guo1-3/+3
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>
2026-07-30rust: pci: use `Option<&IdInfo>` for device ID infoGary Guo1-3/+3
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>
2026-07-30rust: driver: simplify `IdArray::new_without_index`Gary Guo2-38/+28
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>
2026-07-30rust: driver: remove `IdTable::id`Gary Guo1-7/+0
This is unused. 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-1-56fccbe9c5ef@garyguo.net Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-30rust: iommu: add device lifetime to IoPageTableDeborah Brouwer1-23/+9
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>
2026-07-27rust: devres: use `cast_pin_init` instead of manual reimplementationGary Guo1-5/+1
Remove the manual type-casting which is already available as `cast_pin_init`. Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260722-merge-init-v1-2-d4594de76538@garyguo.net Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-27Merge 7.2-rc5 into char-misc-nextGreg Kroah-Hartman2-13/+18
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>
2026-07-27Merge 7.2-rc5 into usb-nextGreg Kroah-Hartman2-13/+18
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-23rust: add basic serial device bus abstractionsMarkus Probst2-0/+607
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>
2026-07-23rust: pci: add sriov_get_totalvfs() helperZhi Wang1-0/+13
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>