2005-04-17 02:20:36 +04:00
#
# Library configuration
#
2009-03-06 19:21:46 +03:00
config BINARY_PRINTF
def_bool n
2005-04-17 02:20:36 +04:00
menu "Library routines"
2009-07-13 14:35:12 +04:00
config RAID6_PQ
tristate
2006-12-08 13:36:25 +03:00
config BITREVERSE
tristate
2014-11-03 05:01:03 +03:00
config HAVE_ARCH_BITREVERSE
2015-02-17 03:00:20 +03:00
bool
2014-11-03 05:01:03 +03:00
default n
depends on BITREVERSE
help
2015-04-16 22:49:07 +03:00
This option enables the use of hardware bit-reversal instructions on
architectures which support such operations.
2014-11-03 05:01:03 +03:00
2009-06-11 17:51:15 +04:00
config RATIONAL
2014-12-20 23:41:11 +03:00
bool
2009-06-11 17:51:15 +04:00
2012-05-25 00:12:28 +04:00
config GENERIC_STRNCPY_FROM_USER
bool
2012-05-26 22:06:38 +04:00
config GENERIC_STRNLEN_USER
bool
2013-06-04 20:46:26 +04:00
config GENERIC_NET_UTILS
bool
2008-04-25 15:12:53 +04:00
config GENERIC_FIND_FIRST_BIT
2008-10-16 09:01:38 +04:00
bool
2008-04-25 15:12:53 +04:00
2012-01-30 02:20:48 +04:00
config NO_GENERIC_PCI_IOPORT_MAP
bool
2011-11-24 22:45:20 +04:00
config GENERIC_PCI_IOMAP
bool
2011-11-24 16:54:28 +04:00
config GENERIC_IOMAP
bool
2011-11-24 22:45:20 +04:00
select GENERIC_PCI_IOMAP
2011-11-24 16:54:28 +04:00
lib: add support for stmp-style devices
MX23/28 use IP cores which follow a register layout I have first seen on
STMP3xxx SoCs. In this layout, every register actually has four u32:
1.) to store a value directly
2.) a SET register where every 1-bit sets the corresponding bit,
others are unaffected
3.) same with a CLR register
4.) same with a TOG (toggle) register
Also, the 2 MSBs in register 0 are always the same and can be used to reset
the IP core.
All this is strictly speaking not mach-specific (but IP core specific) and,
thus, doesn't need to be in mach-mxs/include. At least mx6 also uses IP cores
following this stmp-style. So:
Introduce a stmp-style device, put the code and defines for that in a public
place (lib/), and let drivers for stmp-style devices select that code.
To avoid regressions and ease reviewing, the actual code is simply copied from
mach-mxs. It definately wants updates, but those need a seperate patch series.
Voila, mach dependency gone, reusable code introduced. Note that I didn't
remove the duplicated code from mach-mxs yet, first the drivers have to be
converted.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Dong Aisheng <dong.aisheng@linaro.org>
2011-08-31 22:35:40 +04:00
config STMP_DEVICE
bool
2012-12-18 04:01:39 +04:00
lockref: implement lockless reference count updates using cmpxchg()
Instead of taking the spinlock, the lockless versions atomically check
that the lock is not taken, and do the reference count update using a
cmpxchg() loop. This is semantically identical to doing the reference
count update protected by the lock, but avoids the "wait for lock"
contention that you get when accesses to the reference count are
contended.
Note that a "lockref" is absolutely _not_ equivalent to an atomic_t.
Even when the lockref reference counts are updated atomically with
cmpxchg, the fact that they also verify the state of the spinlock means
that the lockless updates can never happen while somebody else holds the
spinlock.
So while "lockref_put_or_lock()" looks a lot like just another name for
"atomic_dec_and_lock()", and both optimize to lockless updates, they are
fundamentally different: the decrement done by atomic_dec_and_lock() is
truly independent of any lock (as long as it doesn't decrement to zero),
so a locked region can still see the count change.
The lockref structure, in contrast, really is a *locked* reference
count. If you hold the spinlock, the reference count will be stable and
you can modify the reference count without using atomics, because even
the lockless updates will see and respect the state of the lock.
In order to enable the cmpxchg lockless code, the architecture needs to
do three things:
(1) Make sure that the "arch_spinlock_t" and an "unsigned int" can fit
in an aligned u64, and have a "cmpxchg()" implementation that works
on such a u64 data type.
(2) define a helper function to test for a spinlock being unlocked
("arch_spin_value_unlocked()")
(3) select the "ARCH_USE_CMPXCHG_LOCKREF" config variable in its
Kconfig file.
This enables it for x86-64 (but not 32-bit, we'd need to make sure
cmpxchg() turns into the proper cmpxchg8b in order to enable it for
32-bit mode).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-02 23:12:15 +04:00
config ARCH_USE_CMPXCHG_LOCKREF
bool
2014-09-13 22:14:53 +04:00
config ARCH_HAS_FAST_MULTIPLIER
bool
2005-04-17 02:20:36 +04:00
config CRC_CCITT
tristate "CRC-CCITT functions"
help
This option is provided for the case where no in-kernel-tree
modules require CRC-CCITT functions, but a module built outside
the kernel tree does. Such modules that use library CRC-CCITT
functions require M here.
2005-08-17 15:17:26 +04:00
config CRC16
tristate "CRC16 functions"
help
This option is provided for the case where no in-kernel-tree
modules require CRC16 functions, but a module built outside
the kernel tree does. Such modules that use library CRC16
functions require M here.
2008-06-25 19:22:42 +04:00
config CRC_T10DIF
tristate "CRC calculation for the T10 Data Integrity Field"
2013-09-07 06:56:26 +04:00
select CRYPTO
select CRYPTO_CRCT10DIF
2008-06-25 19:22:42 +04:00
help
This option is only needed if a module that's not in the
kernel tree needs to calculate CRC checks for use with the
SCSI data integrity subsystem.
2006-06-12 18:17:04 +04:00
config CRC_ITU_T
tristate "CRC ITU-T V.41 functions"
help
This option is provided for the case where no in-kernel-tree
modules require CRC ITU-T V.41 functions, but a module built outside
the kernel tree does. Such modules that use library CRC ITU-T V.41
functions require M here.
2005-04-17 02:20:36 +04:00
config CRC32
2012-03-24 02:02:25 +04:00
tristate "CRC32/CRC32c functions"
2005-04-17 02:20:36 +04:00
default y
2006-12-08 13:36:25 +03:00
select BITREVERSE
2005-04-17 02:20:36 +04:00
help
This option is provided for the case where no in-kernel-tree
2012-03-24 02:02:25 +04:00
modules require CRC32/CRC32c functions, but a module built outside
the kernel tree does. Such modules that use library CRC32/CRC32c
functions require M here.
2005-04-17 02:20:36 +04:00
2012-03-24 02:02:22 +04:00
config CRC32_SELFTEST
2017-02-25 02:00:49 +03:00
tristate "CRC32 perform self test on init"
2012-03-24 02:02:22 +04:00
depends on CRC32
help
This option enables the CRC32 library functions to perform a
self test on initialization. The self test computes crc32_le
and crc32_be over byte strings with random alignment and length
and computes the total elapsed time and number of bytes processed.
2012-03-24 02:02:26 +04:00
choice
prompt "CRC32 implementation"
depends on CRC32
default CRC32_SLICEBY8
2012-03-29 01:42:56 +04:00
help
This option allows a kernel builder to override the default choice
of CRC32 algorithm. Choose the default ("slice by 8") unless you
know that you need one of the others.
2012-03-24 02:02:26 +04:00
config CRC32_SLICEBY8
bool "Slice by 8 bytes"
help
Calculate checksum 8 bytes at a time with a clever slicing algorithm.
This is the fastest algorithm, but comes with a 8KiB lookup table.
Most modern processors have enough cache to hold this table without
thrashing the cache.
This is the default implementation choice. Choose this one unless
you have a good reason not to.
config CRC32_SLICEBY4
bool "Slice by 4 bytes"
help
Calculate checksum 4 bytes at a time with a clever slicing algorithm.
This is a bit slower than slice by 8, but has a smaller 4KiB lookup
table.
Only choose this option if you know what you are doing.
config CRC32_SARWATE
bool "Sarwate's Algorithm (one byte at a time)"
help
Calculate checksum a byte at a time using Sarwate's algorithm. This
is not particularly fast, but has a small 256 byte lookup table.
Only choose this option if you know what you are doing.
config CRC32_BIT
bool "Classic Algorithm (one bit at a time)"
help
Calculate checksum one bit at a time. This is VERY slow, but has
no lookup table. This is provided as a debugging option.
Only choose this option if you are debugging crc32.
endchoice
2017-06-07 00:08:39 +03:00
config CRC4
tristate "CRC4 functions"
help
This option is provided for the case where no in-kernel-tree
modules require CRC4 functions, but a module built outside
the kernel tree does. Such modules that use library CRC4
functions require M here.
2007-07-17 15:04:03 +04:00
config CRC7
tristate "CRC7 functions"
help
This option is provided for the case where no in-kernel-tree
modules require CRC7 functions, but a module built outside
the kernel tree does. Such modules that use library CRC7
functions require M here.
2005-04-17 02:20:36 +04:00
config LIBCRC32C
tristate "CRC32c (Castagnoli, et al) Cyclic Redundancy-Check"
2008-11-13 17:05:13 +03:00
select CRYPTO
2008-11-07 10:11:47 +03:00
select CRYPTO_CRC32C
2005-04-17 02:20:36 +04:00
help
This option is provided for the case where no in-kernel-tree
modules require CRC32c functions, but a module built outside the
kernel tree does. Such modules that use library CRC32c functions
require M here. See Castagnoli93.
Module will be libcrc32c.
2011-05-31 13:22:15 +04:00
config CRC8
tristate "CRC8 function"
help
This option provides CRC8 function. Drivers may select this
when they need to do cyclic redundancy check according CRC8
algorithm. Module will be called crc8.
lib: Add xxhash module
Adds xxhash kernel module with xxh32 and xxh64 hashes. xxhash is an
extremely fast non-cryptographic hash algorithm for checksumming.
The zstd compression and decompression modules added in the next patch
require xxhash. I extracted it out from zstd since it is useful on its
own. I copied the code from the upstream XXHash source repository and
translated it into kernel style. I ran benchmarks and tests in the kernel
and tests in userland.
I benchmarked xxhash as a special character device. I ran in four modes,
no-op, xxh32, xxh64, and crc32. The no-op mode simply copies the data to
kernel space and ignores it. The xxh32, xxh64, and crc32 modes compute
hashes on the copied data. I also ran it with four different buffer sizes.
The benchmark file is located in the upstream zstd source repository under
`contrib/linux-kernel/xxhash_test.c` [1].
I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
16 GB of RAM, and a SSD. I benchmarked using the file `filesystem.squashfs`
from `ubuntu-16.10-desktop-amd64.iso`, which is 1,536,217,088 B large.
Run the following commands for the benchmark:
modprobe xxhash_test
mknod xxhash_test c 245 0
time cp filesystem.squashfs xxhash_test
The time is reported by the time of the userland `cp`.
The GB/s is computed with
1,536,217,008 B / time(buffer size, hash)
which includes the time to copy from userland.
The Normalized GB/s is computed with
1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).
| Buffer Size (B) | Hash | Time (s) | GB/s | Adjusted GB/s |
|-----------------|-------|----------|------|---------------|
| 1024 | none | 0.408 | 3.77 | - |
| 1024 | xxh32 | 0.649 | 2.37 | 6.37 |
| 1024 | xxh64 | 0.542 | 2.83 | 11.46 |
| 1024 | crc32 | 1.290 | 1.19 | 1.74 |
| 4096 | none | 0.380 | 4.04 | - |
| 4096 | xxh32 | 0.645 | 2.38 | 5.79 |
| 4096 | xxh64 | 0.500 | 3.07 | 12.80 |
| 4096 | crc32 | 1.168 | 1.32 | 1.95 |
| 8192 | none | 0.351 | 4.38 | - |
| 8192 | xxh32 | 0.614 | 2.50 | 5.84 |
| 8192 | xxh64 | 0.464 | 3.31 | 13.60 |
| 8192 | crc32 | 1.163 | 1.32 | 1.89 |
| 16384 | none | 0.346 | 4.43 | - |
| 16384 | xxh32 | 0.590 | 2.60 | 6.30 |
| 16384 | xxh64 | 0.466 | 3.30 | 12.80 |
| 16384 | crc32 | 1.183 | 1.30 | 1.84 |
Tested in userland using the test-suite in the zstd repo under
`contrib/linux-kernel/test/XXHashUserlandTest.cpp` [2] by mocking the
kernel functions. A line in each branch of every function in `xxhash.c`
was commented out to ensure that the test-suite fails. Additionally
tested while testing zstd and with SMHasher [3].
[1] https://phabricator.intern.facebook.com/P57526246
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/XXHashUserlandTest.cpp
[3] https://github.com/aappleby/smhasher
zstd source repository: https://github.com/facebook/zstd
XXHash source repository: https://github.com/cyan4973/xxhash
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
2017-08-04 23:19:17 +03:00
config XXHASH
tristate
2006-09-12 11:04:40 +04:00
config AUDIT_GENERIC
bool
depends on AUDIT && !AUDIT_ARCH
default y
2014-03-15 09:48:00 +04:00
config AUDIT_ARCH_COMPAT_GENERIC
bool
default n
config AUDIT_COMPAT_GENERIC
bool
depends on AUDIT_GENERIC && AUDIT_ARCH_COMPAT_GENERIC && COMPAT
default y
2013-11-11 15:20:37 +04:00
config RANDOM32_SELFTEST
bool "PRNG perform self test on init"
default n
help
This option enables the 32 bit PRNG library functions to perform a
self test on initialization.
2005-04-17 02:20:36 +04:00
#
# compression support is select'ed if needed
#
2015-05-07 20:49:14 +03:00
config 842_COMPRESS
2016-01-14 01:24:02 +03:00
select CRC32
2015-05-07 20:49:14 +03:00
tristate
config 842_DECOMPRESS
2016-01-14 01:24:02 +03:00
select CRC32
2015-05-07 20:49:14 +03:00
tristate
2005-04-17 02:20:36 +04:00
config ZLIB_INFLATE
tristate
config ZLIB_DEFLATE
tristate
2015-10-16 01:28:35 +03:00
select BITREVERSE
2005-04-17 02:20:36 +04:00
2007-07-11 04:22:24 +04:00
config LZO_COMPRESS
tristate
config LZO_DECOMPRESS
tristate
2013-07-09 03:01:49 +04:00
config LZ4_COMPRESS
tristate
config LZ4HC_COMPRESS
tristate
2013-07-09 03:01:46 +04:00
config LZ4_DECOMPRESS
tristate
lib: Add zstd modules
Add zstd compression and decompression kernel modules.
zstd offers a wide varity of compression speed and quality trade-offs.
It can compress at speeds approaching lz4, and quality approaching lzma.
zstd decompressions at speeds more than twice as fast as zlib, and
decompression speed remains roughly the same across all compression levels.
The code was ported from the upstream zstd source repository. The
`linux/zstd.h` header was modified to match linux kernel style.
The cross-platform and allocation code was stripped out. Instead zstd
requires the caller to pass a preallocated workspace. The source files
were clang-formatted [1] to match the Linux Kernel style as much as
possible. Otherwise, the code was unmodified. We would like to avoid
as much further manual modification to the source code as possible, so it
will be easier to keep the kernel zstd up to date.
I benchmarked zstd compression as a special character device. I ran zstd
and zlib compression at several levels, as well as performing no
compression, which measure the time spent copying the data to kernel space.
Data is passed to the compresser 4096 B at a time. The benchmark file is
located in the upstream zstd source repository under
`contrib/linux-kernel/zstd_compress_test.c` [2].
I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
16 GB of RAM, and a SSD. I benchmarked using `silesia.tar` [3], which is
211,988,480 B large. Run the following commands for the benchmark:
sudo modprobe zstd_compress_test
sudo mknod zstd_compress_test c 245 0
sudo cp silesia.tar zstd_compress_test
The time is reported by the time of the userland `cp`.
The MB/s is computed with
1,536,217,008 B / time(buffer size, hash)
which includes the time to copy from userland.
The Adjusted MB/s is computed with
1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).
The memory reported is the amount of memory the compressor requests.
| Method | Size (B) | Time (s) | Ratio | MB/s | Adj MB/s | Mem (MB) |
|----------|----------|----------|-------|---------|----------|----------|
| none | 11988480 | 0.100 | 1 | 2119.88 | - | - |
| zstd -1 | 73645762 | 1.044 | 2.878 | 203.05 | 224.56 | 1.23 |
| zstd -3 | 66988878 | 1.761 | 3.165 | 120.38 | 127.63 | 2.47 |
| zstd -5 | 65001259 | 2.563 | 3.261 | 82.71 | 86.07 | 2.86 |
| zstd -10 | 60165346 | 13.242 | 3.523 | 16.01 | 16.13 | 13.22 |
| zstd -15 | 58009756 | 47.601 | 3.654 | 4.45 | 4.46 | 21.61 |
| zstd -19 | 54014593 | 102.835 | 3.925 | 2.06 | 2.06 | 60.15 |
| zlib -1 | 77260026 | 2.895 | 2.744 | 73.23 | 75.85 | 0.27 |
| zlib -3 | 72972206 | 4.116 | 2.905 | 51.50 | 52.79 | 0.27 |
| zlib -6 | 68190360 | 9.633 | 3.109 | 22.01 | 22.24 | 0.27 |
| zlib -9 | 67613382 | 22.554 | 3.135 | 9.40 | 9.44 | 0.27 |
I benchmarked zstd decompression using the same method on the same machine.
The benchmark file is located in the upstream zstd repo under
`contrib/linux-kernel/zstd_decompress_test.c` [4]. The memory reported is
the amount of memory required to decompress data compressed with the given
compression level. If you know the maximum size of your input, you can
reduce the memory usage of decompression irrespective of the compression
level.
| Method | Time (s) | MB/s | Adjusted MB/s | Memory (MB) |
|----------|----------|---------|---------------|-------------|
| none | 0.025 | 8479.54 | - | - |
| zstd -1 | 0.358 | 592.15 | 636.60 | 0.84 |
| zstd -3 | 0.396 | 535.32 | 571.40 | 1.46 |
| zstd -5 | 0.396 | 535.32 | 571.40 | 1.46 |
| zstd -10 | 0.374 | 566.81 | 607.42 | 2.51 |
| zstd -15 | 0.379 | 559.34 | 598.84 | 4.61 |
| zstd -19 | 0.412 | 514.54 | 547.77 | 8.80 |
| zlib -1 | 0.940 | 225.52 | 231.68 | 0.04 |
| zlib -3 | 0.883 | 240.08 | 247.07 | 0.04 |
| zlib -6 | 0.844 | 251.17 | 258.84 | 0.04 |
| zlib -9 | 0.837 | 253.27 | 287.64 | 0.04 |
Tested in userland using the test-suite in the zstd repo under
`contrib/linux-kernel/test/UserlandTest.cpp` [5] by mocking the kernel
functions. Fuzz tested using libfuzzer [6] with the fuzz harnesses under
`contrib/linux-kernel/test/{RoundTripCrash.c,DecompressCrash.c}` [7] [8]
with ASAN, UBSAN, and MSAN. Additionaly, it was tested while testing the
BtrFS and SquashFS patches coming next.
[1] https://clang.llvm.org/docs/ClangFormat.html
[2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_compress_test.c
[3] http://sun.aei.polsl.pl/~sdeor/index.php?page=silesia
[4] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_decompress_test.c
[5] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/UserlandTest.cpp
[6] http://llvm.org/docs/LibFuzzer.html
[7] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/RoundTripCrash.c
[8] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/DecompressCrash.c
zstd source repository: https://github.com/facebook/zstd
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
2017-08-10 05:35:53 +03:00
config ZSTD_COMPRESS
select XXHASH
tristate
config ZSTD_DECOMPRESS
select XXHASH
tristate
2011-01-13 04:01:22 +03:00
source "lib/xz/Kconfig"
2009-01-06 00:48:31 +03:00
#
# These all provide a common interface (hence the apparent duplication with
# ZLIB_INFLATE; DECOMPRESS_GZIP is just a wrapper.)
#
config DECOMPRESS_GZIP
2009-01-07 11:01:43 +03:00
select ZLIB_INFLATE
2009-01-06 00:48:31 +03:00
tristate
config DECOMPRESS_BZIP2
tristate
config DECOMPRESS_LZMA
tristate
decompressors: add boot-time XZ support
This implements the API defined in <linux/decompress/generic.h> which is
used for kernel, initramfs, and initrd decompression. This patch together
with the first patch is enough for XZ-compressed initramfs and initrd;
XZ-compressed kernel will need arch-specific changes.
The buffering requirements described in decompress_unxz.c are stricter
than with gzip, so the relevant changes should be done to the
arch-specific code when adding support for XZ-compressed kernel.
Similarly, the heap size in arch-specific pre-boot code may need to be
increased (30 KiB is enough).
The XZ decompressor needs memmove(), memeq() (memcmp() == 0), and
memzero() (memset(ptr, 0, size)), which aren't available in all
arch-specific pre-boot environments. I'm including simple versions in
decompress_unxz.c, but a cleaner solution would naturally be nicer.
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alain Knaff <alain@knaff.lu>
Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Cc: Phillip Lougher <phillip@lougher.demon.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-01-13 04:01:23 +03:00
config DECOMPRESS_XZ
select XZ_DEC
tristate
2010-01-09 01:42:46 +03:00
config DECOMPRESS_LZO
select LZO_DECOMPRESS
tristate
2013-07-09 03:01:46 +04:00
config DECOMPRESS_LZ4
select LZ4_DECOMPRESS
tristate
2005-06-22 04:15:02 +04:00
#
# Generic allocator support is selected if needed
#
config GENERIC_ALLOCATOR
2014-12-20 23:41:11 +03:00
bool
2005-06-22 04:15:02 +04:00
2005-04-17 02:20:36 +04:00
#
# reed solomon support is select'ed if needed
#
config REED_SOLOMON
tristate
config REED_SOLOMON_ENC8
2014-12-20 23:41:11 +03:00
bool
2005-04-17 02:20:36 +04:00
config REED_SOLOMON_DEC8
2014-12-20 23:41:11 +03:00
bool
2005-04-17 02:20:36 +04:00
config REED_SOLOMON_ENC16
2014-12-20 23:41:11 +03:00
bool
2005-04-17 02:20:36 +04:00
config REED_SOLOMON_DEC16
2014-12-20 23:41:11 +03:00
bool
2005-04-17 02:20:36 +04:00
lib: add shared BCH ECC library
This is a new software BCH encoding/decoding library, similar to the shared
Reed-Solomon library.
Binary BCH (Bose-Chaudhuri-Hocquenghem) codes are widely used to correct
errors in NAND flash devices requiring more than 1-bit ecc correction; they
are generally better suited for NAND flash than RS codes because NAND bit
errors do not occur in bursts. Latest SLC NAND devices typically require at
least 4-bit ecc protection per 512 bytes block.
This library provides software encoding/decoding, but may also be used with
ASIC/SoC hardware BCH engines to perform error correction. It is being
currently used for this purpose on an OMAP3630 board (4bit/8bit HW BCH). It
has also been used to decode raw dumps of NAND devices with on-die BCH ecc
engines (e.g. Micron 4bit ecc SLC devices).
Latest NAND devices (including SLC) can exhibit high error rates (typically
a dozen or more bitflips per hour during stress tests); in order to
minimize the performance impact of error correction, this library
implements recently developed algorithms for fast polynomial root finding
(see bch.c header for details) instead of the traditional exhaustive Chien
root search; a few performance figures are provided below:
Platform: arm926ejs @ 468 MHz, 32 KiB icache, 16 KiB dcache
BCH ecc : 4-bit per 512 bytes
Encoding average throughput: 250 Mbits/s
Error correction time (compared with Chien search):
average worst average (Chien) worst (Chien)
----------------------------------------------------------
1 bit 8.5 µs 11 µs 200 µs 383 µs
2 bit 9.7 µs 12.5 µs 477 µs 728 µs
3 bit 18.1 µs 20.6 µs 758 µs 1010 µs
4 bit 19.5 µs 23 µs 1028 µs 1280 µs
In the above figures, "worst" is meant in terms of error pattern, not in
terms of cache miss / page faults effects (not taken into account here).
The library has been extensively tested on the following platforms: x86,
x86_64, arm926ejs, omap3630, qemu-ppc64, qemu-mips.
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2011-03-11 13:05:32 +03:00
#
# BCH support is selected if needed
#
config BCH
tristate
config BCH_CONST_PARAMS
2014-12-20 23:41:11 +03:00
bool
lib: add shared BCH ECC library
This is a new software BCH encoding/decoding library, similar to the shared
Reed-Solomon library.
Binary BCH (Bose-Chaudhuri-Hocquenghem) codes are widely used to correct
errors in NAND flash devices requiring more than 1-bit ecc correction; they
are generally better suited for NAND flash than RS codes because NAND bit
errors do not occur in bursts. Latest SLC NAND devices typically require at
least 4-bit ecc protection per 512 bytes block.
This library provides software encoding/decoding, but may also be used with
ASIC/SoC hardware BCH engines to perform error correction. It is being
currently used for this purpose on an OMAP3630 board (4bit/8bit HW BCH). It
has also been used to decode raw dumps of NAND devices with on-die BCH ecc
engines (e.g. Micron 4bit ecc SLC devices).
Latest NAND devices (including SLC) can exhibit high error rates (typically
a dozen or more bitflips per hour during stress tests); in order to
minimize the performance impact of error correction, this library
implements recently developed algorithms for fast polynomial root finding
(see bch.c header for details) instead of the traditional exhaustive Chien
root search; a few performance figures are provided below:
Platform: arm926ejs @ 468 MHz, 32 KiB icache, 16 KiB dcache
BCH ecc : 4-bit per 512 bytes
Encoding average throughput: 250 Mbits/s
Error correction time (compared with Chien search):
average worst average (Chien) worst (Chien)
----------------------------------------------------------
1 bit 8.5 µs 11 µs 200 µs 383 µs
2 bit 9.7 µs 12.5 µs 477 µs 728 µs
3 bit 18.1 µs 20.6 µs 758 µs 1010 µs
4 bit 19.5 µs 23 µs 1028 µs 1280 µs
In the above figures, "worst" is meant in terms of error pattern, not in
terms of cache miss / page faults effects (not taken into account here).
The library has been extensively tested on the following platforms: x86,
x86_64, arm926ejs, omap3630, qemu-ppc64, qemu-mips.
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2011-03-11 13:05:32 +03:00
help
Drivers may select this option to force specific constant
values for parameters 'm' (Galois field order) and 't'
(error correction capability). Those specific values must
be set by declaring default values for symbols BCH_CONST_M
and BCH_CONST_T.
Doing so will enable extra compiler optimizations,
improving encoding and decoding performance up to 2x for
usual (m,t) values (typically such that m*t < 200).
When this option is selected, the BCH library supports
only a single (m,t) configuration. This is mainly useful
for NAND flash board drivers requiring known, fixed BCH
parameters.
config BCH_CONST_M
int
range 5 15
help
Constant value for Galois field order 'm'. If 'k' is the
number of data bits to protect, 'm' should be chosen such
that (k + m*t) <= 2**m - 1.
Drivers should declare a default value for this symbol if
they select option BCH_CONST_PARAMS.
config BCH_CONST_T
int
help
Constant value for error correction capability in bits 't'.
Drivers should declare a default value for this symbol if
they select option BCH_CONST_PARAMS.
2005-06-25 04:39:03 +04:00
#
# Textsearch support is select'ed if needed
#
2005-06-24 07:49:30 +04:00
config TEXTSEARCH
2014-12-20 23:41:11 +03:00
bool
2005-04-17 02:20:36 +04:00
[LIB]: Knuth-Morris-Pratt textsearch algorithm
Implements a linear-time string-matching algorithm due to Knuth,
Morris, and Pratt [1]. Their algorithm avoids the explicit
computation of the transition function DELTA altogether. Its
matching time is O(n), for n being length(text), using just an
auxiliary function PI[1..m], for m being length(pattern),
precomputed from the pattern in time O(m). The array PI allows
the transition function DELTA to be computed efficiently
"on the fly" as needed. Roughly speaking, for any state
"q" = 0,1,...,m and any character "a" in SIGMA, the value
PI["q"] contains the information that is independent of "a" and
is needed to compute DELTA("q", "a") [2]. Since the array PI
has only m entries, whereas DELTA has O(m|SIGMA|) entries, we
save a factor of |SIGMA| in the preprocessing time by computing
PI rather than DELTA.
[1] Cormen, Leiserson, Rivest, Stein
Introdcution to Algorithms, 2nd Edition, MIT Press
[2] See finite automation theory
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-24 07:58:37 +04:00
config TEXTSEARCH_KMP
2005-06-25 04:39:03 +04:00
tristate
[LIB]: Knuth-Morris-Pratt textsearch algorithm
Implements a linear-time string-matching algorithm due to Knuth,
Morris, and Pratt [1]. Their algorithm avoids the explicit
computation of the transition function DELTA altogether. Its
matching time is O(n), for n being length(text), using just an
auxiliary function PI[1..m], for m being length(pattern),
precomputed from the pattern in time O(m). The array PI allows
the transition function DELTA to be computed efficiently
"on the fly" as needed. Roughly speaking, for any state
"q" = 0,1,...,m and any character "a" in SIGMA, the value
PI["q"] contains the information that is independent of "a" and
is needed to compute DELTA("q", "a") [2]. Since the array PI
has only m entries, whereas DELTA has O(m|SIGMA|) entries, we
save a factor of |SIGMA| in the preprocessing time by computing
PI rather than DELTA.
[1] Cormen, Leiserson, Rivest, Stein
Introdcution to Algorithms, 2nd Edition, MIT Press
[2] See finite automation theory
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-24 07:58:37 +04:00
2005-08-26 03:12:22 +04:00
config TEXTSEARCH_BM
2005-08-26 03:23:11 +04:00
tristate
2005-08-26 03:12:22 +04:00
2005-06-24 07:59:16 +04:00
config TEXTSEARCH_FSM
2005-06-25 04:39:03 +04:00
tristate
2005-06-24 07:59:16 +04:00
2009-11-20 22:13:39 +03:00
config BTREE
2014-12-20 23:41:11 +03:00
bool
2009-11-20 22:13:39 +03:00
2014-03-17 16:21:54 +04:00
config INTERVAL_TREE
2014-12-20 23:41:11 +03:00
bool
2014-03-17 16:21:54 +04:00
help
Simple, embeddable, interval-tree. Can find the start of an
overlapping range in log(n) time and then iterate over all
overlapping nodes. The algorithm is implemented as an
augmented rbtree.
See:
Documentation/rbtree.txt
for more information.
2016-05-21 03:01:54 +03:00
config RADIX_TREE_MULTIORDER
bool
Add a generic associative array implementation.
Add a generic associative array implementation that can be used as the
container for keyrings, thereby massively increasing the capacity available
whilst also speeding up searching in keyrings that contain a lot of keys.
This may also be useful in FS-Cache for tracking cookies.
Documentation is added into Documentation/associative_array.txt
Some of the properties of the implementation are:
(1) Objects are opaque pointers. The implementation does not care where they
point (if anywhere) or what they point to (if anything).
[!] NOTE: Pointers to objects _must_ be zero in the two least significant
bits.
(2) Objects do not need to contain linkage blocks for use by the array. This
permits an object to be located in multiple arrays simultaneously.
Rather, the array is made up of metadata blocks that point to objects.
(3) Objects are labelled as being one of two types (the type is a bool value).
This information is stored in the array, but has no consequence to the
array itself or its algorithms.
(4) Objects require index keys to locate them within the array.
(5) Index keys must be unique. Inserting an object with the same key as one
already in the array will replace the old object.
(6) Index keys can be of any length and can be of different lengths.
(7) Index keys should encode the length early on, before any variation due to
length is seen.
(8) Index keys can include a hash to scatter objects throughout the array.
(9) The array can iterated over. The objects will not necessarily come out in
key order.
(10) The array can be iterated whilst it is being modified, provided the RCU
readlock is being held by the iterator. Note, however, under these
circumstances, some objects may be seen more than once. If this is a
problem, the iterator should lock against modification. Objects will not
be missed, however, unless deleted.
(11) Objects in the array can be looked up by means of their index key.
(12) Objects can be looked up whilst the array is being modified, provided the
RCU readlock is being held by the thread doing the look up.
The implementation uses a tree of 16-pointer nodes internally that are indexed
on each level by nibbles from the index key. To improve memory efficiency,
shortcuts can be emplaced to skip over what would otherwise be a series of
single-occupancy nodes. Further, nodes pack leaf object pointers into spare
space in the node rather than making an extra branch until as such time an
object needs to be added to a full node.
Signed-off-by: David Howells <dhowells@redhat.com>
2013-09-24 13:35:17 +04:00
config ASSOCIATIVE_ARRAY
bool
help
Generic associative array. Can be searched and iterated over whilst
it is being modified. It is also reasonably quick to search and
modify. The algorithms are non-recursive, and the trees are highly
capacious.
See:
Documentation/assoc_array.txt
for more information.
2007-02-11 18:41:31 +03:00
config HAS_IOMEM
2014-12-20 23:41:11 +03:00
bool
2007-02-11 18:41:31 +03:00
depends on !NO_IOMEM
2012-02-07 04:22:46 +04:00
select GENERIC_IO
2007-02-11 18:41:31 +03:00
default y
2014-04-08 02:39:19 +04:00
config HAS_IOPORT_MAP
2014-12-20 23:41:11 +03:00
bool
2014-04-08 02:39:19 +04:00
depends on HAS_IOMEM && !NO_IOPORT_MAP
2006-12-13 11:35:00 +03:00
default y
2007-05-07 01:49:09 +04:00
config HAS_DMA
2014-12-20 23:41:11 +03:00
bool
2007-05-07 01:49:09 +04:00
depends on !NO_DMA
default y
2018-01-05 19:26:46 +03:00
config SGL_ALLOC
bool
default n
2018-01-09 18:30:23 +03:00
config DMA_DIRECT_OPS
2017-01-21 00:04:06 +03:00
bool
depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
default n
2017-01-21 00:04:07 +03:00
config DMA_VIRT_OPS
bool
depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
default n
2007-08-23 01:01:36 +04:00
config CHECK_SIGNATURE
bool
2008-12-13 13:50:27 +03:00
config CPUMASK_OFFSTACK
bool "Force CPU masks off stack" if DEBUG_PER_CPU_MAPS
help
Use dynamic allocation for cpumask_var_t, instead of putting
them on the stack. This is a bit more expensive, but avoids
stack overflow.
2011-01-19 14:03:25 +03:00
config CPU_RMAP
bool
depends on SMP
dql: Dynamic queue limits
Implementation of dynamic queue limits (dql). This is a libary which
allows a queue limit to be dynamically managed. The goal of dql is
to set the queue limit, number of objects to the queue, to be minimized
without allowing the queue to be starved.
dql would be used with a queue which has these properties:
1) Objects are queued up to some limit which can be expressed as a
count of objects.
2) Periodically a completion process executes which retires consumed
objects.
3) Starvation occurs when limit has been reached, all queued data has
actually been consumed but completion processing has not yet run,
so queuing new data is blocked.
4) Minimizing the amount of queued data is desirable.
A canonical example of such a queue would be a NIC HW transmit queue.
The queue limit is dynamic, it will increase or decrease over time
depending on the workload. The queue limit is recalculated each time
completion processing is done. Increases occur when the queue is
starved and can exponentially increase over successive intervals.
Decreases occur when more data is being maintained in the queue than
needed to prevent starvation. The number of extra objects, or "slack",
is measured over successive intervals, and to avoid hysteresis the
limit is only reduced by the miminum slack seen over a configurable
time period.
dql API provides routines to manage the queue:
- dql_init is called to intialize the dql structure
- dql_reset is called to reset dynamic values
- dql_queued called when objects are being enqueued
- dql_avail returns availability in the queue
- dql_completed is called when objects have be consumed in the queue
Configuration consists of:
- max_limit, maximum limit
- min_limit, minimum limit
- slack_hold_time, time to measure instances of slack before reducing
queue limit
Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-11-28 20:32:35 +04:00
config DQL
bool
2014-08-07 03:09:23 +04:00
config GLOB
bool
# This actually supports modular compilation, but the module overhead
# is ridiculous for the amount of code involved. Until an out-of-tree
# driver asks for it, we'll just link it directly it into the kernel
# when required. Since we're ignoring out-of-tree users, there's also
# no need bother prompting for a manual decision:
# prompt "glob_match() function"
help
This option provides a glob_match function for performing
simple text pattern matching. It originated in the ATA code
to blacklist particular drive models, but other device drivers
may need similar functionality.
All drivers in the Linux kernel tree that require this function
should automatically select this option. Say N unless you
are compiling an out-of tree driver which tells you that it
depends on this.
2014-08-07 03:09:25 +04:00
config GLOB_SELFTEST
2017-02-25 02:00:52 +03:00
tristate "glob self-test on init"
2014-08-07 03:09:25 +04:00
depends on GLOB
help
This option enables a simple self-test of the glob_match
function on startup. It is primarily useful for people
working on the code to ensure they haven't introduced any
regressions.
It only adds a little bit of code and slows kernel boot (or
module load) by a small amount, so you're welcome to play with
it, but you probably don't need it.
2009-03-04 09:53:30 +03:00
#
# Netlink attribute parsing support is select'ed if needed
#
config NLATTR
bool
2009-06-13 01:10:05 +04:00
#
# Generic 64-bit atomic support is selected if needed
#
config GENERIC_ATOMIC64
bool
2009-09-26 03:07:19 +04:00
config LRU_CACHE
tristate
2012-02-02 02:17:54 +04:00
config CLZ_TAB
bool
2011-05-31 13:22:16 +04:00
config CORDIC
2011-07-29 16:59:51 +04:00
tristate "CORDIC algorithm"
2011-05-31 13:22:16 +04:00
help
2011-07-29 17:36:04 +04:00
This option provides an implementation of the CORDIC algorithm;
calculations are in fixed point. Module will be called cordic.
2011-05-31 13:22:16 +04:00
2012-04-27 16:24:03 +04:00
config DDR
bool "JEDEC DDR data"
help
Data from JEDEC specs for DDR SDRAM memories,
particularly the AC timing parameters and addressing
information. This data is useful for drivers handling
DDR SDRAM controllers.
2015-11-10 16:56:14 +03:00
config IRQ_POLL
bool "IRQ polling library"
help
Helper library to poll interrupt mitigation using polling.
2011-08-31 15:05:16 +04:00
config MPILIB
2012-01-17 19:12:06 +04:00
tristate
2012-02-02 02:17:54 +04:00
select CLZ_TAB
2011-08-31 15:05:16 +04:00
help
Multiprecision maths library from GnuPG.
It is used to implement RSA digital signature verification,
which is used by IMA/EVM digital signature extension.
2012-01-17 19:12:03 +04:00
config SIGNATURE
2012-01-17 19:12:06 +04:00
tristate
2014-07-11 19:59:45 +04:00
depends on KEYS
select CRYPTO
2012-01-17 19:12:04 +04:00
select CRYPTO_SHA1
2011-10-14 16:25:16 +04:00
select MPILIB
help
Digital signature verification. Currently only RSA is supported.
Implementation is done using GnuPG MPI library
2012-07-05 20:12:38 +04:00
#
# libfdt files, only selected if needed.
#
config LIBFDT
bool
2012-09-22 02:30:46 +04:00
config OID_REGISTRY
tristate
help
Enable fast lookup object identifier registry.
2013-04-16 00:09:45 +04:00
config UCS2_STRING
tristate
2013-06-09 13:46:43 +04:00
source "lib/fonts/Kconfig"
lib: scatterlist: add sg splitting function
Sometimes a scatter-gather has to be split into several chunks, or sub
scatter lists. This happens for example if a scatter list will be
handled by multiple DMA channels, each one filling a part of it.
A concrete example comes with the media V4L2 API, where the scatter list
is allocated from userspace to hold an image, regardless of the
knowledge of how many DMAs will fill it :
- in a simple RGB565 case, one DMA will pump data from the camera ISP
to memory
- in the trickier YUV422 case, 3 DMAs will pump data from the camera
ISP pipes, one for pipe Y, one for pipe U and one for pipe V
For these cases, it is necessary to split the original scatter list into
multiple scatter lists, which is the purpose of this patch.
The guarantees that are required for this patch are :
- the intersection of spans of any couple of resulting scatter lists is
empty.
- the union of spans of all resulting scatter lists is a subrange of
the span of the original scatter list.
- streaming DMA API operations (mapping, unmapping) should not happen
both on both the resulting and the original scatter list. It's either
the first or the later ones.
- the caller is reponsible to call kfree() on the resulting
scatterlists.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-08 11:44:10 +03:00
config SG_SPLIT
def_bool n
help
2015-09-04 13:45:05 +03:00
Provides a helper to split scatterlists into chunks, each chunk being
a scatterlist. This should be selected by a driver or an API which
whishes to split a scatterlist amongst multiple DMA channels.
lib: scatterlist: add sg splitting function
Sometimes a scatter-gather has to be split into several chunks, or sub
scatter lists. This happens for example if a scatter list will be
handled by multiple DMA channels, each one filling a part of it.
A concrete example comes with the media V4L2 API, where the scatter list
is allocated from userspace to hold an image, regardless of the
knowledge of how many DMAs will fill it :
- in a simple RGB565 case, one DMA will pump data from the camera ISP
to memory
- in the trickier YUV422 case, 3 DMAs will pump data from the camera
ISP pipes, one for pipe Y, one for pipe U and one for pipe V
For these cases, it is necessary to split the original scatter list into
multiple scatter lists, which is the purpose of this patch.
The guarantees that are required for this patch are :
- the intersection of spans of any couple of resulting scatter lists is
empty.
- the union of spans of all resulting scatter lists is a subrange of
the span of the original scatter list.
- streaming DMA API operations (mapping, unmapping) should not happen
both on both the resulting and the original scatter list. It's either
the first or the later ones.
- the caller is reponsible to call kfree() on the resulting
scatterlists.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-08 11:44:10 +03:00
2016-04-05 00:48:11 +03:00
config SG_POOL
def_bool n
help
Provides a helper to allocate chained scatterlists. This should be
selected by a driver or an API which whishes to allocate chained
scatterlist.
2014-08-09 01:23:25 +04:00
#
# sg chaining option
#
config ARCH_HAS_SG_CHAIN
def_bool n
2015-06-25 10:08:39 +03:00
config ARCH_HAS_PMEM_API
bool
2017-05-29 22:22:50 +03:00
config ARCH_HAS_UACCESS_FLUSHCACHE
bool
2016-03-26 00:22:08 +03:00
config STACKDEPOT
bool
select STACKTRACE
2016-09-17 17:38:44 +03:00
config SBITMAP
bool
2017-02-03 12:29:06 +03:00
config PARMAN
2017-02-24 13:25:55 +03:00
tristate "parman" if COMPILE_TEST
2017-02-03 12:29:06 +03:00
2016-12-22 17:45:14 +03:00
config PRIME_NUMBERS
2017-02-24 05:11:21 +03:00
tristate
2016-12-22 17:45:14 +03:00
2017-09-09 02:13:52 +03:00
config STRING_SELFTEST
2017-11-18 02:27:56 +03:00
tristate "Test string functions"
2017-09-09 02:13:52 +03:00
2005-06-24 07:49:30 +04:00
endmenu
2017-05-23 20:28:26 +03:00
config GENERIC_ASHLDI3
bool
config GENERIC_ASHRDI3
bool
config GENERIC_LSHRDI3
bool
config GENERIC_MULDI3
bool
config GENERIC_CMPDI2
bool
config GENERIC_UCMPDI2
bool
