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>

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

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

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

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

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

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

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

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

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

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

[…]

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

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

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

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