linux-toradex.git/rust/kernel, branch v6.19

Merge tag 'rust-fixes-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux

2026-01-31T00:15:59+00:00

Pull Rust fixes from Miguel Ojeda:
 "Toolchain and infrastructure:

   - Trigger rebuilds of the newly added 'proc-macro2' crate (and its
     dependencies) when the Rust compiler version changes

   - Fix error in '.rsi' targets (macro expanding single targets) under
     'O=' pointing to an external (not subdir) folder

   - Fix off-by-one line number in 'rustdoc' KUnit tests

   - Add '-fdiagnostics-show-context' to GCC flags skipped by 'bindgen'

   - Clean objtool warning by adding one more 'noreturn' function

   - Clean 'libpin_init_internal.{so,dylib}' in 'mrproper'

  'kernel' crate:

   - Fix build error when using expressions in formatting arguments

   - Mark 'num::Bounded::__new()' as unsafe and clean documentation
     accordingly

   - Always inline functions using 'build_assert' with arguments

   - Fix 'rusttest' build error providing the right 'isize_atomic_repr'
     type for the host

  'macros' crate:

   - Fix 'rusttest' build error by ignoring example

  rust-analyzer:

   - Remove assertion that was not true for distributions like NixOS

   - Add missing dependency edges and fix editions for 'quote' and
     sysroot crates to provide correct IDE support

  DRM Tyr:

   - Fix build error by adding missing dependency on 'CONFIG_COMMON_CLK'

  Plus clean a few typos in docs and comments"

* tag 'rust-fixes-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (28 commits)
  rust: num: bounded: clean __new documentation and comments
  scripts: generate_rust_analyzer: fix resolution of #[pin_data] macros
  drm/tyr: depend on `COMMON_CLK` to fix build error
  rust: sync: atomic: Provide stub for `rusttest` 32-bit hosts
  kbuild: rust: clean libpin_init_internal in mrproper
  rust: proc-macro2: rebuild if the version text changes
  rust: num: bounded: add missing comment for always inlined function
  rust: sync: refcount: always inline functions using build_assert with arguments
  rust: bits: always inline functions using build_assert with arguments
  scripts: generate_rust_analyzer: compile sysroot with correct edition
  scripts: generate_rust_analyzer: compile quote with correct edition
  scripts: generate_rust_analyzer: quote: treat `core` and `std` as dependencies
  scripts: generate_rust_analyzer: syn: treat `std` as a dependency
  scripts: generate_rust_analyzer: remove sysroot assertion
  rust: kbuild: give `--config-path` to `rustfmt` in `.rsi` target
  scripts: generate_rust_analyzer: Add pin_init_internal deps
  scripts: generate_rust_analyzer: Add pin_init -> compiler_builtins dep
  scripts: generate_rust_analyzer: Add compiler_builtins -> core dep
  rust: macros: ignore example with module parameters
  rust: num: bounded: mark __new as unsafe
  ...

rust: num: bounded: clean __new documentation and comments

2026-01-26T01:53:16+00:00

Following commit 3a1ec424dd9c ("rust: num: bounded: mark __new as
unsafe"), remove the redundant paragraph in the documentation of __new now
that the Safety section explicitly covers the requirement.

Additionally, add an INVARIANT comment inside the function body where
the Bounded instance is actually constructed to document that the type
invariant is upheld.

Suggested-by: Miguel Ojeda 
Link: https://lore.kernel.org/rust-for-linux/CANiq72mUCUh72BWP4eD1PTDpwdb1ML+Xgfom-Ys6thJooqQPwQ@mail.gmail.com/
Signed-off-by: Shivam Kalra 
Acked-by: Alexandre Courbot 
Link: https://patch.msgid.link/20260123132132.53854-1-shivamklr@cock.li
[ Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda

rust: sync: atomic: Provide stub for `rusttest` 32-bit hosts

2026-01-26T01:18:58+00:00

For arm32, on a x86_64 builder, running the `rusttest` target yields:

    error[E0080]: evaluation of constant value failed
      --> rust/kernel/static_assert.rs:37:23
       |
    37 |         const _: () = ::core::assert!($condition $(,$arg)?);
       |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: size_of::() == size_of::()', rust/kernel/sync/atomic/predefine.rs:68:1
       |
      ::: rust/kernel/sync/atomic/predefine.rs:68:1
       |
    68 | static_assert!(size_of::() == size_of::());
       | -------------------------------------------------------------------- in this macro invocation
       |
       = note: this error originates in the macro `::core::assert` which comes from the expansion of the macro `static_assert` (in Nightly builds, run with -Z macro-backtrace for more info)

The reason is that `rusttest` runs on the host, so for e.g. a x86_64
builder `isize` is 64 bits but it is not a `CONFIG_64BIT` build.

Fix it by providing a stub for `rusttest` as usual.

Fixes: 84c6d36bcaf9 ("rust: sync: atomic: Add Atomic<{usize,isize}>")
Cc: stable@vger.kernel.org
Reviewed-by: Onur Özkan 
Acked-by: Boqun Feng 
Link: https://patch.msgid.link/20260123233432.22703-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda

rust: num: bounded: add missing comment for always inlined function

2026-01-18T19:40:12+00:00

This code is always inlined to avoid a build error if the error path of
`build_assert` cannot be optimized out. Add a comment justifying the
`#[inline(always)]` property to avoid it being taken away by mistake.

Reviewed-by: Daniel Almeida 
Signed-off-by: Alexandre Courbot 
Link: https://patch.msgid.link/20251208-io-build-assert-v3-7-98aded02c1ea@nvidia.com
Signed-off-by: Miguel Ojeda

rust: sync: refcount: always inline functions using build_assert with arguments

2026-01-18T19:40:12+00:00

`build_assert` relies on the compiler to optimize out its error path.
Functions using it with its arguments must thus always be inlined,
otherwise the error path of `build_assert` might not be optimized out,
triggering a build error.

Cc: stable@vger.kernel.org
Fixes: bb38f35b35f9 ("rust: implement `kernel::sync::Refcount`")
Reviewed-by: Daniel Almeida 
Signed-off-by: Alexandre Courbot 
Acked-by: Boqun Feng 
Link: https://patch.msgid.link/20251208-io-build-assert-v3-5-98aded02c1ea@nvidia.com
Signed-off-by: Miguel Ojeda

rust: bits: always inline functions using build_assert with arguments

2026-01-18T19:40:11+00:00

`build_assert` relies on the compiler to optimize out its error path.
Functions using it with its arguments must thus always be inlined,
otherwise the error path of `build_assert` might not be optimized out,
triggering a build error.

Cc: stable@vger.kernel.org
Fixes: cc84ef3b88f4 ("rust: bits: add support for bits/genmask macros")
Reviewed-by: Daniel Almeida 
Signed-off-by: Alexandre Courbot 
Link: https://patch.msgid.link/20251208-io-build-assert-v3-4-98aded02c1ea@nvidia.com
Signed-off-by: Miguel Ojeda

rust: driver: drop device private data post unbind

2026-01-16T00:17:29+00:00

Currently, the driver's device private data is allocated and initialized
from driver core code called from bus abstractions after the driver's
probe() callback returned the corresponding initializer.

Similarly, the driver's device private data is dropped within the
remove() callback of bus abstractions after calling the remove()
callback of the corresponding driver.

However, commit 6f61a2637abe ("rust: device: introduce
Device::drvdata()") introduced an accessor for the driver's device
private data for a Device, i.e. a device that is currently bound
to a driver.

Obviously, this is in conflict with dropping the driver's device private
data in remove(), since a device can not be considered to be fully
unbound after remove() has finished:

We also have to consider registrations guarded by devres - such as IRQ
or class device registrations - which are torn down after remove() in
devres_release_all().

Thus, it can happen that, for instance, a class device or IRQ callback
still calls Device::drvdata(), which then runs concurrently to remove()
(which sets dev->driver_data to NULL and drops the driver's device
private data), before devres_release_all() started to tear down the
corresponding registration. This is because devres guarded registrations
can, as expected, access the corresponding Device that defines
their scope.

In C it simply is the driver's responsibility to ensure that its device
private data is freed after e.g. an IRQ registration is unregistered.

Typically, C drivers achieve this by allocating their device private data
with e.g. devm_kzalloc() before doing anything else, i.e. before e.g.
registering an IRQ with devm_request_threaded_irq(), relying on the
reverse order cleanup of devres.

Technically, we could do something similar in Rust. However, the
resulting code would be pretty messy:

In Rust we have to differentiate between allocated but uninitialized
memory and initialized memory in the type system. Thus, we would need to
somehow keep track of whether the driver's device private data object
has been initialized (i.e. probe() was successful and returned a valid
initializer for this memory) and conditionally call the destructor of
the corresponding object when it is freed.

This is because we'd need to allocate and register the memory of the
driver's device private data *before* it is initialized by the
initializer returned by the driver's probe() callback, because the
driver could already register devres guarded registrations within
probe() outside of the driver's device private data initializer.

Luckily there is a much simpler solution: Instead of dropping the
driver's device private data at the end of remove(), we just drop it
after the device has been fully unbound, i.e. after all devres callbacks
have been processed.

For this, we introduce a new post_unbind() callback private to the
driver-core, i.e. the callback is neither exposed to drivers, nor to bus
abstractions.

This way, the driver-core code can simply continue to conditionally
allocate the memory for the driver's device private data when the
driver's initializer is returned from probe() - no change needed - and
drop it when the driver-core code receives the post_unbind() callback.

Closes: https://lore.kernel.org/all/DEZMS6Y4A7XE.XE7EUBT5SJFJ@kernel.org/
Fixes: 6f61a2637abe ("rust: device: introduce Device::drvdata()")
Acked-by: Alice Ryhl 
Acked-by: Greg Kroah-Hartman 
Acked-by: Igor Korotin 
Link: https://patch.msgid.link/20260107103511.570525-7-dakr@kernel.org
[ Remove #ifdef CONFIG_RUST, rename post_unbind() to post_unbind_rust().
 - Danilo]
Signed-off-by: Danilo Krummrich

rust: driver: add DriverData type to the DriverLayout trait

2026-01-16T00:17:29+00:00

Add an associated type DriverData to the DriverLayout trait indicating
the type of the driver's device private data.

Acked-by: Alice Ryhl 
Acked-by: Igor Korotin 
Link: https://patch.msgid.link/20260107103511.570525-6-dakr@kernel.org
Signed-off-by: Danilo Krummrich

rust: driver: add DEVICE_DRIVER_OFFSET to the DriverLayout trait

2026-01-16T00:17:29+00:00

Add an associated const DEVICE_DRIVER_OFFSET to the DriverLayout trait
indicating the offset of the embedded struct device_driver within
Self::DriverType, i.e. the specific driver structs, such as struct
pci_driver or struct platform_driver.

Acked-by: Alice Ryhl 
Acked-by: Igor Korotin 
Link: https://patch.msgid.link/20260107103511.570525-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich

rust: driver: introduce a DriverLayout trait

2026-01-16T00:16:44+00:00

The DriverLayout trait describes the layout of a specific driver
structure, such as `struct pci_driver` or `struct platform_driver`.

In a first step, this replaces the associated type RegType of the
RegistrationOps with the DriverLayout::DriverType associated type.

Acked-by: Alice Ryhl 
Acked-by: Igor Korotin 
Link: https://patch.msgid.link/20260107103511.570525-4-dakr@kernel.org
[ Rename driver::Driver to driver::DriverLayout, as it represents the
  layout of a driver structure rather than the driver structure itself.
  - Danilo ]
Signed-off-by: Danilo Krummrich