Discussion of the VIRTIO specification
 help / color / mirror / Atom feed
From: Demi Marie Obenour <demiobenour@gmail.com>
To: Vasilii Ianikeev <vasilii.ianikeev@oss.qualcomm.com>,
	virtio-comment@lists.linux.dev
Cc: igor.skalkin@oss.qualcomm.com
Subject: Re: [RFC PATCH] virtio-usb: Add initial virtio-usb specification
Date: Sat, 13 Jun 2026 11:42:03 -0400	[thread overview]
Message-ID: <2e5f2956-eab4-42b6-92cf-20cb1bb49845@gmail.com> (raw)
In-Reply-To: <20260611130826.287372-1-vasilii.ianikeev@oss.qualcomm.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 1816 bytes --]

On 6/11/26 09:08, Vasilii Ianikeev wrote:
> This patch introduces the draft virtio-usb device specification, which
> defines a dual-role USB device capable of operating as a USB host
> controller, USB device controller, or both roles with dynamic role
> switching support.
> 
> A USB device may support one or more ports. Each port can operate as a
> USB host controller port, USB device controller port, or a dual-role
> port that allows role switching, depending on the device’s capabilities.
> 
> 
> The specification includes:
> 
> - Device ID assignment (49) (already reserved) and feature bits for
>   host, device, and role switching capabilities
> - Dedicated virtqueue sets for USB host role, USB device role, and OTG
>   role switching operations
> - Data transfer support for all USB endpoint types (control, interrupt,
>   bulk, and isochronous)
> - USB host role operations including device connection/disconnection
>   events, URB submission, and bulk stream management
> - USB device role operations including endpoint management, gadget
>   lifecycle events, and control request handling
> - USB OTG support for dynamic role switching between host and device
>   modes
> - Multi-port support allowing devices to expose multiple USB ports with
>   independent role configurations
> 
> The specification refers to USB 2.0 and USB 3.2 specifications for
> common terms.
> 
> For this device, there is a prototypical Linux kernel driver for which
> upstreaming is planned, and a proprietary device implementation.

Would it be possible to have a device implementation in QEMU, crosvm,
or another open source project?  If the only implementation is
proprietary, the driver will be of limited value to the community.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      parent reply	other threads:[~2026-06-13 15:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-11 13:08 [RFC PATCH] virtio-usb: Add initial virtio-usb specification Vasilii Ianikeev
2026-06-11 13:08 ` Vasilii Ianikeev
2026-06-13 15:42 ` Demi Marie Obenour [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2e5f2956-eab4-42b6-92cf-20cb1bb49845@gmail.com \
    --to=demiobenour@gmail.com \
    --cc=igor.skalkin@oss.qualcomm.com \
    --cc=vasilii.ianikeev@oss.qualcomm.com \
    --cc=virtio-comment@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox