linux/drivers/misc/Kconfig

632 lines
21 KiB
Plaintext
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0-only
#
# Misc strange devices
#
menu "Misc devices"
config SENSORS_LIS3LV02D
tristate
depends on INPUT
config AD525X_DPOT
tristate "Analog Devices Digital Potentiometers"
depends on (I2C || SPI) && SYSFS
help
If you say yes here, you get support for the Analog Devices
AD5258, AD5259, AD5251, AD5252, AD5253, AD5254, AD5255
AD5160, AD5161, AD5162, AD5165, AD5200, AD5201, AD5203,
AD5204, AD5206, AD5207, AD5231, AD5232, AD5233, AD5235,
AD5260, AD5262, AD5263, AD5290, AD5291, AD5292, AD5293,
AD7376, AD8400, AD8402, AD8403, ADN2850, AD5241, AD5242,
AD5243, AD5245, AD5246, AD5247, AD5248, AD5280, AD5282,
ADN2860, AD5273, AD5171, AD5170, AD5172, AD5173, AD5270,
AD5271, AD5272, AD5274
digital potentiometer chips.
See Documentation/misc-devices/ad525x_dpot.rst for the
userspace interface.
This driver can also be built as a module. If so, the module
will be called ad525x_dpot.
config AD525X_DPOT_I2C
tristate "support I2C bus connection"
depends on AD525X_DPOT && I2C
help
Say Y here if you have a digital potentiometers hooked to an I2C bus.
To compile this driver as a module, choose M here: the
module will be called ad525x_dpot-i2c.
config AD525X_DPOT_SPI
tristate "support SPI bus connection"
depends on AD525X_DPOT && SPI_MASTER
help
Say Y here if you have a digital potentiometers hooked to an SPI bus.
If unsure, say N (but it's safe to say "Y").
To compile this driver as a module, choose M here: the
module will be called ad525x_dpot-spi.
config DUMMY_IRQ
tristate "Dummy IRQ handler"
help
This module accepts a single 'irq' parameter, which it should register for.
The sole purpose of this module is to help with debugging of systems on
which spurious IRQs would happen on disabled IRQ vector.
config IBM_ASM
tristate "Device driver for IBM RSA service processor"
depends on X86 && PCI && INPUT
depends on SERIAL_8250 || SERIAL_8250=n
help
This option enables device driver support for in-band access to the
IBM RSA (Condor) service processor in eServer xSeries systems.
The ibmasm device driver allows user space application to access
ASM (Advanced Systems Management) functions on the service
processor. The driver is meant to be used in conjunction with
a user space API.
The ibmasm driver also enables the OS to use the UART on the
service processor board as a regular serial port. To make use of
this feature serial driver support (CONFIG_SERIAL_8250) must be
enabled.
WARNING: This software may not be supported or function
correctly on your IBM server. Please consult the IBM ServerProven
website <https://www-03.ibm.com/systems/info/x86servers/serverproven/compat/us/>
for information on the specific driver level and support statement
for your IBM server.
config IBMVMC
tristate "IBM Virtual Management Channel support"
depends on PPC_PSERIES
help
This is the IBM POWER Virtual Management Channel
This driver is to be used for the POWER Virtual
Management Channel virtual adapter on the PowerVM
platform. It provides both request/response and
async message support through the /dev/ibmvmc node.
To compile this driver as a module, choose M here: the
module will be called ibmvmc.
config PHANTOM
tristate "Sensable PHANToM (PCI)"
depends on PCI
help
Say Y here if you want to build a driver for Sensable PHANToM device.
This driver is only for PCI PHANToMs.
If you choose to build module, its name will be phantom. If unsure,
say N here.
rpmb: add Replay Protected Memory Block (RPMB) subsystem A number of storage technologies support a specialised hardware partition designed to be resistant to replay attacks. The underlying HW protocols differ but the operations are common. The RPMB partition cannot be accessed via standard block layer, but by a set of specific RPMB commands. Such a partition provides authenticated and replay protected access, hence suitable as a secure storage. The initial aim of this patch is to provide a simple RPMB driver interface which can be accessed by the optee driver to facilitate early RPMB access to OP-TEE OS (secure OS) during the boot time. A TEE device driver can claim the RPMB interface, for example, via rpmb_interface_register() or rpmb_dev_find_device(). The RPMB driver provides a callback to route RPMB frames to the RPMB device accessible via rpmb_route_frames(). The detailed operation of implementing the access is left to the TEE device driver itself. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Manuel Traut <manut@mecka.net> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240814153558.708365-2-jens.wiklander@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-08-14 15:35:55 +00:00
config RPMB
tristate "RPMB partition interface"
depends on MMC
help
Unified RPMB unit interface for RPMB capable devices such as eMMC and
UFS. Provides interface for in-kernel security controllers to access
RPMB unit.
If unsure, select N.
config TIFM_CORE
tristate "TI Flash Media interface support"
depends on PCI
help
If you want support for Texas Instruments(R) Flash Media adapters
you should select this option and then also choose an appropriate
host adapter, such as 'TI Flash Media PCI74xx/PCI76xx host adapter
support', if you have a TI PCI74xx compatible card reader, for
example.
You will also have to select some flash card format drivers. MMC/SD
cards are supported via 'MMC/SD Card support: TI Flash Media MMC/SD
Interface support (MMC_TIFM_SD)'.
To compile this driver as a module, choose M here: the module will
be called tifm_core.
config TIFM_7XX1
tristate "TI Flash Media PCI74xx/PCI76xx host adapter support"
depends on PCI && TIFM_CORE
default TIFM_CORE
help
This option enables support for Texas Instruments(R) PCI74xx and
PCI76xx families of Flash Media adapters, found in many laptops.
To make actual use of the device, you will have to select some
flash card format drivers, as outlined in the TIFM_CORE Help.
To compile this driver as a module, choose M here: the module will
be called tifm_7xx1.
config ICS932S401
tristate "Integrated Circuits ICS932S401"
depends on I2C
help
If you say yes here you get support for the Integrated Circuits
ICS932S401 clock control chips.
This driver can also be built as a module. If so, the module
will be called ics932s401.
config ATMEL_SSC
tristate "Device driver for Atmel SSC peripheral"
depends on HAS_IOMEM && (ARCH_AT91 || COMPILE_TEST)
help
This option enables device driver support for Atmel Synchronized
Serial Communication peripheral (SSC).
The SSC peripheral supports a wide variety of serial frame based
communications, i.e. I2S, SPI, etc.
If unsure, say N.
config ENCLOSURE_SERVICES
tristate "Enclosure Services"
help
Provides support for intelligent enclosures (bays which
contain storage devices). You also need either a host
driver (SCSI/ATA) which supports enclosures
or a SCSI enclosure device (SES) to use these services.
config SGI_XP
tristate "Support communication between SGI SSIs"
depends on NET
arch: Remove Itanium (IA-64) architecture The Itanium architecture is obsolete, and an informal survey [0] reveals that any residual use of Itanium hardware in production is mostly HP-UX or OpenVMS based. The use of Linux on Itanium appears to be limited to enthusiasts that occasionally boot a fresh Linux kernel to see whether things are still working as intended, and perhaps to churn out some distro packages that are rarely used in practice. None of the original companies behind Itanium still produce or support any hardware or software for the architecture, and it is listed as 'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers that contributed on behalf of those companies (nor anyone else, for that matter) have been willing to support or maintain the architecture upstream or even be responsible for applying the odd fix. The Intel firmware team removed all IA-64 support from the Tianocore/EDK2 reference implementation of EFI in 2018. (Itanium is the original architecture for which EFI was developed, and the way Linux supports it deviates significantly from other architectures.) Some distros, such as Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have dropped support years ago. While the argument is being made [1] that there is a 'for the common good' angle to being able to build and run existing projects such as the Grid Community Toolkit [2] on Itanium for interoperability testing, the fact remains that none of those projects are known to be deployed on Linux/ia64, and very few people actually have access to such a system in the first place. Even if there were ways imaginable in which Linux/ia64 could be put to good use today, what matters is whether anyone is actually doing that, and this does not appear to be the case. There are no emulators widely available, and so boot testing Itanium is generally infeasible for ordinary contributors. GCC still supports IA-64 but its compile farm [3] no longer has any IA-64 machines. GLIBC would like to get rid of IA-64 [4] too because it would permit some overdue code cleanups. In summary, the benefits to the ecosystem of having IA-64 be part of it are mostly theoretical, whereas the maintenance overhead of keeping it supported is real. So let's rip off the band aid, and remove the IA-64 arch code entirely. This follows the timeline proposed by the Debian/ia64 maintainer [5], which removes support in a controlled manner, leaving IA-64 in a known good state in the most recent LTS release. Other projects will follow once the kernel support is removed. [0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/ [1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/ [2] https://gridcf.org/gct-docs/latest/index.html [3] https://cfarm.tetaneutral.net/machines/list/ [4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/ [5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/ Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-10-20 13:54:33 +00:00
depends on X86_UV && SMP
depends on X86_64 || BROKEN
select SGI_GRU if X86_64 && SMP
help
An SGI machine can be divided into multiple Single System
Images which act independently of each other and have
hardware based memory protection from the others. Enabling
this feature will allow for direct communication between SSIs
based on a network adapter and DMA messaging.
config SMPRO_ERRMON
tristate "Ampere Computing SMPro error monitor driver"
depends on MFD_SMPRO || COMPILE_TEST
help
Say Y here to get support for the SMpro error monitor function
provided by Ampere Computing's Altra and Altra Max SoCs. Upon
loading, the driver creates sysfs files which can be use to gather
multiple HW error data reported via read and write system calls.
To compile this driver as a module, say M here. The driver will be
called smpro-errmon.
config SMPRO_MISC
tristate "Ampere Computing SMPro miscellaneous driver"
depends on MFD_SMPRO || COMPILE_TEST
help
Say Y here to get support for the SMpro error miscellalenous function
provided by Ampere Computing's Altra and Altra Max SoCs.
To compile this driver as a module, say M here. The driver will be
called smpro-misc.
config CS5535_MFGPT
tristate "CS5535/CS5536 Geode Multi-Function General Purpose Timer (MFGPT) support"
depends on MFD_CS5535
help
This driver provides access to MFGPT functionality for other
drivers that need timers. MFGPTs are available in the CS5535 and
CS5536 companion chips that are found in AMD Geode and several
other platforms. They have a better resolution and max interval
than the generic PIT, and are suitable for use as high-res timers.
You probably don't want to enable this manually; other drivers that
make use of it should enable it.
config CS5535_MFGPT_DEFAULT_IRQ
int
depends on CS5535_MFGPT
default 7
help
MFGPTs on the CS5535 require an interrupt. The selected IRQ
can be overridden as a module option as well as by driver that
use the cs5535_mfgpt_ API; however, different architectures might
want to use a different IRQ by default. This is here for
architectures to set as necessary.
config CS5535_CLOCK_EVENT_SRC
tristate "CS5535/CS5536 high-res timer (MFGPT) events"
depends on GENERIC_CLOCKEVENTS && CS5535_MFGPT
help
This driver provides a clock event source based on the MFGPT
timer(s) in the CS5535 and CS5536 companion chips.
MFGPTs have a better resolution and max interval than the
generic PIT, and are suitable for use as high-res timers.
config GEHC_ACHC
tristate "GEHC ACHC support"
depends on SPI && SYSFS
depends on SOC_IMX53 || COMPILE_TEST
select FW_LOADER
help
Support for GE ACHC microcontroller, that is part of the GE
PPD device.
To compile this driver as a module, choose M here: the
module will be called gehc-achc.
config HI6421V600_IRQ
tristate "HiSilicon Hi6421v600 IRQ and powerkey"
depends on OF
depends on SPMI
depends on HAS_IOMEM
select MFD_CORE
select REGMAP_SPMI
help
This driver provides IRQ handling for Hi6421v600, used on
some Kirin chipsets, like the one at Hikey 970.
config HP_ILO
tristate "Channel interface driver for the HP iLO processor"
depends on PCI
help
The channel interface driver allows applications to communicate
with iLO management processors present on HP ProLiant servers.
Upon loading, the driver creates /dev/hpilo/dXccbN files, which
can be used to gather data from the management processor, via
read and write system calls.
To compile this driver as a module, choose M here: the
module will be called hpilo.
config QCOM_COINCELL
tristate "Qualcomm coincell charger support"
depends on MFD_SPMI_PMIC || COMPILE_TEST
help
This driver supports the coincell block found inside of
Qualcomm PMICs. The coincell charger provides a means to
charge a coincell battery or backup capacitor which is used
to maintain PMIC register and RTC state in the absence of
external power.
config QCOM_FASTRPC
tristate "Qualcomm FastRPC"
depends on ARCH_QCOM || COMPILE_TEST
depends on RPMSG
misc: fastrpc: select CONFIG_DMA_SHARED_BUFFER Fastrpc is a dma buf exporter as well, so select the corresponding DMA_SHARED_BUFFER config to fix below compilation errors on platforms without this config. ld: drivers/misc/fastrpc.o: in function 'fastrpc_free_map': fastrpc.c:(.text+0xbe): undefined reference to 'dma_buf_unmap_attachment' ld: fastrpc.c:(.text+0xcb): undefined reference to 'dma_buf_detach' ld: fastrpc.c:(.text+0xd4): undefined reference to 'dma_buf_put' ld: drivers/misc/fastrpc.o: in function 'fastrpc_map_create': fastrpc.c:(.text+0xb2b): undefined reference to 'dma_buf_get' ld: fastrpc.c:(.text+0xb47): undefined reference to 'dma_buf_attach' ld: fastrpc.c:(.text+0xb61): undefined reference to 'dma_buf_map_attachment' ld: fastrpc.c:(.text+0xc36): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0xc48): undefined reference to 'dma_buf_detach' ld: drivers/misc/fastrpc.o: in function 'fastrpc_device_ioctl': fastrpc.c:(.text+0x1756): undefined reference to 'dma_buf_get' ld: fastrpc.c:(.text+0x1776): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0x1780): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0x1abf): undefined reference to 'dma_buf_export' ld: fastrpc.c:(.text+0x1ae7): undefined reference to 'dma_buf_fd' ld: fastrpc.c:(.text+0x1cb5): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0x1cca): undefined reference to 'dma_buf_put' Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-15 10:40:06 +00:00
select DMA_SHARED_BUFFER
select QCOM_SCM
help
Provides a communication mechanism that allows for clients to
make remote method invocations across processor boundary to
applications DSP processor. Say M if you want to enable this
module.
config SGI_GRU
tristate "SGI GRU driver"
depends on X86_UV && SMP
select MMU_NOTIFIER
help
The GRU is a hardware resource located in the system chipset. The GRU
contains memory that can be mmapped into the user address space.
This memory is used to communicate with the GRU to perform functions
such as load/store, scatter/gather, bcopy, AMOs, etc. The GRU is
directly accessed by user instructions using user virtual addresses.
GRU instructions (ex., bcopy) use user virtual addresses for operands.
If you are not running on a SGI UV system, say N.
config SGI_GRU_DEBUG
bool "SGI GRU driver debug"
depends on SGI_GRU
help
This option enables additional debugging code for the SGI GRU driver.
If you are unsure, say N.
config APDS9802ALS
tristate "Medfield Avago APDS9802 ALS Sensor module"
depends on I2C
help
If you say yes here you get support for the ALS APDS9802 ambient
light sensor.
This driver can also be built as a module. If so, the module
will be called apds9802als.
config ISL29003
tristate "Intersil ISL29003 ambient light sensor"
depends on I2C && SYSFS
help
If you say yes here you get support for the Intersil ISL29003
ambient light sensor.
This driver can also be built as a module. If so, the module
will be called isl29003.
config ISL29020
tristate "Intersil ISL29020 ambient light sensor"
depends on I2C
help
If you say yes here you get support for the Intersil ISL29020
ambient light sensor.
This driver can also be built as a module. If so, the module
will be called isl29020.
config SENSORS_TSL2550
tristate "Taos TSL2550 ambient light sensor"
depends on I2C && SYSFS
help
If you say yes here you get support for the Taos TSL2550
ambient light sensor.
This driver can also be built as a module. If so, the module
will be called tsl2550.
config SENSORS_BH1770
tristate "BH1770GLC / SFH7770 combined ALS - Proximity sensor"
depends on I2C
help
Say Y here if you want to build a driver for BH1770GLC (ROHM) or
SFH7770 (Osram) combined ambient light and proximity sensor chip.
To compile this driver as a module, choose M here: the
module will be called bh1770glc. If unsure, say N here.
config SENSORS_APDS990X
tristate "APDS990X combined als and proximity sensors"
depends on I2C
help
Say Y here if you want to build a driver for Avago APDS990x
combined ambient light and proximity sensor chip.
To compile this driver as a module, choose M here: the
module will be called apds990x. If unsure, say N here.
config HMC6352
tristate "Honeywell HMC6352 compass"
depends on I2C
help
This driver provides support for the Honeywell HMC6352 compass,
providing configuration and heading data via sysfs.
config DS1682
tristate "Dallas DS1682 Total Elapsed Time Recorder with Alarm"
depends on I2C
help
If you say yes here you get support for Dallas Semiconductor
DS1682 Total Elapsed Time Recorder.
This driver can also be built as a module. If so, the module
will be called ds1682.
VMware Balloon driver This is a standalone version of VMware Balloon driver. Ballooning is a technique that allows hypervisor dynamically limit the amount of memory available to the guest (with guest cooperation). In the overcommit scenario, when hypervisor set detects that it needs to shuffle some memory, it instructs the driver to allocate certain number of pages, and the underlying memory gets returned to the hypervisor. Later hypervisor may return memory to the guest by reattaching memory to the pageframes and instructing the driver to "deflate" balloon. We are submitting a standalone driver because KVM maintainer (Avi Kivity) expressed opinion (rightly) that our transport does not fit well into virtqueue paradigm and thus it does not make much sense to integrate with virtio. There were also some concerns whether current ballooning technique is the right thing. If there appears a better framework to achieve this we are prepared to evaluate and switch to using it, but in the meantime we'd like to get this driver upstream. We want to get the driver accepted in distributions so that users do not have to deal with an out-of-tree module and many distributions have "upstream first" requirement. The driver has been shipping for a number of years and users running on VMware platform will have it installed as part of VMware Tools even if it will not come from a distribution, thus there should not be additional risk in pulling the driver into mainline. The driver will only activate if host is VMware so everyone else should not be affected at all. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Cc: Avi Kivity <avi@redhat.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-04-23 17:18:08 +00:00
config VMWARE_BALLOON
tristate "VMware Balloon Driver"
depends on VMWARE_VMCI && X86 && HYPERVISOR_GUEST
select MEMORY_BALLOON
VMware Balloon driver This is a standalone version of VMware Balloon driver. Ballooning is a technique that allows hypervisor dynamically limit the amount of memory available to the guest (with guest cooperation). In the overcommit scenario, when hypervisor set detects that it needs to shuffle some memory, it instructs the driver to allocate certain number of pages, and the underlying memory gets returned to the hypervisor. Later hypervisor may return memory to the guest by reattaching memory to the pageframes and instructing the driver to "deflate" balloon. We are submitting a standalone driver because KVM maintainer (Avi Kivity) expressed opinion (rightly) that our transport does not fit well into virtqueue paradigm and thus it does not make much sense to integrate with virtio. There were also some concerns whether current ballooning technique is the right thing. If there appears a better framework to achieve this we are prepared to evaluate and switch to using it, but in the meantime we'd like to get this driver upstream. We want to get the driver accepted in distributions so that users do not have to deal with an out-of-tree module and many distributions have "upstream first" requirement. The driver has been shipping for a number of years and users running on VMware platform will have it installed as part of VMware Tools even if it will not come from a distribution, thus there should not be additional risk in pulling the driver into mainline. The driver will only activate if host is VMware so everyone else should not be affected at all. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Cc: Avi Kivity <avi@redhat.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-04-23 17:18:08 +00:00
help
This is VMware physical memory management driver which acts
like a "balloon" that can be inflated to reclaim physical pages
by reserving them in the guest and invalidating them in the
monitor, freeing up the underlying machine pages so they can
be allocated to other guests. The balloon can also be deflated
to allow the guest to use more physical memory.
If unsure, say N.
To compile this driver as a module, choose M here: the
module will be called vmw_balloon.
VMware Balloon driver This is a standalone version of VMware Balloon driver. Ballooning is a technique that allows hypervisor dynamically limit the amount of memory available to the guest (with guest cooperation). In the overcommit scenario, when hypervisor set detects that it needs to shuffle some memory, it instructs the driver to allocate certain number of pages, and the underlying memory gets returned to the hypervisor. Later hypervisor may return memory to the guest by reattaching memory to the pageframes and instructing the driver to "deflate" balloon. We are submitting a standalone driver because KVM maintainer (Avi Kivity) expressed opinion (rightly) that our transport does not fit well into virtqueue paradigm and thus it does not make much sense to integrate with virtio. There were also some concerns whether current ballooning technique is the right thing. If there appears a better framework to achieve this we are prepared to evaluate and switch to using it, but in the meantime we'd like to get this driver upstream. We want to get the driver accepted in distributions so that users do not have to deal with an out-of-tree module and many distributions have "upstream first" requirement. The driver has been shipping for a number of years and users running on VMware platform will have it installed as part of VMware Tools even if it will not come from a distribution, thus there should not be additional risk in pulling the driver into mainline. The driver will only activate if host is VMware so everyone else should not be affected at all. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Cc: Avi Kivity <avi@redhat.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-04-23 17:18:08 +00:00
config PCH_PHUB
tristate "Intel EG20T PCH/LAPIS Semicon IOH(ML7213/ML7223/ML7831) PHUB"
select GENERIC_NET_UTILS
depends on PCI && (X86_32 || MIPS || COMPILE_TEST)
help
This driver is for PCH(Platform controller Hub) PHUB(Packet Hub) of
Intel Topcliff which is an IOH(Input/Output Hub) for x86 embedded
processor. The Topcliff has MAC address and Option ROM data in SROM.
This driver can access MAC address and Option ROM data in SROM.
This driver also can be used for LAPIS Semiconductor's IOH,
ML7213/ML7223/ML7831.
ML7213 which is for IVI(In-Vehicle Infotainment) use.
ML7223 IOH is for MP(Media Phone) use.
ML7831 IOH is for general purpose use.
ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
To compile this driver as a module, choose M here: the module will
be called pch_phub.
config LATTICE_ECP3_CONFIG
tristate "Lattice ECP3 FPGA bitstream configuration via SPI"
depends on SPI && SYSFS
select FW_LOADER
help
This option enables support for bitstream configuration (programming
or loading) of the Lattice ECP3 FPGA family via SPI.
If unsure, say N.
config SRAM
bool "Generic on-chip SRAM driver"
depends on HAS_IOMEM
select GENERIC_ALLOCATOR
select SRAM_EXEC if ARM
help
This driver allows you to declare a memory region to be managed by
the genalloc API. It is supposed to be used for small on-chip SRAM
areas found on many SoCs.
config SRAM_EXEC
bool
config DW_XDATA_PCIE
depends on PCI
tristate "Synopsys DesignWare xData PCIe driver"
help
This driver allows controlling Synopsys DesignWare PCIe traffic
generator IP also known as xData, present in Synopsys DesignWare
PCIe Endpoint prototype.
If unsure, say N.
config PCI_ENDPOINT_TEST
depends on PCI
select CRC32
tristate "PCI Endpoint Test driver"
help
Enable this configuration option to enable the host side test driver
for PCI Endpoint.
config XILINX_SDFEC
tristate "Xilinx SDFEC 16"
depends on HAS_IOMEM
help
This option enables support for the Xilinx SDFEC (Soft Decision
Forward Error Correction) driver. This enables a char driver
for the SDFEC.
You may select this driver if your design instantiates the
SDFEC(16nm) hardened block. To compile this as a module choose M.
If unsure, say N.
config MISC_RTSX
tristate
default MISC_RTSX_PCI || MISC_RTSX_USB
config HISI_HIKEY_USB
tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform"
depends on (OF && GPIOLIB) || COMPILE_TEST
depends on USB_ROLE_SWITCH
help
If you say yes here this adds support for the on-board USB GPIO hub
found on HiKey 960/970 boards, which is necessary to support
switching between the dual-role USB-C port and the USB-A host ports
using only one USB controller.
config OPEN_DICE
tristate "Open Profile for DICE driver"
depends on OF_RESERVED_MEM
depends on HAS_IOMEM
help
This driver exposes a DICE reserved memory region to userspace via
a character device. The memory region contains Compound Device
Identifiers (CDIs) generated by firmware as an output of DICE
measured boot flow. Userspace can use CDIs for remote attestation
and sealing.
If unsure, say N.
config NTSYNC
tristate "NT synchronization primitive emulation"
depends on BROKEN
help
This module provides kernel support for emulation of Windows NT
synchronization primitives. It is not a hardware driver.
To compile this driver as a module, choose M here: the
module will be called ntsync.
If unsure, say N.
config VCPU_STALL_DETECTOR
tristate "Guest vCPU stall detector"
depends on OF && HAS_IOMEM
help
When this driver is bound inside a KVM guest, it will
periodically "pet" an MMIO stall detector device from each vCPU
and allow the host to detect vCPU stalls.
To compile this driver as a module, choose M here: the module
will be called vcpu_stall_detector.
If you do not intend to run this kernel as a guest, say N.
config TMR_MANAGER
tristate "Select TMR Manager"
depends on MICROBLAZE && MB_MANAGER
help
This option enables the driver developed for TMR Manager.
The Triple Modular Redundancy(TMR) manager provides support for
fault detection.
Say N here unless you know what you are doing.
config TMR_INJECT
tristate "Select TMR Inject"
depends on TMR_MANAGER && FAULT_INJECTION_DEBUG_FS
help
This option enables the driver developed for TMR Inject.
The Triple Modular Redundancy(TMR) Inject provides
fault injection.
Say N here unless you know what you are doing.
config TPS6594_ESM
tristate "TI TPS6594 Error Signal Monitor support"
depends on MFD_TPS6594
default MFD_TPS6594
help
Support ESM (Error Signal Monitor) on TPS6594 PMIC devices.
ESM is used typically to reboot the board in error condition.
This driver can also be built as a module. If so, the module
will be called tps6594-esm.
config TPS6594_PFSM
tristate "TI TPS6594 Pre-configurable Finite State Machine support"
depends on MFD_TPS6594
default MFD_TPS6594
help
Support PFSM (Pre-configurable Finite State Machine) on TPS6594 PMIC devices.
These devices integrate a finite state machine engine, which manages the state
of the device during operating state transition.
This driver can also be built as a module. If so, the module
will be called tps6594-pfsm.
config NSM
tristate "Nitro (Enclaves) Security Module support"
depends on VIRTIO
select HW_RANDOM
help
This driver provides support for the Nitro Security Module
in AWS EC2 Nitro based Enclaves. The driver exposes a /dev/nsm
device user space can use to communicate with the hypervisor.
To compile this driver as a module, choose M here.
The module will be called nsm.
config MARVELL_CN10K_DPI
tristate "Octeon CN10K DPI driver"
depends on PCI && PCI_IOV
depends on ARCH_THUNDER || (COMPILE_TEST && 64BIT)
help
Enables Octeon CN10K DMA packet interface (DPI) driver which
intializes DPI hardware's physical function (PF) device's
global configuration and its virtual function (VFs) resource
configuration to enable DMA transfers. DPI PF device does not
have any data movement functionality, it only serves VF's
resource configuration requests.
To compile this driver as a module, choose M here: the module
will be called mrvl_cn10k_dpi.
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
source "drivers/misc/ti-st/Kconfig"
source "drivers/misc/lis3lv02d/Kconfig"
source "drivers/misc/altera-stapl/Kconfig"
source "drivers/misc/mei/Kconfig"
source "drivers/misc/vmw_vmci/Kconfig"
source "drivers/misc/genwqe/Kconfig"
source "drivers/misc/echo/Kconfig"
source "drivers/misc/cxl/Kconfig"
source "drivers/misc/ocxl/Kconfig"
source "drivers/misc/bcm-vk/Kconfig"
source "drivers/misc/cardreader/Kconfig"
uacce: add uacce driver Uacce (Unified/User-space-access-intended Accelerator Framework) targets to provide Shared Virtual Addressing (SVA) between accelerators and processes. So accelerator can access any data structure of the main cpu. This differs from the data sharing between cpu and io device, which share only data content rather than address. Since unified address, hardware and user space of process can share the same virtual address in the communication. Uacce create a chrdev for every registration, the queue is allocated to the process when the chrdev is opened. Then the process can access the hardware resource by interact with the queue file. By mmap the queue file space to user space, the process can directly put requests to the hardware without syscall to the kernel space. The IOMMU core only tracks mm<->device bonds at the moment, because it only needs to handle IOTLB invalidation and PASID table entries. However uacce needs a finer granularity since multiple queues from the same device can be bound to an mm. When the mm exits, all bound queues must be stopped so that the IOMMU can safely clear the PASID table entry and reallocate the PASID. An intermediate struct uacce_mm links uacce devices and queues. Note that an mm may be bound to multiple devices but an uacce_mm structure only ever belongs to a single device, because we don't need anything more complex (if multiple devices are bound to one mm, then we'll create one uacce_mm for each bond). uacce_device --+-- uacce_mm --+-- uacce_queue | '-- uacce_queue | '-- uacce_mm --+-- uacce_queue +-- uacce_queue '-- uacce_queue Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Kenneth Lee <liguozhu@hisilicon.com> Signed-off-by: Zaibo Xu <xuzaibo@huawei.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-02-11 07:54:23 +00:00
source "drivers/misc/uacce/Kconfig"
source "drivers/misc/pvpanic/Kconfig"
source "drivers/misc/mchp_pci1xxxx/Kconfig"
source "drivers/misc/keba/Kconfig"
endmenu