From: Tom Rini <trini@ti.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 12:17:07 -0500 [thread overview]
Message-ID: <512E3F93.9020108@ti.com> (raw)
In-Reply-To: <1361984982.15577.4@snotra>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/27/2013 12:09 PM, Scott Wood wrote:
> 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.
Correct. But the check is now inside of nand_(read|write)_skip_bad.
So the write case will fail (without trying to write), but the read
case should not.
>> 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.
I could be missing something, but I'm not sure how to otherwise adjust
things here. With all of the checking moved to nand_util.c and
check_skip_len not knowing if we're a read or write it can only say
"fits using X" or "exceeds device", then it's up to the caller to
decide the next action.
- --
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRLj+TAAoJENk4IS6UOR1WJAAP/RLxsGHN4HqoEC0zfe2eIDZe
ZJU+sevT/murom6fNOfKFuC8pwPavy64FGdXNspwdpJCRTcXIs503k4x4ZMy9USC
HszV9NKF42HyscQi3RmBqlIUb9WQ6UikMZEUpteO0ZGQajRKho3nL3M1qjQsASG9
745qrmJijQEjEu3MsnfEZYEzyliVCpHHiIylhBALizwpjEwzKwlebe/ZrmbTPYO6
QXyfHLd+/5iNUJEjXOaXP/z7gXU+85m2uwxRhyLB1PmULGkmh7A+cvByTPt8TcxK
HTWnL3at4S+OvWqlnYTdTYbsCBUQ3jp/wnLF39vq9E5VIPv7UshwPponeNbFEGzt
GOZP1fIGMWcSFJHd3usR7wkhA5tJZu9329Av283ckwIbSlwz/tOP/efwFF/Zsrc5
oLn4ezRrA+RSKCtCujYJPhnAyEJEkncvpA4Imx6R9v9LZlXu3z8w5AQKcuAlsrxm
FDcjtcAA6y804I2jGPvL9laoCy9li1SVMHbd71zVtRwRJBMYUMfw7aI6uUwBslLJ
4GlnVKKsfEAkEb7APZ5v5YJrwD+mgSJ4TR1fwtoirbQKpG3OrMnXNhzZSBD5UFv6
DUxhMRL+EOawFJIl5AUPHHB7LdvV4qtDwee1bPg31ZXetnimQGLHn8qzppioMIvC
suvFme3/03ZGTDFwUUjp
=My8j
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2013-02-27 17:17 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
2013-02-27 17:17 ` Tom Rini [this message]
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=512E3F93.9020108@ti.com \
--to=trini@ti.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.