public inbox for u-boot@lists.denx.de
 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: Mon, 11 Mar 2013 11:43:21 -0500	[thread overview]
Message-ID: <1363020201.16835.0@snotra> (raw)
In-Reply-To: <CANUnq3ZEH4m6acZvoPBSRyWAXGkPs1FzMNqLrgscpdnYMYDKQA@mail.gmail.com> (from hotforest@gmail.com on Sat Mar  9 19:06:54 2013)

On 03/09/2013 07:06:54 PM, htbegin wrote:
> Hi, Scott
> 
> On Fri, Mar 8, 2013 at 6:27 AM, Scott Wood <scottwood@freescale.com>  
> wrote:
> 
> >> >> 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
> 
> Yes, you are right it's OK to ignore the written length of the
> write-failed block, but as I said before I just wanted to tell the
> upper level what had been actually written. So if you insist the
> subtraction of written_len is unnecessary, it's alright with me.

Thanks.  I do insist -- it adds complexity.

-Scott

      reply	other threads:[~2013-03-11 16:43 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
2013-03-10  1:06           ` htbegin
2013-03-11 16:43             ` Scott Wood [this message]

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=1363020201.16835.0@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox