Skip to contentSkip to conversation

nand: reinstate lazy bad block scanning

PATCH New Rostislav Lisovy 4 participants 6 messages Oct 22, 2014 – Nov 5, 2014

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 nand: reinstate lazy bad block scanning

Commit ff94bc40af3481d47546595ba73c136de6af6929
("mtd, ubi, ubifs: resync with Linux-3.14")
accidentally reverted part of the commit
13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").

Reinstate the change as by commit
fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("nand: reinstate lazy bad block scanning")

---
 drivers/mtd/nand/nand_base.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/mtd/nand/nand_base.c +7 -3
index 0b6e7ee..70e780c 100644
@@ -634,6 +634,11 @@ static int nand_block_checkbad(struct mtd_info *mtd, loff_t ofs, int getchip,
 {
 	struct nand_chip *chip = mtd->priv;
 
+	if (!(chip->options & NAND_BBT_SCANNED)) {
+		chip->scan_bbt(mtd);
+		chip->options |= NAND_BBT_SCANNED;
+	}
+
 	if (!chip->bbt)
 		return chip->block_bad(mtd, ofs, getchip);
 
@@ -4322,10 +4327,9 @@ int nand_scan_tail(struct mtd_info *mtd)
 
 	/* Check, if we should skip the bad block table scan */
 	if (chip->options & NAND_SKIP_BBTSCAN)
-		return 0;
+		chip->options |= NAND_BBT_SCANNED;
 
-	/* Build bad block table */
-	return chip->scan_bbt(mtd);
+	return 0;
 }
 EXPORT_SYMBOL(nand_scan_tail);
 
Signature · 1 line
1.9.1
#1 lore raw

PATCH 1/1 nand: reinstate lazy bad block scanning

Quoted 6 lines · Rostislav Lisovy

Commit ff94bc40af3481d47546595ba73c136de6af6929
("mtd, ubi, ubifs: resync with Linux-3.14")
accidentally reverted part of the commit
13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").

Quoted 8 lines

Reinstate the change as by commit
fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("nand: reinstate lazy bad block scanning")

---
 drivers/mtd/nand/nand_base.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Thanks for catching this.

Heiko, this is the sort of thing I was concerned about with the "resync from scratch" approach.

-Scott

#2 lore raw

PATCH 1/1 nand: reinstate lazy bad block scanning

Hi Scott, Rostislav,

Quoted 16 lines · On Mon, 3 Nov 2014 15:42:29 -0600 Scott Wood <[email protected]> wrote:
Quoted 6 lines · Rostislav Lisovy

Commit ff94bc40af3481d47546595ba73c136de6af6929
("mtd, ubi, ubifs: resync with Linux-3.14")
accidentally reverted part of the commit
13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").

Quoted 8 lines

Reinstate the change as by commit
fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("nand: reinstate lazy bad block scanning")

---
 drivers/mtd/nand/nand_base.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)
Quoted 5 lines

Thanks for catching this.

Heiko, this is the sort of thing I was concerned about with the "resync from scratch" approach.

I do not believe resync is a bad idea,
of course we should be very careful not to break existing features.

I recommend to surround this code with "#ifdef __UBOOT__ ... #endif" as we have done for the other parts.

BTW, we attempt to probe NAND devices during the boot sequence just for displaying the device size, right?

NAND: **** MiB

If so, can we postpone the whole of nand_scan until we use it? I am not sure about this, though.

Best Regards
Masahiro Yamada

#3 lore raw

PATCH 1/1 nand: reinstate lazy bad block scanning

Quoted 21 lines · Masahiro Yamada

Hi Scott, Rostislav,

Quoted 16 lines · On Mon, 3 Nov 2014 15:42:29 -0600 Scott Wood <[email protected]> wrote:
Quoted 14 lines · Rostislav Lisovy

Commit ff94bc40af3481d47546595ba73c136de6af6929
("mtd, ubi, ubifs: resync with Linux-3.14")
accidentally reverted part of the commit
13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").

Reinstate the change as by commit
fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("nand: reinstate lazy bad block scanning")

---
 drivers/mtd/nand/nand_base.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)
Quoted 8 lines
Quoted 5 lines

Thanks for catching this.

Heiko, this is the sort of thing I was concerned about with the "resync from scratch" approach.

I do not believe resync is a bad idea,
of course we should be very careful not to break existing features.

I'm not saying don't sync -- I'm saying do it by generating a diff based on the last sync (which is what all the previous NAND updates did), rather than throwing out the U-Boot code and replacing it with Linux files, and then fixing any problems encountered (which may be a subset of the problems existing).

Quoted 2 lines

I recommend to surround this code with "#ifdef __UBOOT__ ... #endif" as we have done for the other parts.

I recommend not making such a mess, for reasons I've described previously.

Quoted 8 lines

BTW, we attempt to probe NAND devices during the boot sequence just for displaying the device size, right?

NAND: **** MiB

If so, can we postpone the whole of nand_scan until we use it? I am not sure about this, though.

Possibly. IIRC someone once posted a patch trying to do this, but it was missing an initialization check on some paths where NAND could be accessed, and the patchset never got respun.

-Scott

#4 lore raw

PATCH 1/1 nand: reinstate lazy bad block scanning

Hi Scott,

Quoted 49 lines · On Tue, 4 Nov 2014 23:49:36 -0600 Scott Wood <[email protected]> wrote:
Quoted 21 lines · Masahiro Yamada

Hi Scott, Rostislav,

Quoted 16 lines · On Mon, 3 Nov 2014 15:42:29 -0600 Scott Wood <[email protected]> wrote:
Quoted 14 lines · Rostislav Lisovy

Commit ff94bc40af3481d47546595ba73c136de6af6929
("mtd, ubi, ubifs: resync with Linux-3.14")
accidentally reverted part of the commit
13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").

Reinstate the change as by commit
fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("nand: reinstate lazy bad block scanning")

---
 drivers/mtd/nand/nand_base.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)
Quoted 8 lines
Quoted 5 lines

Thanks for catching this.

Heiko, this is the sort of thing I was concerned about with the "resync from scratch" approach.

I do not believe resync is a bad idea,
of course we should be very careful not to break existing features.

I'm not saying don't sync -- I'm saying do it by generating a diff based on the last sync (which is what all the previous NAND updates did), rather than throwing out the U-Boot code and replacing it with Linux files, and then fixing any problems encountered (which may be a subset of the problems existing).

Quoted 2 lines

I recommend to surround this code with "#ifdef __UBOOT__ ... #endif" as we have done for the other parts.

I recommend not making such a mess, for reasons I've described previously.

Quoted 6 lines

BTW, we attempt to probe NAND devices during the boot sequence just for displaying the device size, right?

NAND: **** MiB

Quoted 7 lines
Quoted 2 lines

If so, can we postpone the whole of nand_scan until we use it? I am not sure about this, though.

Possibly. IIRC someone once posted a patch trying to do this, but it was missing an initialization check on some paths where NAND could be accessed, and the patchset never got respun.

In Simon's driver model, devices are probed when they are actually used. Perhaps we can change this when we introduce driver model to NAND.

Best Regards
Masahiro Yamada

#5 lore raw

PATCH 1/1 nand: reinstate lazy bad block scanning

In reply to Scott Wood

Hello Scott, Rostislav,

Am 03.11.2014 22:42, schrieb Scott Wood:

Quoted 11 lines · Rostislav Lisovy
Quoted 10 lines

Commit ff94bc40af3481d47546595ba73c136de6af6929
("mtd, ubi, ubifs: resync with Linux-3.14")
accidentally reverted part of the commit
13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").

Reinstate the change as by commit
fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("nand: reinstate lazy bad block scanning")

Quoted 6 lines
Quoted 4 lines
---
  drivers/mtd/nand/nand_base.c | 10 +++++++---
  1 file changed, 7 insertions(+), 3 deletions(-)

Thanks for catching this.

Yep! I tested it on the siemens am335x boards so

Quoted 2 lines

Heiko, this is the sort of thing I was concerned about with the "resync from scratch" approach.

I know, but the rebase was also error prone (at least in my attempts ...)

As we have now a clear defined base, maybe a resync with the help from git works now in future?

bye,
Heiko

Signature · 2 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany