Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp3447159pxb; Mon, 30 Aug 2021 02:22:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznjXyHwgtMUmdUF249pgNzfu8Ej4dg0GziKI/h1clYgKIHv/rT4aivk4JsENxnzXZdI99S X-Received: by 2002:a17:907:9604:: with SMTP id gb4mr24613985ejc.142.1630315362486; Mon, 30 Aug 2021 02:22:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630315362; cv=none; d=google.com; s=arc-20160816; b=zm2jXNNcnP/EF0bI52TckyHyyta0hRy2VXnxfZao7Qpyjf/izKylik27/nhR+s5DDM xUTzq0tHD3n4ZHSP3LH8s8tuKb5kXz50sD5UspnsCPCvvFbD9s/viYh9UV+9McRsMMJb JqdqODWAIUldgwTaOEHUG5mVyfBGDadfkuYqYBQ2tLk4J6CQSW/SoAB8RwJ0SfOEJcoC sUaxHGs1dwG4WShC2viVuwKwNFrMwDIFa6Sno4vSkXbhN5wN09HJPilo4XBu6TURWCfS Z3m4i7I9MeqpJKPOI2QPScMlbqXsuqq/M0ZFgm0eduwgEYZtizbky1HbB1miPy3/BgHX 1sEw== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=a9RcEfZJDZuAHSjEXx54gjADTLnHgcoZF/J7n1NcjKI=; b=KeTQOUDU8fyrGtUk3wF4wzxJ5UGGyJ2XFf33F4Vests3OlWK++x2O2q7G0ya77452p RTzFXwyGI8RsgaeoasdvHlQQnJMjWgAKrw7qEXaO9/wp8mExNk+/4vxuUup1uzisbl7X AHhj64KFZOxjTtx5TAvudelCk6+NY0AmFaBpK5MNs06OtzG9LjR+QMQ8u3ubfTNpxSZc wKJ9EDcHpNkockwDswBwV8AewBv8pFFpDtoHlsTj+KSwAic0fEzQCTpO6OVOriCFuud+ KHS2dkRt030rgs+mKOyIYQLf3Hj2PahaUpESXT+++oEoK9tvdKGaLZ3k07BTZFBl3gjv 7mzQ== 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 h19si17519265ede.498.2021.08.30.02.22.18; Mon, 30 Aug 2021 02:22:42 -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 S235461AbhH3JV4 convert rfc822-to-8bit (ORCPT + 99 others); Mon, 30 Aug 2021 05:21:56 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:47119 "EHLO relay1-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235340AbhH3JV4 (ORCPT ); Mon, 30 Aug 2021 05:21:56 -0400 Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 2E0A5240007; Mon, 30 Aug 2021 09:20:59 +0000 (UTC) Date: Mon, 30 Aug 2021 11:20:57 +0200 From: Miquel Raynal To: Frieder Schrempf Cc: Frieder Schrempf , stable@vger.kernel.org, voice INTER connect GmbH , Alexander Lobakin , Felix Fietkau , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Richard Weinberger , YouChing Lin Subject: Re: [RESEND PATCH 5.10.x] mtd: spinand: Fix incorrect parameters for on-die ECC Message-ID: <20210830112057.202355ef@xps13> In-Reply-To: <35e30f69-c6f8-ac9c-2314-f566190ac2cb@kontron.de> References: <20210830072108.13770-1-frieder@fris.de> <20210830104122.58f9cdaf@xps13> <35e30f69-c6f8-ac9c-2314-f566190ac2cb@kontron.de> Organization: Bootlin X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-pc-linux-gnu) 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 Hi Frieder, Frieder Schrempf wrote on Mon, 30 Aug 2021 11:18:50 +0200: > On 30.08.21 10:41, Miquel Raynal wrote: > > Hi Frieder, > > > > Frieder Schrempf wrote on Mon, 30 Aug 2021 09:21:07 > > +0200: > > > >> From: Frieder Schrempf > >> > >> The new generic NAND ECC framework stores the configuration and requirements > >> in separate places since commit 93ef92f6f422 (" mtd: nand: Use the new generic ECC object "). > >> In 5.10.x The SPI NAND layer still uses only the requirements to track the ECC > >> properties. This mismatch leads to values of zero being used for ECC strength > >> and step_size in the SPI NAND layer wherever nanddev_get_ecc_conf() is used and > >> therefore breaks the SPI NAND on-die ECC support in 5.10.x. > >> > >> By using nanddev_get_ecc_requirements() instead of nanddev_get_ecc_conf() for > >> SPI NAND, we make sure that the correct parameters for the detected chip are > >> used. In later versions (5.11.x) this is fixed anyway with the implementation > >> of the SPI NAND on-die ECC engine. > >> > >> Cc: stable@vger.kernel.org # 5.10.x > >> Reported-by: voice INTER connect GmbH > >> Signed-off-by: Frieder Schrempf > > > > Why not just reverting 9a333a72c1d0 ("mtd: spinand: Use > > nanddev_get_ecc_conf() when relevant")? I think using this "new" > > nanddev_get_ecc_requirements() helper because it fits the purpose even > > if it is wrong [1] doesn't bring the right information. I know it is > > strictly equivalent but I would personally prefer keeping the old > > writing "nand->eccreq.xxxx". > > I think reverting 9a333a72c1d0 to use nand->eccreq.xxxx doesn't work as the eccreq member has already been removed in 93ef92f6f422 ("mtd: nand: Use the new generic ECC object"). So we would need to revert this commit, too. That would work for the SPI NAND layer, but might have implications on RAW NAND as it already uses the new generic ECC object with 'ctx.conf' and 'requirements'. At least I can't tell how this would affect the RAW NAND layer. I missed that, you're right. Acked-by: Miquel Raynal > > > > > [1] We don't want the requirements but the actual current configuration > > here, which was the primary purpose of the initial patch which ended > > being a mistake at that point in time because the SPI-NAND core was not > > ready yet. > > > > Thanks, > > Miquèl Thanks, Miquèl