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 (Битюцкий Артём)
next prev parent 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