summaryrefslogtreecommitdiffstats
path: root/include/mtd
diff options
context:
space:
mode:
authorArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2008-07-18 12:19:52 +0200
committerArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2008-07-24 12:36:09 +0200
commit9c9ec147709e63e4e8ac6a037c6bb50688ff8e9c (patch)
treed66805c819ffa2ae42bf5743ac77f077c903ad19 /include/mtd
parentUBI: bugfix - do not torture PEB needlessly (diff)
downloadlinux-9c9ec147709e63e4e8ac6a037c6bb50688ff8e9c.tar.xz
linux-9c9ec147709e63e4e8ac6a037c6bb50688ff8e9c.zip
UBI: fix checkpatch.pl errors and warnings
Just out or curiousity ran checkpatch.pl for whole UBI, and discovered there are quite a few of stylistic issues. Fix them. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Diffstat (limited to 'include/mtd')
-rw-r--r--include/mtd/ubi-user.h16
1 files changed, 8 insertions, 8 deletions
diff --git a/include/mtd/ubi-user.h b/include/mtd/ubi-user.h
index e8e57c3dfcdb..ccdc562e444e 100644
--- a/include/mtd/ubi-user.h
+++ b/include/mtd/ubi-user.h
@@ -188,14 +188,14 @@ enum {
* it will be 512 in case of a 2KiB page NAND flash with 4 512-byte sub-pages.
*
* But in rare cases, if this optimizes things, the VID header may be placed to
- * a different offset. For example, the boot-loader might do things faster if the
- * VID header sits at the end of the first 2KiB NAND page with 4 sub-pages. As
- * the boot-loader would not normally need to read EC headers (unless it needs
- * UBI in RW mode), it might be faster to calculate ECC. This is weird example,
- * but it real-life example. So, in this example, @vid_hdr_offer would be
- * 2KiB-64 bytes = 1984. Note, that this position is not even 512-bytes
- * aligned, which is OK, as UBI is clever enough to realize this is 4th sub-page
- * of the first page and add needed padding.
+ * a different offset. For example, the boot-loader might do things faster if
+ * the VID header sits at the end of the first 2KiB NAND page with 4 sub-pages.
+ * As the boot-loader would not normally need to read EC headers (unless it
+ * needs UBI in RW mode), it might be faster to calculate ECC. This is weird
+ * example, but it real-life example. So, in this example, @vid_hdr_offer would
+ * be 2KiB-64 bytes = 1984. Note, that this position is not even 512-bytes
+ * aligned, which is OK, as UBI is clever enough to realize this is 4th
+ * sub-page of the first page and add needed padding.
*/
struct ubi_attach_req {
int32_t ubi_num;