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

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

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

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

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

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.

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.

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.

> 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

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

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

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

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

(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

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

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

> 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

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