usb: gadget: don't couple configfs to legacy gadgets

It's perfectly fine to have all configfs functions
built-in while having modular legacy gadgets. Let's
allow for that.

Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This commit is contained in:
Felipe Balbi 2016-08-26 12:21:34 +03:00
parent 594e121f25
commit bc49d1d17d
1 changed files with 19 additions and 19 deletions

View File

@ -209,25 +209,6 @@ config USB_F_PRINTER
config USB_F_TCM config USB_F_TCM
tristate 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. # this first set of drivers all depend on bulk-capable hardware.
config USB_CONFIGFS config USB_CONFIGFS
@ -475,6 +456,25 @@ config USB_CONFIGFS_F_TCM
Both protocols can work on USB2.0 and USB3.0. Both protocols can work on USB2.0 and USB3.0.
UAS utilizes the USB 3.0 feature called streams support. UAS utilizes the USB 3.0 feature called streams support.
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.
source "drivers/usb/gadget/legacy/Kconfig" source "drivers/usb/gadget/legacy/Kconfig"
endchoice endchoice