Merge tag 'media/v3.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab...
[firefly-linux-kernel-4.4.55.git] / drivers / usb / gadget / Kconfig
1 #
2 # USB Gadget support on a system involves
3 #    (a) a peripheral controller, and
4 #    (b) the gadget driver using it.
5 #
6 # NOTE:  Gadget support ** DOES NOT ** depend on host-side CONFIG_USB !!
7 #
8 #  - Host systems (like PCs) need CONFIG_USB (with "A" jacks).
9 #  - Peripherals (like PDAs) need CONFIG_USB_GADGET (with "B" jacks).
10 #  - Some systems have both kinds of controllers.
11 #
12 # With help from a special transceiver and a "Mini-AB" jack, systems with
13 # both kinds of controller can also support "USB On-the-Go" (CONFIG_USB_OTG).
14 #
15
16 menuconfig USB_GADGET
17         tristate "USB Gadget Support"
18         select NLS
19         help
20            USB is a master/slave protocol, organized with one master
21            host (such as a PC) controlling up to 127 peripheral devices.
22            The USB hardware is asymmetric, which makes it easier to set up:
23            you can't connect a "to-the-host" connector to a peripheral.
24
25            Linux can run in the host, or in the peripheral.  In both cases
26            you need a low level bus controller driver, and some software
27            talking to it.  Peripheral controllers are often discrete silicon,
28            or are integrated with the CPU in a microcontroller.  The more
29            familiar host side controllers have names like "EHCI", "OHCI",
30            or "UHCI", and are usually integrated into southbridges on PC
31            motherboards.
32
33            Enable this configuration option if you want to run Linux inside
34            a USB peripheral device.  Configure one hardware driver for your
35            peripheral/device side bus controller, and a "gadget driver" for
36            your peripheral protocol.  (If you use modular gadget drivers,
37            you may configure more than one.)
38
39            If in doubt, say "N" and don't enable these drivers; most people
40            don't have this kind of hardware (except maybe inside Linux PDAs).
41
42            For more information, see <http://www.linux-usb.org/gadget> and
43            the kernel DocBook documentation for this API.
44
45 if USB_GADGET
46
47 config USB_GADGET_DEBUG
48         boolean "Debugging messages (DEVELOPMENT)"
49         depends on DEBUG_KERNEL
50         help
51            Many controller and gadget drivers will print some debugging
52            messages if you use this option to ask for those messages.
53
54            Avoid enabling these messages, even if you're actively
55            debugging such a driver.  Many drivers will emit so many
56            messages that the driver timings are affected, which will
57            either create new failure modes or remove the one you're
58            trying to track down.  Never enable these messages for a
59            production build.
60
61 config USB_GADGET_VERBOSE
62         bool "Verbose debugging Messages (DEVELOPMENT)"
63         depends on USB_GADGET_DEBUG
64         help
65            Many controller and gadget drivers will print verbose debugging
66            messages if you use this option to ask for those messages.
67
68            Avoid enabling these messages, even if you're actively
69            debugging such a driver.  Many drivers will emit so many
70            messages that the driver timings are affected, which will
71            either create new failure modes or remove the one you're
72            trying to track down.  Never enable these messages for a
73            production build.
74
75 config USB_GADGET_DEBUG_FILES
76         boolean "Debugging information files (DEVELOPMENT)"
77         depends on PROC_FS
78         help
79            Some of the drivers in the "gadget" framework can expose
80            debugging information in files such as /proc/driver/udc
81            (for a peripheral controller).  The information in these
82            files may help when you're troubleshooting or bringing up a
83            driver on a new board.   Enable these files by choosing "Y"
84            here.  If in doubt, or to conserve kernel memory, say "N".
85
86 config USB_GADGET_DEBUG_FS
87         boolean "Debugging information files in debugfs (DEVELOPMENT)"
88         depends on DEBUG_FS
89         help
90            Some of the drivers in the "gadget" framework can expose
91            debugging information in files under /sys/kernel/debug/.
92            The information in these files may help when you're
93            troubleshooting or bringing up a driver on a new board.
94            Enable these files by choosing "Y" here.  If in doubt, or
95            to conserve kernel memory, say "N".
96
97 config USB_GADGET_VBUS_DRAW
98         int "Maximum VBUS Power usage (2-500 mA)"
99         range 2 500
100         default 2
101         help
102            Some devices need to draw power from USB when they are
103            configured, perhaps to operate circuitry or to recharge
104            batteries.  This is in addition to any local power supply,
105            such as an AC adapter or batteries.
106
107            Enter the maximum power your device draws through USB, in
108            milliAmperes.  The permitted range of values is 2 - 500 mA;
109            0 mA would be legal, but can make some hosts misbehave.
110
111            This value will be used except for system-specific gadget
112            drivers that have more specific information.
113
114 config USB_GADGET_STORAGE_NUM_BUFFERS
115         int "Number of storage pipeline buffers"
116         range 2 4
117         default 2
118         help
119            Usually 2 buffers are enough to establish a good buffering
120            pipeline. The number may be increased in order to compensate
121            for a bursty VFS behaviour. For instance there may be CPU wake up
122            latencies that makes the VFS to appear bursty in a system with
123            an CPU on-demand governor. Especially if DMA is doing IO to
124            offload the CPU. In this case the CPU will go into power
125            save often and spin up occasionally to move data within VFS.
126            If selecting USB_GADGET_DEBUG_FILES this value may be set by
127            a module parameter as well.
128            If unsure, say 2.
129
130 source "drivers/usb/gadget/udc/Kconfig"
131
132 #
133 # USB Gadget Drivers
134 #
135
136 # composite based drivers
137 config USB_LIBCOMPOSITE
138         tristate
139         select CONFIGFS_FS
140         depends on USB_GADGET
141
142 config USB_F_ACM
143         tristate
144
145 config USB_F_SS_LB
146         tristate
147
148 config USB_U_SERIAL
149         tristate
150
151 config USB_U_ETHER
152         tristate
153
154 config USB_F_SERIAL
155         tristate
156
157 config USB_F_OBEX
158         tristate
159
160 config USB_F_NCM
161         tristate
162
163 config USB_F_ECM
164         tristate
165
166 config USB_F_PHONET
167         tristate
168
169 config USB_F_EEM
170         tristate
171
172 config USB_F_SUBSET
173         tristate
174
175 config USB_F_RNDIS
176         tristate
177
178 config USB_F_MASS_STORAGE
179         tristate
180
181 config USB_F_FS
182         tristate
183
184 choice
185         tristate "USB Gadget Drivers"
186         default USB_ETH
187         help
188           A Linux "Gadget Driver" talks to the USB Peripheral Controller
189           driver through the abstract "gadget" API.  Some other operating
190           systems call these "client" drivers, of which "class drivers"
191           are a subset (implementing a USB device class specification).
192           A gadget driver implements one or more USB functions using
193           the peripheral hardware.
194
195           Gadget drivers are hardware-neutral, or "platform independent",
196           except that they sometimes must understand quirks or limitations
197           of the particular controllers they work with.  For example, when
198           a controller doesn't support alternate configurations or provide
199           enough of the right types of endpoints, the gadget driver might
200           not be able work with that controller, or might need to implement
201           a less common variant of a device class protocol.
202
203 # this first set of drivers all depend on bulk-capable hardware.
204
205 config USB_CONFIGFS
206         tristate "USB functions configurable through configfs"
207         select USB_LIBCOMPOSITE
208         help
209           A Linux USB "gadget" can be set up through configfs.
210           If this is the case, the USB functions (which from the host's
211           perspective are seen as interfaces) and configurations are
212           specified simply by creating appropriate directories in configfs.
213           Associating functions with configurations is done by creating
214           appropriate symbolic links.
215           For more information see Documentation/usb/gadget_configfs.txt.
216
217 config USB_CONFIGFS_SERIAL
218         boolean "Generic serial bulk in/out"
219         depends on USB_CONFIGFS
220         depends on TTY
221         select USB_U_SERIAL
222         select USB_F_SERIAL
223         help
224           The function talks to the Linux-USB generic serial driver.
225
226 config USB_CONFIGFS_ACM
227         boolean "Abstract Control Model (CDC ACM)"
228         depends on USB_CONFIGFS
229         depends on TTY
230         select USB_U_SERIAL
231         select USB_F_ACM
232         help
233           ACM serial link.  This function can be used to interoperate with
234           MS-Windows hosts or with the Linux-USB "cdc-acm" driver.
235
236 config USB_CONFIGFS_OBEX
237         boolean "Object Exchange Model (CDC OBEX)"
238         depends on USB_CONFIGFS
239         depends on TTY
240         select USB_U_SERIAL
241         select USB_F_OBEX
242         help
243           You will need a user space OBEX server talking to /dev/ttyGS*,
244           since the kernel itself doesn't implement the OBEX protocol.
245
246 config USB_CONFIGFS_NCM
247         boolean "Network Control Model (CDC NCM)"
248         depends on USB_CONFIGFS
249         depends on NET
250         select USB_U_ETHER
251         select USB_F_NCM
252         help
253           NCM is an advanced protocol for Ethernet encapsulation, allows
254           grouping of several ethernet frames into one USB transfer and
255           different alignment possibilities.
256
257 config USB_CONFIGFS_ECM
258         boolean "Ethernet Control Model (CDC ECM)"
259         depends on USB_CONFIGFS
260         depends on NET
261         select USB_U_ETHER
262         select USB_F_ECM
263         help
264           The "Communication Device Class" (CDC) Ethernet Control Model.
265           That protocol is often avoided with pure Ethernet adapters, in
266           favor of simpler vendor-specific hardware, but is widely
267           supported by firmware for smart network devices.
268
269 config USB_CONFIGFS_ECM_SUBSET
270         boolean "Ethernet Control Model (CDC ECM) subset"
271         depends on USB_CONFIGFS
272         depends on NET
273         select USB_U_ETHER
274         select USB_F_SUBSET
275         help
276           On hardware that can't implement the full protocol,
277           a simple CDC subset is used, placing fewer demands on USB.
278
279 config USB_CONFIGFS_RNDIS
280         bool "RNDIS"
281         depends on USB_CONFIGFS
282         depends on NET
283         select USB_U_ETHER
284         select USB_F_RNDIS
285         help
286            Microsoft Windows XP bundles the "Remote NDIS" (RNDIS) protocol,
287            and Microsoft provides redistributable binary RNDIS drivers for
288            older versions of Windows.
289
290            To make MS-Windows work with this, use Documentation/usb/linux.inf
291            as the "driver info file".  For versions of MS-Windows older than
292            XP, you'll need to download drivers from Microsoft's website; a URL
293            is given in comments found in that info file.
294
295 config USB_CONFIGFS_EEM
296         bool "Ethernet Emulation Model (EEM)"
297         depends on USB_CONFIGFS
298         depends on NET
299         select USB_U_ETHER
300         select USB_F_EEM
301         help
302           CDC EEM is a newer USB standard that is somewhat simpler than CDC ECM
303           and therefore can be supported by more hardware.  Technically ECM and
304           EEM are designed for different applications.  The ECM model extends
305           the network interface to the target (e.g. a USB cable modem), and the
306           EEM model is for mobile devices to communicate with hosts using
307           ethernet over USB.  For Linux gadgets, however, the interface with
308           the host is the same (a usbX device), so the differences are minimal.
309
310 config USB_CONFIGFS_PHONET
311         boolean "Phonet protocol"
312         depends on USB_CONFIGFS
313         depends on NET
314         depends on PHONET
315         select USB_U_ETHER
316         select USB_F_PHONET
317         help
318           The Phonet protocol implementation for USB device.
319
320 config USB_CONFIGFS_MASS_STORAGE
321         boolean "Mass storage"
322         depends on USB_CONFIGFS
323         depends on BLOCK
324         select USB_F_MASS_STORAGE
325         help
326           The Mass Storage Gadget acts as a USB Mass Storage disk drive.
327           As its storage repository it can use a regular file or a block
328           device (in much the same way as the "loop" device driver),
329           specified as a module parameter or sysfs option.
330
331 config USB_CONFIGFS_F_LB_SS
332         boolean "Loopback and sourcesink function (for testing)"
333         depends on USB_CONFIGFS
334         select USB_F_SS_LB
335         help
336           Loopback function loops back a configurable number of transfers.
337           Sourcesink function either sinks and sources bulk data.
338           It also implements control requests, for "chapter 9" conformance.
339           Make this be the first driver you try using on top of any new
340           USB peripheral controller driver.  Then you can use host-side
341           test software, like the "usbtest" driver, to put your hardware
342           and its driver through a basic set of functional tests.
343
344 config USB_CONFIGFS_F_FS
345         boolean "Function filesystem (FunctionFS)"
346         depends on USB_CONFIGFS
347         select USB_F_FS
348         help
349           The Function Filesystem (FunctionFS) lets one create USB
350           composite functions in user space in the same way GadgetFS
351           lets one create USB gadgets in user space.  This allows creation
352           of composite gadgets such that some of the functions are
353           implemented in kernel space (for instance Ethernet, serial or
354           mass storage) and other are implemented in user space.
355
356 source "drivers/usb/gadget/legacy/Kconfig"
357
358 endchoice
359
360 endif # USB_GADGET