Re: [RFC] usb: gadget: proposal for Microsoft OS 2.0 descriptor support

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Sep 02, 2025 at 07:33:21AM +0000, Maxime Vincent wrote:
> Hi all,
> 
> This is a request for comments, not a patchset.
> 
> The Linux USB gadget framework already supports Microsoft OS 1.0
> descriptors in usb_composite, which makes it possible for Windows
> hosts to bind WinUSB or other class drivers without requiring a custom
> .inf file. This has been very useful for devices that want to provide
> driverless support on Windows.
> 
> Recent versions of Windows (8.1 and later) extend this mechanism with
> the "Microsoft OS 2.0 descriptor set." This supersedes OS 1.0 and
> provides:
> 
>   - A more structured way to declare WinUSB interface bindings
>   - Registry property descriptors (string values, device properties)
>   - Support across multiple configurations and interfaces
>   - Forward compatibility for future extensions
> 
> At the moment, Linux gadget drivers cannot expose these descriptors
> generically. Developers either hardcode them in out-of-tree patches or
> skip MS OS 2.0 support entirely, limiting interoperability with modern
> Windows hosts.
> 
> I would like to propose adding *generic* MS OS 2.0 descriptor support
> to the gadget framework, in a way analogous to the existing OS 1.0
> support - and similar to how WebUSB support has been implemented:
> 
>   - New configfs attributes to define the OS 2.0 descriptor set
>   - Helpers in usb_composite for handling the vendor-specific requests
>   - Backward compatibility with existing OS 1.0 support
> 
> Before submitting any code, I wanted to ask maintainers:
> 
>   - Is this considered broadly useful enough to merge upstream?
>   - Is it okay to support this fully through configfs?
> 
> I currently have a PoC running, but it's nowhere near ready to submit.
> Feedback would be greatly appreciated before starting work on an
> proper implementation. 

We would like to see a real solution first to prove that it is something
that can actually be done, before we can really provide any sort of
review comments.

That's just how kernel development works,

thanks,

greg k-h