diff mbox

[v8,2/5] mtd: ubi: use 'max_bad_blocks' to compute bad_peb_limit if available

Message ID 1484076621-7789-3-git-send-email-zach.brown@ni.com
State Accepted
Delegated to: Richard Weinberger
Headers show

Commit Message

Zach Brown Jan. 10, 2017, 7:30 p.m. UTC 
From: Jeff Westfahl <jeff.westfahl@ni.com>

If the user has not set max_beb_per1024 using either the cmdline or
Kconfig options for doing so, use the MTD function 'max_bad_blocks' to
compute the UBI bad_peb_limit.

Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Signed-off-by: Zach Brown <zach.brown@ni.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electron.com>
---
 drivers/mtd/ubi/build.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

Comments

Richard Weinberger Feb. 7, 2017, 7:33 p.m. UTC | #1 
Am 10.01.2017 um 20:30 schrieb Zach Brown:
> From: Jeff Westfahl <jeff.westfahl@ni.com>
> 
> If the user has not set max_beb_per1024 using either the cmdline or
> Kconfig options for doing so, use the MTD function 'max_bad_blocks' to
> compute the UBI bad_peb_limit.
> 
> Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
> Acked-by: Boris Brezillon <boris.brezillon@free-electron.com>

Does this patch go via the MTD tree?
In this case:
Acked-by: Richard Weinberger <richard@nod.at>

Thanks,
//richard
Brian Norris Feb. 8, 2017, 10:03 p.m. UTC | #2 
On Tue, Feb 07, 2017 at 08:33:53PM +0100, Richard Weinberger wrote:
> Am 10.01.2017 um 20:30 schrieb Zach Brown:
> > From: Jeff Westfahl <jeff.westfahl@ni.com>
> > 
> > If the user has not set max_beb_per1024 using either the cmdline or
> > Kconfig options for doing so, use the MTD function 'max_bad_blocks' to
> > compute the UBI bad_peb_limit.
> > 
> > Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
> > Signed-off-by: Zach Brown <zach.brown@ni.com>
> > Acked-by: Boris Brezillon <boris.brezillon@free-electron.com>
> 
> Does this patch go via the MTD tree?
> In this case:
> Acked-by: Richard Weinberger <richard@nod.at>

I thought we had said something about going through the UBI tree. But I
don't care.

I'm not sure what's happening with patches 3-5 yet either.

I'm applying patch 1 to l2-mtd.git. Depending on the following, I can
apply patch 2 as well...

...but this is still a bit awkward; AFAICT, if you use the default
Kconfig (MTD_UBI_BEB_LIMIT == 20) then this won't take effect. Accepting
the default seems a little different than "I chose a value in Kconfig."

I think we could probably reconcile this by dropping the Kconfig (as
Richard suggested), and defaulting to 20 if neither cmdline nor
autodetect (e.g., ONFI) have said otherwise.

Or if y'all agree that the behavior I mentioned is fine, I can still
take this on behalf of Richard.

Brian
Brian Norris Feb. 8, 2017, 10:21 p.m. UTC | #3 
On Wed, Feb 08, 2017 at 02:03:45PM -0800, Brian Norris wrote:
> I'm not sure what's happening with patches 3-5 yet either.

Never mind, those were reviewed and ready for me (not the NAND tree).
Applied 3 to 5 to l2-mtd.git.
diff mbox

Patch

diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 85d54f3..3029219 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -584,8 +584,17 @@  static int get_bad_peb_limit(const struct ubi_device *ubi, int max_beb_per1024)
 	int limit, device_pebs;
 	uint64_t device_size;
 
-	if (!max_beb_per1024)
-		return 0;
+	if (!max_beb_per1024) {
+		/*
+		 * Since max_beb_per1024 has not been set by the user in either
+		 * the cmdline or Kconfig, use mtd_max_bad_blocks to set the
+		 * limit if it is supported by the device.
+		 */
+		limit = mtd_max_bad_blocks(ubi->mtd, 0, ubi->mtd->size);
+		if (limit < 0)
+			return 0;
+		return limit;
+	}
 
 	/*
 	 * Here we are using size of the entire flash chip and