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

[PATCH v4 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 v4:
- Switched `c_str!("foo")` usage to `c"foo"`
- Link to v3: https://lore.kernel.org/r/20251216-soc-bindings-v3-0-42ecdc8c117e@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                    |  81 +++++++++++++++++
 8 files changed, 235 insertions(+), 2 deletions(-)
---
base-commit: 008d3547aae5bc86fac3eda317489169c3fda112
change-id: 20251029-soc-bindings-9b0731bcdbed

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

[PATCH v4 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.351.gbe84eed79e-goog

[PATCH v4 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.351.gbe84eed79e-goog

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

[Danilo Krummrich]

On Fri Dec 26, 2025 at 9:17 PM CET, Matthew Maurer wrote:
> 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>

Fixes: da5a70f3519f ("Documentation: add information for new sysfs soc bus functionality")

> ---
>  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).

Is the change from "Ux500" to "ux500" intended?

(If not, no need to resend, I can fix it up on apply.)

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

[Matthew Maurer]

On Sun, Dec 28, 2025 at 10:12 AM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Fri Dec 26, 2025 at 9:17 PM CET, Matthew Maurer wrote:
> > 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>
>
> Fixes: da5a70f3519f ("Documentation: add information for new sysfs soc bus functionality")
>
> > ---
> >  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).
>
> Is the change from "Ux500" to "ux500" intended?

Yes, the sample SoC being described in the documentation uses
"ux500"[1] for the family value.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/ux500/ux500-soc-id.c#n133

>
> (If not, no need to resend, I can fix it up on apply.)

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

[Danilo Krummrich]

On Fri Dec 26, 2025 at 9:17 PM CET, Matthew Maurer wrote:
> 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>

Applied to driver-core-linus, thanks!

[PATCH v4 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 | 81 ++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 94 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..403c1137af779d3c660786959d6f5160f934f4ae
--- /dev/null
+++ b/samples/rust/rust_soc.rs
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Rust SoC Platform driver sample.
+
+use kernel::{
+    acpi,
+    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"test,rust-device"), ())]
+);
+
+kernel::acpi_device_table!(
+    ACPI_TABLE,
+    MODULE_ACPI_TABLE,
+    <SampleSocDriver as platform::Driver>::IdInfo,
+    [(acpi::DeviceId::new(c"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"My cool ACME15 dev board")?;
+            let family = CString::try_from(c"ACME")?;
+            let revision = CString::try_from(c"1.2")?;
+            let serial_number = CString::try_from(c"12345")?;
+            let soc_id = CString::try_from(c"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.351.gbe84eed79e-goog

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

[Kari Argillander]

On Fri, 26 Dec 2025 at 22:18, Matthew Maurer <mmaurer@google.com> wrote:

> +    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"My cool ACME15 dev board")?;
> +            let family = CString::try_from(c"ACME")?;
> +            let revision = CString::try_from(c"1.2")?;
> +            let serial_number = CString::try_from(c"12345")?;
> +            let soc_id = CString::try_from(c"ACME15")?;
> +
> +            let attr = soc::Attributes {
> +                machine: Some(machine),
> +                family: Some(family),
> +                revision: Some(revision),
> +                serial_number: Some(serial_number),
> +                soc_id: Some(soc_id),
> +            };

To me it seems little bit awkward that all needs to be CStrings. Maybe something
like this could be used (basically cow)

```rust
pub enum AttrStr {
    Static(&'static CStr),
    Owned(CString),
    None,
}
```

This will also take out Option with same time. Then some nice ergonomic way
to use this. This is suggestion and I have nothing to do with soc layer.

    Argillander

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

[Matthew Maurer]

On Sat, Dec 27, 2025 at 7:53 AM Kari Argillander
<kari.argillander@gmail.com> wrote:
>
> On Fri, 26 Dec 2025 at 22:18, Matthew Maurer <mmaurer@google.com> wrote:
>
> > +    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"My cool ACME15 dev board")?;
> > +            let family = CString::try_from(c"ACME")?;
> > +            let revision = CString::try_from(c"1.2")?;
> > +            let serial_number = CString::try_from(c"12345")?;
> > +            let soc_id = CString::try_from(c"ACME15")?;
> > +
> > +            let attr = soc::Attributes {
> > +                machine: Some(machine),
> > +                family: Some(family),
> > +                revision: Some(revision),
> > +                serial_number: Some(serial_number),
> > +                soc_id: Some(soc_id),
> > +            };
>
> To me it seems little bit awkward that all needs to be CStrings. Maybe something
> like this could be used (basically cow)
>
> ```rust
> pub enum AttrStr {
>     Static(&'static CStr),
>     Owned(CString),
>     None,
> }
> ```
>
> This will also take out Option with same time. Then some nice ergonomic way
> to use this. This is suggestion and I have nothing to do with soc layer.

IMO something like this should not be a SoC-specific special type.
Feel free to propose a `CowCStr` in `kernel::str`, or adding the more
general `Cow` and appropriate trait definitions to `kernel::alloc`,
and we could modify the API in the future. Basically, this seems like
a suggestion for a new vocabulary type rather than something for SoC.

We could technically also do a many-parameter'd struct and put `:
Deref<Target=CStr>` bounds on everything, but putting 6 type
parameters on something, which would then need explicit resolution
when `None` was used, seems potentially worse ergonomically.

>
>     Argillander

Re: [PATCH v4 0/3] Support exporting SoC info from Rust

[Danilo Krummrich]

On Fri Dec 26, 2025 at 9:17 PM CET, Matthew Maurer wrote:
> 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.

Applied to driver-core-testing, thanks!

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

I will pick this one up once -rc3 is out.

>       rust: Add SoC Driver Sample