linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: richard.genoud@gmail.com (Richard Genoud)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 7/8] UBI: add ioctl for max_beb_per1024
Date: Fri, 17 Aug 2012 16:35:23 +0200	[thread overview]
Message-ID: <1345214124-5478-8-git-send-email-richard.genoud@gmail.com> (raw)
In-Reply-To: <1345214124-5478-1-git-send-email-richard.genoud@gmail.com>

This patch provides the possibility to adjust the "maximum expected number of
bad blocks per 1024 blocks" (max_beb_per1024) for each mtd device from
UBI_IOCATT ioctl.

The majority of NAND devices have their max_beb_per1024 equal to 20, but
sometimes it's more.
We already could adjust that via a kernel parameter, now we can also use
UBI_IOCATT ioctl:
struct ubi_attach_req {
	__s32 ubi_num;
	__s32 mtd_num;
	__s32 vid_hdr_offset;
	__u8 max_beb_per1024;
	__s8 padding[11];
};

Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
---
 drivers/mtd/ubi/Kconfig |    3 ++-
 drivers/mtd/ubi/cdev.c  |    2 +-
 include/mtd/ubi-user.h  |   19 ++++++++++++++++++-
 3 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
index 8b67bac..56531a7 100644
--- a/drivers/mtd/ubi/Kconfig
+++ b/drivers/mtd/ubi/Kconfig
@@ -51,7 +51,8 @@ config MTD_UBI_BEB_LIMIT
 	  MTD partitions of the same size, UBI will reserve 40 eraseblocks when
 	  attaching a partition.
 
-	  This option can be overridden by the kernel parameter ubi.mtd.
+	  This option can be overridden by the kernel parameter ubi.mtd and the
+	  ioctl UBI_IOCATT.
 
 	  Leave the default value if unsure.
 
diff --git a/drivers/mtd/ubi/cdev.c b/drivers/mtd/ubi/cdev.c
index 619f914..7885dc0 100644
--- a/drivers/mtd/ubi/cdev.c
+++ b/drivers/mtd/ubi/cdev.c
@@ -1011,7 +1011,7 @@ static long ctrl_cdev_ioctl(struct file *file, unsigned int cmd,
 		 */
 		mutex_lock(&ubi_devices_mutex);
 		err = ubi_attach_mtd_dev(mtd, req.ubi_num, req.vid_hdr_offset,
-					 CONFIG_MTD_UBI_BEB_LIMIT);
+					 req.max_beb_per1024);
 		mutex_unlock(&ubi_devices_mutex);
 		if (err < 0)
 			put_mtd_device(mtd);
diff --git a/include/mtd/ubi-user.h b/include/mtd/ubi-user.h
index 8787349..8168d9b 100644
--- a/include/mtd/ubi-user.h
+++ b/include/mtd/ubi-user.h
@@ -222,6 +222,7 @@ enum {
  * @ubi_num: UBI device number to create
  * @mtd_num: MTD device number to attach
  * @vid_hdr_offset: VID header offset (use defaults if %0)
+ * @max_beb_per1024: Maximum expected bad eraseblocks per 1024 eraseblocks
  * @padding: reserved for future, not used, has to be zeroed
  *
  * This data structure is used to specify MTD device UBI has to attach and the
@@ -245,12 +246,28 @@ enum {
  * 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.
+ *
+ * The @max_beb_per1024 is the maximum bad eraseblocks UBI expects on the ubi
+ * device per 1024 eraseblocks.
+ * This value is often given in an other form in the NAND datasheet (min NVB
+ * i.e. minimal number of valid blocks). The maximum expected bad eraseblocks
+ * per 1024 is then:
+ *   1024 * (1 - MinNVB / MaxNVB)
+ * Which gives 20 for most NAND devices.
+ * This limit is used in order to derive amount of eraseblock UBI reserves for
+ * handling new bad blocks.
+ * If the device has more bad eraseblocks than this limit, UBI does not reserve
+ * any physical eraseblocks for new bad eraseblocks, but attempts to use
+ * available eraseblocks (if any).
+ * The accepted range is 0-255. If 0 is given, the default kernel config value
+ * CONFIG_MTD_UBI_BEB_LIMIT will be used for compatibility.
  */
 struct ubi_attach_req {
 	__s32 ubi_num;
 	__s32 mtd_num;
 	__s32 vid_hdr_offset;
-	__s8 padding[12];
+	__u8 max_beb_per1024;
+	__s8 padding[11];
 };
 
 /**
-- 
1.7.2.5

  parent reply	other threads:[~2012-08-17 14:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-17 14:35 [PATCH 0/8] UBI: add max_beb_per1024 parameter / ioctl Richard Genoud
2012-08-17 14:35 ` [PATCH 1/8] arm: sam9_l9260_defconfig: adjust UBI bad eraseblocks limit Richard Genoud
2012-08-19 19:21   ` Artem Bityutskiy
2012-08-19 19:29     ` Artem Bityutskiy
2012-08-20  7:56   ` Jean-Christophe PLAGNIOL-VILLARD
2012-08-17 14:35 ` [PATCH 2/8] UBI: separate bad_peb_limit in a function Richard Genoud
2012-08-19  7:20   ` Shmulik Ladkani
2012-08-19 19:19   ` Artem Bityutskiy
2012-08-17 14:35 ` [PATCH 3/8] UBI: introduce MTD_PARAM_MAX_COUNT Richard Genoud
2012-08-19 19:32   ` Artem Bityutskiy
2012-08-19 19:32   ` Artem Bityutskiy
2012-08-17 14:35 ` [PATCH 4/8] UBI: prepare for max_beb_per1024 module parameter addition Richard Genoud
2012-08-19  9:01   ` Shmulik Ladkani
2012-08-17 14:35 ` [PATCH 5/8] UBI: check max_beb_per1024 value in ubi_attach_mtd_dev Richard Genoud
2012-08-19  9:08   ` Shmulik Ladkani
2012-08-20  6:31     ` Richard Genoud
2012-08-20  8:25       ` Artem Bityutskiy
2012-08-20  8:29         ` Artem Bityutskiy
2012-08-17 14:35 ` [PATCH 6/8] UBI: replace MTD_UBI_BEB_LIMIT with module parameter Richard Genoud
2012-08-19  9:26   ` Shmulik Ladkani
2012-08-20  7:38     ` Richard Genoud
2012-08-20  8:21       ` Richard Genoud
2012-08-17 14:35 ` Richard Genoud [this message]
2012-08-17 14:35 ` [PATCH 8/8] UBI: drop CONFIG_MTD_UBI_BEB_LIMIT Richard Genoud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1345214124-5478-8-git-send-email-richard.genoud@gmail.com \
    --to=richard.genoud@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).