From: <gregkh@linuxfoundation.org>
To: computersforpeace@gmail.com, ezequiel.garcia@free-electrons.com,
gregkh@linuxfoundation.org, pekon@ti.com, slash.tmp@free.fr,
u.kleine-koenig@pengutronix.de
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "mtd: nand: don't use read_buf for 8-bit ONFI transfers" has been added to the 3.14-stable tree
Date: Tue, 28 Jul 2015 10:40:26 -0700 [thread overview]
Message-ID: <1438105226127118@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
mtd: nand: don't use read_buf for 8-bit ONFI transfers
to the 3.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mtd-nand-don-t-use-read_buf-for-8-bit-onfi-transfers.patch
and it can be found in the queue-3.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From bd9c6e99b58255b9de1982711ac9487c9a2f18be Mon Sep 17 00:00:00 2001
From: Brian Norris <computersforpeace@gmail.com>
Date: Fri, 29 Nov 2013 22:04:28 -0800
Subject: mtd: nand: don't use read_buf for 8-bit ONFI transfers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Brian Norris <computersforpeace@gmail.com>
commit bd9c6e99b58255b9de1982711ac9487c9a2f18be upstream.
Use a repeated read_byte() instead of read_buf(), since for x16 buswidth
devices, we need to avoid the upper I/O[16:9] bits. See the following
commit for reference:
commit 05f7835975dad6b3b517f9e23415985e648fb875
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Thu Dec 5 22:22:04 2013 +0100
mtd: nand: don't use {read,write}_buf for 8-bit transfers
Now, I think that all barriers to probing ONFI on x16 devices are
removed, so remove the check from nand_flash_detect_onfi().
Tested on 8-bit ONFI NAND (Micron MT29F32G08CBADAWP).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-By: Pekon Gupta <pekon@ti.com>
Cc: Mason <slash.tmp@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/nand/nand_base.c | 14 +++-----------
1 file changed, 3 insertions(+), 11 deletions(-)
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3063,7 +3063,7 @@ static int nand_flash_detect_onfi(struct
int *busw)
{
struct nand_onfi_params *p = &chip->onfi_params;
- int i;
+ int i, j;
int val;
/* Try ONFI for unknown chip or LP */
@@ -3072,18 +3072,10 @@ static int nand_flash_detect_onfi(struct
chip->read_byte(mtd) != 'F' || chip->read_byte(mtd) != 'I')
return 0;
- /*
- * ONFI must be probed in 8-bit mode or with NAND_BUSWIDTH_AUTO, not
- * with NAND_BUSWIDTH_16
- */
- if (chip->options & NAND_BUSWIDTH_16) {
- pr_err("ONFI cannot be probed in 16-bit mode; aborting\n");
- return 0;
- }
-
chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
for (i = 0; i < 3; i++) {
- chip->read_buf(mtd, (uint8_t *)p, sizeof(*p));
+ for (j = 0; j < sizeof(*p); j++)
+ ((uint8_t *)p)[j] = chip->read_byte(mtd);
if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
le16_to_cpu(p->crc)) {
break;
Patches currently in stable-queue which might be from computersforpeace@gmail.com are
queue-3.14/mtd-nand-fix-erroneous-read_buf-call-in-nand_write_page_raw_syndrome.patch
queue-3.14/mtd-fix-avoid-race-condition-when-accessing-mtd-usecount.patch
queue-3.14/mtd-nand-don-t-use-read_buf-for-8-bit-onfi-transfers.patch
queue-3.14/mtd-dc21285-use-raw-spinlock-functions-for-nw_gpio_lock.patch
next reply other threads:[~2015-07-28 17:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 17:40 gregkh [this message]
2015-07-28 17:49 ` Patch "mtd: nand: don't use read_buf for 8-bit ONFI transfers" has been added to the 3.14-stable tree Brian Norris
2015-07-28 17:49 ` Brian Norris
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=1438105226127118@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=computersforpeace@gmail.com \
--cc=ezequiel.garcia@free-electrons.com \
--cc=pekon@ti.com \
--cc=slash.tmp@free.fr \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=u.kleine-koenig@pengutronix.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 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.