This is a patch that makes sure that the device ID data (idVendor,
idProduct and bcdDevice) are assigned to the descriptor in the cdev
structure *before* the composite gadget starts binding. This allows the
composite driver, and all the composite functions it uses, access to
that data.
In one of the composite functions we created, we needed to register an
input device and wanted to use the idVendor, idProduct and bcdDevice
codes to properly initialize the id field of the input device. We could
not do that because the idVendor, idProduct and bcdDevice values were
only set in the cdec structure *after* the composite->bind(cdev) call.
Signed-off-by: Robert Lukassen <robert.lukassen@tomtom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
__init, __initdata and __exit tags have have been removed from
various files to make it possible for gadgets that do not use
the __init/__exit tags to use those.
Files in question are related to:
* the core composite framework,
* the mass storage function (fixing a section mismatch) and
* ethernet driver (ACM, ECM, RNDIS).
Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds a sysfs entry (/sys/devices/platform/_UDC_/gadget/suspended) to
show the suspend state of an USB composite gadget.
Signed-off-by: Fabien Chouteau <fabien.chouteau@barco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The composite framework allows gadgets with more than one function. This
can lead to situations where the configuration descriptor is larger than
the maximum of 512 bytes currently allowed by the composite framework.
This patch proposes to double that limit to 1024.
Signed-off-by: Robert Lukassen <robert.lukassen@tomtom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Changed definition of usb_composite_unregister() function
removing __exit declaration. This way, the function is
included even if the whole code was not compiled as module.
This is required if a compiled-in code would like to
unregister a composite gadget.
Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Control requests targeted at an endpoint (that is sent to EP0 but
specifying the target endpoint address in wIndex) are dispatched to the
current configuration's setup callback, requiring all gadget drivers to
dispatch the requests to the correct function driver.
To avoid this, record which endpoints are used by each function in the
composite driver SET CONFIGURATION handler and dispatch requests
targeted at endpoints to the correct function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Check whether index is within bounds before testing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Address one open question in the composite gadget framework:
Yes, we should have device-level suspend/resume callbacks
in addition to the function-level ones. We have at least one
scenario (with gadget zero in OTG test mode) that's awkward
to handle without it.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In some usb gadget driver, for example usb audio class device, the high
byte of w_index is the entity id and low byte is the interface number.
If we use the 2 bytes of w_index as the array number, we will get a
wrong pointer or NULL pointer.
This patch fixes this issue.
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Offer a "how much VBUS power to request" configuration option
for USB gadgets that aren't using board-specific customization
of their gadget or (composite) configuration drivers.
Also remove a couple pointless "depends on USB_GADGET" bits
from the Kconfig text; booleans inside an "if USB_GADGET" will
already have that dependency.
Based on a patch from Justin Clacherty.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Justin Clacherty <justin@redfish-group.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add a new mechanism to the composite gadget framework, letting
functions deactivate (and reactivate) themselves. Think of it
as a refcounted wrapper for the software pullup control.
A key example of why to use this mechanism involves functions that
require a userspace daemon. Those functions shuld use this new
mechanism to prevent the gadget from enumerating until those daemons
are activated. Without this mechanism, hosts would see devices that
malfunction until the relevant daemons start.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fill in a reserved/unused device qualifier field to ensure that
the USBCV tests will always pass.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add <linux/usb/composite.h> interfaces for composite gadget drivers, and
basic implementation support behind it:
- struct usb_function ... groups one or more interfaces into a function
managed as one unit within a configuration, to which it's added by
usb_add_function().
- struct usb_configuration ... groups one or more such functions into
a configuration managed as one unit by a driver, to which it's added
by usb_add_config(). These operate at either high or full/low speeds
and at a given bMaxPower.
- struct usb_composite_driver ... groups one or more such configurations
into a gadget driver, which may be registered or unregistered.
- struct usb_composite_dev ... a usb_composite_driver manages this; it
wraps the usb_gadget exposed by the controller driver.
This also includes some basic kerneldoc.
How to use it (the short version): provide a usb_composite_driver with a
bind() that calls usb_add_config() for each of the needed configurations.
The configurations in turn have bind() calls, which will usb_add_function()
for each function required. Each function's bind() allocates resources
needed to perform its tasks, like endpoints; sometimes configurations will
allocate resources too.
Separate patches will convert most gadget drivers to this infrastructure.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
