LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Masahiro Yamada <yamada.masahiro@socionext.com>
To: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: Abhishek Sahu <absahu@codeaurora.org>,
	Archit Taneja <architt@codeaurora.org>,
	Richard Weinberger <richard@nod.at>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Marek Vasut <marek.vasut@gmail.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Andy Gross <andy.gross@linaro.org>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v2 01/14] mtd: rawnand: helper function for setting up ECC parameters
Date: Tue, 8 May 2018 15:14:40 +0900	[thread overview]
Message-ID: <CAK7LNATSv1_5hTrWgiATTNwri8YdqzoKe7P701MT69MVMRbUTg@mail.gmail.com> (raw)
In-Reply-To: <20180507093933.393964b7@bbrezillon>

2018-05-07 16:39 GMT+09:00 Boris Brezillon <boris.brezillon@bootlin.com>:
> On Mon, 7 May 2018 12:40:39 +0900
> Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
>
>> 2018-05-03 21:20 GMT+09:00 Abhishek Sahu <absahu@codeaurora.org>:
>> > commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check,
>> > match, maximize ECC settings") provides generic helpers which
>> > drivers can use for setting up ECC parameters.
>> >
>> > Since same board can have different ECC strength nand chips so
>> > following is the logic for setting up ECC strength and ECC step
>> > size, which can be used by most of the drivers.
>> >
>> > 1. If both ECC step size and ECC strength are already set
>> >    (usually by DT) then just check whether this setting
>> >    is supported by NAND controller.
>> > 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength
>> >    supported by NAND controller.
>> > 3. Otherwise, try to match the ECC step size and ECC strength closest
>> >    to the chip's requirement. If available OOB size can't fit the chip
>> >    requirement then select maximum ECC strength which can be fit with
>> >    available OOB size with warning.
>> >
>> > This patch introduces nand_ecc_param_setup function which calls the
>> > required helper functions for the above logic. The drivers can use
>> > this single function instead of calling the 3 helper functions
>> > individually.
>> >
>> > CC: Masahiro Yamada <yamada.masahiro@socionext.com>
>> > Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
>> > ---
>> > * Changes from v1:
>> >
>> >   NEW PATCH
>> >
>> >  drivers/mtd/nand/raw/nand_base.c | 42 ++++++++++++++++++++++++++++++++++++++++
>> >  include/linux/mtd/rawnand.h      |  3 +++
>> >  2 files changed, 45 insertions(+)
>> >
>> > diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
>> > index 72f3a89..dd7a984 100644
>> > --- a/drivers/mtd/nand/raw/nand_base.c
>> > +++ b/drivers/mtd/nand/raw/nand_base.c
>> > @@ -6249,6 +6249,48 @@ int nand_maximize_ecc(struct nand_chip *chip,
>> >  }
>> >  EXPORT_SYMBOL_GPL(nand_maximize_ecc);
>> >
>> > +/**
>> > + * nand_ecc_param_setup - Set the ECC strength and ECC step size
>> > + * @chip: nand chip info structure
>> > + * @caps: ECC engine caps info structure
>> > + * @oobavail: OOB size that the ECC engine can use
>> > + *
>> > + * Choose the ECC strength according to following logic
>> > + *
>> > + * 1. If both ECC step size and ECC strength are already set (usually by DT)
>> > + *    then check if it is supported by this controller.
>> > + * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength.
>> > + * 3. Otherwise, try to match the ECC step size and ECC strength closest
>> > + *    to the chip's requirement. If available OOB size can't fit the chip
>> > + *    requirement then fallback to the maximum ECC step size and ECC strength
>> > + *    and print the warning.
>> > + *
>> > + * On success, the chosen ECC settings are set.
>> > + */
>> > +int nand_ecc_param_setup(struct nand_chip *chip,
>> > +                        const struct nand_ecc_caps *caps, int oobavail)
>> > +{
>> > +       int ret;
>> > +
>> > +       if (chip->ecc.size && chip->ecc.strength)
>> > +               return nand_check_ecc_caps(chip, caps, oobavail);
>> > +
>> > +       if (chip->ecc.options & NAND_ECC_MAXIMIZE)
>> > +               return nand_maximize_ecc(chip, caps, oobavail);
>> > +
>> > +       if (!nand_match_ecc_req(chip, caps, oobavail))
>> > +               return 0;
>> > +
>> > +       ret = nand_maximize_ecc(chip, caps, oobavail);
>>
>>
>> Why two calls for nand_maximize_ecc()?
>
> As long as the code does the same thing, I don't care that much.
>
>>
>> My code is simpler,
>
> and I don't see how your code is simpler. Mainly a matter of taste
> AFAICS.
>
>> and does not display
>> false-positive warning.
>
> I agree on the false-positive warning though, this should be avoided.
>
>>
>>
>> > +       if (!ret)
>> > +               pr_warn("ECC (step, strength) = (%d, %d) not supported on this controller. Fallback to (%d, %d)\n",
>> > +                       chip->ecc_step_ds, chip->ecc_strength_ds,
>> > +                       chip->ecc.size, chip->ecc.strength);
>>
>>
>> This is annoying.
>>
>> {ecc_step_ds, ecc_strength_ds} are not provided by Non-ONFi devices.
>>
>> So,
>>   ECC (step, strength) = (0, 0) not supported on this controller.
>
> Well, if you have a chip that requires ECC but exposes 0bits/0bytes
> then this should be fixed. 0,0 should only be valid when the chip does
> not require ECC at all (so, only really old chips). For all other chips,
> including non-ONFI ones, we should have a valid value here.


Sorry, it was my misunderstanding.

My NAND chip is Toshiba.

If I remember correctly, Toshiba chips were not set
with ECC requirements in the past,
but as far as I tested the latest kernel now,
the ECC requirement was set by
drivers/mtd/nand/raw/nand_toshiba.c





>>
>> will be always displayed.
>>
>>
>> The strength will be checked by nand_ecc_strength_good() anyway.
>
> True. So, I agree that the pr_warn() is unneeded, but I still think we
> should fix all cases where ECC reqs are missing, so if you have such a
> setup, please add some code to nand_<vendor>.c to initialize
> ->ecc_xxx_ds properly.
>

If we decide to not display pr_warn(),
I think the code like denali_ecc_setup() should work, and simple.





-- 
Best Regards
Masahiro Yamada

  reply	other threads:[~2018-05-08  6:15 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03 12:20 [PATCH v2 00/14] Update for QCOM NAND driver Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 01/14] mtd: rawnand: helper function for setting up ECC parameters Abhishek Sahu
2018-05-07  3:40   ` Masahiro Yamada
2018-05-07  6:01     ` Abhishek Sahu
2018-05-07  7:39     ` Boris Brezillon
2018-05-08  6:14       ` Masahiro Yamada [this message]
2018-05-08  7:21         ` Abhishek Sahu
2018-05-07  8:16   ` Boris Brezillon
2018-05-08  7:22     ` Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 02/14] mtd: rawnand: denali: use helper function for ecc setup Abhishek Sahu
2018-05-21 14:30   ` Miquel Raynal
2018-05-22 14:09     ` Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 03/14] dt-bindings: qcom_nandc: make nand-ecc-strength optional Abhishek Sahu
2018-05-07  8:40   ` Boris Brezillon
2018-05-21 14:32   ` Miquel Raynal
2018-05-22 14:08     ` Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 04/14] mtd: rawnand: qcom: use the ecc strength from device parameter Abhishek Sahu
2018-05-07  8:28   ` Boris Brezillon
2018-05-08  7:26     ` Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 05/14] mtd: rawnand: qcom: wait for desc completion in all BAM channels Abhishek Sahu
2018-05-22  6:47   ` Miquel Raynal
2018-05-22 14:07     ` Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 06/14] mtd: rawnand: qcom: erased page detection for uncorrectable errors only Abhishek Sahu
2018-05-22  7:04   ` Miquel Raynal
2018-05-22 14:10     ` Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 07/14] mtd: rawnand: qcom: fix null pointer access for erased page detection Abhishek Sahu
2018-05-22  7:16   ` Miquel Raynal
2018-05-22 14:11     ` Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 08/14] mtd: rawnand: qcom: parse read errors for read oob also Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 09/14] mtd: rawnand: qcom: modify write_oob to remove read codeword part Abhishek Sahu
2018-05-22 10:02   ` Miquel Raynal
2018-05-22 14:14     ` Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 10/14] mtd: rawnand: qcom: fix return value for raw page read Abhishek Sahu
2018-05-22 12:04   ` Miquel Raynal
2018-05-22 14:15     ` Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 11/14] mtd: rawnand: qcom: minor code reorganization for bad block check Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 12/14] mtd: rawnand: qcom: check for operation errors in case of raw read Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 13/14] mtd: rawnand: qcom: helper function for " Abhishek Sahu
2018-05-03 12:20 ` [PATCH v2 14/14] mtd: rawnand: qcom: erased page bitflips detection Abhishek Sahu

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=CAK7LNATSv1_5hTrWgiATTNwri8YdqzoKe7P701MT69MVMRbUTg@mail.gmail.com \
    --to=yamada.masahiro@socionext.com \
    --cc=absahu@codeaurora.org \
    --cc=andy.gross@linaro.org \
    --cc=architt@codeaurora.org \
    --cc=boris.brezillon@bootlin.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --subject='Re: [PATCH v2 01/14] mtd: rawnand: helper function for setting up ECC parameters' \
    /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

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).