From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Zach Brown <zach.brown@ni.com>
Cc: <dwmw2@infradead.org>, <computersforpeace@gmail.com>,
<richard@nod.at>, <dedekind1@gmail.com>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH v2 2/3] mtd: nand: implement 'max_bad_blocks' mtd function
Date: Thu, 27 Oct 2016 22:04:21 +0200 [thread overview]
Message-ID: <20161027220421.7a1471be@bbrezillon> (raw)
In-Reply-To: <1477595642-11454-3-git-send-email-zach.brown@ni.com>
On Thu, 27 Oct 2016 14:14:01 -0500
Zach Brown <zach.brown@ni.com> wrote:
> From: Jeff Westfahl <jeff.westfahl@ni.com>
>
> Implement the new mtd function 'max_bad_blocks'. Use the ONFI parameter
> page to find the maximum bad blocks to reserve for an MTD, taking into
> account how many LUNs the MTD spans.
>
> Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
> ---
> drivers/mtd/nand/nand_base.c | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index e5718e5..ac08224 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -3226,6 +3226,39 @@ static int nand_block_markbad(struct mtd_info *mtd, loff_t ofs)
> }
>
> /**
> + * nand_max_bad_blocks - [MTD Interface] Max number of bad blocks for an mtd
> + * @mtd: MTD device structure
> + * @ofs: offset relative to mtd start
> + * @len: length of mtd
> + */
> +static int nand_max_bad_blocks(struct mtd_info *mtd, loff_t ofs, size_t len)
> +{
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + uint32_t part_start_block;
> + uint32_t part_end_block;
> + uint32_t part_start_lun;
> + uint32_t part_end_lun;
> +
> + /* ONFI is used to determine the maximum bad block count. */
> + if (!chip->onfi_version)
> + return -ENOTSUPP;
> +
> + /* Get the start and end of the partition in erase blocks. */
> + part_start_block = mtd_div_by_eb(ofs, mtd);
> + part_end_block = mtd_div_by_eb(len, mtd) + part_start_block - 1;
> +
> + /* Get the start and end LUNs of the partition. */
> + part_start_lun = part_start_block / chip->onfi_params.blocks_per_lun;
> + part_end_lun = part_end_block / chip->onfi_params.blocks_per_lun;
> +
> + /* Look up the bad blocks per unit and multiply by the number of units
> + * that the partition spans.
> + */
> + return chip->onfi_params.bb_per_lun *
> + (part_end_lun - part_start_lun + 1);
Well, it's a good start, but I'd like to have something that works even
for non-ONFI chips. How about adding a field in nand_chip and filling
this field when the ONFI param page is retrieved/parsed. This way we
can easily extend the implementation for full-id entries in the
nand_ids table or for JEDEC compliant chips (assuming the JEDEC
standard provides such information).
> +}
> +
> +/**
> * nand_onfi_set_features- [REPLACEABLE] set features for ONFI nand
> * @mtd: MTD device structure
> * @chip: nand chip info structure
> @@ -4743,6 +4776,7 @@ int nand_scan_tail(struct mtd_info *mtd)
> mtd->_block_isreserved = nand_block_isreserved;
> mtd->_block_isbad = nand_block_isbad;
> mtd->_block_markbad = nand_block_markbad;
> + mtd->_max_bad_blocks = nand_max_bad_blocks;
> mtd->writebufsize = mtd->writesize;
>
> /*
next prev parent reply other threads:[~2016-10-27 20:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-27 19:13 [RESEND PATCH v2 0/3] mtd: use ONFI bad blocks per LUN to calculate UBI bad PEB limit Zach Brown
2016-10-27 19:14 ` [RESEND PATCH v2 1/3] mtd: introduce function max_bad_blocks Zach Brown
2016-10-27 20:01 ` Boris Brezillon
2016-10-27 19:14 ` [RESEND PATCH v2 2/3] mtd: nand: implement 'max_bad_blocks' mtd function Zach Brown
2016-10-27 20:04 ` Boris Brezillon [this message]
2016-10-27 19:14 ` [RESEND PATCH v2 3/3] mtd: ubi: use 'max_bad_blocks' to compute bad_peb_limit if available Zach Brown
2016-10-27 20:05 ` Boris Brezillon
2016-10-27 19:56 ` [RESEND PATCH v2 0/3] mtd: use ONFI bad blocks per LUN to calculate UBI bad PEB limit Boris Brezillon
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=20161027220421.7a1471be@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=zach.brown@ni.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.