All of lore.kernel.org
 help / color / mirror / Atom feed
From: Derek Ou <derek@siconix.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Pad data length for nand write
Date: Tue, 17 Feb 2009 13:54:00 -0700	[thread overview]
Message-ID: <499B23E8.30607@siconix.com> (raw)
In-Reply-To: <20090217185155.GA31737@ld0162-tx32.am.freescale.net>

This routine is copied from nand_write_opts() at nand_util.c of v1.3.4.  
It maybe better
to pad data length and data buffer in do_nand() at cmd_nand.c.  But I 
don't see real
difference.  I didn't allocate a new buffer since the data length is 
defined in the command
arguments and I have no knowledge of a safe location and large enough 
memory space
to store data.

Maybe we should implement, like Wolfgang said, a "+length" syntax in the 
"nand write"
command to indicates "round up to the next page boundary".  In this 
case, do_nand()
can assume that it's safe to write pass memory address (add + length) 
and Flash offset
(off + length).

Derek
Scott Wood wrote:
> On Tue, Feb 17, 2009 at 10:15:07AM -0700, Derek Ou wrote:
>   
>> +	/* now, pad data with 0xff */
>> +	if (page_offset != 0)
>> +		memset(buffer + *length, 0xff, pad_len);
>>     
> You cannot write to the caller's buffer (or worse, past the end of the
> caller's buffer) like this.  You'll need to allocate a new, padded
> buffer.
>
> -Scott
>   

  reply	other threads:[~2009-02-17 20:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-17 17:15 [U-Boot] [PATCH] Pad data length for nand write Derek Ou
2009-02-17 17:15 ` Derek Ou
2009-02-17 18:51   ` Scott Wood
2009-02-17 20:54     ` Derek Ou [this message]
2009-02-17 21:16       ` Scott Wood
2009-02-17 21:37         ` Derek Ou
2009-02-17 17:55 ` Mike Frysinger
2009-02-17 18:37   ` Derek Ou
2009-02-17 18:41     ` Scott Wood
2009-02-17 20:22     ` Wolfgang Denk

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=499B23E8.30607@siconix.com \
    --to=derek@siconix.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.