| 57c1ccc7 | 23-Nov-2024 |
Daniel Sedlak <daniel@sedlak.dev> |
rust: page: remove unnecessary helper function from doctest
Doctests in `page.rs` contained a helper function `dox` which acted
as a wrapper for using the `?` operator. However, this is not needed
b
rust: page: remove unnecessary helper function from doctest
Doctests in `page.rs` contained a helper function `dox` which acted
as a wrapper for using the `?` operator. However, this is not needed
because doctests are implicitly wrapped in function see [1].
Link: https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html#using--in-doc-tests [1]
Suggested-by: Dirk Behme <dirk.behme@de.bosch.com>
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://lore.kernel.org/rust-for-linux/459782fe-afca-4fe6-8ffb-ba7c7886de0a@de.bosch.com/
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Tamir Duberstein <tamird@gmail.com>
Signed-off-by: Daniel Sedlak <daniel@sedlak.dev>
Link: https://lore.kernel.org/r/20241123095033.41240-4-daniel@sedlak.dev
[ Fixed typo in SoB. Slightly reworded commit. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 3a518544 | 23-Nov-2024 |
Daniel Sedlak <daniel@sedlak.dev> |
rust: rbtree: remove unwrap in asserts
Remove `unwrap` in asserts and replace it with `Option::Some`
matching. By doing it this way, the examples are more
descriptive, so it disambiguates the return
rust: rbtree: remove unwrap in asserts
Remove `unwrap` in asserts and replace it with `Option::Some`
matching. By doing it this way, the examples are more
descriptive, so it disambiguates the return type of
the `get(...)` and `next(...)`, because the `unwrap(...)`
can also be called on `Result`.
Signed-off-by: Daniel Sedlak <daniel@sedlak.dev>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20241123095033.41240-3-daniel@sedlak.dev
[ Reworded title slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 7eeb0e7a | 23-Nov-2024 |
Daniel Sedlak <daniel@sedlak.dev> |
rust: init: replace unwraps with question mark operators
Use `?` operator in the doctests. Since it is in the examples,
using unwraps can convey a wrong impression that unwrapping is
fine in general
rust: init: replace unwraps with question mark operators
Use `?` operator in the doctests. Since it is in the examples,
using unwraps can convey a wrong impression that unwrapping is
fine in general, thus this patch removes this unwrapping.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://lore.kernel.org/rust-for-linux/CANiq72nsK1D4NuQ1U7NqMWoYjXkqQSj4QuUEL98OmFbq022Z9A@mail.gmail.com/
Signed-off-by: Daniel Sedlak <daniel@sedlak.dev>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20241123095033.41240-2-daniel@sedlak.dev
[ Reworded commit slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| bf2aa7df | 10-Jan-2025 |
Alice Ryhl <aliceryhl@google.com> |
miscdevice: rust: use build_error! macro instead of function
The function called build_error is an implementation detail of the macro
of the same name. Thus, update miscdevice to use the macro rathe
miscdevice: rust: use build_error! macro instead of function
The function called build_error is an implementation detail of the macro
of the same name. Thus, update miscdevice to use the macro rather than
the function. See [1] for more information on this.
These use the macro with the kernel:: prefix as it has not yet been
added to the prelude.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20250110162828.38614c1b@canb.auug.org.au
Link: https://lore.kernel.org/all/20241123222849.350287-2-ojeda@kernel.org/ [1]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://lore.kernel.org/r/20250110101459.536726-1-aliceryhl@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| 4401565f | 23-Nov-2024 |
Miguel Ojeda <ojeda@kernel.org> |
rust: add `build_error!` to the prelude
The sibling `build_assert!` is already in the prelude, it makes sense
that a "core"/"language" facility like this is part of the prelude and
users should not
rust: add `build_error!` to the prelude
The sibling `build_assert!` is already in the prelude, it makes sense
that a "core"/"language" facility like this is part of the prelude and
users should not be defining their own one (thus there should be no risk
of future name collisions and we would want to be aware of them anyway).
Thus add `build_error!` into the prelude.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20241123222849.350287-3-ojeda@kernel.org
[ Applied the change to the new miscdevice cases. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 614724e7 | 23-Nov-2024 |
Miguel Ojeda <ojeda@kernel.org> |
rust: kernel: move `build_error` hidden function to prevent mistakes
Users were using the hidden exported `kernel::build_error` function
instead of the intended `kernel::build_error!` macro, e.g. se
rust: kernel: move `build_error` hidden function to prevent mistakes
Users were using the hidden exported `kernel::build_error` function
instead of the intended `kernel::build_error!` macro, e.g. see the
previous commit.
To force to use the macro, move it into the `build_assert` module,
thus making it a compilation error and avoiding a collision in the same
"namespace". Using the function now would require typing the module name
(which is hidden), not just a single character.
Now attempting to use the function will trigger this error with the
right suggestion by the compiler:
error[E0423]: expected function, found macro `kernel::build_error`
--> samples/rust/rust_minimal.rs:29:9
|
29 | kernel::build_error();
| ^^^^^^^^^^^^^^^^^^^ not a function
|
help: use `!` to invoke the macro
|
29 | kernel::build_error!();
| +
An alternative would be using an alias, but it would be more complex
and moving it into the module seems right since it belongs there and
reduces the amount of code at the crate root.
Keep the `#[doc(hidden)]` inside `build_assert` in case the module is
not hidden in the future.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20241123222849.350287-2-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 15f2f931 | 23-Nov-2024 |
Miguel Ojeda <ojeda@kernel.org> |
rust: use the `build_error!` macro, not the hidden function
Code and some examples were using the function, rather than the macro. The
macro is what is documented.
Thus move users to the macro.
Re
rust: use the `build_error!` macro, not the hidden function
Code and some examples were using the function, rather than the macro. The
macro is what is documented.
Thus move users to the macro.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20241123222849.350287-1-ojeda@kernel.org
[ Applied the change to the new miscdevice cases. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 2a87f8b0 | 23-Nov-2024 |
Miguel Ojeda <ojeda@kernel.org> |
rust: kbuild: run Clippy for `rusttest` code
Running Clippy for `rusttest` code is useful to catch issues there too,
even if the code is not as critical. In the future, this code may also
run in ker
rust: kbuild: run Clippy for `rusttest` code
Running Clippy for `rusttest` code is useful to catch issues there too,
even if the code is not as critical. In the future, this code may also
run in kernelspace and could be copy-pasted. Thus it is useful to keep
it under the same standards. For instance, it will now make us add
`// SAFETY` comments.
It also makes everything more consistent.
Thus clean the few issues spotted by Clippy and start running it.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20241123180639.260191-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| e1a51c2b | 03-Jan-2025 |
Danilo Krummrich <dakr@kernel.org> |
rust: driver: address soundness issue in `RegistrationOps`
The `RegistrationOps` trait holds some obligations to the caller and
implementers. While being documented, the trait and the corresponding
rust: driver: address soundness issue in `RegistrationOps`
The `RegistrationOps` trait holds some obligations to the caller and
implementers. While being documented, the trait and the corresponding
functions haven't been marked as unsafe.
Hence, markt the trait and functions unsafe and add the corresponding
safety comments.
This patch does not include any fuctional changes.
Reported-by: Gary Guo <gary@garyguo.net>
Closes: https://lore.kernel.org/rust-for-linux/20241224195821.3b43302b.gary@garyguo.net/
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/r/20250103164655.96590-4-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| 9b880189 | 03-Jan-2025 |
Danilo Krummrich <dakr@kernel.org> |
rust: io: move module entry to its correct location
The module entry of `io` falsely ended up in the "use" block instead of
the "mod" block, hence move it to its correct location.
Signed-off-by: Da
rust: io: move module entry to its correct location
The module entry of `io` falsely ended up in the "use" block instead of
the "mod" block, hence move it to its correct location.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250103164655.96590-3-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| 683a63be | 19-Dec-2024 |
Danilo Krummrich <dakr@kernel.org> |
rust: platform: add basic platform device / driver abstractions
Implement the basic platform bus abstractions required to write a basic
platform driver. This includes the following data structures:
rust: platform: add basic platform device / driver abstractions
Implement the basic platform bus abstractions required to write a basic
platform driver. This includes the following data structures:
The `platform::Driver` trait represents the interface to the driver and
provides `platform::Driver::probe` for the driver to implement.
The `platform::Device` abstraction represents a `struct platform_device`.
In order to provide the platform bus specific parts to a generic
`driver::Registration` the `driver::RegistrationOps` trait is implemented
by `platform::Adapter`.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://lore.kernel.org/r/20241219170425.12036-15-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| 7a718a1f | 19-Dec-2024 |
Danilo Krummrich <dakr@kernel.org> |
rust: driver: implement `Adapter`
In order to not duplicate code in bus specific implementations (e.g.
platform), implement a generic `driver::Adapter` to represent the
connection of matched drivers
rust: driver: implement `Adapter`
In order to not duplicate code in bus specific implementations (e.g.
platform), implement a generic `driver::Adapter` to represent the
connection of matched drivers and devices.
Bus specific `Adapter` implementations can simply implement this trait
to inherit generic functionality, such as matching OF or ACPI device IDs
and ID table entries.
Suggested-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://lore.kernel.org/r/20241219170425.12036-14-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| bbe3b4d1 | 19-Dec-2024 |
Danilo Krummrich <dakr@kernel.org> |
rust: of: add `of::DeviceId` abstraction
`of::DeviceId` is an abstraction around `struct of_device_id`.
This is used by subsequent patches, in particular the platform bus
abstractions, to create OF
rust: of: add `of::DeviceId` abstraction
`of::DeviceId` is an abstraction around `struct of_device_id`.
This is used by subsequent patches, in particular the platform bus
abstractions, to create OF device ID tables.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Tested-by: Fabien Parent <fabien.parent@linaro.org>
Link: https://lore.kernel.org/r/20241219170425.12036-13-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| bf9651f8 | 19-Dec-2024 |
Danilo Krummrich <dakr@kernel.org> |
rust: pci: implement I/O mappable `pci::Bar`
Implement `pci::Bar`, `pci::Device::iomap_region` and
`pci::Device::iomap_region_sized` to allow for I/O mappings of PCI BARs.
To ensure that a `pci::Ba
rust: pci: implement I/O mappable `pci::Bar`
Implement `pci::Bar`, `pci::Device::iomap_region` and
`pci::Device::iomap_region_sized` to allow for I/O mappings of PCI BARs.
To ensure that a `pci::Bar`, and hence the I/O memory mapping, can't
out-live the PCI device, the `pci::Bar` type is always embedded into a
`Devres` container, such that the `pci::Bar` is revoked once the device
is unbound and hence the I/O mapped memory is unmapped.
A `pci::Bar` can be requested with (`pci::Device::iomap_region_sized`) or
without (`pci::Device::iomap_region`) a const generic representing the
minimal requested size of the I/O mapped memory region. In case of the
latter only runtime checked I/O reads / writes are possible.
Co-developed-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://lore.kernel.org/r/20241219170425.12036-11-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| 1bd8b6b2 | 19-Dec-2024 |
Danilo Krummrich <dakr@kernel.org> |
rust: pci: add basic PCI device / driver abstractions
Implement the basic PCI abstractions required to write a basic PCI
driver. This includes the following data structures:
The `pci::Driver` trait
rust: pci: add basic PCI device / driver abstractions
Implement the basic PCI abstractions required to write a basic PCI
driver. This includes the following data structures:
The `pci::Driver` trait represents the interface to the driver and
provides `pci::Driver::probe` for the driver to implement.
The `pci::Device` abstraction represents a `struct pci_dev` and provides
abstractions for common functions, such as `pci::Device::set_master`.
In order to provide the PCI specific parts to a generic
`driver::Registration` the `driver::RegistrationOps` trait is implemented
by `pci::Adapter`.
`pci::DeviceId` implements PCI device IDs based on the generic
`device_id::RawDevceId` abstraction.
Co-developed-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://lore.kernel.org/r/20241219170425.12036-10-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| 76c01ded | 19-Dec-2024 |
Danilo Krummrich <dakr@kernel.org> |
rust: add devres abstraction
Add a Rust abstraction for the kernel's devres (device resource
management) implementation.
The Devres type acts as a container to manage the lifetime and
accessibility
rust: add devres abstraction
Add a Rust abstraction for the kernel's devres (device resource
management) implementation.
The Devres type acts as a container to manage the lifetime and
accessibility of device bound resources. Therefore it registers a
devres callback and revokes access to the resource on invocation.
Users of the Devres abstraction can simply free the corresponding
resources in their Drop implementation, which is invoked when either the
Devres instance goes out of scope or the devres callback leads to the
resource being revoked, which implies a call to drop_in_place().
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://lore.kernel.org/r/20241219170425.12036-9-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| ce30d94e | 19-Dec-2024 |
Danilo Krummrich <dakr@kernel.org> |
rust: add `io::{Io, IoRaw}` base types
I/O memory is typically either mapped through direct calls to ioremap()
or subsystem / bus specific ones such as pci_iomap().
Even though subsystem / bus spec
rust: add `io::{Io, IoRaw}` base types
I/O memory is typically either mapped through direct calls to ioremap()
or subsystem / bus specific ones such as pci_iomap().
Even though subsystem / bus specific functions to map I/O memory are
based on ioremap() / iounmap() it is not desirable to re-implement them
in Rust.
Instead, implement a base type for I/O mapped memory, which generically
provides the corresponding accessors, such as `Io::readb` or
`Io:try_readb`.
`Io` supports an optional const generic, such that a driver can indicate
the minimal expected and required size of the mapping at compile time.
Correspondingly, calls to the 'non-try' accessors, support compile time
checks of the I/O memory offset to read / write, while the 'try'
accessors, provide boundary checks on runtime.
`IoRaw` is meant to be embedded into a structure (e.g. pci::Bar or
io::IoMem) which creates the actual I/O memory mapping and initializes
`IoRaw` accordingly.
To ensure that I/O mapped memory can't out-live the device it may be
bound to, subsystems must embed the corresponding I/O memory type (e.g.
pci::Bar) into a `Devres` container, such that it gets revoked once the
device is unbound.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://lore.kernel.org/r/20241219170425.12036-8-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| 0494d9c8 | 19-Dec-2024 |
Wedson Almeida Filho <wedsonaf@gmail.com> |
rust: add `Revocable` type
Revocable allows access to objects to be safely revoked at run time.
This is useful, for example, for resources allocated during device probe;
when the device is removed,
rust: add `Revocable` type
Revocable allows access to objects to be safely revoked at run time.
This is useful, for example, for resources allocated during device probe;
when the device is removed, the driver should stop accessing the device
resources even if another state is kept in memory due to existing
references (i.e., device context data is ref-counted and has a non-zero
refcount after removal of the device).
Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com>
Co-developed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://lore.kernel.org/r/20241219170425.12036-7-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| 2d3bf6ff | 19-Dec-2024 |
Danilo Krummrich <dakr@kernel.org> |
rust: types: add `Opaque::pin_init`
Analogous to `Opaque::new` add `Opaque::pin_init`, which instead of a
value `T` takes a `PinInit<T>` and returns a `PinInit<Opaque<T>>`.
Reviewed-by: Alice Ryhl
rust: types: add `Opaque::pin_init`
Analogous to `Opaque::new` add `Opaque::pin_init`, which instead of a
value `T` takes a `PinInit<T>` and returns a `PinInit<Opaque<T>>`.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Tested-by: Fabien Parent <fabien.parent@linaro.org>
Link: https://lore.kernel.org/r/20241219170425.12036-6-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|