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 11:09:42 -0600 [thread overview]
Message-ID: <1361984982.15577.4@snotra> (raw)
In-Reply-To: <20130227164955.GA30746@bill-the-cat> (from trini@ti.com on Wed Feb 27 10:49:55 2013)
On 02/27/2013 10:49:55 AM, Tom Rini wrote:
> On Tue, Feb 26, 2013 at 10:56:08AM -0500, Tom Rini wrote:
>
> > We make these two functions take a size_t pointer to how much space
> > was used on NAND to read or write the buffer (when reads/writes
> happen)
> > so that bad blocks can be accounted for. We also make them take an
> > loff_t limit on how much data can be read or written. This means
> that
> > we can now catch the case of when writing to a partition would
> exceed
> > the partition size due to bad blocks. To do this we also need to
> make
> [snip]
> > int nand_read_skip_bad(nand_info_t *nand, loff_t offset, size_t
> *length,
> > - u_char *buffer)
> > + size_t *actual, loff_t lim, u_char *buffer)
> [snip]
> > + if (*actual > lim) {
> > + puts("Size of read exceeds partition or device
> limit\n");
> > + *length = 0;
> > + return -EFBIG;
> > + }
>
> The more I look at this and try testing things, I think I shouldn't be
> introducing a change here. Before you could do:
> nand read ${address} partname-with-badblock
>
> And it would suceed but bleed into the next partition if it wasn't the
> last one. So your production system could do "nand read ${address}
> kernel" and be OK. But with this change, it would fail because
> reading
> the whole partition is now too large with a bad block (you would need
> partition+(blocksize*number bad blocks).
You wouldn't be quite so OK if it were a write instead.
> So I'm going to put this back to a check simply against requested size
> being greater than lim rather than required size greater than lim
> (since
> required size exceeds device is still caught).
No, please retain the check. The other issue is a separate (though
related) bug, and there's a patch from Harvey Chapman to deal with it.
-Scott
next prev parent reply other threads:[~2013-02-27 17:09 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
2013-02-27 23:36 ` Tom Rini
2013-02-27 16:49 ` Tom Rini
2013-02-27 17:09 ` Scott Wood [this message]
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=1361984982.15577.4@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.