All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mtd: nand: fix the written length when nand_write_skip_bad failed
Date: Thu, 7 Mar 2013 16:27:47 -0600	[thread overview]
Message-ID: <1362695267.23227.10@snotra> (raw)
In-Reply-To: <CANUnq3Zw0P_4H5q5Pz8wSHsuejWQ53NDOhK5D_dPW-MQq0jPTA@mail.gmail.com> (from hotforest@gmail.com on Thu Mar  7 09:02:27 2013)

On 03/07/2013 09:02:27 AM, htbegin wrote:
> Hi, Scott
> 
> On Thu, Mar 7, 2013 at 2:22 AM, Scott Wood <scottwood@freescale.com>  
> wrote:
> > On 03/06/2013 08:56:56 AM, htbegin wrote:
> >> > BTW, are you actually using WITH_YAFFS_OOB?  I think there are  
> some
> >> > other
> >> > things wrong with it at the moment, as mentioned here:
> >> > http://lists.denx.de/pipermail/u-boot/2013-March/148378.html
> >> No, I don't use it.
> >
> >
> > Changes to that code should be tested by someone...
> Sorry, I can't help.

It's moot because I don't think this change should be made, but this is  
a case where you could enable it temporarily in your board config for  
some basic testing.

> >> I just use "*length -= left_to_write - written_size" to tell the  
> upper
> >> level that what
> >> had been actually happened. For the current block, "written_size"  
> has
> >> been written to the NAND Flash yet, so left_to_write should be
> >> subtracted by "written_size".
> >
> >
> > But left_to_write isn't decreased until after this error return, so  
> that's
> > already the case.  Subtracting written_size from left_to_write has  
> the
> > effect of increasing length by written_size, so the return value  
> will now
> > look like the error page has been written.
> >
> > -Scott
> No, the returned value doesn't include the length of the error page.
> In no-WITH_YAFFS_OOB case,  when nand_write failed,
> truncated_write_size has been
> updated by nand_write to the length which has been successfully
> written , so it's OK to subtract written_size from left_to_write.

OK, but that doesn't explain why the change is needed.  You said you  
wanted to find the block with the error.  We only write one block at a  
time in the loop.  Why do you need the specific page within the block  
that failed?

-Scott

  reply	other threads:[~2013-03-07 22:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-02  9:01 [U-Boot] [PATCH] mtd: nand: fix the written length when nand_write_skip_bad failed Tao Hou
2013-03-05  1:58 ` Scott Wood
2013-03-06 14:56   ` htbegin
2013-03-06 18:22     ` Scott Wood
2013-03-07 15:02       ` htbegin
2013-03-07 22:27         ` Scott Wood [this message]
2013-03-10  1:06           ` htbegin
2013-03-11 16:43             ` Scott Wood

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=1362695267.23227.10@snotra \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /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.