rust: error: import `kernel`'s `LayoutError` instead of `core`'s

Import the internal (`kernel::alloc`) version of `LayoutError` instead
of the `core::alloc` one.

In particular, this results in swit

rust: error: import `kernel`'s `LayoutError` instead of `core`'s

Import the internal (`kernel::alloc`) version of `LayoutError` instead
of the `core::alloc` one.

In particular, this results in switching the type in the existing
`From<LayoutError> for Error` implementation.

Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Jimmy Ostler <[email protected]>
Link: https://lore.kernel.org/r/fe58a02189e8804a9eabdd01cb1927d4c491d79c.1734674670.git.jtostler1@gmail.com
[ Reworded commit. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: str: replace unwraps with question mark operators

Simplify the error handling by replacing unwraps with the question
mark operator. Furthermore, unwraps can convey a wrong impression that
unwr

rust: str: replace unwraps with question mark operators

Simplify the error handling by replacing unwraps with the question
mark operator. Furthermore, unwraps can convey a wrong impression that
unwrapping is fine in general, thus this patch removes this unwrapping.

Suggested-by: Miguel Ojeda <[email protected]>
Link: https://lore.kernel.org/rust-for-linux/CANiq72nsK1D4NuQ1U7NqMWoYjXkqQSj4QuUEL98OmFbq022Z9A@mail.gmail.com/
Reviewed-by: Alice Ryhl <[email protected]>
Signed-off-by: Daniel Sedlak <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Slightly reworded commit. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

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 <[email protected]>
Suggested-by: Miguel Ojeda <[email protected]>
Link: https://lore.kernel.org/rust-for-linux/[email protected]/
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Tamir Duberstein <[email protected]>
Signed-off-by: Daniel Sedlak <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Fixed typo in SoB. Slightly reworded commit. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

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 <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Reworded title slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

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 <[email protected]>
Link: https://lore.kernel.org/rust-for-linux/CANiq72nsK1D4NuQ1U7NqMWoYjXkqQSj4QuUEL98OmFbq022Z9A@mail.gmail.com/
Signed-off-by: Daniel Sedlak <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Reworded commit slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: devres: remove action in `Devres::drop`

So far `DevresInner` is kept alive, even if `Devres` is dropped until
the devres callback is executed to avoid a WARN() when the action has
been release

rust: devres: remove action in `Devres::drop`

So far `DevresInner` is kept alive, even if `Devres` is dropped until
the devres callback is executed to avoid a WARN() when the action has
been released already.

With the introduction of devm_remove_action_nowarn() we can remove the
action in `Devres::drop`, handle the case where the action has been
released already and hence also free `DevresInner`.

Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/all/[email protected]/ [1]
Signed-off-by: Alice Ryhl <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Applied the change to the new miscdevice cases. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Applied the change to the new miscdevice cases. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

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 <[email protected]>
Closes: https://lore.kernel.org/rust-for-linux/[email protected]/
Signed-off-by: Danilo Krummrich <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

rust: pci: do not depend on CONFIG_PCI_MSI

The PCI abstractions do not actually depend on CONFIG_PCI_MSI; it also
breaks drivers that only depend on CONFIG_PCI, hence drop it.

While at it, move the

rust: pci: do not depend on CONFIG_PCI_MSI

The PCI abstractions do not actually depend on CONFIG_PCI_MSI; it also
breaks drivers that only depend on CONFIG_PCI, hence drop it.

While at it, move the module entry to its correct location.

Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Fixes: 1bd8b6b2c5d3 ("rust: pci: add basic PCI device / driver abstractions")
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

rust: block: fix use of BLK_MQ_F_SHOULD_MERGE

BLK_MQ_F_SHOULD_MERGE has was removed [1] and is now in effect by default.
So remove the flag from tag sets of Rust block device drivers.

Link: https:/

rust: block: fix use of BLK_MQ_F_SHOULD_MERGE

BLK_MQ_F_SHOULD_MERGE has was removed [1] and is now in effect by default.
So remove the flag from tag sets of Rust block device drivers.

Link: https://lore.kernel.org/r/[email protected] [1]
Fixes: 9377b95cda73 ("block: remove BLK_MQ_F_SHOULD_MERGE")
Signed-off-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>

show more ...

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) <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Tested-by: Dirk Behme <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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) <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Tested-by: Dirk Behme <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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) <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Tested-by: Dirk Behme <[email protected]>
Tested-by: Fabien Parent <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: Philipp Stanner <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Tested-by: Dirk Behme <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: FUJITA Tomonori <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Tested-by: Dirk Behme <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Tested-by: Dirk Behme <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Tested-by: Daniel Almeida <[email protected]>
Reviewed-by: Daniel Almeida <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Tested-by: Dirk Behme <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Co-developed-by: Danilo Krummrich <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Tested-by: Dirk Behme <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 <[email protected]>
Suggested-by: Alice Ryhl <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Tested-by: Dirk Behme <[email protected]>
Tested-by: Fabien Parent <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

rust: add rcu abstraction

Add a simple abstraction to guard critical code sections with an rcu
read lock.

Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: Wedson Almeida Filho <wedsona

rust: add rcu abstraction

Add a simple abstraction to guard critical code sections with an rcu
read lock.

Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Co-developed-by: Danilo Krummrich <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Tested-by: Dirk Behme <[email protected]>
Tested-by: Fabien Parent <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...