Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp58688pxb; Tue, 28 Sep 2021 15:24:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0R86jfTWefUdHD8YYtyPAoFFqp4tgBG+eTUWAIejD+6Zkl5hrEVhDS3OFO4Ef1t1OSAZG X-Received: by 2002:a17:903:1d1:b0:13c:897c:c04b with SMTP id e17-20020a17090301d100b0013c897cc04bmr7274116plh.76.1632867899257; Tue, 28 Sep 2021 15:24:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632867899; cv=none; d=google.com; s=arc-20160816; b=hH6RNuJiCi1nYlPbgNNi994lrsGbNWkwF8nUf0qdgb6pbxlen/E1Rj/nN19v3cQNcA finjg7lwITKeFan/Z+EWVVGoGu9ZMyY03lg1sweR/qKmkn8Z2fYSJe/89ZvwmUqh43DN sFYxG2BjnKZ0i0/aCAJ2huS6Z1IzcJ8ddXQ1q0bBK6RGjkVELW49l88cMLKr+Ha2x5dM 3mfEQIf6T9lF3jcaLDiiLS4lqc29ndT6M5DAkdGjSaOMoMXWWyBLYkJ3tnaDp+tBibCZ eOBT+7oSM5yaZBpSthH4zCsRKkNYNJkLvB/WPzzGG6Efw1ITcaokgaNsBbj5NKlCQoRB yPlw== 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=6A6Wlz9I9ou2y0lja6T4LX7w69tn4AI1Dp54XWk+ako=; b=T9JQwuAdVgVZP7YsrcUfsITf5sCDFUdqc+hI3VtpjJF5zDLD2HFcF0LYG072xZdtKP 1Eh/vyivd5zUrREeizBQIouTTzaC7+YOycx53860wPKk/sLaWjPVK7WmRquTQo/O0KAl /EJI1iNUZHthM1iTDAYowYEGO1ZV9evBTXLkanImLbbKWG2tjlZcTskvYs0Q66n1i7nE WdWlG9jzv+vsEiGIycWuhLDN1oIugzV/QfSD65SseHxHLSP1Kx2+/RhTy0gLwU2uZrOx Vt42euLecXTJnPisH+8cR0/3bcIkis/tKtYUBQiddq57rBWP6TMDetgbxIxoK0Ci29i4 lKmQ== 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 t37si506796pgl.46.2021.09.28.15.24.46; Tue, 28 Sep 2021 15:24:59 -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 S243203AbhI1WYy (ORCPT + 99 others); Tue, 28 Sep 2021 18:24:54 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:46527 "EHLO relay11.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243118AbhI1WYq (ORCPT ); Tue, 28 Sep 2021 18:24:46 -0400 Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id AD91B100009; Tue, 28 Sep 2021 22:23:05 +0000 (UTC) From: Miquel Raynal To: Richard Weinberger , Vignesh Raghavendra , Tudor Ambarus Cc: , , Miquel Raynal , stable@vger.kernel.org Subject: [PATCH 8/9] mtd: rawnand: socrates: Keep the driver compatible with on-die ECC engines Date: Wed, 29 Sep 2021 00:22:47 +0200 Message-Id: <20210928222258.199726-9-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: b36bf0a0fe5d ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal --- drivers/mtd/nand/raw/socrates_nand.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/socrates_nand.c b/drivers/mtd/nand/raw/socrates_nand.c index 70f8305c9b6e..fb39cc7ebce0 100644 --- a/drivers/mtd/nand/raw/socrates_nand.c +++ b/drivers/mtd/nand/raw/socrates_nand.c @@ -119,9 +119,8 @@ static int socrates_nand_device_ready(struct nand_chip *nand_chip) static int socrates_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; @@ -175,6 +174,13 @@ static int socrates_nand_probe(struct platform_device *ofdev) /* TODO: I have no idea what real delay is. */ nand_chip->legacy.chip_delay = 20; /* 20us command delay time */ + /* + * 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. + */ + nand_chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + dev_set_drvdata(&ofdev->dev, host); res = nand_scan(nand_chip, 1); -- 2.27.0