---
name: "struct_usb_composite_dev"
section: "9"
platform: "linux"
package: "linux-manual-4.9"
version: "4.9.228-1"
release: "Debian 9 (Stretch)"
platforms: ["linux"]
url: "https://new.carta.tech/struct_usb_composite_dev"
---

# struct\_usb\_composite\_dev(9)

represents one composite usb gadget

## NAME

struct\_usb\_composite\_dev - represents one composite usb gadget

## SYNOPSIS

```
struct usb_composite_dev {
  struct usb_gadget * gadget;
  struct usb_request * req;
  struct usb_request * os_desc_req;
  struct usb_configuration * config;
  u8 qw_sign[OS_STRING_QW_SIGN_LEN];
  u8 b_vendor_code;
  struct usb_configuration * os_desc_config;
  unsigned int use_os_string:1;
};
```

## MEMBERS

gadget

read-only, abstracts the gadget's usb peripheral controller

req

used for control responses; buffer is pre-allocated

os\_desc\_req

used for OS descriptors responses; buffer is pre-allocated

config

the currently active configuration

qw\_sign\[OS\_STRING\_QW\_SIGN\_LEN\]

qwSignature part of the OS string

b\_vendor\_code

bMS\_VendorCode part of the OS string

os\_desc\_config

the configuration to be used with OS descriptors

use\_os\_string

false by default, interested gadgets set it

## DESCRIPTION

One of these devices is allocated and initialized before the associated device driver's **bind** is called.

OPEN ISSUE: it appears that some WUSB devices will need to be built by combining a normal (wired) gadget with a wireless one. This revision of the gadget framework should probably try to make sure doing that won't hurt too much.

One notion for how to handle Wireless USB devices involves: (a) a second gadget here, discovery mechanism TBD, but likely needing separate “register/unregister WUSB gadget” calls; (b) updates to usb\_gadget to include flags “is it wireless”, “is it wired”, plus (presumably in a wrapper structure) bandgroup and PHY info; (c) presumably a wireless\_ep wrapping a usb\_ep, and reporting wireless-specific parameters like maxburst and maxsequence; (d) configurations that are specific to wireless links; (e) function drivers that understand wireless configs and will support wireless for (additional) function instances; (f) a function to support association setup (like CBAF), not necessarily requiring a wireless adapter; (g) composite device setup that can create one or more wireless configs, including appropriate association setup support; (h) more, TBD.

## AUTHOR

**David Brownell** \<dbrownell@users.sourceforge.net\>

Author.

## COPYRIGHT