Re: [RFC PATCH 20/27] mtd: nand: Let software ECC engines be retrieved from the NAND core

[Miquel Raynal <miquel.raynal@xxxxxxxxxxx>]

Hi Boris,

Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> wrote on Mon, 25 Feb
2019 17:13:30 +0100:

> > > > +{
> > > > +	switch (nand->ecc.user_conf.algo) {      
> > > 
> > > Note that the conf is supposed to be passed afterwards, when the ctx is
> > > created, so you should check nand->ecc.user_conf directly here.    
> > 
> > I think this is what I do so I suspect the above sentence is not what
> > you actually meant?  
> 
> Sorry, I meant "should not". My point is, the user_conf should only be
> passed at context creation time, and should not be modified in-place by
> the caller, unless proven necessary.
> 
> There's really 2 different steps that I think need to be isolated:
> 
> 1/ retrieve/create an ECC engine instance (SW, HW-controller-side,
>    on-die)
> 2/ ask this ECC engine instance to create a context out of a user conf
> 
> Your user_conf seems 2 mix the 2 concepts: the engine to use, the
> strength/step-size you expect.

No, I am not mixing things: the user might want a specific engine and a
strength/step-size. All of this is what the user requests.

In the ECC logic, I need to make a choice: I really need to check
what the user request is in order to choose the provider. I am not
changing anything here, just reading.

Later the chosen ECC engine will be prompted to create a context with
the rest of the user configuration.

I don't think it is relevant here to split this structure.


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