Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4626157imm; Sun, 22 Jul 2018 01:53:24 -0700 (PDT) X-Google-Smtp-Source: AAOMgpe0/eTzVkE+hDgZAmDHBKtCzc6hFNwVynxXBGXFmq7L1YaaH17r/QndbE6Qhq1sd85D/PFK X-Received: by 2002:a17:902:46e:: with SMTP id 101-v6mr8549210ple.39.1532249604334; Sun, 22 Jul 2018 01:53:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532249604; cv=none; d=google.com; s=arc-20160816; b=jI0W88wruOTh2FMrQBeOmEIjGTzsVdnueh25M4CeFG8cVCFUG/otzGyDwgw8s9jnSi PUnoa2NcATH6U519EG6k1rn1vuKKzyo7Zd/pvO5B98O4yXQ6pHsg6Ra1xMbwyEc2Qgbp gxj+mH3Y3ztNg6nZiPCyp/H1yremK3vmTLLiBMNb5swtXURdhma3XbtKuV5TimaMsETD WRbvfj7c6vqNBhmjBVnWXh0BfTtrWgP87tz2mDS2x1ALK0A9u71aUnDNYEBOp89Pp7HE tb9ROsmvrC9LT3+McP++eM8t7mMJzUDr16u0jNaIdKjEVrRFgQd1oLhLH7l7EtqDYIPc PYMA== 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=9Xj3bvvykjo9Ubrj0wtJBD4Em/AOC9DlRhbrtkj+Eno=; b=BmizFKOd/f7Ln27cMOh50Y6NKD4aDIVYCPW5fnWePMHj10drh3LTwWEkFuSqN8RgsW Skh4GCrmkSRAMzHfI9Xg3RvZwQgw8AKDasQKT+4FhoIBgOaHYdOVju77U5gTJIxmG1+o pT/aJVqEDwxFhE43XOlnsqAt/9G8ZkEfzXjvQieVwxl5Bx9D7n+7uUJDphzNZWZOr2rS 3OYkhqde84x7qMHovk5i4mS2GIPkeNmTwurOKZ4kwqh3DNsbu0BzfIZ7WYl/4XbK+IXO 4rnUlW7JFC0htmAqdVphN5Bt9PeNSmIk0EgnfysNAqCptLMP3Kj3HPFhjPjkMaTF6GkU VTkg== 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 u195-v6si5977610pgb.443.2018.07.22.01.53.09; Sun, 22 Jul 2018 01:53:24 -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 S1728277AbeGVJsT (ORCPT + 99 others); Sun, 22 Jul 2018 05:48:19 -0400 Received: from mail.bootlin.com ([62.4.15.54]:59305 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728053AbeGVJsT (ORCPT ); Sun, 22 Jul 2018 05:48:19 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 9C11B207AD; Sun, 22 Jul 2018 10:52:19 +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, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (unknown [37.173.20.83]) by mail.bootlin.com (Postfix) with ESMTPSA id 97B0920737; Sun, 22 Jul 2018 10:52:17 +0200 (CEST) Date: Sun, 22 Jul 2018 10:52:16 +0200 From: Boris Brezillon To: Miquel Raynal Cc: Wenyou Yang , Josh Wu , Tudor Ambarus , Richard Weinberger , David Woodhouse , Brian Norris , Marek Vasut , Nicolas Ferre , Alexandre Belloni , Kamal Dasu , Masahiro Yamada , Han Xu , Harvey Hunt , Vladimir Zapolskiy , Sylvain Lemieux , Xiaolei Li , Matthias Brugger , Maxime Ripard , Chen-Yu Tsai , Marc Gonzalez , Mans Rullgard , Stefan Agner , linux-mtd@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, linux-mediatek@lists.infradead.org Subject: Re: [PATCH v4 29/35] mtd: rawnand: docg4: convert driver to nand_scan() Message-ID: <20180722105216.3c1418c0@bbrezillon> In-Reply-To: <20180720151527.16038-30-miquel.raynal@bootlin.com> References: <20180720151527.16038-1-miquel.raynal@bootlin.com> <20180720151527.16038-30-miquel.raynal@bootlin.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 On Fri, 20 Jul 2018 17:15:21 +0200 Miquel Raynal wrote: > Two helpers have been added to the core to make ECC-related > configuration between the detection phase and the final NAND scan. Use > these hooks and convert the driver to just use nand_scan() instead of > both nand_scan_ident() and nand_scan_tail(). > > Signed-off-by: Miquel Raynal > --- > drivers/mtd/nand/raw/docg4.c | 55 ++++++++++++++++++++++++++------------------ > 1 file changed, 32 insertions(+), 23 deletions(-) > > diff --git a/drivers/mtd/nand/raw/docg4.c b/drivers/mtd/nand/raw/docg4.c > index 4dccdfba6140..fec4353ff4ef 100644 > --- a/drivers/mtd/nand/raw/docg4.c > +++ b/drivers/mtd/nand/raw/docg4.c > @@ -1227,10 +1227,9 @@ static void __init init_mtd_structs(struct mtd_info *mtd) > * required within a nand driver because they are performed by the nand > * infrastructure code as part of nand_scan(). In this case they need > * to be initialized here because we skip call to nand_scan_ident() (the > - * first half of nand_scan()). The call to nand_scan_ident() is skipped > - * because for this device the chip id is not read in the manner of a > - * standard nand device. Unfortunately, nand_scan_ident() does other > - * things as well, such as call nand_set_defaults(). > + * first half of nand_scan()). The call to nand_scan_ident() could be > + * skipped because for this device the chip id is not read in the manner > + * of a standard nand device. > */ > > struct nand_chip *nand = mtd_to_nand(mtd); > @@ -1315,6 +1314,27 @@ static int __init read_id_reg(struct mtd_info *mtd) > > static char const *part_probes[] = { "cmdlinepart", "saftlpart", NULL }; > > +static int docg4_attach_chip(struct nand_chip *chip) > +{ > + struct mtd_info *mtd = nand_to_mtd(chip); > + struct docg4_priv *doc = (struct docg4_priv *)(chip + 1); > + > + init_mtd_structs(mtd); > + > + /* Initialize kernel BCH algorithm */ > + doc->bch = init_bch(DOCG4_M, DOCG4_T, DOCG4_PRIMITIVE_POLY); > + if (!doc->bch) > + return -EINVAL; > + You need a ->detach_chip() hook to free the BCH context, don't you? > + reset(mtd); > + > + return read_id_reg(mtd); > +} > + > +static const struct nand_controller_ops docg4_controller_ops = { > + .attach_chip = docg4_attach_chip, > +}; > + > static int __init probe_docg4(struct platform_device *pdev) > { > struct mtd_info *mtd; > @@ -1350,26 +1370,16 @@ static int __init probe_docg4(struct platform_device *pdev) > mtd->dev.parent = &pdev->dev; > doc->virtadr = virtadr; > doc->dev = dev; > - > - init_mtd_structs(mtd); > - > - /* initialize kernel bch algorithm */ > - doc->bch = init_bch(DOCG4_M, DOCG4_T, DOCG4_PRIMITIVE_POLY); > - if (doc->bch == NULL) { > - retval = -EINVAL; > - goto free_nand; > - } > - > platform_set_drvdata(pdev, doc); > > - reset(mtd); > - retval = read_id_reg(mtd); > - if (retval == -ENODEV) { > - dev_warn(dev, "No diskonchip G4 device found.\n"); > - goto free_bch; > - } > - > - retval = nand_scan_tail(mtd); > + /* > + * Asking for 0 chips is useless here but it warns the user that the use > + * of the nand_scan() function is a bit abused here because the > + * initialization is actually a bit specific and re-handled again in the > + * ->attach_chip() hook. It will probably leak some memory though. I don't get the last part. Is there really a memory leak? In that case we should find a solution to prevent that. > + */ > + nand->dummy_controller.ops = &docg4_controller_ops; > + retval = nand_scan(mtd, 0); > if (retval) > goto free_bch; > > @@ -1389,7 +1399,6 @@ static int __init probe_docg4(struct platform_device *pdev) > nand_cleanup(nand); > free_bch: > free_bch(doc->bch); This should be done in the ->detach_chip() hook. > -free_nand: > kfree(nand); > unmap: > iounmap(virtadr);