From: Boris Brezillon <boris.brezillon@collabora.com> To: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Tudor Ambarus <Tudor.Ambarus@microchip.com>, <linux-mtd@lists.infradead.org>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, <devicetree@vger.kernel.org> Subject: Re: [RESEND v5 09/21] mtd: rawnand: Create a new enumeration to describe properly ECC types Date: Wed, 27 May 2020 00:55:18 +0200 [thread overview] Message-ID: <20200527005518.2d780ecc@collabora.com> (raw) In-Reply-To: <20200526195633.11543-10-miquel.raynal@bootlin.com> On Tue, 26 May 2020 21:56:21 +0200 Miquel Raynal <miquel.raynal@bootlin.com> wrote: > Now that the misleading mix between ECC engine type and OOB placement > has been addressed, add a new enumeration to properly define ECC types > (also called provider or mode). Let's pick a name and stick to it. I think "ECC provider type" or "ECC engine type" are good names. > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> > --- > drivers/mtd/nand/raw/nand_base.c | 7 +++++++ > include/linux/mtd/rawnand.h | 16 ++++++++++++++++ > 2 files changed, 23 insertions(+) > > diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c > index 515cd4681660..5c6ab5b93270 100644 > --- a/drivers/mtd/nand/raw/nand_base.c > +++ b/drivers/mtd/nand/raw/nand_base.c > @@ -5018,6 +5018,13 @@ static const char * const nand_ecc_modes[] = { > [NAND_ECC_ON_DIE] = "on-die", > }; > > +static const char * const nand_ecc_engine_providers[] = { I'd rename that one nand_ecc_engine_types or nand_ecc_provider_types. > + [NAND_ECC_ENGINE_NONE] = "none", > + [NAND_ECC_ENGINE_SOFT] = "soft", > + [NAND_ECC_ENGINE_CONTROLLER] = "hw", > + [NAND_ECC_ENGINE_ON_DIE] = "on-die", > +}; > + > static const char * const nand_ecc_placement[] = { > [NAND_ECC_PLACEMENT_INTERLEAVED] = "interleaved", > }; > diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h > index dc909fb977c7..a2078c5f3d21 100644 > --- a/include/linux/mtd/rawnand.h > +++ b/include/linux/mtd/rawnand.h > @@ -92,6 +92,22 @@ enum nand_ecc_mode { > NAND_ECC_ON_DIE, > }; > > +/** > + * enum nand_ecc_engine_type - NAND ECC engine type/provider > + * @NAND_ECC_ENGINE_INVALID: Invalid value > + * @NAND_ECC_ENGINE_NONE: No ECC correction > + * @NAND_ECC_ENGINE_SOFT: Software ECC correction > + * @NAND_ECC_ENGINE_CONTROLLER: Hardware controller ECC correction > + * @NAND_ECC_ENGINE_ON_DIE: On chip hardware ECC correction > + */ > +enum nand_ecc_engine_type { Looks like you went for ecc_engine_type here, so let's stick to that. > + NAND_ECC_ENGINE_INVALID, NAND_ECC_ENGINE_TYPE_xxx > + NAND_ECC_ENGINE_NONE, Do we really need a value for NONE? I'd expect the engine type to be applicable to NAND that have some sort of ECC engine connected to them. > + NAND_ECC_ENGINE_SOFT, > + NAND_ECC_ENGINE_CONTROLLER, > + NAND_ECC_ENGINE_ON_DIE, > +}; > + > /** > * enum nand_ecc_placement - NAND ECC placement > * @NAND_ECC_PLACEMENT_FREE: The driver can decide where to put ECC bytes.
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com> To: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Mark Rutland <mark.rutland@arm.com>, devicetree@vger.kernel.org, Vignesh Raghavendra <vigneshr@ti.com>, Tudor Ambarus <Tudor.Ambarus@microchip.com>, Richard Weinberger <richard@nod.at>, Rob Herring <robh+dt@kernel.org>, linux-mtd@lists.infradead.org Subject: Re: [RESEND v5 09/21] mtd: rawnand: Create a new enumeration to describe properly ECC types Date: Wed, 27 May 2020 00:55:18 +0200 [thread overview] Message-ID: <20200527005518.2d780ecc@collabora.com> (raw) In-Reply-To: <20200526195633.11543-10-miquel.raynal@bootlin.com> On Tue, 26 May 2020 21:56:21 +0200 Miquel Raynal <miquel.raynal@bootlin.com> wrote: > Now that the misleading mix between ECC engine type and OOB placement > has been addressed, add a new enumeration to properly define ECC types > (also called provider or mode). Let's pick a name and stick to it. I think "ECC provider type" or "ECC engine type" are good names. > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> > --- > drivers/mtd/nand/raw/nand_base.c | 7 +++++++ > include/linux/mtd/rawnand.h | 16 ++++++++++++++++ > 2 files changed, 23 insertions(+) > > diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c > index 515cd4681660..5c6ab5b93270 100644 > --- a/drivers/mtd/nand/raw/nand_base.c > +++ b/drivers/mtd/nand/raw/nand_base.c > @@ -5018,6 +5018,13 @@ static const char * const nand_ecc_modes[] = { > [NAND_ECC_ON_DIE] = "on-die", > }; > > +static const char * const nand_ecc_engine_providers[] = { I'd rename that one nand_ecc_engine_types or nand_ecc_provider_types. > + [NAND_ECC_ENGINE_NONE] = "none", > + [NAND_ECC_ENGINE_SOFT] = "soft", > + [NAND_ECC_ENGINE_CONTROLLER] = "hw", > + [NAND_ECC_ENGINE_ON_DIE] = "on-die", > +}; > + > static const char * const nand_ecc_placement[] = { > [NAND_ECC_PLACEMENT_INTERLEAVED] = "interleaved", > }; > diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h > index dc909fb977c7..a2078c5f3d21 100644 > --- a/include/linux/mtd/rawnand.h > +++ b/include/linux/mtd/rawnand.h > @@ -92,6 +92,22 @@ enum nand_ecc_mode { > NAND_ECC_ON_DIE, > }; > > +/** > + * enum nand_ecc_engine_type - NAND ECC engine type/provider > + * @NAND_ECC_ENGINE_INVALID: Invalid value > + * @NAND_ECC_ENGINE_NONE: No ECC correction > + * @NAND_ECC_ENGINE_SOFT: Software ECC correction > + * @NAND_ECC_ENGINE_CONTROLLER: Hardware controller ECC correction > + * @NAND_ECC_ENGINE_ON_DIE: On chip hardware ECC correction > + */ > +enum nand_ecc_engine_type { Looks like you went for ecc_engine_type here, so let's stick to that. > + NAND_ECC_ENGINE_INVALID, NAND_ECC_ENGINE_TYPE_xxx > + NAND_ECC_ENGINE_NONE, Do we really need a value for NONE? I'd expect the engine type to be applicable to NAND that have some sort of ECC engine connected to them. > + NAND_ECC_ENGINE_SOFT, > + NAND_ECC_ENGINE_CONTROLLER, > + NAND_ECC_ENGINE_ON_DIE, > +}; > + > /** > * enum nand_ecc_placement - NAND ECC placement > * @NAND_ECC_PLACEMENT_FREE: The driver can decide where to put ECC bytes. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-05-26 22:55 UTC|newest] Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-26 19:56 [RESEND v5 00/21] Introduce the generic ECC engine abstraction Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 01/21] mtd: Fix typo in mtd_ooblayout_set_databytes() description Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-27 14:11 ` Miquel Raynal 2020-05-27 14:11 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 02/21] mtd: rawnand: Avoid a typedef Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-27 14:11 ` Miquel Raynal 2020-05-27 14:11 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 03/21] mtd: rawnand: Drop OOB_FIRST placement scheme Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 22:46 ` Boris Brezillon 2020-05-26 22:46 ` Boris Brezillon 2020-05-27 14:11 ` Miquel Raynal 2020-05-27 14:11 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 04/21] dt-bindings: mtd: Deprecate OOB_FIRST mode Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 22:42 ` Boris Brezillon 2020-05-26 22:42 ` Boris Brezillon 2020-05-27 14:11 ` Miquel Raynal 2020-05-27 14:11 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 05/21] mtd: rawnand: Return an enum from of_get_nand_ecc_algo() Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 22:41 ` Boris Brezillon 2020-05-26 22:41 ` Boris Brezillon 2020-05-27 14:11 ` Miquel Raynal 2020-05-27 14:11 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 06/21] mtd: rawnand: Add an invalid ECC mode to discriminate with valid ones Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-27 14:11 ` Miquel Raynal 2020-05-27 14:11 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 07/21] mtd: rawnand: Create a new enumeration to describe OOB placement Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 22:39 ` Boris Brezillon 2020-05-26 22:39 ` Boris Brezillon 2020-05-27 8:00 ` Miquel Raynal 2020-05-27 8:00 ` Miquel Raynal 2020-05-27 8:22 ` Boris Brezillon 2020-05-27 8:22 ` Boris Brezillon 2020-05-26 19:56 ` [RESEND v5 08/21] mtd: rawnand: Separate the ECC engine type and the " Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 09/21] mtd: rawnand: Create a new enumeration to describe properly ECC types Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 22:55 ` Boris Brezillon [this message] 2020-05-26 22:55 ` Boris Brezillon 2020-05-26 23:21 ` Boris Brezillon 2020-05-26 23:21 ` Boris Brezillon 2020-05-27 8:21 ` Miquel Raynal 2020-05-27 8:21 ` Miquel Raynal 2020-05-26 22:59 ` Boris Brezillon 2020-05-26 22:59 ` Boris Brezillon 2020-05-27 8:33 ` Miquel Raynal 2020-05-27 8:33 ` Miquel Raynal 2020-05-27 8:44 ` Boris Brezillon 2020-05-27 8:44 ` Boris Brezillon 2020-05-27 8:50 ` Boris Brezillon 2020-05-27 8:50 ` Boris Brezillon 2020-05-26 19:56 ` [RESEND v5 10/21] mtd: rawnand: Create a helper to retrieve the ECC placement Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 11/21] mtd: rawnand: Use the new ECC engine type enumeration Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 12/21] mtd: rawnand: Deprecate nand-ecc-mode in favor of nand-ecc-provider Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 23:03 ` Boris Brezillon 2020-05-26 23:03 ` Boris Brezillon 2020-05-27 8:42 ` Miquel Raynal 2020-05-27 8:42 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 13/21] mtd: rawnand: Drop the legacy ECC type enumeration Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 14/21] dt-bindings: mtd: Add the nand-ecc-placement property Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 23:08 ` Boris Brezillon 2020-05-26 23:08 ` Boris Brezillon 2020-05-26 23:10 ` Rob Herring 2020-05-26 23:10 ` Rob Herring 2020-05-26 19:56 ` [RESEND v5 15/21] dt-bindings: mtd: Deprecate hw_syndrome from the ECC modes Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 23:09 ` Boris Brezillon 2020-05-26 23:09 ` Boris Brezillon 2020-05-26 19:56 ` [RESEND v5 16/21] dt-bindings: mtd: Deprecate the nand-ecc-mode property Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 23:12 ` Boris Brezillon 2020-05-26 23:12 ` Boris Brezillon 2020-05-26 19:56 ` [RESEND v5 17/21] mtd: nand: Move nand_device forward declaration to the top Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 18/21] mtd: nand: Add an extra level in the Kconfig hierarchy Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 19/21] mtd: nand: Drop useless 'depends on' in Kconfig Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 20/21] mtd: nand: Add a NAND page I/O request type Miquel Raynal 2020-05-26 19:56 ` Miquel Raynal 2020-05-26 19:56 ` [RESEND v5 21/21] mtd: nand: Rename a core structure Miquel Raynal 2020-05-26 19:56 ` 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=20200527005518.2d780ecc@collabora.com \ --to=boris.brezillon@collabora.com \ --cc=Tudor.Ambarus@microchip.com \ --cc=devicetree@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=mark.rutland@arm.com \ --cc=miquel.raynal@bootlin.com \ --cc=richard@nod.at \ --cc=robh+dt@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: linkBe 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.