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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Boris,

Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> wrote on Wed, 27 Feb
2019 15:06:33 +0100:

> On Wed, 27 Feb 2019 14:56:07 +0100
> Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
> 
> > Hi Boris,
> > 
> > Boris Brezillon <bbrezillon@xxxxxxxxxx> wrote on Mon, 25 Feb 2019
> > 19:55:43 +0100:
> >   
> > > On Thu, 21 Feb 2019 11:01:52 +0100
> > > Miquel Raynal <miquel.raynal@xxxxxxxxxxx> 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/




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux