[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1552310346-7629-67-git-send-email-info@metux.net>
Date: Mon, 11 Mar 2019 14:18:18 +0100
From: "Enrico Weigelt, metux IT consult" <info@...ux.net>
To: linux-kernel@...r.kernel.org
Subject: [PATCH 066/114] drivers: mtd: Kconfig: pedantic formatting
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@...ux.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
Powered by blists - more mailing lists