[PATCH 0/2] rust: usb: add initial USB abstractions

[PATCH 0/2] rust: usb: add initial USB abstractions

[Daniel Almeida]

This adds initial support for USB Rust drivers, not only because I see a
widespread use of module_usb_driver() in media (which is a subsystem I
aim to support) but also because I want to learn about USB in general
and this is a nice opportunity to start doing so.

I tried to keep things as consistent with pci.rs and platform.rs as
possible and tested it by manually binding a device (i.e.: my Logitech
mouse) to the sample driver via:

/sys/bus/usb/drivers/rust_driver_usb/new_id

This initial patch is therefore comprised of the same patterns that are
known to work for pci and platform already.

Physically disconnecting the device also worked, i.e.: nothing bad
showed up in dmesg.

Note that I did not touch MAINTAINERS at all. The objective is to
kickstart the discussion of what to do there here in v1.

---
Daniel Almeida (2):
      rust: usb: add basic USB abstractions
      samples: rust: add a USB driver sample

 rust/bindings/bindings_helper.h |   1 +
 rust/helpers/helpers.c          |   1 +
 rust/helpers/usb.c              |   8 +
 rust/kernel/lib.rs              |   2 +
 rust/kernel/usb.rs              | 457 ++++++++++++++++++++++++++++++++++++++++
 samples/rust/Kconfig            |  11 +
 samples/rust/Makefile           |   1 +
 samples/rust/rust_driver_usb.rs |  47 +++++
 8 files changed, 528 insertions(+)
---
base-commit: 44d454fcffa8b08d6d66df132121c1d387fa85db
change-id: 20250825-b4-usb-dd0fe44fd78b

Best regards,
-- 
Daniel Almeida <daniel.almeida@collabora.com>

[PATCH 1/2] rust: usb: add basic USB abstractions

[Daniel Almeida]

Add basic USB abstractions, consisting of usb::{Device, Interface,
Driver, Adapter, DeviceId} and the module_usb_driver macro. This is the
first step in being able to write USB device drivers, which paves the
way for USB media drivers - for example - among others.

This initial support will then be used by a subsequent sample driver,
which constitutes the only user of the USB abstractions so far.

Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
---
 rust/bindings/bindings_helper.h |   1 +
 rust/helpers/helpers.c          |   1 +
 rust/helpers/usb.c              |   8 +
 rust/kernel/lib.rs              |   2 +
 rust/kernel/usb.rs              | 457 ++++++++++++++++++++++++++++++++++++++++
 5 files changed, 469 insertions(+)

diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 69a975da829f0c35760f71a1b32b8fcb12c8a8dc..645afe578668097ae04455d9eefb102d1f1ce4af 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -73,6 +73,7 @@
 #include <linux/security.h>
 #include <linux/slab.h>
 #include <linux/tracepoint.h>
+#include <linux/usb.h>
 #include <linux/wait.h>
 #include <linux/workqueue.h>
 #include <linux/xarray.h>
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index 44b2005d50140d34a44ae37d01c2ddbae6aeaa32..da1ee0d3705739e789c7ad21b957bbdb7ca23521 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -48,6 +48,7 @@
 #include "task.c"
 #include "time.c"
 #include "uaccess.c"
+#include "usb.c"
 #include "vmalloc.c"
 #include "wait.c"
 #include "workqueue.c"
diff --git a/rust/helpers/usb.c b/rust/helpers/usb.c
new file mode 100644
index 0000000000000000000000000000000000000000..fb2aad0cbf4d26ac7fb1a3f176ee7a1d30800f92
--- /dev/null
+++ b/rust/helpers/usb.c
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/usb.h>
+
+struct usb_device *rust_helper_interface_to_usbdev(struct usb_interface *intf)
+{
+	return interface_to_usbdev(intf);
+}
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index f8db761c5c95fc66e4c55f539b17fca613161ada..b15277a02028aa1d27480d0630f9f599cacd6e4d 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -127,6 +127,8 @@
 pub mod tracepoint;
 pub mod transmute;
 pub mod types;
+#[cfg(CONFIG_USB)]
+pub mod usb;
 pub mod uaccess;
 pub mod workqueue;
 pub mod xarray;
diff --git a/rust/kernel/usb.rs b/rust/kernel/usb.rs
new file mode 100644
index 0000000000000000000000000000000000000000..8899e7520b58d4e4b08927d54c8912650b78da33
--- /dev/null
+++ b/rust/kernel/usb.rs
@@ -0,0 +1,457 @@
+// SPDX-License-Identifier: GPL-2.0
+// SPDX-FileCopyrightText: Copyright (C) 2025 Collabora Ltd.
+
+//! Abstractions for the USB bus.
+//!
+//! C header: [`include/linux/usb.h`](srctree/include/linux/usb.h)
+
+use crate::{
+    bindings, device,
+    device_id::{RawDeviceId, RawDeviceIdIndex},
+    driver,
+    error::{from_result, to_result, Result},
+    prelude::*,
+    str::CStr,
+    types::{AlwaysRefCounted, Opaque},
+    ThisModule,
+};
+use core::{marker::PhantomData, mem::MaybeUninit, ptr::NonNull};
+
+/// An adapter for the registration of USB drivers.
+pub struct Adapter<T: Driver>(T);
+
+// SAFETY: A call to `unregister` for a given instance of `RegType` is guaranteed to be valid if
+// a preceding call to `register` has been successful.
+unsafe impl<T: Driver + 'static> driver::RegistrationOps for Adapter<T> {
+    type RegType = bindings::usb_driver;
+
+    unsafe fn register(
+        udrv: &Opaque<Self::RegType>,
+        name: &'static CStr,
+        module: &'static ThisModule,
+    ) -> Result {
+        // SAFETY: It's safe to set the fields of `struct usb_driver` on initialization.
+        unsafe {
+            (*udrv.get()).name = name.as_char_ptr();
+            (*udrv.get()).probe = Some(Self::probe_callback);
+            (*udrv.get()).disconnect = Some(Self::disconnect_callback);
+            (*udrv.get()).id_table = T::ID_TABLE.as_ptr();
+        }
+
+        // SAFETY: `udrv` is guaranteed to be a valid `RegType`.
+        to_result(unsafe {
+            bindings::usb_register_driver(udrv.get(), module.0, name.as_char_ptr())
+        })
+    }
+
+    unsafe fn unregister(udrv: &Opaque<Self::RegType>) {
+        // SAFETY: `udrv` is guaranteed to be a valid `RegType`.
+        unsafe { bindings::usb_deregister(udrv.get()) };
+    }
+}
+
+impl<T: Driver + 'static> Adapter<T> {
+    extern "C" fn probe_callback(
+        intf: *mut bindings::usb_interface,
+        id: *const bindings::usb_device_id,
+    ) -> kernel::ffi::c_int {
+        // SAFETY: The USB core only ever calls the probe callback with a valid pointer to a
+        // `struct usb_interface` and `struct usb_device_id`.
+        //
+        // INVARIANT: `intf` is valid for the duration of `probe_callback()`.
+        let intf = unsafe { &*intf.cast::<Interface<device::CoreInternal>>() };
+
+        from_result(|| {
+            // SAFETY: `DeviceId` is a `#[repr(transparent)]` wrapper of `struct usb_device_id` and
+            // does not add additional invariants, so it's safe to transmute.
+            let id = unsafe { &*id.cast::<DeviceId>() };
+
+            let info = T::ID_TABLE.info(id.index());
+            let data = T::probe(intf, id, info)?;
+
+            let dev: &device::Device<device::CoreInternal> = intf.as_ref();
+            dev.set_drvdata(data);
+            Ok(0)
+        })
+    }
+
+    extern "C" fn disconnect_callback(intf: *mut bindings::usb_interface) {
+        // SAFETY: The USB core only ever calls the disconnect callback with a valid pointer to a
+        // `struct usb_interface`.
+        //
+        // INVARIANT: `intf` is valid for the duration of `disconnect_callback()`.
+        let intf = unsafe { &*intf.cast::<Interface<device::CoreInternal>>() };
+
+        let dev: &device::Device<device::CoreInternal> = intf.as_ref();
+
+        // SAFETY: `disconnect_callback` is only ever called after a successful call to
+        // `probe_callback`, hence it's guaranteed that `Device::set_drvdata()` has been called
+        // and stored a `Pin<KBox<T>>`.
+        let data = unsafe { dev.drvdata_obtain::<Pin<KBox<T>>>() };
+
+        T::disconnect(intf, data.as_ref());
+    }
+}
+
+/// Abstraction for the USB device ID structure, i.e. [`struct usb_device_id`].
+///
+/// [`struct usb_device_id`]: https://docs.kernel.org/driver-api/basics.html#c.usb_device_id
+#[repr(transparent)]
+#[derive(Clone, Copy)]
+pub struct DeviceId(bindings::usb_device_id);
+
+impl DeviceId {
+    /// Equivalent to C's `USB_DEVICE` macro.
+    pub const fn from_id(vendor: u16, product: u16) -> Self {
+        Self(bindings::usb_device_id {
+            match_flags: bindings::USB_DEVICE_ID_MATCH_DEVICE as u16,
+            idVendor: vendor,
+            idProduct: product,
+            // SAFETY: It is safe to use all zeroes for the other fields of `usb_device_id`.
+            ..unsafe { MaybeUninit::zeroed().assume_init() }
+        })
+    }
+
+    /// Equivalent to C's `USB_DEVICE_VER` macro.
+    pub const fn from_device_ver(vendor: u16, product: u16, bcd_lo: u16, bcd_hi: u16) -> Self {
+        Self(bindings::usb_device_id {
+            match_flags: bindings::USB_DEVICE_ID_MATCH_DEVICE_AND_VERSION as u16,
+            idVendor: vendor,
+            idProduct: product,
+            bcdDevice_lo: bcd_lo,
+            bcdDevice_hi: bcd_hi,
+            // SAFETY: It is safe to use all zeroes for the other fields of `usb_device_id`.
+            ..unsafe { MaybeUninit::zeroed().assume_init() }
+        })
+    }
+
+    /// Equivalent to C's `USB_DEVICE_INFO` macro.
+    pub const fn from_device_info(class: u8, subclass: u8, protocol: u8) -> Self {
+        Self(bindings::usb_device_id {
+            match_flags: bindings::USB_DEVICE_ID_MATCH_DEV_INFO as u16,
+            bDeviceClass: class,
+            bDeviceSubClass: subclass,
+            bDeviceProtocol: protocol,
+            // SAFETY: It is safe to use all zeroes for the other fields of `usb_device_id`.
+            ..unsafe { MaybeUninit::zeroed().assume_init() }
+        })
+    }
+
+    /// Equivalent to C's `USB_INTERFACE_INFO` macro.
+    pub const fn from_interface_info(class: u8, subclass: u8, protocol: u8) -> Self {
+        Self(bindings::usb_device_id {
+            match_flags: bindings::USB_DEVICE_ID_MATCH_INT_INFO as u16,
+            bInterfaceClass: class,
+            bInterfaceSubClass: subclass,
+            bInterfaceProtocol: protocol,
+            // SAFETY: It is safe to use all zeroes for the other fields of `usb_device_id`.
+            ..unsafe { MaybeUninit::zeroed().assume_init() }
+        })
+    }
+
+    /// Equivalent to C's `USB_DEVICE_INTERFACE_CLASS` macro.
+    pub const fn from_device_interface_class(vendor: u16, product: u16, class: u8) -> Self {
+        Self(bindings::usb_device_id {
+            match_flags: (bindings::USB_DEVICE_ID_MATCH_DEVICE
+                | bindings::USB_DEVICE_ID_MATCH_INT_CLASS) as u16,
+            idVendor: vendor,
+            idProduct: product,
+            bInterfaceClass: class,
+            // SAFETY: It is safe to use all zeroes for the other fields of `usb_device_id`.
+            ..unsafe { MaybeUninit::zeroed().assume_init() }
+        })
+    }
+
+    /// Equivalent to C's `USB_DEVICE_INTERFACE_PROTOCOL` macro.
+    pub const fn from_device_interface_protocol(vendor: u16, product: u16, protocol: u8) -> Self {
+        Self(bindings::usb_device_id {
+            match_flags: (bindings::USB_DEVICE_ID_MATCH_DEVICE
+                | bindings::USB_DEVICE_ID_MATCH_INT_PROTOCOL) as u16,
+            idVendor: vendor,
+            idProduct: product,
+            bInterfaceProtocol: protocol,
+            // SAFETY: It is safe to use all zeroes for the other fields of `usb_device_id`.
+            ..unsafe { MaybeUninit::zeroed().assume_init() }
+        })
+    }
+
+    /// Equivalent to C's `USB_DEVICE_INTERFACE_NUMBER` macro.
+    pub const fn from_device_interface_number(vendor: u16, product: u16, number: u8) -> Self {
+        Self(bindings::usb_device_id {
+            match_flags: (bindings::USB_DEVICE_ID_MATCH_DEVICE
+                | bindings::USB_DEVICE_ID_MATCH_INT_NUMBER) as u16,
+            idVendor: vendor,
+            idProduct: product,
+            bInterfaceNumber: number,
+            // SAFETY: It is safe to use all zeroes for the other fields of `usb_device_id`.
+            ..unsafe { MaybeUninit::zeroed().assume_init() }
+        })
+    }
+
+    /// Equivalent to C's `USB_DEVICE_AND_INTERFACE_INFO` macro.
+    pub const fn from_device_and_interface_info(
+        vendor: u16,
+        product: u16,
+        class: u8,
+        subclass: u8,
+        protocol: u8,
+    ) -> Self {
+        Self(bindings::usb_device_id {
+            match_flags: (bindings::USB_DEVICE_ID_MATCH_INT_INFO
+                | bindings::USB_DEVICE_ID_MATCH_DEVICE) as u16,
+            idVendor: vendor,
+            idProduct: product,
+            bInterfaceClass: class,
+            bInterfaceSubClass: subclass,
+            bInterfaceProtocol: protocol,
+            // SAFETY: It is safe to use all zeroes for the other fields of `usb_device_id`.
+            ..unsafe { MaybeUninit::zeroed().assume_init() }
+        })
+    }
+}
+
+// SAFETY: `DeviceId` is a `#[repr(transparent)]` wrapper of `usb_device_id` and does not add
+// additional invariants, so it's safe to transmute to `RawType`.
+unsafe impl RawDeviceId for DeviceId {
+    type RawType = bindings::usb_device_id;
+}
+
+// SAFETY: `DRIVER_DATA_OFFSET` is the offset to the `driver_info` field.
+unsafe impl RawDeviceIdIndex for DeviceId {
+    const DRIVER_DATA_OFFSET: usize = core::mem::offset_of!(bindings::usb_device_id, driver_info);
+
+    fn index(&self) -> usize {
+        self.0.driver_info
+    }
+}
+
+/// [`IdTable`](kernel::device_id::IdTable) type for USB.
+pub type IdTable<T> = &'static dyn kernel::device_id::IdTable<DeviceId, T>;
+
+/// Create a USB `IdTable` with its alias for modpost.
+#[macro_export]
+macro_rules! usb_device_table {
+    ($table_name:ident, $module_table_name:ident, $id_info_type: ty, $table_data: expr) => {
+        const $table_name: $crate::device_id::IdArray<
+            $crate::usb::DeviceId,
+            $id_info_type,
+            { $table_data.len() },
+        > = $crate::device_id::IdArray::new($table_data);
+
+        $crate::module_device_table!("usb", $module_table_name, $table_name);
+    };
+}
+
+/// The USB driver trait.
+///
+/// # Examples
+///
+///```
+/// # use kernel::{bindings, device::Core, usb};
+/// use kernel::prelude::*;
+///
+/// struct MyDriver;
+///
+/// kernel::usb_device_table!(
+///     USB_TABLE,
+///     MODULE_USB_TABLE,
+///     <MyDriver as usb::Driver>::IdInfo,
+///     [
+///         (usb::DeviceId::from_id(0x1234, 0x5678), ()),
+///         (usb::DeviceId::from_id(0xabcd, 0xef01), ()),
+///     ]
+/// );
+///
+/// impl usb::Driver for MyDriver {
+///     type IdInfo = ();
+///     const ID_TABLE: usb::IdTable<Self::IdInfo> = &USB_TABLE;
+///
+///     fn probe(
+///         _interface: &usb::Interface<Core>,
+///         _id: &usb::DeviceId,
+///         _info: &Self::IdInfo,
+///     ) -> Result<Pin<KBox<Self>>> {
+///         Err(ENODEV)
+///     }
+///
+///     fn disconnect(_interface: &usb::Interface<Core>, _data: Pin<&Self>) {}
+/// }
+///```
+pub trait Driver {
+    /// The type holding information about each one of the device ids supported by the driver.
+    type IdInfo: 'static;
+
+    /// The table of device ids supported by the driver.
+    const ID_TABLE: IdTable<Self::IdInfo>;
+
+    /// USB driver probe.
+    ///
+    /// Called when a new USB interface is bound to this driver.
+    /// Implementers should attempt to initialize the interface here.
+    fn probe(
+        interface: &Interface<device::Core>,
+        id: &DeviceId,
+        id_info: &Self::IdInfo,
+    ) -> Result<Pin<KBox<Self>>>;
+
+    /// USB driver disconnect.
+    ///
+    /// Called when the USB interface is about to be unbound from this driver.
+    fn disconnect(interface: &Interface<device::Core>, data: Pin<&Self>);
+}
+
+/// A USB interface.
+///
+/// This structure represents the Rust abstraction for a C [`struct usb_interface`].
+/// The implementation abstracts the usage of a C [`struct usb_interface`] passed
+/// in from the C side.
+///
+/// # Invariants
+///
+/// An [`Interface`] instance represents a valid [`struct usb_interface`] created
+/// by the C portion of the kernel.
+///
+/// [`struct usb_interface`]: https://www.kernel.org/doc/html/latest/driver-api/usb/usb.html#c.usb_interface
+#[repr(transparent)]
+pub struct Interface<Ctx: device::DeviceContext = device::Normal>(
+    Opaque<bindings::usb_interface>,
+    PhantomData<Ctx>,
+);
+
+impl<Ctx: device::DeviceContext> Interface<Ctx> {
+    fn as_raw(&self) -> *mut bindings::usb_interface {
+        self.0.get()
+    }
+}
+
+// SAFETY: `Interface` is a transparent wrapper of a type that doesn't depend on
+// `Interface`'s generic argument.
+kernel::impl_device_context_deref!(unsafe { Interface });
+kernel::impl_device_context_into_aref!(Interface);
+
+impl<Ctx: device::DeviceContext> AsRef<device::Device<Ctx>> for Interface<Ctx> {
+    fn as_ref(&self) -> &device::Device<Ctx> {
+        // SAFETY: By the type invariant of `Self`, `self.as_raw()` is a pointer to a valid
+        // `struct usb_interface`.
+        let dev = unsafe { &raw mut ((*self.as_raw()).dev) };
+
+        // SAFETY: `dev` points to a valid `struct device`.
+        unsafe { device::Device::from_raw(dev) }
+    }
+}
+
+impl<Ctx: device::DeviceContext> AsRef<Device<Ctx>> for Interface<Ctx> {
+    fn as_ref(&self) -> &Device<Ctx> {
+        // SAFETY: `self.as_raw()` is valid by the type invariants. For a valid interface,
+        // the helper should always return a valid USB device pointer.
+        let usb_dev = unsafe { bindings::interface_to_usbdev(self.as_raw()) };
+
+        // SAFETY: The helper returns a valid interface pointer that shares the
+        // same `DeviceContext`.
+        unsafe { &*(usb_dev.cast()) }
+    }
+}
+
+// SAFETY: Instances of `Interface` are always reference-counted.
+unsafe impl AlwaysRefCounted for Interface {
+    fn inc_ref(&self) {
+        // SAFETY: The invariants of `Interface` guarantee that `self.as_raw()`
+        // returns a valid `struct usb_interface` pointer, for which we will
+        // acquire a new refcount.
+        unsafe { bindings::usb_get_intf(self.as_raw()) };
+    }
+
+    unsafe fn dec_ref(obj: NonNull<Self>) {
+        // SAFETY: The safety requirements guarantee that the refcount is non-zero.
+        unsafe { bindings::usb_put_intf(obj.cast().as_ptr()) }
+    }
+}
+
+// SAFETY: A `Interface` is always reference-counted and can be released from any thread.
+unsafe impl Send for Interface {}
+
+// SAFETY: It is safe to send a &Interface to another thread because we do not
+// allow any mutation through a shared reference.
+unsafe impl Sync for Interface {}
+
+/// A USB device.
+///
+/// This structure represents the Rust abstraction for a C [`struct usb_device`].
+/// The implementation abstracts the usage of a C [`struct usb_device`] passed in
+/// from the C side.
+///
+/// # Invariants
+///
+/// A [`Device`] instance represents a valid [`struct usb_device`] created by the C portion of the
+/// kernel.
+///
+/// [`struct usb_device`]: https://www.kernel.org/doc/html/latest/driver-api/usb/usb.html#c.usb_device
+#[repr(transparent)]
+pub struct Device<Ctx: device::DeviceContext = device::Normal>(
+    Opaque<bindings::usb_device>,
+    PhantomData<Ctx>,
+);
+
+impl<Ctx: device::DeviceContext> Device<Ctx> {
+    fn as_raw(&self) -> *mut bindings::usb_device {
+        self.0.get()
+    }
+}
+
+// SAFETY: `Device` is a transparent wrapper of a type that doesn't depend on `Device`'s generic
+// argument.
+kernel::impl_device_context_deref!(unsafe { Device });
+kernel::impl_device_context_into_aref!(Device);
+
+// SAFETY: Instances of `Device` are always reference-counted.
+unsafe impl AlwaysRefCounted for Device {
+    fn inc_ref(&self) {
+        // SAFETY: The invariants of `Device` guarantee that `self.as_raw()`
+        // returns a valid `struct usb_device` pointer, for which we will
+        // acquire a new refcount.
+        unsafe { bindings::usb_get_dev(self.as_raw()) };
+    }
+
+    unsafe fn dec_ref(obj: NonNull<Self>) {
+        // SAFETY: The safety requirements guarantee that the refcount is non-zero.
+        unsafe { bindings::usb_put_dev(obj.cast().as_ptr()) }
+    }
+}
+
+impl<Ctx: device::DeviceContext> AsRef<device::Device<Ctx>> for Device<Ctx> {
+    fn as_ref(&self) -> &device::Device<Ctx> {
+        // SAFETY: By the type invariant of `Self`, `self.as_raw()` is a pointer to a valid
+        // `struct usb_device`.
+        let dev = unsafe { &raw mut ((*self.as_raw()).dev) };
+
+        // SAFETY: `dev` points to a valid `struct device`.
+        unsafe { device::Device::from_raw(dev) }
+    }
+}
+
+// SAFETY: A `Device` is always reference-counted and can be released from any thread.
+unsafe impl Send for Device {}
+
+// SAFETY: It is safe to send a &Device to another thread because we do not
+// allow any mutation through a shared reference.
+unsafe impl Sync for Device {}
+
+/// Declares a kernel module that exposes a single USB driver.
+///
+/// # Examples
+///
+/// ```ignore
+/// module_usb_driver! {
+///     type: MyDriver,
+///     name: "Module name",
+///     author: ["Author name"],
+///     description: "Description",
+///     license: "GPL v2",
+/// }
+/// ```
+#[macro_export]
+macro_rules! module_usb_driver {
+    ($($f:tt)*) => {
+        $crate::module_driver!(<T>, $crate::usb::Adapter<T>, { $($f)* });
+    }
+}

-- 
2.50.1

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Benno Lossin]

On Mon Aug 25, 2025 at 8:18 PM CEST, Daniel Almeida wrote:
> +impl DeviceId {
> +    /// Equivalent to C's `USB_DEVICE` macro.
> +    pub const fn from_id(vendor: u16, product: u16) -> Self {
> +        Self(bindings::usb_device_id {
> +            match_flags: bindings::USB_DEVICE_ID_MATCH_DEVICE as u16,
> +            idVendor: vendor,
> +            idProduct: product,
> +            // SAFETY: It is safe to use all zeroes for the other fields of `usb_device_id`.
> +            ..unsafe { MaybeUninit::zeroed().assume_init() }

You can avoid this usage of `unsafe` with this patch series:

    https://lore.kernel.org/all/20250814093046.2071971-1-lossin@kernel.org

I'd like to avoid introducing any new one of these.

---
Cheers,
Benno

> +        })
> +    }

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Daniel Almeida]

Hi Benno,

> On 25 Aug 2025, at 17:49, Benno Lossin <lossin@kernel.org> wrote:
> 
> On Mon Aug 25, 2025 at 8:18 PM CEST, Daniel Almeida wrote:
>> +impl DeviceId {
>> +    /// Equivalent to C's `USB_DEVICE` macro.
>> +    pub const fn from_id(vendor: u16, product: u16) -> Self {
>> +        Self(bindings::usb_device_id {
>> +            match_flags: bindings::USB_DEVICE_ID_MATCH_DEVICE as u16,
>> +            idVendor: vendor,
>> +            idProduct: product,
>> +            // SAFETY: It is safe to use all zeroes for the other fields of `usb_device_id`.
>> +            ..unsafe { MaybeUninit::zeroed().assume_init() }
> 
> You can avoid this usage of `unsafe` with this patch series:
> 
>    https://lore.kernel.org/all/20250814093046.2071971-1-lossin@kernel.org
> 
> I'd like to avoid introducing any new one of these.
> 
> ---
> Cheers,
> Benno
> 
>> +        })
>> +    }
> 

Ah, nice, you spoke about this in the last RFL call, I remember it now.

Ok, I will address this in the next version.

— Daniel

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Danilo Krummrich]

On Mon Aug 25, 2025 at 8:18 PM CEST, Daniel Almeida wrote:
> +/// The USB driver trait.
> +///
> +/// # Examples
> +///
> +///```
> +/// # use kernel::{bindings, device::Core, usb};
> +/// use kernel::prelude::*;
> +///
> +/// struct MyDriver;
> +///
> +/// kernel::usb_device_table!(
> +///     USB_TABLE,
> +///     MODULE_USB_TABLE,
> +///     <MyDriver as usb::Driver>::IdInfo,
> +///     [
> +///         (usb::DeviceId::from_id(0x1234, 0x5678), ()),
> +///         (usb::DeviceId::from_id(0xabcd, 0xef01), ()),
> +///     ]
> +/// );
> +///
> +/// impl usb::Driver for MyDriver {
> +///     type IdInfo = ();
> +///     const ID_TABLE: usb::IdTable<Self::IdInfo> = &USB_TABLE;
> +///
> +///     fn probe(
> +///         _interface: &usb::Interface<Core>,
> +///         _id: &usb::DeviceId,
> +///         _info: &Self::IdInfo,
> +///     ) -> Result<Pin<KBox<Self>>> {
> +///         Err(ENODEV)
> +///     }
> +///
> +///     fn disconnect(_interface: &usb::Interface<Core>, _data: Pin<&Self>) {}
> +/// }
> +///```
> +pub trait Driver {
> +    /// The type holding information about each one of the device ids supported by the driver.
> +    type IdInfo: 'static;
> +
> +    /// The table of device ids supported by the driver.
> +    const ID_TABLE: IdTable<Self::IdInfo>;
> +
> +    /// USB driver probe.
> +    ///
> +    /// Called when a new USB interface is bound to this driver.
> +    /// Implementers should attempt to initialize the interface here.
> +    fn probe(
> +        interface: &Interface<device::Core>,
> +        id: &DeviceId,
> +        id_info: &Self::IdInfo,
> +    ) -> Result<Pin<KBox<Self>>>;
> +
> +    /// USB driver disconnect.
> +    ///
> +    /// Called when the USB interface is about to be unbound from this driver.
> +    fn disconnect(interface: &Interface<device::Core>, data: Pin<&Self>);

I think this callback should be optional, like all the other unbind() we have in
other busses.

@Greg: Why is this called disconnect() in the C code instead of remove()?

For Rust, I feel like we should align to the unbind() terminology we use
everywhere else (for the same reasons we chose unbind() over remove() for other
busses as well).

We went with unbind(), since the "raw" remove() (or disconnect()) callback does
more, i.e. it first calls into unbind() and then drops the driver's private data
for this specific device.

So, the unbind() callback that goes to the driver is only meant as a place for
drivers to perform operations to tear down the device. Resources are freed
subsequently when the driver's private data is dropped.

> +/// A USB device.
> +///
> +/// This structure represents the Rust abstraction for a C [`struct usb_device`].
> +/// The implementation abstracts the usage of a C [`struct usb_device`] passed in
> +/// from the C side.
> +///
> +/// # Invariants
> +///
> +/// A [`Device`] instance represents a valid [`struct usb_device`] created by the C portion of the
> +/// kernel.
> +///
> +/// [`struct usb_device`]: https://www.kernel.org/doc/html/latest/driver-api/usb/usb.html#c.usb_device
> +#[repr(transparent)]
> +pub struct Device<Ctx: device::DeviceContext = device::Normal>(
> +    Opaque<bindings::usb_device>,
> +    PhantomData<Ctx>,
> +);

What do you use the struct usb_device abstraction for? I only see the sample
driver probing a USB interface instead.

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Daniel Almeida]

Hi Danilo,


>> +/// A USB device.
>> +///
>> +/// This structure represents the Rust abstraction for a C [`struct usb_device`].
>> +/// The implementation abstracts the usage of a C [`struct usb_device`] passed in
>> +/// from the C side.
>> +///
>> +/// # Invariants
>> +///
>> +/// A [`Device`] instance represents a valid [`struct usb_device`] created by the C portion of the
>> +/// kernel.
>> +///
>> +/// [`struct usb_device`]: https://www.kernel.org/doc/html/latest/driver-api/usb/usb.html#c.usb_device
>> +#[repr(transparent)]
>> +pub struct Device<Ctx: device::DeviceContext = device::Normal>(
>> +    Opaque<bindings::usb_device>,
>> +    PhantomData<Ctx>,
>> +);
> 
> What do you use the struct usb_device abstraction for? I only see the sample
> driver probing a USB interface instead.

What I was brainstorming with Greg is to submit this initial support, and then
follow up with all the other abstractions needed to implement a Rust version of
usb-skeleton.c. IIUC, the plan is to submit any fixes as follow-ups, as we're
close to the merge window.

struct usb_device would be used for the skeleton driver, so we should keep it if
we're following the plan above, IMHO.

— Daniel

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Danilo Krummrich]

On Tue Sep 23, 2025 at 3:31 PM CEST, Daniel Almeida wrote:
>>> +/// A USB device.
>>> +///
>>> +/// This structure represents the Rust abstraction for a C [`struct usb_device`].
>>> +/// The implementation abstracts the usage of a C [`struct usb_device`] passed in
>>> +/// from the C side.
>>> +///
>>> +/// # Invariants
>>> +///
>>> +/// A [`Device`] instance represents a valid [`struct usb_device`] created by the C portion of the
>>> +/// kernel.
>>> +///
>>> +/// [`struct usb_device`]: https://www.kernel.org/doc/html/latest/driver-api/usb/usb.html#c.usb_device
>>> +#[repr(transparent)]
>>> +pub struct Device<Ctx: device::DeviceContext = device::Normal>(
>>> +    Opaque<bindings::usb_device>,
>>> +    PhantomData<Ctx>,
>>> +);
>> 
>> What do you use the struct usb_device abstraction for? I only see the sample
>> driver probing a USB interface instead.
>
> What I was brainstorming with Greg is to submit this initial support, and then
> follow up with all the other abstractions needed to implement a Rust version of
> usb-skeleton.c. IIUC, the plan is to submit any fixes as follow-ups, as we're
> close to the merge window.
>
> struct usb_device would be used for the skeleton driver, so we should keep it if
> we're following the plan above, IMHO.

Yes, it's clearly required for the raw accessors for submitting URBs, e.g.
usb_fill_bulk_urb(), usb_submit_urb(), etc.

But I'm not sure you actually have to expose a representation of a struct
usb_device (with device context information) publically for that. It seems to me
that this can all be contained within the abstraction.

For instance, the public API could look like this:

	let urb = intf.urb_create()?;
	urb.fill_bulk(buffer, callback_fn, ...)?;
	urb.submit();

The urb_create() method of a usb::Interface can derive the struct usb_device
from the struct usb_interface internally and store it in the Urb structure, i.e.
no need to let drivers mess with this.

So, I think for this part it makes more sense to first work out the other
APIs before exposing things speculatively.

I also just spotted this:

	impl<Ctx: device::DeviceContext> AsRef<Device<Ctx>> for Interface<Ctx> {
	    fn as_ref(&self) -> &Device<Ctx> {
	        // SAFETY: `self.as_raw()` is valid by the type invariants. For a valid interface,
	        // the helper should always return a valid USB device pointer.
	        let usb_dev = unsafe { bindings::interface_to_usbdev(self.as_raw()) };
	
	        // SAFETY: The helper returns a valid interface pointer that shares the
	        // same `DeviceContext`.
	        unsafe { &*(usb_dev.cast()) }
	    }
	}

which I think is wrong. You can't derive the device context of a usb::Interface
for a usb::Device generically. You probably can for the Bound context, but not
for the Core context.

But honestly, I'm even unsure for the Bound context.

@Greg: Can we guarantee that a struct usb_device is always bound as long as one
of its interfaces is still bound?

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Greg Kroah-Hartman]

On Tue, Sep 23, 2025 at 04:03:01PM +0200, Danilo Krummrich wrote:
> On Tue Sep 23, 2025 at 3:31 PM CEST, Daniel Almeida wrote:
> >>> +/// A USB device.
> >>> +///
> >>> +/// This structure represents the Rust abstraction for a C [`struct usb_device`].
> >>> +/// The implementation abstracts the usage of a C [`struct usb_device`] passed in
> >>> +/// from the C side.
> >>> +///
> >>> +/// # Invariants
> >>> +///
> >>> +/// A [`Device`] instance represents a valid [`struct usb_device`] created by the C portion of the
> >>> +/// kernel.
> >>> +///
> >>> +/// [`struct usb_device`]: https://www.kernel.org/doc/html/latest/driver-api/usb/usb.html#c.usb_device
> >>> +#[repr(transparent)]
> >>> +pub struct Device<Ctx: device::DeviceContext = device::Normal>(
> >>> +    Opaque<bindings::usb_device>,
> >>> +    PhantomData<Ctx>,
> >>> +);
> >> 
> >> What do you use the struct usb_device abstraction for? I only see the sample
> >> driver probing a USB interface instead.
> >
> > What I was brainstorming with Greg is to submit this initial support, and then
> > follow up with all the other abstractions needed to implement a Rust version of
> > usb-skeleton.c. IIUC, the plan is to submit any fixes as follow-ups, as we're
> > close to the merge window.
> >
> > struct usb_device would be used for the skeleton driver, so we should keep it if
> > we're following the plan above, IMHO.
> 
> Yes, it's clearly required for the raw accessors for submitting URBs, e.g.
> usb_fill_bulk_urb(), usb_submit_urb(), etc.
> 
> But I'm not sure you actually have to expose a representation of a struct
> usb_device (with device context information) publically for that. It seems to me
> that this can all be contained within the abstraction.
> 
> For instance, the public API could look like this:
> 
> 	let urb = intf.urb_create()?;
> 	urb.fill_bulk(buffer, callback_fn, ...)?;
> 	urb.submit();
> 
> The urb_create() method of a usb::Interface can derive the struct usb_device
> from the struct usb_interface internally and store it in the Urb structure, i.e.
> no need to let drivers mess with this.
> 
> So, I think for this part it makes more sense to first work out the other
> APIs before exposing things speculatively.
> 
> I also just spotted this:
> 
> 	impl<Ctx: device::DeviceContext> AsRef<Device<Ctx>> for Interface<Ctx> {
> 	    fn as_ref(&self) -> &Device<Ctx> {
> 	        // SAFETY: `self.as_raw()` is valid by the type invariants. For a valid interface,
> 	        // the helper should always return a valid USB device pointer.
> 	        let usb_dev = unsafe { bindings::interface_to_usbdev(self.as_raw()) };
> 	
> 	        // SAFETY: The helper returns a valid interface pointer that shares the
> 	        // same `DeviceContext`.
> 	        unsafe { &*(usb_dev.cast()) }
> 	    }
> 	}
> 
> which I think is wrong. You can't derive the device context of a usb::Interface
> for a usb::Device generically. You probably can for the Bound context, but not
> for the Core context.
> 
> But honestly, I'm even unsure for the Bound context.
> 
> @Greg: Can we guarantee that a struct usb_device is always bound as long as one
> of its interfaces is still bound?

Bound to what?  It will always exist in the device "tree" as a valid
device as the interfaces are children of these "devices".  (hint, usb
is odd, we have "devices" and "interfaces", a device consists of 1-N
child interfaces, and a normal USB driver binds to an interface, not a
device.)

thanks,

greg k-h

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Danilo Krummrich]

On Tue Sep 23, 2025 at 4:30 PM CEST, Greg Kroah-Hartman wrote:
> On Tue, Sep 23, 2025 at 04:03:01PM +0200, Danilo Krummrich wrote:
>> On Tue Sep 23, 2025 at 3:31 PM CEST, Daniel Almeida wrote:
>> >>> +/// A USB device.
>> >>> +///
>> >>> +/// This structure represents the Rust abstraction for a C [`struct usb_device`].
>> >>> +/// The implementation abstracts the usage of a C [`struct usb_device`] passed in
>> >>> +/// from the C side.
>> >>> +///
>> >>> +/// # Invariants
>> >>> +///
>> >>> +/// A [`Device`] instance represents a valid [`struct usb_device`] created by the C portion of the
>> >>> +/// kernel.
>> >>> +///
>> >>> +/// [`struct usb_device`]: https://www.kernel.org/doc/html/latest/driver-api/usb/usb.html#c.usb_device
>> >>> +#[repr(transparent)]
>> >>> +pub struct Device<Ctx: device::DeviceContext = device::Normal>(
>> >>> +    Opaque<bindings::usb_device>,
>> >>> +    PhantomData<Ctx>,
>> >>> +);
>> >> 
>> >> What do you use the struct usb_device abstraction for? I only see the sample
>> >> driver probing a USB interface instead.
>> >
>> > What I was brainstorming with Greg is to submit this initial support, and then
>> > follow up with all the other abstractions needed to implement a Rust version of
>> > usb-skeleton.c. IIUC, the plan is to submit any fixes as follow-ups, as we're
>> > close to the merge window.
>> >
>> > struct usb_device would be used for the skeleton driver, so we should keep it if
>> > we're following the plan above, IMHO.
>> 
>> Yes, it's clearly required for the raw accessors for submitting URBs, e.g.
>> usb_fill_bulk_urb(), usb_submit_urb(), etc.
>> 
>> But I'm not sure you actually have to expose a representation of a struct
>> usb_device (with device context information) publically for that. It seems to me
>> that this can all be contained within the abstraction.
>> 
>> For instance, the public API could look like this:
>> 
>> 	let urb = intf.urb_create()?;
>> 	urb.fill_bulk(buffer, callback_fn, ...)?;
>> 	urb.submit();
>> 
>> The urb_create() method of a usb::Interface can derive the struct usb_device
>> from the struct usb_interface internally and store it in the Urb structure, i.e.
>> no need to let drivers mess with this.
>> 
>> So, I think for this part it makes more sense to first work out the other
>> APIs before exposing things speculatively.
>> 
>> I also just spotted this:
>> 
>> 	impl<Ctx: device::DeviceContext> AsRef<Device<Ctx>> for Interface<Ctx> {
>> 	    fn as_ref(&self) -> &Device<Ctx> {
>> 	        // SAFETY: `self.as_raw()` is valid by the type invariants. For a valid interface,
>> 	        // the helper should always return a valid USB device pointer.
>> 	        let usb_dev = unsafe { bindings::interface_to_usbdev(self.as_raw()) };
>> 	
>> 	        // SAFETY: The helper returns a valid interface pointer that shares the
>> 	        // same `DeviceContext`.
>> 	        unsafe { &*(usb_dev.cast()) }
>> 	    }
>> 	}
>> 
>> which I think is wrong. You can't derive the device context of a usb::Interface
>> for a usb::Device generically. You probably can for the Bound context, but not
>> for the Core context.
>> 
>> But honestly, I'm even unsure for the Bound context.
>> 
>> @Greg: Can we guarantee that a struct usb_device is always bound as long as one
>> of its interfaces is still bound?
>
> Bound to what?

Well, that's kinda my point. :)

Having a &usb::Device<Bound> would mean that for the lifetime of the reference
it is guaranteed that the usb::Device is bound to its USB device driver
(struct usb_device_driver).

The code above establishes that you can get a &usb::Device<Bound> from a
&usb::Interface<Bound>, i.e. an interface that is bound to a USB driver
(struct usb_driver).

It also does establish the same with other device contexts, such as the Core
context.

Despite the question whether this is sematically useful, I doubt that this is
a correct assumption to take.

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Greg Kroah-Hartman]

On Tue, Sep 23, 2025 at 04:38:34PM +0200, Danilo Krummrich wrote:
> On Tue Sep 23, 2025 at 4:30 PM CEST, Greg Kroah-Hartman wrote:
> > On Tue, Sep 23, 2025 at 04:03:01PM +0200, Danilo Krummrich wrote:
> >> On Tue Sep 23, 2025 at 3:31 PM CEST, Daniel Almeida wrote:
> >> >>> +/// A USB device.
> >> >>> +///
> >> >>> +/// This structure represents the Rust abstraction for a C [`struct usb_device`].
> >> >>> +/// The implementation abstracts the usage of a C [`struct usb_device`] passed in
> >> >>> +/// from the C side.
> >> >>> +///
> >> >>> +/// # Invariants
> >> >>> +///
> >> >>> +/// A [`Device`] instance represents a valid [`struct usb_device`] created by the C portion of the
> >> >>> +/// kernel.
> >> >>> +///
> >> >>> +/// [`struct usb_device`]: https://www.kernel.org/doc/html/latest/driver-api/usb/usb.html#c.usb_device
> >> >>> +#[repr(transparent)]
> >> >>> +pub struct Device<Ctx: device::DeviceContext = device::Normal>(
> >> >>> +    Opaque<bindings::usb_device>,
> >> >>> +    PhantomData<Ctx>,
> >> >>> +);
> >> >> 
> >> >> What do you use the struct usb_device abstraction for? I only see the sample
> >> >> driver probing a USB interface instead.
> >> >
> >> > What I was brainstorming with Greg is to submit this initial support, and then
> >> > follow up with all the other abstractions needed to implement a Rust version of
> >> > usb-skeleton.c. IIUC, the plan is to submit any fixes as follow-ups, as we're
> >> > close to the merge window.
> >> >
> >> > struct usb_device would be used for the skeleton driver, so we should keep it if
> >> > we're following the plan above, IMHO.
> >> 
> >> Yes, it's clearly required for the raw accessors for submitting URBs, e.g.
> >> usb_fill_bulk_urb(), usb_submit_urb(), etc.
> >> 
> >> But I'm not sure you actually have to expose a representation of a struct
> >> usb_device (with device context information) publically for that. It seems to me
> >> that this can all be contained within the abstraction.
> >> 
> >> For instance, the public API could look like this:
> >> 
> >> 	let urb = intf.urb_create()?;
> >> 	urb.fill_bulk(buffer, callback_fn, ...)?;
> >> 	urb.submit();
> >> 
> >> The urb_create() method of a usb::Interface can derive the struct usb_device
> >> from the struct usb_interface internally and store it in the Urb structure, i.e.
> >> no need to let drivers mess with this.
> >> 
> >> So, I think for this part it makes more sense to first work out the other
> >> APIs before exposing things speculatively.
> >> 
> >> I also just spotted this:
> >> 
> >> 	impl<Ctx: device::DeviceContext> AsRef<Device<Ctx>> for Interface<Ctx> {
> >> 	    fn as_ref(&self) -> &Device<Ctx> {
> >> 	        // SAFETY: `self.as_raw()` is valid by the type invariants. For a valid interface,
> >> 	        // the helper should always return a valid USB device pointer.
> >> 	        let usb_dev = unsafe { bindings::interface_to_usbdev(self.as_raw()) };
> >> 	
> >> 	        // SAFETY: The helper returns a valid interface pointer that shares the
> >> 	        // same `DeviceContext`.
> >> 	        unsafe { &*(usb_dev.cast()) }
> >> 	    }
> >> 	}
> >> 
> >> which I think is wrong. You can't derive the device context of a usb::Interface
> >> for a usb::Device generically. You probably can for the Bound context, but not
> >> for the Core context.
> >> 
> >> But honestly, I'm even unsure for the Bound context.
> >> 
> >> @Greg: Can we guarantee that a struct usb_device is always bound as long as one
> >> of its interfaces is still bound?
> >
> > Bound to what?
> 
> Well, that's kinda my point. :)
> 
> Having a &usb::Device<Bound> would mean that for the lifetime of the reference
> it is guaranteed that the usb::Device is bound to its USB device driver
> (struct usb_device_driver).

Wait, usb_device_driver shouldn't be used here, that's only for
"special" things like hubs and an odd Apple device.

> The code above establishes that you can get a &usb::Device<Bound> from a
> &usb::Interface<Bound>, i.e. an interface that is bound to a USB driver
> (struct usb_driver).

Interfaces are bound to usb_driver, and are a child device of a struct
usb_device.  There is no need to worry if a driver is bound to a struct
usb_device at any time, it should be independent if a driver is bound to
a struct interface.  All that we should care about is the driver that is
bound to a usb_interface as that is what the rust binding should be for
here.

Sorry for the naming confusion, usb is messy in places.

thanks,

greg k-h

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Danilo Krummrich]

On 9/23/25 4:52 PM, Greg Kroah-Hartman wrote:
>> Having a &usb::Device<Bound> would mean that for the lifetime of the reference
>> it is guaranteed that the usb::Device is bound to its USB device driver
>> (struct usb_device_driver).
> 
> Wait, usb_device_driver shouldn't be used here, that's only for
> "special" things like hubs and an odd Apple device.

I only mentioned it because if a struct usb_device is bound, then it is bound to
a struct usb_device_driver.

And because we're not doing this, I doubt that a *public* usb::Device
abstraction is required (at least for now).

The cases where we need a struct usb_device for operations on USB interface
(such as usb_fill_bulk_urb(), usb_submit_urb(), etc.) can be dealt with
internally in the abstraction itself, such that drivers only need to know about
the interface.

So, I wouldn't expose it just yet. If we see that further down the road we need
usb_interface drivers to mess with the usb_device directly for some reason, we
can still expose it.

>> The code above establishes that you can get a &usb::Device<Bound> from a
>> &usb::Interface<Bound>, i.e. an interface that is bound to a USB driver
>> (struct usb_driver).
> 
> Interfaces are bound to usb_driver, and are a child device of a struct
> usb_device.  There is no need to worry if a driver is bound to a struct
> usb_device at any time, it should be independent if a driver is bound to
> a struct interface.  All that we should care about is the driver that is
> bound to a usb_interface as that is what the rust binding should be for
> here.

Right, that's why I said I doubt that it is semantically useful to derive a
&usb::Device<Bound> from a &usb::Interface<Bound> or a &usb::Device<Core> from a
&usb::Interface<Core>.

But besides that I also think it's also just wrong, so we should remove the
corresponding code.

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Alan Stern]

On Tue, Sep 23, 2025 at 04:38:34PM +0200, Danilo Krummrich wrote:
> >> @Greg: Can we guarantee that a struct usb_device is always bound as long as one
> >> of its interfaces is still bound?
> >
> > Bound to what?
> 
> Well, that's kinda my point. :)
> 
> Having a &usb::Device<Bound> would mean that for the lifetime of the reference
> it is guaranteed that the usb::Device is bound to its USB device driver
> (struct usb_device_driver).
> 
> The code above establishes that you can get a &usb::Device<Bound> from a
> &usb::Interface<Bound>, i.e. an interface that is bound to a USB driver
> (struct usb_driver).
> 
> It also does establish the same with other device contexts, such as the Core
> context.
> 
> Despite the question whether this is sematically useful, I doubt that this is
> a correct assumption to take.

The intention of the USB stack is that yes, a usb_device cannot have 
children if it isn't bound to a usb_device_driver.  However, we don't 
try to guarantee that this is true; a particular driver might not 
enforce this restriction.

There is a surprisingly large number of calls to 
usb_register_device_driver() in the kernel (four in addition to the 
standard one).  I suppose a little auditing could ensure that these 
drivers do deconfigure their devices when they unbind.

Alan Stern

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Greg Kroah-Hartman]

On Tue, Sep 23, 2025 at 03:21:09PM +0200, Danilo Krummrich wrote:
> On Mon Aug 25, 2025 at 8:18 PM CEST, Daniel Almeida wrote:
> > +/// The USB driver trait.
> > +///
> > +/// # Examples
> > +///
> > +///```
> > +/// # use kernel::{bindings, device::Core, usb};
> > +/// use kernel::prelude::*;
> > +///
> > +/// struct MyDriver;
> > +///
> > +/// kernel::usb_device_table!(
> > +///     USB_TABLE,
> > +///     MODULE_USB_TABLE,
> > +///     <MyDriver as usb::Driver>::IdInfo,
> > +///     [
> > +///         (usb::DeviceId::from_id(0x1234, 0x5678), ()),
> > +///         (usb::DeviceId::from_id(0xabcd, 0xef01), ()),
> > +///     ]
> > +/// );
> > +///
> > +/// impl usb::Driver for MyDriver {
> > +///     type IdInfo = ();
> > +///     const ID_TABLE: usb::IdTable<Self::IdInfo> = &USB_TABLE;
> > +///
> > +///     fn probe(
> > +///         _interface: &usb::Interface<Core>,
> > +///         _id: &usb::DeviceId,
> > +///         _info: &Self::IdInfo,
> > +///     ) -> Result<Pin<KBox<Self>>> {
> > +///         Err(ENODEV)
> > +///     }
> > +///
> > +///     fn disconnect(_interface: &usb::Interface<Core>, _data: Pin<&Self>) {}
> > +/// }
> > +///```
> > +pub trait Driver {
> > +    /// The type holding information about each one of the device ids supported by the driver.
> > +    type IdInfo: 'static;
> > +
> > +    /// The table of device ids supported by the driver.
> > +    const ID_TABLE: IdTable<Self::IdInfo>;
> > +
> > +    /// USB driver probe.
> > +    ///
> > +    /// Called when a new USB interface is bound to this driver.
> > +    /// Implementers should attempt to initialize the interface here.
> > +    fn probe(
> > +        interface: &Interface<device::Core>,
> > +        id: &DeviceId,
> > +        id_info: &Self::IdInfo,
> > +    ) -> Result<Pin<KBox<Self>>>;
> > +
> > +    /// USB driver disconnect.
> > +    ///
> > +    /// Called when the USB interface is about to be unbound from this driver.
> > +    fn disconnect(interface: &Interface<device::Core>, data: Pin<&Self>);
> 
> I think this callback should be optional, like all the other unbind() we have in
> other busses.
> 
> @Greg: Why is this called disconnect() in the C code instead of remove()?

I don't know, naming is hard, and it was the first, or second, user of
the driver model we ever created :)

> For Rust, I feel like we should align to the unbind() terminology we use
> everywhere else (for the same reasons we chose unbind() over remove() for other
> busses as well).
> 
> We went with unbind(), since the "raw" remove() (or disconnect()) callback does
> more, i.e. it first calls into unbind() and then drops the driver's private data
> for this specific device.
> 
> So, the unbind() callback that goes to the driver is only meant as a place for
> drivers to perform operations to tear down the device. Resources are freed
> subsequently when the driver's private data is dropped.

Yes, we should probably match these up with what PCI does here in the
end, that would be good.

> > +/// A USB device.
> > +///
> > +/// This structure represents the Rust abstraction for a C [`struct usb_device`].
> > +/// The implementation abstracts the usage of a C [`struct usb_device`] passed in
> > +/// from the C side.
> > +///
> > +/// # Invariants
> > +///
> > +/// A [`Device`] instance represents a valid [`struct usb_device`] created by the C portion of the
> > +/// kernel.
> > +///
> > +/// [`struct usb_device`]: https://www.kernel.org/doc/html/latest/driver-api/usb/usb.html#c.usb_device
> > +#[repr(transparent)]
> > +pub struct Device<Ctx: device::DeviceContext = device::Normal>(
> > +    Opaque<bindings::usb_device>,
> > +    PhantomData<Ctx>,
> > +);
> 
> What do you use the struct usb_device abstraction for? I only see the sample
> driver probing a USB interface instead.

Functions like usb_fill_bulk_urb() takes a pointer to a usb_device, not
an interface.  Yes, we should fix that, but that "mistake" dates way way
way back to the original USB api decades ago.  So much so that I didn't
even remember that we used that pointer there :)

So it's ok to wrap this for now, it will be needed.

thanks,

greg k-h

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Oliver Neukum]

On 23.09.25 16:13, Greg Kroah-Hartman wrote:

> Functions like usb_fill_bulk_urb() takes a pointer to a usb_device, not
> an interface.  Yes, we should fix that, but that "mistake" dates way way
> way back to the original USB api decades ago.  So much so that I didn't
> even remember that we used that pointer there :)

How would we do that? We need to be able to send at least control
request to devices before we have established which configurations
or interfaces the device has.

	Regards
		Oliver

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Greg Kroah-Hartman]

On Tue, Sep 23, 2025 at 04:16:36PM +0200, Oliver Neukum wrote:
> On 23.09.25 16:13, Greg Kroah-Hartman wrote:
> 
> > Functions like usb_fill_bulk_urb() takes a pointer to a usb_device, not
> > an interface.  Yes, we should fix that, but that "mistake" dates way way
> > way back to the original USB api decades ago.  So much so that I didn't
> > even remember that we used that pointer there :)
> 
> How would we do that? We need to be able to send at least control
> request to devices before we have established which configurations
> or interfaces the device has.

Oops, I thought that usb_dev in struct usb_interface was a pointer to
struct usb_device, but no, it's something else...  So no, we need to
keep that as-is for now.

thanks,

greg k-h

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Danilo Krummrich]

On 9/23/25 4:22 PM, Greg Kroah-Hartman wrote:
> On Tue, Sep 23, 2025 at 04:16:36PM +0200, Oliver Neukum wrote:
>> On 23.09.25 16:13, Greg Kroah-Hartman wrote:
>>
>>> Functions like usb_fill_bulk_urb() takes a pointer to a usb_device, not
>>> an interface.  Yes, we should fix that, but that "mistake" dates way way
>>> way back to the original USB api decades ago.  So much so that I didn't
>>> even remember that we used that pointer there :)
>>
>> How would we do that? We need to be able to send at least control
>> request to devices before we have established which configurations
>> or interfaces the device has.
> 
> Oops, I thought that usb_dev in struct usb_interface was a pointer to
> struct usb_device, but no, it's something else...  So no, we need to
> keep that as-is for now.

You can still get it via interface_to_usbdev(), no?

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Greg Kroah-Hartman]

On Tue, Sep 23, 2025 at 04:25:46PM +0200, Danilo Krummrich wrote:
> On 9/23/25 4:22 PM, Greg Kroah-Hartman wrote:
> > On Tue, Sep 23, 2025 at 04:16:36PM +0200, Oliver Neukum wrote:
> >> On 23.09.25 16:13, Greg Kroah-Hartman wrote:
> >>
> >>> Functions like usb_fill_bulk_urb() takes a pointer to a usb_device, not
> >>> an interface.  Yes, we should fix that, but that "mistake" dates way way
> >>> way back to the original USB api decades ago.  So much so that I didn't
> >>> even remember that we used that pointer there :)
> >>
> >> How would we do that? We need to be able to send at least control
> >> request to devices before we have established which configurations
> >> or interfaces the device has.
> > 
> > Oops, I thought that usb_dev in struct usb_interface was a pointer to
> > struct usb_device, but no, it's something else...  So no, we need to
> > keep that as-is for now.
> 
> You can still get it via interface_to_usbdev(), no?

Sigh, this is what I get for writing emails while sitting in a
conference...

Yes, you are right, it can be gotten that way.  But I can't wait to see
how you wrap that C macro in rust :)

thanks,

greg k-h

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Danilo Krummrich]

On 9/23/25 4:37 PM, Greg Kroah-Hartman wrote:
> Yes, you are right, it can be gotten that way.  But I can't wait to see
> how you wrap that C macro in rust :)

We can either create a Rust helper function for it, or just re-implement it; in
the end it boils down to just a container_of() on the parent device.

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Greg Kroah-Hartman]

On Tue, Sep 23, 2025 at 04:42:11PM +0200, Danilo Krummrich wrote:
> On 9/23/25 4:37 PM, Greg Kroah-Hartman wrote:
> > Yes, you are right, it can be gotten that way.  But I can't wait to see
> > how you wrap that C macro in rust :)
> 
> We can either create a Rust helper function for it, or just re-implement it; in
> the end it boils down to just a container_of() on the parent device.

Yes, and it preserves the "const" of the pointer going into the function
call, can we do that in rust as well?

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Danilo Krummrich]

On Tue Sep 23, 2025 at 4:49 PM CEST, Greg Kroah-Hartman wrote:
> On Tue, Sep 23, 2025 at 04:42:11PM +0200, Danilo Krummrich wrote:
>> On 9/23/25 4:37 PM, Greg Kroah-Hartman wrote:
>> > Yes, you are right, it can be gotten that way.  But I can't wait to see
>> > how you wrap that C macro in rust :)
>> 
>> We can either create a Rust helper function for it, or just re-implement it; in
>> the end it boils down to just a container_of() on the parent device.
>
> Yes, and it preserves the "const" of the pointer going into the function
> call, can we do that in rust as well?

Yes, the Rust container_of!() macro should preserve that.

But despite that, I think it doesn't matter too much in this specific case.

Abstractions of C structures are usually contained within the kernel's Opaque<T>
type, which allows for interior mutability.

Actual mutability is controlled by the corresponding abstraction around the
Opaque<T>.

For instance, a struct device representation looks like this:

	 struct Device<Ctx: DeviceContext = Normal>(Opaque<bindings::device>, PhantomData<Ctx>);

In this case, we never give out a mutable reference to a Device, but rather
control mutability internally with the help of the device context.

For instance, if we have a &Device<Core>, we're guranteed that we're called from
a context where the device_lock() is guaranteed to be held, so we can allow for
some interior mutability.

Re: [PATCH 1/2] rust: usb: add basic USB abstractions

[Danilo Krummrich]

On 9/23/25 4:13 PM, Greg Kroah-Hartman wrote:
> Functions like usb_fill_bulk_urb() takes a pointer to a usb_device, not
> an interface.
Yes, I'm aware, please see my reply [1] regarding that.

[1] https://lore.kernel.org/all/DD08HWM0M68R.2R74OSODBIWSZ@kernel.org/

[PATCH 2/2] samples: rust: add a USB driver sample

[Daniel Almeida]

In light of the newly-added Rust abstractions for USB devices and
drivers, add a sample USB rust driver that serves both to showcase what
is currently supported, as well as be the only user of the USB
abstractions for now.

Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
---
 samples/rust/Kconfig            | 11 ++++++++++
 samples/rust/Makefile           |  1 +
 samples/rust/rust_driver_usb.rs | 47 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 59 insertions(+)

diff --git a/samples/rust/Kconfig b/samples/rust/Kconfig
index 7f7371a004ee0a8f67dca99c836596709a70c4fa..fb222f93014c921b27a8a9a4293e90a2532faa82 100644
--- a/samples/rust/Kconfig
+++ b/samples/rust/Kconfig
@@ -83,6 +83,17 @@ config SAMPLE_RUST_DRIVER_PLATFORM
 
 	  If unsure, say N.
 
+config SAMPLE_RUST_DRIVER_USB
+	tristate "USB Driver"
+	depends on USB
+	help
+	  This option builds the Rust USB driver sample.
+
+	  To compile this as a module, choose M here:
+	  the module will be called rust_driver_usb.
+
+	  If unsure, say N.
+
 config SAMPLE_RUST_DRIVER_FAUX
 	tristate "Faux Driver"
 	help
diff --git a/samples/rust/Makefile b/samples/rust/Makefile
index bd2faad63b4f3befe7d1ed5139fe25c7a8b6d7f6..4e7df8a5cd277d101920c4b89a3ac6648b372b28 100644
--- a/samples/rust/Makefile
+++ b/samples/rust/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_SAMPLE_RUST_PRINT)			+= rust_print.o
 obj-$(CONFIG_SAMPLE_RUST_DMA)			+= rust_dma.o
 obj-$(CONFIG_SAMPLE_RUST_DRIVER_PCI)		+= rust_driver_pci.o
 obj-$(CONFIG_SAMPLE_RUST_DRIVER_PLATFORM)	+= rust_driver_platform.o
+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
diff --git a/samples/rust/rust_driver_usb.rs b/samples/rust/rust_driver_usb.rs
new file mode 100644
index 0000000000000000000000000000000000000000..5c396f421de7f972985e57af48e8a9da0c558973
--- /dev/null
+++ b/samples/rust/rust_driver_usb.rs
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0
+// SPDX-FileCopyrightText: Copyright (C) 2025 Collabora Ltd.
+
+//! Rust USB driver sample.
+
+use kernel::{device, device::Core, prelude::*, sync::aref::ARef, usb};
+
+struct SampleDriver {
+    _intf: ARef<usb::Interface>,
+}
+
+kernel::usb_device_table!(
+    USB_TABLE,
+    MODULE_USB_TABLE,
+    <SampleDriver as usb::Driver>::IdInfo,
+    [(usb::DeviceId::from_id(0x1234, 0x5678), ()),]
+);
+
+impl usb::Driver for SampleDriver {
+    type IdInfo = ();
+    const ID_TABLE: usb::IdTable<Self::IdInfo> = &USB_TABLE;
+
+    fn probe(
+        intf: &usb::Interface<Core>,
+        _id: &usb::DeviceId,
+        _info: &Self::IdInfo,
+    ) -> Result<Pin<KBox<Self>>> {
+        let dev: &device::Device<Core> = intf.as_ref();
+        dev_info!(dev, "Rust USB driver sample probed\n");
+
+        let drvdata = KBox::new(Self { _intf: intf.into() }, GFP_KERNEL)?;
+        Ok(drvdata.into())
+    }
+
+    fn disconnect(intf: &usb::Interface<Core>, _data: Pin<&Self>) {
+        let dev: &device::Device<Core> = intf.as_ref();
+        dev_info!(dev, "Rust USB driver sample disconnected\n");
+    }
+}
+
+kernel::module_usb_driver! {
+    type: SampleDriver,
+    name: "rust_driver_usb",
+    authors: ["Daniel Almeida"],
+    description: "Rust USB driver sample",
+    license: "GPL v2",
+}

-- 
2.50.1

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Greg Kroah-Hartman]

On Mon, Aug 25, 2025 at 03:18:06PM -0300, Daniel Almeida wrote:
> In light of the newly-added Rust abstractions for USB devices and
> drivers, add a sample USB rust driver that serves both to showcase what
> is currently supported, as well as be the only user of the USB
> abstractions for now.
> 
> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
> ---
>  samples/rust/Kconfig            | 11 ++++++++++
>  samples/rust/Makefile           |  1 +
>  samples/rust/rust_driver_usb.rs | 47 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 59 insertions(+)
> 
> diff --git a/samples/rust/Kconfig b/samples/rust/Kconfig
> index 7f7371a004ee0a8f67dca99c836596709a70c4fa..fb222f93014c921b27a8a9a4293e90a2532faa82 100644
> --- a/samples/rust/Kconfig
> +++ b/samples/rust/Kconfig
> @@ -83,6 +83,17 @@ config SAMPLE_RUST_DRIVER_PLATFORM
>  
>  	  If unsure, say N.
>  
> +config SAMPLE_RUST_DRIVER_USB
> +	tristate "USB Driver"
> +	depends on USB
> +	help
> +	  This option builds the Rust USB driver sample.
> +
> +	  To compile this as a module, choose M here:
> +	  the module will be called rust_driver_usb.
> +
> +	  If unsure, say N.
> +
>  config SAMPLE_RUST_DRIVER_FAUX
>  	tristate "Faux Driver"
>  	help
> diff --git a/samples/rust/Makefile b/samples/rust/Makefile
> index bd2faad63b4f3befe7d1ed5139fe25c7a8b6d7f6..4e7df8a5cd277d101920c4b89a3ac6648b372b28 100644
> --- a/samples/rust/Makefile
> +++ b/samples/rust/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_SAMPLE_RUST_PRINT)			+= rust_print.o
>  obj-$(CONFIG_SAMPLE_RUST_DMA)			+= rust_dma.o
>  obj-$(CONFIG_SAMPLE_RUST_DRIVER_PCI)		+= rust_driver_pci.o
>  obj-$(CONFIG_SAMPLE_RUST_DRIVER_PLATFORM)	+= rust_driver_platform.o
> +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
> diff --git a/samples/rust/rust_driver_usb.rs b/samples/rust/rust_driver_usb.rs
> new file mode 100644
> index 0000000000000000000000000000000000000000..5c396f421de7f972985e57af48e8a9da0c558973
> --- /dev/null
> +++ b/samples/rust/rust_driver_usb.rs
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// SPDX-FileCopyrightText: Copyright (C) 2025 Collabora Ltd.
> +
> +//! Rust USB driver sample.
> +
> +use kernel::{device, device::Core, prelude::*, sync::aref::ARef, usb};
> +
> +struct SampleDriver {
> +    _intf: ARef<usb::Interface>,
> +}
> +
> +kernel::usb_device_table!(
> +    USB_TABLE,
> +    MODULE_USB_TABLE,
> +    <SampleDriver as usb::Driver>::IdInfo,
> +    [(usb::DeviceId::from_id(0x1234, 0x5678), ()),]
> +);
> +
> +impl usb::Driver for SampleDriver {
> +    type IdInfo = ();
> +    const ID_TABLE: usb::IdTable<Self::IdInfo> = &USB_TABLE;
> +
> +    fn probe(
> +        intf: &usb::Interface<Core>,
> +        _id: &usb::DeviceId,
> +        _info: &Self::IdInfo,
> +    ) -> Result<Pin<KBox<Self>>> {
> +        let dev: &device::Device<Core> = intf.as_ref();
> +        dev_info!(dev, "Rust USB driver sample probed\n");
> +
> +        let drvdata = KBox::new(Self { _intf: intf.into() }, GFP_KERNEL)?;
> +        Ok(drvdata.into())
> +    }
> +
> +    fn disconnect(intf: &usb::Interface<Core>, _data: Pin<&Self>) {
> +        let dev: &device::Device<Core> = intf.as_ref();
> +        dev_info!(dev, "Rust USB driver sample disconnected\n");
> +    }
> +}
> +
> +kernel::module_usb_driver! {
> +    type: SampleDriver,
> +    name: "rust_driver_usb",
> +    authors: ["Daniel Almeida"],
> +    description: "Rust USB driver sample",
> +    license: "GPL v2",
> +}

Sorry for the delay.

But these bindings really are only for a usb interface probe/disconnect
sequence, right?  no real data flow at all?

I recommend looking at the usb-skeleton.c driver, and implementing that
as your sample driver for rust.  That will ensure that you actually have
the correct apis implemented and the reference count logic working
properly.  You have urb anchors and callbacks and other stuff as well to
ensure that you get right.  That driver pretty much should handle
everything that you need to do to write a usb driver for any type of
"real" device.

thanks,

greg k-h

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Daniel Almeida]

Hi Greg,

[…]

> 
> Sorry for the delay.
> 
> But these bindings really are only for a usb interface probe/disconnect
> sequence, right?  no real data flow at all?
> 
> I recommend looking at the usb-skeleton.c driver, and implementing that
> as your sample driver for rust.  That will ensure that you actually have
> the correct apis implemented and the reference count logic working
> properly.  You have urb anchors and callbacks and other stuff as well to
> ensure that you get right.  That driver pretty much should handle
> everything that you need to do to write a usb driver for any type of
> "real" device.
> 
> thanks,
> 
> greg k-h


I thought that an iterative approach would work here, i.e.: merge this, then
URBs, then more stuff, etc.

In any case that’s OK. I will work on the other stuff you listed here.

— Daniel

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Greg Kroah-Hartman]

On Sat, Sep 06, 2025 at 09:04:04AM -0300, Daniel Almeida wrote:
> Hi Greg,
> 
> […]
> 
> > 
> > Sorry for the delay.
> > 
> > But these bindings really are only for a usb interface probe/disconnect
> > sequence, right?  no real data flow at all?
> > 
> > I recommend looking at the usb-skeleton.c driver, and implementing that
> > as your sample driver for rust.  That will ensure that you actually have
> > the correct apis implemented and the reference count logic working
> > properly.  You have urb anchors and callbacks and other stuff as well to
> > ensure that you get right.  That driver pretty much should handle
> > everything that you need to do to write a usb driver for any type of
> > "real" device.
> > 
> > thanks,
> > 
> > greg k-h
> 
> 
> I thought that an iterative approach would work here, i.e.: merge this, then
> URBs, then more stuff, etc.

Ah, that makes sense, I didn't realize you want that here.  What USB
device do you want to write a rust driver for?  Are you going to need
bindings to the usb major number, or is it going to talk to some other
subsystem instead?

Right now, these bindings don't really do anything USB specific at all
except allow a driver to bind to a device.

thanks,

greg k-h

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Daniel Almeida]

>> 
>> I thought that an iterative approach would work here, i.e.: merge this, then
>> URBs, then more stuff, etc.
> 
> Ah, that makes sense, I didn't realize you want that here.  What USB
> device do you want to write a rust driver for?  Are you going to need
> bindings to the usb major number, or is it going to talk to some other
> subsystem instead?
> 
> Right now, these bindings don't really do anything USB specific at all
> except allow a driver to bind to a device.
> 
> thanks,
> 
> greg k-h

To be honest, I'm trying to pave the way for others.

I often hear people saying that they would look into Rust drivers if only they
did not have to write all the surrounding infrastructure themselves. On the
other hand, there is no infrastructure because there are no drivers. It's a
chicken and egg problem that I am trying to solve.

It's also a cool opportunity to learn about USB, but I don't have any plans
for a driver at the moment other than a instructional sample driver in Rust.

Give me a few more weeks and I'll come up with the code for the other things
you've pointed out.

By the way, I wonder how testing would work. I tested this by plugging in my
mouse and fiddling around with /sys/bus/usb/drivers/rust_driver_usb/new_id. I
am not sure how this is going to work once I start looking into data transfer
and etc. Perhaps there's a simple device out there that I should target? Or
maybe there's a way to "fake" a USB device that would work with the sample
driver for demonstration purposes.

-- Daniel

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Greg Kroah-Hartman]

On Sat, Sep 06, 2025 at 09:41:16AM -0300, Daniel Almeida wrote:
> 
> 
> >> 
> >> I thought that an iterative approach would work here, i.e.: merge this, then
> >> URBs, then more stuff, etc.
> > 
> > Ah, that makes sense, I didn't realize you want that here.  What USB
> > device do you want to write a rust driver for?  Are you going to need
> > bindings to the usb major number, or is it going to talk to some other
> > subsystem instead?
> > 
> > Right now, these bindings don't really do anything USB specific at all
> > except allow a driver to bind to a device.
> > 
> > thanks,
> > 
> > greg k-h
> 
> To be honest, I'm trying to pave the way for others.
> 
> I often hear people saying that they would look into Rust drivers if only they
> did not have to write all the surrounding infrastructure themselves. On the
> other hand, there is no infrastructure because there are no drivers. It's a
> chicken and egg problem that I am trying to solve.

Sure, but a framework like this (probe/disconnect), really isn't USB,
it's just driver core stuff :)

> It's also a cool opportunity to learn about USB, but I don't have any plans
> for a driver at the moment other than a instructional sample driver in Rust.

Then let's not add bindings without a real user please.  We don't want
to maintain them for no good reason.

> Give me a few more weeks and I'll come up with the code for the other things
> you've pointed out.
> 
> By the way, I wonder how testing would work. I tested this by plugging in my
> mouse and fiddling around with /sys/bus/usb/drivers/rust_driver_usb/new_id. I
> am not sure how this is going to work once I start looking into data transfer
> and etc. Perhaps there's a simple device out there that I should target? Or
> maybe there's a way to "fake" a USB device that would work with the sample
> driver for demonstration purposes.

You can use the usb-gadget subsystem and dummy-hcd to create a loop-back
for a virtual USB device.  That's how syzbot does USB driver fuzz
testing, there should be some documentation on that somewhere in the
tree.

thanks

greg k-h

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Alan Stern]

On Sat, Sep 06, 2025 at 03:07:16PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Sep 06, 2025 at 09:41:16AM -0300, Daniel Almeida wrote:
> > By the way, I wonder how testing would work. I tested this by plugging in my
> > mouse and fiddling around with /sys/bus/usb/drivers/rust_driver_usb/new_id. I
> > am not sure how this is going to work once I start looking into data transfer
> > and etc. Perhaps there's a simple device out there that I should target? Or
> > maybe there's a way to "fake" a USB device that would work with the sample
> > driver for demonstration purposes.
> 
> You can use the usb-gadget subsystem and dummy-hcd to create a loop-back
> for a virtual USB device.  That's how syzbot does USB driver fuzz
> testing, there should be some documentation on that somewhere in the
> tree.

Gadget zero is a good one to use for testing.  That's what it's meant 
for.  If you need any help setting it up, just ask.

Alan Stern

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Daniel Almeida]

> On 6 Sep 2025, at 10:07, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> On Sat, Sep 06, 2025 at 09:41:16AM -0300, Daniel Almeida wrote:
>> 
>> 
>>>> 
>>>> I thought that an iterative approach would work here, i.e.: merge this, then
>>>> URBs, then more stuff, etc.
>>> 
>>> Ah, that makes sense, I didn't realize you want that here.  What USB
>>> device do you want to write a rust driver for?  Are you going to need
>>> bindings to the usb major number, or is it going to talk to some other
>>> subsystem instead?
>>> 
>>> Right now, these bindings don't really do anything USB specific at all
>>> except allow a driver to bind to a device.
>>> 
>>> thanks,
>>> 
>>> greg k-h
>> 
>> To be honest, I'm trying to pave the way for others.
>> 
>> I often hear people saying that they would look into Rust drivers if only they
>> did not have to write all the surrounding infrastructure themselves. On the
>> other hand, there is no infrastructure because there are no drivers. It's a
>> chicken and egg problem that I am trying to solve.
> 
> Sure, but a framework like this (probe/disconnect), really isn't USB,
> it's just driver core stuff :)
> 
>> It's also a cool opportunity to learn about USB, but I don't have any plans
>> for a driver at the moment other than a instructional sample driver in Rust.
> 
> Then let's not add bindings without a real user please.  We don't want
> to maintain them for no good reason.
> 

That’s OK Greg, I totally see your point here. I guess we can shelve this
work for the time being then.

To everybody else: if anyone is willing to write USB drivers, let me know. I
will work with you to get the abstractions in place so that we have both the
abstractions and a real user.

-- Daniel

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Danilo Krummrich]

On Sat Sep 6, 2025 at 2:41 PM CEST, Daniel Almeida wrote:
>>> 
>>> I thought that an iterative approach would work here, i.e.: merge this, then
>>> URBs, then more stuff, etc.
>> 
>> Ah, that makes sense, I didn't realize you want that here.  What USB
>> device do you want to write a rust driver for?  Are you going to need
>> bindings to the usb major number, or is it going to talk to some other
>> subsystem instead?
>> 
>> Right now, these bindings don't really do anything USB specific at all
>> except allow a driver to bind to a device.
>> 
>> thanks,
>> 
>> greg k-h
>
> To be honest, I'm trying to pave the way for others.
>
> I often hear people saying that they would look into Rust drivers if only they
> did not have to write all the surrounding infrastructure themselves. On the
> other hand, there is no infrastructure because there are no drivers.

I think saying that there is no infrastructure for writing Rust drivers is not
accurate:

We already have lots of infrastructure in place, such as device / driver core
infrastructure, PCI, platform (with OF and ACPI), faux and auxilirary bus
infrastructure, I/O, workqueues, timekeeping, cpufreq, firmware, DMA and a lot
more.

Not to forget the absolute core primitives, such as kernel allocators, xarray,
locking infrastructure or very recently maple tree and LKMM atomics.

Besides that we also have a lot of infrastructure that we do not have in C
because it's simply not possible or applicable.

However, it is in fact true that there is no USB infrastructure yet.

> It's a chicken and egg problem that I am trying to solve.

This is exactly why we develop Nova in-tree, such that we have a justification
for adding all this infrastructure.

Lot's of the stuff I listed above originates from that and I think the Nova
project has proven that we can break this chicken and egg problem. I think
one proof for that is that Tyr follows the approach.

However, I agree that it still remains that someone (i.e. some driver) has to
take the burden of doing the "heavy lifting" for a particular subsystem.

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Daniel Almeida]

Hi Danilo,

> On 6 Sep 2025, at 10:22, Danilo Krummrich <dakr@kernel.org> wrote:
> 
> On Sat Sep 6, 2025 at 2:41 PM CEST, Daniel Almeida wrote:
>>>> 
>>>> I thought that an iterative approach would work here, i.e.: merge this, then
>>>> URBs, then more stuff, etc.
>>> 
>>> Ah, that makes sense, I didn't realize you want that here.  What USB
>>> device do you want to write a rust driver for?  Are you going to need
>>> bindings to the usb major number, or is it going to talk to some other
>>> subsystem instead?
>>> 
>>> Right now, these bindings don't really do anything USB specific at all
>>> except allow a driver to bind to a device.
>>> 
>>> thanks,
>>> 
>>> greg k-h
>> 
>> To be honest, I'm trying to pave the way for others.
>> 
>> I often hear people saying that they would look into Rust drivers if only they
>> did not have to write all the surrounding infrastructure themselves. On the
>> other hand, there is no infrastructure because there are no drivers.
> 
> I think saying that there is no infrastructure for writing Rust drivers is not
> accurate:
> 
> We already have lots of infrastructure in place, such as device / driver core
> infrastructure, PCI, platform (with OF and ACPI), faux and auxilirary bus
> infrastructure, I/O, workqueues, timekeeping, cpufreq, firmware, DMA and a lot
> more.
> 
> Not to forget the absolute core primitives, such as kernel allocators, xarray,
> locking infrastructure or very recently maple tree and LKMM atomics.
> 
> Besides that we also have a lot of infrastructure that we do not have in C
> because it's simply not possible or applicable.
> 
> However, it is in fact true that there is no USB infrastructure yet.

Ah yes, of course there’s plenty of things but this is specifically about
USB. I worked on a few of those so I'm not denying them, I guess I should have
written this more clearly :)

I’ve also been told the same about media drivers. For example, someone
trying to write a USB media driver stares at work needed to just _start_ doing
what they had initially planned and simply gives up. It creates a scenario
where people continuously wait on each other to do the "heavy work", i.e.: to
come up with the common code/abstractions.

So far I see a pattern where sample drivers count as users. This has been the
case, for example, for rust_dma.rs. I was under the impression that the same
would apply here. Although I do realize that there were plans for dma code
other than rust_dma.rs, of course.

> 
>> It's a chicken and egg problem that I am trying to solve.
> 
> This is exactly why we develop Nova in-tree, such that we have a justification
> for adding all this infrastructure.
> 
> Lot's of the stuff I listed above originates from that and I think the Nova
> project has proven that we can break this chicken and egg problem. I think
> one proof for that is that Tyr follows the approach.
> 
> However, I agree that it still remains that someone (i.e. some driver) has to
> take the burden of doing the "heavy lifting" for a particular subsystem.

As for Nova and Tyr, these are projects with a lot of big companies involved.

They were able to break this chicken and egg situation in part due to that,
because companies were willing to allocate engineers for both the drivers _and_
the required infrastructure. Unless the same can be said for USB, media or any
other subsystems, I don't see it happening. Also, even if there is a company
interested, smaller ones are not willing to work on the infrastructure either,
only on the actual end results (i.e.: drivers).

That's just my humble opinion, of course.

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Danilo Krummrich]

On Sat Sep 6, 2025 at 4:50 PM CEST, Daniel Almeida wrote:
> So far I see a pattern where sample drivers count as users. This has been the
> case, for example, for rust_dma.rs. I was under the impression that the same
> would apply here. Although I do realize that there were plans for dma code
> other than rust_dma.rs, of course.

This isn't the case, we have those sample drivers to make it easy to review the
the code and illustrate in an isolated context how it works. But, there has
always been a "real" user behind that. In the case of the DMA work it was Nova.

> As for Nova and Tyr, these are projects with a lot of big companies involved.
>
> They were able to break this chicken and egg situation in part due to that,
> because companies were willing to allocate engineers for both the drivers _and_
> the required infrastructure. Unless the same can be said for USB, media or any
> other subsystems, I don't see it happening.

Well, this is true for Nova and Tyr, but I disagree that this is the reason we
were able to break the chicken and egg problem.

For instance, the initial lift around the driver core, PCI, I/O, etc.
infrastructure was done by me, a single person. This could have been happening
in the context of a very simple and small driver as well, rather than a big GPU
driver with lots of companies and people involved.

Igor (Cc) is doing the initial lift for I2C and Michal (Cc) for PWM for
instance.

So, I see those things happen and I don't think that such initial lifting
necessarily needs big companies with dozens of engineers being involved.

If we know people who want to write drivers for a subsystem that doesn't yet
have Rust infrastructure (such as USB), let's encourage them to get started /
involved anyways and let's help them as they go.

But also please don't get me wrong, I understand and very much appreciate you
want to get the ball rolling, but let's not discourage people by making it
sounds as if it would be impossible for individuals.

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Daniel Almeida]

> On 6 Sep 2025, at 12:22, Danilo Krummrich <dakr@kernel.org> wrote:
> 
> On Sat Sep 6, 2025 at 4:50 PM CEST, Daniel Almeida wrote:
>> So far I see a pattern where sample drivers count as users. This has been the
>> case, for example, for rust_dma.rs. I was under the impression that the same
>> would apply here. Although I do realize that there were plans for dma code
>> other than rust_dma.rs, of course.
> 
> This isn't the case, we have those sample drivers to make it easy to review the
> the code and illustrate in an isolated context how it works. But, there has
> always been a "real" user behind that. In the case of the DMA work it was Nova.

I see, thanks for clarifying!

> 
>> As for Nova and Tyr, these are projects with a lot of big companies involved.
>> 
>> They were able to break this chicken and egg situation in part due to that,
>> because companies were willing to allocate engineers for both the drivers _and_
>> the required infrastructure. Unless the same can be said for USB, media or any
>> other subsystems, I don't see it happening.
> 
> Well, this is true for Nova and Tyr, but I disagree that this is the reason we
> were able to break the chicken and egg problem.
> 
> For instance, the initial lift around the driver core, PCI, I/O, etc.
> infrastructure was done by me, a single person. This could have been happening
> in the context of a very simple and small driver as well, rather than a big GPU
> driver with lots of companies and people involved.
> 
> Igor (Cc) is doing the initial lift for I2C and Michal (Cc) for PWM for
> instance.
> 
> So, I see those things happen and I don't think that such initial lifting
> necessarily needs big companies with dozens of engineers being involved.

It’s not about the number of people, or the work being out of reach for a
single person, but more of someone asking themselves why it should be them to
do it when there’s no big project like Nova or Tyr to justify it and employ
them to do it all, vs employ them only for the actual drivers but not for the
abstractions. Or if they’re working on their free time, it becomes even
harder to justify spending energy on the abstractions if all they want is
to write a driver.

But if anyone got the impression that it is impossible to do it, my bad. It
isn’t.

> 
> If we know people who want to write drivers for a subsystem that doesn't yet
> have Rust infrastructure (such as USB), let's encourage them to get started /
> involved anyways and let's help them as they go.
> 
> But also please don't get me wrong, I understand and very much appreciate you
> want to get the ball rolling, but let's not discourage people by making it
> sounds as if it would be impossible for individuals.
> 

Yeah, point taken :)

As I said to Greg above, I’m here to help if anyone wants to write a USB
driver. Those interested are free to reach out to me and we will work together
to merge the required abstractions with a real user in mind. Hopefully this
encourages others to join in this work :)


— Daniel

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Danilo Krummrich]

On Sat Sep 6, 2025 at 5:46 PM CEST, Daniel Almeida wrote:
> As I said to Greg above, I’m here to help if anyone wants to write a USB
> driver. Those interested are free to reach out to me and we will work together
> to merge the required abstractions with a real user in mind. Hopefully this
> encourages others to join in this work :)

Yes, that'd be great! :)

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Simon Neuenhausen]

Hi,

> On 06.09.25 17:46, Daniel Almeida wrote:

> As I said to Greg above, I’m here to help if anyone wants to write a USB driver. Those interested 
are free to reach out to me and we will work together to merge the 
required abstractions with a real user in mind. Hopefully this 
encourages others to join in this work :)
I had planned on writing a USB driver for TI nspire calculators, that 
would make them mountable as USB mass storage devices, since they use a 
proprietary USB protocol, that usually requires paid software from TI. 
At the time I gave up on that, due to the lack of USB support in RFL, 
but I could revive the effort using this.

I'll admit that this is pretty gimmicky, but if it helps to get this 
merged, I would be happy to do it.

Greetings

Simon Neuenhausen

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Daniel Almeida]

Greg,

> On 9 Sep 2025, at 08:19, Simon Neuenhausen <simon.neuenhausen@rwth-aachen.de> wrote:
> 
> Hi,
> 
>> On 06.09.25 17:46, Daniel Almeida wrote:
> 
>> As I said to Greg above, I’m here to help if anyone wants to write a USB driver. Those interested
> are free to reach out to me and we will work together to merge the required abstractions with a real user in mind. Hopefully this encourages others to join in this work :)
> I had planned on writing a USB driver for TI nspire calculators, that would make them mountable as USB mass storage devices, since they use a proprietary USB protocol, that usually requires paid software from TI. At the time I gave up on that, due to the lack of USB support in RFL, but I could revive the effort using this.
> 
> I'll admit that this is pretty gimmicky, but if it helps to get this merged, I would be happy to do it.
> 
> Greetings
> 
> Simon Neuenhausen

We apparently have a user :)

Would you be ok if I continue this work? I can look into gadget zero as you and
Alan said.

— Daniel

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Greg Kroah-Hartman]

On Tue, Sep 09, 2025 at 09:12:21AM -0300, Daniel Almeida wrote:
> Greg,
> 
> > On 9 Sep 2025, at 08:19, Simon Neuenhausen <simon.neuenhausen@rwth-aachen.de> wrote:
> > 
> > Hi,
> > 
> >> On 06.09.25 17:46, Daniel Almeida wrote:
> > 
> >> As I said to Greg above, I’m here to help if anyone wants to write a USB driver. Those interested
> > are free to reach out to me and we will work together to merge the required abstractions with a real user in mind. Hopefully this encourages others to join in this work :)
> > I had planned on writing a USB driver for TI nspire calculators, that would make them mountable as USB mass storage devices, since they use a proprietary USB protocol, that usually requires paid software from TI. At the time I gave up on that, due to the lack of USB support in RFL, but I could revive the effort using this.
> > 
> > I'll admit that this is pretty gimmicky, but if it helps to get this merged, I would be happy to do it.
> > 
> > Greetings
> > 
> > Simon Neuenhausen
> 
> We apparently have a user :)

No, this will not work as a kernel driver, it needs to be done in
userspace as the complexity involved would be crazy to be in the
kernel, it would be much simpler as a libusb program.

> Would you be ok if I continue this work? I can look into gadget zero as you and
> Alan said.

Sure, but again, we need a real user before I'll be able to take this.

USB's "problem" is that for any non-class device, it should be done as a
userspace program and not a kernel driver.  It's simpler that way, more
secure, and easier to debug and support.  The number of "new" USB
devices out there that need a new kernel driver for it has been very
very low for the past 15+ years.

thanks,

greg k-h

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Greg Kroah-Hartman]

On Tue, Sep 09, 2025 at 01:19:12PM +0200, Simon Neuenhausen wrote:
> Hi,
> 
> > On 06.09.25 17:46, Daniel Almeida wrote:
> 
> > As I said to Greg above, I’m here to help if anyone wants to write a USB
> > driver. Those interested
> are free to reach out to me and we will work together to merge the required
> abstractions with a real user in mind. Hopefully this encourages others to
> join in this work :)
> I had planned on writing a USB driver for TI nspire calculators, that would
> make them mountable as USB mass storage devices, since they use a
> proprietary USB protocol, that usually requires paid software from TI. At
> the time I gave up on that, due to the lack of USB support in RFL, but I
> could revive the effort using this.

usb-storage is really just SCSI, so if you want to try to do this, you
are going to have to write a scsi driver for the calculator.  Not
something you probably really want to do :(

Odd are this would be a much simpler userspace program instead, as you
can control USB devices directly from userspace, no kernel driver
needed.

thanks,

greg k-h

Re: [PATCH 2/2] samples: rust: add a USB driver sample

[Simon Neuenhausen]

(Sorry for sending this again. I forgot to hit reply all, since I'm 
pretty new to this.)

On 09.09.25 14:14, Greg Kroah-Hartman wrote:

> On Tue, Sep 09, 2025 at 01:19:12PM +0200, Simon Neuenhausen wrote:
>> Hi,
>>
>>> On 06.09.25 17:46, Daniel Almeida wrote:
>>> As I said to Greg above, I’m here to help if anyone wants to write a 
>>> USB
>>> driver. Those interested
>> are free to reach out to me and we will work together to merge the 
>> required
>> abstractions with a real user in mind. Hopefully this encourages 
>> others to
>> join in this work 🙂
>> I had planned on writing a USB driver for TI nspire calculators, that 
>> would
>> make them mountable as USB mass storage devices, since they use a
>> proprietary USB protocol, that usually requires paid software from 
>> TI. At
>> the time I gave up on that, due to the lack of USB support in RFL, but I
>> could revive the effort using this.
> usb-storage is really just SCSI, so if you want to try to do this, you
> are going to have to write a scsi driver for the calculator.  Not
> something you probably really want to do 🙁
AFAIK it's not actually SCSI, but some custom USB protocol, that doesn't 
work on blocks, but files and directories directly. It also allows 
taking screenshots and performing firmware updates.
> Odd are this would be a much simpler userspace program instead, as you
> can control USB devices directly from userspace, no kernel driver
> needed.

Yes, a userspace program using FUSE would probably be simpler, since 
there's already exists "libnspire" for interacting with nspire 
calculators in userspace.

As I said, it's gimmicky.


Greetings

Simon

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Greg Kroah-Hartman]

On Mon, Aug 25, 2025 at 03:18:04PM -0300, Daniel Almeida wrote:
> This adds initial support for USB Rust drivers, not only because I see a
> widespread use of module_usb_driver() in media (which is a subsystem I
> aim to support) but also because I want to learn about USB in general
> and this is a nice opportunity to start doing so.

Oh wow, I wasn't expecting this, nice!

I'm at a conference all this week so I can't review this just yet, give
me a week please.  But I am happy to see this happen, thanks for doing
it.

greg k-h

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Greg Kroah-Hartman]

On Mon, Aug 25, 2025 at 03:18:04PM -0300, Daniel Almeida wrote:
> This adds initial support for USB Rust drivers, not only because I see a
> widespread use of module_usb_driver() in media (which is a subsystem I
> aim to support) but also because I want to learn about USB in general
> and this is a nice opportunity to start doing so.
> 
> I tried to keep things as consistent with pci.rs and platform.rs as
> possible and tested it by manually binding a device (i.e.: my Logitech
> mouse) to the sample driver via:
> 
> /sys/bus/usb/drivers/rust_driver_usb/new_id
> 
> This initial patch is therefore comprised of the same patterns that are
> known to work for pci and platform already.
> 
> Physically disconnecting the device also worked, i.e.: nothing bad
> showed up in dmesg.
> 
> Note that I did not touch MAINTAINERS at all. The objective is to
> kickstart the discussion of what to do there here in v1.

I tried to apply these, but I get the following build error when adding
to the char-misc-testing tree:

ld.lld: error: undefined symbol: usb_get_intf
>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>               rust/kernel.o:(<kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::inc_ref) in archive vmlinux.a
>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>               rust/kernel.o:(<kernel::sync::aref::ARef<kernel::usb::Interface> as core::convert::From<&kernel::usb::Interface<kernel::device::CoreInternal>>>::from) in archive vmlinux.a

ld.lld: error: undefined symbol: usb_put_intf
>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>               rust/kernel.o:(<kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::dec_ref) in archive vmlinux.a

ld.lld: error: undefined symbol: usb_get_dev
>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>               rust/kernel.o:(<kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::inc_ref) in archive vmlinux.a
>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>               rust/kernel.o:(<kernel::sync::aref::ARef<kernel::usb::Device> as core::convert::From<&kernel::usb::Device<kernel::device::CoreInternal>>>::from) in archive vmlinux.a

ld.lld: error: undefined symbol: usb_put_dev
>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>               rust/kernel.o:(<kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::dec_ref) in archive vmlinux.a


Any hints?

thanks,

greg k-h

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Alice Ryhl]

On Tue, Sep 23, 2025 at 2:05 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Mon, Aug 25, 2025 at 03:18:04PM -0300, Daniel Almeida wrote:
> > This adds initial support for USB Rust drivers, not only because I see a
> > widespread use of module_usb_driver() in media (which is a subsystem I
> > aim to support) but also because I want to learn about USB in general
> > and this is a nice opportunity to start doing so.
> >
> > I tried to keep things as consistent with pci.rs and platform.rs as
> > possible and tested it by manually binding a device (i.e.: my Logitech
> > mouse) to the sample driver via:
> >
> > /sys/bus/usb/drivers/rust_driver_usb/new_id
> >
> > This initial patch is therefore comprised of the same patterns that are
> > known to work for pci and platform already.
> >
> > Physically disconnecting the device also worked, i.e.: nothing bad
> > showed up in dmesg.
> >
> > Note that I did not touch MAINTAINERS at all. The objective is to
> > kickstart the discussion of what to do there here in v1.
>
> I tried to apply these, but I get the following build error when adding
> to the char-misc-testing tree:
>
> ld.lld: error: undefined symbol: usb_get_intf
> >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>               rust/kernel.o:(<kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::inc_ref) in archive vmlinux.a
> >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>               rust/kernel.o:(<kernel::sync::aref::ARef<kernel::usb::Interface> as core::convert::From<&kernel::usb::Interface<kernel::device::CoreInternal>>>::from) in archive vmlinux.a
>
> ld.lld: error: undefined symbol: usb_put_intf
> >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>               rust/kernel.o:(<kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::dec_ref) in archive vmlinux.a
>
> ld.lld: error: undefined symbol: usb_get_dev
> >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>               rust/kernel.o:(<kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::inc_ref) in archive vmlinux.a
> >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>               rust/kernel.o:(<kernel::sync::aref::ARef<kernel::usb::Device> as core::convert::From<&kernel::usb::Device<kernel::device::CoreInternal>>>::from) in archive vmlinux.a
>
> ld.lld: error: undefined symbol: usb_put_dev
> >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>               rust/kernel.o:(<kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::dec_ref) in archive vmlinux.a
>
>
> Any hints?

Did you enable CONFIG_USB?

Alice

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Greg Kroah-Hartman]

On Tue, Sep 23, 2025 at 02:29:00PM +0200, Alice Ryhl wrote:
> On Tue, Sep 23, 2025 at 2:05 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Aug 25, 2025 at 03:18:04PM -0300, Daniel Almeida wrote:
> > > This adds initial support for USB Rust drivers, not only because I see a
> > > widespread use of module_usb_driver() in media (which is a subsystem I
> > > aim to support) but also because I want to learn about USB in general
> > > and this is a nice opportunity to start doing so.
> > >
> > > I tried to keep things as consistent with pci.rs and platform.rs as
> > > possible and tested it by manually binding a device (i.e.: my Logitech
> > > mouse) to the sample driver via:
> > >
> > > /sys/bus/usb/drivers/rust_driver_usb/new_id
> > >
> > > This initial patch is therefore comprised of the same patterns that are
> > > known to work for pci and platform already.
> > >
> > > Physically disconnecting the device also worked, i.e.: nothing bad
> > > showed up in dmesg.
> > >
> > > Note that I did not touch MAINTAINERS at all. The objective is to
> > > kickstart the discussion of what to do there here in v1.
> >
> > I tried to apply these, but I get the following build error when adding
> > to the char-misc-testing tree:
> >
> > ld.lld: error: undefined symbol: usb_get_intf
> > >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> > >>>               rust/kernel.o:(<kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::inc_ref) in archive vmlinux.a
> > >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> > >>>               rust/kernel.o:(<kernel::sync::aref::ARef<kernel::usb::Interface> as core::convert::From<&kernel::usb::Interface<kernel::device::CoreInternal>>>::from) in archive vmlinux.a
> >
> > ld.lld: error: undefined symbol: usb_put_intf
> > >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> > >>>               rust/kernel.o:(<kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::dec_ref) in archive vmlinux.a
> >
> > ld.lld: error: undefined symbol: usb_get_dev
> > >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> > >>>               rust/kernel.o:(<kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::inc_ref) in archive vmlinux.a
> > >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> > >>>               rust/kernel.o:(<kernel::sync::aref::ARef<kernel::usb::Device> as core::convert::From<&kernel::usb::Device<kernel::device::CoreInternal>>>::from) in archive vmlinux.a
> >
> > ld.lld: error: undefined symbol: usb_put_dev
> > >>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> > >>>               rust/kernel.o:(<kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::dec_ref) in archive vmlinux.a
> >
> >
> > Any hints?
> 
> Did you enable CONFIG_USB?

Yes, CONFIG_USB=m

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Daniel Almeida]

[…]

>> 
>> I tried to apply these, but I get the following build error when adding
>> to the char-misc-testing tree:
>> 
>> ld.lld: error: undefined symbol: usb_get_intf
>>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>>>              rust/kernel.o:(<kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::inc_ref) in archive vmlinux.a
>>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>>>              rust/kernel.o:(<kernel::sync::aref::ARef<kernel::usb::Interface> as core::convert::From<&kernel::usb::Interface<kernel::device::CoreInternal>>>::from) in archive vmlinux.a
>> 
>> ld.lld: error: undefined symbol: usb_put_intf
>>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>>>              rust/kernel.o:(<kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::dec_ref) in archive vmlinux.a
>> 
>> ld.lld: error: undefined symbol: usb_get_dev
>>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>>>              rust/kernel.o:(<kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::inc_ref) in archive vmlinux.a
>>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>>>              rust/kernel.o:(<kernel::sync::aref::ARef<kernel::usb::Device> as core::convert::From<&kernel::usb::Device<kernel::device::CoreInternal>>>::from) in archive vmlinux.a
>> 
>> ld.lld: error: undefined symbol: usb_put_dev
>>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
>>>>>              rust/kernel.o:(<kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::dec_ref) in archive vmlinux.a
>> 
>> 
>> Any hints?
> 
> Did you enable CONFIG_USB?
> 
> Alice

+#[cfg(CONFIG_USB)]
+pub mod usb;

Hmm, but the USB module is gated by #[cfg(CONFIG_USB) in lib.rs, so not having
CONFIG_USB enabled should not return any errors and instead skip the USB
bindings completely.

I wonder if this has to be CONFIG_USB=y?

— Daniel

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Greg Kroah-Hartman]

On Tue, Sep 23, 2025 at 02:34:27PM +0200, Daniel Almeida wrote:
> […]
> 
> >> 
> >> I tried to apply these, but I get the following build error when adding
> >> to the char-misc-testing tree:
> >> 
> >> ld.lld: error: undefined symbol: usb_get_intf
> >>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>>>              rust/kernel.o:(<kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::inc_ref) in archive vmlinux.a
> >>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>>>              rust/kernel.o:(<kernel::sync::aref::ARef<kernel::usb::Interface> as core::convert::From<&kernel::usb::Interface<kernel::device::CoreInternal>>>::from) in archive vmlinux.a
> >> 
> >> ld.lld: error: undefined symbol: usb_put_intf
> >>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>>>              rust/kernel.o:(<kernel::usb::Interface as kernel::sync::aref::AlwaysRefCounted>::dec_ref) in archive vmlinux.a
> >> 
> >> ld.lld: error: undefined symbol: usb_get_dev
> >>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>>>              rust/kernel.o:(<kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::inc_ref) in archive vmlinux.a
> >>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>>>              rust/kernel.o:(<kernel::sync::aref::ARef<kernel::usb::Device> as core::convert::From<&kernel::usb::Device<kernel::device::CoreInternal>>>::from) in archive vmlinux.a
> >> 
> >> ld.lld: error: undefined symbol: usb_put_dev
> >>>>> referenced by kernel.1a949e63ee2acc6a-cgu.0
> >>>>>              rust/kernel.o:(<kernel::usb::Device as kernel::sync::aref::AlwaysRefCounted>::dec_ref) in archive vmlinux.a
> >> 
> >> 
> >> Any hints?
> > 
> > Did you enable CONFIG_USB?
> > 
> > Alice
> 
> +#[cfg(CONFIG_USB)]
> +pub mod usb;
> 
> Hmm, but the USB module is gated by #[cfg(CONFIG_USB) in lib.rs, so not having
> CONFIG_USB enabled should not return any errors and instead skip the USB
> bindings completely.
> 
> I wonder if this has to be CONFIG_USB=y?

It passes if CONFIG_USB=y, but it is good to keep the USB subsystem as a
module if at all possible :)

thanks,

greg k-h

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Miguel Ojeda]

On Tue, Sep 23, 2025 at 2:34 PM Daniel Almeida
<daniel.almeida@collabora.com> wrote:
>
> Hmm, but the USB module is gated by #[cfg(CONFIG_USB) in lib.rs, so not having
> CONFIG_USB enabled should not return any errors and instead skip the USB
> bindings completely.
>
> I wonder if this has to be CONFIG_USB=y?

Yes, the `kernel` crate is built-in and it is trying to call something
from a module.

Cheers,
Miguel

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Miguel Ojeda]

On Tue, Sep 23, 2025 at 2:05 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> I tried to apply these

By the way, a `MAINTAINERS` entry is needed, according to the log.

Cheers,
Miguel

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Daniel Almeida]

Hi Miguel,

> On 23 Sep 2025, at 14:56, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> 
> On Tue, Sep 23, 2025 at 2:05 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> 
>> I tried to apply these
> 
> By the way, a `MAINTAINERS` entry is needed, according to the log.
> 
> Cheers,
> Miguel
> 

Yeah, I did not add that on purpose. What’s the preferred approach here? I
wonder if we can add the Rust files to the USB SUBSYSTEM entry? I can maintain
the sample driver under a separate entry, for example.

I’m open to any other arrangements.

— Daniel

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Miguel Ojeda]

On Tue, Sep 23, 2025 at 3:25 PM Daniel Almeida
<daniel.almeida@collabora.com> wrote:
>
> Yeah, I did not add that on purpose. What’s the preferred approach here? I
> wonder if we can add the Rust files to the USB SUBSYSTEM entry? I can maintain
> the sample driver under a separate entry, for example.
>
> I’m open to any other arrangements.

Up to the subsystem maintainers, so Greg in this case I assume.

In general, maintainers may want to maintain it themselves (thus
adding the files is fine as you say); otherwise, they may prefer to
have you as co-maintainer, or perhaps a new sub-entry with you as
maintainer for the Rust part, etc.

Thanks!

Cheers,
Miguel

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Greg Kroah-Hartman]

On Mon, Aug 25, 2025 at 03:18:04PM -0300, Daniel Almeida wrote:
> This adds initial support for USB Rust drivers, not only because I see a
> widespread use of module_usb_driver() in media (which is a subsystem I
> aim to support) but also because I want to learn about USB in general
> and this is a nice opportunity to start doing so.
> 
> I tried to keep things as consistent with pci.rs and platform.rs as
> possible and tested it by manually binding a device (i.e.: my Logitech
> mouse) to the sample driver via:
> 
> /sys/bus/usb/drivers/rust_driver_usb/new_id
> 
> This initial patch is therefore comprised of the same patterns that are
> known to work for pci and platform already.
> 
> Physically disconnecting the device also worked, i.e.: nothing bad
> showed up in dmesg.
> 
> Note that I did not touch MAINTAINERS at all. The objective is to
> kickstart the discussion of what to do there here in v1.

Ok, as this seems to now be at least building properly for me, I have
taken it into my char-misc branch for the next -rc1 merge window.

BUT it has shown that it still needs some work to get "correct" and it
really doesn't do much quite yet, so I have applied the patch below to
pretty much just "disable" it entirely from the build at this point in
time.

I'll go and revert this commit after -rc1 is out, in my usb-next branch,
so that we can start to build on top of it and ensure that it doesn't
break, but for 6.18, I don't think it's quite ready to be there.

Yes, this is not a normal way that bindings will probably be merged into
the tree, but as I consulted deeply with the USB maintainer about this
topic while eating some good Paris pizza and French wine this week while
at the Kernel Recipes conference, I think that this deserves an
exception as they agree this can be merged now and they will be
responsible for any fallout.[1]

thanks,

greg k-h

From c1785be6395031f92b62badb27665f80f0a7794c Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Thu, 25 Sep 2025 14:42:40 +0200
Subject: USB: disable rust bindings from the build for now

The rust USB bindings as submitted are a good start, but they don't
really seem to be correct in a number of minor places, so just disable
them from the build entirely at this point in time.  When they are ready
to be re-enabled, this commit can be reverted.

Cc: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 rust/bindings/bindings_helper.h | 1 -
 rust/helpers/helpers.c          | 1 -
 rust/kernel/lib.rs              | 2 --
 samples/rust/Kconfig            | 2 +-
 4 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 41cd42cd286f..9b3a4ab95818 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -74,7 +74,6 @@
 #include <linux/slab.h>
 #include <linux/task_work.h>
 #include <linux/tracepoint.h>
-#include <linux/usb.h>
 #include <linux/wait.h>
 #include <linux/workqueue.h>
 #include <linux/xarray.h>
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index 04103ab1a349..8e8277bdddca 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -48,7 +48,6 @@
 #include "task.c"
 #include "time.c"
 #include "uaccess.c"
-#include "usb.c"
 #include "vmalloc.c"
 #include "wait.c"
 #include "workqueue.c"
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index 004ca70b816d..99dbb7b2812e 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -127,8 +127,6 @@
 pub mod tracepoint;
 pub mod transmute;
 pub mod types;
-#[cfg(CONFIG_USB = "y")]
-pub mod usb;
 pub mod uaccess;
 pub mod workqueue;
 pub mod xarray;
diff --git a/samples/rust/Kconfig b/samples/rust/Kconfig
index 6d6e4d8c88cb..865a62a93ddc 100644
--- a/samples/rust/Kconfig
+++ b/samples/rust/Kconfig
@@ -85,7 +85,7 @@ config SAMPLE_RUST_DRIVER_PLATFORM
 
 config SAMPLE_RUST_DRIVER_USB
 	tristate "USB Driver"
-	depends on USB = y
+	depends on USB = y && BROKEN
 	help
 	  This option builds the Rust USB driver sample.
 
-- 
2.51.0


[1] For those not getting the sarcasm here, I'm that maintainer, and
    yes, Paris has some very good pizza :)

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Daniel Almeida]

Hi Greg,

> On 25 Sep 2025, at 14:52, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> On Mon, Aug 25, 2025 at 03:18:04PM -0300, Daniel Almeida wrote:
>> This adds initial support for USB Rust drivers, not only because I see a
>> widespread use of module_usb_driver() in media (which is a subsystem I
>> aim to support) but also because I want to learn about USB in general
>> and this is a nice opportunity to start doing so.
>> 
>> I tried to keep things as consistent with pci.rs and platform.rs as
>> possible and tested it by manually binding a device (i.e.: my Logitech
>> mouse) to the sample driver via:
>> 
>> /sys/bus/usb/drivers/rust_driver_usb/new_id
>> 
>> This initial patch is therefore comprised of the same patterns that are
>> known to work for pci and platform already.
>> 
>> Physically disconnecting the device also worked, i.e.: nothing bad
>> showed up in dmesg.
>> 
>> Note that I did not touch MAINTAINERS at all. The objective is to
>> kickstart the discussion of what to do there here in v1.
> 
> Ok, as this seems to now be at least building properly for me, I have
> taken it into my char-misc branch for the next -rc1 merge window.
> 
> BUT it has shown that it still needs some work to get "correct" and it
> really doesn't do much quite yet, so I have applied the patch below to
> pretty much just "disable" it entirely from the build at this point in
> time.
> 
> I'll go and revert this commit after -rc1 is out, in my usb-next branch,
> so that we can start to build on top of it and ensure that it doesn't
> break, but for 6.18, I don't think it's quite ready to be there.

Cool,

I’ll follow up with the fixes required, and slowly build the features
needed for usb-skeleton as we discussed.

Give me a couple of weeks though, I need to get myself out of conference
hell first :)

Btw, thanks for the reviews, Danilo!

— Daniel

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Danilo Krummrich]

On Thu Sep 25, 2025 at 2:52 PM CEST, Greg Kroah-Hartman wrote:
> Yes, this is not a normal way that bindings will probably be merged into
> the tree, but as I consulted deeply with the USB maintainer about this
> topic while eating some good Paris pizza and French wine this week while
> at the Kernel Recipes conference, I think that this deserves an
> exception as they agree this can be merged now and they will be
> responsible for any fallout.[1]

If you rather have it "staging" in-tree that's of course up to you. :)

But, I'd prefer not to expose the incorrect conversion between a
&usb::Interface<Ctx> and a &usb::Device<Ctx> for a full release in Linus' tree.

Besides other implications, this conversation also implies that
&usb::Device<Core> can be derived from &usb::Interface<Core>, which semantically
means that if the USB interface's device lock is held we infer that the device
lock of the USB device is held as well.

I know the code isn't even built, but I don't want people reading the code to
take wrong conclusions from that.

Also, it's dead code anyways, so maybe just apply the following hunk?

Thanks,
Danilo

diff --git a/rust/kernel/usb.rs b/rust/kernel/usb.rs
index 8899e7520b58..9bc3478cf561 100644
--- a/rust/kernel/usb.rs
+++ b/rust/kernel/usb.rs
@@ -340,18 +340,6 @@ fn as_ref(&self) -> &device::Device<Ctx> {
     }
 }

-impl<Ctx: device::DeviceContext> AsRef<Device<Ctx>> for Interface<Ctx> {
-    fn as_ref(&self) -> &Device<Ctx> {
-        // SAFETY: `self.as_raw()` is valid by the type invariants. For a valid interface,
-        // the helper should always return a valid USB device pointer.
-        let usb_dev = unsafe { bindings::interface_to_usbdev(self.as_raw()) };
-
-        // SAFETY: The helper returns a valid interface pointer that shares the
-        // same `DeviceContext`.
-        unsafe { &*(usb_dev.cast()) }
-    }
-}
-
 // SAFETY: Instances of `Interface` are always reference-counted.
 unsafe impl AlwaysRefCounted for Interface {
     fn inc_ref(&self) {

Re: [PATCH 0/2] rust: usb: add initial USB abstractions

[Greg Kroah-Hartman]

On Thu, Sep 25, 2025 at 03:29:25PM +0200, Danilo Krummrich wrote:
> On Thu Sep 25, 2025 at 2:52 PM CEST, Greg Kroah-Hartman wrote:
> > Yes, this is not a normal way that bindings will probably be merged into
> > the tree, but as I consulted deeply with the USB maintainer about this
> > topic while eating some good Paris pizza and French wine this week while
> > at the Kernel Recipes conference, I think that this deserves an
> > exception as they agree this can be merged now and they will be
> > responsible for any fallout.[1]
> 
> If you rather have it "staging" in-tree that's of course up to you. :)
> 
> But, I'd prefer not to expose the incorrect conversion between a
> &usb::Interface<Ctx> and a &usb::Device<Ctx> for a full release in Linus' tree.
> 
> Besides other implications, this conversation also implies that
> &usb::Device<Core> can be derived from &usb::Interface<Core>, which semantically
> means that if the USB interface's device lock is held we infer that the device
> lock of the USB device is held as well.
> 
> I know the code isn't even built, but I don't want people reading the code to
> take wrong conclusions from that.
> 
> Also, it's dead code anyways, so maybe just apply the following hunk?
> 
> Thanks,
> Danilo
> 
> diff --git a/rust/kernel/usb.rs b/rust/kernel/usb.rs
> index 8899e7520b58..9bc3478cf561 100644
> --- a/rust/kernel/usb.rs
> +++ b/rust/kernel/usb.rs
> @@ -340,18 +340,6 @@ fn as_ref(&self) -> &device::Device<Ctx> {
>      }
>  }
> 
> -impl<Ctx: device::DeviceContext> AsRef<Device<Ctx>> for Interface<Ctx> {
> -    fn as_ref(&self) -> &Device<Ctx> {
> -        // SAFETY: `self.as_raw()` is valid by the type invariants. For a valid interface,
> -        // the helper should always return a valid USB device pointer.
> -        let usb_dev = unsafe { bindings::interface_to_usbdev(self.as_raw()) };
> -
> -        // SAFETY: The helper returns a valid interface pointer that shares the
> -        // same `DeviceContext`.
> -        unsafe { &*(usb_dev.cast()) }
> -    }
> -}
> -
>  // SAFETY: Instances of `Interface` are always reference-counted.
>  unsafe impl AlwaysRefCounted for Interface {
>      fn inc_ref(&self) {

Cool, I'll be glad to apply this, can you resend it with a real
signed-off-by line?

And we can always submit fixes during the -rc cycle for 6.18, for stuff
like this, so there's no immediate rush at the moment to get this
"perfect".

thanks,

greg k-h