From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936435AbcJ0T5B (ORCPT ); Thu, 27 Oct 2016 15:57:01 -0400 Received: from up.free-electrons.com ([163.172.77.33]:47925 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933171AbcJ0T5A (ORCPT ); Thu, 27 Oct 2016 15:57:00 -0400 Date: Thu, 27 Oct 2016 21:56:53 +0200 From: Boris Brezillon To: Zach Brown Cc: , , , , , Subject: Re: [RESEND PATCH v2 0/3] mtd: use ONFI bad blocks per LUN to calculate UBI bad PEB limit Message-ID: <20161027215653.6f97858d@bbrezillon> In-Reply-To: <1477595642-11454-1-git-send-email-zach.brown@ni.com> References: <1477595642-11454-1-git-send-email-zach.brown@ni.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Zach, Please do not resend after only one week. Reviewing this series was on my TODO list ;). On Thu, 27 Oct 2016 14:13:59 -0500 Zach Brown wrote: > For ONFI-compliant NAND devices, the ONFI parameters report the maximum number > of bad blocks per LUN that will be encountered over the lifetime of the device, > so we can use that information to get a more accurate (and smaller) value for > the UBI bad PEB limit. > > The ONFI parameter "maxiumum number of bad blocks per LUN" is the max number of > bad blocks that each individual LUN will ever ecounter. It is not the number of > bad blocks to reserve for the nand device per LUN in the device. > > This means that in the worst case a UBI device spanning X LUNs will encounter > "maximum number of bad blocks per LUN" * X bad blocks. The implementation in > this patch assumes this worst case and allocates bad block accordingly. That's a discussion I had with Richard a few months ago, and I didn't know someone had already proposed a patch for that. So that's all good news. Indeed, I really think we should use information retrieved at flash detection time rather than asking the user to explicitly tweak the bad_peb_limit value for its chip. > > These patches are ordered in terms of their dependencies, but ideally, all 3 > would need to be applied for this to work as intended. > > v1: > * Changed commit message to address concerns from v1[1] about this patch set > making best case assumptions. > > [1] > http://lkml.iu.edu/hypermail/linux/kernel/1505.1/04822.html > > Jeff Westfahl (3): > mtd: introduce function max_bad_blocks > mtd: nand: implement 'max_bad_blocks' mtd function > mtd: ubi: use 'max_bad_blocks' to compute bad_peb_limit if available > > drivers/mtd/mtdpart.c | 12 ++++++++++++ > drivers/mtd/nand/nand_base.c | 34 ++++++++++++++++++++++++++++++++++ > drivers/mtd/ubi/build.c | 9 +++++++++ > include/linux/mtd/mtd.h | 1 + > 4 files changed, 56 insertions(+) >