From patchwork Tue Jul 25 18:54:06 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Boris Brezillon X-Patchwork-Id: 793595 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133; helo=bombadil.infradead.org; envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jaAyDA8W"; dkim-atps=neutral Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3xH6qr0LNRz9s75 for ; Wed, 26 Jul 2017 04:55:02 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Wmy9QKf1n2I9PvgzPehnBGq1wpN3I3bLjPFB/V6GCc0=; b=jaAyDA8WRkHlyr LR3OL0o1bAy7dWCG/iggVfLeowOro2KAA81r7VKTQSS4xxOwkI0T1dpTasF90XVci1Knx805fSrde E2SEupEesHfAsEA0UkTX9Sk4KsnPhoXmRJyJmZmozaKQCkVXjGNmt63pT/gw2eEq82YcMeuvsbAeN D3JFYCzBbE47pa/gXCieb5ipPOerQJjyuwVBx7Y9McMhj0ohSUDwc7PcxKFnD2FLPeJ12fQjWfoZY pqUqpn8MInNFbs/Yz5gWMn0bOG4OpQhr+F+JeNs9iF763eoJDpSWwWfEAHnEzZehEfCUpSc9wpWN0 xNogPkOZzbdeIvhj4sfQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1da4yu-0007tD-KL; Tue, 25 Jul 2017 18:54:56 +0000 Received: from mail.free-electrons.com ([62.4.15.54]) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1da4yU-0007rg-K9 for linux-mtd@lists.infradead.org; Tue, 25 Jul 2017 18:54:32 +0000 Received: by mail.free-electrons.com (Postfix, from userid 110) id 403F421DA5; Tue, 25 Jul 2017 20:54:05 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.free-electrons.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.free-electrons.com (Postfix) with ESMTPSA id 1C79B209B5; Tue, 25 Jul 2017 20:54:05 +0200 (CEST) Date: Tue, 25 Jul 2017 20:54:06 +0200 From: Boris Brezillon To: Alexander Dahl Subject: Re: mtd: nand: atmel: probe of Spansion S34ML02G1 fails Message-ID: <20170725205406.5a946c08@bbrezillon> In-Reply-To: <5326598.QgYTQxcFMR@ada> References: <5326598.QgYTQxcFMR@ada> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170725_115430_986969_4E82B518 X-CRM114-Status: GOOD ( 21.51 ) X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Richard Weinberger , linux-mtd@lists.infradead.org Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Hi Alexander, Le Tue, 25 Jul 2017 11:26:33 +0200, Alexander Dahl a écrit : > Hello, > > when testing the recent v4.13-rc2 on our at91sam9g20 based platform I > discovered one of the NAND flash chips we use can not be setup correctly > anymore. I guess this may be due to the reworked atmel nand driver after > v4.9, but it may be another problem. > > The board layout is similar to the at91sam9g20ek for the NAND flash part > and we're using different flash chips. With an hynix HY27UF082G2B > everything works, the console output on boot is like this: > > nand: Could not find valid ONFI parameter page; aborting > nand: device found, Manufacturer ID: 0xad, Chip ID: 0xda > nand: Hynix NAND 256MiB 3,3V 8-bit > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 > > The same board with another pin compatible flash chip, the Spansion > S34ML02G100TF100 however fails. I added some debug print statements to a > otherwise clean 4.13-rc2 kernel and get this: > > nand: device found, Manufacturer ID: 0x01, Chip ID: 0xda > nand: AMD/Spansion S34ML02G1 > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 > nand: onfi_version: 10, onfi_params.opt_cmd: 0x001B > nand: chip->onfi_set_features() failed: -22 > nand: nand_setup_data_interface() failed: -22 > atmel-nand-controller 10000000.ebi:nand-controller: nand_scan_ident() > failed: -22 > atmel-nand-controller: probe of 10000000.ebi:nand-controller failed > with error -22 > > So in the ONFI parameter page of the flash chip the value for "optional > commands supported" in the features block is 0x001B which is exactly > what the datasheet says. This means this flash chip does not support > "Get Features" and "Set Features". > > Now nand_onfi_set_features() correctly fails, because the nand chip can > not set features. It's called in nand_setup_data_interface() in > nand_base.c which fails itself because of the return value of the failed > set features call and so the whole chain of fails starts. Oh crap! We didn't consider ONFI NANDs which are supporting the SET/GET FEATURES operations when working on the timing selection logic. > > The nand chip actually works fine in U-Boot, and with kernels up to > v4.9.35, I didn't test v4.10, v4.11, but IIRC the board booted from nand > flash with v4.12. > > Can anyone help me to fix this? Can you try with the following fix? Thanks, Boris > > Greets > Alex > --->8--- diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 5fa5ddc94834..fc897f799def 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -1125,7 +1125,9 @@ static int nand_setup_data_interface(struct nand_chip *chip, int chipnr) * Ensure the timing mode has been changed on the chip side * before changing timings on the controller side. */ - if (chip->onfi_version) { + if (chip->onfi_version && + (le16_to_cpu(chip->onfi_params.opt_cmd) & + ONFI_OPT_CMD_SET_GET_FEATURES)) { u8 tmode_param[ONFI_SUBFEATURE_PARAM_LEN] = { chip->onfi_timing_mode_default, };