From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Mason Yang <masonccyang@mxic.com.tw>, Vignesh R <vigneshr@ti.com>,
Tudor Ambarus <Tudor.Ambarus@microchip.com>,
Julien Su <juliensu@mxic.com.tw>,
Richard Weinberger <richard@nod.at>,
Boris Brezillon <bbrezillon@kernel.org>,
Schrempf Frieder <frieder.schrempf@kontron.de>,
Marek Vasut <marek.vasut@gmail.com>,
linux-mtd@lists.infradead.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 03/27] mtd: nand: Introduce the ECC engine abstraction
Date: Wed, 27 Feb 2019 15:19:57 +0100 [thread overview]
Message-ID: <20190227151957.4de6ff32@xps13> (raw)
In-Reply-To: <20190227150633.7d8f5c5c@collabora.com>
Hi Boris,
Boris Brezillon <boris.brezillon@collabora.com> wrote on Wed, 27 Feb
2019 15:06:33 +0100:
> On Wed, 27 Feb 2019 14:56:07 +0100
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Hi Boris,
> >
> > Boris Brezillon <bbrezillon@kernel.org> wrote on Mon, 25 Feb 2019
> > 19:55:43 +0100:
> >
> > > On Thu, 21 Feb 2019 11:01:52 +0100
> > > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > > +
> > > > +/**
> > > > + * struct nand_ecc_engine_ops - Generic ECC engine operations
> > > > + *
> > > > + * @init_ctx: given a desired user configuration for the pointed NAND device,
> > > > + * requests the ECC engine driver to setup a configuration with
> > > > + * values it supports.
> > > > + * @cleanup_ctx: clean the context initialized by @init_ctx.
> > > > + * @prepare_io_req: is called before reading/writing a page to prepare the I/O
> > > > + * request to be performed with ECC correction.
> > > > + * @finish_io_req: is called after reading/writing a page to terminate the I/O
> > > > + * request and ensure proper ECC correction.
> > > > + */
> > > > +struct nand_ecc_engine_ops {
> > >
> > > We might want to add a
> > >
> > > void (*put_engine)(struct nand_ecc_engine *engine);
> > >
> > > here if we want the nanddev cleanup path to be generic.
> > > This hook would be implemented by drivers where the ECC engine object is
> > > refcounted (typically the case for HW ECC engines shared by the raw NAND
> > > controller and the SPI controller).
> > >
> > > Alternatively, you can just add one nand_put_xxx_ecc_engine() func per
> > > engine class (SW, ondie and HW).
> >
> > Can't this be handled in the init/cleanup_ctx() path directly?
>
> You really have to get the reference before init_ctx() otherwise the
> engine might disappear between your get() and init() call, and, to keep
> things symmetric, I think it's best to handle the put() outside the
> cleanup_ctx() path.
>
> >
> > Furthermore if this is just a hook to do reference counting.
>
> Well, what this put() does depends on the class of engine. For SW and
> on-die ECC it can be a NOOP (that's true only if you keep the approach
> where you have a single instance shared by everyone for SW-based ECC
> engines).
> For HW-controller-side ECC engines, you'll have to call device_get() on
> the parent device in your nand_get_hw_ecc_engine() function while you
> hold the lock protecting the ECC engine list. And device_put() will be
> called in nand_put_hw_ecc_engine().
I see.
Then I prefer keeping the logic in the core, not in the engine driver
and propose a
void nand_ecc_put_engine(struct nand_ecc_engine *engine)
which will do nothing for on-die/sw engines and drop the reference for
hw engines. I will also rename the "find_ecc_engine" to "get_engine" so
that the call to the "put" helper has more meaning.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Mason Yang <masonccyang@mxic.com.tw>, Vignesh R <vigneshr@ti.com>,
Tudor Ambarus <Tudor.Ambarus@microchip.com>,
Julien Su <juliensu@mxic.com.tw>,
Richard Weinberger <richard@nod.at>,
Boris Brezillon <bbrezillon@kernel.org>,
Schrempf Frieder <frieder.schrempf@kontron.de>,
Marek Vasut <marek.vasut@gmail.com>,
linux-mtd@lists.infradead.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 03/27] mtd: nand: Introduce the ECC engine abstraction
Date: Wed, 27 Feb 2019 15:19:57 +0100 [thread overview]
Message-ID: <20190227151957.4de6ff32@xps13> (raw)
In-Reply-To: <20190227150633.7d8f5c5c@collabora.com>
Hi Boris,
Boris Brezillon <boris.brezillon@collabora.com> wrote on Wed, 27 Feb
2019 15:06:33 +0100:
> On Wed, 27 Feb 2019 14:56:07 +0100
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Hi Boris,
> >
> > Boris Brezillon <bbrezillon@kernel.org> wrote on Mon, 25 Feb 2019
> > 19:55:43 +0100:
> >
> > > On Thu, 21 Feb 2019 11:01:52 +0100
> > > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > > +
> > > > +/**
> > > > + * struct nand_ecc_engine_ops - Generic ECC engine operations
> > > > + *
> > > > + * @init_ctx: given a desired user configuration for the pointed NAND device,
> > > > + * requests the ECC engine driver to setup a configuration with
> > > > + * values it supports.
> > > > + * @cleanup_ctx: clean the context initialized by @init_ctx.
> > > > + * @prepare_io_req: is called before reading/writing a page to prepare the I/O
> > > > + * request to be performed with ECC correction.
> > > > + * @finish_io_req: is called after reading/writing a page to terminate the I/O
> > > > + * request and ensure proper ECC correction.
> > > > + */
> > > > +struct nand_ecc_engine_ops {
> > >
> > > We might want to add a
> > >
> > > void (*put_engine)(struct nand_ecc_engine *engine);
> > >
> > > here if we want the nanddev cleanup path to be generic.
> > > This hook would be implemented by drivers where the ECC engine object is
> > > refcounted (typically the case for HW ECC engines shared by the raw NAND
> > > controller and the SPI controller).
> > >
> > > Alternatively, you can just add one nand_put_xxx_ecc_engine() func per
> > > engine class (SW, ondie and HW).
> >
> > Can't this be handled in the init/cleanup_ctx() path directly?
>
> You really have to get the reference before init_ctx() otherwise the
> engine might disappear between your get() and init() call, and, to keep
> things symmetric, I think it's best to handle the put() outside the
> cleanup_ctx() path.
>
> >
> > Furthermore if this is just a hook to do reference counting.
>
> Well, what this put() does depends on the class of engine. For SW and
> on-die ECC it can be a NOOP (that's true only if you keep the approach
> where you have a single instance shared by everyone for SW-based ECC
> engines).
> For HW-controller-side ECC engines, you'll have to call device_get() on
> the parent device in your nand_get_hw_ecc_engine() function while you
> hold the lock protecting the ECC engine list. And device_put() will be
> called in nand_put_hw_ecc_engine().
I see.
Then I prefer keeping the logic in the core, not in the engine driver
and propose a
void nand_ecc_put_engine(struct nand_ecc_engine *engine)
which will do nothing for on-die/sw engines and drop the reference for
hw engines. I will also rename the "find_ecc_engine" to "get_engine" so
that the call to the "put" helper has more meaning.
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-02-27 14:20 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-21 10:01 [RFC PATCH 00/27] Introduce the generic ECC engine abstraction Miquel Raynal
2019-02-21 10:01 ` Miquel Raynal
2019-02-21 10:01 ` [RFC PATCH 01/27] mtd: nand: Move nand_device forward declaration to the top Miquel Raynal
2019-02-21 10:01 ` Miquel Raynal
2019-02-21 10:01 ` [RFC PATCH 02/27] mtd: nand: Compile in the NAND core by default Miquel Raynal
2019-02-21 10:01 ` Miquel Raynal
2019-02-21 10:55 ` Boris Brezillon
2019-02-21 10:55 ` Boris Brezillon
2019-02-21 11:06 ` Miquel Raynal
2019-02-21 11:06 ` Miquel Raynal
2019-02-21 11:14 ` Boris Brezillon
2019-02-21 11:14 ` Boris Brezillon
2019-02-21 11:46 ` Miquel Raynal
2019-02-21 11:46 ` Miquel Raynal
2019-02-21 12:08 ` Boris Brezillon
2019-02-21 12:08 ` Boris Brezillon
2019-02-21 12:52 ` Miquel Raynal
2019-02-21 12:52 ` Miquel Raynal
2019-02-21 10:01 ` [RFC PATCH 03/27] mtd: nand: Introduce the ECC engine abstraction Miquel Raynal
2019-02-21 10:01 ` Miquel Raynal
2019-02-21 11:16 ` Boris Brezillon
2019-02-21 11:16 ` Boris Brezillon
2019-02-27 9:26 ` Miquel Raynal
2019-02-27 9:26 ` Miquel Raynal
2019-02-27 9:47 ` Boris Brezillon
2019-02-27 9:47 ` Boris Brezillon
2019-02-25 18:55 ` Boris Brezillon
2019-02-25 18:55 ` Boris Brezillon
2019-02-27 13:56 ` Miquel Raynal
2019-02-27 13:56 ` Miquel Raynal
2019-02-27 14:06 ` Boris Brezillon
2019-02-27 14:06 ` Boris Brezillon
2019-02-27 14:19 ` Miquel Raynal [this message]
2019-02-27 14:19 ` Miquel Raynal
2019-02-27 14:28 ` Boris Brezillon
2019-02-27 14:28 ` Boris Brezillon
2019-02-27 14:34 ` Miquel Raynal
2019-02-27 14:34 ` Miquel Raynal
2019-02-21 10:01 ` [RFC PATCH 04/27] mtd: Fix typo in mtd_ooblayout_set_databytes() description Miquel Raynal
2019-02-21 10:01 ` Miquel Raynal
2019-02-21 10:01 ` [RFC PATCH 05/27] mtd: nand: Move standard OOB layouts to the NAND core Miquel Raynal
2019-02-21 10:01 ` Miquel Raynal
2019-02-21 11:19 ` Boris Brezillon
2019-02-21 11:19 ` Boris Brezillon
2019-02-21 11:47 ` Miquel Raynal
2019-02-21 11:47 ` Miquel Raynal
2019-02-21 12:10 ` Boris Brezillon
2019-02-21 12:10 ` Boris Brezillon
2019-02-21 10:01 ` [RFC PATCH 06/27] mtd: nand: Move ECC specific functions to ecc/engine.c Miquel Raynal
2019-02-21 10:01 ` Miquel Raynal
2019-02-21 10:01 ` [RFC PATCH 07/27] mtd: nand: ecc: Move BCH code into the ecc/ directory Miquel Raynal
2019-02-21 10:01 ` Miquel Raynal
2019-02-21 10:01 ` [RFC PATCH 08/27] mtd: nand: ecc: Use SPDX license identifier for the software BCH code Miquel Raynal
2019-02-21 10:01 ` Miquel Raynal
2019-02-21 11:25 ` Boris Brezillon
2019-02-21 11:25 ` Boris Brezillon
2019-02-21 11:48 ` Miquel Raynal
2019-02-21 11:48 ` Miquel Raynal
2019-02-21 10:01 ` [RFC PATCH 09/27] mtd: nand: ecc: Turn the software BCH implementation generic Miquel Raynal
2019-02-21 10:01 ` Miquel Raynal
2019-02-21 12:26 ` Boris Brezillon
2019-02-21 12:26 ` Boris Brezillon
2019-02-21 12:53 ` Miquel Raynal
2019-02-21 12:53 ` Miquel Raynal
2019-02-21 10:01 ` [RFC PATCH 10/27] mtd: rawnand: Get rid of chip->ecc.priv Miquel Raynal
2019-02-21 10:01 ` Miquel Raynal
2019-02-21 13:01 ` Boris Brezillon
2019-02-21 13:01 ` Boris Brezillon
2019-02-21 10:02 ` [RFC PATCH 11/27] mtd: nand: ecc: Move Hamming code into the ecc/ directory Miquel Raynal
2019-02-21 10:02 ` Miquel Raynal
2019-02-21 10:02 ` [RFC PATCH 12/27] mtd: nand: ecc: Use SPDX license identifier for the software Hamming code Miquel Raynal
2019-02-21 10:02 ` 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=20190227151957.4de6ff32@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=bbrezillon@kernel.org \
--cc=boris.brezillon@collabora.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=frieder.schrempf@kontron.de \
--cc=juliensu@mxic.com.tw \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=masonccyang@mxic.com.tw \
--cc=richard@nod.at \
--cc=thomas.petazzoni@bootlin.com \
--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.