From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Zach Brown <zach.brown@ni.com>
Cc: <dwmw2@infradead.org>, <dedekind1@gmail.com>, <richard@nod.at>,
<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
<computersforpeace@gmail.com>
Subject: Re: [PATCH v3 3/5] mtd: nand: Add bb_per_lun and blocks_per_lun fields to nand_chip
Date: Sun, 6 Nov 2016 18:53:17 +0100 [thread overview]
Message-ID: <20161106185317.3504896c@bbrezillon> (raw)
In-Reply-To: <20161101183231.GA13831@zach-desktop>
On Tue, 1 Nov 2016 13:32:32 -0500
Zach Brown <zach.brown@ni.com> wrote:
> On Tue, Nov 01, 2016 at 02:50:58PM +0100, Boris Brezillon wrote:
> > On Fri, 28 Oct 2016 15:27:42 -0500
> > Zach Brown <zach.brown@ni.com> wrote:
> >
> > > The fields bb_per_lun and blocks_per_lun are useful determining the
> > > number of bad blocks a MTD needs to allocate. How they are set will
> > > depend on if the chip is ONFI, JEDEC or a fuill-id entry in the nand_ids
> > > table.
> > >
> > > Signed-off-by: Zach Brown <zach.brown@ni.com>
> > > ---
> > > include/linux/mtd/nand.h | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > > index c5d3d502..efbe439 100644
> > > --- a/include/linux/mtd/nand.h
> > > +++ b/include/linux/mtd/nand.h
> > > @@ -771,6 +771,9 @@ nand_get_sdr_timings(const struct nand_data_interface *conf)
> > > * supported, 0 otherwise.
> > > * @jedec_params: [INTERN] holds the JEDEC parameter page when JEDEC is
> > > * supported, 0 otherwise.
> > > + * @bb_per_lun: [INTERN] the max number of bad blocks each LUN of a
> > > + * this nand device will encounter their life times.
> > > + * @blocks_per_lun: [INTERN] The number of PEBs in a LUN
> > > * @read_retries: [INTERN] the number of read retry modes supported
> > > * @onfi_set_features: [REPLACEABLE] set the features for ONFI nand
> > > * @onfi_get_features: [REPLACEABLE] get the features for ONFI nand
> > > @@ -853,6 +856,8 @@ struct nand_chip {
> > > struct nand_onfi_params onfi_params;
> > > struct nand_jedec_params jedec_params;
> > > };
> > > + __le16 bb_per_lun;
> > > + __le32 blocks_per_lun;
> >
> > Two things I don't like here:
> > - you use little-endian types, while it should use native endianness.
> > Make it easier, and just declare those fields as int (or unsigned
> > int).
> > - you stick to the ONFI spec, while I'd prefer to see the term lun
> > replaced by die, and I wonder if we don't already have a field
> > storing the number of blocks per die (I might be wrong though).
> >
>
> I looked for an existing field for number of blocks per die and could not find
> it. Perhaps you were remembering chipsize? or numchips? I looked at how they
> were calculated and chipsize is a multiple of (blocks_per_lun * lun_count) so
> it can't be used to find blocks_per_lun without storing lun_count anyways.
> Let me know if you think I missed something.
Probably not, we so many fields in the nand_chip and mtd_info struct
that I don't remember which ones we are missing ;-).
next prev parent reply other threads:[~2016-11-06 17:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-28 20:27 [PATCH v3 0/5] mtd: use ONFI bad blocks per LUN to calculate UBI bad PEB limit Zach Brown
2016-10-28 20:27 ` [PATCH v3 1/5] mtd: introduce function max_bad_blocks Zach Brown
2016-10-28 20:27 ` [PATCH v3 2/5] mtd: ubi: use 'max_bad_blocks' to compute bad_peb_limit if available Zach Brown
2016-10-28 20:27 ` [PATCH v3 3/5] mtd: nand: Add bb_per_lun and blocks_per_lun fields to nand_chip Zach Brown
2016-11-01 13:50 ` Boris Brezillon
2016-11-01 18:32 ` Zach Brown
2016-11-06 17:53 ` Boris Brezillon [this message]
2016-10-28 20:27 ` [PATCH v3 4/5] mtd: nand: implement 'max_bad_blocks' mtd function Zach Brown
2016-10-28 20:27 ` [PATCH v3 5/5] mtd: nand: set bb_per_lun and blocks_per_lun for ONFI compliant chips Zach Brown
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=20161106185317.3504896c@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 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).