507 lines
15 KiB
Text
507 lines
15 KiB
Text
|
#
|
||
|
# 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).
|
||
|
#
|
||
|
|
||
|
menuconfig USB_GADGET
|
||
|
tristate "USB Gadget Support"
|
||
|
select NLS
|
||
|
help
|
||
|
USB is a master/slave protocol, organized with one master
|
||
|
host (such as a PC) controlling up to 127 peripheral devices.
|
||
|
The USB hardware is asymmetric, which makes it easier to set up:
|
||
|
you can't connect a "to-the-host" connector to a peripheral.
|
||
|
|
||
|
Linux can run in the host, or in the peripheral. In both cases
|
||
|
you need a low level bus controller driver, and some software
|
||
|
talking to it. Peripheral controllers are often discrete silicon,
|
||
|
or are integrated with the CPU in a microcontroller. The more
|
||
|
familiar host side controllers have names like "EHCI", "OHCI",
|
||
|
or "UHCI", and are usually integrated into southbridges on PC
|
||
|
motherboards.
|
||
|
|
||
|
Enable this configuration option if you want to run Linux inside
|
||
|
a USB peripheral device. Configure one hardware driver for your
|
||
|
peripheral/device side bus controller, and a "gadget driver" for
|
||
|
your peripheral protocol. (If you use modular gadget drivers,
|
||
|
you may configure more than one.)
|
||
|
|
||
|
If in doubt, say "N" and don't enable these drivers; most people
|
||
|
don't have this kind of hardware (except maybe inside Linux PDAs).
|
||
|
|
||
|
For more information, see <http://www.linux-usb.org/gadget> and
|
||
|
the kernel DocBook documentation for this API.
|
||
|
|
||
|
if USB_GADGET
|
||
|
|
||
|
config USB_GADGET_DEBUG
|
||
|
boolean "Debugging messages (DEVELOPMENT)"
|
||
|
depends on DEBUG_KERNEL
|
||
|
help
|
||
|
Many controller and gadget drivers will print some debugging
|
||
|
messages if you use this option to ask for those messages.
|
||
|
|
||
|
Avoid enabling these messages, even if you're actively
|
||
|
debugging such a driver. Many drivers will emit so many
|
||
|
messages that the driver timings are affected, which will
|
||
|
either create new failure modes or remove the one you're
|
||
|
trying to track down. Never enable these messages for a
|
||
|
production build.
|
||
|
|
||
|
config USB_GADGET_VERBOSE
|
||
|
bool "Verbose debugging Messages (DEVELOPMENT)"
|
||
|
depends on USB_GADGET_DEBUG
|
||
|
help
|
||
|
Many controller and gadget drivers will print verbose debugging
|
||
|
messages if you use this option to ask for those messages.
|
||
|
|
||
|
Avoid enabling these messages, even if you're actively
|
||
|
debugging such a driver. Many drivers will emit so many
|
||
|
messages that the driver timings are affected, which will
|
||
|
either create new failure modes or remove the one you're
|
||
|
trying to track down. Never enable these messages for a
|
||
|
production build.
|
||
|
|
||
|
config USB_GADGET_DEBUG_FILES
|
||
|
boolean "Debugging information files (DEVELOPMENT)"
|
||
|
depends on PROC_FS
|
||
|
help
|
||
|
Some of the drivers in the "gadget" framework can expose
|
||
|
debugging information in files such as /proc/driver/udc
|
||
|
(for a peripheral controller). The information in these
|
||
|
files may help when you're troubleshooting or bringing up a
|
||
|
driver on a new board. Enable these files by choosing "Y"
|
||
|
here. If in doubt, or to conserve kernel memory, say "N".
|
||
|
|
||
|
config USB_GADGET_DEBUG_FS
|
||
|
boolean "Debugging information files in debugfs (DEVELOPMENT)"
|
||
|
depends on DEBUG_FS
|
||
|
help
|
||
|
Some of the drivers in the "gadget" framework can expose
|
||
|
debugging information in files under /sys/kernel/debug/.
|
||
|
The information in these files may help when you're
|
||
|
troubleshooting or bringing up a driver on a new board.
|
||
|
Enable these files by choosing "Y" here. If in doubt, or
|
||
|
to conserve kernel memory, say "N".
|
||
|
|
||
|
config USB_GADGET_VBUS_DRAW
|
||
|
int "Maximum VBUS Power usage (2-500 mA)"
|
||
|
range 2 500
|
||
|
default 2
|
||
|
help
|
||
|
Some devices need to draw power from USB when they are
|
||
|
configured, perhaps to operate circuitry or to recharge
|
||
|
batteries. This is in addition to any local power supply,
|
||
|
such as an AC adapter or batteries.
|
||
|
|
||
|
Enter the maximum power your device draws through USB, in
|
||
|
milliAmperes. The permitted range of values is 2 - 500 mA;
|
||
|
0 mA would be legal, but can make some hosts misbehave.
|
||
|
|
||
|
This value will be used except for system-specific gadget
|
||
|
drivers that have more specific information.
|
||
|
|
||
|
config USB_GADGET_STORAGE_NUM_BUFFERS
|
||
|
int "Number of storage pipeline buffers"
|
||
|
range 2 4
|
||
|
default 2
|
||
|
help
|
||
|
Usually 2 buffers are enough to establish a good buffering
|
||
|
pipeline. The number may be increased in order to compensate
|
||
|
for a bursty VFS behaviour. For instance there may be CPU wake up
|
||
|
latencies that makes the VFS to appear bursty in a system with
|
||
|
an CPU on-demand governor. Especially if DMA is doing IO to
|
||
|
offload the CPU. In this case the CPU will go into power
|
||
|
save often and spin up occasionally to move data within VFS.
|
||
|
If selecting USB_GADGET_DEBUG_FILES this value may be set by
|
||
|
a module parameter as well.
|
||
|
If unsure, say 2.
|
||
|
|
||
|
source "drivers/usb/gadget/udc/Kconfig"
|
||
|
|
||
|
#
|
||
|
# USB Gadget Drivers
|
||
|
#
|
||
|
|
||
|
# composite based drivers
|
||
|
config USB_LIBCOMPOSITE
|
||
|
tristate
|
||
|
select CONFIGFS_FS
|
||
|
depends on USB_GADGET
|
||
|
|
||
|
config USB_F_ACM
|
||
|
tristate
|
||
|
|
||
|
config USB_F_SS_LB
|
||
|
tristate
|
||
|
|
||
|
config USB_U_SERIAL
|
||
|
tristate
|
||
|
|
||
|
config USB_U_ETHER
|
||
|
tristate
|
||
|
|
||
|
config USB_F_SERIAL
|
||
|
tristate
|
||
|
|
||
|
config USB_F_OBEX
|
||
|
tristate
|
||
|
|
||
|
config USB_F_NCM
|
||
|
tristate
|
||
|
|
||
|
config USB_F_ECM
|
||
|
tristate
|
||
|
|
||
|
config USB_F_PHONET
|
||
|
tristate
|
||
|
|
||
|
config USB_F_EEM
|
||
|
tristate
|
||
|
|
||
|
config USB_F_SUBSET
|
||
|
tristate
|
||
|
|
||
|
config USB_F_RNDIS
|
||
|
tristate
|
||
|
|
||
|
config USB_F_MASS_STORAGE
|
||
|
tristate
|
||
|
|
||
|
config USB_F_FS
|
||
|
tristate
|
||
|
|
||
|
config USB_F_UAC1
|
||
|
tristate
|
||
|
|
||
|
config USB_F_UAC2
|
||
|
tristate
|
||
|
|
||
|
config USB_F_UVC
|
||
|
tristate
|
||
|
|
||
|
config USB_F_MTP
|
||
|
tristate
|
||
|
|
||
|
config USB_F_PTP
|
||
|
tristate
|
||
|
|
||
|
config USB_F_AUDIO_SRC
|
||
|
tristate
|
||
|
|
||
|
config USB_F_ACC
|
||
|
tristate
|
||
|
|
||
|
choice
|
||
|
tristate "USB Gadget Drivers"
|
||
|
default USB_ETH
|
||
|
help
|
||
|
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.
|
||
|
|
||
|
# this first set of drivers all depend on bulk-capable hardware.
|
||
|
|
||
|
config USB_CONFIGFS
|
||
|
tristate "USB functions configurable through configfs"
|
||
|
select USB_LIBCOMPOSITE
|
||
|
help
|
||
|
A Linux USB "gadget" can be set up through configfs.
|
||
|
If this is the case, the USB functions (which from the host's
|
||
|
perspective are seen as interfaces) and configurations are
|
||
|
specified simply by creating appropriate directories in configfs.
|
||
|
Associating functions with configurations is done by creating
|
||
|
appropriate symbolic links.
|
||
|
For more information see Documentation/usb/gadget_configfs.txt.
|
||
|
|
||
|
config USB_CONFIGFS_SERIAL
|
||
|
boolean "Generic serial bulk in/out"
|
||
|
depends on USB_CONFIGFS
|
||
|
depends on TTY
|
||
|
select USB_U_SERIAL
|
||
|
select USB_F_SERIAL
|
||
|
help
|
||
|
The function talks to the Linux-USB generic serial driver.
|
||
|
|
||
|
config USB_CONFIGFS_ACM
|
||
|
boolean "Abstract Control Model (CDC ACM)"
|
||
|
depends on USB_CONFIGFS
|
||
|
depends on TTY
|
||
|
select USB_U_SERIAL
|
||
|
select USB_F_ACM
|
||
|
help
|
||
|
ACM serial link. This function can be used to interoperate with
|
||
|
MS-Windows hosts or with the Linux-USB "cdc-acm" driver.
|
||
|
|
||
|
config USB_CONFIGFS_OBEX
|
||
|
boolean "Object Exchange Model (CDC OBEX)"
|
||
|
depends on USB_CONFIGFS
|
||
|
depends on TTY
|
||
|
select USB_U_SERIAL
|
||
|
select USB_F_OBEX
|
||
|
help
|
||
|
You will need a user space OBEX server talking to /dev/ttyGS*,
|
||
|
since the kernel itself doesn't implement the OBEX protocol.
|
||
|
|
||
|
config USB_CONFIGFS_NCM
|
||
|
boolean "Network Control Model (CDC NCM)"
|
||
|
depends on USB_CONFIGFS
|
||
|
depends on NET
|
||
|
select USB_U_ETHER
|
||
|
select USB_F_NCM
|
||
|
help
|
||
|
NCM is an advanced protocol for Ethernet encapsulation, allows
|
||
|
grouping of several ethernet frames into one USB transfer and
|
||
|
different alignment possibilities.
|
||
|
|
||
|
config USB_CONFIGFS_ECM
|
||
|
boolean "Ethernet Control Model (CDC ECM)"
|
||
|
depends on USB_CONFIGFS
|
||
|
depends on NET
|
||
|
select USB_U_ETHER
|
||
|
select USB_F_ECM
|
||
|
help
|
||
|
The "Communication Device Class" (CDC) Ethernet Control Model.
|
||
|
That protocol is often avoided with pure Ethernet adapters, in
|
||
|
favor of simpler vendor-specific hardware, but is widely
|
||
|
supported by firmware for smart network devices.
|
||
|
|
||
|
config USB_CONFIGFS_ECM_SUBSET
|
||
|
boolean "Ethernet Control Model (CDC ECM) subset"
|
||
|
depends on USB_CONFIGFS
|
||
|
depends on NET
|
||
|
select USB_U_ETHER
|
||
|
select USB_F_SUBSET
|
||
|
help
|
||
|
On hardware that can't implement the full protocol,
|
||
|
a simple CDC subset is used, placing fewer demands on USB.
|
||
|
|
||
|
config USB_CONFIGFS_RNDIS
|
||
|
bool "RNDIS"
|
||
|
depends on USB_CONFIGFS
|
||
|
depends on NET
|
||
|
select USB_U_ETHER
|
||
|
select USB_F_RNDIS
|
||
|
help
|
||
|
Microsoft Windows XP bundles the "Remote NDIS" (RNDIS) protocol,
|
||
|
and Microsoft provides redistributable binary RNDIS drivers for
|
||
|
older versions of Windows.
|
||
|
|
||
|
To make MS-Windows work with this, use Documentation/usb/linux.inf
|
||
|
as the "driver info file". For versions of MS-Windows older than
|
||
|
XP, you'll need to download drivers from Microsoft's website; a URL
|
||
|
is given in comments found in that info file.
|
||
|
|
||
|
config USB_CONFIGFS_EEM
|
||
|
bool "Ethernet Emulation Model (EEM)"
|
||
|
depends on USB_CONFIGFS
|
||
|
depends on NET
|
||
|
select USB_U_ETHER
|
||
|
select USB_F_EEM
|
||
|
help
|
||
|
CDC EEM is a newer USB standard that is somewhat simpler than CDC ECM
|
||
|
and therefore can be supported by more hardware. Technically ECM and
|
||
|
EEM are designed for different applications. The ECM model extends
|
||
|
the network interface to the target (e.g. a USB cable modem), and the
|
||
|
EEM model is for mobile devices to communicate with hosts using
|
||
|
ethernet over USB. For Linux gadgets, however, the interface with
|
||
|
the host is the same (a usbX device), so the differences are minimal.
|
||
|
|
||
|
config USB_CONFIGFS_PHONET
|
||
|
boolean "Phonet protocol"
|
||
|
depends on USB_CONFIGFS
|
||
|
depends on NET
|
||
|
depends on PHONET
|
||
|
select USB_U_ETHER
|
||
|
select USB_F_PHONET
|
||
|
help
|
||
|
The Phonet protocol implementation for USB device.
|
||
|
|
||
|
config USB_CONFIGFS_MASS_STORAGE
|
||
|
boolean "Mass storage"
|
||
|
depends on USB_CONFIGFS
|
||
|
depends on BLOCK
|
||
|
select USB_F_MASS_STORAGE
|
||
|
help
|
||
|
The Mass Storage Gadget acts as a USB Mass Storage disk drive.
|
||
|
As its storage repository it can use a regular file or a block
|
||
|
device (in much the same way as the "loop" device driver),
|
||
|
specified as a module parameter or sysfs option.
|
||
|
|
||
|
config USB_CONFIGFS_F_LB_SS
|
||
|
boolean "Loopback and sourcesink function (for testing)"
|
||
|
depends on USB_CONFIGFS
|
||
|
select USB_F_SS_LB
|
||
|
help
|
||
|
Loopback function loops back a configurable number of transfers.
|
||
|
Sourcesink function either sinks and sources bulk data.
|
||
|
It also implements control requests, for "chapter 9" conformance.
|
||
|
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.
|
||
|
|
||
|
config USB_CONFIGFS_F_FS
|
||
|
boolean "Function filesystem (FunctionFS)"
|
||
|
depends on USB_CONFIGFS
|
||
|
select USB_F_FS
|
||
|
help
|
||
|
The Function Filesystem (FunctionFS) lets one create USB
|
||
|
composite functions in user space in the same way GadgetFS
|
||
|
lets one create USB gadgets in user space. This allows creation
|
||
|
of composite gadgets such that some of the functions are
|
||
|
implemented in kernel space (for instance Ethernet, serial or
|
||
|
mass storage) and other are implemented in user space.
|
||
|
|
||
|
config USB_CONFIGFS_F_MTP
|
||
|
boolean "MTP gadget"
|
||
|
depends on USB_CONFIGFS
|
||
|
select USB_F_MTP
|
||
|
help
|
||
|
USB gadget MTP support
|
||
|
|
||
|
config USB_CONFIGFS_F_PTP
|
||
|
boolean "PTP gadget"
|
||
|
depends on USB_CONFIGFS && USB_CONFIGFS_F_MTP
|
||
|
select USB_F_PTP
|
||
|
help
|
||
|
USB gadget PTP support
|
||
|
|
||
|
config USB_CONFIGFS_F_ACC
|
||
|
boolean "Accessory gadget"
|
||
|
depends on USB_CONFIGFS
|
||
|
select USB_F_ACC
|
||
|
help
|
||
|
USB gadget Accessory support
|
||
|
|
||
|
config USB_CONFIGFS_F_AUDIO_SRC
|
||
|
boolean "Audio Source gadget"
|
||
|
depends on USB_CONFIGFS && USB_CONFIGFS_F_ACC
|
||
|
select USB_F_AUDIO_SRC
|
||
|
help
|
||
|
USB gadget Audio Source support
|
||
|
|
||
|
config USB_CONFIGFS_UEVENT
|
||
|
boolean "Uevent notification of Gadget state"
|
||
|
depends on USB_CONFIGFS
|
||
|
help
|
||
|
Enable uevent notifications to userspace when the gadget
|
||
|
state changes. The gadget can be in any of the following
|
||
|
three states: "CONNECTED/DISCONNECTED/CONFIGURED"
|
||
|
|
||
|
config USB_G_ANDROID
|
||
|
boolean "Android Composite Gadget"
|
||
|
select USB_F_ACM
|
||
|
select USB_F_AUDIO_SRC
|
||
|
select USB_F_SERIAL
|
||
|
select USB_LIBCOMPOSITE
|
||
|
select USB_F_FS
|
||
|
select USB_U_SERIAL
|
||
|
select USB_F_ECM
|
||
|
select USB_F_NCM
|
||
|
select USB_F_MASS_STORAGE
|
||
|
select USB_F_UAC1 if SND_PCM
|
||
|
help
|
||
|
The Android Composite Gadget supports multiple USB
|
||
|
functions: adb, acm, mass storage, mtp, accessory
|
||
|
and rndis.
|
||
|
Each function can be configured and enabled/disabled
|
||
|
dynamically from userspace through a sysfs interface.
|
||
|
|
||
|
config USB_ANDROID_SAMSUNG_COMPOSITE
|
||
|
boolean "Samsung Composite function"
|
||
|
depends on USB_G_ANDROID
|
||
|
help
|
||
|
Provides SAMSUNG composite driver.
|
||
|
It also provides KIES connection and
|
||
|
Multi Configuration.
|
||
|
If you enable this option, android composite will be changed.
|
||
|
|
||
|
config USB_DUN_SUPPORT
|
||
|
boolean "DUN support function"
|
||
|
depends on USB_G_ANDROID
|
||
|
help
|
||
|
Provides USB modem serial driver.
|
||
|
This function makes connection to acm from data router.
|
||
|
It uses misc register.
|
||
|
Support fops : open, close, release, read, poll, llseek, ioctl
|
||
|
|
||
|
config USB_ANDROID_SAMSUNG_MTP
|
||
|
boolean "Samsung MTP function"
|
||
|
depends on USB_G_ANDROID && !SEC_FACTORY
|
||
|
help
|
||
|
Provides Media Transfer Protocol (MTP) support
|
||
|
for samsung gadget driver.
|
||
|
If you enable this option,
|
||
|
google mtp will be changed to samsung mtp.
|
||
|
|
||
|
config USB_ANDROID_SAMSUNG_SIDESYNC
|
||
|
boolean "Samsung SideSync function"
|
||
|
depends on USB_G_ANDROID
|
||
|
help
|
||
|
Provides SideSync support
|
||
|
for samsung gadget driver.
|
||
|
If you enable this option,
|
||
|
SideSync will be able to be used.
|
||
|
|
||
|
config USB_LOCK_SUPPORT_FOR_MDM
|
||
|
boolean "Samsung USB_LOCK function for MDM"
|
||
|
depends on USB_G_ANDROID
|
||
|
help
|
||
|
Support USB lock for SDS MDM function.
|
||
|
If you enable this option,
|
||
|
USB is not connected to the work in office.
|
||
|
Of employees who have installed MDM(SDS).
|
||
|
|
||
|
config USB_RNDIS_VZW_REQ
|
||
|
boolean "Samsung USB RNDIS 5.x function"
|
||
|
depends on USB_G_ANDROID
|
||
|
help
|
||
|
Provides USB RNDIS version 5.x support
|
||
|
for samsung gadget driver.
|
||
|
If you enable this option,
|
||
|
you can connect via RNDIS 5.x.
|
||
|
It's VZW carrier concept.
|
||
|
|
||
|
config USB_NCM_SUPPORT_MTU_CHANGE
|
||
|
boolean "Samsung NCM MTU Change function"
|
||
|
depends on USB_G_ANDROID
|
||
|
help
|
||
|
Provides NCM MTU Change support
|
||
|
for samsung gadget driver.
|
||
|
If you enable this option,
|
||
|
NCM MTU Change will be able to be used.
|
||
|
|
||
|
config USB_ANDROID_RNDIS_DWORD_ALIGNED
|
||
|
boolean "Use double word aligned"
|
||
|
depends on USB_G_ANDROID
|
||
|
help
|
||
|
Provides dword aligned for DMA controller.
|
||
|
|
||
|
source "drivers/usb/gadget/legacy/Kconfig"
|
||
|
|
||
|
endchoice
|
||
|
|
||
|
endif # USB_GADGET
|