Extract the bitfield-defining part of the `register!` macro into an
independent macro used to define bitfield types with bounds-checked
accessors.
Each field is represented as a `Bounded` of the appropriate bit width,
ensuring field values are never silently truncated.
Fields can optionally be converted to/from custom types, either fallibly
or infallibly.
Appropriate documentation is also added, and a MAINTAINERS entry created
for the new module.
Two minor fixups are also applied: the private accessors are inlined,
and a couple of missing fully qualified types in the macro are fixed.
Acked-by: Yury Norov <ynorov@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Yury Norov <ynorov@nvidia.com>
Link: https://patch.msgid.link/20260606-bitfield-v5-1-b92188820914@nvidia.com
[ Added some more intra-doc links. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
When building the kernel, the following Rust symbol is generated:
$ nm vmlinux | grep ' _R'.*Page | rustfilt
<kernel::page::Page>::nid
`Page::nid` is a trivial wrapper around the C function `page_to_nid`. It
does not make sense to go through a trivial wrapper for this function, so
mark it inline.
This follows commit 878620c5a9 ("rust: page: optimize rust symbol
generation for Page"), which did the same for `alloc_page` and `drop`.
Link: https://github.com/Rust-for-Linux/linux/issues/1145
Link: https://lore.kernel.org/20260529085316.27432-1-nakamura.shuta@gmail.com
Signed-off-by: Nakamura Shuta <nakamura.shuta@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Cc: Andreas Hindborg <a.hindborg@kernel.org>
Cc: Björn Roy Baron <bjorn3_gh@protonmail.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Trevor Gross <tmgross@umich.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Pass KBUILD_MODNAME through the driver registration macro so that the
driver core can create the module symlink in sysfs for built-in drivers,
and fixup all callers.
The Rust platform adapter is updated to pass the module name through to
the new parameter.
Tested on qemu with:
- x86 defconfig + CONFIG_RUST
- arm64 defconfig + CONFIG_RUST + CONFIG_CORESIGHT stuff
Examples after this patch:
/sys/bus/platform/drivers/...
coresight-itnoc/module -> coresight_tnoc
coresight-static-tpdm/module -> coresight_tpdm
coresight-catu-platform/module -> coresight_catu
serial8250/module -> 8250
acpi-ged/module -> acpi
vmclock/module -> ptp_vmclock
Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
Link: https://patch.msgid.link/20260518-acpi_mod_name-v5-4-705ccc430885@sony.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
- Fix memory leak and a potential race in the OPP core (Abdun Nihaal,
and Di Shen).
- Mark Rust OPP methods as inline (Nicolás Antinori)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEx73Crsp7f6M6scA70rkcPK6BEhwFAmomWtIACgkQ0rkcPK6B
EhyfnQ/8D16I3iIJHkg/Pnz7nazV99essmCTpsp/+2Z+pECfkn5+WnnKrFE/LEn3
kE0Fy2lggV25pQkhTJjUjtmCg6OMHlnIFljHeiAAK4ug8kg5Ab5pPxk9uto9qlCy
cvkxS09xOlmT/Pmo00sovJWOAcNVPy6FAebJ/roJVmI54wOnOf6MZeQmQKxvd6BN
B17NlXUF0nYot05vF+iiJ4NvrhLmWQdDCG+lBhIBLAUm87pz5QB1YN69aa1J6QWv
x8Rki0nGqQABQZvgvPJ+RTEqT8E898VGGK2+QE+XBtDQU2eDNlwJfCj2yuG/svWo
E9ui62EhRmfQKt73KC+WBW7J/n/JSve0/55rFNq1lYE9JJPS60Zlcsbfhat5jndt
RfvQutz/nP382dxYRHiPzfCVOS7HuH3BJL6IcysnteoPkCYoC9RkJeQJKU5Yp5zQ
9/syMd1zPpH+bKhvPrWidjQm2Xv9YorEQpCK3Oi0OqRnB2+mOdfCzwuHyhTT89I/
bbKs8GHJZsXhLnST/hMNEDumCR7Q9W7CcBZ0sHtsQE8Zjxx47o41v/n6zC2XI0u8
nBTihRWIlSBTTpVUR3+lmOVmiAU+MSCYjrnkWsAJ0ZzLEdmZDVblhHIsTyh9vU+K
+s3nVWIMBwcq0hM3c0Az28YlIpfqJOlqGXs/Mw1qKqFF0SjMmj0=
=9mEx
-----END PGP SIGNATURE-----
Merge tag 'opp-updates-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm
Pull OPP updates for 7.2 from Viresh Kumar:
"- Fix memory leak and a potential race in the OPP core (Abdun Nihaal,
and Di Shen).
- Mark Rust OPP methods as inline (Nicolás Antinori)"
* tag 'opp-updates-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
opp: rust: mark OPP methods as inline
OPP: of: Fix potential memory leak in opp_parse_supplies()
OPP: Fix race between OPP addition and lookup
A single bugfix for the Rust I2C abstractions, targeting 7.1.
`I2cAdapter::get` calls `i2c_get_adapter()` which returns a pointer with
an already-incremented refcount. The code then converts the raw pointer to
an `ARef` via `.into()`, which calls `inc_ref()` again through the
`From<&T> for ARef<T>` impl — resulting in a leaked device and module
reference on every call.
The fix uses `ARef::from_raw()` instead, which takes ownership of the
existing refcount without incrementing it.
Signed-off-by: Igor Korotin <igor.korotin@linux.dev>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEG0Kepq7dYk2deNuvoxQiWQ2T6tUFAmokUrYACgkQoxQiWQ2T
6tXfcw//SeqQ76PJjSQf1DKf7uTEgR73RZIVEEAWEYaABPOVmwZpIAniqMz+Np2s
CBNVpttdcbgjCsbxQny9zbgCbeOGbexP2sMEuugjxDYwXAHo5OFnY3q0ReJVQIGa
I6HB38lQpK1+p20W+CzqH7TIT5Tj7VOCpuIRu86lMUVTFVAgJSW8VMGkKqjO7ler
VshMUQe8SJaIxC6XAj1ChsELfHptJozZw7zUZhj2wCmfs+pl43onE079DqNfxQJ8
YWgaF3oSBxh2/CFORJKpCy5S7J4P6JQ4j0U8G7Gvs01lhnXggPewA0oJTQlpfNPj
UGKLnSo9pG0BdGcxFqiPKqfxrAq29LO776IcrRSQa7sEcSlwRh4L4h0LFY0TUvmY
5nR5BoXLOYpmrNP7WFCUISvjVXJaX8F3MEnVC7R/PmnOUhXWLBXZyzqzgUrAPkgl
R4Ofye3yWpdJRes4O7diR3vnvRdxLMpfehJi2WHUjB90StxrLkYGZRK5fGj6+90m
Pmefu7Qic1mos5jy0/9UjfaIaUS1W23KxX8HcNoMLZF/tl8YJ1FtMpm6ZrRSxM/v
1LiEXLZkQOfuNebjfyUZwzWIptYtq9h4N9X9ANykLPTiTncJmxQmzaPsoRE4ew0T
AD7P/WpLFbLs2XI/J5JuAVrfnOe+UjnvsixBxuPxEtgVY5K2pjA=
=LhTi
-----END PGP SIGNATURE-----
Merge tag 'rust-i2c-7.1-rc7' of https://github.com/ikrtn/linux into i2c/for-current
rust: i2c: fix I2cAdapter refcount double increment
There are 6 individual Rust KUnit test suites (plus the doctests one). All
the tests are compiled unconditionally now, which adds ~200 kB to the
kernel image for me on x86_64. As Rust matures, this bloating will
inevitably grow.
Add Kconfig.test which includes a RUST_KUNIT_TESTS menu, and all
individual tests under it.
As usual, new tests are all enabled if KUNIT_ALL_TESTS=y.
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Reviewed-by: David Gow <david@davidgow.net>
Acked-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260417031531.315281-3-ynorov@nvidia.com
[ Fixed capitalization. Used singular for "API" for consistency.
Reworded to clarify these are suites and that there exists
the doctests one (which is the biggest at the moment by
far). - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The following patch makes usage of macros::kunit_tests crate conditional
on the corresponding configs. When the configs are disabled, compiler
warns on unused crate. So, embed it in unit test declaration.
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Reviewed-by: David Gow <david@davidgow.net>
Acked-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260417031531.315281-2-ynorov@nvidia.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
When `I2cAdapter::get` executes, it first calls
`bindings::i2c_get_adapter()` which increments the device and module
reference counts. It then takes a reference to the raw pointer and
converts it to an `ARef` via `.into()`.
The implementation of `From<&T> for ARef<T>` where `T: AlwaysRefCounted`
unconditionally calls `T::inc_ref()`. This leads to a second increment
to the reference counts.
Since the returned `ARef` will only release a single reference when
dropped via `dec_ref()`, this leaks one device and module reference count
on every call.
This fix was suggested by sashiko.dev.
Link: https://sashiko.dev/#/patchset/20260521190937.248904-1-nico.antinori.7@gmail.com
Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com>
Reviewed-by: Igor Korotin <igor.korotin@linux.dev>
Signed-off-by: Igor Korotin <igor.korotin@linux.dev>
User visible changes:
- `non_snake_case` warnings will no longer be generated for identifiers that
are syntactically just users of a field name. This would allow all
`#[allow(non_snake_case)]` in nova-core to be removed, which I will send to
nova tree next cycle.
- Non-cfg attributes are now properly filtered out in derived structs. This
improves pin-init compatibility with other derive macros.
- Projection types have their where clause properly inserted now.
Other changes:
- MSRV is bumped to 1.82 and associated cleanups.
- There is an overhaul on how init slots are projected. The new approach is
easier to justify with safety comments.
- More functions are marked as inline, which should help mitigate super-long
symbol name issue due to lack of inlining.
- Various small code quality cleanups.
-----BEGIN PGP SIGNATURE-----
iIcEABYKAC8WIQRIiwFmsgGbHdMqd+kPoQF7f9ATtgUCah6+GREcZ2FyeUBnYXJ5
Z3VvLm5ldAAKCRAPoQF7f9ATttL5AP0YPT6NwXTHG9XJU6s/dGYsRO+8c1W5Q0oJ
jo3OYOqaMQD+K9uZMradLq60+5AHhRiJI/wIbhZmW42Y/fIRvXrbsgc=
=um+N
-----END PGP SIGNATURE-----
Merge tag 'pin-init-v7.2' of https://github.com/Rust-for-Linux/linux into rust-next
Pull pin-init updates from Gary Guo:
"User visible changes:
- Do not generate 'non_snake_case' warnings for identifiers that are
syntactically just users of a field name. This would allow all
'#[allow(non_snake_case)]' in nova-core to be removed, which I will
send to the nova tree next cycle.
- Filter non-cfg attributes out properly in derived structs. This
improves pin-init compatibility with other derive macros.
- Insert projection types' where clause properly.
Other changes:
- Bump MSRV to 1.82, plus associated cleanups.
- Overhaul how init slots are projected. The new approach is easier
to justify with safety comments.
- Mark more functions as inline, which should help mitigate the
super-long symbol name issue due to lack of inlining.
- Various small code quality cleanups."
* tag 'pin-init-v7.2' of https://github.com/Rust-for-Linux/linux: (27 commits)
rust: pin_init: internal: use `loop {}` to produce never value
rust: pin-init: remove `E` from `InitClosure`
rust: pin-init: move `InitClosure` out from `__internal`
rust: pin-init: docs: fix typos in MaybeZeroable documentation
rust: pin-init: internal: suppress `non_snake_case` lint in `[pin_]init!`
rust: pin-init: internal: suppress `non_snake_case` lint in `#[pin_data]`
rust: pin-init: internal: pin_data: filter non-`#[cfg]` attr in generated code
rust: pin-init: internal: project using full slot
rust: pin-init: internal: project slots instead of references
rust: pin-init: internal: make `make_closure` inherent methods
rust: pin-init: internal: use marker on drop guard type for pinned fields
rust: pin-init: internal: init: handle code blocks early
rust: pin-init: internal: add `PhantomInvariant` and `PhantomInvariantLifetime`
rust: pin-init: internal: pin_data: add struct to record field info
rust: pin-init: internal: pin_data: use closure for `handle_field`
rust: pin-init: examples: fix `useless_borrows_in_formatting` clippy warning
rust: pin-init: internal: remove `collect_tuple` polyfill after MSRV bump
rust: pin-init: internal: turn `PhantomPinned` error into warnings
rust: pin-init: cleanup workaround for old Rust compiler
rust: pin-init: fix badge URL in README
...
All users have been converted to use keyworded index projection syntax to
explicitly state their intention when doing index projection.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260602-projection-syntax-rework-v2-6-6989470f5440@garyguo.net
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Demonstrate the preferred syntax of index projection in DMA documentation
and examples. A few `[i]?` cases are converted to demonstrate the new
variant.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260602-projection-syntax-rework-v2-4-6989470f5440@garyguo.net
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
There have been a few cases where the programmer knows that the indices are
in bounds but the compiler cannot deduce that. This is also
compiler-version-dependent, so using build indexing here can be
problematic. On the other hand, it is also not ideal to use the fallible
variant, as it adds an error handling path that is never hit.
Add a new panicking index projection for this scenario. Like all panicking
operations, this should be used carefully only in cases where the user
knows the index is going to be in bounds, and panicking would indicate
something is catastrophically wrong.
To signify this, require users to explicitly denote the type of index being
used. The existing two types of index projections also gain the keyworded
version, which will be the recommended way going forward.
The keyworded syntax also paves the way of perhaps adding more flavors in
the future, e.g. `unsafe` index projection. However, unless the code is
extremely performance sensitive and bounds checking cannot be tolerated,
the panicking variant is safer and should be preferred, so it will be left
to the future when demand arises.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260602-projection-syntax-rework-v2-3-6989470f5440@garyguo.net
[ Fixed broken intra-doc link. Added a few extra intra-doc links. Reworded
some docs slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The corresponding `SliceIndex` trait in Rust uses `index` to mean the
panicking variant, which is also being added to `ProjectIndex`. Hence
rename our custom `build_error!` index variant to `build_index`.
Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/rust-for-linux/DI5LLN2V3XCS.34H4CG99N4MPA@nvidia.com
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260602-projection-syntax-rework-v2-1-6989470f5440@garyguo.net
[ Reworded docs slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Guard is marked #[must_use] since dropping it releases the lock. GlobalGuard
wraps Guard with identical semantics but was missing the annotation, so
discarding it would silently compile without warning.
Similarly, GlobalLock::try_lock was missing #[must_use]. Option<T> does not
propagate #[must_use] from T, so the attribute needs to be on the function
directly - same reason Lock::try_lock has it.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260502160057.3402896-1-ashutoshdesai993@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add a trailing newline ('\n') to the pr_warn_once! call in set_param to
ensure the kernel ring buffer flushes the message correctly and
prevents log line smearing.
Signed-off-by: Kenny Glowner <SisyphusCode0311@gmail.com>
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1139
[Sami: Updated the commit message as we use pr_warn_once now.]
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Now that we have the ability to represent the context in which a DRM device
is in at compile-time, we can start carrying around this context with GEM
object types in order to allow a driver to safely create GEM objects before
a DRM device has registered with userspace.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260507220044.3204919-4-lyude@redhat.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
This is just a type alias that resolves into the AllocImpl for a given
T: drm:💎:DriverObject.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260507220044.3204919-3-lyude@redhat.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
One of the tricky things about DRM bindings in Rust is the fact that
initialization of a DRM device is a multi-step process. It's quite normal
for a device driver to start making use of its DRM device for tasks like
creating GEM objects before userspace registration happens. This is an
issue in rust though, since prior to userspace registration the device is
only partly initialized. This means there's a plethora of DRM device
operations we can't yet expose without opening up the door to UB if the DRM
device in question isn't yet registered.
Additionally, this isn't something we can reliably check at runtime. And
even if we could, performing an operation which requires the device be
registered when the device isn't actually registered is a programmer bug,
meaning there's no real way to gracefully handle such a mistake at runtime.
And even if that wasn't the case, it would be horrendously annoying and
noisy to have to check if a device is registered constantly throughout a
driver.
In order to solve this, we first take inspiration from
`kernel::device::DeviceContext` and introduce `kernel::drm::DeviceContext`.
This provides us with a ZST type that we can generalize over to represent
contexts where a device is known to have been registered with userspace at
some point in time (`Registered`), along with contexts where we can't make
such a guarantee (`Uninit`).
It's important to note we intentionally do not provide a `DeviceContext`
which represents an unregistered device. This is because there's no
reasonable way to guarantee that a device with long-living references to
itself will not be registered eventually with userspace. Instead, we
provide a new-type for this: `UnregisteredDevice` which can
provide a guarantee that the `Device` has never been registered with
userspace. To ensure this, we modify `Registration` so that creating a new
`Registration` requires passing ownership of an `UnregisteredDevice`.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260507220044.3204919-2-lyude@redhat.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
We're about to start explicitly mentioning kernel devices as well in this
file, so this makes it easier to differentiate the two by allowing us to
import `device` as `kernel::device`.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260428190605.3355690-2-lyude@redhat.com
GenDiskBuilder::build() still has fallible work after
__blk_mq_alloc_disk(), but its error path only recovers the
foreign queue data. That leaks the temporary gendisk and
request_queue until later teardown. If the caller moved the last
Arc<TagSet<T>> into build(), the leaked queue can retain blk-mq
state after the tag set is dropped.
Fix the pre-registration failure path by dropping the temporary
gendisk reference with put_disk() before recovering queue_data,
so disk_release() can tear down the owned queue.
Also pair GenDisk::drop() with put_disk() after del_gendisk().
Once a Rust GenDisk has been added with device_add_disk(),
del_gendisk() only unregisters it; the final gendisk reference
still has to be dropped to complete the release path.
Fixes: 3253aba340 ("rust: block: introduce `kernel::block::mq` module")
Cc: stable@kernel.org
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: Haoze Xie <royenheart@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Link: https://patch.msgid.link/b70aff9a920cc42110fe5cf454c3099561863519.1780063368.git.royenheart@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
In the `init!`/`pin_init!` macros, we rely on a trick that assigns never
(`!`) values to all mentioned fields in never-executed code to let the
compiler check that all fields have been initialized.
Currently we use `::core::panic!()` to produce this value, but before Rust
1.91.0, it creates outlined `panic_cold_explicit` functions which do not
get removed by the optimizer, thus leaving dead code behind in the binary.
This has been fixed by [1], which lands in Rust 1.91.0+, higher than the
kernel minimum version 1.85.0.
This causes ~200 dead `panic_cold_explicit` instances being included in the
binary, with ~90 of them from nova-core's usage of pin-init.
Work around the issue by using `loop {}` which creates the never value
without macro expansion or function call at all. All instances of
`panic_cold_explicit` outside libcore are removed by this change in my
kernel build.
Link: https://github.com/rust-lang/rust/pull/145304 [1]
Link: https://patch.msgid.link/20260508152950.833635-1-gary@kernel.org
Signed-off-by: Gary Guo <gary@garyguo.net>
Move `E` from type to trait impl block. This greatly shortens the
monomorphized type names. The `__pinned_init` function name is only
slightly shortened as it still encodes the `E` as part of `PinInit<T, E>`
in the symbol.
`T` cannot be moved to trait impl block otherwise it will start to conflict
with the `impl Init<T> for T` as Rust cannot deduce that there're no types
that fulfill `T: FnOnce(*mut T)`.
Link: https://patch.msgid.link/20260527-pin-init-sync-v1-6-e20335ed2501@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
The `__internal` module is for exposing internal items publicly to
procedural macros (pin-init-internal). Types that are crate-local only can
just have proper visibility and does not need to be in `__internal`.
The type name of `InitClosure` can often shows up in symbol names, this
reduces the length slightly.
Link: https://patch.msgid.link/20260527-pin-init-sync-v1-5-e20335ed2501@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
Allows `non_snake_case` lint on struct fields generated by `#[pin_data]`.
Since the same warning will be reported by the compiler on the struct
definition, having extra warnings for the generated code is unnecessary
and confusing.
Signed-off-by: Mirko Adzic <adzicmirko97@gmail.com>
Link: https://patch.msgid.link/20260527-pin-init-sync-v1-2-e20335ed2501@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
When using a macro with custom attributes in a `#[pin_data]` struct it
can mess up the generated code. The generated code needs nothing more than
the `#[cfg]` attribute, thus strip away all other attributes.
[ Rebased and updated to only include `#[cfg]` instead of both `#[cfg]` and
`#[doc]`; doc is not needed for the generated hidden items. - Gary ]
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Co-developed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260527-pin-init-sync-v1-1-e20335ed2501@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
The kernel allows arches to select between inline and outline
implementations of the copy_{from,to}_user() by defining individual
INLINE_COPY_FROM_USER and INLINE_COPY_TO_USER, correspondingly. However,
all arches enable or disable them always together.
Without the real use-case for one helper being inlined while the other
outlined, having independent controls is excessive and error prone.
Switch the codebase to the single unified INLINE_COPY_USER control.
Link: https://lore.kernel.org/20260425020857.356850-3-ynorov@nvidia.com
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Tested-by: Alice Ryhl <aliceryhl@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Viktor Malik <vmalik@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Patch series "uaccess: unify inline vs outline copy_{from,to}_user()
selection", v2.
The kernel allows arches to select between inline and outline
implementations of the copy_{from,to}_user() by defining individual
INLINE_COPY_FROM_USER and INLINE_COPY_TO_USER, correspondingly. However,
all arches enable or disable them always together.
Without the real use-case for one helper being inlined while the other
outlined, having independent controls is excessive and error prone.
The first patch of the series fixes rust/uaccess coppy_to_user() wrapper
guarded with INLINE_COPY_FROM_USER. The 2nd patch switches codebase to
the unified INLINE_COPY_USER. And the last patch cleans up ifdefery in
the include/linux/uaccess.h
This patch (of 3):
The copy_to_user() rust helper is only needed when the main kernel inlines
the function. It is controlled by INLINE_COPY_TO_USER, but the rust
helper is protected with INLINE_COPY_FROM_USER.
Fix that.
Link: https://lore.kernel.org/20260425020857.356850-1-ynorov@nvidia.com
Link: https://lore.kernel.org/20260425020857.356850-2-ynorov@nvidia.com
Fixes: d99dc586ca ("uaccess: decouple INLINE_COPY_FROM_USER and CONFIG_RUST")
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Reported-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Closes: https://lore.kernel.org/all/746c9c50-20c4-4dc9-a539-bf1310ff9414@kernel.org/
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Viktor Malik <vmalik@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Devres::new() registers a callback with the C devres subsystem via
devres_node_add(). If the Devres is leaked (e.g. via
core::mem::forget(), which is safe), its Drop impl never runs, and the
devres release callback will revoke the inner Revocable on device
unbind, which drops T in place. If T contains non-'static references,
those may be dangling by that point.
Add a 'static bound to prevent storing types with borrowed data in
Devres.
Fixes: 76c01ded72 ("rust: add devres abstraction")
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260526000447.350558-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Replace drvdata() with registration data on the auxiliary bus. Private
data is now scoped to the registration object, removing the ordering
constraints and lifetime complications that came with drvdata().
Add Higher-Ranked Lifetime Types (HRT) so driver structs can borrow
device resources like pci::Bar and IoMem directly, tied to the device
binding scope. This removes the need for Devres indirection and
ARef<Device> in most driver code.
This is a stable tag for other trees to merge.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS2q/xV6QjXAdC7k+1FlHeO1qrKLgUCahjG2wAKCRBFlHeO1qrK
Lt0SAP9yaQFBx6t8rJdxtj2UgqrEBvW+20Gq5ze06ZRxaogqpAD9Ez0niV2z7Smh
T9YLPmJ5XDaz92QckskoifLmY/oYHQY=
=7fHo
-----END PGP SIGNATURE-----
Merge tag 'dd-lifetimes-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core into drm-rust-next
Higher-Ranked Lifetime Types for Rust device drivers
Replace drvdata() with registration data on the auxiliary bus. Private
data is now scoped to the registration object, removing the ordering
constraints and lifetime complications that came with drvdata().
Add Higher-Ranked Lifetime Types (HRT) so driver structs can borrow
device resources like pci::Bar and IoMem directly, tied to the device
binding scope. This removes the need for Devres indirection and
ARef<Device> in most driver code.
This is a stable tag for other trees to merge.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Danilo Krummrich <dakr@kernel.org> says:
Currently, Rust device drivers access device resources such as PCI BAR mappings
and I/O memory regions through Devres<T>.
Devres::access() provides zero-overhead access by taking a &Device<Bound>
reference as proof that the device is still bound. Since a &Device<Bound> is
available in almost all contexts by design, Devres is mostly a type-system level
proof that the resource is valid, but it can also be used from scopes without
this guarantee through its try_access() accessor.
This works well in general, but has a few limitations:
- Every access to a device resource goes through Devres::access(), which
despite zero cost, adds boilerplate to every access site.
- Destructors do not receive a &Device<Bound>, so they must use try_access(),
which can fail. In practice the access succeeds if teardown ordering is
correct, but the type system can't express this, forcing drivers to handle a
failure path that should never be taken.
- Sharing a resource across components (e.g. passing a BAR to a sub-component)
requires Arc<Devres<T>>.
- Device references must be stored as ARef<Device> rather than plain &Device
borrows.
These limitations stem from the driver's bus device private data being 'static
-- the driver struct cannot borrow from the device reference it receives in
probe(), even though it structurally cannot outlive the device binding.
This series introduces Higher-Ranked Lifetime Types (HRT) for Rust device
drivers. An HRT is a type that is generic over a lifetime -- it does not have a
fixed lifetime, but can be instantiated with any lifetime chosen by the caller.
Bus driver traits use a Generic Associated Type (GAT) type Data<'bound> to
introduce the lifetime on the private data, rather than parameterizing the
Driver trait itself. This avoids a driver trait global lifetime and avoids the
need for ForLt for bus device private data, making the bus implementations much
simpler. ForLt is only needed for auxiliary registration data, where the
lifetime is not introduced by a trait callback but must be threaded through
Registration.
With HRT, driver structs carry a lifetime parameter tied to the device binding
scope -- the interval of a bus device being bound to a driver. Device resources
like pci::Bar<'bound> and IoMem<'bound> are handed out with this lifetime, so
the compiler enforces at build time that they do not escape the binding scope.
Before:
struct MyDriver {
pdev: ARef<pci::Device>,
bar: Devres<pci::Bar<BAR_SIZE>>,
}
let io = self.bar.access(dev)?;
io.read32(OFFSET);
After:
struct MyDriver<'bound> {
pdev: &'bound pci::Device,
bar: pci::Bar<'bound, BAR_SIZE>,
}
self.bar.read32(OFFSET);
Lifetime-parameterized device resources can be put into a Devres at any point
via Bar::into_devres() / IoMem::into_devres(), providing the exact same
semantics as before. This is useful for resources shared across subsystem
boundaries where revocation is needed.
This also synergizes with the upcoming self-referential initialization support
in pin-init, which allows one field of the driver struct to borrow another
during initialization without unsafe code.
The same pattern is applied to auxiliary device registration data as a first
example beyond bus device private data. Registration<F: ForLt> can hold
lifetime-parameterized data tied to the parent driver's binding scope. Since the
auxiliary bus guarantees that the parent remains bound while the auxiliary
device is registered, the registration data can safely borrow the parent's
device resources.
More generally, binding resource lifetimes to a registration scope applies to
every registration that is scoped to a driver binding -- auxiliary devices,
class devices, IRQ handlers, workqueues.
A follow-up series extends this to class device registrations, starting with
DRM, so that class device callbacks (IOCTLs, etc.) can safely access device
resources through the separate registration data bound to the registration's
lifetime without Devres indirection.
Thanks to Gary for coming up with the ForLt implementation; thanks to Alice for
the early discussions around lifetime-parameterized private data that helped
shape the direction of this work.
Link: https://patch.msgid.link/20260525202921.124698-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add FEAT_RENDER bool constant to the Driver trait to control
render node support. When enabled, the driver exposes /dev/dri/renderDXX
render nodes to userspace. The flag defaults to false, drivers can opt
in by setting it to true in their Driver implementation.
This is then enabled in the Tyr driver, while it's left disabled for
Nova for the time being.
Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Laura Nao <laura.nao@collabora.com>
Link: https://patch.msgid.link/20260507080914.95478-2-laura.nao@collabora.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Backmerge to pull in commit 838d852da8 ("rust: allow
`clippy::collapsible_match` globally"), in order to get rid of spurious
warnings messing with developer tooling.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
This patch replaces an instance of match + panic with const expect,
which is now usable in const contexts after the MSRV was updated to
1.85.0 (it was available since Rust 1.83.0).
Suggested-by: Gary Guo <gary@garyguo.net>
Link: https://github.com/Rust-for-Linux/linux/issues/1229
Signed-off-by: Daniel del Castillo <delcastillodelarosadaniel@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260408200949.99059-1-delcastillodelarosadaniel@gmail.com
[ Adjusted Git author's name with the Signed-off-by value. Reworded
slightly and removed duplicated word. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
- Fix the Vec::reserve() doc test to properly account for the existing
vector length in the capacity assertion
- Fix an incorrect operator in the Vec::extend_with() SAFETY comment;
add a doc test demonstrating basic usage and the zero-length case
- Cleanup all imports in the alloc module and its doctests to use the
"kernel vertical" import style
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS2q/xV6QjXAdC7k+1FlHeO1qrKLgUCahOgcAAKCRBFlHeO1qrK
LnUJAP4qD/Mdo35beMgEMzql2vK1Gxcc/tKg4dc8gccHYBtXJgD/cwHcwfjuoSIH
R4a4B43Jz7r+XA1ej9hNr5Ci1f47xgQ=
=ZrNv
-----END PGP SIGNATURE-----
Merge tag 'alloc-7.2-rc1' of https://github.com/Rust-for-Linux/linux into rust-next
Pull alloc updates from Danilo Krummrich:
- Fix the 'Vec::reserve()' doctest to properly account for the existing
vector length in the capacity assertion.
- Fix an incorrect operator in the 'Vec::extend_with()' SAFETY comment;
add a doc test demonstrating basic usage and the zero-length case.
- Cleanup all imports in the alloc module and its doctests to use the
"kernel vertical" import style.
* tag 'alloc-7.2-rc1' of https://github.com/Rust-for-Linux/linux:
rust: alloc: cleanup doctest imports to "kernel vertical" style
rust: alloc: cleanup imports and use "kernel vertical" style
rust: alloc: fix `Vec::extend_with` SAFETY comment
rust: alloc: add doc test for `Vec::extend_with`
rust: alloc: fix assert in `Vec::reserve` doc test
Commit 47ac2a4b5c ("rust: kvec: implement shrink_to for KVVec")
introduced a call to bindings::is_vmalloc_addr(). However, this
fails to compile on architectures where CONFIG_MMU is disabled,
resulting in the following build error:
error[E0425]: cannot find function `is_vmalloc_addr` in crate `bindings`
--> rust/kernel/alloc/kvec.rs:781:32
|
781 | if !unsafe { bindings::is_vmalloc_addr(self.ptr.as_ptr().cast()) } {
| ^^^^^^^^^^^^^^^ not found in `bindings`
When CONFIG_MMU is not set, is_vmalloc_addr() is defined as a
static inline function in <linux/mm.h> that unconditionally
returns false. Because bindgen skips static inline functions
when generating bindings, the symbol is completely missing from
the Rust bindings crate.
Fix this by providing a C helper wrapper, rust_helper_is_vmalloc_addr(),
in rust/helpers/vmalloc.c. This ensures the function is reliably
exposed to Rust regardless of the MMU configuration. On NOMMU builds,
this allows KVVec::shrink_to() to successfully compile and correctly
route all allocations through the kmalloc realloc path.
Fixes: 47ac2a4b5c ("rust: kvec: implement shrink_to for KVVec")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605220811.LRplxeBR-lkp@intel.com/
Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260523-is-vmalloc-addr-build-fix-v1-1-73c919440c41@zohomail.in
[ Pasted exact compiler output and expanded it. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Commit b040a1a452 ("block: switch numa_node to int in
blk_mq_hw_ctx and init_request") changed the type of the
`numa_node` argument of `blk_mq_ops::init_request` from
`unsigned int` to `int`. Update the Rust callback signature to
match, so that the function item can be coerced to the C fn
pointer type stored in `blk_mq_ops`.
Without this change the Rust block layer fails to build:
error[E0308]: mismatched types
--> rust/kernel/block/mq/operations.rs:274:28
|
274 | init_request: Some(Self::init_request_callback),
| ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^
| expected fn pointer, found fn item
|
= note: expected fn pointer
`unsafe extern "C" fn(_, _, _, i32) -> _`
found fn item
`unsafe extern "C" fn(_, _, _, u32) -> _ {...}`
The argument is unused on the Rust side, so this is a pure
type-signature change with no functional impact.
Fixes: b040a1a452 ("block: switch numa_node to int in blk_mq_hw_ctx and init_request")
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260527-block-for-next-2026-05-26-2200-failure-v1-1-4865889e282c@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Generalize Registration<T> to Registration<F: ForLt> and
Device::registration_data<F: ForLt>() to return Pin<&F::Of<'_>>.
The stored 'static lifetime is shortened to the borrow lifetime of &self
via ForLt::cast_ref; ForLt's covariance guarantee makes this sound.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-24-dakr@kernel.org
[ Use PhantomData<F::Of<'a>> instead of
PhantomData<(fn(&'a ()) -> &'a (), F)>], which also gets us rid of
#[allow(clippy::type_complexity)]. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
There are a few cases, e.g. when dealing with data referencing each
other, one might want to write code that is generic over lifetimes. For
example, if you want to take a function that takes `&'a Foo` and gives
`Bar<'a>`, you can write:
f: impl for<'a> FnOnce(&'a Foo) -> Bar<'a>,
However, it becomes tricky when you want that function to not have a
fixed `Bar`, but have it be generic again. In this case, one needs
something that is generic over types that are themselves generic over
lifetimes.
`ForLt` provides such support. It provides a trait `ForLt` which
describes a type generic over a lifetime. One may use `ForLt::Of<'a>` to
get an instance of a type for a specific lifetime.
For the case of cross referencing, one would almost always want the
lifetime to be covariant. Therefore this is also made a requirement for
the `ForLt` trait, so functions with `ForLt` trait bound can assume
covariance.
A macro `ForLt!()` is provided to be able to obtain a type that
implements `ForLt`. For example, `ForLt!(for<'a> Bar<'a>)` would yield a
type that `<TheType as ForLt>::Of<'a>` is `Bar<'a>`. This also works
with lifetime elision, e.g. `ForLt!(Bar<'_>)` or for types without
lifetime at all, e.g. `ForLt!(u32)`.
The API design draws inspiration from the higher-kinded-types [1] crate,
however a different design decision has been taken (e.g. covariance
requirement) and the implementation is independent.
License headers use "Apache-2.0 OR MIT" because I anticipate this to be
used in pin-init crate too which is licensed as such.
Link: https://docs.rs/higher-kinded-types/ [1]
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260525202921.124698-23-dakr@kernel.org
[ Handle macro_rules! invocations in the ForLt! proc macro's covariance
and WF checks. Since proc macros cannot expand macro_rules!, add a
visit_macro() implementation to conservatively assume macro
invocations may contain lifetimes, forcing them through the
compiler-assisted covariance proof.
Fix a few typos in the documentation and in the commit message, add
empty lines before samples, add missing periods and consistently use
markdown.
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a lifetime parameter to IoMem<'a, SIZE> and ExclusiveIoMem<'a,
SIZE>, storing a &'a Device<Bound> reference to tie the mapping to the
device's lifetime.
This mirrors the pci::Bar<'a, SIZE> design and enables drivers to hold
I/O memory mappings directly in their HRT private data, tied to the
device lifetime.
IoRequest::iomap_* methods now return the mapping directly instead of
wrapping it in Devres. Callers that need device-managed revocation can
call the new into_devres() method.
Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-20-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Convert pci::Bar<SIZE> to pci::Bar<'a, SIZE>, storing &'a Device<Bound>
to tie the BAR mapping lifetime to the device.
iomap_region_sized() now returns Result<Bar<'a, SIZE>> directly instead
of impl PinInit<Devres<Bar<SIZE>>, Error>.
Since the lifetime ties the mapping to the device's bound state, callers
no longer need Devres for the common case where the Bar lives in the
driver's private data.
Add Bar::into_devres() to consume the bar and register it as a
device-managed resource, returning Devres<Bar<'static, SIZE>>. The
lifetime is erased to 'static because Devres guarantees the bar does not
actually outlive the device -- access is revoked on unbind.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-19-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Now that all bus driver traits use type Data<'bound>: 'bound, update the
illustrative driver trait in the module documentation to reflect the GAT
pattern and lifetime-parameterized callbacks.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-18-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a 'bound lifetime to the associated Data, changing type Data to type
Data<'bound>.
This allows the driver's bus device private data to capture the device /
driver bound lifetime; device resources can be stored directly by
reference rather than requiring Devres.
The probe() and unbind() callbacks thus gain a 'bound lifetime parameter
on the methods themselves; avoiding a global lifetime on the trait impl.
Existing drivers set type Data<'bound> = Self, preserving the current
behavior.
Acked-by: Igor Korotin <igor.korotin@linux.dev>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-17-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a 'bound lifetime to the associated Data, changing type Data to type
Data<'bound>.
This allows the driver's bus device private data to capture the device /
driver bound lifetime; device resources can be stored directly by
reference rather than requiring Devres.
The probe() and disconnect() callbacks thus gain a 'bound lifetime
parameter on the methods themselves; avoiding a global lifetime on the
trait impl.
Existing drivers set type Data<'bound> = Self, preserving the current
behavior.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260525202921.124698-16-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a 'bound lifetime to the associated Data, changing type Data to type
Data<'bound>.
This allows the driver's bus device private data to capture the device /
driver bound lifetime; device resources can be stored directly by
reference rather than requiring Devres.
The probe() and unbind() callbacks thus gain a 'bound lifetime parameter
on the methods themselves; avoiding a global lifetime on the trait impl.
Existing drivers set type Data<'bound> = Self, preserving the current
behavior.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-15-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a 'bound lifetime to the associated Data, changing type Data to type
Data<'bound>.
This allows the driver's bus device private data to capture the device /
driver bound lifetime; device resources can be stored directly by
reference rather than requiring Devres.
The probe() and unbind() callbacks thus gain a 'bound lifetime parameter
on the methods themselves; avoiding a global lifetime on the trait impl.
Existing drivers set type Data<'bound> = Self, preserving the current
behavior.
Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-14-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a 'bound lifetime to the associated Data, changing type Data to type
Data<'bound>.
This allows the driver's bus device private data to capture the device /
driver bound lifetime; device resources can be stored directly by
reference rather than requiring Devres.
The probe() and unbind() callbacks thus gain a 'bound lifetime parameter
on the methods themselves; avoiding a global lifetime on the trait impl.
Existing drivers set type Data<'bound> = Self, preserving the current
behavior.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-13-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Device<Core> references in probe callbacks are scoped to the callback,
not the full binding duration. Add a lifetime parameter to Core and
CoreInternal to accurately represent this in the type system.
Suggested-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-12-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Implement Sync for Device<Bound> in addition to Device<Normal>.
Device<Bound> uses the same underlying struct device as Device<Normal>;
Bound is a zero-sized type-state marker that does not affect thread
safety.
This is needed for types that hold &'bound Device<Bound>, such as
io::mem::IoMem, to be Send.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://patch.msgid.link/20260525202921.124698-11-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Implement Sync for Device<Bound> in addition to Device<Normal>.
Device<Bound> uses the same underlying struct usb_device as
Device<Normal>; Bound is a zero-sized type-state marker that does not
affect thread safety.
This is needed for drivers to store &'bound usb::Device<Bound> in their
private data while remaining Send.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://patch.msgid.link/20260525202921.124698-10-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Implement Sync for Device<Bound> in addition to Device<Normal>.
Device<Bound> uses the same underlying struct auxiliary_device as
Device<Normal>; Bound is a zero-sized type-state marker that does not
affect thread safety.
This is needed for drivers to store &'bound auxiliary::Device<Bound> in
their private data while remaining Send.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://patch.msgid.link/20260525202921.124698-9-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Implement Sync for Device<Bound> in addition to Device<Normal>.
Device<Bound> uses the same underlying struct platform_device as
Device<Normal>; Bound is a zero-sized type-state marker that does not
affect thread safety.
This is needed for drivers to store &'bound platform::Device<Bound> in
their private data while remaining Send.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://patch.msgid.link/20260525202921.124698-8-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Implement Sync for Device<Bound> in addition to Device<Normal>.
Device<Bound> uses the same underlying struct pci_dev as Device<Normal>;
Bound is a zero-sized type-state marker that does not affect thread
safety.
This is needed for drivers to store &'bound pci::Device<Bound> in their
private data while remaining Send.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://patch.msgid.link/20260525202921.124698-7-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Move the post_unbind_rust callback before devres_release_all() in
device_unbind_cleanup().
With drvdata() removed, the driver's bus device private data is only
accessible by the owning driver itself. It is hence safe to drop the
driver's bus device private data before devres actions are released.
This reordering is the key enabler for Higher-Ranked Lifetime Types
(HRT) in Rust device drivers -- it allows driver structs to hold direct
references to devres-managed resources, because the bus device private
data (and with it all such references) is guaranteed to be dropped while
the underlying devres resources are still alive.
Without this change, devres resources would be freed first, leaving the
driver's bus device private data with dangling references during its
destructor.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260525202921.124698-6-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a type Data<'bound> associated type to all bus driver traits,
decoupling the driver's bus device private data type from the driver
struct itself.
In the context of adding a 'bound lifetime, making this an associated
type has the advantage that it allows us to avoid a driver trait global
lifetime and it avoids the need for ForLt for bus device private data;
both of which make the subsequent implementation by buses much simpler.
All existing drivers and doc examples set type Data = Self to preserve
the current behavior.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260525202921.124698-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
With the ForeignOwnable lifetime change, the 'static bound is no longer
necessary on the drvdata methods or bus adapter impls. Move it to the
Registration constructor instead.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260525202921.124698-4-dakr@kernel.org
Co-developed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The `'static` bound is currently necessary because there's no
restriction on the lifetime of the GAT. Add a `Self: 'a` bound to
restrict possible lifetimes on `Borrowed` and `BorrowedMut`, and lift
the `'static` requirement.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Gary Guo <gary@garyguo.net>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://patch.msgid.link/20260525202921.124698-3-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Replace `pr_warn!` and the accompanying TODO with `pr_warn_once!`, now that
the macro is available.
[ Note: Adarsh Das independently authored an identical patch on the
rust-for-linux list, but it missed the modules tree. ]
Suggested-by: Adarsh Das <adarshdas950@gmail.com>
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
When building the kernel using llvm-19.1.7-rust-1.85.0-x86_64, the
following symbols are generated:
$ nm vmlinux | grep ' _R'.*OPP | rustfilt
ffffffff81801560 T <kernel::opp::OPP>::freq
ffffffff81801540 T <kernel::opp::OPP as kernel::sync::aref::AlwaysRefCounted>::dec_ref
ffffffff81801520 T <kernel::opp::OPP as kernel::sync::aref::AlwaysRefCounted>::inc_ref
However, these Rust symbols are trivial wrappers around the
`dev_pm_opp_get`, `dev_pm_opp_put` and `dev_pm_opp_get_freq_indexed`
functions. It doesn't make sense to go through a trivial wrapper for
these functions.
After applying this patch, the above command will produce no output.
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>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCgA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmoTZAYeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGKZ0H/A8Ti79DXqEl4M6V
S1ZYfteuvyWCdygPfY7+CQsxS1EjfmeRXd0213n95jijUoXvAVe7HJ5FuroTltsF
LYqH3CAedeEWMO1rIZjuDs5J1BzWAh7b0/QoanTlAjI1ZL8c3Btj/o//PoQfztiS
HWlN/aCcsZTi9n0ewV9eQM9jdiuhBlpZujfDX90vYurxAB+3K2c1b0UN+Y4/zMXO
83zaDLMYhIh8cEaU52+23H9UpyfrT0B8n6YgqbU4ZBRIbgA1BC4gloT6B7OHFKfq
PAfjAOBfpe43K8lLUyfbkfNohNblLOboiMmekdf+j2y4wqpCO64o6WigCrZtxtHe
9znkJpM=
=H+I9
-----END PGP SIGNATURE-----
Merge tag 'v7.1-rc5' 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>
Switch single-line `use` imports in fmt.rs to vertical style for
better readability and easier maintenance.
Signed-off-by: Ke Sun <sunke@kylinos.cn>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260512-clean-fmt-use-v1-1-7ae7858192ac@kylinos.cn
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Somehow the rustdoc heuristics determined that a large chunk of the items
found in prelude should have documentation inlined. This bloats the
generated documentation size.
Also, for crates that optimize documentation with `cfg(doc)`, as the
documentation inlining makes use of the metadata compiled by just rustc, it
will not pick up the `cfg(doc)` attributes from the inlined documentation.
pin-init for example optimizes tuple/fn rendering using the nightly
fake_variadic feature [1], but this is missing from the inlined version
[2].
Thus, mark all prelude items as `#[doc(no_inline)]`.
Link: https://rust.docs.kernel.org/next/pin_init/trait.Zeroable.html#impl-Zeroable-for-(J,) [1]
Link: https://rust.docs.kernel.org/next/kernel/prelude/trait.Zeroable.html#impl-Zeroable-for-(J,) [2]
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260420161636.1790502-1-gary@kernel.org
[ Reworded for typo. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Instead of projecting using pointer to a field project the full slot. This
further shifts the code generation from the initializer site to the struct
definition site, which means less code is generated overall.
It also makes the safety comment easier to justify, as now the projection
is done by the `#[pin_data]` macro which has full visibility of pinnedness
of fields.
The field alignment could also be checked on the `#[pin_data]` side;
however, since `init!()` macro works for other type of structs, we cannot
remove the alignment check from `init!`/`pin_init!` side anyway, so I opted
to still keep the alignment check in init.rs.
Signed-off-by: Gary Guo <gary@garyguo.net>
By projecting slots, the `pin_init!` and `init!` code path can be more
unified. This also reduces the amount of macro-generated code and shifts
them to the shared infrastructure.
Signed-off-by: Gary Guo <gary@garyguo.net>
The `InitData` and `PinData` traits do not need to exist, the inference
helpers could be inherent methods instead.
There is no risk for calling the wrong methods even when user defines it,
as inherent methods take priority over trait methods.
With this change, it unlocks the possibility of attaching additional bounds
to the method per type, which is not possible for trait methods.
Signed-off-by: Gary Guo <gary@garyguo.net>
Instead of projecting the created reference, simply create drop guards with
different marker types and have the `let_binding()` method of guards of
different marker produce different type instead.
This allows more flexible lifetime as this is now controlled by the guard.
This will be needed when implementing self-referential fields.
Signed-off-by: Gary Guo <gary@garyguo.net>
`InitializerKind::Code` is a special case where it does not initialize a
field, and thus generate no guard and accessors. Handle it earlier and make
the rest of the code more linear.
Signed-off-by: Gary Guo <gary@garyguo.net>
Currently, the `pin_init` library has an `Invariant` type alias, and it is
instantiated using `PhantomData`. Generated code from `pin_data` on the
other hand cannot access the crate-local type alias, so it generates
`PhantomData<fn(T) -> T>` directly. This is all very inconsistent, despite
the exact same use case of ensuring invariance.
Add `PhantomInvariant` and `PhantomInvariantLifetime` and switch all users
that need to express the concept of invariance to use these. They're
polyfills of unstable types in the same names in the Rust standard library.
Link: https://patch.msgid.link/20260512-pin-init-sync-v1-3-81963130dfbd@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
Introduce `FieldInfo` struct to encapsulate field and other relevant data,
instead of carrying a pair of `(pinned, field)` in all places. This allows
us to add more information to the struct in the future.
Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>
Co-developed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260512-pin-init-sync-v1-2-81963130dfbd@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
`handle_field` is currently a function, which precludes it from referencing
things in the scope of the parent function. Given that it's only called
once, inline its contents to the closure that invokes it instead, so it can
directly reference `struct_name` without having to pass in as argument.
Link: https://patch.msgid.link/20260512-pin-init-sync-v1-1-81963130dfbd@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
Danilo Krummrich <dakr@kernel.org> says:
When drvdata() was introduced in commit 6f61a2637a ("rust: device: introduce
Device::drvdata()"), its commit message already noted that a direct accessor to
the driver's bus device private data is not commonly required -- bus callbacks
provide access through &self, and other entry points (IRQs, workqueues, IOCTLs,
etc.) carry their own private data.
The sole motivation for drvdata() was inter-driver interaction, e.g. a parent
driver deriving its bus device private data from the child driver via the
auxiliary bus.
However, drvdata() exposes the driver's bus device private data beyond the
driver's own scope. This creates ordering constraints -- drvdata may not be set
yet when the first caller of drvdata() can appear -- and forces the driver's bus
device private data to outlive all registrations that access it; a requirement
that causes unnecessary complications.
Private data should be private to the entity that issues it; bus device private
data belongs to bus callbacks, class device private data to class callbacks, IRQ
private data to the IRQ handler, etc.
This series replaces drvdata() with a dedicated registration_data pointer on
struct auxiliary_device. The parent stores its private data explicitly during
registration; the data is private to the registration and lives as long as the
Registration object.
On teardown, Registration::drop() first triggers auxiliary_device_delete()
(unbinding the child), then frees the registration data. Ordering constraints
are structural -- the child's lifecycle is scoped to the registration by
construction, not by convention.
With no remaining use case for drvdata(), drvdata(), match_type_id(),
set_type_id() and struct driver_type are removed.
This is a prerequisite for [1], which builds on the removal of drvdata() to
enable Higher-Ranked Lifetime Types (HRT) for Rust device drivers.
[1] https://lore.kernel.org/driver-core/20260427221155.2144848-1-dakr@kernel.org/
Link: https://patch.msgid.link/20260505152400.3905096-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Fix an incorrect operator in the SAFETY comment, changing `<` to `<=`,
since `Vec::reserve` guarantees capacity for exactly n additional elements,
so the equal case should be included.
Signed-off-by: Hsiu Che Yu <yu.whisper.personal@gmail.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Fixes: 2aac4cd7da ("rust: alloc: implement kernel `Vec` type")
Link: https://patch.msgid.link/18fc8eee2f057a6bfbcadae156d1d0b7c40d0077.1777111268.git.yu.whisper.personal@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The assert in the doctest used `>= 10`, which only checks that the
capacity can hold `additional` elements, ignoring the existing length
of `v`. The correct check should ensure there is room for `additional`
*extra* elements on top of what is already in the vector.
Fix the assert to use `>= v.len() + 10` so the example accurately
reflects the actual semantics of the function.
Reported-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Closes: https://lore.kernel.org/rust-for-linux/CANiq72nkXWhjK9iFRrhGtkMZGsvNE_zVsu4JnxaFRfxWL7RRdg@mail.gmail.com/
Fixes: 2aac4cd7da ("rust: alloc: implement kernel `Vec` type")
Signed-off-by: Hsiu Che Yu <yu.whisper.personal@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260427-doctest-kvec-reserve-v1-1-0623abcd9c2e@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
When drvdata() was introduced in commit 6f61a2637a ("rust: device:
introduce Device::drvdata()"), its commit message already noted that a
direct accessor to the driver's bus device private data is not commonly
required -- bus callbacks provide access through &self, and other entry
points (IRQs, workqueues, IOCTLs, etc.) carry their own private data.
The sole motivation for drvdata() was inter-driver interaction -- an
auxiliary driver deriving the parent's bus device private data from the
parent device.
However, drvdata() exposes the driver's bus device private data beyond
the driver's own scope. This creates ordering constraints; for instance
drvdata may not be set yet when the first caller of drvdata() can
appear. It also forces the driver's bus device private data to outlive
all registrations that access it, which causes unnecessary
complications.
Private data should be private to the entity that issues it, i.e. bus
device private data belongs to bus callbacks, class device private data
to class callbacks, IRQ private data to the IRQ handler, etc.
With registration-private data now available through the auxiliary bus,
there is no remaining user of drvdata(), thus remove it.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260505152400.3905096-4-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a registration_data pointer to struct auxiliary_device, allowing the
registering (parent) driver to attach private data to the device at
registration time and retrieve it later when called back by the
auxiliary (child) driver.
By tying the data to the device's registration, Rust drivers can bind
the lifetime of device resources to it, since the auxiliary bus
guarantees that the parent driver remains bound while the auxiliary
device is bound.
On the Rust side, Registration<T> takes ownership of the data via
ForeignOwnable. A TypeId is stored alongside the data for runtime type
checking, making Device::registration_data<T>() a safe method.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260505152400.3905096-3-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add Box::zeroed() for T: Zeroable types.
This allocates with __GFP_ZERO directly, letting the underlying
allocator deal with zeroing out the memory compared to
Box::new(T::zeroed(), flags).
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260505152400.3905096-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Clippy 1.97 introduces new `useless_borrows_in_formatting` warning which
fires on the examples as we have `&*expr` where the format macro takes
reference already. Remove the extra borrow.
Link: https://patch.msgid.link/20260505115138.2466966-1-gary@kernel.org
Signed-off-by: Gary Guo <gary@garyguo.net>
Tuples implement `FromIterator` since Rust 1.79. Remove the `collect_tuple`
polyfill now the MSRV is above 1.79.
To avoid over-identing the closure, I move the `Field` destructure from the
closure parameter to a let binding. This keeps the diff small.
Link: https://patch.msgid.link/20260501134445.3809731-1-gary@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
The `PhantomPinned` detection is just a lint, and is emitted as an error
because there is no `compile_warning!()` macro, and
`proc-macro-diagnostics` is not stable.
Use of `#[deprecated = ""]` attribute to approximate custom proc-macro
warnings. A new line is added before message for visual clarity.
An example warning with this trick looks like this:
warning: use of deprecated function `_::warn`:
The field `pin` of type `PhantomPinned` only has an effect if it has the `#[pin]` attribute
--> test.rs:9:5
|
9 | pin: marker::PhantomPinned,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
Suggested-by: Benno Lossin <lossin@kernel.org>
Link: https://github.com/Rust-for-Linux/pin-init/issues/51
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-10-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
The pin-init crate has been licensed under `Apache-2.0 OR MIT` since the
beginning. I introduced in commit 071cedc84e ("rust: add derive macro for
`Zeroable`") `zeroable.rs` with incompatible GPL-2.0 SPDX identifier. The
file has not been modified by other authors, so relicense it under the
above license.
Signed-off-by: Benno Lossin <lossin@kernel.org>
[ Reworded commit message - Gary ]
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-7-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
The `generate_projections` and `generate_the_pin_data` function already
receive filtered field lists, they do not need to filter out `#[pin]`
again.
Reviewed-by: Benno Lossin <lossin@kernel.org>
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-6-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
Improve impl_zeroable_option macro to handle generic impls for types
like `&T`, `&mut T`, `NonNull<T>`, and others (for which `Option<T>`
is guaranteed to be zeroable) with similar approach to
`impl_zeroable`.
Also, update old declarations to use generics e.g. `NonZeroU8` to
`NonZero<u8>`.
Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-4-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
Place definitions and implementations (incl. macro invocations) of
the `Zeroable` trait first in the relevant section of `src/lib.rs`,
followed by the ZeroableOption trait and its implementations.
Rename `impl_non_zero_int_zeroable_option` to `impl_zeroable_option`
for consistency.
This commit should not introduce any functional changes.
Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-3-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
Following the kernel minimum version bump in commit f32fb9c58a ("rust:
bump Rust minimum supported version to 1.85.0 (Debian Trixie)"), bump
pin-init's minimum Rust version to 1.82.
This removes the `lint_reasons` feature which is stabilized in 1.81 and the
`raw_ref_ops` and `new_uninit` features which are stabilized in 1.82.
Given we do not use any features that are stabilized in 1.82..=1.85 range,
and pin-init crate is useful for other projects which may have their own
MSRV requirements, the minimum version is not straightly bumped to 1.85.
Reviewed-by: Benno Lossin <lossin@kernel.org>
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-2-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
There was a recent request in kernel [1] to mark as `#[inline]` the
simple `From::from()` functions implemented for `Error`.
Thus mark all of the existing
impl From<...> for Error {
fn from(err: ...) -> Self {
...
}
}
functions as `#[inline]`.
While in pin-init crate the relevant code is just examples, it
nevertheless does not hurt to use good practice for them.
Suggested-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/all/8403c8b7a832b5274743816eb77abfa4@garyguo.net/ [1]
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
[ Reworded commit message - Gary ]
Link: https://patch.msgid.link/20260428-pin-init-sync-v1-1-07f9bd3859fb@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
Since Rust uses GPUVM via the kernel crate, which is built-in, the GPUVM
module must also be built-in to use GPUVM from Rust. Adjust the Kconfig
settings accordingly.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260427-gpuvm-config-v1-1-8ece03771f8a@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Finally also add the operation for creating new mappings. Mapping
operations need extra data in the context since they involve a vm_bo
coming from the outside.
Co-developed-by: Asahi Lina <lina+kernel@asahilina.net>
Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-5-b16e6ada7261@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
