Subject: Re: [RFC PATCH 03/27] mtd: nand: Introduce the ECC engine abstraction

From: Boris Brezillon <[email-masked]>
Date: Wed, 27 Feb 2019 15:06:33 +0100

On Wed, 27 Feb 2019 14:56:07 +0100
Miquel Raynal <[email-masked]> wrote:

> Hi Boris,
> 
> Boris Brezillon <[email-masked]> wrote on Mon, 25 Feb 2019
> 19:55:43 +0100:
> 
> > On Thu, 21 Feb 2019 11:01:52 +0100
> > Miquel Raynal <[email-masked]> 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().

_______________________________________________
linux-arm-kernel mailing list
[email-masked]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel