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>

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 3c3f31c..2ea3fc3 100644 (file)
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -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