From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Add +size syntax to nand commands to pad lengths to page sizes.
Date: Mon, 11 May 2009 16:02:42 -0500 [thread overview]
Message-ID: <4A089272.7070202@freescale.com> (raw)
In-Reply-To: <4A088EE5.7030401@vocollect.com>
Josh Karabin wrote:
>> Why not support plussed for read as well?
>
> "read" isn't strictly necessary, since the existing code permits lengths
> that result in page-unaligned reads.
Would be nice to keep the syntax consistent and not error if the user
does provide a plus, though.
> Other operations are a little obvious. "erase" implicitly extends the
> page size already if it needs to,
That should probably be changed to only do so if plus is used -- it's
just as dangerous as implicitly rounding up with write (more so, since
the blocks are bigger).
> "write" is the only operation that would ever need to depend on
> +{filesize} for which I could think of a non contrived example, so I
> stopped there.
Erase is also quite likely to use {filesize} -- and I could see it being
used for load as well.
> That said, would you prefer me to support plussed "read"
> or any of the other operations (erase, unlock)?
Yes.
>>> + if (plussed) {
>>> + int tailsize = size & (nand->writesize - 1);
>>> + memset ((u_char *)addr + size, 0xff, nand->writesize - tailsize);
>>> + size += nand->writesize - tailsize;
>> NACK, you cannot write to arbitrary memory beyond the end of the range
>> specified. Allocate a buffer to hold the partial page.
>
> OK. I expected this, but I wanted to ask a question about it.
>
> Are there actual callers for which this would cause a problem, or is
> this intended to make the code future proof? I couldn't find any, so I
> assume that the objection is the latter?
The caller is the user typing a command, and while most of the time it
would be harmless, it's unexpected behavior.
> Commands like "tftpboot" and
> "loadb" already stomp on memory without allocating it, so I wasn't sure
> why the nand commands should be handled differently.
Stomping on memory that the user asks to be stomped on is one thing --
stomping on a few extra bytes beyond the end of that region is another
(and if those other commands do that, I'd rather not emulate them).
>>> + }
>>> + }
>> Please keep lines under 80 characters.
>>
>
> Will do. I noticed a few other lines in the file that hadn't, so
> figured it wasn't an enforced standard. It will be corrected.
Sometimes it's deliberately overlooked because the wrapped version would
be too awkward, but most of the time those long lines got in there by
accident.
-Scott
prev parent reply other threads:[~2009-05-11 21:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-01 20:24 [U-Boot] [PATCH] Add +size syntax to nand commands to pad lengths to page sizes Josh Karabin
2009-05-11 19:37 ` Scott Wood
2009-05-11 20:47 ` Josh Karabin
2009-05-11 21:02 ` 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=4A089272.7070202@freescale.com \
--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