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

drivers/usb/gadget/Kconfig

+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