From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: Stefan Roese <sr@denx.de>,
Brian Norris <computersforpeace@gmail.com>,
linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v2] mtd: nand: omap: fix BCHx ecc.correct to return detected bit-flips in erased-page
Date: Mon, 19 May 2014 09:20:52 -0300 [thread overview]
Message-ID: <20140519122052.GA698@arch.cereza> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EACDE66@DBDE04.ent.ti.com>
Hi Pekon,
On 19 May 05:00 AM, Gupta, Pekon wrote:
> >From: Brian Norris [mailto:computersforpeace@gmail.com]
> >
> >On Tue, Mar 25, 2014 at 12:28:19PM +0530, Pekon Gupta wrote:
> >> fixes: commit 62116e5171e00f85a8d53f76e45b84423c89ff34
> >> mtd: nand: omap2: Support for hardware BCH error correction.
> >>
> >> In omap_elm_correct_data(), if bitflip_count in an erased-page is within the
> >> correctable limit (< ecc.strength), then it is not indicated back to the caller
> >> ecc->read_page().
> >> This mis-guides upper layers like MTD and UBIFS layer to assume erased-page as
> >> perfectly clean and use it for writing even if actual bitflip_count was
> >> dangerously high (bitflip_count > mtd->bitflip_threshold).
> >>
> >> This patch fixes this above issue, by returning 'stats' to caller
> >> ecc->read_page() under all scenarios.
> >>
> >> Reported-by: Brian Norris <computersforpeace@gmail.com>
> >> Signed-off-by: Pekon Gupta <pekon@ti.com>
> >
> >Pushed to l2-mtd.git. Thanks!
> >
>
> Just forgot to ask, Is this patch candidate for stable?
>
> This one fixes the long standing issue of returning bit-flip count of an
> erased-page to upper layers. So that upper layers take correct decision.
>
Yes, if the commit fixes a bug then it can be marked for stable.
There's some instructions on this subject, please take a look at [1] and [2].
I think this patch qualifies the stable rules.
In particular, if a patch fixes a bug and you know the culprit commit you
can add a Fixes tag to pass such information, with a 12-digit commit ID and
the commit title enclosed in double-quotes [1]:
Fixes: 62116e5171e0 ("mtd: nand: omap2: Support for hardware BCH error correction")
To mark it for stable [2], you need add a Cc tag like this:
Cc: <stable@vger.kernel.org> # 3.x.y
You can use something like this to find the releases that contain the bug:
git tag -l --contains 62116e5171e0 | grep ^v3
It's handy to add that as a git alias:
[alias]
..
ontags = !sh -c 'git tag -l --contains $1 | grep ^v[23]' -
However, now that Brian has pushed the patch, you don't need to do any of
this. AFAIK, maintainers usually take care of all the above.
[1] Documentation/SubmittingPatches
[2] Documentation/stable_kernel_rules.txt.
Hope this helps,
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-05-19 12:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-25 6:58 [PATCH v2] mtd: nand: omap: fix BCHx ecc.correct to return detected bit-flips in erased-page Pekon Gupta
2014-03-25 7:05 ` Gupta, Pekon
2014-04-23 6:29 ` Gupta, Pekon
2014-05-12 20:36 ` Brian Norris
2014-05-19 5:00 ` Gupta, Pekon
2014-05-19 12:20 ` Ezequiel Garcia [this message]
2014-05-20 4:43 ` Gupta, Pekon
2014-05-20 23:42 ` Brian Norris
2014-05-22 17:56 ` Gupta, Pekon
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=20140519122052.GA698@arch.cereza \
--to=ezequiel.garcia@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=pekon@ti.com \
--cc=sr@denx.de \
/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