#include <composite.h>

Data Fields
struct usb_gadget *	gadget

struct usb_request *	req

unsigned	bufsiz

struct usb_configuration *	config

unsigned int	suspended:1

struct usb_device_descriptor	desc

struct list_head	configs

struct usb_composite_driver *	driver

u8	next_string_id

u8	manufacturer_override

u8	product_override

u8	serial_override

unsigned	deactivations

int	delayed_status

spinlock_t	lock

char *	def_manufacturer

Detailed Description

struct usb_composite_device - represents one composite usb gadget : read-only, abstracts the gadget's usb peripheral controller : used for control responses; buffer is pre-allocated : size of buffer pre-allocated in : the currently active configuration

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.

struct usb_composite_device - represents one composite usb gadget : read-only, abstracts the gadget's usb peripheral controller : used for control responses; buffer is pre-allocated : the currently active configuration

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.

Definition at line 345 of file composite.h.