summaryrefslogtreecommitdiffstats
path: root/Documentation/ABI/testing/sysfs-class-mtd
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/ABI/testing/sysfs-class-mtd')
-rw-r--r--Documentation/ABI/testing/sysfs-class-mtd176
1 files changed, 0 insertions, 176 deletions
diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd
deleted file mode 100644
index db1ad7e..0000000
--- a/Documentation/ABI/testing/sysfs-class-mtd
+++ /dev/null
@@ -1,176 +0,0 @@
-What: /sys/class/mtd/
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- The mtd/ class subdirectory belongs to the MTD subsystem
- (MTD core).
-
-What: /sys/class/mtd/mtdX/
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- The /sys/class/mtd/mtd{0,1,2,3,...} directories correspond
- to each /dev/mtdX character device. These may represent
- physical/simulated flash devices, partitions on a flash
- device, or concatenated flash devices. They exist regardless
- of whether CONFIG_MTD_CHAR is actually enabled.
-
-What: /sys/class/mtd/mtdXro/
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- These directories provide the corresponding read-only device
- nodes for /sys/class/mtd/mtdX/ . They are only created
- (for the benefit of udev) if CONFIG_MTD_CHAR is enabled.
-
-What: /sys/class/mtd/mtdX/dev
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- Major and minor numbers of the character device corresponding
- to this MTD device (in <major>:<minor> format). This is the
- read-write device so <minor> will be even.
-
-What: /sys/class/mtd/mtdXro/dev
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- Major and minor numbers of the character device corresponding
- to the read-only variant of thie MTD device (in
- <major>:<minor> format). In this case <minor> will be odd.
-
-What: /sys/class/mtd/mtdX/erasesize
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- "Major" erase size for the device. If numeraseregions is
- zero, this is the eraseblock size for the entire device.
- Otherwise, the MEMGETREGIONCOUNT/MEMGETREGIONINFO ioctls
- can be used to determine the actual eraseblock layout.
-
-What: /sys/class/mtd/mtdX/flags
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- A hexadecimal value representing the device flags, ORed
- together:
-
- 0x0400: MTD_WRITEABLE - device is writable
- 0x0800: MTD_BIT_WRITEABLE - single bits can be flipped
- 0x1000: MTD_NO_ERASE - no erase necessary
- 0x2000: MTD_POWERUP_LOCK - always locked after reset
-
-What: /sys/class/mtd/mtdX/name
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- A human-readable ASCII name for the device or partition.
- This will match the name in /proc/mtd .
-
-What: /sys/class/mtd/mtdX/numeraseregions
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- For devices that have variable eraseblock sizes, this
- provides the total number of erase regions. Otherwise,
- it will read back as zero.
-
-What: /sys/class/mtd/mtdX/oobsize
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- Number of OOB bytes per page.
-
-What: /sys/class/mtd/mtdX/size
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- Total size of the device/partition, in bytes.
-
-What: /sys/class/mtd/mtdX/type
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- One of the following ASCII strings, representing the device
- type:
-
- absent, ram, rom, nor, nand, dataflash, ubi, unknown
-
-What: /sys/class/mtd/mtdX/writesize
-Date: April 2009
-KernelVersion: 2.6.29
-Contact: linux-mtd@lists.infradead.org
-Description:
- Minimal writable flash unit size. This will always be
- a positive integer.
-
- In the case of NOR flash it is 1 (even though individual
- bits can be cleared).
-
- In the case of NAND flash it is one NAND page (or a
- half page, or a quarter page).
-
- In the case of ECC NOR, it is the ECC block size.
-
-What: /sys/class/mtd/mtdX/ecc_strength
-Date: April 2012
-KernelVersion: 3.4
-Contact: linux-mtd@lists.infradead.org
-Description:
- Maximum number of bit errors that the device is capable of
- correcting within each region covering an ecc step. This will
- always be a non-negative integer. Note that some devices will
- have multiple ecc steps within each writesize region.
-
- In the case of devices lacking any ECC capability, it is 0.
-
-What: /sys/class/mtd/mtdX/bitflip_threshold
-Date: April 2012
-KernelVersion: 3.4
-Contact: linux-mtd@lists.infradead.org
-Description:
- This allows the user to examine and adjust the criteria by which
- mtd returns -EUCLEAN from mtd_read(). If the maximum number of
- bit errors that were corrected on any single region comprising
- an ecc step (as reported by the driver) equals or exceeds this
- value, -EUCLEAN is returned. Otherwise, absent an error, 0 is
- returned. Higher layers (e.g., UBI) use this return code as an
- indication that an erase block may be degrading and should be
- scrutinized as a candidate for being marked as bad.
-
- The initial value may be specified by the flash device driver.
- If not, then the default value is ecc_strength.
-
- The introduction of this feature brings a subtle change to the
- meaning of the -EUCLEAN return code. Previously, it was
- interpreted to mean simply "one or more bit errors were
- corrected". Its new interpretation can be phrased as "a
- dangerously high number of bit errors were corrected on one or
- more regions comprising an ecc step". The precise definition of
- "dangerously high" can be adjusted by the user with
- bitflip_threshold. Users are discouraged from doing this,
- however, unless they know what they are doing and have intimate
- knowledge of the properties of their device. Broadly speaking,
- bitflip_threshold should be low enough to detect genuine erase
- block degradation, but high enough to avoid the consequences of
- a persistent return value of -EUCLEAN on devices where sticky
- bitflips occur. Note that if bitflip_threshold exceeds
- ecc_strength, -EUCLEAN is never returned by mtd_read().
- Conversely, if bitflip_threshold is zero, -EUCLEAN is always
- returned, absent a hard error.
-
- This is generally applicable only to NAND flash devices with ECC
- capability. It is ignored on devices lacking ECC capability;
- i.e., devices for which ecc_strength is zero.