Linux Audio

Check our new training course

Linux BSP development engineering services

Need help to port Linux and bootloaders to your hardware?
Loading...
v3.1
  1menuconfig 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.
 12
 13if MTD
 14
 15config 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'.
 20
 21config 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.
 27
 28config MTD_TESTS
 29	tristate "MTD tests support"
 30	depends on m
 31	help
 32	  This option includes various MTD tests into compilation. The tests
 33	  should normally be compiled as kernel modules. The modules perform
 34	  various checks and verifications when loaded.
 35
 
 
 
 36config MTD_REDBOOT_PARTS
 37	tristate "RedBoot partition table parsing"
 38	---help---
 39	  RedBoot is a ROM monitor and bootloader which deals with multiple
 40	  'images' in flash devices by putting a table one of the erase
 41	  blocks on the device, similar to a partition table, which gives
 42	  the offsets, lengths and names of all the images stored in the
 43	  flash.
 44
 45	  If you need code which can detect and parse this table, and register
 46	  MTD 'partitions' corresponding to each image in the table, enable
 47	  this option.
 48
 49	  You will still need the parsing functions to be called by the driver
 50	  for your particular device. It won't happen automatically. The
 51	  SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
 52	  example.
 53
 54if MTD_REDBOOT_PARTS
 55
 56config MTD_REDBOOT_DIRECTORY_BLOCK
 57	int "Location of RedBoot partition table"
 58	default "-1"
 59	---help---
 60	  This option is the Linux counterpart to the
 61	  CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK RedBoot compile time
 62	  option.
 63
 64	  The option specifies which Flash sectors holds the RedBoot
 65	  partition table.  A zero or positive value gives an absolute
 66	  erase block number. A negative value specifies a number of
 67	  sectors before the end of the device.
 68
 69	  For example "2" means block number 2, "-1" means the last
 70	  block and "-2" means the penultimate block.
 71
 72config MTD_REDBOOT_PARTS_UNALLOCATED
 73	bool "Include unallocated flash regions"
 74	help
 75	  If you need to register each unallocated flash region as a MTD
 76	  'partition', enable this option.
 77
 78config MTD_REDBOOT_PARTS_READONLY
 79	bool "Force read-only for RedBoot system images"
 80	help
 81	  If you need to force read-only for 'RedBoot', 'RedBoot Config' and
 82	  'FIS directory' images, enable this option.
 83
 84endif # MTD_REDBOOT_PARTS
 85
 86config MTD_CMDLINE_PARTS
 87	bool "Command line partition table parsing"
 88	depends on MTD = "y"
 89	---help---
 90	  Allow generic configuration of the MTD partition tables via the kernel
 91	  command line. Multiple flash resources are supported for hardware where
 92	  different kinds of flash memory are available.
 93
 94	  You will still need the parsing functions to be called by the driver
 95	  for your particular device. It won't happen automatically. The
 96	  SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
 97	  example.
 98
 99	  The format for the command line is as follows:
100
101	  mtdparts=<mtddef>[;<mtddef]
102	  <mtddef>  := <mtd-id>:<partdef>[,<partdef>]
103	  <partdef> := <size>[@offset][<name>][ro]
104	  <mtd-id>  := unique id used in mapping driver/device
105	  <size>    := standard linux memsize OR "-" to denote all
106	  remaining space
107	  <name>    := (NAME)
108
109	  Due to the way Linux handles the command line, no spaces are
110	  allowed in the partition definition, including mtd id's and partition
111	  names.
112
113	  Examples:
114
115	  1 flash resource (mtd-id "sa1100"), with 1 single writable partition:
116	  mtdparts=sa1100:-
117
118	  Same flash, but 2 named partitions, the first one being read-only:
119	  mtdparts=sa1100:256k(ARMboot)ro,-(root)
120
121	  If unsure, say 'N'.
122
123config MTD_AFS_PARTS
124	tristate "ARM Firmware Suite partition parsing"
125	depends on ARM
126	---help---
127	  The ARM Firmware Suite allows the user to divide flash devices into
128	  multiple 'images'. Each such image has a header containing its name
129	  and offset/size etc.
130
131	  If you need code which can detect and parse these tables, and
132	  register MTD 'partitions' corresponding to each image detected,
133	  enable this option.
134
135	  You will still need the parsing functions to be called by the driver
136	  for your particular device. It won't happen automatically. The
137	  'physmap' map driver (CONFIG_MTD_PHYSMAP) does this, for example.
138
139config MTD_OF_PARTS
140	def_bool y
 
141	depends on OF
142	help
143	  This provides a partition parsing function which derives
144	  the partition map from the children of the flash node,
145	  as described in Documentation/powerpc/booting-without-of.txt.
146
147config MTD_AR7_PARTS
148	tristate "TI AR7 partitioning support"
149	---help---
150	  TI AR7 partitioning support
151
 
 
 
 
 
 
 
 
152comment "User Modules And Translation Layers"
153
154config MTD_CHAR
155	tristate "Direct char device access to MTD devices"
156	help
157	  This provides a character device for each MTD device present in
158	  the system, allowing the user to read and write directly to the
159	  memory chips, and also use ioctl() to obtain information about
160	  the device, or to erase parts of it.
161
162config HAVE_MTD_OTP
163	bool
164	help
165	  Enable access to OTP regions using MTD_CHAR.
166
167config MTD_BLKDEVS
168	tristate "Common interface to block layer for MTD 'translation layers'"
169	depends on BLOCK
170	default n
171
172config MTD_BLOCK
173	tristate "Caching block device access to MTD devices"
174	depends on BLOCK
175	select MTD_BLKDEVS
176	---help---
177	  Although most flash chips have an erase size too large to be useful
178	  as block devices, it is possible to use MTD devices which are based
179	  on RAM chips in this manner. This block device is a user of MTD
180	  devices performing that function.
181
182	  At the moment, it is also required for the Journalling Flash File
183	  System(s) to obtain a handle on the MTD device when it's mounted
184	  (although JFFS and JFFS2 don't actually use any of the functionality
185	  of the mtdblock device).
186
187	  Later, it may be extended to perform read/erase/modify/write cycles
188	  on flash chips to emulate a smaller block size. Needless to say,
189	  this is very unsafe, but could be useful for file systems which are
190	  almost never written to.
191
192	  You do not need this option for use with the DiskOnChip devices. For
193	  those, enable NFTL support (CONFIG_NFTL) instead.
194
195config MTD_BLOCK_RO
196	tristate "Readonly block device access to MTD devices"
197	depends on MTD_BLOCK!=y && BLOCK
198	select MTD_BLKDEVS
199	help
200	  This allows you to mount read-only file systems (such as cramfs)
201	  from an MTD device, without the overhead (and danger) of the caching
202	  driver.
203
204	  You do not need this option for use with the DiskOnChip devices. For
205	  those, enable NFTL support (CONFIG_NFTL) instead.
206
207config FTL
208	tristate "FTL (Flash Translation Layer) support"
209	depends on BLOCK
210	select MTD_BLKDEVS
211	---help---
212	  This provides support for the original Flash Translation Layer which
213	  is part of the PCMCIA specification. It uses a kind of pseudo-
214	  file system on a flash device to emulate a block device with
215	  512-byte sectors, on top of which you put a 'normal' file system.
216
217	  You may find that the algorithms used in this code are patented
218	  unless you live in the Free World where software patents aren't
219	  legal - in the USA you are only permitted to use this on PCMCIA
220	  hardware, although under the terms of the GPL you're obviously
221	  permitted to copy, modify and distribute the code as you wish. Just
222	  not use it.
223
224config NFTL
225	tristate "NFTL (NAND Flash Translation Layer) support"
226	depends on BLOCK
227	select MTD_BLKDEVS
228	---help---
229	  This provides support for the NAND Flash Translation Layer which is
230	  used on M-Systems' DiskOnChip devices. It uses a kind of pseudo-
231	  file system on a flash device to emulate a block device with
232	  512-byte sectors, on top of which you put a 'normal' file system.
233
234	  You may find that the algorithms used in this code are patented
235	  unless you live in the Free World where software patents aren't
236	  legal - in the USA you are only permitted to use this on DiskOnChip
237	  hardware, although under the terms of the GPL you're obviously
238	  permitted to copy, modify and distribute the code as you wish. Just
239	  not use it.
240
241config NFTL_RW
242	bool "Write support for NFTL"
243	depends on NFTL
244	help
245	  Support for writing to the NAND Flash Translation Layer, as used
246	  on the DiskOnChip.
247
248config INFTL
249	tristate "INFTL (Inverse NAND Flash Translation Layer) support"
250	depends on BLOCK
251	select MTD_BLKDEVS
252	---help---
253	  This provides support for the Inverse NAND Flash Translation
254	  Layer which is used on M-Systems' newer DiskOnChip devices. It
255	  uses a kind of pseudo-file system on a flash device to emulate
256	  a block device with 512-byte sectors, on top of which you put
257	  a 'normal' file system.
258
259	  You may find that the algorithms used in this code are patented
260	  unless you live in the Free World where software patents aren't
261	  legal - in the USA you are only permitted to use this on DiskOnChip
262	  hardware, although under the terms of the GPL you're obviously
263	  permitted to copy, modify and distribute the code as you wish. Just
264	  not use it.
265
266config RFD_FTL
267        tristate "Resident Flash Disk (Flash Translation Layer) support"
268	depends on BLOCK
269	select MTD_BLKDEVS
270	---help---
271	  This provides support for the flash translation layer known
272	  as the Resident Flash Disk (RFD), as used by the Embedded BIOS
273	  of General Software. There is a blurb at:
274
275		http://www.gensw.com/pages/prod/bios/rfd.htm
276
277config SSFDC
278	tristate "NAND SSFDC (SmartMedia) read only translation layer"
279	depends on BLOCK
280	select MTD_BLKDEVS
281	help
282	  This enables read only access to SmartMedia formatted NAND
283	  flash. You can mount it with FAT file system.
284
285
286config SM_FTL
287	tristate "SmartMedia/xD new translation layer"
288	depends on EXPERIMENTAL && BLOCK
289	select MTD_BLKDEVS
290	select MTD_NAND_ECC
291	help
292	  This enables EXPERIMENTAL R/W support for SmartMedia/xD
293	  FTL (Flash translation layer).
294	  Write support is only lightly tested, therefore this driver
295	  isn't recommended to use with valuable data (anyway if you have
296	  valuable data, do backups regardless of software/hardware you
297	  use, because you never know what will eat your data...)
298	  If you only need R/O access, you can use older R/O driver
299	  (CONFIG_SSFDC)
300
301config MTD_OOPS
302	tristate "Log panic/oops to an MTD buffer"
303	help
304	  This enables panic and oops messages to be logged to a circular
305	  buffer in a flash partition where it can be read back at some
306	  later point.
307
308	  To use, add console=ttyMTDx to the kernel command line,
309	  where x is the MTD device number to use.
310
311config MTD_SWAP
312	tristate "Swap on MTD device support"
313	depends on MTD && SWAP
314	select MTD_BLKDEVS
315	help
316	  Provides volatile block device driver on top of mtd partition
317          suitable for swapping.  The mapping of written blocks is not saved.
318	  The driver provides wear leveling by storing erase counter into the
319	  OOB.
320
321source "drivers/mtd/chips/Kconfig"
322
323source "drivers/mtd/maps/Kconfig"
324
325source "drivers/mtd/devices/Kconfig"
326
327source "drivers/mtd/nand/Kconfig"
328
329source "drivers/mtd/onenand/Kconfig"
330
331source "drivers/mtd/lpddr/Kconfig"
332
333source "drivers/mtd/ubi/Kconfig"
334
335endif # MTD
v3.5.6
  1menuconfig MTD
  2	tristate "Memory Technology Device (MTD) support"
  3	depends on GENERIC_IO
  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.
 12
 13if MTD
 14
 
 
 
 
 
 
 
 
 
 
 
 
 
 15config MTD_TESTS
 16	tristate "MTD tests support (DANGEROUS)"
 17	depends on m
 18	help
 19	  This option includes various MTD tests into compilation. The tests
 20	  should normally be compiled as kernel modules. The modules perform
 21	  various checks and verifications when loaded.
 22
 23	  WARNING: some of the tests will ERASE entire MTD device which they
 24	  test. Do not use these tests unless you really know what you do.
 25
 26config MTD_REDBOOT_PARTS
 27	tristate "RedBoot partition table parsing"
 28	---help---
 29	  RedBoot is a ROM monitor and bootloader which deals with multiple
 30	  'images' in flash devices by putting a table one of the erase
 31	  blocks on the device, similar to a partition table, which gives
 32	  the offsets, lengths and names of all the images stored in the
 33	  flash.
 34
 35	  If you need code which can detect and parse this table, and register
 36	  MTD 'partitions' corresponding to each image in the table, enable
 37	  this option.
 38
 39	  You will still need the parsing functions to be called by the driver
 40	  for your particular device. It won't happen automatically. The
 41	  SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
 42	  example.
 43
 44if MTD_REDBOOT_PARTS
 45
 46config MTD_REDBOOT_DIRECTORY_BLOCK
 47	int "Location of RedBoot partition table"
 48	default "-1"
 49	---help---
 50	  This option is the Linux counterpart to the
 51	  CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK RedBoot compile time
 52	  option.
 53
 54	  The option specifies which Flash sectors holds the RedBoot
 55	  partition table.  A zero or positive value gives an absolute
 56	  erase block number. A negative value specifies a number of
 57	  sectors before the end of the device.
 58
 59	  For example "2" means block number 2, "-1" means the last
 60	  block and "-2" means the penultimate block.
 61
 62config MTD_REDBOOT_PARTS_UNALLOCATED
 63	bool "Include unallocated flash regions"
 64	help
 65	  If you need to register each unallocated flash region as a MTD
 66	  'partition', enable this option.
 67
 68config MTD_REDBOOT_PARTS_READONLY
 69	bool "Force read-only for RedBoot system images"
 70	help
 71	  If you need to force read-only for 'RedBoot', 'RedBoot Config' and
 72	  'FIS directory' images, enable this option.
 73
 74endif # MTD_REDBOOT_PARTS
 75
 76config MTD_CMDLINE_PARTS
 77	bool "Command line partition table parsing"
 78	depends on MTD = "y"
 79	---help---
 80	  Allow generic configuration of the MTD partition tables via the kernel
 81	  command line. Multiple flash resources are supported for hardware where
 82	  different kinds of flash memory are available.
 83
 84	  You will still need the parsing functions to be called by the driver
 85	  for your particular device. It won't happen automatically. The
 86	  SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
 87	  example.
 88
 89	  The format for the command line is as follows:
 90
 91	  mtdparts=<mtddef>[;<mtddef]
 92	  <mtddef>  := <mtd-id>:<partdef>[,<partdef>]
 93	  <partdef> := <size>[@offset][<name>][ro]
 94	  <mtd-id>  := unique id used in mapping driver/device
 95	  <size>    := standard linux memsize OR "-" to denote all
 96	  remaining space
 97	  <name>    := (NAME)
 98
 99	  Due to the way Linux handles the command line, no spaces are
100	  allowed in the partition definition, including mtd id's and partition
101	  names.
102
103	  Examples:
104
105	  1 flash resource (mtd-id "sa1100"), with 1 single writable partition:
106	  mtdparts=sa1100:-
107
108	  Same flash, but 2 named partitions, the first one being read-only:
109	  mtdparts=sa1100:256k(ARMboot)ro,-(root)
110
111	  If unsure, say 'N'.
112
113config MTD_AFS_PARTS
114	tristate "ARM Firmware Suite partition parsing"
115	depends on ARM
116	---help---
117	  The ARM Firmware Suite allows the user to divide flash devices into
118	  multiple 'images'. Each such image has a header containing its name
119	  and offset/size etc.
120
121	  If you need code which can detect and parse these tables, and
122	  register MTD 'partitions' corresponding to each image detected,
123	  enable this option.
124
125	  You will still need the parsing functions to be called by the driver
126	  for your particular device. It won't happen automatically. The
127	  'physmap' map driver (CONFIG_MTD_PHYSMAP) does this, for example.
128
129config MTD_OF_PARTS
130	tristate "OpenFirmware partitioning information support"
131	default y
132	depends on OF
133	help
134	  This provides a partition parsing function which derives
135	  the partition map from the children of the flash node,
136	  as described in Documentation/devicetree/booting-without-of.txt.
137
138config MTD_AR7_PARTS
139	tristate "TI AR7 partitioning support"
140	---help---
141	  TI AR7 partitioning support
142
143config MTD_BCM63XX_PARTS
144	tristate "BCM63XX CFE partitioning support"
145	depends on BCM63XX
146	select CRC32
147	help
148	  This provides partions parsing for BCM63xx devices with CFE
149	  bootloaders.
150
151comment "User Modules And Translation Layers"
152
153config MTD_CHAR
154	tristate "Direct char device access to MTD devices"
155	help
156	  This provides a character device for each MTD device present in
157	  the system, allowing the user to read and write directly to the
158	  memory chips, and also use ioctl() to obtain information about
159	  the device, or to erase parts of it.
160
161config HAVE_MTD_OTP
162	bool
163	help
164	  Enable access to OTP regions using MTD_CHAR.
165
166config MTD_BLKDEVS
167	tristate "Common interface to block layer for MTD 'translation layers'"
168	depends on BLOCK
169	default n
170
171config MTD_BLOCK
172	tristate "Caching block device access to MTD devices"
173	depends on BLOCK
174	select MTD_BLKDEVS
175	---help---
176	  Although most flash chips have an erase size too large to be useful
177	  as block devices, it is possible to use MTD devices which are based
178	  on RAM chips in this manner. This block device is a user of MTD
179	  devices performing that function.
180
181	  At the moment, it is also required for the Journalling Flash File
182	  System(s) to obtain a handle on the MTD device when it's mounted
183	  (although JFFS and JFFS2 don't actually use any of the functionality
184	  of the mtdblock device).
185
186	  Later, it may be extended to perform read/erase/modify/write cycles
187	  on flash chips to emulate a smaller block size. Needless to say,
188	  this is very unsafe, but could be useful for file systems which are
189	  almost never written to.
190
191	  You do not need this option for use with the DiskOnChip devices. For
192	  those, enable NFTL support (CONFIG_NFTL) instead.
193
194config MTD_BLOCK_RO
195	tristate "Readonly block device access to MTD devices"
196	depends on MTD_BLOCK!=y && BLOCK
197	select MTD_BLKDEVS
198	help
199	  This allows you to mount read-only file systems (such as cramfs)
200	  from an MTD device, without the overhead (and danger) of the caching
201	  driver.
202
203	  You do not need this option for use with the DiskOnChip devices. For
204	  those, enable NFTL support (CONFIG_NFTL) instead.
205
206config FTL
207	tristate "FTL (Flash Translation Layer) support"
208	depends on BLOCK
209	select MTD_BLKDEVS
210	---help---
211	  This provides support for the original Flash Translation Layer which
212	  is part of the PCMCIA specification. It uses a kind of pseudo-
213	  file system on a flash device to emulate a block device with
214	  512-byte sectors, on top of which you put a 'normal' file system.
215
216	  You may find that the algorithms used in this code are patented
217	  unless you live in the Free World where software patents aren't
218	  legal - in the USA you are only permitted to use this on PCMCIA
219	  hardware, although under the terms of the GPL you're obviously
220	  permitted to copy, modify and distribute the code as you wish. Just
221	  not use it.
222
223config NFTL
224	tristate "NFTL (NAND Flash Translation Layer) support"
225	depends on BLOCK
226	select MTD_BLKDEVS
227	---help---
228	  This provides support for the NAND Flash Translation Layer which is
229	  used on M-Systems' DiskOnChip devices. It uses a kind of pseudo-
230	  file system on a flash device to emulate a block device with
231	  512-byte sectors, on top of which you put a 'normal' file system.
232
233	  You may find that the algorithms used in this code are patented
234	  unless you live in the Free World where software patents aren't
235	  legal - in the USA you are only permitted to use this on DiskOnChip
236	  hardware, although under the terms of the GPL you're obviously
237	  permitted to copy, modify and distribute the code as you wish. Just
238	  not use it.
239
240config NFTL_RW
241	bool "Write support for NFTL"
242	depends on NFTL
243	help
244	  Support for writing to the NAND Flash Translation Layer, as used
245	  on the DiskOnChip.
246
247config INFTL
248	tristate "INFTL (Inverse NAND Flash Translation Layer) support"
249	depends on BLOCK
250	select MTD_BLKDEVS
251	---help---
252	  This provides support for the Inverse NAND Flash Translation
253	  Layer which is used on M-Systems' newer DiskOnChip devices. It
254	  uses a kind of pseudo-file system on a flash device to emulate
255	  a block device with 512-byte sectors, on top of which you put
256	  a 'normal' file system.
257
258	  You may find that the algorithms used in this code are patented
259	  unless you live in the Free World where software patents aren't
260	  legal - in the USA you are only permitted to use this on DiskOnChip
261	  hardware, although under the terms of the GPL you're obviously
262	  permitted to copy, modify and distribute the code as you wish. Just
263	  not use it.
264
265config RFD_FTL
266        tristate "Resident Flash Disk (Flash Translation Layer) support"
267	depends on BLOCK
268	select MTD_BLKDEVS
269	---help---
270	  This provides support for the flash translation layer known
271	  as the Resident Flash Disk (RFD), as used by the Embedded BIOS
272	  of General Software. There is a blurb at:
273
274		http://www.gensw.com/pages/prod/bios/rfd.htm
275
276config SSFDC
277	tristate "NAND SSFDC (SmartMedia) read only translation layer"
278	depends on BLOCK
279	select MTD_BLKDEVS
280	help
281	  This enables read only access to SmartMedia formatted NAND
282	  flash. You can mount it with FAT file system.
283
284
285config SM_FTL
286	tristate "SmartMedia/xD new translation layer"
287	depends on EXPERIMENTAL && BLOCK
288	select MTD_BLKDEVS
289	select MTD_NAND_ECC
290	help
291	  This enables EXPERIMENTAL R/W support for SmartMedia/xD
292	  FTL (Flash translation layer).
293	  Write support is only lightly tested, therefore this driver
294	  isn't recommended to use with valuable data (anyway if you have
295	  valuable data, do backups regardless of software/hardware you
296	  use, because you never know what will eat your data...)
297	  If you only need R/O access, you can use older R/O driver
298	  (CONFIG_SSFDC)
299
300config MTD_OOPS
301	tristate "Log panic/oops to an MTD buffer"
302	help
303	  This enables panic and oops messages to be logged to a circular
304	  buffer in a flash partition where it can be read back at some
305	  later point.
 
 
 
306
307config MTD_SWAP
308	tristate "Swap on MTD device support"
309	depends on MTD && SWAP
310	select MTD_BLKDEVS
311	help
312	  Provides volatile block device driver on top of mtd partition
313          suitable for swapping.  The mapping of written blocks is not saved.
314	  The driver provides wear leveling by storing erase counter into the
315	  OOB.
316
317source "drivers/mtd/chips/Kconfig"
318
319source "drivers/mtd/maps/Kconfig"
320
321source "drivers/mtd/devices/Kconfig"
322
323source "drivers/mtd/nand/Kconfig"
324
325source "drivers/mtd/onenand/Kconfig"
326
327source "drivers/mtd/lpddr/Kconfig"
328
329source "drivers/mtd/ubi/Kconfig"
330
331endif # MTD