 48476df998
			
		
	
	
	48476df998
	
	
	
		
			
			* misc clean-ups in the MTD command-line partitioning parser (cmdlinepart)
  * add flash locking support for STmicro chips serial flash chips, as well as
    for CFI command set 2 chips.
  * new driver for the ELM error correction HW module found in various TI chips,
    enable the OMAP NAND driver to use the ELM HW error correction
  * added number of new serial flash IDs
  * various fixes and improvements in the gpmi NAND driver
  * bcm47xx NAND driver improvements
  * make the mtdpart module actually removable
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.13 (GNU/Linux)
 
 iEYEABECAAYFAlExEs8ACgkQdwG7hYl686Oa+gCgiBNt+I0MiixDeN+MGuE1uw9s
 i2wAniD9sR2HDy6y5SkbdXK/aPr8ez/p
 =xV1l
 -----END PGP SIGNATURE-----
Merge tag 'for-linus-20130301' of git://git.infradead.org/linux-mtd
Pull MTD update from David Woodhouse:
 "Fairly unexciting MTD merge for 3.9:
   - misc clean-ups in the MTD command-line partitioning parser
     (cmdlinepart)
   - add flash locking support for STmicro chips serial flash chips, as
     well as for CFI command set 2 chips.
   - new driver for the ELM error correction HW module found in various
     TI chips, enable the OMAP NAND driver to use the ELM HW error
     correction
   - added number of new serial flash IDs
   - various fixes and improvements in the gpmi NAND driver
   - bcm47xx NAND driver improvements
   - make the mtdpart module actually removable"
* tag 'for-linus-20130301' of git://git.infradead.org/linux-mtd: (45 commits)
  mtd: map: BUG() in non handled cases
  mtd: bcm47xxnflash: use pr_fmt for module prefix in messages
  mtd: davinci_nand: Use managed resources
  mtd: mtd_torturetest can cause stack overflows
  mtd: physmap_of: Convert device allocation to managed devm_kzalloc()
  mtd: at91: atmel_nand: for PMECC, add code to check the ONFI parameter ECC requirement.
  mtd: atmel_nand: make pmecc-cap, pmecc-sector-size in dts is optional.
  mtd: atmel_nand: avoid to report an error when lookup table offset is 0.
  mtd: bcm47xxsflash: adjust names of bus-specific functions
  mtd: bcm47xxpart: improve probing of nvram partition
  mtd: bcm47xxpart: add support for other erase sizes
  mtd: bcm47xxnflash: register this as normal driver
  mtd: bcm47xxnflash: fix message
  mtd: bcm47xxsflash: register this as normal driver
  mtd: bcm47xxsflash: write number of written bytes
  mtd: gpmi: add sanity check for the ECC
  mtd: gpmi: set the Golois Field bit for mx6q's BCH
  mtd: devices: elm: Removes <xx> literals in elm DT node
  mtd: gpmi: fix a dereferencing freed memory error
  mtd: fix the wrong timeo for panic_nand_wait()
  ...
		
	
			
		
			
				
	
	
		
			338 lines
		
	
	
	
		
			11 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			338 lines
		
	
	
	
		
			11 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
| menuconfig MTD
 | |
| 	tristate "Memory Technology Device (MTD) support"
 | |
| 	depends on GENERIC_IO
 | |
| 	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.
 | |
| 
 | |
| config MTD_REDBOOT_PARTS
 | |
| 	tristate "RedBoot partition table parsing"
 | |
| 	---help---
 | |
| 	  RedBoot is a ROM monitor and bootloader which deals with multiple
 | |
| 	  'images' in flash devices by putting a table one of the erase
 | |
| 	  blocks on the device, similar to a partition table, which gives
 | |
| 	  the offsets, lengths and names of all the images stored in the
 | |
| 	  flash.
 | |
| 
 | |
| 	  If you need code which can detect and parse this table, and register
 | |
| 	  MTD 'partitions' corresponding to each image in the table, enable
 | |
| 	  this option.
 | |
| 
 | |
| 	  You will still need the parsing functions to be called by the driver
 | |
| 	  for your particular device. It won't happen automatically. The
 | |
| 	  SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
 | |
| 	  example.
 | |
| 
 | |
| if MTD_REDBOOT_PARTS
 | |
| 
 | |
| config MTD_REDBOOT_DIRECTORY_BLOCK
 | |
| 	int "Location of RedBoot partition table"
 | |
| 	default "-1"
 | |
| 	---help---
 | |
| 	  This option is the Linux counterpart to the
 | |
| 	  CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK RedBoot compile time
 | |
| 	  option.
 | |
| 
 | |
| 	  The option specifies which Flash sectors holds the RedBoot
 | |
| 	  partition table.  A zero or positive value gives an absolute
 | |
| 	  erase block number. A negative value specifies a number of
 | |
| 	  sectors before the end of the device.
 | |
| 
 | |
| 	  For example "2" means block number 2, "-1" means the last
 | |
| 	  block and "-2" means the penultimate block.
 | |
| 
 | |
| config MTD_REDBOOT_PARTS_UNALLOCATED
 | |
| 	bool "Include unallocated flash regions"
 | |
| 	help
 | |
| 	  If you need to register each unallocated flash region as a MTD
 | |
| 	  'partition', enable this option.
 | |
| 
 | |
| config MTD_REDBOOT_PARTS_READONLY
 | |
| 	bool "Force read-only for RedBoot system images"
 | |
| 	help
 | |
| 	  If you need to force read-only for 'RedBoot', 'RedBoot Config' and
 | |
| 	  'FIS directory' images, enable this option.
 | |
| 
 | |
| endif # MTD_REDBOOT_PARTS
 | |
| 
 | |
| config MTD_CMDLINE_PARTS
 | |
| 	tristate "Command line partition table parsing"
 | |
| 	depends on MTD
 | |
| 	---help---
 | |
| 	  Allow generic configuration of the MTD partition tables via the kernel
 | |
| 	  command line. Multiple flash resources are supported for hardware where
 | |
| 	  different kinds of flash memory are available.
 | |
| 
 | |
| 	  You will still need the parsing functions to be called by the driver
 | |
| 	  for your particular device. It won't happen automatically. The
 | |
| 	  SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
 | |
| 	  example.
 | |
| 
 | |
| 	  The format for the command line is as follows:
 | |
| 
 | |
| 	  mtdparts=<mtddef>[;<mtddef]
 | |
| 	  <mtddef>  := <mtd-id>:<partdef>[,<partdef>]
 | |
| 	  <partdef> := <size>[@offset][<name>][ro]
 | |
| 	  <mtd-id>  := unique id used in mapping driver/device
 | |
| 	  <size>    := standard linux memsize OR "-" to denote all
 | |
| 	  remaining space
 | |
| 	  <name>    := (NAME)
 | |
| 
 | |
| 	  Due to the way Linux handles the command line, no spaces are
 | |
| 	  allowed in the partition definition, including mtd id's and partition
 | |
| 	  names.
 | |
| 
 | |
| 	  Examples:
 | |
| 
 | |
| 	  1 flash resource (mtd-id "sa1100"), with 1 single writable partition:
 | |
| 	  mtdparts=sa1100:-
 | |
| 
 | |
| 	  Same flash, but 2 named partitions, the first one being read-only:
 | |
| 	  mtdparts=sa1100:256k(ARMboot)ro,-(root)
 | |
| 
 | |
| 	  If unsure, say 'N'.
 | |
| 
 | |
| config MTD_AFS_PARTS
 | |
| 	tristate "ARM Firmware Suite partition parsing"
 | |
| 	depends on ARM
 | |
| 	---help---
 | |
| 	  The ARM Firmware Suite allows the user to divide flash devices into
 | |
| 	  multiple 'images'. Each such image has a header containing its name
 | |
| 	  and offset/size etc.
 | |
| 
 | |
| 	  If you need code which can detect and parse these tables, and
 | |
| 	  register MTD 'partitions' corresponding to each image detected,
 | |
| 	  enable this option.
 | |
| 
 | |
| 	  You will still need the parsing functions to be called by the driver
 | |
| 	  for your particular device. It won't happen automatically. The
 | |
| 	  'physmap' map driver (CONFIG_MTD_PHYSMAP) does this, for example.
 | |
| 
 | |
| config MTD_OF_PARTS
 | |
| 	tristate "OpenFirmware partitioning information support"
 | |
| 	default y
 | |
| 	depends on OF
 | |
| 	help
 | |
| 	  This provides a partition parsing function which derives
 | |
| 	  the partition map from the children of the flash node,
 | |
| 	  as described in Documentation/devicetree/booting-without-of.txt.
 | |
| 
 | |
| config MTD_AR7_PARTS
 | |
| 	tristate "TI AR7 partitioning support"
 | |
| 	---help---
 | |
| 	  TI AR7 partitioning support
 | |
| 
 | |
| config MTD_BCM63XX_PARTS
 | |
| 	tristate "BCM63XX CFE partitioning support"
 | |
| 	depends on BCM63XX
 | |
| 	select CRC32
 | |
| 	help
 | |
| 	  This provides partions parsing for BCM63xx devices with CFE
 | |
| 	  bootloaders.
 | |
| 
 | |
| config MTD_BCM47XX_PARTS
 | |
| 	tristate "BCM47XX partitioning support"
 | |
| 	depends on BCM47XX
 | |
| 	help
 | |
| 	  This provides partitions parser for devices based on BCM47xx
 | |
| 	  boards.
 | |
| 
 | |
| comment "User Modules And Translation Layers"
 | |
| 
 | |
| config MTD_CHAR
 | |
| 	tristate "Direct char device access to MTD devices"
 | |
| 	help
 | |
| 	  This provides a character device for each MTD device present in
 | |
| 	  the system, allowing the user to read and write directly to the
 | |
| 	  memory chips, and also use ioctl() to obtain information about
 | |
| 	  the device, or to erase parts of it.
 | |
| 
 | |
| config HAVE_MTD_OTP
 | |
| 	bool
 | |
| 	help
 | |
| 	  Enable access to OTP regions using MTD_CHAR.
 | |
| 
 | |
| config MTD_BLKDEVS
 | |
| 	tristate "Common interface to block layer for MTD 'translation layers'"
 | |
| 	depends on BLOCK
 | |
| 	default n
 | |
| 
 | |
| 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
 | |
| 	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_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.
 | |
| 
 | |
| source "drivers/mtd/chips/Kconfig"
 | |
| 
 | |
| source "drivers/mtd/maps/Kconfig"
 | |
| 
 | |
| source "drivers/mtd/devices/Kconfig"
 | |
| 
 | |
| source "drivers/mtd/nand/Kconfig"
 | |
| 
 | |
| source "drivers/mtd/onenand/Kconfig"
 | |
| 
 | |
| source "drivers/mtd/lpddr/Kconfig"
 | |
| 
 | |
| source "drivers/mtd/ubi/Kconfig"
 | |
| 
 | |
| endif # MTD
 |