From: Greg KH <gregkh@linuxfoundation.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: stable@vger.kernel.org, sashal@kernel.org,
david regan <dregan@mail.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Brian Norris <computersforpeace@gmail.com>,
"open list:NAND FLASH SUBSYSTEM" <linux-mtd@lists.infradead.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND stable 4.9] mtd: rawnand: brcmnand: Fixed incorrect sub-page ECC status
Date: Wed, 23 Feb 2022 18:54:05 +0100 [thread overview]
Message-ID: <YhZ0vZxlp1VTgNG8@kroah.com> (raw)
In-Reply-To: <20220223174431.1083-3-f.fainelli@gmail.com>
On Wed, Feb 23, 2022 at 09:44:31AM -0800, Florian Fainelli wrote:
> From: david regan <dregan@mail.com>
>
> commit 36415a7964711822e63695ea67fede63979054d9 upstream
>
> The brcmnand driver contains a bug in which if a page (example 2k byte)
> is read from the parallel/ONFI NAND and within that page a subpage (512
> byte) has correctable errors which is followed by a subpage with
> uncorrectable errors, the page read will return the wrong status of
> correctable (as opposed to the actual status of uncorrectable.)
>
> The bug is in function brcmnand_read_by_pio where there is a check for
> uncorrectable bits which will be preempted if a previous status for
> correctable bits is detected.
>
> The fix is to stop checking for bad bits only if we already have a bad
> bits status.
>
> Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
> Signed-off-by: david regan <dregan@mail.com>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Link: https://lore.kernel.org/linux-mtd/trinity-478e0c09-9134-40e8-8f8c-31c371225eda-1643237024774@3c-app-mailcom-lxa02
> [florian: make patch apply to 4.14, file was renamed]
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/mtd/nand/brcmnand/brcmnand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Why is this a RESEND? What happened with the first set?
thanks,
greg k-h
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: stable@vger.kernel.org, sashal@kernel.org,
david regan <dregan@mail.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Brian Norris <computersforpeace@gmail.com>,
"open list:NAND FLASH SUBSYSTEM" <linux-mtd@lists.infradead.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND stable 4.9] mtd: rawnand: brcmnand: Fixed incorrect sub-page ECC status
Date: Wed, 23 Feb 2022 18:54:05 +0100 [thread overview]
Message-ID: <YhZ0vZxlp1VTgNG8@kroah.com> (raw)
In-Reply-To: <20220223174431.1083-3-f.fainelli@gmail.com>
On Wed, Feb 23, 2022 at 09:44:31AM -0800, Florian Fainelli wrote:
> From: david regan <dregan@mail.com>
>
> commit 36415a7964711822e63695ea67fede63979054d9 upstream
>
> The brcmnand driver contains a bug in which if a page (example 2k byte)
> is read from the parallel/ONFI NAND and within that page a subpage (512
> byte) has correctable errors which is followed by a subpage with
> uncorrectable errors, the page read will return the wrong status of
> correctable (as opposed to the actual status of uncorrectable.)
>
> The bug is in function brcmnand_read_by_pio where there is a check for
> uncorrectable bits which will be preempted if a previous status for
> correctable bits is detected.
>
> The fix is to stop checking for bad bits only if we already have a bad
> bits status.
>
> Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
> Signed-off-by: david regan <dregan@mail.com>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Link: https://lore.kernel.org/linux-mtd/trinity-478e0c09-9134-40e8-8f8c-31c371225eda-1643237024774@3c-app-mailcom-lxa02
> [florian: make patch apply to 4.14, file was renamed]
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/mtd/nand/brcmnand/brcmnand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Why is this a RESEND? What happened with the first set?
thanks,
greg k-h
next prev parent reply other threads:[~2022-02-23 17:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 17:44 [PATCH RESEND stable 4.19] mtd: rawnand: brcmnand: Fixed incorrect sub-page ECC status Florian Fainelli
2022-02-23 17:44 ` Florian Fainelli
2022-02-23 17:44 ` [PATCH RESEND stable 4.14] " Florian Fainelli
2022-02-23 17:44 ` Florian Fainelli
2022-02-23 17:44 ` [PATCH RESEND stable 4.9] " Florian Fainelli
2022-02-23 17:44 ` Florian Fainelli
2022-02-23 17:54 ` Greg KH [this message]
2022-02-23 17:54 ` Greg KH
2022-02-23 17:54 ` Florian Fainelli
2022-02-23 17:54 ` Florian Fainelli
2022-02-23 18:24 ` Greg KH
2022-02-23 18:24 ` Greg KH
2022-02-23 18:29 ` Florian Fainelli
2022-02-23 18:29 ` Florian Fainelli
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=YhZ0vZxlp1VTgNG8@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=computersforpeace@gmail.com \
--cc=dregan@mail.com \
--cc=f.fainelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=vigneshr@ti.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.