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
Родитель 594e121f25
Коммит bc49d1d17d
1 изменённых файлов: 19 добавлений и 19 удалений

Просмотреть файл

@ -209,25 +209,6 @@ config USB_F_PRINTER
config USB_F_TCM
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
@ -475,6 +456,25 @@ config USB_CONFIGFS_F_TCM
Both protocols can work on USB2.0 and USB3.0.
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"
endchoice