[U-Boot] [PATCH] NAND: Really ignore bad blocks when scrubbing
Signed-off-by: Marek Vasut marek.vasut@gmail.com --- drivers/mtd/nand/nand_base.c | 2 +- drivers/mtd/nand/nand_util.c | 1 + include/linux/mtd/mtd.h | 1 + 3 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index a5f872e..3093067 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2224,7 +2224,7 @@ int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr, /* * heck if we have a bad block, we do not erase bad blocks ! */ - if (nand_block_checkbad(mtd, ((loff_t) page) << + if (!instr->scrub && nand_block_checkbad(mtd, ((loff_t) page) << chip->page_shift, 0, allowbbt)) { printk(KERN_WARNING "nand_erase: attempt to erase a " "bad block at page 0x%08x\n", page); diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c index 81bf366..9da6eea 100644 --- a/drivers/mtd/nand/nand_util.c +++ b/drivers/mtd/nand/nand_util.c @@ -98,6 +98,7 @@ int nand_erase_opts(nand_info_t *meminfo, const nand_erase_options_t *opts) erase.mtd = meminfo; erase.len = meminfo->erasesize; erase.addr = opts->offset; + erase.scrub = opts->scrub; erase_length = lldiv(opts->length + meminfo->erasesize - 1, meminfo->erasesize);
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h index 3b18d7d..13a711d 100644 --- a/include/linux/mtd/mtd.h +++ b/include/linux/mtd/mtd.h @@ -55,6 +55,7 @@ struct erase_info { u_long priv; u_char state; struct erase_info *next; + int scrub; };
struct mtd_erase_region_info {
On 08/16/2011 12:03 PM, Marek Vasut wrote:
Signed-off-by: Marek Vasut marek.vasut@gmail.com
drivers/mtd/nand/nand_base.c | 2 +- drivers/mtd/nand/nand_util.c | 1 + include/linux/mtd/mtd.h | 1 + 3 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index a5f872e..3093067 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2224,7 +2224,7 @@ int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr, /* * heck if we have a bad block, we do not erase bad blocks ! */
if (nand_block_checkbad(mtd, ((loff_t) page) <<
if (!instr->scrub && nand_block_checkbad(mtd, ((loff_t) page) << chip->page_shift, 0, allowbbt)) { printk(KERN_WARNING "nand_erase: attempt to erase a " "bad block at page 0x%08x\n", page);
Changelog should describe why the existing mechanism of overriding the block_bad method is insufficient (I think there may be issues if you try to scrub before the bbt is first built) -- and if this supersedes that mechanism, that mechanism should be removed.
-Scott
On Friday, August 19, 2011 10:08:33 PM Scott Wood wrote:
On 08/16/2011 12:03 PM, Marek Vasut wrote:
Signed-off-by: Marek Vasut marek.vasut@gmail.com
drivers/mtd/nand/nand_base.c | 2 +- drivers/mtd/nand/nand_util.c | 1 + include/linux/mtd/mtd.h | 1 + 3 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index a5f872e..3093067 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2224,7 +2224,7 @@ int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr,
/** heck if we have a bad block, we do not erase bad blocks ! */
if (nand_block_checkbad(mtd, ((loff_t) page) <<
if (!instr->scrub && nand_block_checkbad(mtd, ((loff_t) page) << chip->page_shift, 0, allowbbt)) {printk(KERN_WARNING "nand_erase: attempt to erase a " "bad block at page 0x%08x\n", page);
Changelog should describe why the existing mechanism of overriding the block_bad method is insufficient (I think there may be issues if you try to scrub before the bbt is first built) -- and if this supersedes that mechanism, that mechanism should be removed.
Indeed, this completely ignores the BBT, unlike the previous way. From my understanding, scrub should behave this way, right ?
-Scott
On 08/19/2011 04:47 PM, Marek Vasut wrote:
On Friday, August 19, 2011 10:08:33 PM Scott Wood wrote:
Changelog should describe why the existing mechanism of overriding the block_bad method is insufficient (I think there may be issues if you try to scrub before the bbt is first built) -- and if this supersedes that mechanism, that mechanism should be removed.
Indeed, this completely ignores the BBT, unlike the previous way. From my understanding, scrub should behave this way, right ?
Yes. This is a more straightforward approach, but the changelog should explain why the change is being made, and the patch should remove the nand_block_bad_scrub() hack that is now unnecessary.
-Scott
On Friday, August 19, 2011 11:55:30 PM Scott Wood wrote:
On 08/19/2011 04:47 PM, Marek Vasut wrote:
On Friday, August 19, 2011 10:08:33 PM Scott Wood wrote:
Changelog should describe why the existing mechanism of overriding the block_bad method is insufficient (I think there may be issues if you try to scrub before the bbt is first built) -- and if this supersedes that mechanism, that mechanism should be removed.
Indeed, this completely ignores the BBT, unlike the previous way. From my understanding, scrub should behave this way, right ?
Yes. This is a more straightforward approach, but the changelog should explain why the change is being made, and the patch should remove the nand_block_bad_scrub() hack that is now unnecessary.
V2 on the way.
-Scott
Hi all,
I couldn't (easily) find a doc for coding style regarding defines in u-boot. I commenly don't indent preprocessor macro's, but when reading code from some one else code I tend to prefer single space indentation for these (before the #). Is there a standard for this in u-boot?
Regards, Jeroen
On Friday, August 19, 2011 17:57:50 Jeroen Hofstee wrote:
I couldn't (easily) find a doc for coding style regarding defines in u-boot. I commenly don't indent preprocessor macro's, but when reading code from some one else code I tend to prefer single space indentation for these (before the #). Is there a standard for this in u-boot?
i prefer: #if 1 # if 2 # if 3 ... # else ... # endif # endif #endif
but doing this without the space after the "#" is acceptable. these two styles are your only options, but i dont believe there is a rule as to which you pick other than "if you're the maintainer of the code in question, use whichever you like".
also, please dont hijack threads. start a new e-mail from scratch ... dont just hit "reply" to any old e-mail and erase the subject/body. -mike
participants (4)
-
Jeroen Hofstee -
Marek Vasut -
Mike Frysinger -
Scott Wood