UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/mtd/devices/Kconfig

225 lines
7.8 KiB
Plaintext
Raw Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
menu "Self-contained MTD device drivers"
depends on MTD!=n
MTD: Relax dependencies CONFIG_GENERIC_IO is just enough for the basic MTD stuff. Signed-off-by: Richard Weinberger <richard@nod.at> Acked-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2012-02-07 08:22:50 +08:00
depends on HAS_IOMEM
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
config MTD_PMC551
tristate "Ramix PMC551 PCI Mezzanine RAM card support"
Use menuconfig objects: MTD Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-04-20 05:21:41 +08:00
depends on PCI
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
---help---
This provides a MTD device driver for the Ramix PMC551 RAM PCI card
from Ramix Inc. <http://www.ramix.com/products/memory/pmc551.html>.
These devices come in memory configurations from 32M - 1G. If you
have one, you probably want to enable this.
If this driver is compiled as a module you get the ability to select
the size of the aperture window pointing into the devices memory.
What this means is that if you have a 1G card, normally the kernel
will use a 1G memory map as its view of the device. As a module,
you can select a 1M window into the memory and the driver will
"slide" the window around the PMC551's memory. This was
particularly useful on the 2.2 kernels on PPC architectures as there
was limited kernel space to deal with.
config MTD_PMC551_BUGFIX
bool "PMC551 256M DRAM Bugfix"
depends on MTD_PMC551
help
Some of Ramix's PMC551 boards with 256M configurations have invalid
column and row mux values. This option will fix them, but will
break other memory configurations. If unsure say N.
config MTD_PMC551_DEBUG
bool "PMC551 Debugging"
depends on MTD_PMC551
help
This option makes the PMC551 more verbose during its operation and
is only really useful if you are developing on this driver or
suspect a possible hardware or driver bug. If unsure say N.
config MTD_MS02NV
tristate "DEC MS02-NV NVRAM module support"
Use menuconfig objects: MTD Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-04-20 05:21:41 +08:00
depends on MACH_DECSTATION
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
help
This is an MTD driver for the DEC's MS02-NV (54-20948-01) battery
backed-up NVRAM module. The module was originally meant as an NFS
accelerator. Say Y here if you have a DECstation 5000/2x0 or a
DECsystem 5900 equipped with such a module.
Re-add module description for ms02-nv to Kconfig In an unrelated MTD commit, a description about the ms02-nv module got removed from Kconfig. While I personally agree with this removal, the module maintainer (Maciej W. Rozycki) would like to see it added back. In the absense of any consistency regarding Kconfig descriptions his wish should be followed. Signed-off-by: Martin Michlmayr <tbm@cyrius.com> Acked-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-03-20 12:40:26 +08:00
If you want to compile this driver as a module ( = code which can be
inserted in and removed from the running kernel whenever you want),
kconfig: fix path to modules.txt in Kconfig help Documentation/modules.txt doesn't exist, but Documentation/kbuild/modules.txt does. Signed-off-by: Alexander E. Patrakov Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-03-16 21:28:43 +08:00
say M here and read <file:Documentation/kbuild/modules.txt>.
trivial: Kconfig: .ko is normally not included in module names .ko is normally not included in Kconfig help, make it consistent. Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-06-05 06:44:53 +08:00
The module will be called ms02-nv.
Re-add module description for ms02-nv to Kconfig In an unrelated MTD commit, a description about the ms02-nv module got removed from Kconfig. While I personally agree with this removal, the module maintainer (Maciej W. Rozycki) would like to see it added back. In the absense of any consistency regarding Kconfig descriptions his wish should be followed. Signed-off-by: Martin Michlmayr <tbm@cyrius.com> Acked-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-03-20 12:40:26 +08:00
[PATCH] spi: mtd dataflash driver This is a conversion of the AT91rm9200 DataFlash MTD driver to use the lightweight SPI framework, and no longer be AT91-specific. It compiles down to less than 3KBytes on ARM. The driver allows board-specific init code to provide platform_data with the relevant MTD partitioning information, and hotplugs. This version has been lightly tested. Its parent at91_dataflash driver has been pretty well banged on, although kernel.org JFFS2 dataflash support was acting broken the last time I tried it. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:22 +08:00
config MTD_DATAFLASH
tristate "Support for AT45xxx DataFlash"
drivers/mtd/devices: remove depends on CONFIG_EXPERIMENTAL The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. CC: David Woodhouse <dwmw2@infradead.org> CC: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com> CC: Robert Jarzmik <robert.jarzmik@free.fr> CC: Fabio Estevam <fabio.estevam@freescale.com> CC: Richard Weinberger <richard@nod.at> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
2012-10-03 02:17:51 +08:00
depends on SPI_MASTER
[PATCH] spi: mtd dataflash driver This is a conversion of the AT91rm9200 DataFlash MTD driver to use the lightweight SPI framework, and no longer be AT91-specific. It compiles down to less than 3KBytes on ARM. The driver allows board-specific init code to provide platform_data with the relevant MTD partitioning information, and hotplugs. This version has been lightly tested. Its parent at91_dataflash driver has been pretty well banged on, although kernel.org JFFS2 dataflash support was acting broken the last time I tried it. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:22 +08:00
help
This enables access to AT45xxx DataFlash chips, using SPI.
Sometimes DataFlash chips are packaged inside MMC-format
cards; at this writing, the MMC stack won't handle those.
[MTD] make dataflash write-verify be optional This adds a WRITE_VERIFY Kconfig option to the DataFlash driver, closely mirroring the similar NAND and ONENAND options, giving an option to disable some code that's currently always enabled. Removing this step probably saves a millisecond or so per page when writing data, which will add up quickly since these pages are small (the largest is 1 KiB). It doesn't seem to add a lot in terms of reliability, and wouldn't detect errors which crop up when transferring data to the on-chip SRAM buffer. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Acked-by: Andrew Victor <linux@maxim.org.za> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-08-07 12:55:14 +08:00
config MTD_DATAFLASH_WRITE_VERIFY
bool "Verify DataFlash page writes"
depends on MTD_DATAFLASH
help
This adds an extra check when data is written to the flash.
It may help if you are verifying chip setup (timings etc) on
your board. There is a rare possibility that even though the
device thinks the write was successful, a bit could have been
flipped accidentally due to device wear or something else.
[MTD] dataflash OTP support Now that we can tell when we have one of the newer DataFlash chips, optionally expose the 128 bytes of OTP memory they provide. Tested on at45db642 revision B and D chips. Switch mtdchar over to a generic HAVE_MTD_OTP flag instead of adding another #ifdef for each type of chip whose driver has OTP support. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Bryan Wu <cooloney@kernel.org> Cc: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-07-31 03:35:05 +08:00
config MTD_DATAFLASH_OTP
bool "DataFlash OTP support (Security Register)"
depends on MTD_DATAFLASH
help
Newer DataFlash chips (revisions C and D) support 128 bytes of
one-time-programmable (OTP) data. The first half may be written
(once) with up to 64 bytes of data, such as a serial number or
other key product data. The second half is programmed with a
unique-to-each-chip bit pattern at the factory.
[PATCH] spi: M25 series SPI flash This was originally a driver for the ST M25P80 SPI flash. It's been updated slightly to handle other M25P series chips. For many of these chips, the specific type could be probed, but for now this just requires static setup with flash_platform_data that lists the chip type (size, format) and any default partitioning to use. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Mike Lavender <mike@steroidmicros.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:27 +08:00
config MTD_M25P80
[MTD] m25p80 handles more chips, uses JEDEC ids and small eraseblocks Update chip ID tables in m25p80 to handle more SPI flash chips, matching datasheets. All of these can use the same core operations and are newer chips that support the JEDEC "read id" instruction: - Atmel AT25 and AT26 (seven chips) - Spansion S25SL (five chips) - SST 25VF (four chips) - ST M25, M45 (five more chips) - Winbond W25X series (seven chips) That JEDEC instruction is now used, either to support a sanity check on the platform data holding board configuration data, or to determine chip type when it's not included in platform data. In fact, boards that don't need a standard partition table may not need that platform data any more. For chips that support 4KiB erase units, use that smaller block size instead of the larger size (usually 64KiB); it's less wasteful. (Tested on W25X80.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-06-25 06:12:35 +08:00
tristate "Support most SPI Flash chips (AT26DF, M25P, W25X, ...)"
mtd: spi-nor: shorten Kconfig naming Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Acked-by: Huang Shijie <b32955@freescale.com>
2014-04-09 11:30:25 +08:00
depends on SPI_MASTER && MTD_SPI_NOR
[PATCH] spi: M25 series SPI flash This was originally a driver for the ST M25P80 SPI flash. It's been updated slightly to handle other M25P series chips. For many of these chips, the specific type could be probed, but for now this just requires static setup with flash_platform_data that lists the chip type (size, format) and any default partitioning to use. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Mike Lavender <mike@steroidmicros.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:27 +08:00
help
[MTD] m25p80 handles more chips, uses JEDEC ids and small eraseblocks Update chip ID tables in m25p80 to handle more SPI flash chips, matching datasheets. All of these can use the same core operations and are newer chips that support the JEDEC "read id" instruction: - Atmel AT25 and AT26 (seven chips) - Spansion S25SL (five chips) - SST 25VF (four chips) - ST M25, M45 (five more chips) - Winbond W25X series (seven chips) That JEDEC instruction is now used, either to support a sanity check on the platform data holding board configuration data, or to determine chip type when it's not included in platform data. In fact, boards that don't need a standard partition table may not need that platform data any more. For chips that support 4KiB erase units, use that smaller block size instead of the larger size (usually 64KiB); it's less wasteful. (Tested on W25X80.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-06-25 06:12:35 +08:00
This enables access to most modern SPI flash chips, used for
program and data storage. Series supported include Atmel AT26DF,
Spansion S25SL, SST 25VF, ST M25P, and Winbond W25X. Other chips
are supported as well. See the driver source for the current list,
or to add other chips.
Note that the original DataFlash chips (AT45 series, not AT26DF),
need an entirely different driver.
Set up your spi devices with the right board-specific platform data,
if you want to specify device partitioning or to use a device which
doesn't support the JEDEC ID instruction.
[PATCH] spi: M25 series SPI flash This was originally a driver for the ST M25P80 SPI flash. It's been updated slightly to handle other M25P series chips. For many of these chips, the specific type could be probed, but for now this just requires static setup with flash_platform_data that lists the chip type (size, format) and any default partitioning to use. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Mike Lavender <mike@steroidmicros.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 05:34:27 +08:00
mtd: ST SPEAr: Add SMI driver for serial NOR flash SPEAr platforms (spear3xx/spear6xx/spear13xx) provide SMI (Serial Memory Interface) controller to access serial NOR flash. SMI provides a simple interface for SPI/serial NOR flashes and has certain inbuilt commands and features to support these flashes easily. It also makes it possible to map an address range in order to directly access (read/write) the SNOR over address bus. This patch intends to provide serial nor driver support for spear platforms which are accessed through SMI. Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com> Signed-off-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-01-12 21:38:57 +08:00
config MTD_SPEAR_SMI
tristate "SPEAR MTD NOR Support through SMI controller"
depends on PLAT_SPEAR
default y
help
This enable SNOR support on SPEAR platforms using SMI controller
mtd: SST25L (non JEDEC) SPI Flash driver Add support for the non JEDEC SST25L SPI Flash devices. [dwmw2: Some cleanups] Signed-off-by: Andre Renaud <andre@bluewatersys.com> Signed-off-by: Ryan Mallon <ryan@bluewatersys.com> Acked-by: Linus Walleij <linus.walleij@stericsson.com> Cc: Anton Vorontsov <avorontsov@ru.mvista.com> Cc: "H Hartley Sweeten" <hartleys@visionengravers.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-09-19 03:51:40 +08:00
config MTD_SST25L
tristate "Support SST25L (non JEDEC) SPI Flash chips"
depends on SPI_MASTER
help
This enables access to the non JEDEC SST25L SPI flash chips, used
for program and data storage.
Set up your spi devices with the right board-specific platform data,
if you want to specify device partitioning.
mtd: basic (read only) driver for BCMA serial flash This registers MTD driver for serial flash platform device. Right now it supports reading only, writing still has to be implemented. Artem: minor amendments. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-09-17 17:50:49 +08:00
config MTD_BCM47XXSFLASH
mtd: update description of MTD_BCM47XXSFLASH symbol For years now we support writing to BCMA SoC serial flash, so don't describe this driver as providing read-only support anymore. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-07-18 18:07:03 +08:00
tristate "Support for serial flash on BCMA bus"
mtd: add arch dependency for MTD_BCM47XXSFLASH symbol We dropped strict MIPS dependency for bcm47xxsflash driver in: commit 5651d6aaf489 ("mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR()") but using ioremap_cache still limits building it to few selected architectures only. A recent commit 57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs") automatically dropped MIPS dependency for MTD_BCM47XXSFLASH which broke building e.g. on powerpc and cris. The bcma change is alright as it doesn't break building bcma code in any way. MTD_BCM47XXSFLASH on the other hand should be limited to archs which need it and can build it (by providing ioremap_cache). Fixes: 57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs") Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Cc: Brian Norris <computersforpeace@gmail.com> Acked-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-07-19 15:08:32 +08:00
depends on BCMA_SFLASH && (MIPS || ARM)
mtd: basic (read only) driver for BCMA serial flash This registers MTD driver for serial flash platform device. Right now it supports reading only, writing still has to be implemented. Artem: minor amendments. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-09-17 17:50:49 +08:00
help
BCMA bus can have various flash memories attached, they are
registered by bcma as platform devices. This enables driver for
mtd: update description of MTD_BCM47XXSFLASH symbol For years now we support writing to BCMA SoC serial flash, so don't describe this driver as providing read-only support anymore. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-07-18 18:07:03 +08:00
serial flash memories.
mtd: basic (read only) driver for BCMA serial flash This registers MTD driver for serial flash platform device. Right now it supports reading only, writing still has to be implemented. Artem: minor amendments. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-09-17 17:50:49 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
config MTD_SLRAM
tristate "Uncached system RAM"
help
If your CPU cannot cache all of the physical memory in your machine,
you can still use it for storage or swap by using this driver to
present it to the system as a Memory Technology Device.
config MTD_PHRAM
tristate "Physical system RAM"
help
This is a re-implementation of the slram driver above.
Use this driver to access physical memory that the kernel proper
doesn't have access to, memory beyond the mem=xxx limit, nvram,
memory on the video card, etc...
config MTD_LART
tristate "28F160xx flash driver for LART"
Use menuconfig objects: MTD Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-04-20 05:21:41 +08:00
depends on SA1100_LART
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
help
This enables the flash driver for LART. Please note that you do
not need any mapping/chip driver for LART. This one does it all
for you, so go disable all of those if you enabled some of them (:
config MTD_MTDRAM
tristate "Test driver using RAM"
help
This enables a test MTD device driver which uses vmalloc() to
provide storage. You probably want to say 'N' unless you're
testing stuff.
config MTDRAM_TOTAL_SIZE
int "MTDRAM device size in KiB"
depends on MTD_MTDRAM
default "4096"
help
This allows you to configure the total size of the MTD device
emulated by the MTDRAM driver. If the MTDRAM driver is built
as a module, it is also possible to specify this as a parameter when
loading the module.
config MTDRAM_ERASE_SIZE
int "MTDRAM erase block size in KiB"
depends on MTD_MTDRAM
default "128"
help
This allows you to configure the size of the erase blocks in the
device emulated by the MTDRAM driver. If the MTDRAM driver is built
as a module, it is also possible to specify this as a parameter when
loading the module.
[PATCH] Remove blkmtd Remove the blkmtd driver. - An alternative exists (block2mtd) that hasn't had bug report for > 1 year. - Most embedded people tend to use ancient kernels with custom patches from mtd cvs and elsewhere, so the 1 year warning period neither helps nor hurts them too much. - It's in the way of klibc. The problems caused by pulling blkmtd support are fairly low, while the problems caused by delaying klibc can be fairly substantial. At best, this would be a severe burden on hpa's time. Signed-off-by: Joern Engel <joern@wohnheim.fh-wedel.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11 13:54:17 +08:00
config MTD_BLOCK2MTD
tristate "MTD using block device"
Use menuconfig objects: MTD Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-04-20 05:21:41 +08:00
depends on BLOCK
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
help
This driver allows a block device to appear as an MTD. It would
generally be used in the following cases:
Using Compact Flash as an MTD, these usually present themselves to
the system as an ATA drive.
Testing MTD users (eg JFFS2) on large media and media that might
be removed during a write (using the floppy drive).
mtd: powernv: Add powernv flash MTD abstraction driver Powerpc powernv platforms allow access to certain system flash devices through a firmwarwe interface. This change adds an mtd driver for these flash devices. Minor updates from Jeremy Kerr and Joel Stanley. Signed-off-by: Cyril Bur <cyrilbur@gmail.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Reviewed-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-06-02 12:26:09 +08:00
config MTD_POWERNV_FLASH
tristate "powernv flash MTD driver"
depends on PPC_POWERNV
help
This provides an MTD device to access flash on powernv OPAL
platforms from Linux. This device abstracts away the
firmware interface for flash access.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
comment "Disk-On-Chip Device Drivers"
mtd: Add DiskOnChip G3 support Add support for DiskOnChip G3 chips. The support is quite limited yet : - no flash writes/erases are implemented - ECC fixes are not implemented - powerdown is not implemented - IPL handling is not yet done On the brighter side, the chip reading does work. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
2011-10-05 21:22:34 +08:00
config MTD_DOCG3
tristate "M-Systems Disk-On-Chip G3"
mtd: docg3: add ECC correction code Credit for discovering the BCH algorith parameters, and bit reversing algorithm is to be give to Mike Dunn and Ivan Djelic. The BCH correction code relied upon the BCH library, where all data and ECC is bit-reversed. The BCH library works correctly when each input byte is bit-reversed, and accordingly ECC output is also bit-reversed. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Reviewed-by: Ivan Djelic <ivan.djelic@parrot.com> Reviewed-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2011-11-19 23:02:55 +08:00
select BCH
select BCH_CONST_PARAMS
mtd: docg3 fix missing bitreverse lib Fix missing dependency which can cause a build error such as: ERROR: "byte_rev_table" [drivers/mtd/devices/docg3.ko] undefined! Reported-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2013-01-15 03:01:37 +08:00
select BITREVERSE
mtd: Add DiskOnChip G3 support Add support for DiskOnChip G3 chips. The support is quite limited yet : - no flash writes/erases are implemented - ECC fixes are not implemented - powerdown is not implemented - IPL handling is not yet done On the brighter side, the chip reading does work. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
2011-10-05 21:22:34 +08:00
---help---
This provides an MTD device driver for the M-Systems DiskOnChip
G3 devices.
The driver provides access to G3 DiskOnChip, distributed by
M-Systems and now Sandisk. The support is very experimental,
and doesn't give access to any write operations.
mtd: st_spi_fsm: Allocate resources and register with MTD framework This is a new driver. It's used to communicate with a special type of optimised Serial Flash Controller called the FSM. The FSM uses a subset of the SPI protocol to communicate with supported NOR-Flash devices. Acked-by Angus Clark <angus.clark@st.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2014-03-20 17:20:33 +08:00
config MTD_ST_SPI_FSM
tristate "ST Microelectronics SPI FSM Serial Flash Controller"
mtd: st_spi_fsm: only build for ARM COMPILE_TEST allows us to build this driver on other arch'es. But not all arch'es have the right I/O accessors -- particularly, x86 is missing readsl() and writesl(). So just restrict this driver to ARCH_STI. It's still buildable for a multiplatform ARM kernel, so it can get decent compile coverage. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Lee Jones <lee.jones@linaro.org>
2014-04-16 16:40:17 +08:00
depends on ARCH_STI
mtd: st_spi_fsm: Allocate resources and register with MTD framework This is a new driver. It's used to communicate with a special type of optimised Serial Flash Controller called the FSM. The FSM uses a subset of the SPI protocol to communicate with supported NOR-Flash devices. Acked-by Angus Clark <angus.clark@st.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2014-03-20 17:20:33 +08:00
help
This provides an MTD device driver for the ST Microelectronics
SPI Fast Sequence Mode (FSM) Serial Flash Controller and support
for a subset of connected Serial Flash devices.
mtd: docg3: add ECC correction code Credit for discovering the BCH algorith parameters, and bit reversing algorithm is to be give to Mike Dunn and Ivan Djelic. The BCH correction code relied upon the BCH library, where all data and ECC is bit-reversed. The BCH library works correctly when each input byte is bit-reversed, and accordingly ECC output is also bit-reversed. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Reviewed-by: Ivan Djelic <ivan.djelic@parrot.com> Reviewed-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2011-11-19 23:02:55 +08:00
if MTD_DOCG3
config BCH_CONST_M
default 14
config BCH_CONST_T
default 4
endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
endmenu