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:
parent
594e121f25
commit
bc49d1d17d
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue