OpenCloudOS-Kernel/drivers/usb/host/Kconfig

732 lines
23 KiB
Plaintext
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0
#
# USB Host Controller Drivers
#
comment "USB Host Controller Drivers"
config USB_C67X00_HCD
tristate "Cypress C67x00 HCD support"
depends on HAS_IOMEM
help
The Cypress C67x00 (EZ-Host/EZ-OTG) chips are dual-role
host/peripheral/OTG USB controllers.
Enable this option to support this chip in host controller mode.
If unsure, say N.
To compile this driver as a module, choose M here: the
module will be called c67x00.
config USB_XHCI_HCD
tristate "xHCI HCD (USB 3.0) support"
usb: host: Host drivers relying on DMA should depend on HAS_DMA If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/usb/host/xhci-plat-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-mtk.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ohci-platform.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ehci-platform.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/ehci-hcd.ko] undefined! Add dependencies on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-22 05:48:47 +08:00
depends on HAS_DMA && HAS_IOMEM
help
The eXtensible Host Controller Interface (xHCI) is standard for USB 3.0
"SuperSpeed" host controller hardware.
To compile this driver as a module, choose M here: the
module will be called xhci-hcd.
if USB_XHCI_HCD
config USB_XHCI_DBGCAP
bool "xHCI support for debug capability"
depends on TTY
help
Say 'Y' to enable the support for the xHCI debug capability. Make
sure that your xHCI host supports the extended debug capability and
you want a TTY serial device based on the xHCI debug capability
before enabling this option. If unsure, say 'N'.
config USB_XHCI_PCI
tristate
depends on USB_PCI
depends on USB_XHCI_PCI_RENESAS || !USB_XHCI_PCI_RENESAS
default y
usb: renesas-xhci: Add the renesas xhci driver This add a new driver for renesas xhci which is basically a firmware loader for uPD720201 and uPD720202 w/o ROM. The xhci-pci driver will invoke this driver for loading/unloading on relevant devices. This patch adds a firmware loader for the uPD720201K8-711-BAC-A and uPD720202K8-711-BAA-A variant. Both of these chips are listed in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as devices which need the firmware loader on page 2 in order to work as they "do not support the External ROM". The "Firmware Download Sequence" is describe in chapter "7.1 FW Download Interface" R19UH0078EJ0500 Rev.5.00 page 131. The firmware "K2013080.mem" is available from a USB3.0 Host to PCIe Adapter (PP2U-E card) "Firmware download" archive. An alternative version can be sourced from Netgear's WNDR4700 GPL archives. The release notes of the PP2U-E's "Firmware Download" ver 2.0.1.3 (2012-06-15) state that the firmware is for the following devices: - uPD720201 ES 2.0 sample whose revision ID is 2. - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3. - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2. [vkoul: fixed comments: used macros for timeout count and delay removed renesas_fw_alive_check cleaned renesas_fw_callback removed recursion for renesas_fw_download add register defines and field names move to a separate file make fw loader as sync probe so that we execute in probe and prevent race make xhci-pci-renesas a seprate module] Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200514122039.300417-3-vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-14 20:20:37 +08:00
config USB_XHCI_PCI_RENESAS
tristate "Support for additional Renesas xHCI controller with firmware"
help
usb: renesas-xhci: Add the renesas xhci driver This add a new driver for renesas xhci which is basically a firmware loader for uPD720201 and uPD720202 w/o ROM. The xhci-pci driver will invoke this driver for loading/unloading on relevant devices. This patch adds a firmware loader for the uPD720201K8-711-BAC-A and uPD720202K8-711-BAA-A variant. Both of these chips are listed in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as devices which need the firmware loader on page 2 in order to work as they "do not support the External ROM". The "Firmware Download Sequence" is describe in chapter "7.1 FW Download Interface" R19UH0078EJ0500 Rev.5.00 page 131. The firmware "K2013080.mem" is available from a USB3.0 Host to PCIe Adapter (PP2U-E card) "Firmware download" archive. An alternative version can be sourced from Netgear's WNDR4700 GPL archives. The release notes of the PP2U-E's "Firmware Download" ver 2.0.1.3 (2012-06-15) state that the firmware is for the following devices: - uPD720201 ES 2.0 sample whose revision ID is 2. - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3. - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2. [vkoul: fixed comments: used macros for timeout count and delay removed renesas_fw_alive_check cleaned renesas_fw_callback removed recursion for renesas_fw_download add register defines and field names move to a separate file make fw loader as sync probe so that we execute in probe and prevent race make xhci-pci-renesas a seprate module] Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200514122039.300417-3-vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-14 20:20:37 +08:00
Say 'Y' to enable the support for the Renesas xHCI controller with
firmware. Make sure you have the firmware for the device and
usb: renesas-xhci: Add the renesas xhci driver This add a new driver for renesas xhci which is basically a firmware loader for uPD720201 and uPD720202 w/o ROM. The xhci-pci driver will invoke this driver for loading/unloading on relevant devices. This patch adds a firmware loader for the uPD720201K8-711-BAC-A and uPD720202K8-711-BAA-A variant. Both of these chips are listed in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as devices which need the firmware loader on page 2 in order to work as they "do not support the External ROM". The "Firmware Download Sequence" is describe in chapter "7.1 FW Download Interface" R19UH0078EJ0500 Rev.5.00 page 131. The firmware "K2013080.mem" is available from a USB3.0 Host to PCIe Adapter (PP2U-E card) "Firmware download" archive. An alternative version can be sourced from Netgear's WNDR4700 GPL archives. The release notes of the PP2U-E's "Firmware Download" ver 2.0.1.3 (2012-06-15) state that the firmware is for the following devices: - uPD720201 ES 2.0 sample whose revision ID is 2. - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3. - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2. [vkoul: fixed comments: used macros for timeout count and delay removed renesas_fw_alive_check cleaned renesas_fw_callback removed recursion for renesas_fw_download add register defines and field names move to a separate file make fw loader as sync probe so that we execute in probe and prevent race make xhci-pci-renesas a seprate module] Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200514122039.300417-3-vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-14 20:20:37 +08:00
installed on your system for this device to work.
If unsure, say 'N'.
config USB_XHCI_PLATFORM
tristate "Generic xHCI driver for a platform device"
help
Adds an xHCI host driver for a generic platform device, which
provides a memory space and an irq.
It is also a prerequisite for platform specific drivers that
implement some extra quirks.
If unsure, say N.
config USB_XHCI_HISTB
tristate "xHCI support for HiSilicon STB SoCs"
depends on USB_XHCI_PLATFORM && (ARCH_HISI || COMPILE_TEST)
help
Say 'Y' to enable the support for the xHCI host controller
found in HiSilicon STB SoCs.
config USB_XHCI_MTK
tristate "xHCI support for MediaTek SoCs"
select MFD_SYSCON
depends on (MIPS && SOC_MT7621) || ARCH_MEDIATEK || COMPILE_TEST
help
Say 'Y' to enable the support for the xHCI host controller
found in MediaTek SoCs.
If unsure, say N.
config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x/37xx"
select USB_XHCI_PLATFORM
depends on HAS_IOMEM
depends on ARCH_MVEBU || COMPILE_TEST
help
Say 'Y' to enable the support for the xHCI host controller
found in Marvell Armada 375/38x/37xx ARM SOCs.
config USB_XHCI_RCAR
tristate "xHCI support for Renesas R-Car SoCs"
depends on USB_XHCI_PLATFORM
depends on ARCH_RENESAS || COMPILE_TEST
xhci: split out rcar/rz support from xhci-plat.c The USB_XHCI_RZV2M and USB_RENESAS_USB3 select other drivers based on the enabled SoC types, which leads to build failures when the dependencies are not met: WARNING: unmet direct dependencies detected for USB_RZV2M_USB3DRD Depends on [n]: USB_SUPPORT [=y] && USB_GADGET [=n] && (ARCH_R9A09G011 [=n] || COMPILE_TEST [=y]) Selected by [m]: - USB_XHCI_RZV2M [=m] && USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=m] && USB_XHCI_PLATFORM [=m] && (ARCH_R9A09G011 [=n] || COMPILE_TEST [=y]) ERROR: modpost: "rzv2m_usb3drd_reset" [drivers/usb/host/xhci-plat-hcd.ko] undefined! The xhci-rcar driver has a reverse dependency with the xhci core, and it depends on the UDC driver in turn. To untangle this, make the xhci-rcar.ko driver a standalone module that just calls into the xhci-plat.ko module like other drivers do. This allows handling the dependency on the USB_RZV2M_USB3DRD driver to only affect the xhci-rcar module and simplify the xhci-plat module. It also allows leaving out the hacks for broken dma mask and nested devices from the rcar side and keep that only in the generic xhci driver. As a future cleanup, the marvell and dwc3 specific bits of xhci-plat.c could be moved out as well, but that is not required for this bugfix. Fixes: c52c9acc415e ("xhci: host: Add Renesas RZ/V2M SoC support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20230131150531.12347-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-31 23:04:31 +08:00
default ARCH_RENESAS
help
Say 'Y' to enable the support for the xHCI host controller
found in Renesas R-Car ARM SoCs.
config USB_XHCI_RZV2M
xhci: split out rcar/rz support from xhci-plat.c The USB_XHCI_RZV2M and USB_RENESAS_USB3 select other drivers based on the enabled SoC types, which leads to build failures when the dependencies are not met: WARNING: unmet direct dependencies detected for USB_RZV2M_USB3DRD Depends on [n]: USB_SUPPORT [=y] && USB_GADGET [=n] && (ARCH_R9A09G011 [=n] || COMPILE_TEST [=y]) Selected by [m]: - USB_XHCI_RZV2M [=m] && USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=m] && USB_XHCI_PLATFORM [=m] && (ARCH_R9A09G011 [=n] || COMPILE_TEST [=y]) ERROR: modpost: "rzv2m_usb3drd_reset" [drivers/usb/host/xhci-plat-hcd.ko] undefined! The xhci-rcar driver has a reverse dependency with the xhci core, and it depends on the UDC driver in turn. To untangle this, make the xhci-rcar.ko driver a standalone module that just calls into the xhci-plat.ko module like other drivers do. This allows handling the dependency on the USB_RZV2M_USB3DRD driver to only affect the xhci-rcar module and simplify the xhci-plat module. It also allows leaving out the hacks for broken dma mask and nested devices from the rcar side and keep that only in the generic xhci driver. As a future cleanup, the marvell and dwc3 specific bits of xhci-plat.c could be moved out as well, but that is not required for this bugfix. Fixes: c52c9acc415e ("xhci: host: Add Renesas RZ/V2M SoC support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20230131150531.12347-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-31 23:04:31 +08:00
bool "xHCI support for Renesas RZ/V2M SoC"
depends on USB_XHCI_RCAR
depends on ARCH_R9A09G011 || COMPILE_TEST
xhci: split out rcar/rz support from xhci-plat.c The USB_XHCI_RZV2M and USB_RENESAS_USB3 select other drivers based on the enabled SoC types, which leads to build failures when the dependencies are not met: WARNING: unmet direct dependencies detected for USB_RZV2M_USB3DRD Depends on [n]: USB_SUPPORT [=y] && USB_GADGET [=n] && (ARCH_R9A09G011 [=n] || COMPILE_TEST [=y]) Selected by [m]: - USB_XHCI_RZV2M [=m] && USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=m] && USB_XHCI_PLATFORM [=m] && (ARCH_R9A09G011 [=n] || COMPILE_TEST [=y]) ERROR: modpost: "rzv2m_usb3drd_reset" [drivers/usb/host/xhci-plat-hcd.ko] undefined! The xhci-rcar driver has a reverse dependency with the xhci core, and it depends on the UDC driver in turn. To untangle this, make the xhci-rcar.ko driver a standalone module that just calls into the xhci-plat.ko module like other drivers do. This allows handling the dependency on the USB_RZV2M_USB3DRD driver to only affect the xhci-rcar module and simplify the xhci-plat module. It also allows leaving out the hacks for broken dma mask and nested devices from the rcar side and keep that only in the generic xhci driver. As a future cleanup, the marvell and dwc3 specific bits of xhci-plat.c could be moved out as well, but that is not required for this bugfix. Fixes: c52c9acc415e ("xhci: host: Add Renesas RZ/V2M SoC support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20230131150531.12347-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-31 23:04:31 +08:00
depends on USB_RZV2M_USB3DRD=y || (USB_RZV2M_USB3DRD=USB_XHCI_RCAR)
help
Say 'Y' to enable the support for the xHCI host controller
found in Renesas RZ/V2M SoC.
config USB_XHCI_TEGRA
tristate "xHCI support for NVIDIA Tegra SoCs"
depends on PHY_TEGRA_XUSB
depends on RESET_CONTROLLER
select FW_LOADER
help
Say 'Y' to enable the support for the xHCI host controller
found in NVIDIA Tegra124 and later SoCs.
endif # USB_XHCI_HCD
config USB_EHCI_BRCMSTB
tristate
config USB_BRCMSTB
tristate "Broadcom STB USB support"
depends on (ARCH_BRCMSTB && PHY_BRCM_USB) || COMPILE_TEST
select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
select USB_EHCI_BRCMSTB if USB_EHCI_HCD
select USB_XHCI_PLATFORM if USB_XHCI_HCD
help
Enables support for XHCI, EHCI and OHCI host controllers
found in Broadcom STB SoC's.
To compile these drivers as modules, choose M here: the
modules will be called ohci-platform.ko, ehci-brcm.ko and
xhci-plat-hcd.ko
Disabling this will keep the controllers and corresponding
PHYs powered down.
config USB_EHCI_HCD
tristate "EHCI HCD (USB 2.0) support"
usb: host: Host drivers relying on DMA should depend on HAS_DMA If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/usb/host/xhci-plat-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-mtk.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ohci-platform.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ehci-platform.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/ehci-hcd.ko] undefined! Add dependencies on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-22 05:48:47 +08:00
depends on HAS_DMA && HAS_IOMEM
help
The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0
"high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware.
If your USB host controller supports USB 2.0, you will likely want to
configure this Host Controller Driver.
EHCI controllers are packaged with "companion" host controllers (OHCI
or UHCI) to handle USB 1.1 devices connected to root hub ports. Ports
will connect to EHCI if the device is high speed, otherwise they
connect to a companion controller. If you configure EHCI, you should
probably configure the OHCI (for NEC and some other vendors) USB Host
Controller Driver or UHCI (for Via motherboards) Host Controller
Driver too.
You may want to read <file:Documentation/usb/ehci.rst>.
To compile this driver as a module, choose M here: the
module will be called ehci-hcd.
config USB_EHCI_ROOT_HUB_TT
bool "Root Hub Transaction Translators"
depends on USB_EHCI_HCD
help
Some EHCI chips have vendor-specific extensions to integrate
transaction translators, so that no OHCI or UHCI companion
controller is needed. It's safe to say "y" even if your
controller doesn't support this feature.
This supports the EHCI implementation that's originally
from ARC, and has since changed hands a few times.
config USB_EHCI_TT_NEWSCHED
bool "Improved Transaction Translator scheduling"
depends on USB_EHCI_HCD
default y
help
This changes the periodic scheduling code to fill more of the low
and full speed bandwidth available from the Transaction Translator
(TT) in USB 2.0 hubs. Without this, only one transfer will be
issued in each microframe, significantly reducing the number of
periodic low/fullspeed transfers possible.
If you have multiple periodic low/fullspeed devices connected to a
highspeed USB hub which is connected to a highspeed USB Host
Controller, and some of those devices will not work correctly
(possibly due to "ENOSPC" or "-28" errors), say Y. Conversely, if
you have only one such device and it doesn't work, you could try
saying N.
If unsure, say Y.
if USB_EHCI_HCD
config USB_EHCI_PCI
tristate
depends on USB_PCI
default y
config XPS_USB_HCD_XILINX
bool "Use Xilinx usb host EHCI controller core"
depends on (PPC32 || MICROBLAZE)
select USB_EHCI_BIG_ENDIAN_DESC
select USB_EHCI_BIG_ENDIAN_MMIO
help
Xilinx xps USB host controller core is EHCI compliant and has
transaction translator built-in. It can be configured to either
support both high speed and full speed devices, or high speed
devices only.
config USB_EHCI_FSL
tristate "Support for Freescale on-chip EHCI USB controller"
select USB_EHCI_ROOT_HUB_TT
help
Variation of ARC USB block used in some Freescale chips.
config USB_EHCI_HCD_NPCM7XX
tristate "Support for Nuvoton NPCM on-chip EHCI USB controller"
depends on (USB_EHCI_HCD && ARCH_NPCM) || COMPILE_TEST
default y if (USB_EHCI_HCD && ARCH_NPCM)
help
Enables support for the on-chip EHCI controller on
Nuvoton NPCM chips.
config USB_EHCI_HCD_OMAP
tristate "EHCI support for OMAP3 and later chips"
depends on ARCH_OMAP || COMPILE_TEST
depends on NOP_USB_XCEIV
default y
help
Enables support for the on-chip EHCI controller on
OMAP3 and later chips.
USB: EHCI: make ehci-orion a separate driver Separate the Orion host controller driver from ehci-hcd host code into its own driver module because of following reason. With the multiplatform changes in arm-soc tree, it becomes possible to enable the mvebu platform (which uses ehci-orion) at the same time as other platforms that require a conflicting EHCI bus glue. At the moment, this results in a warning like drivers/usb/host/ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default] drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable] and an ehci driver that only works on one of them. With the infrastructure added by Alan Stern in patch 3e0232039 "USB: EHCI: prepare to make ehci-hcd a library module", we can avoid this problem by turning a bus glue into a separate module, as we do here for the orion bus glue. An earlier version of this patch was included in 3.9 but caused a regression there, which has subsequently been fixed. While we are here, use the opportunity to disabiguate the two Marvell EHCI controller implementations in Kconfig. In V4 (arnd): - Improve Kconfig text In V3: - More detail provided in commit message regarding this patch. - Replaced hcd_name string "ehci-orion" into "orion-ehci". - MODULE_LICENSE is GPL v2. - In ehci_init_driver calling second argument passed as NULL instead of ehci_orion_overrides because ehci_orion_overrides is removed. In V2: - Tegra patch related changes removed from this patch. Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Jason Cooper <jason@lakedaemon.net> Tested-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-03 00:23:59 +08:00
config USB_EHCI_HCD_ORION
tristate "Support for Marvell EBU on-chip EHCI USB controller"
depends on USB_EHCI_HCD && (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST)
default y if (PLAT_ORION || ARCH_MVEBU)
help
USB: EHCI: make ehci-orion a separate driver Separate the Orion host controller driver from ehci-hcd host code into its own driver module because of following reason. With the multiplatform changes in arm-soc tree, it becomes possible to enable the mvebu platform (which uses ehci-orion) at the same time as other platforms that require a conflicting EHCI bus glue. At the moment, this results in a warning like drivers/usb/host/ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default] drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable] and an ehci driver that only works on one of them. With the infrastructure added by Alan Stern in patch 3e0232039 "USB: EHCI: prepare to make ehci-hcd a library module", we can avoid this problem by turning a bus glue into a separate module, as we do here for the orion bus glue. An earlier version of this patch was included in 3.9 but caused a regression there, which has subsequently been fixed. While we are here, use the opportunity to disabiguate the two Marvell EHCI controller implementations in Kconfig. In V4 (arnd): - Improve Kconfig text In V3: - More detail provided in commit message regarding this patch. - Replaced hcd_name string "ehci-orion" into "orion-ehci". - MODULE_LICENSE is GPL v2. - In ehci_init_driver calling second argument passed as NULL instead of ehci_orion_overrides because ehci_orion_overrides is removed. In V2: - Tegra patch related changes removed from this patch. Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Jason Cooper <jason@lakedaemon.net> Tested-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-03 00:23:59 +08:00
Enables support for the on-chip EHCI controller on Marvell's
embedded ARM SoCs, including Orion, Kirkwood, Dove, Armada XP,
Armada 370. This is different from the EHCI implementation
on Marvell's mobile PXA and MMP SoC, see "EHCI support for
Marvell PXA/MMP USB controller" for those.
USB: EHCI: make ehci-spear a separate driver Separate the SPEAr host controller driver from ehci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; however, note that other changes are still needed before SPEAr can be booted with a multi-platform kernel, but they are queued in the arm-soc tree for 3.10. With the infrastructure added by Alan Stern in patch 3e0232039 "USB: EHCI: prepare to make ehci-hcd a library module", we can avoid this problem by turning a bus glue into a separate module, as we do here for the SPEAr bus glue. In V4 (arnd): - renamed all 'struct spear_ehci' pointers from 'ehci' to the less ambiguous 'sehci'. - folded trivial spear_start_ehci/spear_stop_ehci functions into callers. - brought back initialization of ehci->caps. In V3: - Detailed commit message added here about why this patch is required. - Eliminated ehci_spear_setup routine because hcd registers can be directly set in the spear_ehci_hcd_drv_probe function. - spear_overrides struct initialized. - Converted to using .extra_priv_size for allocating spear_ehci, and updated all users of that structure. - to_spear_ehci() macro modified for spear_ehci. In V2: - Replaced spear as SPEAr everywhere, leaving functions/variables/config options. Signed-off-by: Deepak Saxena <dsaxena@linaro.org> Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Viresh Kumar <viresh.linux@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Shiraz Hashim <shiraz.hashim@st.com> Cc: spear-devel@list.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-03 00:24:00 +08:00
config USB_EHCI_HCD_SPEAR
tristate "Support for ST SPEAr on-chip EHCI USB controller"
depends on USB_EHCI_HCD && (PLAT_SPEAR || COMPILE_TEST)
default y if PLAT_SPEAR
help
Enables support for the on-chip EHCI controller on
ST SPEAr chips.
USB: EHCI: make ehci-spear a separate driver Separate the SPEAr host controller driver from ehci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; however, note that other changes are still needed before SPEAr can be booted with a multi-platform kernel, but they are queued in the arm-soc tree for 3.10. With the infrastructure added by Alan Stern in patch 3e0232039 "USB: EHCI: prepare to make ehci-hcd a library module", we can avoid this problem by turning a bus glue into a separate module, as we do here for the SPEAr bus glue. In V4 (arnd): - renamed all 'struct spear_ehci' pointers from 'ehci' to the less ambiguous 'sehci'. - folded trivial spear_start_ehci/spear_stop_ehci functions into callers. - brought back initialization of ehci->caps. In V3: - Detailed commit message added here about why this patch is required. - Eliminated ehci_spear_setup routine because hcd registers can be directly set in the spear_ehci_hcd_drv_probe function. - spear_overrides struct initialized. - Converted to using .extra_priv_size for allocating spear_ehci, and updated all users of that structure. - to_spear_ehci() macro modified for spear_ehci. In V2: - Replaced spear as SPEAr everywhere, leaving functions/variables/config options. Signed-off-by: Deepak Saxena <dsaxena@linaro.org> Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Viresh Kumar <viresh.linux@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Shiraz Hashim <shiraz.hashim@st.com> Cc: spear-devel@list.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-03 00:24:00 +08:00
config USB_EHCI_HCD_STI
tristate "Support for ST STiHxxx on-chip EHCI USB controller"
depends on (ARCH_STI || COMPILE_TEST) && OF
select GENERIC_PHY
select USB_EHCI_HCD_PLATFORM
help
Enable support for the on-chip EHCI controller found on
STMicroelectronics consumer electronics SoC's.
USB: EHCI: make ehci-atmel a separate driver Separate the Atmel host controller driver from ehci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; however, note that other changes are still needed before Atmel can be booted with a multi-platform kernel. This is currently planned for Linux-3.11. With the infrastructure added by Alan Stern in patch 3e0232039 "USB: EHCI: prepare to make ehci-hcd a library module", we can avoid this problem by turning a bus glue into a separate module, as we do here for the Atmel bus glue. In V4 (arnd): - reordered #include statements. - removed call to ehci_shutdown and the corresponding export In V3: - Detailed commit message added here about why this patch is required. - Replaced hcd_name string "ehci-atmel" to "atmel-ehci". - Inserted blank line in the Makefile to separate the EHCI drivers from the following non-EHCI drivers. - Exported ehci_shutdown symbol as it is needed by the Atmel driver. - Eliminated ehci_atmel_setup routine because hcd registers can be directly set in the ehci_atmel_drv_probe function. In V2: Resolved below compiler error. drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove': drivers/usb/host/ehci-atmel.c:167: error: implicit declaration of function 'ehci_shutdown' Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Andrew Victor <linux@maxim.org.za> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-03 00:24:02 +08:00
config USB_EHCI_HCD_AT91
tristate "Support for Atmel on-chip EHCI USB controller"
depends on USB_EHCI_HCD && (ARCH_AT91 || COMPILE_TEST)
default y if ARCH_AT91
help
Enables support for the on-chip EHCI controller on
Atmel chips.
USB: EHCI: make ehci-atmel a separate driver Separate the Atmel host controller driver from ehci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; however, note that other changes are still needed before Atmel can be booted with a multi-platform kernel. This is currently planned for Linux-3.11. With the infrastructure added by Alan Stern in patch 3e0232039 "USB: EHCI: prepare to make ehci-hcd a library module", we can avoid this problem by turning a bus glue into a separate module, as we do here for the Atmel bus glue. In V4 (arnd): - reordered #include statements. - removed call to ehci_shutdown and the corresponding export In V3: - Detailed commit message added here about why this patch is required. - Replaced hcd_name string "ehci-atmel" to "atmel-ehci". - Inserted blank line in the Makefile to separate the EHCI drivers from the following non-EHCI drivers. - Exported ehci_shutdown symbol as it is needed by the Atmel driver. - Eliminated ehci_atmel_setup routine because hcd registers can be directly set in the ehci_atmel_drv_probe function. In V2: Resolved below compiler error. drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove': drivers/usb/host/ehci-atmel.c:167: error: implicit declaration of function 'ehci_shutdown' Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Andrew Victor <linux@maxim.org.za> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-03 00:24:02 +08:00
config USB_EHCI_TEGRA
tristate "NVIDIA Tegra HCD support"
depends on ARCH_TEGRA
select USB_CHIPIDEA
select USB_CHIPIDEA_HOST
select USB_CHIPIDEA_TEGRA
select USB_GADGET
help
This option is deprecated now and the driver was removed, use
USB_CHIPIDEA_TEGRA instead.
Enable support for the internal USB Host Controllers
found in NVIDIA Tegra SoCs. The controllers are EHCI compliant.
config USB_EHCI_HCD_PPC_OF
bool "EHCI support for PPC USB controller on OF platform bus"
depends on PPC
default y
help
Enables support for the USB controller present on the PowerPC
OpenFirmware platform bus.
config USB_EHCI_SH
bool "EHCI support for SuperH USB controller"
depends on SUPERH || COMPILE_TEST
help
Enables support for the on-chip EHCI controller on the SuperH.
If you use the PCI EHCI controller, this option is not necessary.
config USB_EHCI_EXYNOS
tristate "EHCI support for Samsung S5P/Exynos SoC Series"
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
help
Enable support for the Samsung S5Pv210 and Exynos SOC's on-chip EHCI
controller.
config USB_EHCI_MV
tristate "EHCI support for Marvell PXA/MMP USB controller"
depends on ARCH_PXA || ARCH_MMP || COMPILE_TEST
select USB_EHCI_ROOT_HUB_TT
help
Enables support for Marvell (including PXA and MMP series) on-chip
USB SPH and OTG controller. SPH is a single port host, and it can
only be EHCI host. OTG is controller that can switch to host mode.
USB: EHCI: make ehci-orion a separate driver Separate the Orion host controller driver from ehci-hcd host code into its own driver module because of following reason. With the multiplatform changes in arm-soc tree, it becomes possible to enable the mvebu platform (which uses ehci-orion) at the same time as other platforms that require a conflicting EHCI bus glue. At the moment, this results in a warning like drivers/usb/host/ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default] drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable] and an ehci driver that only works on one of them. With the infrastructure added by Alan Stern in patch 3e0232039 "USB: EHCI: prepare to make ehci-hcd a library module", we can avoid this problem by turning a bus glue into a separate module, as we do here for the orion bus glue. An earlier version of this patch was included in 3.9 but caused a regression there, which has subsequently been fixed. While we are here, use the opportunity to disabiguate the two Marvell EHCI controller implementations in Kconfig. In V4 (arnd): - Improve Kconfig text In V3: - More detail provided in commit message regarding this patch. - Replaced hcd_name string "ehci-orion" into "orion-ehci". - MODULE_LICENSE is GPL v2. - In ehci_init_driver calling second argument passed as NULL instead of ehci_orion_overrides because ehci_orion_overrides is removed. In V2: - Tegra patch related changes removed from this patch. Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Jason Cooper <jason@lakedaemon.net> Tested-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-03 00:23:59 +08:00
Note that this driver will not work on Marvell's other EHCI
controller used by the EBU-type SoCs including Orion, Kirkwood,
Dova, Armada 370 and Armada XP. See "Support for Marvell EBU
on-chip EHCI USB controller" for those.
config USB_OCTEON_HCD
tristate "Cavium Networks Octeon USB support"
depends on CAVIUM_OCTEON_SOC && USB
help
This driver supports USB host controller on some Cavium
Networks' products in the Octeon family.
To compile this driver as a module, choose M here. The module
will be called octeon-hcd.
config USB_EHCI_HCD_PLATFORM
tristate "Generic EHCI driver for a platform device"
help
Adds an EHCI host driver for a generic platform device, which
provides a memory space and an irq.
If unsure, say N.
config USB_OCTEON_EHCI
bool "Octeon on-chip EHCI support (DEPRECATED)"
depends on CAVIUM_OCTEON_SOC
select USB_EHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_EHCI_HCD_PLATFORM
help
This option is deprecated now and the driver was removed, use
USB_EHCI_HCD_PLATFORM instead.
Enable support for the Octeon II SOC's on-chip EHCI
controller. It is needed for high-speed (480Mbit/sec)
USB 2.0 device support. All CN6XXX based chips with USB are
supported.
endif # USB_EHCI_HCD
config USB_OXU210HP_HCD
tristate "OXU210HP HCD support"
depends on HAS_IOMEM
help
The OXU210HP is an USB host/OTG/device controller. Enable this
option if your board has this chip. If unsure, say N.
This driver does not support isochronous transfers and doesn't
implement OTG nor USB device controllers.
To compile this driver as a module, choose M here: the
module will be called oxu210hp-hcd.
config USB_ISP116X_HCD
tristate "ISP116X HCD support"
depends on HAS_IOMEM
help
The ISP1160 and ISP1161 chips are USB host controllers. Enable this
option if your board has this chip. If unsure, say N.
This driver does not support isochronous transfers.
To compile this driver as a module, choose M here: the
module will be called isp116x-hcd.
config USB_ISP1362_HCD
tristate "ISP1362 HCD support"
depends on HAS_IOPORT
depends on COMPILE_TEST # nothing uses this
help
Supports the Philips ISP1362 chip as a host controller
This driver does not support isochronous transfers.
To compile this driver as a module, choose M here: the
module will be called isp1362-hcd.
config USB_MAX3421_HCD
tristate "MAX3421 HCD (USB-over-SPI) support"
depends on USB && SPI
help
The Maxim MAX3421E chip supports standard USB 2.0-compliant
full-speed devices either in host or peripheral mode. This
driver supports the host-mode of the MAX3421E only.
To compile this driver as a module, choose M here: the module will
be called max3421-hcd.
config USB_OHCI_HCD
USB: OHCI: make ohci-pci a separate driver This patch splits the PCI portion of ohci-hcd out into its own separate driver module, called ohci-pci. The major point of difficulty lies in ohci-pci's many vendor- and device-specific workarounds. Some of them have to be applied before calling ohci_start() some after, which necessitates a fair amount of code motion. The other platform drivers require much smaller changes. The complete sb800_prefetch() function moved to ohci-q.c,because its only related to ohci-pci driver. USB_OHCI_HCD_PCI symbol no longer dependence on STB03xxx, PPC_MPC52xx and USB_OHCI_HCD_PPC_OF that's what removed. V2: - few specific content of pci related code in ohci_pci_start function has been moved to ohci_pci_reset and rest of the generic code is written in ohci_start of ohci-hcd.c file. V3: - ohci_restart() has been called in ohci_pci_reset() function for to reset the ohci pci. V4: -sb800_prefetch() moved to ohci-q.c,because its only related to ohci-pci. -no longer _creating_ CONFIG_USB_OHCI_PCI,creating CONFIG_USB_OHCI_HCD_PCI. -overrides renamed with pci_override,its giving proper meaning. V5: -sb800_prefetch() moved to pci-quirks.c,because its only related to pci. V6: -sb800_prefetch() function has been moved to pci-quirks.c made as separate patch in 2/3. -Most of the generic ohci pci changes moved in 2/3 patch,now this is complete ohci-pci separation patch. V7: -Unrelated include file has been removed from ohci.h file. V8: -USB_OHCI_HCD_PCI symbol does not dependence on STB03xxx, PPC_MPC52xx and USB_OHCI_HCD_PPC_OF. Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-28 21:04:51 +08:00
tristate "OHCI HCD (USB 1.1) support"
usb: host: Host drivers relying on DMA should depend on HAS_DMA If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/usb/host/xhci-plat-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-mtk.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ohci-platform.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ehci-platform.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/ehci-hcd.ko] undefined! Add dependencies on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-22 05:48:47 +08:00
depends on HAS_DMA && HAS_IOMEM
help
The Open Host Controller Interface (OHCI) is a standard for accessing
USB 1.1 host controller hardware. It does more in hardware than Intel's
UHCI specification. If your USB host controller follows the OHCI spec,
say Y. On most non-x86 systems, and on x86 hardware that's not using a
USB controller from Intel or VIA, this is appropriate. If your host
controller doesn't use PCI, this is probably appropriate. For a PCI
based system where you're not sure, the "lspci -v" entry will list the
right "prog-if" for your USB controller(s): EHCI, OHCI, or UHCI.
To compile this driver as a module, choose M here: the
module will be called ohci-hcd.
if USB_OHCI_HCD
config USB_OHCI_HCD_OMAP1
tristate "OHCI support for OMAP1/2 chips"
depends on ARCH_OMAP1
default y
help
Enables support for the OHCI controller on OMAP1/2 chips.
config USB_OHCI_HCD_SPEAR
tristate "Support for ST SPEAr on-chip OHCI USB controller"
depends on USB_OHCI_HCD && (PLAT_SPEAR || COMPILE_TEST)
default y if PLAT_SPEAR
help
Enables support for the on-chip OHCI controller on
ST SPEAr chips.
config USB_OHCI_HCD_STI
tristate "Support for ST STiHxxx on-chip OHCI USB controller"
depends on (ARCH_STI || COMPILE_TEST) && OF
select GENERIC_PHY
select USB_OHCI_HCD_PLATFORM
help
Enable support for the on-chip OHCI controller found on
STMicroelectronics consumer electronics SoC's.
config USB_OHCI_HCD_S3C2410
tristate "OHCI support for Samsung S3C64xx SoC series"
depends on USB_OHCI_HCD && (ARCH_S3C64XX || COMPILE_TEST)
default ARCH_S3C64XX
help
Enables support for the on-chip OHCI controller on
S3C64xx chips.
config USB_OHCI_HCD_LPC32XX
tristate "Support for LPC on-chip OHCI USB controller"
depends on USB_OHCI_HCD
depends on ARCH_LPC32XX || COMPILE_TEST
depends on USB_ISP1301
default y
help
Enables support for the on-chip OHCI controller on
NXP chips.
config USB_OHCI_HCD_PXA27X
tristate "Support for PXA27X/PXA3XX on-chip OHCI USB controller"
depends on USB_OHCI_HCD && (PXA27x || PXA3xx)
default y
help
Enables support for the on-chip OHCI controller on
PXA27x/PXA3xx chips.
config USB_OHCI_HCD_AT91
tristate "Support for Atmel on-chip OHCI USB controller"
depends on USB_OHCI_HCD && (ARCH_AT91 || COMPILE_TEST) && OF
default y if ARCH_AT91
help
Enables support for the on-chip OHCI controller on
Atmel chips.
config USB_OHCI_HCD_OMAP3
tristate "OHCI support for OMAP3 and later chips"
depends on ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5 || COMPILE_TEST
select USB_OHCI_HCD_PLATFORM
default y if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5
help
This option is deprecated now and the driver was removed, use
USB_OHCI_HCD_PLATFORM instead.
Enables support for the on-chip OHCI controller on
OMAP3 and later chips.
config USB_OHCI_HCD_DAVINCI
tristate "OHCI support for TI DaVinci DA8xx"
depends on ARCH_DAVINCI_DA8XX || COMPILE_TEST
depends on USB_OHCI_HCD
select PHY_DA8XX_USB
default y if ARCH_DAVINCI_DA8XX
help
Enables support for the DaVinci DA8xx integrated OHCI
controller. This driver cannot currently be a loadable
module because it lacks a proper PHY abstraction.
config USB_OHCI_HCD_PPC_OF_BE
bool "OHCI support for OF platform bus (big endian)"
depends on PPC
select USB_OHCI_BIG_ENDIAN_DESC
select USB_OHCI_BIG_ENDIAN_MMIO
help
Enables support for big-endian USB controllers present on the
OpenFirmware platform bus.
config USB_OHCI_HCD_PPC_OF_LE
bool "OHCI support for OF platform bus (little endian)"
depends on PPC
select USB_OHCI_LITTLE_ENDIAN
help
Enables support for little-endian USB controllers present on the
OpenFirmware platform bus.
config USB_OHCI_HCD_PPC_OF
bool
depends on PPC
default USB_OHCI_HCD_PPC_OF_BE || USB_OHCI_HCD_PPC_OF_LE
config USB_OHCI_HCD_PCI
USB: OHCI: make ohci-pci a separate driver This patch splits the PCI portion of ohci-hcd out into its own separate driver module, called ohci-pci. The major point of difficulty lies in ohci-pci's many vendor- and device-specific workarounds. Some of them have to be applied before calling ohci_start() some after, which necessitates a fair amount of code motion. The other platform drivers require much smaller changes. The complete sb800_prefetch() function moved to ohci-q.c,because its only related to ohci-pci driver. USB_OHCI_HCD_PCI symbol no longer dependence on STB03xxx, PPC_MPC52xx and USB_OHCI_HCD_PPC_OF that's what removed. V2: - few specific content of pci related code in ohci_pci_start function has been moved to ohci_pci_reset and rest of the generic code is written in ohci_start of ohci-hcd.c file. V3: - ohci_restart() has been called in ohci_pci_reset() function for to reset the ohci pci. V4: -sb800_prefetch() moved to ohci-q.c,because its only related to ohci-pci. -no longer _creating_ CONFIG_USB_OHCI_PCI,creating CONFIG_USB_OHCI_HCD_PCI. -overrides renamed with pci_override,its giving proper meaning. V5: -sb800_prefetch() moved to pci-quirks.c,because its only related to pci. V6: -sb800_prefetch() function has been moved to pci-quirks.c made as separate patch in 2/3. -Most of the generic ohci pci changes moved in 2/3 patch,now this is complete ohci-pci separation patch. V7: -Unrelated include file has been removed from ohci.h file. V8: -USB_OHCI_HCD_PCI symbol does not dependence on STB03xxx, PPC_MPC52xx and USB_OHCI_HCD_PPC_OF. Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-28 21:04:51 +08:00
tristate "OHCI support for PCI-bus USB controllers"
depends on USB_PCI
default y
select USB_OHCI_LITTLE_ENDIAN
help
Enables support for PCI-bus plug-in USB controller cards.
If unsure, say Y.
config USB_OHCI_HCD_SSB
bool "OHCI support for Broadcom SSB OHCI core (DEPRECATED)"
depends on (SSB = y || SSB = USB_OHCI_HCD)
select USB_HCD_SSB
select USB_OHCI_HCD_PLATFORM
help
This option is deprecated now and the driver was removed, use
USB_HCD_SSB and USB_OHCI_HCD_PLATFORM instead.
Support for the Sonics Silicon Backplane (SSB) attached
Broadcom USB OHCI core.
This device is present in some embedded devices with
Broadcom based SSB bus.
If unsure, say N.
config USB_OHCI_EXYNOS
tristate "OHCI support for Samsung S5P/Exynos SoC Series"
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
help
Enable support for the Samsung S5Pv210 and Exynos SOC's on-chip OHCI
controller.
config USB_OHCI_HCD_PLATFORM
tristate "Generic OHCI driver for a platform device"
help
Adds an OHCI host driver for a generic platform device, which
provides a memory space and an irq.
If unsure, say N.
config USB_OCTEON_OHCI
bool "Octeon on-chip OHCI support (DEPRECATED)"
depends on CAVIUM_OCTEON_SOC
default USB_OCTEON_EHCI
select USB_OHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_OHCI_LITTLE_ENDIAN
select USB_OHCI_HCD_PLATFORM
help
This option is deprecated now and the driver was removed, use
USB_OHCI_HCD_PLATFORM instead.
Enable support for the Octeon II SOC's on-chip OHCI
controller. It is needed for low-speed USB 1.0 device
support. All CN6XXX based chips with USB are supported.
endif # USB_OHCI_HCD
config USB_UHCI_HCD
tristate "UHCI HCD (most Intel and VIA) support"
depends on (USB_PCI && HAS_IOPORT) || USB_UHCI_SUPPORT_NON_PCI_HC
help
The Universal Host Controller Interface is a standard by Intel for
accessing the USB hardware in the PC (which is also called the USB
host controller). If your USB host controller conforms to this
standard, you may want to say Y, but see below. All recent boards
with Intel PCI chipsets (like intel 430TX, 440FX, 440LX, 440BX,
i810, i820) conform to this standard. Also all VIA PCI chipsets
(like VIA VP2, VP3, MVP3, Apollo Pro, Apollo Pro II or Apollo Pro
133) and LEON/GRLIB SoCs with the GRUSBHC controller.
If unsure, say Y.
To compile this driver as a module, choose M here: the
module will be called uhci-hcd.
config USB_UHCI_SUPPORT_NON_PCI_HC
bool
default y if (SPARC_LEON || USB_UHCI_PLATFORM)
config USB_UHCI_PLATFORM
bool
default y if (ARCH_VT8500 || ARCH_ASPEED)
config USB_UHCI_ASPEED
bool
default y if ARCH_ASPEED
config USB_FHCI_HCD
tristate "Freescale QE USB Host Controller support"
depends on OF_GPIO && QE_GPIO && QUICC_ENGINE
select FSL_GTM
select QE_USB
help
This driver enables support for Freescale QE USB Host Controller
(as found on MPC8360 and MPC8323 processors), the driver supports
Full and Low Speed USB.
config FHCI_DEBUG
bool "Freescale QE USB Host Controller debug support"
depends on USB_FHCI_HCD && DEBUG_FS
help
Say "y" to see some FHCI debug information and statistics
through debugfs.
config USB_SL811_HCD
tristate "SL811HS HCD support"
usb: add HAS_IOMEM dependency to USB_SL811_HCD CC drivers/usb/host/xhci-mtk.o drivers/usb/host/xhci-mtk.c:135:12: warning: ‘xhci_mtk_host_disable’ defined but not used [-Wunused-function] static int xhci_mtk_host_disable(struct xhci_hcd_mtk *mtk) ^ drivers/usb/host/xhci-mtk.c:313:13: warning: ‘usb_wakeup_enable’ defined but not used [-Wunused-function] static void usb_wakeup_enable(struct xhci_hcd_mtk *mtk) ^ drivers/usb/host/xhci-mtk.c:321:13: warning: ‘usb_wakeup_disable’ defined but not used [-Wunused-function] static void usb_wakeup_disable(struct xhci_hcd_mtk *mtk) ^ CC drivers/usb/host/sl811-hcd.o drivers/usb/host/sl811-hcd.c: In function ‘sl811h_remove’: drivers/usb/host/sl811-hcd.c:1607:3: error: implicit declaration of function ‘iounmap’ [-Werror=implicit-function-declaration] iounmap(sl811->data_reg); ^ drivers/usb/host/sl811-hcd.c: In function ‘sl811h_probe’: drivers/usb/host/sl811-hcd.c:1669:3: error: implicit declaration of function ‘ioremap’ [-Werror=implicit-function-declaration] addr_reg = ioremap(addr->start, 1); ^ drivers/usb/host/sl811-hcd.c:1669:12: warning: assignment makes pointer from integer without a cast [enabled by default] addr_reg = ioremap(addr->start, 1); ^ drivers/usb/host/sl811-hcd.c:1675:12: warning: assignment makes pointer from integer without a cast [enabled by default] data_reg = ioremap(data->start, 1); ^ Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-10 22:29:43 +08:00
depends on HAS_IOMEM
help
The SL811HS is a single-port USB controller that supports either
host side or peripheral side roles. Enable this option if your
board has this chip, and you want to use it as a host controller.
If unsure, say N.
To compile this driver as a module, choose M here: the
module will be called sl811-hcd.
config USB_SL811_HCD_ISO
bool "partial ISO support"
depends on USB_SL811_HCD
help
The driver doesn't support iso_frame_desc (yet), but for some simple
devices that just queue one ISO frame per URB, then ISO transfers
"should" work using the normal urb status fields.
If unsure, say N.
config USB_SL811_CS
tristate "CF/PCMCIA support for SL811HS HCD"
depends on USB_SL811_HCD && PCMCIA
help
Wraps a PCMCIA driver around the SL811HS HCD, supporting the RATOC
REX-CFU1U CF card (often used with PDAs). If unsure, say N.
To compile this driver as a module, choose M here: the
module will be called "sl811_cs".
config USB_R8A66597_HCD
tristate "R8A66597 HCD support"
depends on HAS_IOMEM
help
The R8A66597 is a USB 2.0 host and peripheral controller.
Enable this option if your board has this chip, and you want
to use it as a host controller. If unsure, say N.
To compile this driver as a module, choose M here: the
module will be called r8a66597-hcd.
config USB_RENESAS_USBHS_HCD
tristate "Renesas USBHS HCD support"
depends on USB_RENESAS_USBHS
help
The Renesas USBHS is a USB 2.0 host and peripheral controller.
Enable this option if your board has this chip, and you want
to use it as a host controller. If unsure, say N.
To compile this driver as a module, choose M here: the
module will be called renesas-usbhs.
config USB_HCD_BCMA
tristate "BCMA usb host driver"
depends on BCMA
select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
help
Enable support for the EHCI and OCHI host controller on an bcma bus.
It converts the bcma driver into two platform device drivers
for ehci and ohci.
If unsure, say N.
config USB_HCD_SSB
tristate "SSB usb host driver"
depends on SSB
select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
help
Enable support for the EHCI and OCHI host controller on an bcma bus.
It converts the bcma driver into two platform device drivers
for ehci and ohci.
If unsure, say N.
config USB_HCD_TEST_MODE
bool "HCD test mode support"
help
Say 'Y' to enable additional software test modes that may be
supported by the host controller drivers.
One such test mode is the Embedded High-speed Host Electrical Test
(EHSET) for EHCI host controller hardware, specifically the "Single
Step Set Feature" test. Typically this will be enabled for On-the-Go
or embedded hosts that need to undergo USB-IF compliance testing with
the aid of special testing hardware. In the future, this may expand
to include other tests that require support from a HCD driver.
This option is of interest only to developers who need to validate
their USB hardware designs. It is not needed for normal use. If
unsure, say N.
config USB_XEN_HCD
tristate "Xen usb virtual host driver"
depends on XEN
select XEN_XENBUS_FRONTEND
help
The Xen usb virtual host driver serves as a frontend driver enabling
a Xen guest system to access USB Devices passed through to the guest
by the Xen host (usually Dom0).
Only needed if the kernel is running in a Xen guest and generic
access to a USB device is needed.