NAND: Really ignore bad blocks when scrubbing

PATCH New Marek Vasut 4 participants 7 messages Aug 16, 2011 – Aug 19, 2011

Subsystems (2)

Memory technology devices (MTD) NAND flash

lore

Share & tools

lore

Marek Vasut

author

2011-08-16 17:03 UTC #0 lore raw

PATCH 1/1 NAND: Really ignore bad blocks when scrubbing

Signed-off-by Marek Vasut <[email protected]>

---
 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(-)

drivers/mtd/nand/nand_base.c +1 -1

index a5f872e..3093067 100644
@@ -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);

drivers/mtd/nand/nand_util.c +1 -0

index 81bf366..9da6eea 100644
@@ -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);

include/linux/mtd/mtd.h +1 -0

index 3b18d7d..13a711d 100644
@@ -55,6 +55,7 @@ struct erase_info {
 	u_long priv;
 	u_char state;
 	struct erase_info *next;
+	int scrub;
 };
 
 struct mtd_erase_region_info {

Signature · 1 line

1.7.5.4

Scott Wood

2011-08-19 20:08 UTC #1 lore raw

PATCH 1/1 NAND: Really ignore bad blocks when scrubbing

Quoted 12 lines · Marek Vasut

Signed-off-by Marek Vasut <[email protected]>

---
 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(-)

drivers/mtd/nand/nand_base.c +0 -0

index a5f872e..3093067 100644

drivers/mtd/nand/nand_base.c int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr, · line 2230

Quoted 8 lines

drivers/mtd/nand/nand_base.c +1 -1

@@ -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

Marek Vasut

author

2011-08-19 21:47 UTC #2 lore raw

PATCH 1/1 NAND: Really ignore bad blocks when scrubbing

Quoted 26 lines · Scott Wood

Quoted 25 lines · Marek Vasut

Signed-off-by Marek Vasut <[email protected]>

---

 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(-)

drivers/mtd/nand/nand_base.c +1 -1

index a5f872e..3093067 100644
@@ -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)) {

Quoted 8 lines

drivers/mtd/nand/nand_base.c int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr, · line 2230
Quoted 3 lines
drivers/mtd/nand/nand_base.c +0 -0
 			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 ?

Quoted 2 lines

-Scott

Scott Wood

2011-08-19 21:55 UTC #3 lore raw

PATCH 1/1 NAND: Really ignore bad blocks when scrubbing

Quoted 8 lines · Marek Vasut

Quoted 4 lines · Scott Wood
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

Marek Vasut

author

2011-08-19 22:46 UTC #4 lore raw

PATCH 1/1 NAND: Really ignore bad blocks when scrubbing

Quoted 7 lines · Scott Wood

Quoted 6 lines · Marek Vasut
Quoted 4 lines · Scott Wood
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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 2 lines

-Scott

Jeroen Hofstee

2011-08-19 21:57 UTC #5 lore raw

[U-Boot] nested defines coding style

In reply to Marek Vasut

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

Mike Frysinger

2011-08-19 22:31 UTC #6 lore raw

[U-Boot] nested defines coding style

Quoted 4 lines · 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110819/c5c4a8f7/attachment.pgp