From patchwork Wed Oct 10 06:26:06 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Norris X-Patchwork-Id: 190556 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id B9B222C0085 for ; Wed, 10 Oct 2012 17:28:48 +1100 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TLpl8-0005S0-Sc; Wed, 10 Oct 2012 06:27:10 +0000 Received: from mail-da0-f49.google.com ([209.85.210.49]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1TLpl6-0005Rm-SL for linux-mtd@lists.infradead.org; Wed, 10 Oct 2012 06:27:09 +0000 Received: by mail-da0-f49.google.com with SMTP id q27so5906daj.36 for ; Tue, 09 Oct 2012 23:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer; bh=b2m3rTcglhepU1eqAulaC84G9C5iIDAfMC/ZKMynBWI=; b=VJowJe7zJzNXb+sO2F/Wvim/w5f0jbOo1nhSdMgSZZHpJcVlMjJDr/We0zasEPHDjE yNSg/qnfqTe2Mq8xROznx21dlNCPImcx4SjuKJAbuae+BXFbCjeWURk7okXzyhUMrWDs QSloa6HmPISGiDT/Y4ETsIu8TCWjh2tqSNooEiSislgCJpKpc9TgpLOUA2tBPjT54tOT P4zgLaVO/ZO21zmcAYwnEJUGw8pLwVjtk0x7Bx8sZcmEnxD22NiWnWMhXA8hjgIDBGwj +owQdpibbCETeDTWJnzDovPe0BYh2tSMJdeoRJNA0+lRQMUQHM0hRv9SK76y1eII0w6Y SObg== Received: by 10.66.85.37 with SMTP id e5mr10817052paz.64.1349850425835; Tue, 09 Oct 2012 23:27:05 -0700 (PDT) Received: from ld-irv-0074.broadcom.com (5520-maca-inet1-outside.broadcom.com. [216.31.211.11]) by mx.google.com with ESMTPS id pv9sm532358pbb.67.2012.10.09.23.27.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 23:27:04 -0700 (PDT) From: Brian Norris To: David Woodhouse Subject: [PATCH for 3.7] mtd: nand: fix Samsung SLC NAND identification regression Date: Tue, 9 Oct 2012 23:26:06 -0700 Message-Id: <1349850366-4731-1-git-send-email-computersforpeace@gmail.com> X-Mailer: git-send-email 1.7.11.3 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (computersforpeace[at]gmail.com) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.210.49 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: Marek Vasut , Brian Norris , linux-mtd@lists.infradead.org, Linux Kernel , Artem Bityutskiy X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org A combination of the following two commits caused a regression in 3.7-rc1 when identifying some Samsung NAND, so that some previously working NAND were no longer detected properly: commit e3b88bd604283ef83ae6e8f53622d5b1ffe9d43a mtd: nand: add generic READ ID length calculation functions commit e2d3a35ee427aaba99b6c68a56609ce276c51270 mtd: nand: detect Samsung K9GBG08U0A, K9GAG08U0F ID Particularly, a regression was seen on Samsung K9F2G08U0B, with the following full 8-byte READ ID string: ec da 10 95 44 00 ec da The basic problem is that Samsung manufactures both SLC and MLC NAND that use a non-standard decoding table for deriving information from their IDs. I have heuristically determined that all the chips that use the new table have ID strings which wrap around after the 6th byte. Unfortunately, I overlooked the fact that some older Samsung SLC (which use a different decoding table) have "5 byte ID strings" which also wrap around after the 6th byte. This patch re-introduces a distinction between these old and new Samsung NAND by checking that the 6th byte is non-zero, allowing both old and new Samsung NAND to be detected properly. Signed-off-by: Brian Norris Tested-by: Brian Norris Reported-by: Marek Vasut Tested-by: Marek Vasut --- David, Marek and I just discovered this issue during the merge window. Please merge this fix in the 3.7-rc cycle. Thanks. drivers/mtd/nand/nand_base.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index ec6841d..d5ece6e 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2983,13 +2983,14 @@ static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip, /* * Field definitions are in the following datasheets: * Old style (4,5 byte ID): Samsung K9GAG08U0M (p.32) - * New style (6 byte ID): Samsung K9GAG08U0F (p.44) + * New Samsung (6 byte ID): Samsung K9GAG08U0F (p.44) * Hynix MLC (6 byte ID): Hynix H27UBG8T2B (p.22) * - * Check for ID length, cell type, and Hynix/Samsung ID to decide what - * to do. + * Check for ID length, non-zero 6th byte, cell type, and Hynix/Samsung + * ID to decide what to do. */ - if (id_len == 6 && id_data[0] == NAND_MFR_SAMSUNG) { + if (id_len == 6 && id_data[0] == NAND_MFR_SAMSUNG && + id_data[5] != 0x00) { /* Calc pagesize */ mtd->writesize = 2048 << (extid & 0x03); extid >>= 2;