From: Artem Bityutskiy <dedekind@infradead.org>
To: simon polette <spolette@gmail.com>
Cc: Gregory CLEMENT <gclement@adeneo.eu>,
linux-mtd <linux-mtd@lists.infradead.org>,
linux-arm-kernel@lists.arm.linux.org.uk,
spolette@adetelgroup.com
Subject: Re: [PATCH] mtd: Nand Atmel: add On Flash BBT support
Date: Tue, 26 May 2009 12:43:51 +0300 [thread overview]
Message-ID: <1243331031.21646.134.camel@localhost.localdomain> (raw)
In-Reply-To: <72795ccb0905260240q6389dd35j681dbe50a6d4990f@mail.gmail.com>
On Tue, 2009-05-26 at 11:40 +0200, simon polette wrote:
> 2009/5/26 Artem Bityutskiy <dedekind@infradead.org>:
> > On Mon, 2009-05-25 at 17:44 +0200, simon polette wrote:
> >> +config MTD_NAND_ATMEL_FLASH_BBT
> >> + bool "Use On-Flash Bad Block Table"
> >> + depends on MTD_NAND_ATMEL
> >> + help
> >> + This enables the On-Flash BBT, which mean that the bad blocks
> >> + will be scanned one time then the BBT will be stored
> >> + in flash, so scanning Nand flash for bad blocks will be no more
> >> + necessary for the next boots.
> >> +
> >
> > I do not think you need a config option for this. It should be
> > a module parameter instead.
> >
> > --
> > Best regards,
> > Artem Bityutskiy (Битюцкий Артём)
> >
> >
>
> Yes, good idea, but do you think that I can keep a config option to
> define the default state of that param, it means doing something like
> :
> #ifdef CONFIG_MTD_NAND_ATMEL_FLASH_BBT
> static int use_on_flash_bbt = 1;
> #else
> static int use_on_flash_bbt = 0;
> #endif
> module_param(use_on_flash_bbt, int, 0);
I think it is generally bad idea if each nand driver will
introduce a separate config option for this kind of stuff.
You may always boot your kernel with something like
atmel_nand.on_flash_bbt=1 in the kernel parameters.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2009-05-26 9:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-25 15:44 [PATCH] mtd: Nand Atmel: add On Flash BBT support simon polette
2009-05-26 7:32 ` Artem Bityutskiy
2009-05-26 9:40 ` simon polette
2009-05-26 9:43 ` Artem Bityutskiy [this message]
2009-05-26 9:47 ` simon polette
2009-05-26 10:21 ` simon polette
2009-05-26 11:55 ` simon polette
2009-05-27 6:21 ` Artem Bityutskiy
2009-05-27 10:00 ` simon polette
2009-05-27 13:37 ` Artem Bityutskiy
2009-05-27 14:44 ` simon polette
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=1243331031.21646.134.camel@localhost.localdomain \
--to=dedekind@infradead.org \
--cc=gclement@adeneo.eu \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-mtd@lists.infradead.org \
--cc=spolette@adetelgroup.com \
--cc=spolette@gmail.com \
/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