This commit removes USB_GADGET_DUALSPEED and USB_GADGET_SUPERSPEED
Kconfig options.  Since now kernel allows many UDC drivers to be
compiled, those options may turn to no longer be valid.  For
instance, if someone decides to build UDC that supports super
speed and UDC that supports high speed only, the latter will be
"assumed" to support super speed since USB_GADGET_SUPERSPEED will
be selected by the former.

The test of whether CONFIG_USB_GADGET_*SPEED was defined was just
an optimisation which removed otherwise dead code (ie. if UDC is
not dual speed, there is no need to handle cases that can happen
if speed is high).  This commit removes those checks.
Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The warning shown up when ran with randconfig,

warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct dependencies (USB_SUPPORT && USB_XHCI_HCD)
Signed-off-by: Njoseph daniel <josephdanielwalter@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

now that we have host support, we must depend
on both sides.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We can decide in runtime if that will be used
or not.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The Designware USB3 IP can be configured with
an internal xHCI. If we're running on such a
version, let's start the xHCI stack.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The DesignWare USB3 is a highly
configurable IP Core which can be
instantiated as Dual-Role Device (DRD),
Peripheral Only and Host Only (XHCI)
configurations.

Several other parameters can be configured
like amount of FIFO space, amount of TX and
RX endpoints, amount of Host Interrupters,
etc.

The current driver has been validated with
a virtual model of version 1.73a of that core
and with an FPGA burned with version 1.83a
of the DRD core. We have support for PCIe
bus, which is used on FPGA prototyping, and
for the OMAP5, more adaptation (or glue)
layers can be easily added and the driver
is half prepared to handle any possible
configuration the HW engineer has chosen
considering we have the information on
one of the GHWPARAMS registers to do
runtime checking of certain features.

More runtime checks can, and should, be added
in order to make this driver even more flexible
with regards to number of endpoints, FIFO sizes,
transfer types, etc.

While this supports only the device side, for
now, we will add support for Host side (xHCI -
see the updated series Sebastian has sent [1])
and OTG after we have it all stabilized.

[1] http://marc.info/?l=linux-usb&m=131341992020339&w=2Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>