rust/kernel/auxiliary.rs | 11 +++-- rust/kernel/device_id.rs | 91 ++++++++++++++++++++++++---------- rust/kernel/net/phy.rs | 104 +++++++++++++++++++-------------------- rust/kernel/of.rs | 15 ++++-- rust/kernel/pci.rs | 11 +++-- 5 files changed, 138 insertions(+), 94 deletions(-)
Build PHY device tables by using module_device_table macro.
The PHY abstractions have been generating their own device tables
manually instead of using the module_device_table macro provided by
the device_id crate. However, the format of device tables occasionally
changes [1] [2], requiring updates to both the device_id crate and the custom
format used by the PHY abstractions, which is cumbersome to maintain.
[1]: https://lore.kernel.org/lkml/20241119235705.1576946-14-masahiroy@kernel.org/
[2]: https://lore.kernel.org/lkml/6e2f70b07a710e761eb68d089d96cee7b27bb2d5.1750511018.git.legion@kernel.org/
v3:
- Fix Safety comments and typo
v2: https://lore.kernel.org/lkml/20250701141252.600113-1-fujita.tomonori@gmail.com/
- Split off index-related parts of RawDeviceId into RawDeviceIdIndex
v1: https://lore.kernel.org/lkml/20250623060951.118564-1-fujita.tomonori@gmail.com/
FUJITA Tomonori (3):
rust: device_id: split out index support into a separate trait
rust: net::phy represent DeviceId as transparent wrapper over
mdio_device_id
rust: net::phy Change module_phy_driver macro to use
module_device_table macro
rust/kernel/auxiliary.rs | 11 +++--
rust/kernel/device_id.rs | 91 ++++++++++++++++++++++++----------
rust/kernel/net/phy.rs | 104 +++++++++++++++++++--------------------
rust/kernel/of.rs | 15 ++++--
rust/kernel/pci.rs | 11 +++--
5 files changed, 138 insertions(+), 94 deletions(-)
base-commit: 2009a2d5696944d85c34d75e691a6f3884e787c0
--
2.43.0
On Fri, 4 Jul 2025 13:10:00 +0900 FUJITA Tomonori wrote: > The PHY abstractions have been generating their own device tables > manually instead of using the module_device_table macro provided by > the device_id crate. However, the format of device tables occasionally > changes [1] [2], requiring updates to both the device_id crate and the custom > format used by the PHY abstractions, which is cumbersome to maintain. Does not apply to networking trees so I suspect someone else will take these: Acked-by: Jakub Kicinski <kuba@kernel.org>
On 7/8/25 2:53 AM, Jakub Kicinski wrote: > On Fri, 4 Jul 2025 13:10:00 +0900 FUJITA Tomonori wrote: >> The PHY abstractions have been generating their own device tables >> manually instead of using the module_device_table macro provided by >> the device_id crate. However, the format of device tables occasionally >> changes [1] [2], requiring updates to both the device_id crate and the custom >> format used by the PHY abstractions, which is cumbersome to maintain. > > Does not apply to networking trees so I suspect someone else will take > these: > > Acked-by: Jakub Kicinski <kuba@kernel.org> I gave an Acked-by: for patch 1, but can also take it through the driver-core tree. - Danilo
On Tue, Jul 8, 2025 at 2:53 AM Jakub Kicinski <kuba@kernel.org> wrote: > > Does not apply to networking trees so I suspect someone else will take > these: > > Acked-by: Jakub Kicinski <kuba@kernel.org> Thanks! Happy to take it through Rust tree if that is best. Greg, Rob/Saravana: Acked-by's for auxiliary and OF (in patch #1) appreciated, thanks! Cheers, Miguel
On 7/8/25 12:45 PM, Miguel Ojeda wrote: > On Tue, Jul 8, 2025 at 2:53 AM Jakub Kicinski <kuba@kernel.org> wrote: >> >> Does not apply to networking trees so I suspect someone else will take >> these: >> >> Acked-by: Jakub Kicinski <kuba@kernel.org> > > Thanks! Happy to take it through Rust tree if that is best. Ah, didn't get this one before I replied in [1]. I gave an ACK because I thought it's going through the networking tree, but I can also take it through driver-core. Taking it through the rust tree is fine for me too; just let me know. :) [1] https://lore.kernel.org/lkml/1b9754c7-b9ad-4b01-8476-3d8367a49635@kernel.org/
On Tue, 8 Jul 2025 12:45:20 +0200 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > On Tue, Jul 8, 2025 at 2:53 AM Jakub Kicinski <kuba@kernel.org> wrote: >> >> Does not apply to networking trees so I suspect someone else will take >> these: >> >> Acked-by: Jakub Kicinski <kuba@kernel.org> > > Thanks! Happy to take it through Rust tree if that is best. This is based on Rust tree. If I remember correctly, it can't be applied cleanly to other trees because of Tamir's patch in Rust tree. Thanks everyone!
On Tue Jul 8, 2025 at 12:59 PM CEST, FUJITA Tomonori wrote: > On Tue, 8 Jul 2025 12:45:20 +0200 > Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > >> On Tue, Jul 8, 2025 at 2:53 AM Jakub Kicinski <kuba@kernel.org> wrote: >>> >>> Does not apply to networking trees so I suspect someone else will take >>> these: >>> >>> Acked-by: Jakub Kicinski <kuba@kernel.org> >> >> Thanks! Happy to take it through Rust tree if that is best. > > This is based on Rust tree. If I remember correctly, it can't be > applied cleanly to other trees because of Tamir's patch in Rust tree. Had a brief look. There will be two trivial conflicts with the driver-core tree, which fixed up some of the safety comments you modify in this series as well. The other way around, there is one trivial conflict with Tamir patch in the rust tree fixing up an `as _` cast. So, either way works fine.
On Tue, Jul 8, 2025 at 2:48 PM Danilo Krummrich <dakr@kernel.org> wrote: > > Had a brief look. > > There will be two trivial conflicts with the driver-core tree, which fixed up > some of the safety comments you modify in this series as well. > > The other way around, there is one trivial conflict with Tamir patch in the rust > tree fixing up an `as _` cast. > > So, either way works fine. Thanks Danilo -- ditto. Even netdev could make sense as you said. Since it touched several subsystems and it is based on rust-next, I am happy to do so, but driver-core makes sense given that is the main change after all. So if I don't see you picking it, I will eventually do it. Cheers, Miguel
On Tue, Jul 08, 2025 at 08:47:13PM +0200, Miguel Ojeda wrote:
> Thanks Danilo -- ditto. Even netdev could make sense as you said.
>
> Since it touched several subsystems and it is based on rust-next, I am
> happy to do so, but driver-core makes sense given that is the main
> change after all.
>
> So if I don't see you picking it, I will eventually do it.
Checked again and the driver-core tree makes most sense, since we also need to
fix up the ACPI device ID code, which is queued up in driver-core-next.
I also caught a missing change in rust/kernel/driver.rs, which most likely
slipped through by not building with CONFIG_OF. :)
Here's the diff to fix up both, I already fixed it up on my end -- no need to
send a new version.
--
diff --git a/rust/kernel/acpi.rs b/rust/kernel/acpi.rs
index 2af4d4f92924..7ae317368b00 100644
--- a/rust/kernel/acpi.rs
+++ b/rust/kernel/acpi.rs
@@ -2,7 +2,11 @@
//! Advanced Configuration and Power Interface abstractions.
-use crate::{bindings, device_id::RawDeviceId, prelude::*};
+use crate::{
+ bindings,
+ device_id::{RawDeviceId, RawDeviceIdIndex},
+ prelude::*,
+};
/// IdTable type for ACPI drivers.
pub type IdTable<T> = &'static dyn kernel::device_id::IdTable<DeviceId, T>;
@@ -12,13 +16,14 @@
#[derive(Clone, Copy)]
pub struct DeviceId(bindings::acpi_device_id);
-// SAFETY:
-// * `DeviceId` is a `#[repr(transparent)` wrapper of `struct acpi_device_id` and does not add
-// additional invariants, so it's safe to transmute to `RawType`.
-// * `DRIVER_DATA_OFFSET` is the offset to the `data` field.
+// SAFETY: `DeviceId` is a `#[repr(transparent)]` wrapper of `acpi_device_id` and does not add
+// additional invariants, so it's safe to transmute to `RawType`.
unsafe impl RawDeviceId for DeviceId {
type RawType = bindings::acpi_device_id;
+}
+// SAFETY: `DRIVER_DATA_OFFSET` is the offset to the `driver_data` field.
+unsafe impl RawDeviceIdIndex for DeviceId {
const DRIVER_DATA_OFFSET: usize = core::mem::offset_of!(bindings::acpi_device_id, driver_data);
fn index(&self) -> usize {
diff --git a/rust/kernel/driver.rs b/rust/kernel/driver.rs
index f8dd7593e8dc..573d516b2f06 100644
--- a/rust/kernel/driver.rs
+++ b/rust/kernel/driver.rs
@@ -170,7 +170,7 @@ fn acpi_id_info(dev: &device::Device) -> Option<&'static Self::IdInfo> {
// and does not add additional invariants, so it's safe to transmute.
let id = unsafe { &*raw_id.cast::<acpi::DeviceId>() };
- Some(table.info(<acpi::DeviceId as crate::device_id::RawDeviceId>::index(id)))
+ Some(table.info(<acpi::DeviceId as crate::device_id::RawDeviceIdIndex>::index(id)))
}
}
}
@@ -204,7 +204,7 @@ fn of_id_info(dev: &device::Device) -> Option<&'static Self::IdInfo> {
// and does not add additional invariants, so it's safe to transmute.
let id = unsafe { &*raw_id.cast::<of::DeviceId>() };
- Some(table.info(<of::DeviceId as crate::device_id::RawDeviceId>::index(id)))
+ Some(table.info(<of::DeviceId as crate::device_id::RawDeviceIdIndex>::index(id)))
}
}
}
On Wed, 9 Jul 2025 00:51:24 +0200 Danilo Krummrich <dakr@kernel.org> wrote: >> Since it touched several subsystems and it is based on rust-next, I am >> happy to do so, but driver-core makes sense given that is the main >> change after all. >> >> So if I don't see you picking it, I will eventually do it. > > Checked again and the driver-core tree makes most sense, since we also need to > fix up the ACPI device ID code, which is queued up in driver-core-next. > > I also caught a missing change in rust/kernel/driver.rs, which most likely > slipped through by not building with CONFIG_OF. :) Oops, you are right. I mistakenly thought that CONFIG_OF was enabled because kernel/of.rs was being compiled. > Here's the diff to fix up both, I already fixed it up on my end -- no need to > send a new version. Thanks a lot!
On 7/9/25 4:08 AM, FUJITA Tomonori wrote: > On Wed, 9 Jul 2025 00:51:24 +0200 > Danilo Krummrich <dakr@kernel.org> wrote: >> Here's the diff to fix up both, I already fixed it up on my end -- no need to >> send a new version. > > Thanks a lot! Given the comments from Trevor, do you want me to wait for a respin, consider the few nits when applying, or apply as is? - Danilo
On Thu, 10 Jul 2025 22:01:56 +0200 Danilo Krummrich <dakr@kernel.org> wrote: > On 7/9/25 4:08 AM, FUJITA Tomonori wrote: >> On Wed, 9 Jul 2025 00:51:24 +0200 >> Danilo Krummrich <dakr@kernel.org> wrote: >>> Here's the diff to fix up both, I already fixed it up on my end -- no >>> need to >>> send a new version. >> Thanks a lot! > > Given the comments from Trevor, do you want me to wait for a respin, > consider > the few nits when applying, or apply as is? Thanks, I'll send v4 shortly.
© 2016 - 2025 Red Hat, Inc.