public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Vijay Kumar <vijaykumar@bravegnu.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH 2/2] NAND: nandsim sector-wise allocation
Date: Fri, 06 Oct 2006 10:08:16 +0300	[thread overview]
Message-ID: <1160118496.13696.57.camel@sauron> (raw)
In-Reply-To: <17701.15655.736379.98045@vaishnavi.localdomain>

Vijay,

thank you for your patches. Please, find my comments below.

On Thu, 2006-10-05 at 22:43 +0530, Vijay Kumar wrote:
> For page wise allocation, an array of flash page pointers is allocated
> during initialization. The flash pages are themselves allocated when a
> write occurs to the page. The flash pages are deallocated when they
> are erased.
> 
> The init, read, prog and erase operations are moved to separate functions,
> and for each allocation/mapping type a set of init/read/prog/erase
> functions are defined.
> 
> Signed-off-by: Vijay Kumar <vijaykumar@bravegnu.org>

Frankly, I do not understand many things in nandsim code now, although I
wrote it :-) So no deep review for now, just minor or obvious things.

>  config  MTD_NAND_NANDSIM_CHIP_ALLOC
> -	bool "Use allocated memory"
> +	bool "Allocate entire chip"
>  	help
> -	  The flash data is stored in allocated memory.
> +	  The flash data is stored in allocated memory. The entire
> +	  memory to hold the flash data is allocated during 
> +	  initialization.
>  
> +config MTD_NAND_NANDSIM_PAGE_ALLOC
> +	bool "Allocate flash pages as required"
> +	help
> +	  The flash data is stored in allocated memory. The
> +	  allocation is done on a per page basis, when data is 
> +	  written to the page. Enables simulation of 
> +	  higher capacity NAND devices in systems that do
> +	  not have as much RAM.

I believe there is no need in these options. As soon as you've added the
new method, what's the reason to keep the old one? Why you didn't delete
it - any good reason?

> -#ifdef CONFIG_MTD_NAND_NANDSIM_CHIP_MAP
> +#if defined(CONFIG_MTD_NAND_NANDSIM_CHIP_MAP)

I wonder, why "#if defined(kaka)" is better then "#ifdef kaka" ? What
for is this change :-) ?

>  #include <asm/io.h>
>  #endif
>  
> @@ -45,8 +45,10 @@
>  #define CONFIG_NANDSIM_CHIP_MAP      1
>  #elif defined(CONFIG_MTD_NAND_NANDSIM_CHIP_ALLOC)
>  #define CONFIG_NANDSIM_CHIP_ALLOC    1
> +#elif defined(CONFIG_MTD_NAND_NANDSIM_PAGE_ALLOC)
> +#define CONFIG_NANDSIM_PAGE_ALLOC  1

Ditto. Although it is anyway reasonable to get rid of this junk #ifdefs
at all.

> +union ns_mem_t {
> +	u_char *byte;
> +	uint16_t *word;
> +};

Minor, but 'union ns_mem' is a better name. We usually use "_t" for
typedefs, and we use typedefs very rarely and only if there is a good
reason.

> +static int
> +alloc_map_device(struct nandsim *ns)

Again minor. I understand that everybody has its own style, and I
appreciate this. But when one fixes an existing code, it makes sense to
follow the same style. So I offer to use definitions like

static int alloc_map_device(struct nandsim *ns);

This is just a nice stuff to bear in mind, IMHO.

> +	for (i = 0; i < num; i++) {
> +		ns->mem.byte[NS_RAW_OFFSET(ns) + ns->regs.off + i] &= ns->buf.byte[i];
> +	}

Again a nit. We usually don't use brackets in case of one-line code -
just a convention.

> 			ns->mem.byte[NS_RAW_OFFSET(ns) + ns->regs.off + i] &= ns->buf.byte[i];
> +		if (prog_page(ns, num) == -1) {
> +			return -1;
> +		}

Ditto.

-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)

  reply	other threads:[~2006-10-06  7:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-05 16:57 [PATCH 0/2] NAND: nandsim sector-wise allocation Vijay Kumar
2006-10-05 17:04 ` [PATCH 1/2] " Vijay Kumar
2006-10-06  6:49   ` Artem Bityutskiy
2006-10-08  5:38     ` Vijay Kumar
2006-10-05 17:13 ` [PATCH 2/2] " Vijay Kumar
2006-10-06  7:08   ` Artem Bityutskiy [this message]
2006-10-08  5:50     ` Vijay Kumar
2006-10-06  6:44 ` [PATCH 0/2] " Artem Bityutskiy

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=1160118496.13696.57.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vijaykumar@bravegnu.org \
    /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