Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp59253pxb; Tue, 28 Sep 2021 15:25:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzdsgspJ/mSPmKx9paloyFBd7heoYwr2z8Qhdd1JCSjEPDLcZ7mwil7DEgxqRWA15Ui/uCd X-Received: by 2002:a17:906:d1d1:: with SMTP id bs17mr9388831ejb.198.1632867948952; Tue, 28 Sep 2021 15:25:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632867948; cv=none; d=google.com; s=arc-20160816; b=zJBIdWO/5dTZh5llYlWT3LKnYzSKzGy/rzxg+yqXlloW486/qYBsjgclmJyfvs4SR3 +HDrxTKT/hKpVQCcSA+A9nsDLKIwuM3/NS1jrz5AkNWVYJxai+6vDdMHSIlTj5pMkIzs DMdroEQMVGdpwLDq3rWHK1LTZF3beWNmIycQyNU3T5aqBd367NwtPyWkphlyzapSLZJE 1g2rBmK7+XMtSzkyzu+lZxR7b6SQrzsLZaMOnqmCWZM1rRdGcQ/IVVKkc4NRdS5c9Bdj MJ9V1UvaKbaBCR1tr9xLvPzuMcn75f/6eJW/JryYk77L6BJk4L0Lhk9QHeSfHogRe6+D wpjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=eMI01I4fkhOn4PuQy5XukeDX0STsP9nnVHh8Cj02Yq0=; b=bWKTQHFb2QuwKs+XLUfYAF1uRUqJbn7c6ecstA9dMmo+usdhZWJkqxJCJmbhqHNQyp 59rsQlxIFpzNSSuqJ05+pwOmj+v3T09RZHSEnIDDH/ZMj8UMKC4mObzCcvnCfDH5tKka 31ZCB5mkwSqyAJUgGVeRK7h0G7tgWtqyTDH64dJtbG1/ORrdp2olHRE1IJc2Z/pFe2Fn SePt6T4F/JII62aDq39qrWUyEeL9L0jgxKHEmWaoJOpNfJpy2I82zgPYiP5LzYqO7DN3 NnakCrqFQ1NGvGTAl1HmY38dYvch2jGQEFckfs5cGfA8b22ks0FTD5uNislJOGc1EKOt 1tXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b10si338418edf.629.2021.09.28.15.25.25; Tue, 28 Sep 2021 15:25:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243267AbhI1WZD (ORCPT + 99 others); Tue, 28 Sep 2021 18:25:03 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:56823 "EHLO relay11.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243173AbhI1WYw (ORCPT ); Tue, 28 Sep 2021 18:24:52 -0400 Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id CFF70100009; Tue, 28 Sep 2021 22:23:10 +0000 (UTC) From: Miquel Raynal To: Richard Weinberger , Vignesh Raghavendra , Tudor Ambarus Cc: , , Miquel Raynal , stable@vger.kernel.org Subject: [PATCH 4/9] mtd: rawnand: mpc5121: Keep the driver compatible with on-die ECC engines Date: Wed, 29 Sep 2021 00:22:53 +0200 Message-Id: <20210928222258.199726-15-miquel.raynal@bootlin.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20210928222258.199726-1-miquel.raynal@bootlin.com> References: <20210928222258.199726-1-miquel.raynal@bootlin.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 6dd09f775b72 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal --- drivers/mtd/nand/raw/mpc5121_nfc.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/mpc5121_nfc.c b/drivers/mtd/nand/raw/mpc5121_nfc.c index bcd4a556c959..cb293c50acb8 100644 --- a/drivers/mtd/nand/raw/mpc5121_nfc.c +++ b/drivers/mtd/nand/raw/mpc5121_nfc.c @@ -605,9 +605,8 @@ static void mpc5121_nfc_free(struct device *dev, struct mtd_info *mtd) static int mpc5121_nfc_attach_chip(struct nand_chip *chip) { - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - - if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && + chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; @@ -772,6 +771,13 @@ static int mpc5121_nfc_probe(struct platform_device *op) goto error; } + /* + * This driver assumes that the default ECC engine should be TYPE_SOFT. + * Set ->engine_type before registering the NAND devices in order to + * provide a driver specific default value. + */ + chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + /* Detect NAND chips */ retval = nand_scan(chip, be32_to_cpup(chips_no)); if (retval) { -- 2.27.0