From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Schrempf Frieder <frieder.schrempf@kontron.de>,
Boris Brezillon <bbrezillon@kernel.org>,
Jeff Kletsky <git-commits@allycomm.com>,
liaoweixiong <liaoweixiong@allwinnertech.com>,
Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH v3 1/3] mtd: spinand: Stop using spinand->oobbuf for buffering bad block markers
Date: Tue, 10 Mar 2020 19:31:49 +0100 [thread overview]
Message-ID: <20200310183149.18839-1-miquel.raynal@bootlin.com> (raw)
In-Reply-To: <20200218100432.32433-2-frieder.schrempf@kontron.de>
On Tue, 2020-02-18 at 10:05:14 UTC, Schrempf Frieder wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> For reading and writing the bad block markers, spinand->oobbuf is
> currently used as a buffer for the marker bytes. During the
> underlying read and write operations to actually get/set the content
> of the OOB area, the content of spinand->oobbuf is reused and changed
> by accessing it through spinand->oobbuf and/or spinand->databuf.
>
> This is a flaw in the original design of the SPI NAND core and at the
> latest from 13c15e07eedf ("mtd: spinand: Handle the case where
> PROGRAM LOAD does not reset the cache") on, it results in not having
> the bad block marker written at all, as the spinand->oobbuf is
> cleared to 0xff after setting the marker bytes to zero.
>
> To fix it, we now just store the two bytes for the marker on the
> stack and let the read/write operations copy it from/to the page
> buffer later.
>
> Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
> Cc: stable@vger.kernel.org
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-03-10 18:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 10:05 [PATCH v3 0/3] mtd: spinand: Fix reading and writing of bad block markers Schrempf Frieder
2020-02-18 10:05 ` [PATCH v3 1/3] mtd: spinand: Stop using spinand->oobbuf for buffering " Schrempf Frieder
2020-03-10 18:31 ` Miquel Raynal [this message]
2020-02-18 10:05 ` [PATCH v3 2/3] mtd: spinand: Explicitly use MTD_OPS_RAW to write the bad block marker to OOB Schrempf Frieder
2020-03-10 18:31 ` Miquel Raynal
2020-02-18 10:05 ` [PATCH v3 3/3] mtd: spinand: Do not erase the block before writing a bad block marker Schrempf Frieder
2020-03-10 18:31 ` Miquel Raynal
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=20200310183149.18839-1-miquel.raynal@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=bbrezillon@kernel.org \
--cc=frieder.schrempf@kontron.de \
--cc=git-commits@allycomm.com \
--cc=liaoweixiong@allwinnertech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
/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).