usb: gadget: move choice ... endchoice to legacy/Kconfig

drivers/usb/gadget/Kconfig includes drivers/usb/gadget/legacy/Kconfig
inside the 'choice' block. The current Kconfig allows this, but I'd
like to discourage this usage.

People tend to mess up the structure without noticing that entire
drivers/usb/gadget/legacy/Kconfig is placed in the choice context.
In fact, legacy/Kconfig mixes up bool and tristate in the choice,
and creates nested choice, etc.

This commit does not change the behavior, but it will help people
notice how badly this Kconfig file is written.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20191211073857.16780-1-masahiroy@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Masahiro Yamada 2019-12-11 16:38:57 +09:00 committed by Greg Kroah-Hartman
parent fcc8469829
commit 10e5e6c249
2 changed files with 28 additions and 28 deletions

View File

@ -483,34 +483,6 @@ 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 precomposed configurations"
default USB_ETH
optional
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.
The available choices each represent a single precomposed USB
gadget configuration. In the device model, each option contains
both the device instantiation as a child for a USB gadget
controller, and the relevant drivers for each function declared
by the device.
source "drivers/usb/gadget/legacy/Kconfig"
endchoice
endif # USB_GADGET

View File

@ -14,6 +14,32 @@
# both kinds of controller can also support "USB On-the-Go" (CONFIG_USB_OTG).
#
choice
tristate "USB Gadget precomposed configurations"
default USB_ETH
optional
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.
The available choices each represent a single precomposed USB
gadget configuration. In the device model, each option contains
both the device instantiation as a child for a USB gadget
controller, and the relevant drivers for each function declared
by the device.
config USB_ZERO
tristate "Gadget Zero (DEVELOPMENT)"
select USB_LIBCOMPOSITE
@ -489,3 +515,5 @@ config USB_G_WEBCAM
Say "y" to link the driver statically, or "m" to build a
dynamically linked module called "g_webcam".
endchoice