public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Bryan Wu <bryan.wu@analog.com>
To: dedekind@infradead.org
Cc: bryan.wu@analog.com, Mike Frysinger <vapier.adi@gmail.com>,
	linux-kernel@vger.kernel.org,
	Robin Getz <rgetz@blackfin.uclinux.org>,
	linux-mtd@lists.infradead.org,
	Thomas Gleixner <tglx@linutronix.de>,
	David Woodhouse <dwmw2@infradead.org>,
	akpm@linux-foundation.org
Subject: Re: [PATCH try #2] Blackfin on-chip NAND Flash Controller driver
Date: Tue, 11 Sep 2007 17:04:47 +0800	[thread overview]
Message-ID: <1189501487.12074.11.camel@roc-desktop> (raw)
In-Reply-To: <1189499707.14370.107.camel@sauron>

On Tue, 2007-09-11 at 11:35 +0300, Artem Bityutskiy wrote:
> Hi,
> 
> On Mon, 2007-09-10 at 17:50 +0800, Bryan Wu wrote:
> > Here is the test log, only 2 errors in oobtest. After digging into the
> > mtd-nand driver code, it should be no relation to my bf5xx_nand driver.
> > Maybe somethings wrong in the mtd-nand code. I intend to get some help
> > from you, please see my test log below:
> 
> > oobtest: Attempting to read past end of device
> > oobtest: An error is expected...
> > oobtest: error: read past end of device
> 
> This means that MTD did not return an error when the test tried to read
> the last NAND page's OOB. Here is the code:
> 
> /* Attempt to write off end of device */
> ops.mode      = MTD_OOB_AUTO;
> ops.ooblen    = mtd->ecclayout->oobavail + 1;
> ops.oobbuf    = writebuf;
> printk(PRINT_PREF "Attempting to write past end of device\n");
> printk(PRINT_PREF "An error is expected...\n");
> err = mtd->write_oob(mtd, mtd->size - mtd->writesize, &ops);
> 
> So we read OOB size + 1 byte from the last NAND page and get no error.
> 

Yes, it makes sense.

> This test passes for nandsim, so I'm not sure the problem is in the
> generic code. On the other hand, it is generic code which should check
> rages.

Actually, I debugged both oobtest.c and drivers/mtd/nand/nand_base.c

in the kernel nand_base.c
mtd->read_oob() --> nand_read_oob() --> nand_do_read_oob() -->
chip->ecc.read_oob() --> nand_read_oob_std() --> chip->read_buf() -->
bf5xx_nand.c bf5xx_nand_dma_read_buf().

In the calling path, rage check should not be in my driver code
bf5xx_nand_dma_read_buf() like other low level nand controller drivers.
It is already in nand_do_read_oob() as below:

---
	/* Do not allow reads past end of device */
	if (unlikely(from >= mtd->size ||
		     ops->ooboffs + readlen > ((mtd->size >> chip->page_shift) -
					(from >> chip->page_shift)) * len)) {
		DEBUG(MTD_DEBUG_LEVEL0, "nand_read_oob: "
			"Attempt read beyond end of device\n");
		return -EINVAL;
	}
---

maybe this condition testing does not include your case. I am not sure,
still busy at other task.

> > oobtest: Attempting to write past end of device
> > oobtest: An error is expected...
> > nand_write_oob: Attempt to write past end of page
> > oobtest: Error occurred as expected
> > oobtest: Attempting to read past end of device
> > oobtest: An error is expected...
> > oobtest: error: read past end of device
> 
> Similar.
> 
> > I plan to do the torture test after this oobtest passed. And this
> > nand_test suites are intended to integrated into our Blackfin
> > uClinux-dist testsuites.
> 
> We are planning to clean up the tests and submit them for kernel
> inclusion some day, when we have time.
> 

Good news. Thanks
Best Regards,
- Bryan Wu

  reply	other threads:[~2007-09-11  9:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-04  5:57 [PATCH try #2] Blackfin on-chip NAND Flash Controller driver Bryan Wu
2007-09-07  5:52 ` Artem Bityutskiy
2007-09-10  9:50   ` Bryan Wu
2007-09-11  8:35     ` Artem Bityutskiy
2007-09-11  9:04       ` Bryan Wu [this message]
2007-09-14  7:15 ` [PATCH try #3] " Bryan Wu

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=1189501487.12074.11.camel@roc-desktop \
    --to=bryan.wu@analog.com \
    --cc=akpm@linux-foundation.org \
    --cc=dedekind@infradead.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=rgetz@blackfin.uclinux.org \
    --cc=tglx@linutronix.de \
    --cc=vapier.adi@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox