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] dfu, nand: before write a buffer to nand, erase the nand sectors
Date: Thu, 20 Jun 2013 12:22:45 -0500	[thread overview]
Message-ID: <1371748965.11064.12@snotra> (raw)
In-Reply-To: <51C286C1.2030101@denx.de> (from hs@denx.de on Wed Jun 19 23:36:17 2013)

On 06/19/2013 11:36:17 PM, Heiko Schocher wrote:
> Hello Scott,
> 
> Am 18.06.2013 02:51, schrieb Scott Wood:
> > Maybe we need an opts.limit?
> 
> Yes, I think so ... whats with the following proposal:
> 
> diff --git a/drivers/mtd/nand/nand_util.c  
> b/drivers/mtd/nand/nand_util.c
> index d81972c..b877c7d 100644
> --- a/drivers/mtd/nand/nand_util.c
> +++ b/drivers/mtd/nand/nand_util.c
> @@ -120,6 +120,10 @@ int nand_erase_opts(nand_info_t *meminfo, const  
> nand_erase_options_t *opts)
> 
>                 WATCHDOG_RESET();
> 
> +               if ((opts->limit) && (erase.addr > opts->limit)) {
> +                       puts("Size of write exceeds partition or  
> device limit\n");
> +                       return -EFBIG;
> +               }

This is treating limit as an address rather than a size.

Also, unnecessary parens.

> diff --git a/include/nand.h b/include/nand.h
> index 26190e4..d799df3 100644
> --- a/include/nand.h
> +++ b/include/nand.h
> @@ -125,6 +125,8 @@ struct nand_erase_options {
> 
>         /* Don't include skipped bad blocks in size to be erased */
>         int spread;
> +       /* maximum size that actual may be in order to not exceed the  
> buf */
> +       loff_t limit;
>  };
> 
>  typedef struct nand_erase_options nand_erase_options_t;
> 
> I checked for all calls from nand_erase_opts, that the  
> nand_erase_options_t
> parameters are initialized with 0 ... so this patch should not change
> current behaviour.
> 
> Should I do this in a seperate patch, or add it to the "dfu, nand:
> before write a buffer to nand, erase the nand sectors" patch, so it  
> adds
> no dead code ...

A separate patch within a patchset should be fine, but I'm also OK with  
combining them since the whole thing would still be small and  
straightforward enough to be easily reviewed.

-Scott

  reply	other threads:[~2013-06-20 17:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-14 10:24 [U-Boot] [PATCH] dfu, nand: before write a buffer to nand, erase the nand sectors Heiko Schocher
2013-06-14 22:19 ` Scott Wood
2013-06-17  5:01 ` [U-Boot] [PATCH v2] " Heiko Schocher
2013-06-18  0:51   ` Scott Wood
2013-06-20  4:36     ` Heiko Schocher
2013-06-20 17:22       ` Scott Wood [this message]
2013-06-21  5:09   ` [U-Boot] [PATCH v3] " Heiko Schocher
2013-06-21 22:50     ` Scott Wood
2013-06-24 16:50     ` [U-Boot] [PATCH v4] " Heiko Schocher
2013-06-24 23:26       ` Scott Wood
2013-07-25  4:43       ` [U-Boot] [PATCH v5] dfu, nand, ubi: add partubi alt settings for updating ubi partition Heiko Schocher
2013-07-26 22:05         ` Scott Wood

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