Received: by 10.192.165.148 with SMTP id m20csp3590178imm; Mon, 30 Apr 2018 03:01:20 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr/Gz6SarBvJM8qumFDpXi39AnRbCaH+KaMIaqr5TWWlDc5AAT7SNxmx/2HNBTHJdNfISmv X-Received: by 2002:a65:56cb:: with SMTP id w11-v6mr9306017pgs.176.1525082480307; Mon, 30 Apr 2018 03:01:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525082480; cv=none; d=google.com; s=arc-20160816; b=e6mLM09s00grHZuHSFfkWfZMo3KNpiUbNtM5iXIEOLRmxOVwX857L+SYZIrn+6susH /ZqNH/M0EiVQPPv+27FpNwn6DKIPE/EYACwMS3Fger2gnZ6DTFxF5td5Uz23eAFvOq3N cURLpyvPYqUvawJ4kjqkrQS8xsuokk7ITgGTV6LnOKKqQ2kj2Z5AnBPEwH/FP5rEKDMp Ig+8c0yce6gEICBNmW5E0tg3xfrZkD+g2Yb1wkT70Y+4POnMeX2PWcsflQXcZA/UQlem OfxLXCRB8LbCIMetHzWf1sLki26JZkonw0HqonujDM5pvdyxyl7R6YF+fREMDqVTA0jy llTA== 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=JIQUGDOtr7QXadWTtDl1nFRzem1jdm6HWAUR9OjYGxE=; b=oKCwJFjxXsEHlxAVjqSsNcy8VcLxBG9Xm51F6RnxGQl/1odrvXYVlZhWfYnpO2+zHy 8ux8unqki8UiYB0plpH1AeOEZQSgTutlJ+g5+oC6wa1kKkS/mc8rV5nOwY4NmmgGy6RC IWpQfNIGoulnLCxyF5/b3FEmhspFGsO/52wdcXJKlDBv1hvIBE7HHysu12KYPzxQLm+q MIQTkmiLA72dZi0O+dyECmRMEWOZFVOV7suA5aA0ABU1rn+FUQ4pABI4OpljJ45Zfc1w F9OH5aJiivf0YBL9y9uXyeuZqZ0n8c7O7xxmJcp7AROvv3wC1trCTF6EN2sszoCuWf8w nH2Q== 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 f14-v6si6018361pgn.597.2018.04.30.03.01.06; Mon, 30 Apr 2018 03:01:20 -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 S1752861AbeD3KAt (ORCPT + 99 others); Mon, 30 Apr 2018 06:00:49 -0400 Received: from mail.bootlin.com ([62.4.15.54]:45358 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751308AbeD3KAs (ORCPT ); Mon, 30 Apr 2018 06:00:48 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 4DA5B207A5; Mon, 30 Apr 2018 12:00:46 +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 (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.bootlin.com (Postfix) with ESMTPSA id 12C5D20650; Mon, 30 Apr 2018 12:00:46 +0200 (CEST) Date: Mon, 30 Apr 2018 12:00:46 +0200 From: Boris Brezillon To: Jane Wan Cc: dwmw2@infradead.org, computersforpeace@gmail.com, ties.bos@nokia.com, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] Fix FSL NAND driver to read all ONFI parameter pages Message-ID: <20180430120046.3c87db2a@bbrezillon> In-Reply-To: <1524788396-32380-2-git-send-email-Jane.Wan@nokia.com> References: <1524788396-32380-1-git-send-email-Jane.Wan@nokia.com> <1524788396-32380-2-git-send-email-Jane.Wan@nokia.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 Jane, On Thu, 26 Apr 2018 17:19:55 -0700 Jane Wan wrote: > Signed-off-by: Jane Wan > --- > drivers/mtd/nand/fsl_ifc_nand.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c > index ca36b35..a3cf6ca 100644 > --- a/drivers/mtd/nand/fsl_ifc_nand.c > +++ b/drivers/mtd/nand/fsl_ifc_nand.c > @@ -413,6 +413,7 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, unsigned int command, > struct fsl_ifc_mtd *priv = chip->priv; > struct fsl_ifc_ctrl *ctrl = priv->ctrl; > struct fsl_ifc_runtime __iomem *ifc = ctrl->rregs; > + int len; > > /* clear the read buffer */ > ifc_nand_ctrl->read_bytes = 0; > @@ -462,11 +463,12 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, unsigned int command, > ifc_out32(column, &ifc->ifc_nand.row3); > > /* > - * although currently it's 8 bytes for READID, we always read > - * the maximum 256 bytes(for PARAM) > + * For READID, read 8 bytes that are currently used. > + * For PARAM, read all 3 copies of 256-bytes pages. > */ > - ifc_out32(256, &ifc->ifc_nand.nand_fbcr); > - ifc_nand_ctrl->read_bytes = 256; > + len = (command == NAND_CMD_PARAM) ? (3 * 256) : 8; > + ifc_out32(len, &ifc->ifc_nand.nand_fbcr); > + ifc_nand_ctrl->read_bytes = len; This driver really calls for a clean rework to transition to ->exec_op(). Guessing the amount of data to be read from ->cmdfunc() is broken and your patch series just shows how broken this is. What next? What if some NANDs have 4 or more copies of the param page? I'm still undecided whether I want to apply this patch. I guess having some guarantees that someone will actually work on implementing ->exec_op() in a near future would help me take this decision. Regards, Boris