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