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

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.

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.

> 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.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)


  reply	other threads:[~2007-09-11  8:36 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 [this message]
2007-09-11  9:04       ` Bryan Wu
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=1189499707.14370.107.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=bryan.wu@analog.com \
    --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