All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Naga Sureshkumar Relli <nagasure@xilinx.com>,
	Michal Simek <monstr@monstr.eu>,
	Amit Kumar Mahapatra <akumarma@xilinx.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	<linux-mtd@lists.infradead.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 2/3] mtd: rawnand: Check the CHANGE_READ_COLUMN from nand_read_subpage() is supported
Date: Mon, 6 Sep 2021 19:32:55 +0200	[thread overview]
Message-ID: <20210906193255.05b7aa7c@xps13> (raw)
In-Reply-To: <20210906183344.7fda2cf2@collabora.com>


> > > > diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> > > > index 7f29f27bb6fd..8175635b9802 100644
> > > > --- a/drivers/mtd/nand/raw/nand_base.c
> > > > +++ b/drivers/mtd/nand/raw/nand_base.c
> > > > @@ -3065,10 +3065,19 @@ static int nand_read_subpage(struct nand_chip *chip, uint32_t data_offs,
> > > >  		    (busw - 1))
> > > >  			aligned_len++;
> > > >  
> > > > -		ret = nand_change_read_column_op(chip,
> > > > -						 mtd->writesize + aligned_pos,
> > > > -						 &chip->oob_poi[aligned_pos],
> > > > -						 aligned_len, false);
> > > > +		ret = nand_check_change_read_column_op(chip,
> > > > +						       mtd->writesize + aligned_pos,
> > > > +						       &chip->oob_poi[aligned_pos],
> > > > +						       aligned_len, false, true);
> > > > +		if (!ret)
> > > > +			ret = nand_change_read_column_op(chip,
> > > > +							 mtd->writesize + aligned_pos,
> > > > +							 &chip->oob_poi[aligned_pos],
> > > > +							 aligned_len, false);
> > > > +		else
> > > > +			ret = nand_change_read_column_op(chip, mtd->writesize,
> > > > +							 chip->oob_poi,
> > > > +							 mtd->oobsize, false);
> > > >  		if (ret)
> > > >  			return ret;      
> > >     
> > 
> > 
> > The previous behavior was:
> > 
> > /*
> >  * gaps == true means we need to request the entire OOB area and we
> >  * will call an OOB layout helper to extract the ECC bytes.
> >  * gaps == false means there is no data interleaved, we can just read
> >  * the number of ECC bytes by starting at the right offset and no
> >  * extracting operation will be needed.
> >  */
> > gaps = ...;
> > if (!gaps)
> > 	nand_change_read_column(at a specific offset and a specific
> > 				length just to match the ECC bytes);
> > else
> > 	nand_change_read_column(the entire OOB);
> > 
> > While the new behavior is:
> > 
> > if (!gaps) {
> > 	op_supported = nand_check_change_read_column();
> > 	if (!op_supported)
> > 		// same operation as if gaps == true
> > 		nand_change_read_column(the entire OOB);  
> 
> What if this one is not supported either?

If this one is not supported either I guess the entire software ECC
support cannot be used. But what I am trying to achieve here is more
complicated: the controller does not support one thing: reading the ECC
bytes until the OOB end minus 2. Only a call to
nand_change_read_column with these particular parameters would fail
because it depends on the actual offset and length that are requested.

> > 	else
> > 		nand_change_read_column(at a specific offset);
> > } else {
> > 	nand_change_read_column(the entire OOB)
> > }
> >   
> > > So you just fail if the CHANGE column op is not supported? Looks like
> > > this check should be done before we assign ecc->read_subpage to
> > > nand_read_subpage in
> > > nand_set_ecc_on_host_ops()/nand_set_ecc_soft_ops()...    
> > 
> > So I actually don't understand the above comment as the code is not
> > simply failing, it's actually falling back to second method which is
> > maybe slightly slower but still valid. Do you think it's wrong?  
> 
> Well, it's falling back to a different method that might be unsupported
> too, so it might still fail on other controllers.

Well, yes it may fail on other controllers but as I said, if
controllers do not support any type of nand_change_read_column() then
they cannot use software ECC at all (and are close to be almost
useless).

> Moreover, I really
> think this sort of things should be checked at probe time so you don't
> spend time checking it every time you do a read.

Agreed. I can certainly make something like this in theory, but what
would be the condition? I am describing it in patch 3/3 : there is
really a tiny set of conditions where this will fail so in the end I
would end-up writing a condition that precisely matches the Arasan
limitation.

Not mentioning that it only fails with NV-DDR enabled (also something
that I missed to capture in patch 3/3). The data interface being
initialized after the read_subpage() hook it means I couldn't use this
information. 

> Something like:
> 
> 	if (nand_check_change_read_column(gaps=false))
> 		ecc->read_subpage = nand_read_subpage_nogaps;
> 	else if (nand_check_change_read_column(gaps=true))
> 		ecc->read_subpage = nand_read_subpage_gaps;
> 	else
> 		return -EOPNOTSUP;


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

  reply	other threads:[~2021-09-06 17:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-06 13:29 [PATCH 1/3] mtd: rawnand: Add a helper to check if a CHANGE_READ_COLUMN is possible Miquel Raynal
2021-09-06 13:29 ` [PATCH 2/3] mtd: rawnand: Check the CHANGE_READ_COLUMN from nand_read_subpage() is supported Miquel Raynal
2021-09-06 15:08   ` Boris Brezillon
2021-09-06 16:13     ` Miquel Raynal
2021-09-06 16:33       ` Boris Brezillon
2021-09-06 17:32         ` Miquel Raynal [this message]
2021-09-06 17:59           ` Boris Brezillon
2021-09-06 13:29 ` [PATCH 3/3] mtd: rawnand: arasan: Provide an additional ->exec_op() check 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=20210906193255.05b7aa7c@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=akumarma@xilinx.com \
    --cc=boris.brezillon@collabora.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=monstr@monstr.eu \
    --cc=nagasure@xilinx.com \
    --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.