[PATCH v3 0/3] Support exporting SoC info from Rust

[PATCH v3 0/3] Support exporting SoC info from Rust

[Matthew Maurer]

This is a fairly straightforward binding of `soc_device_register` and
`soc_device_unregister` which allows a driver to export basic info about
a SoC.

The last patch is a sample demonstrating usage, and can be dropped
without issue.

Signed-off-by: Matthew Maurer <mmaurer@google.com>
---
Changes in v3:
- Renamed `Registration::register` to `Registration::new`
- Inlined registration function and avoided `this` usage, per Danilo's
  suggestion.
- Link to v2: https://lore.kernel.org/r/20251216-soc-bindings-v2-0-1fb394cc921a@google.com

Changes in v2:
- Switch to new import style
- Increased documentation. Some of this had to be gathered by looking at
  what is done in practice at the moment, as documentation was absent or
  did not match code.
- Remove `Device` intermediate abstraction
- Removed unnecessary pinning of `BuiltDeviceAttributes` - it only needs
  to be pinned for registration, not to exist.
- Aesthetic renames (`Attributes` pluralization, dropping `Device`,
  etc.)
- Use more representative values for attributes in the sample driver
- Fix swap of example values in the documentation for machine vs family
- Link to v1: https://lore.kernel.org/r/20251212-soc-bindings-v1-0-db51044ce805@google.com

---
Matthew Maurer (3):
      rust: Add soc_device support
      docs: ABI: sysfs-devices-soc: Fix swapped sample values
      rust: Add SoC Driver Sample

 Documentation/ABI/testing/sysfs-devices-soc |   4 +-
 MAINTAINERS                                 |   2 +
 rust/bindings/bindings_helper.h             |   1 +
 rust/kernel/lib.rs                          |   2 +
 rust/kernel/soc.rs                          | 135 ++++++++++++++++++++++++++++
 samples/rust/Kconfig                        |  11 +++
 samples/rust/Makefile                       |   1 +
 samples/rust/rust_soc.rs                    |  82 +++++++++++++++++
 8 files changed, 236 insertions(+), 2 deletions(-)
---
base-commit: 008d3547aae5bc86fac3eda317489169c3fda112
change-id: 20251029-soc-bindings-9b0731bcdbed

Best regards,
-- 
Matthew Maurer <mmaurer@google.com>

[PATCH v3 1/3] rust: Add soc_device support

[Matthew Maurer]

Allow SoC drivers in Rust to present metadata about their devices to
userspace through /sys/devices/socX and other drivers to identify their
properties through `soc_device_match`.

Signed-off-by: Matthew Maurer <mmaurer@google.com>
---
 MAINTAINERS                     |   1 +
 rust/bindings/bindings_helper.h |   1 +
 rust/kernel/lib.rs              |   2 +
 rust/kernel/soc.rs              | 135 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 139 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c5a7cda26c600e49c7ab0d547306d3281333f672..4ff01fb0f1bda27002094113c0bf9d074d28fdb6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7700,6 +7700,7 @@ F:	rust/kernel/devres.rs
 F:	rust/kernel/driver.rs
 F:	rust/kernel/faux.rs
 F:	rust/kernel/platform.rs
+F:	rust/kernel/soc.rs
 F:	samples/rust/rust_debugfs.rs
 F:	samples/rust/rust_debugfs_scoped.rs
 F:	samples/rust/rust_driver_platform.rs
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index a067038b4b422b4256f4a2b75fe644d47e6e82c8..9fdf76ca630e00715503e2a3a809bedc895697fd 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -80,6 +80,7 @@
 #include <linux/sched.h>
 #include <linux/security.h>
 #include <linux/slab.h>
+#include <linux/sys_soc.h>
 #include <linux/task_work.h>
 #include <linux/tracepoint.h>
 #include <linux/usb.h>
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index f812cf12004286962985a068665443dc22c389a2..6d637e2fed1b605e2dfc2e7b2247179439a90ba9 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -138,6 +138,8 @@
 pub mod seq_file;
 pub mod sizes;
 pub mod slice;
+#[cfg(CONFIG_SOC_BUS)]
+pub mod soc;
 mod static_assert;
 #[doc(hidden)]
 pub mod std_vendor;
diff --git a/rust/kernel/soc.rs b/rust/kernel/soc.rs
new file mode 100644
index 0000000000000000000000000000000000000000..0d6a36c83cb67ef20dc1e3d3995752f36e25ac9f
--- /dev/null
+++ b/rust/kernel/soc.rs
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+
+// Copyright (C) 2025 Google LLC.
+
+//! SoC Driver Abstraction.
+//!
+//! C header: [`include/linux/sys_soc.h`](srctree/include/linux/sys_soc.h)
+
+use crate::{
+    bindings,
+    error,
+    prelude::*,
+    str::CString,
+    types::Opaque, //
+};
+use core::ptr::NonNull;
+
+/// Attributes for a SoC device.
+///
+/// These are both exported to userspace under /sys/devices/socX and provided to other drivers to
+/// match against via `soc_device_match` (not yet available in Rust) to enable quirks or
+/// device-specific support where necessary.
+///
+/// All fields are freeform - they have no specific formatting, just defined meanings.
+/// For example, the [`machine`](`Attributes::machine`) field could be "DB8500" or
+/// "Qualcomm Technologies, Inc. SM8560 HDK", but regardless it should identify a board or product.
+pub struct Attributes {
+    /// Should generally be a board ID or product ID. Examples
+    /// include DB8500 (ST-Ericsson) or "Qualcomm Technologies, inc. SM8560 HDK".
+    ///
+    /// If this field is not populated, the SoC infrastructure will try to populate it from
+    /// `/model` in the device tree.
+    pub machine: Option<CString>,
+    /// The broader class this SoC belongs to. Examples include ux500
+    /// (for DB8500) or Snapdragon (for SM8650).
+    ///
+    /// On chips with ARM firmware supporting SMCCC v1.2+, this may be a JEDEC JEP106 manufacturer
+    /// identification.
+    pub family: Option<CString>,
+    /// The manufacturing revision of the part. Frequently this is MAJOR.MINOR, but not always.
+    pub revision: Option<CString>,
+    /// Serial Number - uniquely identifies a specific SoC. If present, should be unique (buying a
+    /// replacement part should change it if present). This field cannot be matched on and is
+    /// solely present to export through /sys.
+    pub serial_number: Option<CString>,
+    /// SoC ID - identifies a specific SoC kind in question, sometimes more specifically than
+    /// `machine` if the same SoC is used in multiple products. Some devices use this to specify a
+    /// SoC name, e.g. "I.MX??", and others just print an ID number (e.g. Tegra and Qualcomm).
+    ///
+    /// On chips with ARM firmware supporting SMCCC v1.2+, this may be a JEDEC JEP106 manufacturer
+    /// identification (the family value) followed by a colon and then a 4-digit ID value.
+    pub soc_id: Option<CString>,
+}
+
+struct BuiltAttributes {
+    // While `inner` has pointers to `_backing`, it is to the interior of the `CStrings`, not
+    // `backing` itself, so it does not need to be pinned.
+    _backing: Attributes,
+    // `Opaque` makes us `!Unpin`, as the registration holds a pointer to `inner` when used.
+    inner: Opaque<bindings::soc_device_attribute>,
+}
+
+fn cstring_to_c(mcs: &Option<CString>) -> *const kernel::ffi::c_char {
+    mcs.as_ref()
+        .map(|cs| cs.as_char_ptr())
+        .unwrap_or(core::ptr::null())
+}
+
+impl BuiltAttributes {
+    fn as_mut_ptr(&self) -> *mut bindings::soc_device_attribute {
+        self.inner.get()
+    }
+}
+
+impl Attributes {
+    fn build(self) -> BuiltAttributes {
+        BuiltAttributes {
+            inner: Opaque::new(bindings::soc_device_attribute {
+                machine: cstring_to_c(&self.machine),
+                family: cstring_to_c(&self.family),
+                revision: cstring_to_c(&self.revision),
+                serial_number: cstring_to_c(&self.serial_number),
+                soc_id: cstring_to_c(&self.soc_id),
+                data: core::ptr::null(),
+                custom_attr_group: core::ptr::null(),
+            }),
+            _backing: self,
+        }
+    }
+}
+
+#[pin_data(PinnedDrop)]
+/// Registration handle for your soc_dev. If you let it go out of scope, your soc_dev will be
+/// unregistered.
+pub struct Registration {
+    #[pin]
+    attr: BuiltAttributes,
+    soc_dev: NonNull<bindings::soc_device>,
+}
+
+// SAFETY: We provide no operations through `&Registration`.
+unsafe impl Sync for Registration {}
+
+// SAFETY: All pointers are normal allocations, not thread-specific.
+unsafe impl Send for Registration {}
+
+#[pinned_drop]
+impl PinnedDrop for Registration {
+    fn drop(self: Pin<&mut Self>) {
+        // SAFETY: Device always contains a live pointer to a soc_device that can be unregistered
+        unsafe { bindings::soc_device_unregister(self.soc_dev.as_ptr()) }
+    }
+}
+
+impl Registration {
+    /// Register a new SoC device
+    pub fn new(attr: Attributes) -> impl PinInit<Self, Error> {
+        try_pin_init!(Self {
+            attr: attr.build(),
+            soc_dev: {
+                // SAFETY:
+                // * The struct provided through attr is backed by pinned data next to it,
+                //   so as long as attr lives, the strings pointed to by the struct will too.
+                // * `attr` is pinned, so the pinned data won't move.
+                // * If it returns a device, and so others may try to read this data, by
+                //   caller invariant, `attr` won't be released until the device is.
+                let raw_soc = error::from_err_ptr(unsafe {
+                    bindings::soc_device_register(attr.as_mut_ptr())
+                })?;
+
+                NonNull::new(raw_soc).ok_or(EINVAL)?
+            },
+        }? Error)
+    }
+}

-- 
2.52.0.305.g3fc767764a-goog

Re: [PATCH v3 1/3] rust: Add soc_device support

[Alexandre Courbot]

On Wed Dec 17, 2025 at 4:24 AM JST, Matthew Maurer wrote:
> Allow SoC drivers in Rust to present metadata about their devices to
> userspace through /sys/devices/socX and other drivers to identify their
> properties through `soc_device_match`.
>
> Signed-off-by: Matthew Maurer <mmaurer@google.com>
> ---
>  MAINTAINERS                     |   1 +
>  rust/bindings/bindings_helper.h |   1 +
>  rust/kernel/lib.rs              |   2 +
>  rust/kernel/soc.rs              | 135 ++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 139 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c5a7cda26c600e49c7ab0d547306d3281333f672..4ff01fb0f1bda27002094113c0bf9d074d28fdb6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7700,6 +7700,7 @@ F:	rust/kernel/devres.rs
>  F:	rust/kernel/driver.rs
>  F:	rust/kernel/faux.rs
>  F:	rust/kernel/platform.rs
> +F:	rust/kernel/soc.rs
>  F:	samples/rust/rust_debugfs.rs
>  F:	samples/rust/rust_debugfs_scoped.rs
>  F:	samples/rust/rust_driver_platform.rs
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index a067038b4b422b4256f4a2b75fe644d47e6e82c8..9fdf76ca630e00715503e2a3a809bedc895697fd 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -80,6 +80,7 @@
>  #include <linux/sched.h>
>  #include <linux/security.h>
>  #include <linux/slab.h>
> +#include <linux/sys_soc.h>
>  #include <linux/task_work.h>
>  #include <linux/tracepoint.h>
>  #include <linux/usb.h>
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index f812cf12004286962985a068665443dc22c389a2..6d637e2fed1b605e2dfc2e7b2247179439a90ba9 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -138,6 +138,8 @@
>  pub mod seq_file;
>  pub mod sizes;
>  pub mod slice;
> +#[cfg(CONFIG_SOC_BUS)]
> +pub mod soc;
>  mod static_assert;
>  #[doc(hidden)]
>  pub mod std_vendor;
> diff --git a/rust/kernel/soc.rs b/rust/kernel/soc.rs
> new file mode 100644
> index 0000000000000000000000000000000000000000..0d6a36c83cb67ef20dc1e3d3995752f36e25ac9f
> --- /dev/null
> +++ b/rust/kernel/soc.rs
> @@ -0,0 +1,135 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +// Copyright (C) 2025 Google LLC.
> +
> +//! SoC Driver Abstraction.
> +//!
> +//! C header: [`include/linux/sys_soc.h`](srctree/include/linux/sys_soc.h)
> +
> +use crate::{
> +    bindings,
> +    error,
> +    prelude::*,
> +    str::CString,
> +    types::Opaque, //
> +};
> +use core::ptr::NonNull;
> +
> +/// Attributes for a SoC device.
> +///
> +/// These are both exported to userspace under /sys/devices/socX and provided to other drivers to
> +/// match against via `soc_device_match` (not yet available in Rust) to enable quirks or
> +/// device-specific support where necessary.
> +///
> +/// All fields are freeform - they have no specific formatting, just defined meanings.
> +/// For example, the [`machine`](`Attributes::machine`) field could be "DB8500" or
> +/// "Qualcomm Technologies, Inc. SM8560 HDK", but regardless it should identify a board or product.
> +pub struct Attributes {
> +    /// Should generally be a board ID or product ID. Examples
> +    /// include DB8500 (ST-Ericsson) or "Qualcomm Technologies, inc. SM8560 HDK".
> +    ///
> +    /// If this field is not populated, the SoC infrastructure will try to populate it from
> +    /// `/model` in the device tree.
> +    pub machine: Option<CString>,
> +    /// The broader class this SoC belongs to. Examples include ux500
> +    /// (for DB8500) or Snapdragon (for SM8650).

Formatting of the comments seems a bit off (also appears in other
places, please reapply formatting globally to be sure).

> +    ///
> +    /// On chips with ARM firmware supporting SMCCC v1.2+, this may be a JEDEC JEP106 manufacturer
> +    /// identification.
> +    pub family: Option<CString>,
> +    /// The manufacturing revision of the part. Frequently this is MAJOR.MINOR, but not always.
> +    pub revision: Option<CString>,
> +    /// Serial Number - uniquely identifies a specific SoC. If present, should be unique (buying a
> +    /// replacement part should change it if present). This field cannot be matched on and is
> +    /// solely present to export through /sys.
> +    pub serial_number: Option<CString>,
> +    /// SoC ID - identifies a specific SoC kind in question, sometimes more specifically than
> +    /// `machine` if the same SoC is used in multiple products. Some devices use this to specify a
> +    /// SoC name, e.g. "I.MX??", and others just print an ID number (e.g. Tegra and Qualcomm).
> +    ///
> +    /// On chips with ARM firmware supporting SMCCC v1.2+, this may be a JEDEC JEP106 manufacturer
> +    /// identification (the family value) followed by a colon and then a 4-digit ID value.
> +    pub soc_id: Option<CString>,
> +}
> +
> +struct BuiltAttributes {

Even though this struct is private, some short documentation would be
helpful - actually the explanation about the relationship between
`_backing` and `inner` belongs here imho instead of in the member's
documentation.

Re: [PATCH v3 1/3] rust: Add soc_device support

[Matthew Maurer]

On Tue, Dec 16, 2025 at 6:31 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> On Wed Dec 17, 2025 at 4:24 AM JST, Matthew Maurer wrote:
> > Allow SoC drivers in Rust to present metadata about their devices to
> > userspace through /sys/devices/socX and other drivers to identify their
> > properties through `soc_device_match`.
> >
> > Signed-off-by: Matthew Maurer <mmaurer@google.com>
> > ---
> >  MAINTAINERS                     |   1 +
> >  rust/bindings/bindings_helper.h |   1 +
> >  rust/kernel/lib.rs              |   2 +
> >  rust/kernel/soc.rs              | 135 ++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 139 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index c5a7cda26c600e49c7ab0d547306d3281333f672..4ff01fb0f1bda27002094113c0bf9d074d28fdb6 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -7700,6 +7700,7 @@ F:      rust/kernel/devres.rs
> >  F:   rust/kernel/driver.rs
> >  F:   rust/kernel/faux.rs
> >  F:   rust/kernel/platform.rs
> > +F:   rust/kernel/soc.rs
> >  F:   samples/rust/rust_debugfs.rs
> >  F:   samples/rust/rust_debugfs_scoped.rs
> >  F:   samples/rust/rust_driver_platform.rs
> > diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> > index a067038b4b422b4256f4a2b75fe644d47e6e82c8..9fdf76ca630e00715503e2a3a809bedc895697fd 100644
> > --- a/rust/bindings/bindings_helper.h
> > +++ b/rust/bindings/bindings_helper.h
> > @@ -80,6 +80,7 @@
> >  #include <linux/sched.h>
> >  #include <linux/security.h>
> >  #include <linux/slab.h>
> > +#include <linux/sys_soc.h>
> >  #include <linux/task_work.h>
> >  #include <linux/tracepoint.h>
> >  #include <linux/usb.h>
> > diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> > index f812cf12004286962985a068665443dc22c389a2..6d637e2fed1b605e2dfc2e7b2247179439a90ba9 100644
> > --- a/rust/kernel/lib.rs
> > +++ b/rust/kernel/lib.rs
> > @@ -138,6 +138,8 @@
> >  pub mod seq_file;
> >  pub mod sizes;
> >  pub mod slice;
> > +#[cfg(CONFIG_SOC_BUS)]
> > +pub mod soc;
> >  mod static_assert;
> >  #[doc(hidden)]
> >  pub mod std_vendor;
> > diff --git a/rust/kernel/soc.rs b/rust/kernel/soc.rs
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..0d6a36c83cb67ef20dc1e3d3995752f36e25ac9f
> > --- /dev/null
> > +++ b/rust/kernel/soc.rs
> > @@ -0,0 +1,135 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +// Copyright (C) 2025 Google LLC.
> > +
> > +//! SoC Driver Abstraction.
> > +//!
> > +//! C header: [`include/linux/sys_soc.h`](srctree/include/linux/sys_soc.h)
> > +
> > +use crate::{
> > +    bindings,
> > +    error,
> > +    prelude::*,
> > +    str::CString,
> > +    types::Opaque, //
> > +};
> > +use core::ptr::NonNull;
> > +
> > +/// Attributes for a SoC device.
> > +///
> > +/// These are both exported to userspace under /sys/devices/socX and provided to other drivers to
> > +/// match against via `soc_device_match` (not yet available in Rust) to enable quirks or
> > +/// device-specific support where necessary.
> > +///
> > +/// All fields are freeform - they have no specific formatting, just defined meanings.
> > +/// For example, the [`machine`](`Attributes::machine`) field could be "DB8500" or
> > +/// "Qualcomm Technologies, Inc. SM8560 HDK", but regardless it should identify a board or product.
> > +pub struct Attributes {
> > +    /// Should generally be a board ID or product ID. Examples
> > +    /// include DB8500 (ST-Ericsson) or "Qualcomm Technologies, inc. SM8560 HDK".
> > +    ///
> > +    /// If this field is not populated, the SoC infrastructure will try to populate it from
> > +    /// `/model` in the device tree.
> > +    pub machine: Option<CString>,
> > +    /// The broader class this SoC belongs to. Examples include ux500
> > +    /// (for DB8500) or Snapdragon (for SM8650).
>
> Formatting of the comments seems a bit off (also appears in other
> places, please reapply formatting globally to be sure).

I have just re-run the `rustfmt` target on this commit, and see no
changes. Is there something specific that you think is off?

>
> > +    ///
> > +    /// On chips with ARM firmware supporting SMCCC v1.2+, this may be a JEDEC JEP106 manufacturer
> > +    /// identification.
> > +    pub family: Option<CString>,
> > +    /// The manufacturing revision of the part. Frequently this is MAJOR.MINOR, but not always.
> > +    pub revision: Option<CString>,
> > +    /// Serial Number - uniquely identifies a specific SoC. If present, should be unique (buying a
> > +    /// replacement part should change it if present). This field cannot be matched on and is
> > +    /// solely present to export through /sys.
> > +    pub serial_number: Option<CString>,
> > +    /// SoC ID - identifies a specific SoC kind in question, sometimes more specifically than
> > +    /// `machine` if the same SoC is used in multiple products. Some devices use this to specify a
> > +    /// SoC name, e.g. "I.MX??", and others just print an ID number (e.g. Tegra and Qualcomm).
> > +    ///
> > +    /// On chips with ARM firmware supporting SMCCC v1.2+, this may be a JEDEC JEP106 manufacturer
> > +    /// identification (the family value) followed by a colon and then a 4-digit ID value.
> > +    pub soc_id: Option<CString>,
> > +}
> > +
> > +struct BuiltAttributes {
>
> Even though this struct is private, some short documentation would be
> helpful - actually the explanation about the relationship between
> `_backing` and `inner` belongs here imho instead of in the member's
> documentation.

Re: [PATCH v3 1/3] rust: Add soc_device support

[Matthew Maurer]

On Fri, Dec 26, 2025 at 11:26 AM Matthew Maurer <mmaurer@google.com> wrote:
>
> On Tue, Dec 16, 2025 at 6:31 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
> >
> > On Wed Dec 17, 2025 at 4:24 AM JST, Matthew Maurer wrote:
> > > Allow SoC drivers in Rust to present metadata about their devices to
> > > userspace through /sys/devices/socX and other drivers to identify their
> > > properties through `soc_device_match`.
> > >
> > > Signed-off-by: Matthew Maurer <mmaurer@google.com>
> > > ---
> > >  MAINTAINERS                     |   1 +
> > >  rust/bindings/bindings_helper.h |   1 +
> > >  rust/kernel/lib.rs              |   2 +
> > >  rust/kernel/soc.rs              | 135 ++++++++++++++++++++++++++++++++++++++++
> > >  4 files changed, 139 insertions(+)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index c5a7cda26c600e49c7ab0d547306d3281333f672..4ff01fb0f1bda27002094113c0bf9d074d28fdb6 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -7700,6 +7700,7 @@ F:      rust/kernel/devres.rs
> > >  F:   rust/kernel/driver.rs
> > >  F:   rust/kernel/faux.rs
> > >  F:   rust/kernel/platform.rs
> > > +F:   rust/kernel/soc.rs
> > >  F:   samples/rust/rust_debugfs.rs
> > >  F:   samples/rust/rust_debugfs_scoped.rs
> > >  F:   samples/rust/rust_driver_platform.rs
> > > diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> > > index a067038b4b422b4256f4a2b75fe644d47e6e82c8..9fdf76ca630e00715503e2a3a809bedc895697fd 100644
> > > --- a/rust/bindings/bindings_helper.h
> > > +++ b/rust/bindings/bindings_helper.h
> > > @@ -80,6 +80,7 @@
> > >  #include <linux/sched.h>
> > >  #include <linux/security.h>
> > >  #include <linux/slab.h>
> > > +#include <linux/sys_soc.h>
> > >  #include <linux/task_work.h>
> > >  #include <linux/tracepoint.h>
> > >  #include <linux/usb.h>
> > > diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> > > index f812cf12004286962985a068665443dc22c389a2..6d637e2fed1b605e2dfc2e7b2247179439a90ba9 100644
> > > --- a/rust/kernel/lib.rs
> > > +++ b/rust/kernel/lib.rs
> > > @@ -138,6 +138,8 @@
> > >  pub mod seq_file;
> > >  pub mod sizes;
> > >  pub mod slice;
> > > +#[cfg(CONFIG_SOC_BUS)]
> > > +pub mod soc;
> > >  mod static_assert;
> > >  #[doc(hidden)]
> > >  pub mod std_vendor;
> > > diff --git a/rust/kernel/soc.rs b/rust/kernel/soc.rs
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..0d6a36c83cb67ef20dc1e3d3995752f36e25ac9f
> > > --- /dev/null
> > > +++ b/rust/kernel/soc.rs
> > > @@ -0,0 +1,135 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +
> > > +// Copyright (C) 2025 Google LLC.
> > > +
> > > +//! SoC Driver Abstraction.
> > > +//!
> > > +//! C header: [`include/linux/sys_soc.h`](srctree/include/linux/sys_soc.h)
> > > +
> > > +use crate::{
> > > +    bindings,
> > > +    error,
> > > +    prelude::*,
> > > +    str::CString,
> > > +    types::Opaque, //
> > > +};
> > > +use core::ptr::NonNull;
> > > +
> > > +/// Attributes for a SoC device.
> > > +///
> > > +/// These are both exported to userspace under /sys/devices/socX and provided to other drivers to
> > > +/// match against via `soc_device_match` (not yet available in Rust) to enable quirks or
> > > +/// device-specific support where necessary.
> > > +///
> > > +/// All fields are freeform - they have no specific formatting, just defined meanings.
> > > +/// For example, the [`machine`](`Attributes::machine`) field could be "DB8500" or
> > > +/// "Qualcomm Technologies, Inc. SM8560 HDK", but regardless it should identify a board or product.
> > > +pub struct Attributes {
> > > +    /// Should generally be a board ID or product ID. Examples
> > > +    /// include DB8500 (ST-Ericsson) or "Qualcomm Technologies, inc. SM8560 HDK".
> > > +    ///
> > > +    /// If this field is not populated, the SoC infrastructure will try to populate it from
> > > +    /// `/model` in the device tree.
> > > +    pub machine: Option<CString>,
> > > +    /// The broader class this SoC belongs to. Examples include ux500
> > > +    /// (for DB8500) or Snapdragon (for SM8650).
> >
> > Formatting of the comments seems a bit off (also appears in other
> > places, please reapply formatting globally to be sure).
>
> I have just re-run the `rustfmt` target on this commit, and see no
> changes. Is there something specific that you think is off?
>
> >
> > > +    ///
> > > +    /// On chips with ARM firmware supporting SMCCC v1.2+, this may be a JEDEC JEP106 manufacturer
> > > +    /// identification.
> > > +    pub family: Option<CString>,
> > > +    /// The manufacturing revision of the part. Frequently this is MAJOR.MINOR, but not always.
> > > +    pub revision: Option<CString>,
> > > +    /// Serial Number - uniquely identifies a specific SoC. If present, should be unique (buying a
> > > +    /// replacement part should change it if present). This field cannot be matched on and is
> > > +    /// solely present to export through /sys.
> > > +    pub serial_number: Option<CString>,
> > > +    /// SoC ID - identifies a specific SoC kind in question, sometimes more specifically than
> > > +    /// `machine` if the same SoC is used in multiple products. Some devices use this to specify a
> > > +    /// SoC name, e.g. "I.MX??", and others just print an ID number (e.g. Tegra and Qualcomm).
> > > +    ///
> > > +    /// On chips with ARM firmware supporting SMCCC v1.2+, this may be a JEDEC JEP106 manufacturer
> > > +    /// identification (the family value) followed by a colon and then a 4-digit ID value.
> > > +    pub soc_id: Option<CString>,
> > > +}
> > > +
> > > +struct BuiltAttributes {
> >
> > Even though this struct is private, some short documentation would be
> > helpful - actually the explanation about the relationship between
> > `_backing` and `inner` belongs here imho instead of in the member's
> > documentation.

I don't think I should do this unless there's some kernel-specific
style guidance I'm unaware of (I checked and couldn't find anything,
but maybe I missed something):
1. These are comments, not documentation. Documentation is intended
for a user of an interface, comments are intended for a reader of the
code. The information in these comments should not be considered by a
user of `BuiltAttributes`, even an internal one.
2. Usually the reason to provide documentation for a private structure
is that it is available for use at a larger scope than the local
module, even if it's not accessible outside the crate, for the
purposes of helping developers engage with the type either through an
IDE or a local reference. That does not apply here - this is an
implementation detail of `Registration` and should never be used
outside this file.

That said, I don't care that deeply about where this text goes, so if
consensus is that we'd prefer it to be in a doc comment I can put it
there; it just seems wrong to me.

Re: [PATCH v3 1/3] rust: Add soc_device support

[Miguel Ojeda]

On Fri, Dec 26, 2025 at 8:38 PM Matthew Maurer <mmaurer@google.com> wrote:
>
> I don't think I should do this unless there's some kernel-specific
> style guidance I'm unaware of (I checked and couldn't find anything,
> but maybe I missed something):

So we don't require private docs, but developers are always welcome to
add them. It really depends on a case-by-case basis: sometimes docs
are really needed, even if private, and other times not so much. Thus,
so far, I considered it was best to leave it to the developer and see
how code evolves.

In the future, the value/benefit of private docs may increase: I would
like to have a runtime toggle for the user that shows/hides private
and/or hidden items in the rendered docs, thus treating them as
first-class docs (including e.g. checking their intra-doc links work).
Upstream `rustdoc` seems to like the idea and even they even
implemented a draft of it (see
https://github.com/Rust-for-Linux/linux/issues/350 -> "private/hidden
items").

Comments vs. docs is an orthogonal part of this, and indeed, we use
comments for implementation-oriented things, and docs for the users
(and mixing them in the same place is also OK -- there is an example
of that in our guidelines that I wrote for clarity). There are some
exceptions and cases where it is reasonable to have either position
but, generally, we should avoid aim to avoid details that are clearly
implementation details in code documentation and vice versa.

As a rule of thumb: if a Rust item would have needed good docs to be
understandable if it were public (or became public later on), then it
should also have those docs even if it is private.

Cheers,
Miguel

Re: [PATCH v3 1/3] rust: Add soc_device support

[Alexandre Courbot]

On Sat Dec 27, 2025 at 4:38 AM JST, Matthew Maurer wrote:
> On Fri, Dec 26, 2025 at 11:26 AM Matthew Maurer <mmaurer@google.com> wrote:
>>
>> On Tue, Dec 16, 2025 at 6:31 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>> >
>> > On Wed Dec 17, 2025 at 4:24 AM JST, Matthew Maurer wrote:
>> > > Allow SoC drivers in Rust to present metadata about their devices to
>> > > userspace through /sys/devices/socX and other drivers to identify their
>> > > properties through `soc_device_match`.
>> > >
>> > > Signed-off-by: Matthew Maurer <mmaurer@google.com>
>> > > ---
>> > >  MAINTAINERS                     |   1 +
>> > >  rust/bindings/bindings_helper.h |   1 +
>> > >  rust/kernel/lib.rs              |   2 +
>> > >  rust/kernel/soc.rs              | 135 ++++++++++++++++++++++++++++++++++++++++
>> > >  4 files changed, 139 insertions(+)
>> > >
>> > > diff --git a/MAINTAINERS b/MAINTAINERS
>> > > index c5a7cda26c600e49c7ab0d547306d3281333f672..4ff01fb0f1bda27002094113c0bf9d074d28fdb6 100644
>> > > --- a/MAINTAINERS
>> > > +++ b/MAINTAINERS
>> > > @@ -7700,6 +7700,7 @@ F:      rust/kernel/devres.rs
>> > >  F:   rust/kernel/driver.rs
>> > >  F:   rust/kernel/faux.rs
>> > >  F:   rust/kernel/platform.rs
>> > > +F:   rust/kernel/soc.rs
>> > >  F:   samples/rust/rust_debugfs.rs
>> > >  F:   samples/rust/rust_debugfs_scoped.rs
>> > >  F:   samples/rust/rust_driver_platform.rs
>> > > diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
>> > > index a067038b4b422b4256f4a2b75fe644d47e6e82c8..9fdf76ca630e00715503e2a3a809bedc895697fd 100644
>> > > --- a/rust/bindings/bindings_helper.h
>> > > +++ b/rust/bindings/bindings_helper.h
>> > > @@ -80,6 +80,7 @@
>> > >  #include <linux/sched.h>
>> > >  #include <linux/security.h>
>> > >  #include <linux/slab.h>
>> > > +#include <linux/sys_soc.h>
>> > >  #include <linux/task_work.h>
>> > >  #include <linux/tracepoint.h>
>> > >  #include <linux/usb.h>
>> > > diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
>> > > index f812cf12004286962985a068665443dc22c389a2..6d637e2fed1b605e2dfc2e7b2247179439a90ba9 100644
>> > > --- a/rust/kernel/lib.rs
>> > > +++ b/rust/kernel/lib.rs
>> > > @@ -138,6 +138,8 @@
>> > >  pub mod seq_file;
>> > >  pub mod sizes;
>> > >  pub mod slice;
>> > > +#[cfg(CONFIG_SOC_BUS)]
>> > > +pub mod soc;
>> > >  mod static_assert;
>> > >  #[doc(hidden)]
>> > >  pub mod std_vendor;
>> > > diff --git a/rust/kernel/soc.rs b/rust/kernel/soc.rs
>> > > new file mode 100644
>> > > index 0000000000000000000000000000000000000000..0d6a36c83cb67ef20dc1e3d3995752f36e25ac9f
>> > > --- /dev/null
>> > > +++ b/rust/kernel/soc.rs
>> > > @@ -0,0 +1,135 @@
>> > > +// SPDX-License-Identifier: GPL-2.0
>> > > +
>> > > +// Copyright (C) 2025 Google LLC.
>> > > +
>> > > +//! SoC Driver Abstraction.
>> > > +//!
>> > > +//! C header: [`include/linux/sys_soc.h`](srctree/include/linux/sys_soc.h)
>> > > +
>> > > +use crate::{
>> > > +    bindings,
>> > > +    error,
>> > > +    prelude::*,
>> > > +    str::CString,
>> > > +    types::Opaque, //
>> > > +};
>> > > +use core::ptr::NonNull;
>> > > +
>> > > +/// Attributes for a SoC device.
>> > > +///
>> > > +/// These are both exported to userspace under /sys/devices/socX and provided to other drivers to
>> > > +/// match against via `soc_device_match` (not yet available in Rust) to enable quirks or
>> > > +/// device-specific support where necessary.
>> > > +///
>> > > +/// All fields are freeform - they have no specific formatting, just defined meanings.
>> > > +/// For example, the [`machine`](`Attributes::machine`) field could be "DB8500" or
>> > > +/// "Qualcomm Technologies, Inc. SM8560 HDK", but regardless it should identify a board or product.
>> > > +pub struct Attributes {
>> > > +    /// Should generally be a board ID or product ID. Examples
>> > > +    /// include DB8500 (ST-Ericsson) or "Qualcomm Technologies, inc. SM8560 HDK".
>> > > +    ///
>> > > +    /// If this field is not populated, the SoC infrastructure will try to populate it from
>> > > +    /// `/model` in the device tree.
>> > > +    pub machine: Option<CString>,
>> > > +    /// The broader class this SoC belongs to. Examples include ux500
>> > > +    /// (for DB8500) or Snapdragon (for SM8650).
>> >
>> > Formatting of the comments seems a bit off (also appears in other
>> > places, please reapply formatting globally to be sure).
>>
>> I have just re-run the `rustfmt` target on this commit, and see no
>> changes. Is there something specific that you think is off?
>>
>> >
>> > > +    ///
>> > > +    /// On chips with ARM firmware supporting SMCCC v1.2+, this may be a JEDEC JEP106 manufacturer
>> > > +    /// identification.
>> > > +    pub family: Option<CString>,
>> > > +    /// The manufacturing revision of the part. Frequently this is MAJOR.MINOR, but not always.
>> > > +    pub revision: Option<CString>,
>> > > +    /// Serial Number - uniquely identifies a specific SoC. If present, should be unique (buying a
>> > > +    /// replacement part should change it if present). This field cannot be matched on and is
>> > > +    /// solely present to export through /sys.
>> > > +    pub serial_number: Option<CString>,
>> > > +    /// SoC ID - identifies a specific SoC kind in question, sometimes more specifically than
>> > > +    /// `machine` if the same SoC is used in multiple products. Some devices use this to specify a
>> > > +    /// SoC name, e.g. "I.MX??", and others just print an ID number (e.g. Tegra and Qualcomm).
>> > > +    ///
>> > > +    /// On chips with ARM firmware supporting SMCCC v1.2+, this may be a JEDEC JEP106 manufacturer
>> > > +    /// identification (the family value) followed by a colon and then a 4-digit ID value.
>> > > +    pub soc_id: Option<CString>,
>> > > +}
>> > > +
>> > > +struct BuiltAttributes {
>> >
>> > Even though this struct is private, some short documentation would be
>> > helpful - actually the explanation about the relationship between
>> > `_backing` and `inner` belongs here imho instead of in the member's
>> > documentation.
>
> I don't think I should do this unless there's some kernel-specific
> style guidance I'm unaware of (I checked and couldn't find anything,
> but maybe I missed something):
> 1. These are comments, not documentation. Documentation is intended
> for a user of an interface, comments are intended for a reader of the
> code. The information in these comments should not be considered by a
> user of `BuiltAttributes`, even an internal one.
> 2. Usually the reason to provide documentation for a private structure
> is that it is available for use at a larger scope than the local
> module, even if it's not accessible outside the crate, for the
> purposes of helping developers engage with the type either through an
> IDE or a local reference. That does not apply here - this is an
> implementation detail of `Registration` and should never be used
> outside this file.
>
> That said, I don't care that deeply about where this text goes, so if
> consensus is that we'd prefer it to be in a doc comment I can put it
> there; it just seems wrong to me.

My thinking for suggesting this is that this code is open; other folks
might work on it later, who are not familiar with it.

Having the data structures properly documented is useful for them,
especially if they are related to other types in ways that are not
immediately obvious.

Re: [PATCH v3 1/3] rust: Add soc_device support

[Alexandre Courbot]

On Sat Dec 27, 2025 at 4:26 AM JST, Matthew Maurer wrote:
> On Tue, Dec 16, 2025 at 6:31 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>> On Wed Dec 17, 2025 at 4:24 AM JST, Matthew Maurer wrote:
>> > Allow SoC drivers in Rust to present metadata about their devices to
>> > userspace through /sys/devices/socX and other drivers to identify their
>> > properties through `soc_device_match`.
>> >
>> > Signed-off-by: Matthew Maurer <mmaurer@google.com>
>> > ---
>> >  MAINTAINERS                     |   1 +
>> >  rust/bindings/bindings_helper.h |   1 +
>> >  rust/kernel/lib.rs              |   2 +
>> >  rust/kernel/soc.rs              | 135 ++++++++++++++++++++++++++++++++++++++++
>> >  4 files changed, 139 insertions(+)
>> >
>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> > index c5a7cda26c600e49c7ab0d547306d3281333f672..4ff01fb0f1bda27002094113c0bf9d074d28fdb6 100644
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -7700,6 +7700,7 @@ F:      rust/kernel/devres.rs
>> >  F:   rust/kernel/driver.rs
>> >  F:   rust/kernel/faux.rs
>> >  F:   rust/kernel/platform.rs
>> > +F:   rust/kernel/soc.rs
>> >  F:   samples/rust/rust_debugfs.rs
>> >  F:   samples/rust/rust_debugfs_scoped.rs
>> >  F:   samples/rust/rust_driver_platform.rs
>> > diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
>> > index a067038b4b422b4256f4a2b75fe644d47e6e82c8..9fdf76ca630e00715503e2a3a809bedc895697fd 100644
>> > --- a/rust/bindings/bindings_helper.h
>> > +++ b/rust/bindings/bindings_helper.h
>> > @@ -80,6 +80,7 @@
>> >  #include <linux/sched.h>
>> >  #include <linux/security.h>
>> >  #include <linux/slab.h>
>> > +#include <linux/sys_soc.h>
>> >  #include <linux/task_work.h>
>> >  #include <linux/tracepoint.h>
>> >  #include <linux/usb.h>
>> > diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
>> > index f812cf12004286962985a068665443dc22c389a2..6d637e2fed1b605e2dfc2e7b2247179439a90ba9 100644
>> > --- a/rust/kernel/lib.rs
>> > +++ b/rust/kernel/lib.rs
>> > @@ -138,6 +138,8 @@
>> >  pub mod seq_file;
>> >  pub mod sizes;
>> >  pub mod slice;
>> > +#[cfg(CONFIG_SOC_BUS)]
>> > +pub mod soc;
>> >  mod static_assert;
>> >  #[doc(hidden)]
>> >  pub mod std_vendor;
>> > diff --git a/rust/kernel/soc.rs b/rust/kernel/soc.rs
>> > new file mode 100644
>> > index 0000000000000000000000000000000000000000..0d6a36c83cb67ef20dc1e3d3995752f36e25ac9f
>> > --- /dev/null
>> > +++ b/rust/kernel/soc.rs
>> > @@ -0,0 +1,135 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +
>> > +// Copyright (C) 2025 Google LLC.
>> > +
>> > +//! SoC Driver Abstraction.
>> > +//!
>> > +//! C header: [`include/linux/sys_soc.h`](srctree/include/linux/sys_soc.h)
>> > +
>> > +use crate::{
>> > +    bindings,
>> > +    error,
>> > +    prelude::*,
>> > +    str::CString,
>> > +    types::Opaque, //
>> > +};
>> > +use core::ptr::NonNull;
>> > +
>> > +/// Attributes for a SoC device.
>> > +///
>> > +/// These are both exported to userspace under /sys/devices/socX and provided to other drivers to
>> > +/// match against via `soc_device_match` (not yet available in Rust) to enable quirks or
>> > +/// device-specific support where necessary.
>> > +///
>> > +/// All fields are freeform - they have no specific formatting, just defined meanings.
>> > +/// For example, the [`machine`](`Attributes::machine`) field could be "DB8500" or
>> > +/// "Qualcomm Technologies, Inc. SM8560 HDK", but regardless it should identify a board or product.
>> > +pub struct Attributes {
>> > +    /// Should generally be a board ID or product ID. Examples
>> > +    /// include DB8500 (ST-Ericsson) or "Qualcomm Technologies, inc. SM8560 HDK".
>> > +    ///
>> > +    /// If this field is not populated, the SoC infrastructure will try to populate it from
>> > +    /// `/model` in the device tree.
>> > +    pub machine: Option<CString>,
>> > +    /// The broader class this SoC belongs to. Examples include ux500
>> > +    /// (for DB8500) or Snapdragon (for SM8650).
>>
>> Formatting of the comments seems a bit off (also appears in other
>> places, please reapply formatting globally to be sure).
>
> I have just re-run the `rustfmt` target on this commit, and see no
> changes. Is there something specific that you think is off?

rustfmt doesn't touch comments IIUC.

What I had in mind was for instance that the first line of the comment
for `machine` is shorter than it could be, i.e. the comments should be
re-wrapped for consistency.

[PATCH v3 2/3] docs: ABI: sysfs-devices-soc: Fix swapped sample values

[Matthew Maurer]

The sample values for `family` and `machine` were swapped relative to
what the driver actually does, and doesn't match the field description.

Reviewed-by: Lee Jones <lee@kernel.org>
Signed-off-by: Matthew Maurer <mmaurer@google.com>
---
 Documentation/ABI/testing/sysfs-devices-soc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-devices-soc b/Documentation/ABI/testing/sysfs-devices-soc
index 5269808ec35f8e2b18516556f886c77f5fac9401..cb6776a4afe02a76fe27ac6fc236babdc7865287 100644
--- a/Documentation/ABI/testing/sysfs-devices-soc
+++ b/Documentation/ABI/testing/sysfs-devices-soc
@@ -17,14 +17,14 @@ Date:		January 2012
 contact:	Lee Jones <lee@kernel.org>
 Description:
 		Read-only attribute common to all SoCs. Contains the SoC machine
-		name (e.g. Ux500).
+		name (e.g. DB8500).
 
 What:		/sys/devices/socX/family
 Date:		January 2012
 contact:	Lee Jones <lee@kernel.org>
 Description:
 		Read-only attribute common to all SoCs. Contains SoC family name
-		(e.g. DB8500).
+		(e.g. ux500).
 
 		On many of ARM based silicon with SMCCC v1.2+ compliant firmware
 		this will contain the JEDEC JEP106 manufacturer’s identification

-- 
2.52.0.305.g3fc767764a-goog

[PATCH v3 3/3] rust: Add SoC Driver Sample

[Matthew Maurer]

Shows registration of a SoC device upon receipt of a probe.

Signed-off-by: Matthew Maurer <mmaurer@google.com>
---
 MAINTAINERS              |  1 +
 samples/rust/Kconfig     | 11 +++++++
 samples/rust/Makefile    |  1 +
 samples/rust/rust_soc.rs | 82 ++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 95 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4ff01fb0f1bda27002094113c0bf9d074d28fdb6..bb2e710277cc84dd6042d4d46076e665d9f68752 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7705,6 +7705,7 @@ F:	samples/rust/rust_debugfs.rs
 F:	samples/rust/rust_debugfs_scoped.rs
 F:	samples/rust/rust_driver_platform.rs
 F:	samples/rust/rust_driver_faux.rs
+F:	samples/rust/rust_soc.rs
 
 DRIVERS FOR OMAP ADAPTIVE VOLTAGE SCALING (AVS)
 M:	Nishanth Menon <nm@ti.com>
diff --git a/samples/rust/Kconfig b/samples/rust/Kconfig
index 3efa51bfc8efccd91d9ee079ccd078ed1a6e8aa7..c49ab910634596aea4a1a73dac87585e084f420a 100644
--- a/samples/rust/Kconfig
+++ b/samples/rust/Kconfig
@@ -161,6 +161,17 @@ config SAMPLE_RUST_DRIVER_AUXILIARY
 
 	  If unsure, say N.
 
+config SAMPLE_RUST_SOC
+	tristate "SoC Driver"
+	select SOC_BUS
+	help
+	  This option builds the Rust SoC driver sample.
+
+	  To compile this as a module, choose M here:
+	  the module will be called rust_soc.
+
+	  If unsure, say N.
+
 config SAMPLE_RUST_HOSTPROGS
 	bool "Host programs"
 	help
diff --git a/samples/rust/Makefile b/samples/rust/Makefile
index f65885d1d62bf406b0db13121ef3e5b09829cfbc..6c0aaa58ccccfd12ef019f68ca784f6d977bc668 100644
--- a/samples/rust/Makefile
+++ b/samples/rust/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_SAMPLE_RUST_DRIVER_USB)		+= rust_driver_usb.o
 obj-$(CONFIG_SAMPLE_RUST_DRIVER_FAUX)		+= rust_driver_faux.o
 obj-$(CONFIG_SAMPLE_RUST_DRIVER_AUXILIARY)	+= rust_driver_auxiliary.o
 obj-$(CONFIG_SAMPLE_RUST_CONFIGFS)		+= rust_configfs.o
+obj-$(CONFIG_SAMPLE_RUST_SOC)			+= rust_soc.o
 
 rust_print-y := rust_print_main.o rust_print_events.o
 
diff --git a/samples/rust/rust_soc.rs b/samples/rust/rust_soc.rs
new file mode 100644
index 0000000000000000000000000000000000000000..33043b0ac8dadec36aebf369f0fb68dbb3b118ed
--- /dev/null
+++ b/samples/rust/rust_soc.rs
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Rust SoC Platform driver sample.
+
+use kernel::{
+    acpi,
+    c_str,
+    device::Core,
+    of,
+    platform,
+    prelude::*,
+    soc,
+    str::CString,
+    sync::aref::ARef, //
+};
+use pin_init::pin_init_scope;
+
+#[pin_data]
+struct SampleSocDriver {
+    pdev: ARef<platform::Device>,
+    #[pin]
+    _dev_reg: soc::Registration,
+}
+
+kernel::of_device_table!(
+    OF_TABLE,
+    MODULE_OF_TABLE,
+    <SampleSocDriver as platform::Driver>::IdInfo,
+    [(of::DeviceId::new(c_str!("test,rust-device")), ())]
+);
+
+kernel::acpi_device_table!(
+    ACPI_TABLE,
+    MODULE_ACPI_TABLE,
+    <SampleSocDriver as platform::Driver>::IdInfo,
+    [(acpi::DeviceId::new(c_str!("LNUXBEEF")), ())]
+);
+
+impl platform::Driver for SampleSocDriver {
+    type IdInfo = ();
+    const OF_ID_TABLE: Option<of::IdTable<Self::IdInfo>> = Some(&OF_TABLE);
+    const ACPI_ID_TABLE: Option<acpi::IdTable<Self::IdInfo>> = Some(&ACPI_TABLE);
+
+    fn probe(
+        pdev: &platform::Device<Core>,
+        _info: Option<&Self::IdInfo>,
+    ) -> impl PinInit<Self, Error> {
+        let dev = pdev.as_ref();
+
+        dev_dbg!(dev, "Probe Rust SoC driver sample.\n");
+
+        let pdev = pdev.into();
+        pin_init_scope(move || {
+            let machine = CString::try_from(c_str!("My cool ACME15 dev board"))?;
+            let family = CString::try_from(c_str!("ACME"))?;
+            let revision = CString::try_from(c_str!("1.2"))?;
+            let serial_number = CString::try_from(c_str!("12345"))?;
+            let soc_id = CString::try_from(c_str!("ACME15"))?;
+
+            let attr = soc::Attributes {
+                machine: Some(machine),
+                family: Some(family),
+                revision: Some(revision),
+                serial_number: Some(serial_number),
+                soc_id: Some(soc_id),
+            };
+
+            Ok(try_pin_init!(SampleSocDriver {
+                pdev: pdev,
+                _dev_reg <- soc::Registration::new(attr),
+            }? Error))
+        })
+    }
+}
+
+kernel::module_platform_driver! {
+    type: SampleSocDriver,
+    name: "rust_soc",
+    authors: ["Matthew Maurer"],
+    description: "Rust SoC Driver",
+    license: "GPL",
+}

-- 
2.52.0.305.g3fc767764a-goog

Re: [PATCH v3 3/3] rust: Add SoC Driver Sample

[Alexandre Courbot]

On Wed Dec 17, 2025 at 4:24 AM JST, Matthew Maurer wrote:
> Shows registration of a SoC device upon receipt of a probe.
>
> Signed-off-by: Matthew Maurer <mmaurer@google.com>
> ---
>  MAINTAINERS              |  1 +
>  samples/rust/Kconfig     | 11 +++++++
>  samples/rust/Makefile    |  1 +
>  samples/rust/rust_soc.rs | 82 ++++++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 95 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4ff01fb0f1bda27002094113c0bf9d074d28fdb6..bb2e710277cc84dd6042d4d46076e665d9f68752 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7705,6 +7705,7 @@ F:	samples/rust/rust_debugfs.rs
>  F:	samples/rust/rust_debugfs_scoped.rs
>  F:	samples/rust/rust_driver_platform.rs
>  F:	samples/rust/rust_driver_faux.rs
> +F:	samples/rust/rust_soc.rs
>  
>  DRIVERS FOR OMAP ADAPTIVE VOLTAGE SCALING (AVS)
>  M:	Nishanth Menon <nm@ti.com>
> diff --git a/samples/rust/Kconfig b/samples/rust/Kconfig
> index 3efa51bfc8efccd91d9ee079ccd078ed1a6e8aa7..c49ab910634596aea4a1a73dac87585e084f420a 100644
> --- a/samples/rust/Kconfig
> +++ b/samples/rust/Kconfig
> @@ -161,6 +161,17 @@ config SAMPLE_RUST_DRIVER_AUXILIARY
>  
>  	  If unsure, say N.
>  
> +config SAMPLE_RUST_SOC
> +	tristate "SoC Driver"
> +	select SOC_BUS
> +	help
> +	  This option builds the Rust SoC driver sample.
> +
> +	  To compile this as a module, choose M here:
> +	  the module will be called rust_soc.
> +
> +	  If unsure, say N.
> +
>  config SAMPLE_RUST_HOSTPROGS
>  	bool "Host programs"
>  	help
> diff --git a/samples/rust/Makefile b/samples/rust/Makefile
> index f65885d1d62bf406b0db13121ef3e5b09829cfbc..6c0aaa58ccccfd12ef019f68ca784f6d977bc668 100644
> --- a/samples/rust/Makefile
> +++ b/samples/rust/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_SAMPLE_RUST_DRIVER_USB)		+= rust_driver_usb.o
>  obj-$(CONFIG_SAMPLE_RUST_DRIVER_FAUX)		+= rust_driver_faux.o
>  obj-$(CONFIG_SAMPLE_RUST_DRIVER_AUXILIARY)	+= rust_driver_auxiliary.o
>  obj-$(CONFIG_SAMPLE_RUST_CONFIGFS)		+= rust_configfs.o
> +obj-$(CONFIG_SAMPLE_RUST_SOC)			+= rust_soc.o
>  
>  rust_print-y := rust_print_main.o rust_print_events.o
>  
> diff --git a/samples/rust/rust_soc.rs b/samples/rust/rust_soc.rs
> new file mode 100644
> index 0000000000000000000000000000000000000000..33043b0ac8dadec36aebf369f0fb68dbb3b118ed
> --- /dev/null
> +++ b/samples/rust/rust_soc.rs
> @@ -0,0 +1,82 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Rust SoC Platform driver sample.
> +
> +use kernel::{
> +    acpi,
> +    c_str,
> +    device::Core,
> +    of,
> +    platform,
> +    prelude::*,
> +    soc,
> +    str::CString,
> +    sync::aref::ARef, //
> +};
> +use pin_init::pin_init_scope;
> +
> +#[pin_data]
> +struct SampleSocDriver {
> +    pdev: ARef<platform::Device>,
> +    #[pin]
> +    _dev_reg: soc::Registration,
> +}
> +
> +kernel::of_device_table!(
> +    OF_TABLE,
> +    MODULE_OF_TABLE,
> +    <SampleSocDriver as platform::Driver>::IdInfo,
> +    [(of::DeviceId::new(c_str!("test,rust-device")), ())]

C strings can now be declared using `c"test,rust-device"` (applies
through this file).