UBI: cleanup comments about corrupted PEBs

 * eraseblocks are put to the @free list and the physical eraseblock to be

 * erased are put to the @erase list.

 *

 * About corruptions

 * ~~~~~~~~~~~~~~~~~

 *

 * UBI protects EC and VID headers with CRC-32 checksums, so it can detect

 * whether the headers are corrupted or not. Sometimes UBI also protects the

 * data with CRC-32, e.g., when it executes the atomic LEB change operation, or

 * when it moves the contents of a PEB for wear-leveling purposes.

 *

 * UBI tries to distinguish between 2 types of corruptions.

 * 1. Corruptions caused by power cuts. These are harmless and expected

 *    corruptions and UBI tries to handle them gracefully, without printing too

 *    many warnings and error messages. The idea is that we do not lose

 *    important data in these case - we may lose only the data which was being

 *    written to the media just before the power cut happened, and the upper

 *    layers (e.g., UBIFS) are supposed to handle these situations. UBI puts

 *    these PEBs to the head of the @erase list and they are scheduled for

 *    erasure.

 *

 * 1. Corruptions caused by power cuts. These are expected corruptions and UBI

 * tries to handle them gracefully, without printing too many warnings and

 * error messages. The idea is that we do not lose important data in these case

 * - we may lose only the data which was being written to the media just before

 * the power cut happened, and the upper layers (e.g., UBIFS) are supposed to

 * handle such data losses (e.g., by using the FS journal).

 *

 * When UBI detects a corruption (CRC-32 mismatch) in a PEB, and it looks like

 * the reason is a power cut, UBI puts this PEB to the @erase list, and all

 * PEBs in the @erase list are scheduled for erasure later.

 *

 * 2. Unexpected corruptions which are not caused by power cuts. During

 * scanning, such PEBs are put to the @corr list and UBI preserves them.

 *    Obviously, this lessens the amount of available PEBs, and if at some

 *    point UBI runs out of free PEBs, it switches to R/O mode. UBI also loudly

 *    informs about such PEBs every time the MTD device is attached.

 * Obviously, this lessens the amount of available PEBs, and if at some  point

 * UBI runs out of free PEBs, it switches to R/O mode. UBI also loudly informs

 * about such PEBs every time the MTD device is attached.

 *

 * However, it is difficult to reliably distinguish between these types of

 * corruptions and UBI's strategy is as follows. UBI assumes (2.) if the VID

 * header is corrupted and the data area does not contain all 0xFFs, and there

 * were not bit-flips or integrity errors while reading the data area. Otherwise

 * UBI assumes (1.). The assumptions are:

 *   o if the data area contains only 0xFFs, there is no data, and it is safe

 *     to just erase this PEB.

 *   o if the data area has bit-flips and data integrity errors (ECC errors on

 * corruptions and UBI's strategy is as follows. UBI assumes corruption type 2

 * if the VID header is corrupted and the data area does not contain all 0xFFs,

 * and there were no bit-flips or integrity errors while reading the data area.

 * Otherwise UBI assumes corruption type 1. So the decision criteria are as

 * follows.

 *   o If the data area contains only 0xFFs, there is no data, and it is safe

 *     to just erase this PEB - this is corruption type 1.

 *   o If the data area has bit-flips or data integrity errors (ECC errors on

 *     NAND), it is probably a PEB which was being erased when power cut

 *     happened.

 *     happened, so this is corruption type 1. However, this is just a guess,

 *     which might be wrong.

 *   o Otherwise this it corruption type 2.

 */

#include <linux/err.h>