All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Jan Hoffmann <jan@3e8.eu>
Cc: Daniel Kestrel <kestrelseventyfour@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mtd: rawnand: xway: No hardcoded ECC engine, use device tree setting
Date: Mon, 27 Sep 2021 18:31:50 +0200	[thread overview]
Message-ID: <20210927183150.4be87140@xps13> (raw)
In-Reply-To: <14eb0cb7-b0af-87bf-b9a5-3e35eeb43f54@3e8.eu>

Hi Jan,

Sorry for the delay, I had to rethink about the problem first.

jan@3e8.eu wrote on Sat, 18 Sep 2021 23:26:48 +0200:

> Hi Miquèl,
> 
> > Yes this was my understanding, that only software ECC engine was
> > supported. The mainline driver shows absolutely no signs of hardware
> > ECC engine support.
> > 
> > Perhaps however you mean that on-die ECC engine are not supported
> > anymore because of the engine_type being set in attach_chip()?  
> 
> Yes, this is exactly the issue.
> 
> > If yes then indeed there is something to do, perhaps checking if an
> > engine has been already set is enough? You can try something like:
> > 
> > if (engine_type == unknown)
> > 	engine_type = soft;  
> 
> Checking for NAND_ECC_ENGINE_TYPE_INVALID doesn't work, as the engine
> type is already set to NAND_ECC_ENGINE_TYPE_ON_HOST by rawnand_dt_init.
> The code there seems to expect that chip->ecc.engine_type contains the
> default value, which is no longer the case after commit 525914b5bd8
> ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()").

This is indeed an issue and should be fixed. However the solution is I
think already available in the raw NAND core (but I had to dig into the
code again to remember how I wanted to handle this).

> The following in attach_chip works:
> 
> if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_ON_HOST)
> 	chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;

If you look at the rawnand_dt_init() function [1] the logic is:

Is the user configuration (DT) valid ? if yes take it.
Is the NAND controller driver setting a default mode? if yes take it.
Otherwise take the raw NAND subsystem default: ON_HOST.

This logic happens very soon in the init process so the default mode
for the driver should be provided before the nand_scan() call.

So what I propose is:
- in the driver probe: set the default to software ECC
- in the attach() hook: drop the line setting the engine_type to SOFT.

Please check the below diff and tell me if it works for you. I'll then
propose a wider series fixing the other drivers as well.

> However, this will also silently use the software ECC engine if anyone
> actually configures the on-host hardware ECC engine in the device tree
> (which is of course unsupported for xway).
> 
> Thanks,
> Jan


[1] https://elixir.bootlin.com/linux/latest/source/drivers/mtd/nand/raw/nand_base.c#L5328

Thanks,
Miquèl

---
diff --git a/drivers/mtd/nand/raw/xway_nand.c b/drivers/mtd/nand/raw/xway_nand.c
index 26751976e502..d9e167dbb717 100644
--- a/drivers/mtd/nand/raw/xway_nand.c
+++ b/drivers/mtd/nand/raw/xway_nand.c
@@ -148,9 +148,8 @@ static void xway_write_buf(struct nand_chip *chip, const u_char *buf, int len)
 
 static int xway_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;
@@ -219,6 +218,14 @@ static int xway_nand_probe(struct platform_device *pdev)
                    | NAND_CON_SE_P | NAND_CON_WP_P | NAND_CON_PRE_P
                    | cs_flag, EBU_NAND_CON);
 
+       /*
+        * This controller has no hardware ECC engine and the driver assumes
+        * that the default ECC engine should be TYPE_SOFT. Set ->engine_type
+        * before the NAND registration in order to provide a default value.
+        */
+       data->chip.ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
+
+
        /* Scan to find existence of the device */
        err = nand_scan(&data->chip, 1);
        if (err)

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Jan Hoffmann <jan@3e8.eu>
Cc: Daniel Kestrel <kestrelseventyfour@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mtd: rawnand: xway: No hardcoded ECC engine, use device tree setting
Date: Mon, 27 Sep 2021 18:31:50 +0200	[thread overview]
Message-ID: <20210927183150.4be87140@xps13> (raw)
In-Reply-To: <14eb0cb7-b0af-87bf-b9a5-3e35eeb43f54@3e8.eu>

Hi Jan,

Sorry for the delay, I had to rethink about the problem first.

jan@3e8.eu wrote on Sat, 18 Sep 2021 23:26:48 +0200:

> Hi Miquèl,
> 
> > Yes this was my understanding, that only software ECC engine was
> > supported. The mainline driver shows absolutely no signs of hardware
> > ECC engine support.
> > 
> > Perhaps however you mean that on-die ECC engine are not supported
> > anymore because of the engine_type being set in attach_chip()?  
> 
> Yes, this is exactly the issue.
> 
> > If yes then indeed there is something to do, perhaps checking if an
> > engine has been already set is enough? You can try something like:
> > 
> > if (engine_type == unknown)
> > 	engine_type = soft;  
> 
> Checking for NAND_ECC_ENGINE_TYPE_INVALID doesn't work, as the engine
> type is already set to NAND_ECC_ENGINE_TYPE_ON_HOST by rawnand_dt_init.
> The code there seems to expect that chip->ecc.engine_type contains the
> default value, which is no longer the case after commit 525914b5bd8
> ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()").

This is indeed an issue and should be fixed. However the solution is I
think already available in the raw NAND core (but I had to dig into the
code again to remember how I wanted to handle this).

> The following in attach_chip works:
> 
> if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_ON_HOST)
> 	chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;

If you look at the rawnand_dt_init() function [1] the logic is:

Is the user configuration (DT) valid ? if yes take it.
Is the NAND controller driver setting a default mode? if yes take it.
Otherwise take the raw NAND subsystem default: ON_HOST.

This logic happens very soon in the init process so the default mode
for the driver should be provided before the nand_scan() call.

So what I propose is:
- in the driver probe: set the default to software ECC
- in the attach() hook: drop the line setting the engine_type to SOFT.

Please check the below diff and tell me if it works for you. I'll then
propose a wider series fixing the other drivers as well.

> However, this will also silently use the software ECC engine if anyone
> actually configures the on-host hardware ECC engine in the device tree
> (which is of course unsupported for xway).
> 
> Thanks,
> Jan


[1] https://elixir.bootlin.com/linux/latest/source/drivers/mtd/nand/raw/nand_base.c#L5328

Thanks,
Miquèl

---
diff --git a/drivers/mtd/nand/raw/xway_nand.c b/drivers/mtd/nand/raw/xway_nand.c
index 26751976e502..d9e167dbb717 100644
--- a/drivers/mtd/nand/raw/xway_nand.c
+++ b/drivers/mtd/nand/raw/xway_nand.c
@@ -148,9 +148,8 @@ static void xway_write_buf(struct nand_chip *chip, const u_char *buf, int len)
 
 static int xway_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;
@@ -219,6 +218,14 @@ static int xway_nand_probe(struct platform_device *pdev)
                    | NAND_CON_SE_P | NAND_CON_WP_P | NAND_CON_PRE_P
                    | cs_flag, EBU_NAND_CON);
 
+       /*
+        * This controller has no hardware ECC engine and the driver assumes
+        * that the default ECC engine should be TYPE_SOFT. Set ->engine_type
+        * before the NAND registration in order to provide a default value.
+        */
+       data->chip.ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
+
+
        /* Scan to find existence of the device */
        err = nand_scan(&data->chip, 1);
        if (err)

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

  reply	other threads:[~2021-09-27 16:31 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-08  7:26 [PATCH v2] mtd: rawnand: xway: No hardcoded ECC engine, use device tree setting Daniel Kestrel
2021-08-08  7:26 ` Daniel Kestrel
2021-08-16  7:31 ` Miquel Raynal
2021-08-16  7:31   ` Miquel Raynal
2021-08-19  7:21   ` Kestrel seventyfour
2021-08-19  7:21     ` Kestrel seventyfour
2021-08-19  8:03     ` Miquel Raynal
2021-08-19  8:03       ` Miquel Raynal
2021-08-23 11:19       ` Kestrel seventyfour
2021-08-23 11:19         ` Kestrel seventyfour
2021-08-23 15:24         ` Miquel Raynal
2021-08-23 15:24           ` Miquel Raynal
2021-08-24  7:15           ` Kestrel seventyfour
2021-08-24  7:15             ` Kestrel seventyfour
2021-08-24 17:22             ` Miquel Raynal
2021-08-24 17:22               ` Miquel Raynal
2021-08-25  8:47               ` Kestrel seventyfour
2021-08-25  8:47                 ` Kestrel seventyfour
2021-08-25  8:51                 ` Miquel Raynal
2021-08-25  8:51                   ` Miquel Raynal
2021-08-25 14:07                   ` Kestrel seventyfour
2021-08-25 14:07                     ` Kestrel seventyfour
2021-08-25 15:31                     ` Miquel Raynal
2021-08-25 15:31                       ` Miquel Raynal
2021-08-26  5:27                       ` Kestrel seventyfour
2021-08-26  5:27                         ` Kestrel seventyfour
2021-09-16 19:38 ` Jan Hoffmann
2021-09-16 19:38   ` Jan Hoffmann
2021-09-17 17:01   ` Miquel Raynal
2021-09-17 17:01     ` Miquel Raynal
2021-09-17 17:45     ` Jan Hoffmann
2021-09-17 17:45       ` Jan Hoffmann
2021-09-17 19:32       ` Miquel Raynal
2021-09-17 19:32         ` Miquel Raynal
2021-09-18 21:26         ` Jan Hoffmann
2021-09-18 21:26           ` Jan Hoffmann
2021-09-27 16:31           ` Miquel Raynal [this message]
2021-09-27 16:31             ` Miquel Raynal
2021-09-27 20:32             ` Jan Hoffmann
2021-09-27 20:32               ` Jan Hoffmann
2021-09-28  8:49               ` Miquel Raynal
2021-09-28  8:49                 ` 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=20210927183150.4be87140@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=jan@3e8.eu \
    --cc=kestrelseventyfour@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --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.