linux-toradex.git/include/linux/mtd/bbm.h, branch v4.11-rc3 Linux kernel for Apalis and Colibri modules mtd: onenand: make onenand_scan_bbt() static 2016-01-23T22:00:16+00:00 Thomas Petazzoni thomas.petazzoni@free-electrons.com 2016-01-14T14:44:50+00:00 fd2a2f20c7a8173acd4858e5178eb40fd7c025b9 Like was done in commit 17799359e7b3fa6ef4f2bf926cd6821cf7903ecf ("mtd: nand_bbt: make nand_scan_bbt() static") for the NAND code, this commit makes the onenand_scan_bbt() function static in the OneNAND code, since it is only used in onenand_bbt.c itself. Consequently, the EXPORT_SYMBOL() and declaration in bbm.h are also removed. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> 
Like was done in commit 17799359e7b3fa6ef4f2bf926cd6821cf7903ecf
("mtd: nand_bbt: make nand_scan_bbt() static") for the NAND code, this
commit makes the onenand_scan_bbt() function static in the OneNAND
code, since it is only used in onenand_bbt.c itself.

Consequently, the EXPORT_SYMBOL() and declaration in bbm.h are also
removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
mtd: nand_bbt: kill NAND_BBT_SCANALLPAGES 2013-11-07T07:33:14+00:00 Brian Norris computersforpeace@gmail.com 2013-10-30T04:41:30+00:00 5961ad2cb4dd14933889f5219e0d8505669d752d Now that the last user of NAND_BBT_SCANALLPAGES has been removed, let's kill this peculiar BBT feature flag. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 
Now that the last user of NAND_BBT_SCANALLPAGES has been removed, let's
kill this peculiar BBT feature flag.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
mtd: nand: remove NAND_BBT_SCANEMPTY 2013-08-30T15:48:37+00:00 Brian Norris computersforpeace@gmail.com 2013-07-31T00:53:00+00:00 dad2256269cb2ee3a72baefc5eb6e02ae1de2cfe NAND_BBT_SCANEMPTY is a strange, badly-supported option with omap as its single remaining user. NAND_BBT_SCANEMPTY was likely used by accident in omap2[1]. And anyway, omap2 doesn't scan the chip for bad blocks (courtesy of NAND_SKIP_BBTSCAN), and so its use of this option is irrelevant. This patch drops the NAND_BBT_SCANEMPTY option. [1] http://lists.infradead.org/pipermail/linux-mtd/2012-July/042902.html Signed-off-by: Brian Norris <computersforpeace@gmail.com> Cc: Ivan Djelic <ivan.djelic@parrot.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
NAND_BBT_SCANEMPTY is a strange, badly-supported option with omap as its
single remaining user.

NAND_BBT_SCANEMPTY was likely used by accident in omap2[1]. And anyway,
omap2 doesn't scan the chip for bad blocks (courtesy of
NAND_SKIP_BBTSCAN), and so its use of this option is irrelevant.

This patch drops the NAND_BBT_SCANEMPTY option.

[1] http://lists.infradead.org/pipermail/linux-mtd/2012-July/042902.html

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Ivan Djelic <ivan.djelic@parrot.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
mtd: Better comment NAND_BBT_NO_OOB 2012-07-06T17:18:18+00:00 Shmulik Ladkani shmulik.ladkani@gmail.com 2012-06-26T14:28:28+00:00 f3bae3df764737a168fbc51484b277cf0187933e Amend the comment to reflect the fact NAND_BBT_NO_OOB refers to the location of the bad block table marker. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
Amend the comment to reflect the fact NAND_BBT_NO_OOB refers to the
location of the bad block table marker.

Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
mtd: nand: remove NAND_BBT_SEARCH option 2012-07-06T17:17:04+00:00 Brian Norris computersforpeace@gmail.com 2012-05-22T14:30:48+00:00 63d99c0e89039e1509209d36ee17fc374fd112c9 This option was never used and isn't currently used. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
This option was never used and isn't currently used.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
mtd: nand: write BBM to OOB even with flash-based BBT 2012-03-26T23:27:02+00:00 Brian Norris computersforpeace@gmail.com 2012-02-06T21:44:00+00:00 e2414f4c20bd4dc62186fbfd7bdec50bce6d2ead Currently, the flash-based BBT implementation writes bad block data only to its flash-based table and not to the OOB marker area. Then, as new bad blocks are marked over time, the OOB markers become incomplete and the flash-based table becomes the only source of current bad block information. This becomes an obvious problem when, for example: * bootloader cannot read the flash-based BBT format * BBT is corrupted and the flash must be rescanned for bad blocks; we want to remember bad blocks that were marked from Linux So to keep the bad block markers in sync with the flash-based BBT, this patch changes the default so that we write bad block markers to the proper OOB area on each block in addition to flash-based BBT. Comments are updated, expanded, and/or relocated as necessary. The new flash-based BBT procedure for marking bad blocks: (1) erase the affected block, to allow OOB marker to be written cleanly (2) update in-memory BBT (3) write bad block marker to OOB area of affected block (4) update flash-based BBT Note that we retain the first error encountered in (3) or (4), finish the procedures, and dump the error in the end. This should handle power cuts gracefully enough. (1) and (2) are mostly harmless (note that (1) will not erase an already-recognized bad block). The OOB and BBT may be "out of sync" if we experience power loss bewteen (3) and (4), but we can reasonably expect that on next boot, subsequent I/O operations will discover that the block should be marked bad again, thus re-syncing the OOB and BBT. Note that this is a change from the previous default flash-based BBT behavior. If your system cannot support writing bad block markers to OOB, use the new NAND_BBT_NO_OOB_BBM option (in combination with NAND_BBT_USE_FLASH and NAND_BBT_NO_OOB). Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 
Currently, the flash-based BBT implementation writes bad block data only
to its flash-based table and not to the OOB marker area. Then, as new bad
blocks are marked over time, the OOB markers become incomplete and the
flash-based table becomes the only source of current bad block
information. This becomes an obvious problem when, for example:

 * bootloader cannot read the flash-based BBT format
 * BBT is corrupted and the flash must be rescanned for bad
   blocks; we want to remember bad blocks that were marked from Linux

So to keep the bad block markers in sync with the flash-based BBT, this
patch changes the default so that we write bad block markers to the proper
OOB area on each block in addition to flash-based BBT. Comments are
updated, expanded, and/or relocated as necessary.

The new flash-based BBT procedure for marking bad blocks:
 (1) erase the affected block, to allow OOB marker to be written cleanly
 (2) update in-memory BBT
 (3) write bad block marker to OOB area of affected block
 (4) update flash-based BBT
Note that we retain the first error encountered in (3) or (4), finish the
procedures, and dump the error in the end.

This should handle power cuts gracefully enough. (1) and (2) are mostly
harmless (note that (1) will not erase an already-recognized bad block).
The OOB and BBT may be "out of sync" if we experience power loss bewteen
(3) and (4), but we can reasonably expect that on next boot, subsequent
I/O operations will discover that the block should be marked bad again,
thus re-syncing the OOB and BBT.

Note that this is a change from the previous default flash-based BBT
behavior. If your system cannot support writing bad block markers to OOB,
use the new NAND_BBT_NO_OOB_BBM option (in combination with
NAND_BBT_USE_FLASH and NAND_BBT_NO_OOB).

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
mtd: nand: improve comment on NAND_BBT_DYNAMIC_STRUCT 2011-09-11T12:01:57+00:00 Brian Norris computersforpeace@gmail.com 2011-05-31T23:31:27+00:00 9eeff8243677b8bbfc17e8e606e965bb591a759d In an attempt to improve the documentation of the BBT code, I am expanding the comments I left in commit: 58373ff0afff4cc8ac40608872995f4d87eb72ec mtd: nand: more BB Detection refactoring and dynamic scan options Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> 
In an attempt to improve the documentation of the BBT code, I am expanding
the comments I left in commit:
    58373ff0afff4cc8ac40608872995f4d87eb72ec
    mtd: nand: more BB Detection refactoring and dynamic scan options

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
mtd: nand: renumber the reorganized flags in nand.h / bbm.h 2011-09-11T12:01:56+00:00 Brian Norris computersforpeace@gmail.com 2011-05-31T23:31:26+00:00 b4dc53e16ff00c0edba3d3219e216475e68951b3 After several steps of rearrangement and consolidation, it is probably worth re-sequencing the numbers on some of our affected flags in nand.h and bbm.h. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> 
After several steps of rearrangement and consolidation, it is probably
worth re-sequencing the numbers on some of our affected flags in nand.h
and bbm.h.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
mtd: nand: rename CREATE_EMPTY bbt flag with proper prefix 2011-09-11T12:01:56+00:00 Brian Norris computersforpeace@gmail.com 2011-05-31T23:31:25+00:00 53d5d8885089b8abeb487392311ed18f897deb93 According to our new prefix rules, we should rename NAND_CREATE_EMPTY_BBT with a NAND_BBT prefix, i.e., NAND_BBT_CREATE_EMPTY. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> 
According to our new prefix rules, we should rename NAND_CREATE_EMPTY_BBT
with a NAND_BBT prefix, i.e., NAND_BBT_CREATE_EMPTY.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
mtd: nand: move NAND_CREATE_EMPTY_BBT flag 2011-09-11T12:01:56+00:00 Brian Norris computersforpeace@gmail.com 2011-05-31T23:31:24+00:00 b8f80684054ec8a3bcdf35dc9c76ddf629a36482 The NAND_CREATE_EMPTY_BBT flag was added by commit: 453281a973c10bce941b240d1c654d536623b16b mtd: nand: introduce NAND_CREATE_EMPTY_BBT This flag is not used within the kernel and not explained well, so I took the liberty to edit its comments. Also, this is a BBT-related flag (and closely tied with NAND_BBT_CREATE) so I'm moving it to bbm.h next to NAND_BBT_CREATE, thus requiring that we use the flag in nand_chip.bbt_options, *not* in nand_chip.options. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> 
The NAND_CREATE_EMPTY_BBT flag was added by commit:
  453281a973c10bce941b240d1c654d536623b16b
  mtd: nand: introduce NAND_CREATE_EMPTY_BBT
This flag is not used within the kernel and not explained well, so I
took the liberty to edit its comments.

Also, this is a BBT-related flag (and closely tied with NAND_BBT_CREATE)
so I'm moving it to bbm.h next to NAND_BBT_CREATE, thus requiring that
we use the flag in nand_chip.bbt_options, *not* in nand_chip.options.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>