Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit bc49d1d1 authored by Felipe Balbi's avatar Felipe Balbi
Browse files

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: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
parent 594e121f
Loading
Loading
Loading
Loading
+19 −19
Original line number Diff line number Diff line
@@ -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