While rebasing rvkms I noticed that timers I was setting seemed to have
pretty random timer values that amounted slightly over 2x the time value I
set each time. After a lot of debugging, I finally managed to figure out
why: it seems that since we moved to Instant and Delta, we mistakenly
began passing the clocksource ID to hrtimer_start_range_ns, when we should
be passing the timer mode instead. Presumably, this works fine for simple
relative timers - but immediately breaks on other types of timers.
So, fix this by passing the ID for the timer mode instead.
Signed-off-by: Lyude Paul <[email protected]>
Acked-by: Andreas Hindborg <[email protected]>
Reviewed-by: FUJITA Tomonori <[email protected]>
Fixes: e0c0ab04f6 ("rust: time: Make HasHrTimer generic over HrTimerMode")
Link: https://lore.kernel.org/r/[email protected]
[ Removed cast, applied `rustfmt`, fixed `Fixes:` tag. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
Pull timekeeping updates from Andreas Hindborg:
- Make 'Instant' generic over clock source. This allows the compiler to
assert that arithmetic expressions involving the 'Instant' use
'Instants' based on the same clock source.
- Make 'HrTimer' generic over the timer mode. 'HrTimer' timers take a
'Duration' or an 'Instant' when setting the expiry time, depending on
the timer mode. With this change, the compiler can check the type
matches the timer mode.
- Add an abstraction for 'fsleep'. 'fsleep' is a flexible sleep
function that will select an appropriate sleep method depending on
the requested sleep time.
- Avoid 64-bit divisions on 32-bit hardware when calculating
timestamps.
- Seal the 'HrTimerMode' trait. This prevents users of the
'HrTimerMode' from implementing the trait on their own types.
* tag 'rust-timekeeping-for-v6.17' of https://github.com/Rust-for-Linux/linux:
rust: time: Add wrapper for fsleep() function
rust: time: Seal the HrTimerMode trait
rust: time: Remove Ktime in hrtimer
rust: time: Make HasHrTimer generic over HrTimerMode
rust: time: Add HrTimerExpires trait
rust: time: Replace HrTimerMode enum with trait-based mode types
rust: time: Add ktime_get() to ClockSource trait
rust: time: Make Instant generic over ClockSource
rust: time: Replace ClockId enum with ClockSource trait
rust: time: Avoid 64-bit integer division on 32-bit architectures
Pull alloc and DMA updates from Danilo Krummrich:
Box:
- Implement Borrow / BorrowMut for Box<T, A>.
Vec:
- Implement Default for Vec<T, A>.
- Implement Borrow / BorrowMut for Vec<T, A>.
DMA:
- Clarify wording and be consistent in 'coherent' nomenclature.
- Convert the read!() / write!() macros to return a Result.
- Add as_slice() / write() methods in CoherentAllocation.
- Fix doc-comment of dma_handle().
- Expose count() and size() in CoherentAllocation and add the
corresponding type invariants.
- Implement CoherentAllocation::dma_handle_with_offset().
- Require mutable reference for as_slice_mut() and write().
MAINTAINERS:
- Add Vlastimil Babka, Liam R. Howlett, Uladzislau Rezki and Lorenzo
Stoakes as reviewers (thanks everyone).
* tag 'alloc-next-v6.17-2025-07-15' of https://github.com/Rust-for-Linux/linux:
MAINTAINERS: add mm folks as reviewers to rust alloc
rust: dma: require mutable reference for as_slice_mut() and write()
rust: dma: add dma_handle_with_offset method to CoherentAllocation
rust: dma: expose the count and size of CoherentAllocation
rust: dma: fix doc-comment of dma_handle()
rust: dma: add as_slice/write functions for CoherentAllocation
rust: dma: convert the read/write macros to return Result
rust: dma: clarify wording and be consistent in `coherent` nomenclature
rust: alloc: implement `Borrow` and `BorrowMut` for `KBox`
rust: alloc: implement `Borrow` and `BorrowMut` for `Vec`
rust: vec: impl Default for Vec with any allocator
This patch is being sent for use in the various Rust GPU drivers that
are under development. It provides the additional feature of work items
that are executed after a delay.
The design of the existing workqueue is rather extensible, as most of
the logic is reused for delayed work items even though a different work
item type is required. The new logic consists of:
* A new DelayedWork struct that wraps struct delayed_work.
* A new impl_has_delayed_work! macro that provides adjusted versions of
the container_of logic, that is suitable with delayed work items.
* A `enqueue_delayed` method that can enqueue a delayed work item.
This patch does *not* rely on the fact that `struct delayed_work`
contains `struct work_struct` at offset zero. It will continue to work
even if the layout is changed to hold the `work` field at a different
offset.
Please see the example introduced at the top of the file for example
usage of delayed work items.
Acked-by: Tejun Heo <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Replaced `as _` with `as ffi::c_int` to clean warning. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
In the previous patch we added Opaque::cast_from() that performs the
opposite operation to Opaque::raw_get(). For consistency with this
naming, rename raw_get() to cast_from().
There are a few other options such as calling cast_from() something
closer to raw_get() rather than renaming this method. However, I could
not find a great naming scheme that works with raw_get(). The previous
version of this patch used from_raw(), but functions of that name
typically have a different signature, so that's not a great option.
Suggested-by: Danilo Krummrich <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Acked-by: Benno Lossin <[email protected]>
Acked-by: Andreas Hindborg <[email protected]>
Acked-by: Boqun Feng <[email protected]>
Reviewed-by: Danilo Krummrich <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Removed `HrTimer::raw_get` change. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
Since commit b20fbbc08a ("rust: check type of `$ptr` in
`container_of!`") we have enforced that the field pointer passed to
container_of! must match the declared field. This caused mismatches when
using a pointer to bindings::x for fields of type Opaque<bindings::x>.
This situation encourages the user to simply pass field.cast() to the
container_of! macro, but this is not great because you might
accidentally pass a *mut bindings::y when the field type is
Opaque<bindings::x>, which would be wrong.
To help catch this kind of mistake, add a new Opaque::cast_from that
wraps a raw pointer in Opaque without changing the inner type. Also
update the docs to reflect this as well as some existing users.
Signed-off-by: Alice Ryhl <[email protected]>
Acked-by: Andreas Hindborg <[email protected]>
Acked-by: Boqun Feng <[email protected]>
Reviewed-by: Danilo Krummrich <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
The intended implementations of `ForeignOwnable` will not return null
pointers from `into_foreign`, as this would render the implementation of
`try_from_foreign` useless. Current users of `ForeignOwnable` rely on
`into_foreign` returning non-null pointers. So require `into_foreign` to
return non-null pointers.
Suggested-by: Benno Lossin <[email protected]>
Suggested-by: Alice Ryhl <[email protected]>
Signed-off-by: Andreas Hindborg <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
The current implementation of `ForeignOwnable` is leaking the type of the
opaque pointer to consumers of the API. This allows consumers of the opaque
pointer to rely on the information that can be extracted from the pointer
type.
To prevent this, change the API to the version suggested by Maira
Canal (link below): Remove `ForeignOwnable::PointedTo` in favor of a
constant, which specifies the alignment of the pointers returned by
`into_foreign`.
With this change, `ArcInner` no longer needs `pub` visibility, so change it
to private.
Suggested-by: Alice Ryhl <[email protected]>
Suggested-by: Maíra Canal <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Danilo Krummrich <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Andreas Hindborg <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
The previous version used a verbose `match` to get
`current`, which may be slightly confusing at first
glance.
This change makes it shorter and more clearly expresses
the intent: prefer `next` if available, otherwise fall
back to `prev`.
Signed-off-by: Onur Özkan <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
Currently, Rust code uses a typedef for unsigned long to represent
userspace addresses. This is unfortunate because it means that userspace
addresses could accidentally be mixed up with other integers. To
alleviate that, we introduce a new UserPtr struct that wraps a raw
pointer to represent a userspace address. By using a struct, type
checking enforces that userspace addresses cannot be mixed up with
anything else.
This is similar to the __user annotation in C that detects cases where
user pointers are mixed with non-user pointers.
Note that unlike __user pointers in C, this type is just a pointer
without a target type. This means that it can't detect cases such as
mixing up which struct this user pointer references. However, that is
okay due to the way this is intended to be used - generally, you create
a UserPtr in your ioctl callback from the provided usize *before*
dispatching on which ioctl is in use, and then after dispatching on the
ioctl you pass the UserPtr into a UserSliceReader or UserSliceWriter;
selecting the target type does not happen until you have obtained the
UserSliceReader/Writer.
The UserPtr type is not marked with #[derive(Debug)], which means that
it's not possible to print values of this type. This avoids ASLR
leakage.
The type is added to the prelude as it is a fairly fundamental type
similar to c_int. The wrapping_add() method is renamed to
wrapping_byte_add() for consistency with the method name found on raw
pointers.
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Danilo Krummrich <[email protected]>
Reviewed-by: Christian Schrefl <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
This patch adds a more convenient method for reading C strings from
userspace. Logic is added to NUL-terminate the buffer when necessary so
that a &CStr can be returned.
Note that we treat attempts to read past `self.length` as a fault, so
this returns EFAULT if that limit is exceeded before `buf.len()` is
reached.
Reviewed-by: Danilo Krummrich <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Use `from_mut` to clean `clippy::ref_as_ptr` lint. Reworded
title. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
This patch adds a direct wrapper around the C function of the same name.
It's not really intended for direct use by Rust code since
strncpy_from_user has a somewhat unfortunate API where it only
nul-terminates the buffer if there's space for the nul-terminator. This
means that a direct Rust wrapper around it could not return a &CStr
since the buffer may not be a cstring. However, we still add the method
to build more convenient APIs on top of it, which will happen in
subsequent patches.
Reviewed-by: Danilo Krummrich <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
Pull pin-init updates from Benno Lossin:
"Added:
- 'impl<T, E> [Pin]Init<T, E> for Result<T, E>', so results are now
(pin-)initializers.
- 'Zeroable::init_zeroed()' delegating to 'init_zeroed()'.
- New 'zeroed()', a safe version of 'mem::zeroed()' and also provide
it via 'Zeroable::zeroed()'.
- Implement 'Zeroable' for 'Option<&T>' and 'Option<&mut T>'.
- Implement 'Zeroable' for 'Option<[unsafe] [extern "abi"]
fn(...args...) -> ret>' for '"Rust"' and '"C"' ABIs and up to 20
arguments.
Changed:
- Blanket impls of 'Init' and 'PinInit' from 'impl<T, E>
[Pin]Init<T, E> for T' to 'impl<T> [Pin]Init<T> for T'.
- Renamed 'zeroed()' to 'init_zeroed()'.
Upstream dev news:
- More CI improvements to deny warnings, use '--all-targets'. Also
check the synchronization status of the two '-next' branches in
upstream and the kernel."
Acked-by: Andreas Hindborg <[email protected]>
* tag 'pin-init-v6.17' of https://github.com/Rust-for-Linux/linux:
rust: pin-init: examples, tests: use `ignore` instead of conditionally compiling tests
rust: init: remove doctest's `Error::from_errno` workaround
rust: init: re-enable doctests
rust: pin-init: implement `ZeroableOption` for function pointers with up to 20 arguments
rust: pin-init: change `impl Zeroable for Option<NonNull<T>>` to `ZeroableOption for NonNull<T>`
rust: pin-init: implement `ZeroableOption` for `&T` and `&mut T`
rust: pin-init: add `zeroed()` & `Zeroable::zeroed()` functions
rust: pin-init: add `Zeroable::init_zeroed`
rust: pin-init: rename `zeroed` to `init_zeroed`
rust: pin-init: feature-gate the `stack_init_reuse` test on the `std` feature
rust: pin-init: examples: pthread_mutex: disable the main test for miri
rust: pin-init: examples, tests: add conditional compilation in order to compile under any feature combination
rust: pin-init: change blanket impls for `[Pin]Init` and add one for `Result<T, E>`
rust: pin-init: improve safety documentation for `impl<T> [Pin]Init<T> for T`
Implement `Borrow<T>` and `BorrowMut<T>` for `UniqueArc<T>`, and
`Borrow<T>` for `Arc<T>`. This allows these containers to be used in
generic APIs asking for types implementing those traits. `T` and `&mut
T` also implement those traits allowing users to use either owned,
shared or borrowed values.
`ForeignOwnable` makes a call to its own `borrow` method which must be
disambiguated.
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
Add a wrapper for fsleep(), flexible sleep functions in
include/linux/delay.h which typically deals with hardware delays.
The kernel supports several sleep functions to handle various lengths
of delay. This adds fsleep(), automatically chooses the best sleep
method based on a duration.
fsleep() can only be used in a nonatomic context. This requirement is
not checked by these abstractions, but it is intended that klint [1]
or a similar tool will be used to check it in the future.
Link: https://rust-for-linux.com/klint [1]
Reviewed-by: Gary Guo <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
Tested-by: Daniel Almeida <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Signed-off-by: FUJITA Tomonori <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andreas Hindborg <[email protected]>
Prevent downstream crates or drivers from implementing `HrTimerMode`
for arbitrary types, which could otherwise leads to unsupported
behavior.
Introduce a `private::Sealed` trait and implement it for all types
that implement `HrTimerMode`.
Signed-off-by: FUJITA Tomonori <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andreas Hindborg <[email protected]>
In Rust Binder I need to be able to determine whether a red/black tree
is empty. Thus, add a method for that operation to replace
rbtree.iter().next().is_none()
This is terrible, so add a method for this purpose. We do not add a
RBTree::len method because computing the number of elements requires
iterating the entire tree, but checking whether it is empty can be done
cheaply.
Signed-off-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Adjusted title. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
Remove the use of `Ktime` from the hrtimer code, which was originally
introduced as a temporary workaround. The hrtimer has now been fully
converted to use the `Instant` and `Delta` types instead.
Reviewed-by: Andreas Hindborg <[email protected]>
Signed-off-by: FUJITA Tomonori <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andreas Hindborg <[email protected]>
Add a `TimerMode` associated type to the `HasHrTimer` trait to
represent the operational mode of the timer, such as absolute or
relative expiration. This new type must implement the `HrTimerMode`
trait, which defines how expiration values are interpreted.
Update the `start()` method to accept an `expires` parameter of type
`<Self::TimerMode as HrTimerMode>::Expires` instead of the fixed `Ktime`.
This enables different timer modes to provide strongly typed expiration
values, such as `Instant<C>` or `Delta`.
The `impl_has_hr_timer` macro is also extended to allow specifying the
`HrTimerMode`. In the following example, it guarantees that the
`start()` method for `Foo` only accepts `Instant<Monotonic>`. Using a
`Delta` or an `Instant` with a different clock source will result in a
compile-time error:
struct Foo {
#[pin]
timer: HrTimer<Self>,
}
impl_has_hr_timer! {
impl HasHrTimer<Self> for Foo {
mode : AbsoluteMode<Monotonic>,
field : self.timer
}
}
This design eliminates runtime mismatches between expires types and
clock sources, and enables stronger type-level guarantees throughout
hrtimer.
Signed-off-by: FUJITA Tomonori <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ changed conversion method names to `as_*` - Andreas ]
Signed-off-by: Andreas Hindborg <[email protected]>
Introduce the `HrTimerExpires` trait to represent types that can be
used as expiration values for high-resolution timers. Define a
required method, `into_nanos()`, which returns the expiration time as a
raw nanosecond value suitable for use with C's hrtimer APIs.
Also extend the `HrTimerMode` to use the `HrTimerExpires` trait.
This refactoring is a preparation for enabling hrtimer code to work
uniformly with both absolute and relative expiration modes.
Reviewed-by: Andreas Hindborg <[email protected]>
Signed-off-by: FUJITA Tomonori <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ changed conversion method names to `as_*` - Andreas ]
Signed-off-by: Andreas Hindborg <[email protected]>
Replace the `HrTimerMode` enum with a trait-based approach that uses
zero-sized types to represent each mode of operation. Each mode now
implements the `HrTimerMode` trait.
This refactoring is a preparation for replacing raw `Ktime` in HrTimer
with the `Instant` and `Delta` types, and for making `HrTimer` generic
over a `ClockSource`.
Reviewed-by: Andreas Hindborg <[email protected]>
Signed-off-by: FUJITA Tomonori <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andreas Hindborg <[email protected]>
Commit 38559da6af ("rust: module: introduce `authors` key") introduced
a new `authors` key to support multiple module authors, while keeping
the old `author` key for backward compatibility.
Now that most in-tree modules have migrated to `authors`, remove:
1. The deprecated `author` key support from the module macro
2. Legacy `author` entries from remaining modules
Signed-off-by: Guilherme Giacomo Simoes <[email protected]>
Acked-by: Andreas Hindborg <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
Remove `use core::ffi::c_void`, which shadows `kernel::ffi::c_void`
brought in via `use crate::prelude::*`, to maintain consistency and
centralize the abstraction.
Since `kernel::ffi::c_void` is a straightforward re-export of
`core::ffi::c_void`, both are functionally equivalent. However, using
`kernel::ffi::c_void` improves consistency across the kernel's Rust code
and provides a unified reference point in case the definition ever needs
to change, even if such a change is unlikely.
Reviewed-by: Benno Lossin <[email protected]>
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089/topic/x/near/520452733
Signed-off-by: Jesung Yang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
DMA features for v6.17
- Clarify wording and be consistent in 'coherent' nomenclature.
- Convert the read!() / write!() macros to return a Result.
- Add as_slice() / write() methods in CoherentAllocation.
- Fix doc-comment of dma_handle().
- Expose count() and size() in CoherentAllocation and add the
corresponding type invariants.
- Implement CoherentAllocation::dma_handle_with_offset().
Sometimes one may want to obtain a DMA handle starting at a given
offset. This can be done by adding said offset to the result of
`dma_handle()`, but doing so on the client side carries the risk that
the operation will go outside the bounds of the allocation.
Thus, add a `dma_handle_with_offset` method that adds the desired offset
after checking that it is still valid.
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
These properties are very useful to have (and to be used by nova-core)
and should be accessible, hence add them.
Additionally, add type invariants for the size of an allocation.
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Slightly extend the commit message. - Danilo ]
Signed-off-by: Danilo Krummrich <[email protected]>
Add unsafe accessors for the region for reading or writing large
blocks of data.
Reviewed-by: Andreas Hindborg <[email protected]>
Signed-off-by: Abdiel Janulgue <[email protected]>
Reviewed-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Fix line length and slightly reword safety comment in doc-test of
CoherentAllocation::write(); fix formatting issue. - Danilo ]
Signed-off-by: Danilo Krummrich <[email protected]>
In the kernel, `consistent` and `coherent` are used interchangeably for the
region described in this api. Stick with `coherent` nomenclature
to show that dma_alloc_coherent() is being used, in addition to improving
the clarity in the DMA mapping attributes documentation.
Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Abdiel Janulgue <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
Before Rust 1.29.0, Clippy introduced the `cast_lossless` lint [1]:
> Rust’s `as` keyword will perform many kinds of conversions, including
> silently lossy conversions. Conversion functions such as `i32::from`
> will only perform lossless conversions. Using the conversion functions
> prevents conversions from becoming silently lossy if the input types
> ever change, and makes it clear for people reading the code that the
> conversion is lossless.
While this doesn't eliminate unchecked `as` conversions, it makes such
conversions easier to scrutinize. It also has the slight benefit of
removing a degree of freedom on which to bikeshed. Thus apply the
changes and enable the lint -- no functional change intended.
Link: https://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless [1]
Suggested-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/all/[email protected]/
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: Tamir Duberstein <[email protected]>
Acked-by: FUJITA Tomonori <[email protected]>
Acked-by: Jocelyn Falempe <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
In Rust 1.63.0, Clippy introduced the `as_underscore` lint [1]:
> The conversion might include lossy conversion or a dangerous cast that
> might go undetected due to the type being inferred.
>
> The lint is allowed by default as using `_` is less wordy than always
> specifying the type.
Always specifying the type is especially helpful in function call
contexts where the inferred type may change at a distance. Specifying
the type also allows Clippy to spot more cases of `useless_conversion`.
The primary downside is the need to specify the type in trivial getters.
There are 4 such functions: 3 have become slightly less ergonomic, 1 was
revealed to be a `useless_conversion`.
While this doesn't eliminate unchecked `as` conversions, it makes such
conversions easier to scrutinize. It also has the slight benefit of
removing a degree of freedom on which to bikeshed. Thus apply the
changes and enable the lint -- no functional change intended.
Link: https://rust-lang.github.io/rust-clippy/master/index.html#as_underscore [1]
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: Tamir Duberstein <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Changed `isize` to `c_long`. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
In Rust 1.66.0, Clippy introduced the `as_ptr_cast_mut` lint [1]:
> Since `as_ptr` takes a `&self`, the pointer won’t have write
> permissions unless interior mutability is used, making it unlikely
> that having it as a mutable pointer is correct.
There is only one affected callsite, and the change amounts to replacing
`as _` with `.cast_mut().cast()`. This doesn't change the semantics, but
is more descriptive of what's going on.
Apply this change and enable the lint -- no functional change intended.
Link: https://rust-lang.github.io/rust-clippy/master/index.html#as_ptr_cast_mut [1]
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: Tamir Duberstein <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
In Rust 1.72.0, Clippy introduced the `ptr_cast_constness` lint [1]:
> Though `as` casts between raw pointers are not terrible,
> `pointer::cast_mut` and `pointer::cast_const` are safer because they
> cannot accidentally cast the pointer to another type.
There are only 3 affected sites:
- `*mut T as *const U as *mut U` becomes `(*mut T).cast()`.
- `&self as *const Self as *mut Self` becomes
`core::ptr::from_ref(self).cast_mut()`.
- `*const T as *mut _` becommes `(*const T).cast_mut()`.
Apply these changes and enable the lint -- no functional change
intended.
Link: https://rust-lang.github.io/rust-clippy/master/index.html#ptr_cast_constness [1]
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: Tamir Duberstein <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
In Rust 1.51.0, Clippy introduced the `ptr_as_ptr` lint [1]:
> Though `as` casts between raw pointers are not terrible,
> `pointer::cast` is safer because it cannot accidentally change the
> pointer's mutability, nor cast the pointer to other types like `usize`.
There are a few classes of changes required:
- Modules generated by bindgen are marked
`#[allow(clippy::ptr_as_ptr)]`.
- Inferred casts (` as _`) are replaced with `.cast()`.
- Ascribed casts (` as *... T`) are replaced with `.cast::<T>()`.
- Multistep casts from references (` as *const _ as *const T`) are
replaced with `core::ptr::from_ref(&x).cast()` with or without `::<T>`
according to the previous rules. The `core::ptr::from_ref` call is
required because `(x as *const _).cast::<T>()` results in inference
failure.
- Native literal C strings are replaced with `c_str!().as_char_ptr()`.
- `*mut *mut T as _` is replaced with `let *mut *const T = (*mut *mut
T)`.cast();` since pointer to pointer can be confusing.
Apply these changes and enable the lint -- no functional change
intended.
Link: https://rust-lang.github.io/rust-clippy/master/index.html#ptr_as_ptr [1]
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: Tamir Duberstein <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added `.cast()` for `opp`. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
Pull driver core fixes from Danilo Krummrich:
- Fix a race condition in Devres::drop(). This depends on two other
patches:
- (Minimal) Rust abstractions for struct completion
- Let Revocable indicate whether its data is already being revoked
- Fix Devres to avoid exposing the internal Revocable
- Add .mailmap entry for Danilo Krummrich
- Add Madhavan Srinivasan to embargoed-hardware-issues.rst
* tag 'driver-core-6.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core:
Documentation: embargoed-hardware-issues.rst: Add myself for Power
mailmap: add entry for Danilo Krummrich
rust: devres: do not dereference to the internal Revocable
rust: devres: fix race in Devres::drop()
rust: revocable: indicate whether `data` has been revoked already
rust: completion: implement initial abstraction
Implement `Borrow<T>` and `BorrowMut<T>` for `KBox<T>`. This allows
`KBox<T>` to be used in generic APIs asking for types implementing those
traits. `T` and `&mut T` also implement those traits allowing users to
use either owned, borrowed and heap-owned values.
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
Implement `Borrow<[T]>` and `BorrowMut<[T]>` for `Vec<T>`. This allows
`Vec<T>` to be used in generic APIs asking for types implementing those
traits. `[T; N]` and `&mut [T]` also implement those traits allowing
users to use either owned, borrowed and heap-owned values.
The implementation leverages `as_slice` and `as_mut_slice`.
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
Introduce the ktime_get() associated function to the ClockSource
trait, allowing each clock source to specify how it retrieves the
current time. This enables Instant::now() to be implemented
generically using the type-level ClockSource abstraction.
This change enhances the type safety and extensibility of timekeeping
by statically associating time retrieval mechanisms with their
respective clock types. It also reduces the reliance on hardcoded
clock logic within Instant.
Signed-off-by: FUJITA Tomonori <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andreas Hindborg <[email protected]>
Refactor the Instant type to be generic over a ClockSource type
parameter, enabling static enforcement of clock correctness across
APIs that deal with time. Previously, the clock source was implicitly
fixed (typically CLOCK_MONOTONIC), and developers had to ensure
compatibility manually.
This design eliminates runtime mismatches between clock sources, and
enables stronger type-level guarantees throughout the timer subsystem.
Reviewed-by: Andreas Hindborg <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: FUJITA Tomonori <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andreas Hindborg <[email protected]>
Replace the ClockId enum with a trait-based abstraction called
ClockSource. This change enables expressing clock sources as types and
leveraging the Rust type system to enforce clock correctness at
compile time.
This also sets the stage for future generic abstractions over Instant
types such as Instant<C>.
Reviewed-by: Andreas Hindborg <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: FUJITA Tomonori <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andreas Hindborg <[email protected]>
Avoid 64-bit integer division that 32-bit architectures don't
implement generally. This uses ktime_to_us() and ktime_to_ms()
instead.
The time abstraction needs i64 / u32 division so C's div_s64() can be
used but ktime_to_us() and ktime_to_ms() provide a simpler solution
for this time abstraction problem on 32-bit architectures.
32-bit ARM is the only 32-bit architecture currently supported by
Rust. Using the cfg attribute, only 32-bit architectures will call
ktime_to_us() and ktime_to_ms(), while the other 64-bit architectures
will continue to use the current code as-is to avoid the overhead.
One downside of calling the C's functions is that the as_micros/millis
methods can no longer be const fn. We stick with the simpler approach
unless there's a compelling need for a const fn.
Suggested-by: Arnd Bergmann <[email protected]>
Suggested-by: Boqun Feng <[email protected]>
Signed-off-by: FUJITA Tomonori <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andreas Hindborg <[email protected]>
Pull Rust fix from Miguel Ojeda:
- 'hrtimer': fix future compile error when the 'impl_has_hr_timer!'
macro starts to get called
* tag 'rust-fixes-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
rust: time: Fix compile error in impl_has_hr_timer macro
We can't expose direct access to the internal Revocable, since this
allows users to directly revoke the internal Revocable without Devres
having the chance to synchronize with the devres callback -- we have to
guarantee that the internal Revocable has been fully revoked before
the device is fully unbound.
Hence, remove the corresponding Deref implementation and, instead,
provide indirect accessors for the internal Revocable.
Note that we can still support Devres::revoke() by implementing the
required synchronization (which would be almost identical to the
synchronization in Devres::drop()).
Fixes: 76c01ded72 ("rust: add devres abstraction")
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
Lyude Paul