All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.