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