[PATCH] rust: acpi: add `acpi::DeviceId` abstraction

[PATCH] rust: acpi: add `acpi::DeviceId` abstraction

[Igor Korotin]

`acpi::DeviceId` is an abstraction around `struct acpi_device_id`.

This is used by subsequent patches, in particular the i2c driver
abstractions, to create ACPI device ID tables.

Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
---
 MAINTAINERS         |  1 +
 rust/kernel/acpi.rs | 63 +++++++++++++++++++++++++++++++++++++++++++++
 rust/kernel/lib.rs  |  1 +
 3 files changed, 65 insertions(+)
 create mode 100644 rust/kernel/acpi.rs

diff --git a/MAINTAINERS b/MAINTAINERS
index b659fb27ab63..5f8dfae08454 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -302,6 +302,7 @@ F:	include/linux/acpi.h
 F:	include/linux/fwnode.h
 F:	include/linux/fw_table.h
 F:	lib/fw_table.c
+F:	rust/kernel/acpi.rs
 F:	tools/power/acpi/
 
 ACPI APEI
diff --git a/rust/kernel/acpi.rs b/rust/kernel/acpi.rs
new file mode 100644
index 000000000000..bbd38910736c
--- /dev/null
+++ b/rust/kernel/acpi.rs
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Advanced Configuration and Power Interface abstractions.
+
+use crate::{bindings, device_id::RawDeviceId, prelude::*};
+
+/// IdTable type for ACPI drivers.
+pub type IdTable<T> = &'static dyn kernel::device_id::IdTable<DeviceId, T>;
+
+/// An ACPI device id.
+#[repr(transparent)]
+#[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.
+unsafe impl RawDeviceId for DeviceId {
+    type RawType = bindings::acpi_device_id;
+
+    const DRIVER_DATA_OFFSET: usize = core::mem::offset_of!(bindings::acpi_device_id, driver_data);
+
+    fn index(&self) -> usize {
+        self.0.driver_data as _
+    }
+}
+
+impl DeviceId {
+    const ACPI_ID_LEN: usize = 16;
+
+    /// Create a new device id from an ACPI 'id' string.
+    pub const fn new(id: &'static CStr) -> Self {
+        assert!(id.len() <= Self::ACPI_ID_LEN, "ID exceeds 16 bytes");
+        let src = id.as_bytes_with_nul();
+        // Replace with `bindings::acpi_device_id::default()` once stabilized for `const`.
+        // SAFETY: FFI type is valid to be zero-initialized.
+        let mut acpi: bindings::acpi_device_id = unsafe { core::mem::zeroed() };
+        // TODO: Use `clone_from_slice` once the corresponding types do match.
+        let mut i = 0;
+        while i < src.len() {
+            acpi.id[i] = src[i] as _;
+            i += 1;
+        }
+
+        Self(acpi)
+    }
+}
+
+/// Create an ACPI `IdTable` with an "alias" for modpost.
+#[macro_export]
+macro_rules! acpi_device_table {
+    ($table_name:ident, $module_table_name:ident, $id_info_type: ty, $table_data: expr) => {
+        const $table_name: $crate::device_id::IdArray<
+            $crate::acpi::DeviceId,
+            $id_info_type,
+            { $table_data.len() },
+        > = $crate::device_id::IdArray::new($table_data);
+
+        $crate::module_device_table!("acpi", $module_table_name, $table_name);
+    };
+}
+
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index 15c5f72976cd..05f1d3870bf7 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -78,6 +78,7 @@
 #[cfg(CONFIG_NET)]
 pub mod net;
 pub mod of;
+pub mod acpi;
 pub mod page;
 #[cfg(CONFIG_I2C)]
 pub mod i2c;
-- 
2.43.0

Re: [PATCH] rust: acpi: add `acpi::DeviceId` abstraction

[Greg KH]

On Fri, May 30, 2025 at 01:38:06PM +0100, Igor Korotin wrote:
> `acpi::DeviceId` is an abstraction around `struct acpi_device_id`.
> 
> This is used by subsequent patches, in particular the i2c driver
> abstractions, to create ACPI device ID tables.
> 
> Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
> ---
>  MAINTAINERS         |  1 +
>  rust/kernel/acpi.rs | 63 +++++++++++++++++++++++++++++++++++++++++++++
>  rust/kernel/lib.rs  |  1 +
>  3 files changed, 65 insertions(+)
>  create mode 100644 rust/kernel/acpi.rs

I'm not seeing any "subsequent patches" here.  Is this part of a patch
series that didn't all get sent out properly?

thanks,

greg k-h


> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b659fb27ab63..5f8dfae08454 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -302,6 +302,7 @@ F:	include/linux/acpi.h
>  F:	include/linux/fwnode.h
>  F:	include/linux/fw_table.h
>  F:	lib/fw_table.c
> +F:	rust/kernel/acpi.rs
>  F:	tools/power/acpi/
>  
>  ACPI APEI
> diff --git a/rust/kernel/acpi.rs b/rust/kernel/acpi.rs
> new file mode 100644
> index 000000000000..bbd38910736c
> --- /dev/null
> +++ b/rust/kernel/acpi.rs
> @@ -0,0 +1,63 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Advanced Configuration and Power Interface abstractions.
> +
> +use crate::{bindings, device_id::RawDeviceId, prelude::*};
> +
> +/// IdTable type for ACPI drivers.
> +pub type IdTable<T> = &'static dyn kernel::device_id::IdTable<DeviceId, T>;
> +
> +/// An ACPI device id.
> +#[repr(transparent)]
> +#[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.
> +unsafe impl RawDeviceId for DeviceId {
> +    type RawType = bindings::acpi_device_id;
> +
> +    const DRIVER_DATA_OFFSET: usize = core::mem::offset_of!(bindings::acpi_device_id, driver_data);
> +
> +    fn index(&self) -> usize {
> +        self.0.driver_data as _
> +    }
> +}
> +
> +impl DeviceId {
> +    const ACPI_ID_LEN: usize = 16;
> +
> +    /// Create a new device id from an ACPI 'id' string.
> +    pub const fn new(id: &'static CStr) -> Self {
> +        assert!(id.len() <= Self::ACPI_ID_LEN, "ID exceeds 16 bytes");
> +        let src = id.as_bytes_with_nul();
> +        // Replace with `bindings::acpi_device_id::default()` once stabilized for `const`.
> +        // SAFETY: FFI type is valid to be zero-initialized.
> +        let mut acpi: bindings::acpi_device_id = unsafe { core::mem::zeroed() };
> +        // TODO: Use `clone_from_slice` once the corresponding types do match.
> +        let mut i = 0;
> +        while i < src.len() {
> +            acpi.id[i] = src[i] as _;
> +            i += 1;
> +        }
> +
> +        Self(acpi)
> +    }
> +}
> +
> +/// Create an ACPI `IdTable` with an "alias" for modpost.
> +#[macro_export]
> +macro_rules! acpi_device_table {
> +    ($table_name:ident, $module_table_name:ident, $id_info_type: ty, $table_data: expr) => {
> +        const $table_name: $crate::device_id::IdArray<
> +            $crate::acpi::DeviceId,
> +            $id_info_type,
> +            { $table_data.len() },
> +        > = $crate::device_id::IdArray::new($table_data);
> +
> +        $crate::module_device_table!("acpi", $module_table_name, $table_name);
> +    };
> +}
> +
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index 15c5f72976cd..05f1d3870bf7 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -78,6 +78,7 @@
>  #[cfg(CONFIG_NET)]
>  pub mod net;
>  pub mod of;
> +pub mod acpi;

Aren't these supposed to be sorted?

thanks,

greg k-h

Re: [PATCH] rust: acpi: add `acpi::DeviceId` abstraction

[Danilo Krummrich]

On Fri, May 30, 2025 at 01:38:06PM +0100, Igor Korotin wrote:
> `acpi::DeviceId` is an abstraction around `struct acpi_device_id`.
> 
> This is used by subsequent patches, in particular the i2c driver
> abstractions, to create ACPI device ID tables.
> 
> Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>

As Greg mentioned it would be nice to see the subsequent patches.

Also, for this to be useful you need to implement the generic glue code in
rust/kernel/driver.rs in the generic Adapter trait.

You also may want to connect it to the platform bus abstraction, just like the
OF bindings are, since I assume that's the bus you care about?

> ---
>  MAINTAINERS         |  1 +
>  rust/kernel/acpi.rs | 63 +++++++++++++++++++++++++++++++++++++++++++++
>  rust/kernel/lib.rs  |  1 +
>  3 files changed, 65 insertions(+)
>  create mode 100644 rust/kernel/acpi.rs
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b659fb27ab63..5f8dfae08454 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -302,6 +302,7 @@ F:	include/linux/acpi.h
>  F:	include/linux/fwnode.h
>  F:	include/linux/fw_table.h
>  F:	lib/fw_table.c
> +F:	rust/kernel/acpi.rs
>  F:	tools/power/acpi/
>  
>  ACPI APEI
> diff --git a/rust/kernel/acpi.rs b/rust/kernel/acpi.rs
> new file mode 100644
> index 000000000000..bbd38910736c
> --- /dev/null
> +++ b/rust/kernel/acpi.rs
> @@ -0,0 +1,63 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Advanced Configuration and Power Interface abstractions.
> +
> +use crate::{bindings, device_id::RawDeviceId, prelude::*};
> +
> +/// IdTable type for ACPI drivers.
> +pub type IdTable<T> = &'static dyn kernel::device_id::IdTable<DeviceId, T>;
> +
> +/// An ACPI device id.
> +#[repr(transparent)]
> +#[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.
> +unsafe impl RawDeviceId for DeviceId {
> +    type RawType = bindings::acpi_device_id;
> +
> +    const DRIVER_DATA_OFFSET: usize = core::mem::offset_of!(bindings::acpi_device_id, driver_data);
> +
> +    fn index(&self) -> usize {
> +        self.0.driver_data as _
> +    }
> +}
> +
> +impl DeviceId {
> +    const ACPI_ID_LEN: usize = 16;
> +
> +    /// Create a new device id from an ACPI 'id' string.
> +    pub const fn new(id: &'static CStr) -> Self {
> +        assert!(id.len() <= Self::ACPI_ID_LEN, "ID exceeds 16 bytes");
> +        let src = id.as_bytes_with_nul();
> +        // Replace with `bindings::acpi_device_id::default()` once stabilized for `const`.
> +        // SAFETY: FFI type is valid to be zero-initialized.
> +        let mut acpi: bindings::acpi_device_id = unsafe { core::mem::zeroed() };

The patch did not land yet, but for this there's the following improvement
upcoming:

https://lore.kernel.org/rust-for-linux/20250523145125.523275-13-lossin@kernel.org/

> +        // TODO: Use `clone_from_slice` once the corresponding types do match.

clone_from_slice() can't be used from const context, this comment is wrong in
of.rs (where you probably copied it from).

> +        let mut i = 0;
> +        while i < src.len() {
> +            acpi.id[i] = src[i] as _;

You can drop this cast, it shouldn't be needed anymore.

> +            i += 1;
> +        }
> +
> +        Self(acpi)
> +    }
> +}
> +
> +/// Create an ACPI `IdTable` with an "alias" for modpost.
> +#[macro_export]
> +macro_rules! acpi_device_table {
> +    ($table_name:ident, $module_table_name:ident, $id_info_type: ty, $table_data: expr) => {
> +        const $table_name: $crate::device_id::IdArray<
> +            $crate::acpi::DeviceId,
> +            $id_info_type,
> +            { $table_data.len() },
> +        > = $crate::device_id::IdArray::new($table_data);
> +
> +        $crate::module_device_table!("acpi", $module_table_name, $table_name);
> +    };
> +}
> +
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index 15c5f72976cd..05f1d3870bf7 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -78,6 +78,7 @@
>  #[cfg(CONFIG_NET)]
>  pub mod net;
>  pub mod of;
> +pub mod acpi;

As mentioned by Greg, please keep this ordered.

Re: [PATCH] rust: acpi: add `acpi::DeviceId` abstraction

[Igor Korotin]

On Fri, May 30, 2025 at 3:43 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Fri, May 30, 2025 at 01:38:06PM +0100, Igor Korotin wrote:
> > `acpi::DeviceId` is an abstraction around `struct acpi_device_id`.
> >
> > This is used by subsequent patches, in particular the i2c driver
> > abstractions, to create ACPI device ID tables.
> >
> > Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
>
> As Greg mentioned it would be nice to see the subsequent patches.

Ok. There's a little misunderstanding from my side. I'm in the
progress of implementation
of I2C driver abstractions. I2C drivers can use either "of" or "acpi".
The idea was to push this
change first, because:
 - It's quite standalone one.
 - I'm not sure how much time it will take me to finalize I2C drivers
abstractions.

If it is not appropriate way of commits, I'll then keep it until all is done.

Noted all the remarks. Will sort them in the next drop.

Thanks for the review.

Thanks
Igor

Re: [PATCH] rust: acpi: add `acpi::DeviceId` abstraction

[Greg KH]

On Fri, May 30, 2025 at 05:11:29PM +0100, Igor Korotin wrote:
> On Fri, May 30, 2025 at 3:43 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > On Fri, May 30, 2025 at 01:38:06PM +0100, Igor Korotin wrote:
> > > `acpi::DeviceId` is an abstraction around `struct acpi_device_id`.
> > >
> > > This is used by subsequent patches, in particular the i2c driver
> > > abstractions, to create ACPI device ID tables.
> > >
> > > Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
> >
> > As Greg mentioned it would be nice to see the subsequent patches.
> 
> Ok. There's a little misunderstanding from my side. I'm in the
> progress of implementation
> of I2C driver abstractions. I2C drivers can use either "of" or "acpi".
> The idea was to push this
> change first, because:
>  - It's quite standalone one.
>  - I'm not sure how much time it will take me to finalize I2C drivers
> abstractions.

If you don't need it now, then there's no rush to get it merged now :)

> If it is not appropriate way of commits, I'll then keep it until all is done.

We would like to see it be used first, to ensure that the code is
actually correct.

thanks,

greg k-h

Re: [PATCH] rust: acpi: add `acpi::DeviceId` abstraction

[Danilo Krummrich]

On Sat, May 31, 2025 at 07:49:46AM +0200, Greg KH wrote:
> On Fri, May 30, 2025 at 05:11:29PM +0100, Igor Korotin wrote:
> > On Fri, May 30, 2025 at 3:43 PM Danilo Krummrich <dakr@kernel.org> wrote:
> > >
> > > On Fri, May 30, 2025 at 01:38:06PM +0100, Igor Korotin wrote:
> > > > `acpi::DeviceId` is an abstraction around `struct acpi_device_id`.
> > > >
> > > > This is used by subsequent patches, in particular the i2c driver
> > > > abstractions, to create ACPI device ID tables.
> > > >
> > > > Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
> > >
> > > As Greg mentioned it would be nice to see the subsequent patches.
> > 
> > Ok. There's a little misunderstanding from my side. I'm in the
> > progress of implementation
> > of I2C driver abstractions. I2C drivers can use either "of" or "acpi".
> > The idea was to push this
> > change first, because:
> >  - It's quite standalone one.
> >  - I'm not sure how much time it will take me to finalize I2C drivers
> > abstractions.
> 
> If you don't need it now, then there's no rush to get it merged now :)
> 
> > If it is not appropriate way of commits, I'll then keep it until all is done.
> 
> We would like to see it be used first, to ensure that the code is
> actually correct.

Alternatively, if you want to upstream this dependency already you can send the
following patches:

  - this acpi::DeviceId abstraction
  - the glue code for the generic adapter trait in rust/kernel/driver.rs
  - use this glue code in the platform abstraction
  - add acpi support to the platform sample driver

This way we can already validate that the code works correctly. All this is
required anyways if the I2C device you write a driver for is on the platform
bus.

Re: [PATCH] rust: acpi: add `acpi::DeviceId` abstraction

[Igor Korotin]

> Alternatively, if you want to upstream this dependency already you can send the
> following patches:
>
>   - this acpi::DeviceId abstraction
>   - the glue code for the generic adapter trait in rust/kernel/driver.rs
>   - use this glue code in the platform abstraction
>   - add acpi support to the platform sample driver
>
> This way we can already validate that the code works correctly. All this is
> required anyways if the I2C device you write a driver for is on the platform
> bus.

A few questions if I may:
1. I committed to 4 different files: `acpi.rs`, `driver.rs`,
`platform.rs`, platform rust sample driver.
Should I commit all of this as one commit or split each part to a
separate commit and send it as a patch sequence?
2. From author's point of view, as Danilo noticed, `acpi table`
abstraction code is in general just copy-paste from `of table`
abstraction code. How should I explicitly mark that fact?

Thanks
Igor

Re: [PATCH] rust: acpi: add `acpi::DeviceId` abstraction

[Danilo Krummrich]

On Tue, Jun 03, 2025 at 01:55:47PM +0100, Igor Korotin wrote:
> > Alternatively, if you want to upstream this dependency already you can send the
> > following patches:
> >
> >   - this acpi::DeviceId abstraction
> >   - the glue code for the generic adapter trait in rust/kernel/driver.rs
> >   - use this glue code in the platform abstraction
> >   - add acpi support to the platform sample driver
> >
> > This way we can already validate that the code works correctly. All this is
> > required anyways if the I2C device you write a driver for is on the platform
> > bus.
> 
> A few questions if I may:
> 1. I committed to 4 different files: `acpi.rs`, `driver.rs`,
> `platform.rs`, platform rust sample driver.
> Should I commit all of this as one commit or split each part to a
> separate commit and send it as a patch sequence?

Every entry of my list above should be a separate commit. It might happen that
writing the glue code for the generic adapter trait in rust/kernel/driver.rs
breaks the build in the platform abstraction, then you have to fix it up in the
same commit, i.e. we never break the build. Please also see [1].

> 2. From author's point of view, as Danilo noticed, `acpi table`
> abstraction code is in general just copy-paste from `of table`
> abstraction code. How should I explicitly mark that fact?

You don't need to do anything specific here. You authored the commit, even
though it's based on existing code.

If you want you can add a note in the commit message that your case is based on
the OF table abstraction. But AFAIC, you don't have to.

[1] https://docs.kernel.org/process/submitting-patches.html#separate-your-changes