mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-27 06:34:11 +08:00
78c08247b9
This introduces mtdpstore, which is similar to mtdoops but more powerful. It uses pstore/blk, and aims to store panic and oops logs to a flash partition, where pstore can later read back and present as files in the mounted pstore filesystem. To make mtdpstore work, the "blkdev" of pstore/blk should be set as MTD device name or MTD device number. For more details, see Documentation/admin-guide/pstore-blk.rst This solves a number of issues: - Work duplication: both of pstore and mtdoops do the same job storing panic/oops log. They have very similar logic, registering to kmsg dumper and storing logs to several chunks one by one. - Layer violations: drivers should provides methods instead of polices. MTD should provide read/write/erase operations, and allow a higher level drivers to provide the chunk management, kmsg dump configuration, etc. - Missing features: pstore provides many additional features, including presenting the logs as files, logging dump time and count, and supporting other frontends like pmsg, console, etc. Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com> Link: https://lore.kernel.org/lkml/20200511233229.27745-11-keescook@chromium.org/ Link: https://lore.kernel.org/r/1589266715-4168-1-git-send-email-liaoweixiong@allwinnertech.com Signed-off-by: Kees Cook <keescook@chromium.org>
223 lines
7.6 KiB
Plaintext
223 lines
7.6 KiB
Plaintext
menuconfig MTD
|
|
tristate "Memory Technology Device (MTD) support"
|
|
imply NVMEM
|
|
help
|
|
Memory Technology Devices are flash, RAM and similar chips, often
|
|
used for solid state file systems on embedded devices. This option
|
|
will provide the generic support for MTD drivers to register
|
|
themselves with the kernel and for potential users of MTD devices
|
|
to enumerate the devices which are present and obtain a handle on
|
|
them. It will also allow you to select individual drivers for
|
|
particular hardware and users of MTD devices. If unsure, say N.
|
|
|
|
if MTD
|
|
|
|
config MTD_TESTS
|
|
tristate "MTD tests support (DANGEROUS)"
|
|
depends on m
|
|
help
|
|
This option includes various MTD tests into compilation. The tests
|
|
should normally be compiled as kernel modules. The modules perform
|
|
various checks and verifications when loaded.
|
|
|
|
WARNING: some of the tests will ERASE entire MTD device which they
|
|
test. Do not use these tests unless you really know what you do.
|
|
|
|
menu "Partition parsers"
|
|
source "drivers/mtd/parsers/Kconfig"
|
|
endmenu
|
|
|
|
comment "User Modules And Translation Layers"
|
|
|
|
#
|
|
# MTD block device support is select'ed if needed
|
|
#
|
|
config MTD_BLKDEVS
|
|
tristate
|
|
|
|
config MTD_BLOCK
|
|
tristate "Caching block device access to MTD devices"
|
|
depends on BLOCK
|
|
select MTD_BLKDEVS
|
|
help
|
|
Although most flash chips have an erase size too large to be useful
|
|
as block devices, it is possible to use MTD devices which are based
|
|
on RAM chips in this manner. This block device is a user of MTD
|
|
devices performing that function.
|
|
|
|
At the moment, it is also required for the Journalling Flash File
|
|
System(s) to obtain a handle on the MTD device when it's mounted
|
|
(although JFFS and JFFS2 don't actually use any of the functionality
|
|
of the mtdblock device).
|
|
|
|
Later, it may be extended to perform read/erase/modify/write cycles
|
|
on flash chips to emulate a smaller block size. Needless to say,
|
|
this is very unsafe, but could be useful for file systems which are
|
|
almost never written to.
|
|
|
|
You do not need this option for use with the DiskOnChip devices. For
|
|
those, enable NFTL support (CONFIG_NFTL) instead.
|
|
|
|
config MTD_BLOCK_RO
|
|
tristate "Readonly block device access to MTD devices"
|
|
depends on MTD_BLOCK!=y && BLOCK
|
|
select MTD_BLKDEVS
|
|
help
|
|
This allows you to mount read-only file systems (such as cramfs)
|
|
from an MTD device, without the overhead (and danger) of the caching
|
|
driver.
|
|
|
|
You do not need this option for use with the DiskOnChip devices. For
|
|
those, enable NFTL support (CONFIG_NFTL) instead.
|
|
|
|
config FTL
|
|
tristate "FTL (Flash Translation Layer) support"
|
|
depends on BLOCK
|
|
select MTD_BLKDEVS
|
|
help
|
|
This provides support for the original Flash Translation Layer which
|
|
is part of the PCMCIA specification. It uses a kind of pseudo-
|
|
file system on a flash device to emulate a block device with
|
|
512-byte sectors, on top of which you put a 'normal' file system.
|
|
|
|
You may find that the algorithms used in this code are patented
|
|
unless you live in the Free World where software patents aren't
|
|
legal - in the USA you are only permitted to use this on PCMCIA
|
|
hardware, although under the terms of the GPL you're obviously
|
|
permitted to copy, modify and distribute the code as you wish. Just
|
|
not use it.
|
|
|
|
config NFTL
|
|
tristate "NFTL (NAND Flash Translation Layer) support"
|
|
depends on BLOCK
|
|
select MTD_BLKDEVS
|
|
help
|
|
This provides support for the NAND Flash Translation Layer which is
|
|
used on M-Systems' DiskOnChip devices. It uses a kind of pseudo-
|
|
file system on a flash device to emulate a block device with
|
|
512-byte sectors, on top of which you put a 'normal' file system.
|
|
|
|
You may find that the algorithms used in this code are patented
|
|
unless you live in the Free World where software patents aren't
|
|
legal - in the USA you are only permitted to use this on DiskOnChip
|
|
hardware, although under the terms of the GPL you're obviously
|
|
permitted to copy, modify and distribute the code as you wish. Just
|
|
not use it.
|
|
|
|
config NFTL_RW
|
|
bool "Write support for NFTL"
|
|
depends on NFTL
|
|
help
|
|
Support for writing to the NAND Flash Translation Layer, as used
|
|
on the DiskOnChip.
|
|
|
|
config INFTL
|
|
tristate "INFTL (Inverse NAND Flash Translation Layer) support"
|
|
depends on BLOCK
|
|
select MTD_BLKDEVS
|
|
help
|
|
This provides support for the Inverse NAND Flash Translation
|
|
Layer which is used on M-Systems' newer DiskOnChip devices. It
|
|
uses a kind of pseudo-file system on a flash device to emulate
|
|
a block device with 512-byte sectors, on top of which you put
|
|
a 'normal' file system.
|
|
|
|
You may find that the algorithms used in this code are patented
|
|
unless you live in the Free World where software patents aren't
|
|
legal - in the USA you are only permitted to use this on DiskOnChip
|
|
hardware, although under the terms of the GPL you're obviously
|
|
permitted to copy, modify and distribute the code as you wish. Just
|
|
not use it.
|
|
|
|
config RFD_FTL
|
|
tristate "Resident Flash Disk (Flash Translation Layer) support"
|
|
depends on BLOCK
|
|
select MTD_BLKDEVS
|
|
help
|
|
This provides support for the flash translation layer known
|
|
as the Resident Flash Disk (RFD), as used by the Embedded BIOS
|
|
of General Software. There is a blurb at:
|
|
|
|
http://www.gensw.com/pages/prod/bios/rfd.htm
|
|
|
|
config SSFDC
|
|
tristate "NAND SSFDC (SmartMedia) read only translation layer"
|
|
depends on BLOCK
|
|
select MTD_BLKDEVS
|
|
help
|
|
This enables read only access to SmartMedia formatted NAND
|
|
flash. You can mount it with FAT file system.
|
|
|
|
config SM_FTL
|
|
tristate "SmartMedia/xD new translation layer"
|
|
depends on BLOCK
|
|
select MTD_BLKDEVS
|
|
select MTD_NAND_ECC_SW_HAMMING
|
|
help
|
|
This enables EXPERIMENTAL R/W support for SmartMedia/xD
|
|
FTL (Flash translation layer).
|
|
Write support is only lightly tested, therefore this driver
|
|
isn't recommended to use with valuable data (anyway if you have
|
|
valuable data, do backups regardless of software/hardware you
|
|
use, because you never know what will eat your data...)
|
|
If you only need R/O access, you can use older R/O driver
|
|
(CONFIG_SSFDC)
|
|
|
|
config MTD_OOPS
|
|
tristate "Log panic/oops to an MTD buffer"
|
|
help
|
|
This enables panic and oops messages to be logged to a circular
|
|
buffer in a flash partition where it can be read back at some
|
|
later point.
|
|
|
|
config MTD_PSTORE
|
|
tristate "Log panic/oops to an MTD buffer based on pstore"
|
|
depends on PSTORE_BLK
|
|
help
|
|
This enables panic and oops messages to be logged to a circular
|
|
buffer in a flash partition where it can be read back as files after
|
|
mounting pstore filesystem.
|
|
|
|
If unsure, say N.
|
|
|
|
config MTD_SWAP
|
|
tristate "Swap on MTD device support"
|
|
depends on MTD && SWAP
|
|
select MTD_BLKDEVS
|
|
help
|
|
Provides volatile block device driver on top of mtd partition
|
|
suitable for swapping. The mapping of written blocks is not saved.
|
|
The driver provides wear leveling by storing erase counter into the
|
|
OOB.
|
|
|
|
config MTD_PARTITIONED_MASTER
|
|
bool "Retain master device when partitioned"
|
|
default n
|
|
depends on MTD
|
|
help
|
|
For historical reasons, by default, either a master is present or
|
|
several partitions are present, but not both. The concern was that
|
|
data listed in multiple partitions was dangerous; however, SCSI does
|
|
this and it is frequently useful for applications. This config option
|
|
leaves the master in even if the device is partitioned. It also makes
|
|
the parent of the partition device be the master device, rather than
|
|
what lies behind the master.
|
|
|
|
source "drivers/mtd/chips/Kconfig"
|
|
|
|
source "drivers/mtd/maps/Kconfig"
|
|
|
|
source "drivers/mtd/devices/Kconfig"
|
|
|
|
source "drivers/mtd/nand/Kconfig"
|
|
|
|
source "drivers/mtd/lpddr/Kconfig"
|
|
|
|
source "drivers/mtd/spi-nor/Kconfig"
|
|
|
|
source "drivers/mtd/ubi/Kconfig"
|
|
|
|
source "drivers/mtd/hyperbus/Kconfig"
|
|
|
|
endif # MTD
|