[PATCH 066/114] drivers: mtd: Kconfig: pedantic formatting

["Enrico Weigelt, metux IT consult" <info@metux.net>]

Formatting of Kconfig files doesn't look so pretty, so let the
Great White Handkerchief come around and clean it up.

Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
---
 drivers/mtd/nand/onenand/Kconfig | 12 ++++----
 drivers/mtd/ubi/Kconfig          | 60 ++++++++++++++++++++--------------------
 2 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/mtd/nand/onenand/Kconfig b/drivers/mtd/nand/onenand/Kconfig
index 9dc1574..dfa0f45 100644
--- a/drivers/mtd/nand/onenand/Kconfig
+++ b/drivers/mtd/nand/onenand/Kconfig
@@ -32,12 +32,12 @@ config MTD_ONENAND_OMAP2
 	  Enable dmaengine and gpiolib for better performance.
 
 config MTD_ONENAND_SAMSUNG
-        tristate "OneNAND on Samsung SOC controller support"
-        depends on ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS4
-        help
-          Support for a OneNAND flash device connected to an Samsung SOC.
-          S3C64XX uses command mapping method.
-          S5PC110/S5PC210 use generic OneNAND method.
+	tristate "OneNAND on Samsung SOC controller support"
+	depends on ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS4
+	help
+	  Support for a OneNAND flash device connected to an Samsung SOC.
+	  S3C64XX uses command mapping method.
+	  S5PC110/S5PC210 use generic OneNAND method.
 
 config MTD_ONENAND_OTP
 	bool "OneNAND OTP Support"
diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
index 43d131f..e010dd5 100644
--- a/drivers/mtd/ubi/Kconfig
+++ b/drivers/mtd/ubi/Kconfig
@@ -60,47 +60,47 @@ config MTD_UBI_FASTMAP
 	bool "UBI Fastmap (Experimental feature)"
 	default n
 	help
-	   Important: this feature is experimental so far and the on-flash
-	   format for fastmap may change in the next kernel versions
-
-	   Fastmap is a mechanism which allows attaching an UBI device
-	   in nearly constant time. Instead of scanning the whole MTD device it
-	   only has to locate a checkpoint (called fastmap) on the device.
-	   The on-flash fastmap contains all information needed to attach
-	   the device. Using fastmap makes only sense on large devices where
-	   attaching by scanning takes long. UBI will not automatically install
-	   a fastmap on old images, but you can set the UBI module parameter
-	   fm_autoconvert to 1 if you want so. Please note that fastmap-enabled
-	   images are still usable with UBI implementations without
-	   fastmap support. On typical flash devices the whole fastmap fits
-	   into one PEB. UBI will reserve PEBs to hold two fastmaps.
-
-	   If in doubt, say "N".
+	  Important: this feature is experimental so far and the on-flash
+	  format for fastmap may change in the next kernel versions
+
+	  Fastmap is a mechanism which allows attaching an UBI device
+	  in nearly constant time. Instead of scanning the whole MTD device it
+	  only has to locate a checkpoint (called fastmap) on the device.
+	  The on-flash fastmap contains all information needed to attach
+	  the device. Using fastmap makes only sense on large devices where
+	  attaching by scanning takes long. UBI will not automatically install
+	  a fastmap on old images, but you can set the UBI module parameter
+	  fm_autoconvert to 1 if you want so. Please note that fastmap-enabled
+	  images are still usable with UBI implementations without
+	  fastmap support. On typical flash devices the whole fastmap fits
+	  into one PEB. UBI will reserve PEBs to hold two fastmaps.
+
+	  If in doubt, say "N".
 
 config MTD_UBI_GLUEBI
 	tristate "MTD devices emulation driver (gluebi)"
 	help
-	   This option enables gluebi - an additional driver which emulates MTD
-	   devices on top of UBI volumes: for each UBI volumes an MTD device is
-	   created, and all I/O to this MTD device is redirected to the UBI
-	   volume. This is handy to make MTD-oriented software (like JFFS2)
-	   work on top of UBI. Do not enable this unless you use legacy
-	   software.
+	  This option enables gluebi - an additional driver which emulates MTD
+	  devices on top of UBI volumes: for each UBI volumes an MTD device is
+	  created, and all I/O to this MTD device is redirected to the UBI
+	  volume. This is handy to make MTD-oriented software (like JFFS2)
+	  work on top of UBI. Do not enable this unless you use legacy
+	  software.
 
 config MTD_UBI_BLOCK
 	bool "Read-only block devices on top of UBI volumes"
 	default n
 	depends on BLOCK
 	help
-	   This option enables read-only UBI block devices support. UBI block
-	   devices will be layered on top of UBI volumes, which means that the
-	   UBI driver will transparently handle things like bad eraseblocks and
-	   bit-flips. You can put any block-oriented file system on top of UBI
-	   volumes in read-only mode (e.g., ext4), but it is probably most
-	   practical for read-only file systems, like squashfs.
+	  This option enables read-only UBI block devices support. UBI block
+	  devices will be layered on top of UBI volumes, which means that the
+	  UBI driver will transparently handle things like bad eraseblocks and
+	  bit-flips. You can put any block-oriented file system on top of UBI
+	  volumes in read-only mode (e.g., ext4), but it is probably most
+	  practical for read-only file systems, like squashfs.
 
-	   When selected, this feature will be built in the UBI driver.
+	  When selected, this feature will be built in the UBI driver.
 
-	   If in doubt, say "N".
+	  If in doubt, say "N".
 
 endif # MTD_UBI
-- 
1.9.1