android_kernel_xiaomi_sm7250/drivers/char/Kconfig
Stephan Mueller be966387fe Linux Random Number Generator
In an effort to provide a flexible implementation for a random number
generator that also delivers entropy during early boot time, allows
replacement of the deterministic random number generation mechanism,
implement the various components in separate code for easier
maintenance, and provide compliance to SP800-90[A|B|C], introduce
the Linux Random Number Generator (LRNG) framework.

The general design is as follows. Additional implementation details
are given in [1]. The LRNG consists of the following components:

1. The LRNG implements a DRNG. The DRNG always generates the
requested amount of output. When using the SP800-90A terminology
it operates without prediction resistance. The secondary DRNG
maintains a counter of how many bytes were generated since last
re-seed and a timer of the elapsed time since last re-seed. If either
the counter or the timer reaches a threshold, the secondary DRNG is
seeded from the entropy pool.

In case the Linux kernel detects a NUMA system, one secondary DRNG
instance per NUMA node is maintained.

2. The DRNG is seeded by concatenating the data from the
following sources:

(a) the output of the entropy pool,

(b) the Jitter RNG if available and enabled, and

(c) the CPU-based noise source such as Intel RDRAND if available and
enabled.

The entropy estimate of the data of all noise sources are added to
form the entropy estimate of the data used to seed the DRNG with.
The LRNG ensures, however, that the DRNG after seeding is at
maximum the security strength of the DRNG.

The LRNG is designed such that none of these noise sources can dominate
the other noise sources to provide seed data to the DRNG during due to
the following:

(a) During boot time, the amount of received interrupts are the trigger
points to (re)seed the DRNG.

(b) At runtime, the available entropy from the slow noise source is
concatenated with a pre-defined amount of data from the fast noise
sources. In addition, each DRNG reseed operation triggers external
noise source providers to deliver one block of data.

3. The entropy pool accumulates entropy obtained from certain events,
which will henceforth be collectively called "slow noise sources".
The entropy pool collects noise data from slow noise sources. Any data
received by the LRNG from the slow noise sources is inserted into a
per-CPU entropy pool using a hash operation that can be changed during
runtime. Per default, SHA-256 is used.

 (a) When an interrupt occurs, the high-resolution time stamp is mixed
into the per-CPU entropy pool. This time stamp is credited with
heuristically implied entropy.

 (b) HID event data like the key stroke or the mouse coordinates are
mixed into the per-CPU entropy pool. This data is not credited with
entropy by the LRNG.

 (c) Device drivers may provide data that is mixed into an auxiliary
pool using the same hash that is used to process the per-CPU entropy
pool. This data is not credited with entropy by the LRNG.

Any data provided from user space by either writing to /dev/random,
/dev/urandom or the IOCTL of RNDADDENTROPY on both device files
are always injected into the auxiliary pool.

In addition, when a hardware random number generator covered by the
Linux kernel HW generator framework wants to deliver random numbers,
it is injected into the auxiliary pool as well. HW generator noise source
is handled separately from the other noise source due to the fact that
the HW generator framework may decide by itself when to deliver data
whereas the other noise sources always requested for data driven by the
LRNG operation. Similarly any user space provided data is inserted into
the entropy pool.

When seed data for the DRNG is to be generated, all per-CPU
entropy pools and the auxiliary pool are hashed. The message digest
forms the new auxiliary pool state. At the same time, this data
is used for seeding the DRNG.

To speed up the interrupt handling code of the LRNG, the time stamp
collected for an interrupt event is truncated to the 8 least
significant bits. 64 truncated time stamps are concatenated and then
jointly inserted into the per-CPU entropy pool. During boot time,
until the fully seeded stage is reached, each time stamp with its
32 least significant bits is are concatenated. When 16 such events
are received, they are injected into the per-CPU entropy pool.

The LRNG allows the DRNG mechanism to be changed at runtime. Per default,
a ChaCha20-based DRNG is used. The ChaCha20-DRNG implemented for the
LRNG is also provided as a stand-alone user space deterministic random
number generator. The LRNG also offers an SP800-90A DRBG based on the
Linux kernel crypto API DRBG implementation.

The processing of entropic data from the noise source before injecting
them into the DRNG is performed with the following mathematical
operations:

1. Truncation: The received time stamps are truncated to 8 least
significant bits (or 32 least significant bits during boot time)

2. Concatenation: The received and truncated time stamps as well as
auxiliary 32 bit words are concatenated to fill the per-CPU data
array that is capable of holding 64 8-bit words.

3. Hashing: A set of concatenated time stamp data received from the
interrupts are hashed together with the current existing per-CPU
entropy pool state. The resulting message digest is the new per-CPU
entropy pool state.

4. Hashing: When new data is added to the auxiliary pool, the data
is hashed together with the auxiliary pool to form a new auxiliary
pool state.

5. Hashing: A message digest of all per-CPU entropy pools and the
auxiliary pool is calculated which forms the new auxiliary pool
state. At the same time, this message digest is used to fill the
slow noise source output buffer discussed in the following.

6. Truncation: The most-significant bits (MSB) defined by the
requested number of bits (commonly equal to the security strength
of the DRBG) or the entropy available transported with the buffer
(which is the minimum of the message digest size and the available
entropy in all entropy pools and the auxiliary pool), whatever is
smaller, are obtained from the slow noise source output buffer.

7. Concatenation: The temporary seed buffer used to seed the DRNG
is a concatenation of the slow noise source buffer, the Jitter RNG
output, the CPU noise source output, and the current time.

The DRNG always tries to seed itself with 256 bits of entropy, except
during boot. In any case, if the noise sources cannot deliver that
amount, the available entropy is used and the DRNG keeps track on how
much entropy it was seeded with. The entropy implied by the LRNG
available in the entropy pool may be too conservative. To ensure
that during boot time all available entropy from the entropy pool is
transferred to the DRNG, the hash_df function always generates 256
data bits during boot to seed the DRNG. During boot, the DRNG is
seeded as follows:

1. The DRNG is reseeded from the entropy pool and potentially the fast
noise sources if the entropy pool has collected at least 32 bits of
entropy from the interrupt noise source. The goal of this step is to
ensure that the DRNG receives some initial entropy as early as
possible. In addition it receives the entropy available from
the fast noise sources.

2. The DRNG is reseeded from the entropy pool and potentially the fast
noise sources if all noise sources collectively can provide at least
128 bits of entropy.

3. The DRNG is reseeded from the entropy pool and potentially the fast
noise sources if all noise sources collectivel can provide at least 256
bits.

At the time of the reseeding steps, the DRNG requests as much entropy as
is available in order to skip certain steps and reach the seeding level
of 256 bits. This may imply that one or more of the aforementioned steps
are skipped.

In all listed steps, the DRNG is (re)seeded with a number of random
bytes from the entropy pool that is at most the amount of entropy
present in the entropy pool. This means that when the entropy pool
contains 128 or 256 bits of entropy, the DRNG is seeded with that
amount of entropy as well.

Before the DRNG is seeded with 256 bits of entropy in step 3,
requests of random data from /dev/random and the getrandom system
call are not processed.

The hash operation providing random data from the entropy pools will
always require that all entropy sources collectively can deliver at
least 128 entropy bits.

The DRNG operates as deterministic random number generator with the
following properties:

* The maximum number of random bytes that can be generated with one
DRNG generate operation is limited to 4096 bytes. When longer random
numbers are requested, multiple DRNG generate operations are performed.
The ChaCha20 DRNG as well as the SP800-90A DRBGs implement an update of
their state after completing a generate request for backtracking
resistance.

* The secondary DRNG is reseeded with whatever entropy is available –
in the worst case where no additional entropy can be provided by the
noise sources, the DRNG is not re-seeded and continues its operation
to try to reseed again after again the expiry of one of these thresholds:

 - If the last reseeding of the secondary DRNG is more than 600 seconds
   ago, or

 - 2^20 DRNG generate operations are performed, whatever comes first, or

 - the secondary DRNG is forced to reseed before the next generation of
   random numbers if data has been injected into the LRNG by writing data
   into /dev/random or /dev/urandom.

The chosen values prevent high-volume requests from user space to cause
frequent reseeding operations which drag down the performance of the
DRNG.

With the automatic reseeding after 600 seconds, the LRNG is triggered
to reseed itself before the first request after a suspend that put the
hardware to sleep for longer than 600 seconds.

To support smaller devices including IoT environments, this patch
allows reducing the runtime memory footprint of the LRNG at compile
time by selecting smaller collection data sizes.

When selecting the compilation of a kernel for a small environment,
prevent the allocation of a buffer up to 4096 bytes to serve user space
requests. In this case, the stack variable of 64 bytes is used to serve
all user space requests.

The LRNG has the following properties:

* internal noise source: interrupts timing with fast boot time seeding

* high performance of interrupt handling code: The LRNG impact on the
interrupt handling has been reduced to a minimum. On one example
system, the LRNG interrupt handling code in its fastest configuration
executes within an average 55 cycles whereas the existing
/dev/random on the same device takes about 97 cycles when measuring
the execution time of add_interrupt_randomness().

* use of almost never contended lock for hashing operation to collect
  raw entropy supporting concurrency-free use of massive parallel
  systems - worst case rate of contention is the number of DRNG
  reseeds, usually: number of NUMA nodes contentions per 5 minutes.

* use of standalone ChaCha20 based RNG with the option to use a
  different DRNG selectable at compile time

* instantiate one DRNG per NUMA node

* support for runtime switchable output DRNGs

* use of runtime-switchable hash for conditioning implementation
following widely accepted approach

* compile-time selectable collection size

* support of small systems by allowing the reduction of the
runtime memory needs

Further details including the rationale for the design choices and
properties of the LRNG together with testing is provided at [1].
In addition, the documentation explains the conducted regression
tests to verify that the LRNG is API and ABI compatible with the
existing /dev/random implementation.

[1] https://www.chronox.de/lrng.html

CC: Torsten Duwe <duwe@lst.de>
CC: "Eric W. Biederman" <ebiederm@xmission.com>
CC: "Alexander E. Patrakov" <patrakov@gmail.com>
CC: "Ahmed S. Darwish" <darwish.07@gmail.com>
CC: "Theodore Y. Ts'o" <tytso@mit.edu>
CC: Willy Tarreau <w@1wt.eu>
CC: Matthew Garrett <mjg59@srcf.ucam.org>
CC: Vito Caputo <vcaputo@pengaru.com>
CC: Andreas Dilger <adilger.kernel@dilger.ca>
CC: Jan Kara <jack@suse.cz>
CC: Ray Strode <rstrode@redhat.com>
CC: William Jon McCann <mccann@jhu.edu>
CC: zhangjs <zachary@baishancloud.com>
CC: Andy Lutomirski <luto@kernel.org>
CC: Florian Weimer <fweimer@redhat.com>
CC: Lennart Poettering <mzxreary@0pointer.de>
CC: Nicolai Stange <nstange@suse.de>
Reviewed-by: Alexander Lobakin <alobakin@pm.me>
Tested-by: Alexander Lobakin <alobakin@pm.me>
Mathematical aspects Reviewed-by: "Peter, Matthias" <matthias.peter@bsi.bund.de>
Reviewed-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Reviewed-by: Roman Drahtmueller <draht@schaltsekun.de>
Tested-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Tested-by: Neil Horman <nhorman@redhat.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Change-Id: I0d6de43dd73f6c4455ba5c5fc98cdf63fd620d5a
2022-11-12 11:23:14 +00:00

714 lines
25 KiB
Plaintext

# SPDX-License-Identifier: GPL-2.0
#
# Character device configuration
#
menu "Character devices"
source "drivers/tty/Kconfig"
config DEVMEM
bool "/dev/mem virtual device support"
default y
help
Say Y here if you want to support the /dev/mem device.
The /dev/mem device is used to access areas of physical
memory.
When in doubt, say "Y".
config DEVKMEM
bool "/dev/kmem virtual device support"
# On arm64, VMALLOC_START < PAGE_OFFSET, which confuses kmem read/write
depends on !ARM64
help
Say Y here if you want to support the /dev/kmem device. The
/dev/kmem device is rarely used, but can be used for certain
kind of kernel debugging operations.
When in doubt, say "N".
config SGI_SNSC
bool "SGI Altix system controller communication support"
depends on (IA64_SGI_SN2 || IA64_GENERIC)
help
If you have an SGI Altix and you want to enable system
controller communication from user space (you want this!),
say Y. Otherwise, say N.
config SGI_TIOCX
bool "SGI TIO CX driver support"
depends on (IA64_SGI_SN2 || IA64_GENERIC)
help
If you have an SGI Altix and you have fpga devices attached
to your TIO, say Y here, otherwise say N.
config SGI_MBCS
tristate "SGI FPGA Core Services driver support"
depends on SGI_TIOCX
help
If you have an SGI Altix with an attached SABrick
say Y or M here, otherwise say N.
source "drivers/tty/serial/Kconfig"
source "drivers/tty/serdev/Kconfig"
config TTY_PRINTK
tristate "TTY driver to output user messages via printk"
depends on EXPERT && TTY
default n
---help---
If you say Y here, the support for writing user messages (i.e.
console messages) via printk is available.
The feature is useful to inline user messages with kernel
messages.
In order to use this feature, you should output user messages
to /dev/ttyprintk or redirect console to this TTY.
If unsure, say N.
config PRINTER
tristate "Parallel printer support"
depends on PARPORT
---help---
If you intend to attach a printer to the parallel port of your Linux
box (as opposed to using a serial printer; if the connector at the
printer has 9 or 25 holes ["female"], then it's serial), say Y.
Also read the Printing-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
It is possible to share one parallel port among several devices
(e.g. printer and ZIP drive) and it is safe to compile the
corresponding drivers into the kernel.
To compile this driver as a module, choose M here and read
<file:Documentation/admin-guide/parport.rst>. The module will be called lp.
If you have several parallel ports, you can specify which ports to
use with the "lp" kernel command line option. (Try "man bootparam"
or see the documentation of your boot loader (lilo or loadlin) about
how to pass options to the kernel at boot time.) The syntax of the
"lp" command line option can be found in <file:drivers/char/lp.c>.
If you have more than 8 printers, you need to increase the LP_NO
macro in lp.c and the PARPORT_MAX macro in parport.h.
config LP_CONSOLE
bool "Support for console on line printer"
depends on PRINTER
---help---
If you want kernel messages to be printed out as they occur, you
can have a console on the printer. This option adds support for
doing that; to actually get it to happen you need to pass the
option "console=lp0" to the kernel at boot time.
If the printer is out of paper (or off, or unplugged, or too
busy..) the kernel will stall until the printer is ready again.
By defining CONSOLE_LP_STRICT to 0 (at your own risk) you
can make the kernel continue when this happens,
but it'll lose the kernel messages.
If unsure, say N.
config PPDEV
tristate "Support for user-space parallel port device drivers"
depends on PARPORT
---help---
Saying Y to this adds support for /dev/parport device nodes. This
is needed for programs that want portable access to the parallel
port, for instance deviceid (which displays Plug-and-Play device
IDs).
This is the parallel port equivalent of SCSI generic support (sg).
It is safe to say N to this -- it is not needed for normal printing
or parallel port CD-ROM/disk support.
To compile this driver as a module, choose M here: the
module will be called ppdev.
If unsure, say N.
source "drivers/tty/hvc/Kconfig"
config VIRTIO_CONSOLE
tristate "Virtio console"
depends on VIRTIO && TTY
select HVC_DRIVER
help
Virtio console for use with hypervisors.
Also serves as a general-purpose serial device for data
transfer between the guest and host. Character devices at
/dev/vportNpn will be created when corresponding ports are
found, where N is the device number and n is the port number
within that device. If specified by the host, a sysfs
attribute called 'name' will be populated with a name for
the port which can be used by udev scripts to create a
symlink to the device.
config IBM_BSR
tristate "IBM POWER Barrier Synchronization Register support"
depends on PPC_PSERIES
help
This devices exposes a hardware mechanism for fast synchronization
of threads across a large system which avoids bouncing a cacheline
between several cores on a system
config POWERNV_OP_PANEL
tristate "IBM POWERNV Operator Panel Display support"
depends on PPC_POWERNV
default m
help
If you say Y here, a special character device node, /dev/op_panel,
will be created which exposes the operator panel display on IBM
Power Systems machines with FSPs.
If you don't require access to the operator panel display from user
space, say N.
If unsure, say M here to build it as a module called powernv-op-panel.
source "drivers/char/ipmi/Kconfig"
config DS1620
tristate "NetWinder thermometer support"
depends on ARCH_NETWINDER
help
Say Y here to include support for the thermal management hardware
found in the NetWinder. This driver allows the user to control the
temperature set points and to read the current temperature.
It is also possible to say M here to build it as a module (ds1620)
It is recommended to be used on a NetWinder, but it is not a
necessity.
config NWBUTTON
tristate "NetWinder Button"
depends on ARCH_NETWINDER
---help---
If you say Y here and create a character device node /dev/nwbutton
with major and minor numbers 10 and 158 ("man mknod"), then every
time the orange button is pressed a number of times, the number of
times the button was pressed will be written to that device.
This is most useful for applications, as yet unwritten, which
perform actions based on how many times the button is pressed in a
row.
Do not hold the button down for too long, as the driver does not
alter the behaviour of the hardware reset circuitry attached to the
button; it will still execute a hard reset if the button is held
down for longer than approximately five seconds.
To compile this driver as a module, choose M here: the
module will be called nwbutton.
Most people will answer Y to this question and "Reboot Using Button"
below to be able to initiate a system shutdown from the button.
config NWBUTTON_REBOOT
bool "Reboot Using Button"
depends on NWBUTTON
help
If you say Y here, then you will be able to initiate a system
shutdown and reboot by pressing the orange button a number of times.
The number of presses to initiate the shutdown is two by default,
but this can be altered by modifying the value of NUM_PRESSES_REBOOT
in nwbutton.h and recompiling the driver or, if you compile the
driver as a module, you can specify the number of presses at load
time with "insmod button reboot_count=<something>".
config NWFLASH
tristate "NetWinder flash support"
depends on ARCH_NETWINDER
---help---
If you say Y here and create a character device /dev/flash with
major 10 and minor 160 you can manipulate the flash ROM containing
the NetWinder firmware. Be careful as accidentally overwriting the
flash contents can render your computer unbootable. On no account
allow random users access to this device. :-)
To compile this driver as a module, choose M here: the
module will be called nwflash.
If you're not sure, say N.
source "drivers/char/hw_random/Kconfig"
config NVRAM
tristate "/dev/nvram support"
depends on ATARI || X86 || GENERIC_NVRAM
---help---
If you say Y here and create a character special file /dev/nvram
with major number 10 and minor number 144 using mknod ("man mknod"),
you get read and write access to the extra bytes of non-volatile
memory in the real time clock (RTC), which is contained in every PC
and most Ataris. The actual number of bytes varies, depending on the
nvram in the system, but is usually 114 (128-14 for the RTC).
This memory is conventionally called "CMOS RAM" on PCs and "NVRAM"
on Ataris. /dev/nvram may be used to view settings there, or to
change them (with some utility). It could also be used to frequently
save a few bits of very important data that may not be lost over
power-off and for which writing to disk is too insecure. Note
however that most NVRAM space in a PC belongs to the BIOS and you
should NEVER idly tamper with it. See Ralf Brown's interrupt list
for a guide to the use of CMOS bytes by your BIOS.
On Atari machines, /dev/nvram is always configured and does not need
to be selected.
To compile this driver as a module, choose M here: the
module will be called nvram.
#
# These legacy RTC drivers just cause too many conflicts with the generic
# RTC framework ... let's not even try to coexist any more.
#
if RTC_LIB=n
config RTC
tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
depends on ALPHA || (MIPS && MACH_LOONGSON64)
---help---
If you say Y here and create a character special file /dev/rtc with
major number 10 and minor number 135 using mknod ("man mknod"), you
will get access to the real time clock (or hardware clock) built
into your computer.
Every PC has such a clock built in. It can be used to generate
signals from as low as 1Hz up to 8192Hz, and can also be used
as a 24 hour alarm. It reports status information via the file
/proc/driver/rtc and its behaviour is set by various ioctls on
/dev/rtc.
If you run Linux on a multiprocessor machine and said Y to
"Symmetric Multi Processing" above, you should say Y here to read
and set the RTC in an SMP compatible fashion.
If you think you have a use for such a device (such as periodic data
sampling), then say Y here, and read <file:Documentation/rtc.txt>
for details.
To compile this driver as a module, choose M here: the
module will be called rtc.
config JS_RTC
tristate "Enhanced Real Time Clock Support"
depends on SPARC32 && PCI
---help---
If you say Y here and create a character special file /dev/rtc with
major number 10 and minor number 135 using mknod ("man mknod"), you
will get access to the real time clock (or hardware clock) built
into your computer.
Every PC has such a clock built in. It can be used to generate
signals from as low as 1Hz up to 8192Hz, and can also be used
as a 24 hour alarm. It reports status information via the file
/proc/driver/rtc and its behaviour is set by various ioctls on
/dev/rtc.
If you think you have a use for such a device (such as periodic data
sampling), then say Y here, and read <file:Documentation/rtc.txt>
for details.
To compile this driver as a module, choose M here: the
module will be called js-rtc.
config EFI_RTC
bool "EFI Real Time Clock Services"
depends on IA64
endif # RTC_LIB
config DTLK
tristate "Double Talk PC internal speech card support"
depends on ISA
help
This driver is for the DoubleTalk PC, a speech synthesizer
manufactured by RC Systems (<http://www.rcsys.com/>). It is also
called the `internal DoubleTalk'.
To compile this driver as a module, choose M here: the
module will be called dtlk.
config XILINX_HWICAP
tristate "Xilinx HWICAP Support"
depends on XILINX_VIRTEX || MICROBLAZE
help
This option enables support for Xilinx Internal Configuration
Access Port (ICAP) driver. The ICAP is used on Xilinx Virtex
FPGA platforms to partially reconfigure the FPGA at runtime.
If unsure, say N.
config R3964
tristate "Siemens R3964 line discipline"
depends on TTY && BROKEN
---help---
This driver allows synchronous communication with devices using the
Siemens R3964 packet protocol. Unless you are dealing with special
hardware like PLCs, you are unlikely to need this.
To compile this driver as a module, choose M here: the
module will be called n_r3964.
If unsure, say N.
config APPLICOM
tristate "Applicom intelligent fieldbus card support"
depends on PCI
---help---
This driver provides the kernel-side support for the intelligent
fieldbus cards made by Applicom International. More information
about these cards can be found on the WWW at the address
<http://www.applicom-int.com/>, or by email from David Woodhouse
<dwmw2@infradead.org>.
To compile this driver as a module, choose M here: the
module will be called applicom.
If unsure, say N.
config SONYPI
tristate "Sony Vaio Programmable I/O Control Device support"
depends on X86_32 && PCI && INPUT
---help---
This driver enables access to the Sony Programmable I/O Control
Device which can be found in many (all ?) Sony Vaio laptops.
If you have one of those laptops, read
<file:Documentation/laptops/sonypi.txt>, and say Y or M here.
To compile this driver as a module, choose M here: the
module will be called sonypi.
config GPIO_TB0219
tristate "TANBAC TB0219 GPIO support"
depends on TANBAC_TB022X
select GPIO_VR41XX
source "drivers/char/pcmcia/Kconfig"
config MWAVE
tristate "ACP Modem (Mwave) support"
depends on X86 && TTY
select SERIAL_8250
---help---
The ACP modem (Mwave) for Linux is a WinModem. It is composed of a
kernel driver and a user level application. Together these components
support direct attachment to public switched telephone networks (PSTNs)
and support selected world wide countries.
This version of the ACP Modem driver supports the IBM Thinkpad 600E,
600, and 770 that include on board ACP modem hardware.
The modem also supports the standard communications port interface
(ttySx) and is compatible with the Hayes AT Command Set.
The user level application needed to use this driver can be found at
the IBM Linux Technology Center (LTC) web site:
<http://www.ibm.com/linux/ltc/>.
If you own one of the above IBM Thinkpads which has the Mwave chipset
in it, say Y.
To compile this driver as a module, choose M here: the
module will be called mwave.
config SCx200_GPIO
tristate "NatSemi SCx200 GPIO Support"
depends on SCx200
select NSC_GPIO
help
Give userspace access to the GPIO pins on the National
Semiconductor SCx200 processors.
If compiled as a module, it will be called scx200_gpio.
config PC8736x_GPIO
tristate "NatSemi PC8736x GPIO Support"
depends on X86_32 && !UML
default SCx200_GPIO # mostly N
select NSC_GPIO # needed for support routines
help
Give userspace access to the GPIO pins on the National
Semiconductor PC-8736x (x=[03456]) SuperIO chip. The chip
has multiple functional units, inc several managed by
hwmon/pc87360 driver. Tested with PC-87366
If compiled as a module, it will be called pc8736x_gpio.
config NSC_GPIO
tristate "NatSemi Base GPIO Support"
depends on X86_32
# selected by SCx200_GPIO and PC8736x_GPIO
# what about 2 selectors differing: m != y
help
Common support used (and needed) by scx200_gpio and
pc8736x_gpio drivers. If those drivers are built as
modules, this one will be too, named nsc_gpio
config RAW_DRIVER
tristate "RAW driver (/dev/raw/rawN)"
depends on BLOCK
help
The raw driver permits block devices to be bound to /dev/raw/rawN.
Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
See the raw(8) manpage for more details.
Applications should preferably open the device (eg /dev/hda1)
with the O_DIRECT flag.
config MAX_RAW_DEVS
int "Maximum number of RAW devices to support (1-65536)"
depends on RAW_DRIVER
range 1 65536
default "256"
help
The maximum number of RAW devices that are supported.
Default is 256. Increase this number in case you need lots of
raw devices.
config HPET
bool "HPET - High Precision Event Timer" if (X86 || IA64)
default n
depends on ACPI
help
If you say Y here, you will have a miscdevice named "/dev/hpet/". Each
open selects one of the timers supported by the HPET. The timers are
non-periodic and/or periodic.
config HPET_MMAP
bool "Allow mmap of HPET"
default y
depends on HPET
help
If you say Y here, user applications will be able to mmap
the HPET registers.
config HPET_MMAP_DEFAULT
bool "Enable HPET MMAP access by default"
default y
depends on HPET_MMAP
help
In some hardware implementations, the page containing HPET
registers may also contain other things that shouldn't be
exposed to the user. This option selects the default (if
kernel parameter hpet_mmap is not set) user access to the
registers for applications that require it.
config HANGCHECK_TIMER
tristate "Hangcheck timer"
depends on X86 || IA64 || PPC64 || S390
help
The hangcheck-timer module detects when the system has gone
out to lunch past a certain margin. It can reboot the system
or merely print a warning.
config UV_MMTIMER
tristate "UV_MMTIMER Memory mapped RTC for SGI UV"
depends on X86_UV
default m
help
The uv_mmtimer device allows direct userspace access to the
UV system timer.
source "drivers/char/tpm/Kconfig"
config TELCLOCK
tristate "Telecom clock driver for ATCA SBC"
depends on X86
default n
help
The telecom clock device is specific to the MPCBL0010 and MPCBL0050
ATCA computers and allows direct userspace access to the
configuration of the telecom clock configuration settings. This
device is used for hardware synchronization across the ATCA backplane
fabric. Upon loading, the driver exports a sysfs directory,
/sys/devices/platform/telco_clock, with a number of files for
controlling the behavior of this hardware.
config DEVPORT
bool "/dev/port character device"
depends on ISA || PCI
default y
help
Say Y here if you want to support the /dev/port device. The /dev/port
device is similar to /dev/mem, but for I/O ports.
source "drivers/s390/char/Kconfig"
config MSM_SMD_PKT
bool "Enable device interface for some SMD packet ports"
default n
depends on RPMSG_QCOM_SMD
help
smd_pkt driver provides the interface for the userspace clients
to communicate over smd via device nodes. This enable the
usersapce clients to read and write to some smd packets channel
for MSM chipset.
config TILE_SROM
tristate "Character-device access via hypervisor to the Tilera SPI ROM"
depends on TILE
default y
help
This device provides character-level read-write access
to the SROM, typically via the "0", "1", and "2" devices
in /dev/srom/. The Tilera hypervisor makes the flash
device appear much like a simple EEPROM, and knows
how to partition a single ROM for multiple purposes.
source "drivers/char/xillybus/Kconfig"
source "drivers/char/diag/Kconfig"
config MSM_FASTCVPD
bool "QTI FASTCVP driver"
depends on QCOM_GLINK
help
This driver exposes APIs (Application Program Interface) to video driver
to share HFI command queue address to CDSP (Compute Digital Signal
Processor) and handle errors to exit gracefully in case video and cdsp
subsystems crash.
config MSM_ADSPRPC
tristate "QTI FastRPC driver"
depends on QCOM_GLINK
help
Provides a communication mechanism that allows clients to
make remote method invocations across processor boundary to
applications/compute DSP processor.
Say M if you want to enable this module.
config ADSPRPC_DEBUG
bool "Debug logs in FastRPC driver"
help
Enable debug logs in the fastrpc driver. Flag will be
disabled by default to maximize RPC performance as debug
logging will impact RPC overhead.
Say Y here if you want to enable the logs.
config MSM_RDBG
tristate "QTI Remote debug driver"
help
Implements a shared memory based transport mechanism that allows
for a debugger running on a host PC to communicate with a remote
stub running on peripheral subsystems such as the ADSP, MODEM etc.
Say M if you want to enable this module.
config ADI
tristate "SPARC Privileged ADI driver"
depends on SPARC64
default m
help
SPARC M7 and newer processors utilize ADI (Application Data
Integrity) to version and protect memory. This driver provides
read/write access to the ADI versions for privileged processes.
This feature is also known as MCD (Memory Corruption Detection)
and SSM (Silicon Secured Memory). Intended consumers of this
driver include crash and makedumpfile.
config RB5_FAN_CONTROLLER
tristate "RB5 fan controller driver support"
help
The driver supports the fan controller on QRB5165 device.
The driver controls fan with PM8150L gpio10. It outputs
high to the pin, which is defined in device-tree as
qcom,pwr-enable-gpio.
config RB5_GPIOS_ENABLE
tristate "Enable RB5 GPIO 140/145,116/117"
help
The driver for enable QRB5165 GPIO 140/145,116/117.
The pins are shared between Kona GPIOs and QCA concurrency
signals, GPIO 60 is default set to low to connect GPIOs
140/145,116/117 to mezzanine connectors.
source "drivers/char/lrng/Kconfig"
config RANDOM_TRUST_CPU
bool "Initialize RNG using CPU RNG instructions"
default y
depends on ARCH_RANDOM
help
Initialize the RNG using random numbers supplied by the CPU's
RNG instructions (e.g. RDRAND), if supported and available. These
random numbers are never used directly, but are rather hashed into
the main input pool, and this happens regardless of whether or not
this option is enabled. Instead, this option controls whether the
they are credited and hence can initialize the RNG. Additionally,
other sources of randomness are always used, regardless of this
setting. Enabling this implies trusting that the CPU can supply high
quality and non-backdoored random numbers.
Say Y here unless you have reason to mistrust your CPU or believe
its RNG facilities may be faulty. This may also be configured at
boot time with "random.trust_cpu=on/off".
config OKL4_PIPE
bool "OKL4 Pipe Driver"
depends on OKL4_GUEST
default n
help
Virtual pipe driver for the OKL4 Microvisor. This driver allows
OKL4 Microvisor pipes to be exposed directly to user level as
character devices.
config VSERVICES_SERIAL
tristate
config VSERVICES_SERIAL_SERVER
tristate "Virtual Services serial server"
depends on VSERVICES_SUPPORT && VSERVICES_SERVER
select VSERVICES_SERIAL
select VSERVICES_PROTOCOL_SERIAL_SERVER
default y
help
Select this option if you want support for server side Virtual
Services serial. A virtual serial service behaves similarly to
a UNIX pseudo terminal (pty), and does not require any physical
serial hardware. Virtual serial devices are typically called
/dev/ttyVS0, /dev/ttyVS1, etc.
config VSERVICES_SERIAL_CLIENT
tristate "Virtual Services serial client"
depends on VSERVICES_SUPPORT && VSERVICES_CLIENT
select VSERVICES_SERIAL
select VSERVICES_PROTOCOL_SERIAL_CLIENT
default y
help
Select this option if you want support for client side Virtual
Services serial. A virtual serial service behaves similarly to
a UNIX pseudo terminal (pty), and does not require any physical
serial hardware. Virtual serial devices are typically called
/dev/ttyVS0, /dev/ttyVS1, etc.
config VSERVICES_VTTY_COUNT
int "Maximum number of Virtual Services serial devices"
depends on VSERVICES_SERIAL
range 0 256
default "8"
help
The maximum number of Virtual Services serial devices to support.
This limit applies to both the client and server.
config RANDOM_TRUST_BOOTLOADER
bool "Initialize RNG using bootloader-supplied seed"
default y
help
Initialize the RNG using a seed supplied by the bootloader or boot
environment (e.g. EFI or a bootloader-generated device tree). This
seed is not used directly, but is rather hashed into the main input
pool, and this happens regardless of whether or not this option is
enabled. Instead, this option controls whether the seed is credited
and hence can initialize the RNG. Additionally, other sources of
randomness are always used, regardless of this setting. Enabling
this implies trusting that the bootloader can supply high quality and
non-backdoored seeds.
Say Y here unless you have reason to mistrust your bootloader or
believe its RNG facilities may be faulty. This may also be configured
at boot time with "random.trust_bootloader=on/off".
endmenu