This series introduces initial abstractions to allow for the
implementation of USB drivers in Rust.

This is an RFC to demonstrate a rough idea on how the USB abstractions
needed to create drivers in Rust could be implemented.

The series is broken up into 4 parts:

1. USB chapter 9 standard descriptors and constants - Exposes the
   necessary structs and constants from include/uapi/linux/usb/ch9.h as
   a new ch9 submodule.

2. Interface and endpoint abstractions - Wraps the relevant C structs
   and functions defined in include/linux/usb.h, allowing drivers to
   safely query and configure interfaces and their endpoints.

3. USB Request Block (URB) abstractions - Creates a safe wrapper around
   the C `struct urb` to allow Rust drivers to communicate with devices.

4. An initial user of the new abstractions - A driver for the GV-USB2
   composite-usb video capture device.

Patch 3 is the bulk and core of this series. By their asynchronous
nature, creating a safe URB abstraction for drivers to use is tricky.
The goals of the URB abstraction are:

1. No `unsafe` needed in driver code. This means providing a way for a
   driver to safely access private data sent with the URB.
2. Drivers are forced to handle the URB status in their completion
   callback before accessing the URB data.
3. Dropping an URB ensures it is not in-flight and frees its resources.
4. The URB can be safely resubmitted from the completion callback.

The patch elaborates on how these goals are achieved in more detail.

Although the URB abstractions do not include immediate support for bulk
or interrupt URBs, I believe it creates a foundation conducive to
future, safe abstractions for them.

Patch 4 is first user of these USB abstractions. The initial
implementation is very much bare-bones, only exposing audio data via
debugfs. It is based on the in-tree STK1160 driver and an old,
out-of-tree driver written by Isaac Lozano [1].

[1] https://github.com/Isaac-Lozano/GV-USB2-Driver

Signed-off-by: Colin Braun <colin.braun.cl@gmail.com>
---
Colin Braun (4):
      rust: usb: add USB ch9 standard descriptors and constants
      rust: usb: add usb host interface and endpoint abstractions
      rust: usb: add urb abstraction with control and isochronous support
      media: add gv-usb2 audio capture driver

 drivers/media/usb/Kconfig            |   1 +
 drivers/media/usb/Makefile           |   1 +
 drivers/media/usb/gv-usb2/Kconfig    |   9 +
 drivers/media/usb/gv-usb2/Makefile   |   1 +
 drivers/media/usb/gv-usb2/driver.rs  | 361 ++++++++++++++
 drivers/media/usb/gv-usb2/gv_usb2.rs |  16 +
 drivers/media/usb/gv-usb2/regs.rs    |  25 +
 include/linux/usb.h                  |   4 +
 rust/kernel/usb.rs                   | 905 ++++++++++++++++++++++++++++++++++-
 rust/kernel/usb/ch9.rs               | 295 ++++++++++++
 10 files changed, 1613 insertions(+), 5 deletions(-)
---
base-commit: 30e873dd61b044092dbc657c7c67a5d19adfd933
change-id: 20260712-urb-abstraction-v1-020a67f16cff

Best regards,
--  
Colin Braun <colin.braun.cl@gmail.com>

Hi Colin!

> On 12 Jul 2026, at 18:07, Colin Braun <colinbrauncl@gmail.com> wrote:
> 
> This series introduces initial abstractions to allow for the
> implementation of USB drivers in Rust.
> 
> This is an RFC to demonstrate a rough idea on how the USB abstractions
> needed to create drivers in Rust could be implemented.
> 
> The series is broken up into 4 parts:
> 
> 1. USB chapter 9 standard descriptors and constants - Exposes the
>   necessary structs and constants from include/uapi/linux/usb/ch9.h as
>   a new ch9 submodule.
> 
> 2. Interface and endpoint abstractions - Wraps the relevant C structs
>   and functions defined in include/linux/usb.h, allowing drivers to
>   safely query and configure interfaces and their endpoints.
> 
> 3. USB Request Block (URB) abstractions - Creates a safe wrapper around
>   the C `struct urb` to allow Rust drivers to communicate with devices.
> 
> 4. An initial user of the new abstractions - A driver for the GV-USB2
>   composite-usb video capture device.
> 
> Patch 3 is the bulk and core of this series. By their asynchronous
> nature, creating a safe URB abstraction for drivers to use is tricky.
> The goals of the URB abstraction are:
> 
> 1. No `unsafe` needed in driver code. This means providing a way for a
>   driver to safely access private data sent with the URB.
> 2. Drivers are forced to handle the URB status in their completion
>   callback before accessing the URB data.
> 3. Dropping an URB ensures it is not in-flight and frees its resources.
> 4. The URB can be safely resubmitted from the completion callback.
> 
> The patch elaborates on how these goals are achieved in more detail.
> 
> Although the URB abstractions do not include immediate support for bulk
> or interrupt URBs, I believe it creates a foundation conducive to
> future, safe abstractions for them.
> 
> Patch 4 is first user of these USB abstractions. The initial
> implementation is very much bare-bones, only exposing audio data via
> debugfs. It is based on the in-tree STK1160 driver and an old,
> out-of-tree driver written by Isaac Lozano [1].
> 
> [1] https://github.com/Isaac-Lozano/GV-USB2-Driver
> 
> Signed-off-by: Colin Braun <colin.braun.cl@gmail.com>
> ---
> Colin Braun (4):
>      rust: usb: add USB ch9 standard descriptors and constants
>      rust: usb: add usb host interface and endpoint abstractions
>      rust: usb: add urb abstraction with control and isochronous support
>      media: add gv-usb2 audio capture driver

Have you talked to the media people about adding a Rust driver?

> 
> drivers/media/usb/Kconfig            |   1 +
> drivers/media/usb/Makefile           |   1 +
> drivers/media/usb/gv-usb2/Kconfig    |   9 +
> drivers/media/usb/gv-usb2/Makefile   |   1 +
> drivers/media/usb/gv-usb2/driver.rs  | 361 ++++++++++++++
> drivers/media/usb/gv-usb2/gv_usb2.rs |  16 +
> drivers/media/usb/gv-usb2/regs.rs    |  25 +
> include/linux/usb.h                  |   4 +
> rust/kernel/usb.rs                   | 905 ++++++++++++++++++++++++++++++++++-
> rust/kernel/usb/ch9.rs               | 295 ++++++++++++
> 10 files changed, 1613 insertions(+), 5 deletions(-)
> ---
> base-commit: 30e873dd61b044092dbc657c7c67a5d19adfd933
> change-id: 20260712-urb-abstraction-v1-020a67f16cff
> 
> Best regards,
> --  
> Colin Braun <colin.braun.cl@gmail.com>
> 
> 

On Mon, Jul 13, 2026 at 10:53:53AM -0300, Daniel Almeida wrote:
> 
> Have you talked to the media people about adding a Rust driver?
> 

I have not. I was actually wondering if this belongs in
drivers/staging/media, given how much work still needs to be done for it
to support basic functionality. I had seen some v4l2 Rust abstraction
work done but not merged in, so I had hoped this could eventually be a
user of that work. Still trying to get a lay of the land, this is my
first attempt at contributing to the kernel.

Hi Colin,

> On 13 Jul 2026, at 17:32, Colin Braun <colinbrauncl@gmail.com> wrote:
> 
> On Mon, Jul 13, 2026 at 10:53:53AM -0300, Daniel Almeida wrote:
>> 
>> Have you talked to the media people about adding a Rust driver?
>> 
> 
> I have not. I was actually wondering if this belongs in
> drivers/staging/media, given how much work still needs to be done for it
> to support basic functionality. I had seen some v4l2 Rust abstraction
> work done but not merged in, so I had hoped this could eventually be a

Yep, I was behind this for a few years, in a few different ways.

> user of that work. Still trying to get a lay of the land, this is my
> first attempt at contributing to the kernel.
> 

I’m cc’ing my colleague Nicolas. He was at the media summit this year
discussing a topic somewhat related to Rust.

IIUC, the consensus is unfavorable for Rust media drivers at the moment. They
are waiting for more progress on gcc-rs before allowing it, as clang does not
fit some of their infrastructure.

This doesn't have to discourage you from this work, though. Last I spoke to
Greg, I think he was OK with having enough infrastructure to build a Rust
version of usb-skeleton.c. You could perhaps work on that? I never really found
the time to, but I can chime in with reviews. It's always nice to onboard new people :)

As Danilo pointed out, there is a competing implementation, though that seems
to be completely AI-generated, IIRC. Perhaps Mike would be interested in
letting you take it over? It's already a lot of work on their plate to do
hardware RE + KMS + usb, so you could work together instead.

Just a suggestion, of course.

-- Daniel

On Tue, Jul 14, 2026 at 11:35:50PM -0300, Daniel Almeida wrote:
> I’m cc’ing my colleague Nicolas. He was at the media summit this year
> discussing a topic somewhat related to Rust.
> 
> IIUC, the consensus is unfavorable for Rust media drivers at the moment. They
> are waiting for more progress on gcc-rs before allowing it, as clang does not
> fit some of their infrastructure.

This is good to know, thanks for mentioning this. I will table my work
on the media driver for now, though I might continue working on some of
it privately until gcc-rs has progressed enough.

> This doesn't have to discourage you from this work, though. Last I spoke to
> Greg, I think he was OK with having enough infrastructure to build a Rust
> version of usb-skeleton.c. You could perhaps work on that? I never really found
> the time to, but I can chime in with reviews. It's always nice to onboard new people :)

I would definitely be interested in picking up this work.

Unless my first 3 patches seem to be heading in the wrong direction,
I will integrate the initial and any coming feedback here, as well as
some of the concerns the Sashiko AI bot emailed me. I'll include an
attempt at the rust version of usb-skeleton as well.

I imagine it makes sense to strip out functions usb-skeleton doesn't use,
so I will remove those in my next revision.

Thanks,
Colin

On Tue, Jul 14, 2026 at 11:35:50PM -0300, Daniel Almeida wrote:
> This doesn't have to discourage you from this work, though. Last I spoke to
> Greg, I think he was OK with having enough infrastructure to build a Rust
> version of usb-skeleton.c. You could perhaps work on that? I never really found
> the time to, but I can chime in with reviews. It's always nice to onboard new people :)

Yes, if we have a rust version of usb-skeleton, that would go a long way
toward actually being able to write a "real" USB driver in rust.  I have
no objection to taking the bindings to make that happen.

thanks,

greg k-h

On Sun Jul 12, 2026 at 11:07 PM CEST, Colin Braun wrote:
> This series introduces initial abstractions to allow for the
> implementation of USB drivers in Rust.

Note that there's also [1].

[1] https://lore.kernel.org/lkml/20260617145946.1894-1-mike@fireburn.co.uk/

On Mon, Jul 13, 2026 at 03:22:25PM +0200, Danilo Krummrich wrote:
> On Sun Jul 12, 2026 at 11:07 PM CEST, Colin Braun wrote:
> > This series introduces initial abstractions to allow for the
> > implementation of USB drivers in Rust.
> 
> Note that there's also [1].
> 
> [1] https://lore.kernel.org/lkml/20260617145946.1894-1-mike@fireburn.co.uk/

Yep, I saw that series pop up while I was working on this one.
By and large there is not a lot of overlap, so I felt that my patch
series was okay to submit.