1What:		/sys/class/mtd/
2Date:		April 2009
3KernelVersion:	2.6.29
4Contact:	linux-mtd@lists.infradead.org
5Description:
6		The mtd/ class subdirectory belongs to the MTD subsystem
7		(MTD core).
8
9What:		/sys/class/mtd/mtdX/
10Date:		April 2009
11KernelVersion:	2.6.29
12Contact:	linux-mtd@lists.infradead.org
13Description:
14		The /sys/class/mtd/mtd{0,1,2,3,...} directories correspond
15		to each /dev/mtdX character device.  These may represent
16		physical/simulated flash devices, partitions on a flash
17		device, or concatenated flash devices.  They exist regardless
18		of whether CONFIG_MTD_CHAR is actually enabled.
19
20What:		/sys/class/mtd/mtdXro/
21Date:		April 2009
22KernelVersion:	2.6.29
23Contact:	linux-mtd@lists.infradead.org
24Description:
25		These directories provide the corresponding read-only device
26		nodes for /sys/class/mtd/mtdX/ .  They are only created
27		(for the benefit of udev) if CONFIG_MTD_CHAR is enabled.
28
29What:		/sys/class/mtd/mtdX/dev
30Date:		April 2009
31KernelVersion:	2.6.29
32Contact:	linux-mtd@lists.infradead.org
33Description:
34		Major and minor numbers of the character device corresponding
35		to this MTD device (in <major>:<minor> format).  This is the
36		read-write device so <minor> will be even.
37
38What:		/sys/class/mtd/mtdXro/dev
39Date:		April 2009
40KernelVersion:	2.6.29
41Contact:	linux-mtd@lists.infradead.org
42Description:
43		Major and minor numbers of the character device corresponding
44		to the read-only variant of thie MTD device (in
45		<major>:<minor> format).  In this case <minor> will be odd.
46
47What:		/sys/class/mtd/mtdX/erasesize
48Date:		April 2009
49KernelVersion:	2.6.29
50Contact:	linux-mtd@lists.infradead.org
51Description:
52		"Major" erase size for the device.  If numeraseregions is
53		zero, this is the eraseblock size for the entire device.
54		Otherwise, the MEMGETREGIONCOUNT/MEMGETREGIONINFO ioctls
55		can be used to determine the actual eraseblock layout.
56
57What:		/sys/class/mtd/mtdX/flags
58Date:		April 2009
59KernelVersion:	2.6.29
60Contact:	linux-mtd@lists.infradead.org
61Description:
62		A hexadecimal value representing the device flags, ORed
63		together:
64
65		0x0400: MTD_WRITEABLE - device is writable
66		0x0800: MTD_BIT_WRITEABLE - single bits can be flipped
67		0x1000: MTD_NO_ERASE - no erase necessary
68		0x2000: MTD_POWERUP_LOCK - always locked after reset
69
70What:		/sys/class/mtd/mtdX/name
71Date:		April 2009
72KernelVersion:	2.6.29
73Contact:	linux-mtd@lists.infradead.org
74Description:
75		A human-readable ASCII name for the device or partition.
76		This will match the name in /proc/mtd .
77
78What:		/sys/class/mtd/mtdX/numeraseregions
79Date:		April 2009
80KernelVersion:	2.6.29
81Contact:	linux-mtd@lists.infradead.org
82Description:
83		For devices that have variable eraseblock sizes, this
84		provides the total number of erase regions.  Otherwise,
85		it will read back as zero.
86
87What:		/sys/class/mtd/mtdX/oobsize
88Date:		April 2009
89KernelVersion:	2.6.29
90Contact:	linux-mtd@lists.infradead.org
91Description:
92		Number of OOB bytes per page.
93
94What:		/sys/class/mtd/mtdX/size
95Date:		April 2009
96KernelVersion:	2.6.29
97Contact:	linux-mtd@lists.infradead.org
98Description:
99		Total size of the device/partition, in bytes.
100
101What:		/sys/class/mtd/mtdX/type
102Date:		April 2009
103KernelVersion:	2.6.29
104Contact:	linux-mtd@lists.infradead.org
105Description:
106		One of the following ASCII strings, representing the device
107		type:
108
109		absent, ram, rom, nor, nand, dataflash, ubi, unknown
110
111What:		/sys/class/mtd/mtdX/writesize
112Date:		April 2009
113KernelVersion:	2.6.29
114Contact:	linux-mtd@lists.infradead.org
115Description:
116		Minimal writable flash unit size.  This will always be
117		a positive integer.
118
119		In the case of NOR flash it is 1 (even though individual
120		bits can be cleared).
121
122		In the case of NAND flash it is one NAND page (or a
123		half page, or a quarter page).
124
125		In the case of ECC NOR, it is the ECC block size.
126
127What:		/sys/class/mtd/mtdX/ecc_strength
128Date:		April 2012
129KernelVersion:	3.4
130Contact:	linux-mtd@lists.infradead.org
131Description:
132		Maximum number of bit errors that the device is capable of
133		correcting within each region covering an ecc step.  This will
134		always be a non-negative integer.  Note that some devices will
135		have multiple ecc steps within each writesize region.
136
137		In the case of devices lacking any ECC capability, it is 0.
138
139What:		/sys/class/mtd/mtdX/bitflip_threshold
140Date:		April 2012
141KernelVersion:	3.4
142Contact:	linux-mtd@lists.infradead.org
143Description:
144		This allows the user to examine and adjust the criteria by which
145		mtd returns -EUCLEAN from mtd_read() and mtd_read_oob().  If the
146		maximum number of bit errors that were corrected on any single
147		region comprising an ecc step (as reported by the driver) equals
148		or exceeds this value, -EUCLEAN is returned.  Otherwise, absent
149		an error, 0 is returned.  Higher layers (e.g., UBI) use this
150		return code as an indication that an erase block may be
151		degrading and should be scrutinized as a candidate for being
152		marked as bad.
153
154		The initial value may be specified by the flash device driver.
155		If not, then the default value is ecc_strength.
156
157		The introduction of this feature brings a subtle change to the
158		meaning of the -EUCLEAN return code.  Previously, it was
159		interpreted to mean simply "one or more bit errors were
160		corrected".  Its new interpretation can be phrased as "a
161		dangerously high number of bit errors were corrected on one or
162		more regions comprising an ecc step".  The precise definition of
163		"dangerously high" can be adjusted by the user with
164		bitflip_threshold.  Users are discouraged from doing this,
165		however, unless they know what they are doing and have intimate
166		knowledge of the properties of their device.  Broadly speaking,
167		bitflip_threshold should be low enough to detect genuine erase
168		block degradation, but high enough to avoid the consequences of
169		a persistent return value of -EUCLEAN on devices where sticky
170		bitflips occur.  Note that if bitflip_threshold exceeds
171		ecc_strength, -EUCLEAN is never returned by the read operations.
172		Conversely, if bitflip_threshold is zero, -EUCLEAN is always
173		returned, absent a hard error.
174
175		This is generally applicable only to NAND flash devices with ECC
176		capability.  It is ignored on devices lacking ECC capability;
177		i.e., devices for which ecc_strength is zero.
178