OpenCloudOS-Kernel/drivers/usb/misc/Kconfig

321 lines
11 KiB
Plaintext
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0
#
# USB Miscellaneous driver configuration
#
comment "USB Miscellaneous drivers"
usb: move config USB_USS720 to usb's misc Kconfig The USS720 parport driver source code is in drivers/usb/misc/, the corresponding config is defined in drivers/usb/Kconfig. Some digging in the kernel's history revealed no good reason why it needs to be defined in USB's top-level Kconfig file, and why the config for the USS720 parport driver should be the first in the list of USB port drivers, while all other configs for drivers in drivers/usb/misc are in the USB Miscellaneous driver configuration file. Most probably, it was simply considered a bit more special when the USB Miscellaneous driver configuration file (drivers/usb/misc/Config.in back then) was initially created, and this config simply survived to remain at the top-level USB Kconfig file with all further code/Kconfig transformations and additions later on. Users rarely notice this config being at this position, as CONFIG_PARPORT (Parallel port support) needs to be enabled and only few users enable that. Nowadays, this USB_USS720 driver is probably not that special that it needs to be listed as first item of the USB port drivers. Move the configuration of the USS720 parport driver to the top of the USB Miscellaneous drivers section, as the configurations does not have a lot of specific ordering USB Miscellaneous drivers. This way, the USS720 parport driver is moved to the comment "USB Miscellaneous drivers", fitting to the driver's source code location, but still is at the top of the list for those few acquainted users of Kconfig UIs that might be looking for the config that was once at the top of the list of the USB port drivers. Put this config definition to a more local place. No semantic change. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20230329075125.32352-1-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-29 15:51:25 +08:00
config USB_USS720
tristate "USS720 parport driver"
depends on PARPORT
select PARPORT_NOT_PC
help
This driver is for USB parallel port adapters that use the Lucent
Technologies USS-720 chip. These cables are plugged into your USB
port and provide USB compatibility to peripherals designed with
parallel port interfaces.
The chip has two modes: automatic mode and manual mode. In automatic
mode, it looks to the computer like a standard USB printer. Only
printers may be connected to the USS-720 in this mode. The generic
USB printer driver ("USB Printer support", above) may be used in
that mode, and you can say N here if you want to use the chip only
in this mode.
Manual mode is not limited to printers, any parallel port
device should work. This driver utilizes manual mode.
Note however that some operations are three orders of magnitude
slower than on a PCI/ISA Parallel Port, so timing critical
applications might not work.
Say Y here if you own an USS-720 USB->Parport cable and intend to
connect anything other than a printer to it.
To compile this driver as a module, choose M here: the
module will be called uss720.
config USB_EMI62
tristate "EMI 6|2m USB Audio interface support"
help
This driver loads firmware to Emagic EMI 6|2m low latency USB
Audio and Midi interface.
After firmware load the device is handled with standard linux
USB Audio driver.
This code is also available as a module ( = code which can be
inserted in and removed from the running kernel whenever you want).
The module will be called audio. If you want to compile it as a
module, say M here and read <file:Documentation/kbuild/modules.rst>.
config USB_EMI26
tristate "EMI 2|6 USB Audio interface support"
help
This driver loads firmware to Emagic EMI 2|6 low latency USB
Audio interface.
After firmware load the device is handled with standard linux
USB Audio driver.
To compile this driver as a module, choose M here: the
module will be called emi26.
config USB_ADUTUX
tristate "ADU devices from Ontrak Control Systems"
help
Say Y if you want to use an ADU device from Ontrak Control
Systems.
To compile this driver as a module, choose M here. The module
will be called adutux.
config USB_SEVSEG
tristate "USB 7-Segment LED Display"
help
Say Y here if you have a USB 7-Segment Display by Delcom
To compile this driver as a module, choose M here: the
module will be called usbsevseg.
config USB_LEGOTOWER
tristate "USB Lego Infrared Tower support"
help
Say Y here if you want to connect a USB Lego Infrared Tower to your
computer's USB port.
This code is also available as a module ( = code which can be
inserted in and removed from the running kernel whenever you want).
The module will be called legousbtower. If you want to compile it as
a module, say M here and read
<file:Documentation/kbuild/modules.rst>.
config USB_LCD
tristate "USB LCD driver support"
help
Say Y here if you want to connect an USBLCD to your computer's
USB port. The USBLCD is a small USB interface board for
alphanumeric LCD modules. See <http://www.usblcd.de/> for more
information.
To compile this driver as a module, choose M here: the
module will be called usblcd.
config USB_CYPRESS_CY7C63
tristate "Cypress CY7C63xxx USB driver support"
help
Say Y here if you want to connect a Cypress CY7C63xxx
micro controller to your computer's USB port. Currently this
driver supports the pre-programmed devices (incl. firmware)
by AK Modul-Bus Computer GmbH.
Please see: https://www.ak-modul-bus.de/stat/mikrocontroller.html
To compile this driver as a module, choose M here: the
module will be called cypress_cy7c63.
config USB_CYTHERM
tristate "Cypress USB thermometer driver support"
help
Say Y here if you want to connect a Cypress USB thermometer
device to your computer's USB port. This device is also known
as the Cypress USB Starter kit or demo board. The Elektor
magazine published a modified version of this device in issue
#291.
To compile this driver as a module, choose M here: the
module will be called cytherm.
config USB_IDMOUSE
tristate "Siemens ID USB Mouse Fingerprint sensor support"
help
Say Y here if you want to use the fingerprint sensor on
the Siemens ID Mouse. There is also a Siemens ID Mouse
_Professional_, which has not been tested with this driver,
but uses the same sensor and may therefore work.
This driver creates an entry "/dev/idmouseX" or "/dev/usb/idmouseX",
which can be used by, e.g.,"cat /dev/idmouse0 > fingerprint.pnm".
See also <https://www.fs.tum.de/~echtler/idmouse/>.
config USB_APPLEDISPLAY
tristate "Apple Cinema Display support"
select BACKLIGHT_CLASS_DEVICE
help
Say Y here if you want to control the backlight of Apple Cinema
Displays over USB. This driver provides a sysfs interface.
config USB_QCOM_EUD
tristate "QCOM Embedded USB Debugger(EUD) Driver"
depends on ARCH_QCOM || COMPILE_TEST
select USB_ROLE_SWITCH
help
This module enables support for Qualcomm Technologies, Inc.
Embedded USB Debugger (EUD). The EUD is a control peripheral
which reports VBUS attach/detach events and has USB-based
debug and trace capabilities. On selecting m, the module name
that is built is qcom_eud.ko
config APPLE_MFI_FASTCHARGE
tristate "Fast charge control for iOS devices"
select POWER_SUPPLY
help
Say Y here if you want to control whether iOS devices will
fast charge from the USB interface, as implemented in "MFi"
chargers.
It is safe to say M here.
source "drivers/usb/misc/sisusbvga/Kconfig"
config USB_LD
tristate "USB LD driver"
help
This driver is for generic USB devices that use interrupt transfers,
like LD Didactic's USB devices.
To compile this driver as a module, choose M here: the
module will be called ldusb.
config USB_TRANCEVIBRATOR
tristate "PlayStation 2 Trance Vibrator driver support"
help
Say Y here if you want to connect a PlayStation 2 Trance Vibrator
device to your computer's USB port.
To compile this driver as a module, choose M here: the
module will be called trancevibrator.
config USB_IOWARRIOR
tristate "IO Warrior driver support"
help
Say Y here if you want to support the IO Warrior devices from Code
Mercenaries. This includes support for the following devices:
IO Warrior 40
IO Warrior 24
IO Warrior 56
IO Warrior 24 Power Vampire
To compile this driver as a module, choose M here: the
module will be called iowarrior.
config USB_TEST
tristate "USB testing driver"
help
This driver is for testing host controller software. It is used
with specialized device firmware for regression and stress testing,
to help prevent problems from cropping up with "real" drivers.
See <http://www.linux-usb.org/usbtest/> for more information,
including sample test device firmware and "how to use it".
config USB_EHSET_TEST_FIXTURE
tristate "USB EHSET Test Fixture driver"
help
Say Y here if you want to support the special test fixture device
used for the USB-IF Embedded Host High-Speed Electrical Test procedure.
When the test fixture is connected, it can enumerate as one of several
VID/PID pairs. This driver then initiates a corresponding test mode on
the downstream port to which the test fixture is attached.
See <http://www.usb.org/developers/onthego/EHSET_v1.01.pdf> for more
information.
config USB_ISIGHTFW
tristate "iSight firmware loading support"
select FW_LOADER
help
This driver loads firmware for USB Apple iSight cameras, allowing
them to be driven by the USB video class driver available at
http://linux-uvc.berlios.de
The firmware for this driver must be extracted from the MacOS
driver beforehand. Tools for doing so are available at
http://bersace03.free.fr
config USB_YUREX
tristate "USB YUREX driver support"
help
Say Y here if you want to connect a YUREX to your computer's
USB port. The YUREX is a leg-shakes sensor. See
<http://bbu.kayac.com/en/> for further information.
This driver supports read/write of leg-shakes counter and
fasync for the counter update via a device file /dev/yurex*.
To compile this driver as a module, choose M here: the
module will be called yurex.
config USB_EZUSB_FX2
tristate "Functions for loading firmware on EZUSB chips"
help
Say Y here if you need EZUSB device support.
(Cypress FX/FX2/FX2LP microcontrollers)
config USB_HUB_USB251XB
tristate "USB251XB Hub Controller Configuration Driver"
depends on I2C
help
This option enables support for configuration via SMBus of the
Microchip USB251x/xBi USB 2.0 Hub Controller series. Configuration
parameters may be set in devicetree or platform data.
Say Y or M here if you need to configure such a device via SMBus.
config USB_HSIC_USB3503
tristate "USB3503 HSIC to USB20 Driver"
depends on I2C
select REGMAP_I2C
help
This option enables support for SMSC USB3503 HSIC to USB 2.0 Driver.
config USB_HSIC_USB4604
tristate "USB4604 HSIC to USB20 Driver"
depends on I2C
help
This option enables support for SMSC USB4604 HSIC to USB 2.0 Driver.
USB: Add LVS Test device driver OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification system (SS-OVS) which consists of an excersizer and analyzer. USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for Link Layer Validation (LVS). Some modifications are needed for an embedded Linux USB host to pass all these tests. Most of these tests require just Link to be in U0. They do not work with default Linux USB stack since, default stack does port reset and then starts sending setup packet, which is not expected by Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then, There are many Link Layer Tests which need host to generate specific traffic. This patch supports specific traffic generation cases. As of now all the host Lecroy Link Layer-USBIF tests (except TD7.26) passes with this patch for single run using Lecroy USB Compliance Suite Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80 Build 1603. Therefore patch seems to be a good candidate for inclusion. Further modification can be done on top of it. lvstest driver will not bind to any device by default. It can bind manually to a super speed USB host controller root hub. Therefore, regular hub driver must be unbound before this driver is bound. For example, if 2-0:1.0 is the xhci root hub, then execute following to unbind hub driver. echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind Then write Linux Foundation's vendor ID which is used by root hubs and SS root hub's device ID into new_id file. Writing IDs into new_id file will also bind the lvs driver with any available SS root hub interfaces. echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id Now connect LVS device with root hub port. Test case specific traffic can be generated as follows whenever needed: 1. To issue "Get Device descriptor" command for TD.7.06: echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc 2. To set U1 timeout to 127 for TD.7.18 echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout 3. To set U2 timeout to 0 for TD.7.18 echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout 4. To issue "Hot Reset" for TD.7.29 echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset 5. To issue "U3 Entry" for TD.7.35 echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry 6. To issue "U3 Exit" for TD.7.36 echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-14 21:57:49 +08:00
config USB_LINK_LAYER_TEST
tristate "USB Link Layer Test driver"
help
This driver is for generating specific traffic for Super Speed Link
Layer Test Device. Say Y only when you want to conduct USB Super Speed
Link Layer Test for host controllers.
config USB_CHAOSKEY
tristate "ChaosKey random number generator driver support"
depends on HW_RANDOM
help
Say Y here if you want to connect an AltusMetrum ChaosKey or
Araneus Alea I to your computer's USB port. These devices
are hardware random number generators which hook into the
kernel entropy pool to ensure a large supply of entropy for
/dev/random and /dev/urandom and also provides direct access
via /dev/chaoskeyX
To compile this driver as a module, choose M here: the
module will be called chaoskey.
config BRCM_USB_PINMAP
tristate "Broadcom pinmap driver support"
depends on (ARCH_BRCMSTB && PHY_BRCM_USB) || COMPILE_TEST
default ARCH_BRCMSTB && PHY_BRCM_USB
help
This option enables support for remapping some USB external
signals, which are typically on dedicated pins on the chip,
to any gpio.
usb: misc: Add onboard_usb_hub driver The main issue this driver addresses is that a USB hub needs to be powered before it can be discovered. For discrete onboard hubs (an example for such a hub is the Realtek RTS5411) this is often solved by supplying the hub with an 'always-on' regulator, which is kind of a hack. Some onboard hubs may require further initialization steps, like changing the state of a GPIO or enabling a clock, which requires even more hacks. This driver creates a platform device representing the hub which performs the necessary initialization. Currently it only supports switching on a single regulator, support for multiple regulators or other actions can be added as needed. Different initialization sequences can be supported based on the compatible string. Besides performing the initialization the driver can be configured to power the hub off during system suspend. This can help to extend battery life on battery powered devices which have no requirements to keep the hub powered during suspend. The driver can also be configured to leave the hub powered when a wakeup capable USB device is connected when suspending, and power it off otherwise. Technically the driver consists of two drivers, the platform driver described above and a very thin USB driver that subclasses the generic driver. The purpose of this driver is to provide the platform driver with the USB devices corresponding to the hub(s) (a hub controller may provide multiple 'logical' hubs, e.g. one to support USB 2.0 and another for USB 3.x). Co-developed-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220630123445.v24.3.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-01 03:35:29 +08:00
config USB_ONBOARD_HUB
tristate "Onboard USB hub support"
depends on OF
usb: misc: Add onboard_usb_hub driver The main issue this driver addresses is that a USB hub needs to be powered before it can be discovered. For discrete onboard hubs (an example for such a hub is the Realtek RTS5411) this is often solved by supplying the hub with an 'always-on' regulator, which is kind of a hack. Some onboard hubs may require further initialization steps, like changing the state of a GPIO or enabling a clock, which requires even more hacks. This driver creates a platform device representing the hub which performs the necessary initialization. Currently it only supports switching on a single regulator, support for multiple regulators or other actions can be added as needed. Different initialization sequences can be supported based on the compatible string. Besides performing the initialization the driver can be configured to power the hub off during system suspend. This can help to extend battery life on battery powered devices which have no requirements to keep the hub powered during suspend. The driver can also be configured to leave the hub powered when a wakeup capable USB device is connected when suspending, and power it off otherwise. Technically the driver consists of two drivers, the platform driver described above and a very thin USB driver that subclasses the generic driver. The purpose of this driver is to provide the platform driver with the USB devices corresponding to the hub(s) (a hub controller may provide multiple 'logical' hubs, e.g. one to support USB 2.0 and another for USB 3.x). Co-developed-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220630123445.v24.3.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-01 03:35:29 +08:00
help
Say Y here if you want to support discrete onboard USB hubs that
don't require an additional control bus for initialization, but
need some non-trivial form of initialization, such as enabling a
power regulator. An example for such a hub is the Realtek
RTS5411.
This driver can be used as a module but its state (module vs
builtin) must match the state of the USB subsystem. Enabling
this config will enable the driver and it will automatically
match the state of the USB subsystem. If this driver is a
module it will be called onboard_usb_hub.