|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6 |
|
| #
dbd5058b |
| 08-Mar-2025 |
Benno Lossin <[email protected]> |
rust: make pin-init its own crate
Rename relative paths inside of the crate to still refer to the same items, also rename paths inside of the kernel crate and adjust the build system to build the cr
rust: make pin-init its own crate
Rename relative paths inside of the crate to still refer to the same items, also rename paths inside of the kernel crate and adjust the build system to build the crate.
[ Remove the `expect` (and thus the `lint_reasons` feature) since the tree now uses `quote!` from `rust/macros/export.rs`. Remove the `TokenStream` import removal, since it is now used as well.
In addition, temporarily (i.e. just for this commit) use an `--extern force:alloc` to prevent an unknown `new_uninit` error in the `rustdoc` target. For context, please see a similar case in:
https://lore.kernel.org/lkml/[email protected]/
And adjusted the message above. - Miguel ]
Signed-off-by: Benno Lossin <[email protected]> Reviewed-by: Fiona Behrens <[email protected]> Tested-by: Andreas Hindborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
|
Revision tags: v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6 |
|
| #
e1a51c2b |
| 03-Jan-2025 |
Danilo Krummrich <[email protected]> |
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 ...
|
|
Revision tags: v6.13-rc5, v6.13-rc4 |
|
| #
7a718a1f |
| 19-Dec-2024 |
Danilo Krummrich <[email protected]> |
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 ...
|
| #
ea7e1828 |
| 19-Dec-2024 |
Danilo Krummrich <[email protected]> |
rust: implement generic driver registration
Implement the generic `Registration` type and the `RegistrationOps` trait.
The `Registration` structure is the common type that represents a driver regis
rust: implement generic driver registration
Implement the generic `Registration` type and the `RegistrationOps` trait.
The `Registration` structure is the common type that represents a driver registration and is typically bound to the lifetime of a module. However, it doesn't implement actual calls to the kernel's driver core to register drivers itself.
Instead the `RegistrationOps` trait is provided to subsystems, which have to implement `RegistrationOps::register` and `RegistrationOps::unregister`. Subsystems have to provide an implementation for both of those methods where the subsystem specific variants to register / unregister a driver have to implemented.
For instance, the PCI subsystem would call __pci_register_driver() from `RegistrationOps::register` and pci_unregister_driver() from `DrvierOps::unregister`.
Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[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 ...
|