All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH 2/9] mtd: rawnand: au1550nd: Keep the driver compatible with on-die ECC engines
Date: Fri, 15 Oct 2021 12:32:28 +0200	[thread overview]
Message-ID: <20211015103228.949834-1-miquel.raynal@bootlin.com> (raw)
In-Reply-To: <20210928222258.199726-3-miquel.raynal@bootlin.com>

On Tue, 2021-09-28 at 22:22:41 UTC, Miquel Raynal wrote:
> 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: dbffc8ccdf3a ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.

Miquel

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH 2/9] mtd: rawnand: au1550nd: Keep the driver compatible with on-die ECC engines
Date: Fri, 15 Oct 2021 12:32:28 +0200	[thread overview]
Message-ID: <20211015103228.949834-1-miquel.raynal@bootlin.com> (raw)
In-Reply-To: <20210928222258.199726-3-miquel.raynal@bootlin.com>

On Tue, 2021-09-28 at 22:22:41 UTC, Miquel Raynal wrote:
> 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: dbffc8ccdf3a ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2021-10-15 10:32 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-28 22:22 [PATCH 0/9] Keep on-die ECC engines compatibility Miquel Raynal
2021-09-28 22:22 ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 1/9] mtd: rawnand: ams-delta: Keep the driver compatible with on-die ECC engines Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-10-15 10:32   ` Miquel Raynal
2021-10-15 10:32     ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 2/9] mtd: rawnand: au1550nd: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-10-15 10:32   ` Miquel Raynal [this message]
2021-10-15 10:32     ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 3/9] mtd: rawnand: gpio: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-10-15 10:32   ` Miquel Raynal
2021-10-15 10:32     ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 4/9] mtd: rawnand: mpc5121: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-10-15 10:32   ` Miquel Raynal
2021-10-15 10:32     ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 5/9] mtd: rawnand: orion: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-10-15 10:32   ` Miquel Raynal
2021-10-15 10:32     ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 6/9] mtd: rawnand: pasemi: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-10-15 10:32   ` Miquel Raynal
2021-10-15 10:32     ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 7/9] mtd: rawnand: plat_nand: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-10-15 10:32   ` Miquel Raynal
2021-10-15 10:32     ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 8/9] mtd: rawnand: socrates: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-10-15 10:32   ` Miquel Raynal
2021-10-15 10:32     ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 9/9] mtd: rawnand: xway: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-10-04 15:40   ` Miquel Raynal
2021-10-04 15:40     ` Miquel Raynal
2021-10-04 16:21     ` Jan Hoffmann
2021-10-04 16:21       ` Jan Hoffmann
2021-10-15 10:31   ` Miquel Raynal
2021-10-15 10:31     ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 0/9] Keep on-die ECC engines compatibility Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 1/9] mtd: rawnand: ams-delta: Keep the driver compatible with on-die ECC engines Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 2/9] mtd: rawnand: au1550nd: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 3/9] mtd: rawnand: gpio: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 4/9] mtd: rawnand: mpc5121: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 5/9] mtd: rawnand: orion: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 6/9] mtd: rawnand: pasemi: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 7/9] mtd: rawnand: plat_nand: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 8/9] mtd: rawnand: socrates: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal
2021-09-28 22:22 ` [PATCH 9/9] mtd: rawnand: xway: " Miquel Raynal
2021-09-28 22:22   ` Miquel Raynal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211015103228.949834-1-miquel.raynal@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=stable@vger.kernel.org \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.