nand: reinstate lazy bad block scanning
Subsystems (2)
PATCH 1/1 nand: reinstate lazy bad block scanning
Commit ff94bc40af3481d47546595ba73c136de6af6929
("mtd, ubi, ubifs: resync with Linux-3.14")
accidentally reverted part of the commit13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").
Reinstate the change as by commitfb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("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
@@ -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
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 commit13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").
Quoted 8 lines
Reinstate the change as by commit
fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("nand: reinstate lazy bad block scanning")Signed-off-by Rostislav Lisovy <[email protected]>--- 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
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 commit13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").Quoted 8 lines
Reinstate the change as by commit
fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("nand: reinstate lazy bad block scanning")Signed-off-by Rostislav Lisovy <[email protected]>--- 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
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 commit13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").Reinstate the change as by commit
fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("nand: reinstate lazy bad block scanning")Signed-off-by Rostislav Lisovy <[email protected]>--- 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_scanuntil 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
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 commit13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").Reinstate the change as by commit
fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("nand: reinstate lazy bad block scanning")Signed-off-by Rostislav Lisovy <[email protected]>--- 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_scanuntil 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
PATCH 1/1 nand: reinstate lazy bad block scanning
In reply to Scott WoodHello 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 commit13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
("NAND: Scan bad blocks lazily.").Reinstate the change as by commit
fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
("nand: reinstate lazy bad block scanning")
Quoted 6 lines
Quoted 4 lines
Signed-off-by Rostislav Lisovy<[email protected]>--- 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