cipso: unsigned buf_len cannot be negative
[linux-2.6/next.git] / drivers / mtd / Kconfig
bloba90d50c2c3e5535343e859c5df1c40c3be7e464a
1 menuconfig MTD
2         tristate "Memory Technology Device (MTD) support"
3         depends on HAS_IOMEM
4         help
5           Memory Technology Devices are flash, RAM and similar chips, often
6           used for solid state file systems on embedded devices. This option
7           will provide the generic support for MTD drivers to register
8           themselves with the kernel and for potential users of MTD devices
9           to enumerate the devices which are present and obtain a handle on
10           them. It will also allow you to select individual drivers for
11           particular hardware and users of MTD devices. If unsure, say N.
13 if MTD
15 config MTD_DEBUG
16         bool "Debugging"
17         help
18           This turns on low-level debugging for the entire MTD sub-system.
19           Normally, you should say 'N'.
21 config MTD_DEBUG_VERBOSE
22         int "Debugging verbosity (0 = quiet, 3 = noisy)"
23         depends on MTD_DEBUG
24         default "0"
25         help
26           Determines the verbosity level of the MTD debugging messages.
28 config MTD_CONCAT
29         tristate "MTD concatenating support"
30         help
31           Support for concatenating several MTD devices into a single
32           (virtual) one. This allows you to have -for example- a JFFS(2)
33           file system spanning multiple physical flash chips. If unsure,
34           say 'Y'.
36 config MTD_PARTITIONS
37         bool "MTD partitioning support"
38         help
39           If you have a device which needs to divide its flash chip(s) up
40           into multiple 'partitions', each of which appears to the user as
41           a separate MTD device, you require this option to be enabled. If
42           unsure, say 'Y'.
44           Note, however, that you don't need this option for the DiskOnChip
45           devices. Partitioning on NFTL 'devices' is a different - that's the
46           'normal' form of partitioning used on a block device.
48 config MTD_REDBOOT_PARTS
49         tristate "RedBoot partition table parsing"
50         depends on MTD_PARTITIONS
51         ---help---
52           RedBoot is a ROM monitor and bootloader which deals with multiple
53           'images' in flash devices by putting a table one of the erase
54           blocks on the device, similar to a partition table, which gives
55           the offsets, lengths and names of all the images stored in the
56           flash.
58           If you need code which can detect and parse this table, and register
59           MTD 'partitions' corresponding to each image in the table, enable
60           this option.
62           You will still need the parsing functions to be called by the driver
63           for your particular device. It won't happen automatically. The
64           SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
65           example.
67 config MTD_REDBOOT_DIRECTORY_BLOCK
68         int "Location of RedBoot partition table"
69         depends on MTD_REDBOOT_PARTS
70         default "-1"
71         ---help---
72           This option is the Linux counterpart to the
73           CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK RedBoot compile time
74           option.
76           The option specifies which Flash sectors holds the RedBoot
77           partition table.  A zero or positive value gives an absolute
78           erase block number. A negative value specifies a number of
79           sectors before the end of the device.
81           For example "2" means block number 2, "-1" means the last
82           block and "-2" means the penultimate block.
84 config MTD_REDBOOT_PARTS_UNALLOCATED
85         bool "Include unallocated flash regions"
86         depends on MTD_REDBOOT_PARTS
87         help
88           If you need to register each unallocated flash region as a MTD
89           'partition', enable this option.
91 config MTD_REDBOOT_PARTS_READONLY
92         bool "Force read-only for RedBoot system images"
93         depends on MTD_REDBOOT_PARTS
94         help
95           If you need to force read-only for 'RedBoot', 'RedBoot Config' and
96           'FIS directory' images, enable this option.
98 config MTD_CMDLINE_PARTS
99         bool "Command line partition table parsing"
100         depends on MTD_PARTITIONS = "y" && MTD = "y"
101         ---help---
102           Allow generic configuration of the MTD partition tables via the kernel
103           command line. Multiple flash resources are supported for hardware where
104           different kinds of flash memory are available.
106           You will still need the parsing functions to be called by the driver
107           for your particular device. It won't happen automatically. The
108           SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
109           example.
111           The format for the command line is as follows:
113           mtdparts=<mtddef>[;<mtddef]
114           <mtddef>  := <mtd-id>:<partdef>[,<partdef>]
115           <partdef> := <size>[@offset][<name>][ro]
116           <mtd-id>  := unique id used in mapping driver/device
117           <size>    := standard linux memsize OR "-" to denote all
118           remaining space
119           <name>    := (NAME)
121           Due to the way Linux handles the command line, no spaces are
122           allowed in the partition definition, including mtd id's and partition
123           names.
125           Examples:
127           1 flash resource (mtd-id "sa1100"), with 1 single writable partition:
128           mtdparts=sa1100:-
130           Same flash, but 2 named partitions, the first one being read-only:
131           mtdparts=sa1100:256k(ARMboot)ro,-(root)
133           If unsure, say 'N'.
135 config MTD_AFS_PARTS
136         tristate "ARM Firmware Suite partition parsing"
137         depends on ARM && MTD_PARTITIONS
138         ---help---
139           The ARM Firmware Suite allows the user to divide flash devices into
140           multiple 'images'. Each such image has a header containing its name
141           and offset/size etc.
143           If you need code which can detect and parse these tables, and
144           register MTD 'partitions' corresponding to each image detected,
145           enable this option.
147           You will still need the parsing functions to be called by the driver
148           for your particular device. It won't happen automatically. The
149           'armflash' map driver (CONFIG_MTD_ARMFLASH) does this, for example.
151 config MTD_OF_PARTS
152         tristate "Flash partition map based on OF description"
153         depends on PPC_OF && MTD_PARTITIONS
154         help
155           This provides a partition parsing function which derives
156           the partition map from the children of the flash node,
157           as described in Documentation/powerpc/booting-without-of.txt.
159 config MTD_AR7_PARTS
160         tristate "TI AR7 partitioning support"
161         depends on MTD_PARTITIONS
162         ---help---
163           TI AR7 partitioning support
165 comment "User Modules And Translation Layers"
167 config MTD_CHAR
168         tristate "Direct char device access to MTD devices"
169         help
170           This provides a character device for each MTD device present in
171           the system, allowing the user to read and write directly to the
172           memory chips, and also use ioctl() to obtain information about
173           the device, or to erase parts of it.
175 config HAVE_MTD_OTP
176         bool
177         help
178           Enable access to OTP regions using MTD_CHAR.
180 config MTD_BLKDEVS
181         tristate "Common interface to block layer for MTD 'translation layers'"
182         depends on BLOCK
183         default n
185 config MTD_BLOCK
186         tristate "Caching block device access to MTD devices"
187         depends on BLOCK
188         select MTD_BLKDEVS
189         ---help---
190           Although most flash chips have an erase size too large to be useful
191           as block devices, it is possible to use MTD devices which are based
192           on RAM chips in this manner. This block device is a user of MTD
193           devices performing that function.
195           At the moment, it is also required for the Journalling Flash File
196           System(s) to obtain a handle on the MTD device when it's mounted
197           (although JFFS and JFFS2 don't actually use any of the functionality
198           of the mtdblock device).
200           Later, it may be extended to perform read/erase/modify/write cycles
201           on flash chips to emulate a smaller block size. Needless to say,
202           this is very unsafe, but could be useful for file systems which are
203           almost never written to.
205           You do not need this option for use with the DiskOnChip devices. For
206           those, enable NFTL support (CONFIG_NFTL) instead.
208 config MTD_BLOCK_RO
209         tristate "Readonly block device access to MTD devices"
210         depends on MTD_BLOCK!=y && BLOCK
211         select MTD_BLKDEVS
212         help
213           This allows you to mount read-only file systems (such as cramfs)
214           from an MTD device, without the overhead (and danger) of the caching
215           driver.
217           You do not need this option for use with the DiskOnChip devices. For
218           those, enable NFTL support (CONFIG_NFTL) instead.
220 config FTL
221         tristate "FTL (Flash Translation Layer) support"
222         depends on BLOCK
223         select MTD_BLKDEVS
224         ---help---
225           This provides support for the original Flash Translation Layer which
226           is part of the PCMCIA specification. It uses a kind of pseudo-
227           file system on a flash device to emulate a block device with
228           512-byte sectors, on top of which you put a 'normal' file system.
230           You may find that the algorithms used in this code are patented
231           unless you live in the Free World where software patents aren't
232           legal - in the USA you are only permitted to use this on PCMCIA
233           hardware, although under the terms of the GPL you're obviously
234           permitted to copy, modify and distribute the code as you wish. Just
235           not use it.
237 config NFTL
238         tristate "NFTL (NAND Flash Translation Layer) support"
239         depends on BLOCK
240         select MTD_BLKDEVS
241         ---help---
242           This provides support for the NAND Flash Translation Layer which is
243           used on M-Systems' DiskOnChip devices. It uses a kind of pseudo-
244           file system on a flash device to emulate a block device with
245           512-byte sectors, on top of which you put a 'normal' file system.
247           You may find that the algorithms used in this code are patented
248           unless you live in the Free World where software patents aren't
249           legal - in the USA you are only permitted to use this on DiskOnChip
250           hardware, although under the terms of the GPL you're obviously
251           permitted to copy, modify and distribute the code as you wish. Just
252           not use it.
254 config NFTL_RW
255         bool "Write support for NFTL"
256         depends on NFTL
257         help
258           Support for writing to the NAND Flash Translation Layer, as used
259           on the DiskOnChip.
261 config INFTL
262         tristate "INFTL (Inverse NAND Flash Translation Layer) support"
263         depends on BLOCK
264         select MTD_BLKDEVS
265         ---help---
266           This provides support for the Inverse NAND Flash Translation
267           Layer which is used on M-Systems' newer DiskOnChip devices. It
268           uses a kind of pseudo-file system on a flash device to emulate
269           a block device with 512-byte sectors, on top of which you put
270           a 'normal' file system.
272           You may find that the algorithms used in this code are patented
273           unless you live in the Free World where software patents aren't
274           legal - in the USA you are only permitted to use this on DiskOnChip
275           hardware, although under the terms of the GPL you're obviously
276           permitted to copy, modify and distribute the code as you wish. Just
277           not use it.
279 config RFD_FTL
280         tristate "Resident Flash Disk (Flash Translation Layer) support"
281         depends on BLOCK
282         select MTD_BLKDEVS
283         ---help---
284           This provides support for the flash translation layer known
285           as the Resident Flash Disk (RFD), as used by the Embedded BIOS
286           of General Software. There is a blurb at:
288                 http://www.gensw.com/pages/prod/bios/rfd.htm
290 config SSFDC
291         tristate "NAND SSFDC (SmartMedia) read only translation layer"
292         depends on BLOCK
293         select MTD_BLKDEVS
294         help
295           This enables read only access to SmartMedia formatted NAND
296           flash. You can mount it with FAT file system.
298 config MTD_OOPS
299         tristate "Log panic/oops to an MTD buffer"
300         depends on MTD
301         help
302           This enables panic and oops messages to be logged to a circular
303           buffer in a flash partition where it can be read back at some
304           later point.
306           To use, add console=ttyMTDx to the kernel command line,
307           where x is the MTD device number to use.
309 source "drivers/mtd/chips/Kconfig"
311 source "drivers/mtd/maps/Kconfig"
313 source "drivers/mtd/devices/Kconfig"
315 source "drivers/mtd/nand/Kconfig"
317 source "drivers/mtd/onenand/Kconfig"
319 source "drivers/mtd/ubi/Kconfig"
321 endif # MTD