Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2813452imm; Fri, 24 Aug 2018 05:57:09 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZmWUE3aaK2iTJKO++gxSEJshem/6zmWHmBmsKW+v1QhpnxJa23+zlg/k4GVPCT3mnugJ1x X-Received: by 2002:a62:9349:: with SMTP id b70-v6mr1907572pfe.193.1535115429186; Fri, 24 Aug 2018 05:57:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535115429; cv=none; d=google.com; s=arc-20160816; b=gfXAS+w53Cye/aRUSVphmTfYno75m1I6SO07qYPyxPf5iLeQpl6iKeTcb/HAk75BvB +kzIBvNEsQ2T9ge2847CbsWAQq5aLTMujjhZ+mW4RCQkKr8wmDJnICJo+gYwH0vIoDLq Z4wwbmQnxrTwKAfRG1NczxVylwEQAyxAh768T/rgswjb25p7bG7BU7NNoNmKdC3wM+Th AfBTH/ryFczukDTRKlgIerpK9Pz9x3bwe6K2VwUQcDgxgREpfsxXUywXF+Uv9wwEDHYe 5Eql7guRaDpJBtZQHSNXkQ7EBkqcQe7LkKJryzpVhXNbntsMxsusRaCllPjyTc6afLw7 /4cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=JFDdAuPP8tzCh9qAODsIjeZ8NU6/w7bxC3fR4yHxGAM=; b=BsP8rOQcFXQEcondxkXIn9d2jpmBKbG3IqL77jjSZfirjbw4biV/jyhUlqPDXOA9sh J/6npfy5/v8V/HQ/f8wOLJ7rDZ05AlIiPcRkZdRhYTZBuCxiCYH3D9k/85wYtSouz14/ HZOIMSLUfbaNQXv21HiO3njcy/2SoOCENwETGxDM8OokGE3SKYNFFD8UPDRJzay+wUMD l2X2lDtLMvbjxQtX0yrZv5/BYUohcJyq8zYC2zU1hNlc2vG6bAqXuzUUvqnrePgD9tJQ dVyqVZv9aMPSt6rfo2Knt7EgAOxHDkq4CHhKhn43kVyKF4BQiumEBBRQh9yNKx+BkGcd bipQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si6609729plv.28.2018.08.24.05.56.53; Fri, 24 Aug 2018 05:57:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727526AbeHXQaE (ORCPT + 99 others); Fri, 24 Aug 2018 12:30:04 -0400 Received: from mail.bootlin.com ([62.4.15.54]:47950 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726636AbeHXQaE (ORCPT ); Fri, 24 Aug 2018 12:30:04 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id B4E48207A3; Fri, 24 Aug 2018 14:55:30 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.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 (AAubervilliers-681-1-53-19.w90-88.abo.wanadoo.fr [90.88.170.19]) by mail.bootlin.com (Postfix) with ESMTPSA id 6300020728; Fri, 24 Aug 2018 14:55:20 +0200 (CEST) Date: Fri, 24 Aug 2018 14:55:19 +0200 From: Boris Brezillon To: Masahiro Yamada Cc: linux-mtd@lists.infradead.org, Miquel Raynal , linux-kernel@vger.kernel.org, Marek Vasut , Brian Norris , Richard Weinberger , David Woodhouse Subject: Re: [PATCH] mtd: rawnand: denali: do not pass zero maxchips to nand_scan() Message-ID: <20180824145519.330133a4@bbrezillon> In-Reply-To: <1534839799-14112-1-git-send-email-yamada.masahiro@socionext.com> References: <1534839799-14112-1-git-send-email-yamada.masahiro@socionext.com> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Masahiro, On Tue, 21 Aug 2018 17:23:19 +0900 Masahiro Yamada wrote: > Commit 49aa76b16676 ("mtd: rawnand: do not execute nand_scan_ident() > if maxchips is zero") gave a new meaning for calling nand_scan_ident() > with maxchips=0. > > It is a special usage for some drivers such as docg4, but in fact > the Denali driver may pass maxchips=0 to nand_scan() when the driver > is enabled but no NAND chip is found on the board for some reasons. > > If nand_scan_with_ids() is called with maxchips=0, nand_scan_ident() > is skipped, i.e. nand_set_defaults() is skipped. Therefore, the > driver must have set chip->controller beforehand. Otherwise, > nand_attach() causes NULL pointer dereference. > > In fact, the Denali controller knows the number of connected chips > before calling nand_scan_ident(); if DEVICE_RESET fails, there is no > chip in that chip select. Then, denali_reset_banks() sets the maxchips > to the number of detected chips. If no chip is found, it is zero. > > The reason of this trick was, as commit f486287d2372 ("mtd: nand: > denali: fix bank reset function to detect the number of chips") > explained, nand_scan_ident() issued Set Features (0xEF) command > to all CS lines, some of which may not be connected with a chip. > Then, the driver would wait until R/B# response, which never happens. > > This problem was solved by commit 107b7d6a7ad4 ("mtd: rawnand: avoid > setting again the timings to mode 0 after a reset"). In the current > code, nand_setup_data_interface() is called from nand_scan_tail(), > which is after the chip detection is done. > > Remove the code that is causing NULL pointer dereference. Now, the > maxchips passed to nand_scan() is the maximum number of chip selects > supported by the IP (typically 4 or 8). Leave all the chip detection > process to nand_scan_ident(). > > Signed-off-by: Masahiro Yamada > --- > > drivers/mtd/nand/raw/denali.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c > index ca18612..3e4b8e1 100644 > --- a/drivers/mtd/nand/raw/denali.c > +++ b/drivers/mtd/nand/raw/denali.c > @@ -1086,7 +1086,6 @@ static void denali_reset_banks(struct denali_nand_info *denali) > } > > dev_dbg(denali->dev, "%d chips connected\n", i); > - denali->max_banks = i; Shouldn't we instead avoid calling nand_scan() when denali->max_banks=0? I mean, what's the point of calling this function if you know for sure it will fail. Last question: do we still need this denali_reset_banks()? If it's only about resetting the chip to detect how many are actually present, that's already done by nand_scan(). > } > > static void denali_hw_init(struct denali_nand_info *denali)