drivers/usb/gadget/legacy/Kconfig

Source file repositories/reference/linux-study-clean/drivers/usb/gadget/legacy/Kconfig

File Facts

System
Linux kernel
Corpus path
drivers/usb/gadget/legacy/Kconfig
Extension
[no extension]
Size
18652 bytes
Lines
533
Domain
Driver Families
Bucket
drivers/usb
Inferred role
Driver Families: build/configuration rule
Status
atlas-only

Why This File Exists

Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.

Dependency Surface

Detected Declarations

Annotated Snippet

# SPDX-License-Identifier: GPL-2.0
#
# USB Gadget support on a system involves
#    (a) a peripheral controller, and
#    (b) the gadget driver using it.
#
# NOTE:  Gadget support ** DOES NOT ** depend on host-side CONFIG_USB !!
#
#  - Host systems (like PCs) need CONFIG_USB (with "A" jacks).
#  - Peripherals (like PDAs) need CONFIG_USB_GADGET (with "B" jacks).
#  - Some systems have both kinds of controllers.
#
# With help from a special transceiver and a "Mini-AB" jack, systems with
# both kinds of controller can also support "USB On-the-Go" (CONFIG_USB_OTG).
#
# A Linux "Gadget Driver" talks to the USB Peripheral Controller
# driver through the abstract "gadget" API.  Some other operating
# systems call these "client" drivers, of which "class drivers"
# are a subset (implementing a USB device class specification).
# A gadget driver implements one or more USB functions using
# the peripheral hardware.
#
# Gadget drivers are hardware-neutral, or "platform independent",
# except that they sometimes must understand quirks or limitations
# of the particular controllers they work with.  For example, when
# a controller doesn't support alternate configurations or provide
# enough of the right types of endpoints, the gadget driver might
# not be able work with that controller, or might need to implement
# a less common variant of a device class protocol.
#
# The available choices each represent a single precomposed USB
# gadget configuration. In the device model, each option contains
# both the device instantiation as a child for a USB gadget
# controller, and the relevant drivers for each function declared
# by the device.

menu "USB Gadget precomposed configurations"

config USB_ZERO
	tristate "Gadget Zero (DEVELOPMENT)"
	select USB_LIBCOMPOSITE
	select USB_F_SS_LB
	help
	  Gadget Zero is a two-configuration device.  It either sinks and
	  sources bulk data; or it loops back a configurable number of
	  transfers.  It also implements control requests, for "chapter 9"
	  conformance.  The driver needs only two bulk-capable endpoints, so
	  it can work on top of most device-side usb controllers.  It's
	  useful for testing, and is also a working example showing how
	  USB "gadget drivers" can be written.

	  Make this be the first driver you try using on top of any new
	  USB peripheral controller driver.  Then you can use host-side
	  test software, like the "usbtest" driver, to put your hardware
	  and its driver through a basic set of functional tests.

	  Gadget Zero also works with the host-side "usb-skeleton" driver,
	  and with many kinds of host-side test software.  You may need
	  to tweak product and vendor IDs before host software knows about
	  this device, and arrange to select an appropriate configuration.

	  Say "y" to link the driver statically, or "m" to build a
	  dynamically linked module called "g_zero".

config USB_ZERO_HNPTEST
	bool "HNP Test Device"
	depends on USB_ZERO && USB_OTG
	help
	  You can configure this device to enumerate using the device
	  identifiers of the USB-OTG test device.  That means that when

Annotation

Implementation Notes