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 v2 1/4] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters
Date: Wed, 27 Feb 2013 16:04:54 -0600	[thread overview]
Message-ID: <1362002694.15577.17@snotra> (raw)
In-Reply-To: <512E1623.5080509@ti.com> (from trini@ti.com on Wed Feb 27 08:20:19 2013)

On 02/27/2013 08:20:19 AM, Tom Rini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02/26/2013 09:08 PM, Scott Wood wrote:
> > The name "maxsize" suggests that it's a size, not a position.
> 
> OK, I'll call it maxoff (because it's the max offset within the NAND
> for a given partition, or end of the NAND).

Wouldn't it be less intrusive to just make it actually be the size  
instead of an offset?

> >> -        offset += block_len; +        *offset += block_len; }
> >>
> >> return ret; @@ -459,22 +463,26 @@ static size_t drop_ffs(const
> >> nand_info_t *nand, const u_char *buf, * Write image to NAND
> >> flash. * Blocks that are marked bad are skipped and the is
> >> written to the next * block instead as long as the image is
> >> short enough to fit even after - * skipping the bad blocks. + *
> >> skipping the bad blocks.  Note that the actual size needed may
> >> exceed + * both the length and available NAND due to bad blocks.
> >
> > If that happens, then the function returns failure.  Are the
> > contents of "actual" well-defined when the function returns
> > failure?
> 
> They are as well defined as what happens with length.  If we say we
> can't write, we set both to 0 and return an error.  I'll take this as
> a request to expand the comment and do so.

The comments could use expanding (it doesn't even explain what happens  
to length in the non-error case), but also it looks like there are some  
error paths where actual doesn't get cleared, in the  
CONFIG_CMD_NAND_YAFFS section.

I was also wondering about the case where check_skip_bad() says it  
doesn't fit.  It doesn't return the actual in that case -- it returns  
offset as of when it stopped.  So a caller of  
nand_read|write_skip_bad() would see the same "actual" as if it just  
barely fit.  I'm not sure that this function ever would return an  
actual size that exceeds the available NAND.

-Scott

  reply	other threads:[~2013-02-27 22:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-26 15:56 [U-Boot] [PATCH v2 0/4] Add NAND support to DFU Tom Rini
2013-02-26 15:56 ` [U-Boot] [PATCH v2 1/4] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters Tom Rini
2013-02-27  2:08   ` Scott Wood
2013-02-27 14:20     ` Tom Rini
2013-02-27 22:04       ` Scott Wood [this message]
2013-02-27 23:36         ` Tom Rini
2013-02-27 16:49   ` Tom Rini
2013-02-27 17:09     ` Scott Wood
2013-02-27 17:17       ` Tom Rini
2013-02-27 17:22         ` Tom Rini
2013-02-26 15:56 ` [U-Boot] [PATCH v2 2/4] dfu: NAND specific routines for DFU operation Tom Rini
2013-02-26 15:56 ` [U-Boot] [PATCH v2 3/4] am335x_evm: Add CONFIG_CMD_MTDPARTS and relevant defaults Tom Rini
2013-02-27  8:54   ` Peter Korsgaard
2013-02-27 13:21     ` Tom Rini
2013-02-26 15:56 ` [U-Boot] [PATCH v2 4/4] am335x_evm: Enable DFU for NAND and MMC, provide example alt_info for both Tom Rini

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=1362002694.15577.17@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.