usb_gadget_probe_driver(9) [centos man page]

USB_GADGET_PROBE_DRI(9) 				      Kernel Mode Gadget API					   USB_GADGET_PROBE_DRI(9)

NAME

       usb_gadget_probe_driver - probe a gadget driver

SYNOPSIS

       int usb_gadget_probe_driver(struct usb_gadget_driver * driver);

ARGUMENTS

       driver
	   the driver being registered

CONTEXT

       can sleep

DESCRIPTION

       Call this in your gadget driver's module initialization function, to tell the underlying usb controller driver about your driver. The
       bind() function will be called to bind it to a gadget before this registration call returns. It's expected that the bind() function will be
       in init sections.

AUTHOR

       David Brownell <dbrownell@users.sourceforge.net>
	   Author.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014						   USB_GADGET_PROBE_DRI(9)

STRUCT 
USB_COMPOSITE(9) 				      Kernel Mode Gadget API					   STRUCT USB_COMPOSITE(9)

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_configuration * config;
       };

MEMBERS

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

       req
	   used for control responses; buffer is pre-allocated

       config
	   the currently active configuration

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

Kernel Hackers Manual 3.10					     June 2014						   STRUCT USB_COMPOSITE(9)