The current ubi.mtd parsing logic will warn & continue on when attaching
the specified mtd device fails (for any reason).  It doesn't however skip
things when the specified mtd device can't be opened.

This scenario can be hit in a couple of different ways such as:
 - build NAND controller driver as a module
 - build UBI into the kernel
 - include ubi.mtd on the kernel command line
 - boot the system
 - MTD devices don't exist, so UBI init fails

This is problematic because failing init means the entire UBI layer is
unavailable until you reboot and modify the kernel command line.  If
we just warn and continue on, /dev/ubi_ctrl is available for userland
to add UBI volumes on the fly once it loads the NAND driver.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

The ubi_err() macro automatically prefixes "UBI error" before the message.
By also using it here, we get a log like so:
	UBI error: ubi_init: UBI error: cannot initialize UBI, error -19
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

ubi_debug_info struct was dynamically allocated which
is always suboptimal, for it tends to fragment memory
and make the code error-prone.
Fix this by embedding it in ubi_device struct.
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This kind of memcpy() is error-prone. Its replacement with a struct
assignment is prefered because it's type-safe and much easier to read.

Found by coccinelle. Hand patched and reviewed.
Tested by compilation only.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
identifier struct_name;
struct struct_name to;
struct struct_name from;
expression E;
@@
-memcpy(&(to), &(from), E);
+to = from;
// </smpl>
Signed-off-by: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

- Export compare_lebs() as fastmap needs this function.
- Implement fastmap scan logic.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Use 'late_initcall()' in UBI to make sure it initializes after MTD drivers.
Signed-off-by: NJiang Lu <lu.jiang@windriver.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

UBI currently prints a lot of information when it mounts a volume, which
bothers some people. Make it less chatty - print only important information
by default.

Get rid of 'dbg_msg()' macro completely.
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Use 'pr_err()' instead of 'printk(KERN_ERR', etc.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Join all the split printk lines in order to stop checkpatch complaining.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Currently UBI fails in autoresize when it is in R/O mode (e.g., because the
underlying MTD device is R/O). This patch fixes the issue - we just skip
autoresize and print a warning.
Reported-by: NPali Rohár <pali.rohar@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This patch provides the possibility to adjust the "maximum expected number of
bad blocks per 1024 blocks" (max_beb_per1024) for each mtd device.

The majority of NAND devices have their max_beb_per1024 equal to 20, but
sometimes it's more.
Now, we can adjust that via a kernel parameter:
ubi.mtd=<name|num|path>[,<vid_hdr_offs>[,max_beb_per1024]]
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

max_beb_per1024 shouldn't be negative, and a 0 value will be treated as
the default value. For the upper bound, 768/1024 should be enough.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This patch prepare the way for the addition of max_beb_per1024 module
parameter.  There's no functional change.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Reviewed-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

No functional changes here, just to prepare for next patch.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

On NAND flash devices, UBI reserves some physical erase blocks (PEB) for
bad block handling. Today, the number of reserved PEB can only be set as a
percentage of the total number of PEB in each MTD partition. For example, for a
NAND flash with 128KiB PEB, 2 MTD partition of 20MiB (mtd0) and 100MiB (mtd1)
and 2% reserved PEB:
 - the UBI device on mtd0 will have 2 PEB reserved
 - the UBI device on mtd1 will have 16 PEB reserved

The problem with this behaviour is that NAND flash manufacturers give a
minimum number of valid block (NVB) during the endurance life of the
device, e.g.:

Parameter             Symbol    Min    Max    Unit      Notes
--------------------------------------------------------------
Valid block number     NVB     1004    1024   Blocks     1

From this number we can deduce the maximum number of bad PEB that a device will
contain during its endurance life: a 128MiB NAND flash (1024 PEB) will not have
less than 20 bad blocks during the flash endurance life.

But the manufacturer doesn't tell where those bad block will appear. He doesn't
say either if they will be equally disposed on the whole device (and I'm pretty
sure they won't). So, according to the datasheets, we should reserve the
maximum number of bad PEB for each UBI device (worst case scenario: 20 bad
blocks appears on the smallest MTD partition).

So this patch make UBI use the whole MTD device size to calculate the maximum
bad expected eraseblocks.

The Kconfig option is in per1024 blocks, thus it can have a default value of 20
which is *very* common for NAND devices.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Introduce 'ubi->bad_peb_limit', which specifies an upper limit of PEBs
UBI expects to go bad.  Currently, it is initialized to a fixed percentage
of total PEBs in the UBI device (configurable via CONFIG_MTD_UBI_BEB_LIMIT).

The 'bad_peb_limit' is intended to be used for calculating the amount of PEBs
UBI needs to reserve for bad eraseblock handling.

Artem: minor amendments.
Signed-off-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>

Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Rename the 'attach_by_scanning()' function to 'ubi_attach()' and move it to
scan.c. Richard will plug his fastmap stuff there.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

We have a couple of initialization funcntionsn left which have "_scan" suffic -
rename them:

ubi_eba_init_scan() -> ubi_eba_init()
ubi_wl_init_scan() -> ubi_wl_init()
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This patch amends commentaries in scan.[ch] to match the new logic. Reminder -
we did the restructuring to prepare the code for adding the fastmap. This patch
also renames a couple of functions - it was too difficult to separate out that
change and I decided that it is not too bad to have it in the same patch with
commentaries changes.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

The old name is not logical anymore - rename it to 'ubi_destroy_ai()'.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

After re-naming the 'struct ubi_scan_info' we should adjust all variables
named 'si' to something else, because 'si' stands for "scanning info".
Let's rename it to 'ai' which stands for "attaching info" which is
a bit more consistent and has the same length, which makes re-naming easy.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>

Rename 'struct ubi_scan_info' to 'struct ubi_attach_info'. This is part
of the code re-structuring I am trying to do in order to add fastmap
in a more logical way. Fastmap can share a lot with scanning, including
the attach-time data structures, which all now have "scan" word in the
name. Let's get rid of this word.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>

Rename 'struct ubi_scan_leb' to 'struct ubi_ainf_leb'. This is part
of the code re-structuring I am trying to do in order to add fastmap
in a more logical way. Fastmap can share a lot with scanning, including
the attach-time data structures, which all now have "scan" word in the
name. Let's get rid of this word and use "ainf" instead which stands
for "attach information". It has the same length as "scan" so re-naming
is trivial.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>

This patch removes the 'dbg_err()' macro and we now use 'ubi_err' instead.
The idea of 'dbg_err()' was to compile out some error message to make the
binary a bit smaller - but I think it was a bad idea.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Now we have only one buffer so let's rename it to just 'peb_buf1'.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Remove the pre-allocated 'peb_buf2' buffer because we do not really need it.
The only reason UBI has it is to check that the data were written correctly.
But we do not have to have 2 buffers for this and waste RAM - we can just
compare CRC checksums instead. This reduces UBI memory consumption.

Artem bityutskiy: massaged the patch and commit message
Signed-off-by: NJosselin Costanzi <josselin.costanzi@mobile-devices.fr>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This patch introduces new 'mtd_can_have_bb()' helper function which checks
whether the flash can have bad eraseblocks. Then it changes all the
direct 'mtd->block_isbad' use cases with 'mtd_can_have_bb()'.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch fixes an oops in the error path of 'ubi_attach_mtd_dev()'. If
anything after 'uif_init()' fails, we get an oops in 'cancel_pending()'. The
reason is that 'uif_close()' drops the last reference count for 'ubi->dev' and
whole 'struct ubi_device' is freed. And then
'ubi_wl_close()'->'cancel_pending()' tries to access the 'ubi' pointer and
problems begin.

Note, in 'ubi_detach_mtd_dev()' function we get a device reference to
work-around this issue. Do the same in the error path of
'ubi_attach_mtd_dev()'.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This patch introduces debugfs support to UBI. All the UBI stuff is kept in the
"ubi" debugfs directory, which contains per-UBI device "ubi/ubiX"
sub-directories, containing debugging files. This file also creates
"ubi/ubiX/chk_gen" and "ubi/ubiX/chk_io" knobs for switching general and I/O
extra checks on and off. And it removes the 'debug_chks' UBI module parameters.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Similarly to the debugging checks and message, make the test modes
be dynamically selected via the "debug_tsts" module parameter or
via the "/sys/module/ubi/parameters/debug_tsts" sysfs file. This
is consistent with UBIFS as well.

And now, since all the Kconfig knobs became dynamic, we can remove
the Kconfig.debug file completely.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This patch kills the 'ubi->dbg_peb_buf' debugging buffer and the
associated mutex, because all users of this buffer are now gone.
We are killing this buffer because we are going to switch to
dynamic debugging control, just like in UBIFS, which means that
CONFIG_MTD_UBI_DEBUG_PARANOID will be removed. In this case we'd
end up always allocating 'ubi->dbg_peb_buf', which is rather large
(128KiB or more), and this would be wasteful. Thus, we are just
killing it.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Incorporate MTD write buffer size into UBI device information
because UBIFS needs this field. UBI does not use it ATM, just
provides to upper layers in 'struct ubi_device_info'.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

During scanning UBI allocates one struct ubi_scan_leb object for each PEB,
so it can end up allocating thousands of them. Use slab cache to reduce
memory consumption for these 48-byte objects, because currently used
'kmalloc()' ends up allocating 64 bytes per object, instead of 48.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This reverts commit a121f643.

Unfortunately, this commit breaks UBIFS backward compatibility and
makes new UBIFS refuse older UBIFS-formatted media:

UBIFS error: validate_sb: min. I/O unit mismatch: 8 in superblock, 64 real

Thus, we have to revert this patch and work on a better solution.
Reported-by: NHolger Brunck <holger.brunck@keymile.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Wrong macro was used in calculating the data offset: UBI_EC_HDR_SIZE instead of
UBI_VID_HDR_SIZE. The data offset should be VID header offset + VID header size
(aligned to the minimum I/O unit).

This was not a bug only because currently UBI_EC_HDR_SIZE and UBI_VID_HDR_SIZE
have the same value of 64 bytes.

Commit message was amended by Artem.
Signed-off-by: NJohn Ogness <john.ogness@linutronix.de>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Previously we used mtd->writesize field to set UBI's minimal
I/O unit size. This sometimes caused UBIFS recovery issues
when mounting an uncleanly unmounted UBIFS partition on NOR
flash since mtd->writesize is 1 byte for NOR flash. The
MTD CFI driver however often performs writing multiple
bytes in one programming operation using the chip's write
buffer. We have to use the size of this write buffer as
a minimal I/O unit size for UBI on NOR flash to fix the
observed UBIFS recovery issues.
Signed-off-by: NAnatolij Gustschin <agust@denx.de>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Currently UBI erases all corrupted eraseblocks, irrespectively of the nature
of corruption: corruption due to power cuts and non-power cut corruption.
The former case is OK, but the latter is not, because UBI may destroy
potentially important data.

With this patch, during scanning, when UBI hits a PEB with corrupted VID
header, it checks whether this PEB contains only 0xFF data. If yes, it is
safe to erase this PEB and it is put to the 'erase' list. If not, this may
be important data and it is better to avoid erasing this PEB. Instead,
UBI puts it to the corr list and moves out of the pool of available PEB.
IOW, UBI preserves this PEB.

Such corrupted PEB lessen the amount of available PEBs. So the more of them
we accumulate, the less PEBs are available. The maximum amount of non-power
cut corrupted PEBs is 8.

This patch is a response to UBIFS problem where reporter
(Matthew L. Creech <mlcreech@gmail.com>) observes that UBIFS index points
to an unmapped LEB. The theory is that corresponding PEB somehow got
corrupted and UBI wiped it. This patch (actually a series of patches)
tries to make sure such PEBs are preserved - this would make it is easier
to analyze the corruption.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>