In order to have a way of distinguishing an invalid ioctl from a
not supported (but otherwise valid) ioctl, this commit changes the
return value of the ioctl stubs from ENOTTY to ENOSYS.

This will be useful to report more accurate error messages from
userspace tools.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

We already use term attach/detach for UBI->MTD relations, let's not use this
for UBI->ubiblock relations to avoid confusion. Just use 'create' and 'remove'
instead. E.g., "create a R/O block device on top of a UBI volume".
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This commit introduces read-only block device emulation on top of UBI volumes.

Given UBI takes care of wear leveling and bad block management it's possible
to add a thin layer to enable block device access to UBI volumes.
This allows to use a block-oriented filesystem on a flash device.

The UBI block devices are meant to be used in conjunction with any
regular, block-oriented file system (e.g. ext4), although it's primarily
targeted at read-only file systems, such as squashfs.

Block devices are created upon user request through new ioctls:
UBI_IOCVOLATTBLK to attach and UBI_IOCVOLDETBLK to detach.
Also, a new UBI module parameter is added 'ubi.block'. This parameter is
needed in order to attach a block device on boot-up time, allowing to
mount the rootfs on a ubiblock device.
For instance, you could have these kernel parameters:

  ubi.mtd=5 ubi.block=0,0 root=/dev/ubiblock0_0

Or, if you compile ubi as a module:

  $ modprobe ubi mtd=/dev/mtd5 block=/dev/ubi0_0

Artem: amend commentaries and massage the patch a little bit.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
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>

- 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>

This patch adds fastmap specific data structures to ubi.h.
It moves also struct ubi_work to ubi.h as it is now needed
for more than one c file.
Signed-off-by: NRichard Weinberger <richard@nod.at>
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>

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>

CONFIG_MTD_UBI_BEB_RESERVE and MIN_RESEVED_PEBS are no longer used,
since the amount of reserved eraseblocks for bad PEB handling is now
derived from 'ubi->bad_peb_limit' (ubi's maximum expected bad
eraseblocks).
Signed-off-by: NShmulik Ladkani <shmulik.ladkani@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>

Currently, there are several locations where an attempt to reserve more
PEBs for bad PEB handling is made, with the same code being duplicated.

Harmonize it by introducing 'ubi_update_reserved()'.

Also, improve the debug message issued, making it more descriptive.

Artem: amended the patch a little.
Signed-off-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>

This patch modifies ubi_wl_flush to force the erasure of
particular volume id / logical eraseblock number pairs. Previous functionality
is preserved when passing UBI_ALL for both values. The locations where ubi_wl_flush
were called are appropriately changed: ubi_leb_erase only flushes for the
erased LEB, and ubi_create_volume forces only flushing for its volume id.
External code can call this new feature via the new function ubi_flush() added
to kapi.c, which simply passes through to ubi_wl_flush().

This was tested by disabling the call to do_work in ubi thread, which results
in the work queue remaining unless explicitly called to remove. UBIFS was
changed to call ubifs_leb_change 50 times for four different LEBs. Then the
new function was called to clear the queue: passing wrong volume ids / lnum,
correct ones, and finally UBI_ALL for both to ensure it was finally all
cleard. The work queue was dumped each time and the selective removal
of the particular LEB numbers was observed. Extra checks were enabled and
ubifs's integck was also run. Finally, the drive was repeatedly filled and
emptied to ensure that the queue was cleared normally.

Artem: amended the patch.
Signed-off-by: NJoel Reardon <reardonj@inf.ethz.ch>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Joel will use it in his 'ubi_flush()' extention to specify all eraseblocks.
Also amend the comment for UBI_UNKNOWN - it is used beyond attaching info
structure now.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This is part of a multipart patch to allow UBI to force the erasure of
particular logical eraseblock numbers. In this patch, the volume id and LEB
number are added to ubi_work data structure, and both are also passed as a
parameter to schedule erase to set it appropriately. Whenever ubi_wl_put_peb
is called, the lnum is also passed to be forwarded to schedule erase. Later,
a new ubi_sync_lnum will be added to execute immediately all work related to
that lnum.

This was tested by outputting the vol_id and lnum during the schedule of
erasure. The ubi thread was disabled and two ubifs drives on separate
partitions repeated changed a small number of LEBs. The ubi module was readded,
and all the erased LEBs, corresponding to the volumes, were added to the
schedule erase queue.

Artem: minor tweaks
Signed-off-by: NJoel Reardon <reardonj@inf.ethz.ch>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This patch adds the volume id to struct ubi_ainf_peb when scanning the LEBs at
startup. PEBs now added to the erase queue will know their original LEB number
and volume id, if available, and will be -1 otherwise (for instance, if the VID
header is unreadable).

This was tested by creating an ubi device with 3 volumes and disabiling the
ubi_thread's do_work functionality. The different ubi volumes were formatted
to ubifs and had files created and erased.  The ubi modules was reloaded and
the list of LEB's added to the erased list was outputted, confirming the
volume ids and LEB numbers were appropriate.
Signed-off-by: NJoel Reardon <reardonj@inf.ethz.ch>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This file is small and it does not make sense to have it separate from where
everything else lives, so merge it with ubi.h.
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>

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>

We do not need this feature and to our shame it even was not working
and there was a bug found very recently.
	-- Artem Bityutskiy

Without the data type hint UBI2 (fastmap) will be easier to implement.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

UBI (and UBIFS) are a bit over-engineered WRT debugging. The idea was to
link as few as possible when debugging is disabled, but the downside is
that most people produce bug reports which are difficult to understand.

This patch weeds out the 'ubi_dbg_dump_stack()' function and turns it
into 'dump_stack()' - it is always useful to have stack dump in case of
an error.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>

While looking at a problem reported by UBI around the PEB moving area I
noticed that the 'MOVE_CANCEL_BITFLIPS' is a bit inconsistent name and
'MOVE_TARGET_BITFLIPS' better - let's rename it.
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>

Under some cases, when scrubbing the PEB if we did not get the lock on
the PEB it fails to scrub. Add that PEB again to the scrub list

Artem: minor amendments.

Cc: stable@kernel.org [2.6.31+]
Signed-off-by: NBhavesh Parekh <bparekh@nvidia.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

If we have debugging enabled and switching to R/O mode because of an error -
dump the stack to improve UBI error reporting and make the further diagnostics
easier to do.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Current layout does not allow us to add inline functions to debug.h which use
the 'struct ubi_device' object, because it is undefined there. Move
'#include "debug.h"' in "ubi.h" down so to make 'struct ubi_device" be defined.
Additionally, this makes it possible to remove a bunch of forward declarations
in "debug.h". This is a preparation to the next patch.
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>

Fix checkpatch.pl errors and warnings:

* space before tab
* line over 80 characters
* include linux/ioctl.h instead of asm/ioctl.h
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>

Instead of using pre-allocated 'ubi->dbg_peb_buf' buffer in
'ubi_dbg_check_write()', dynamically allocate it when needed. The
intend is to get rid of the pre-allocated 'ubi->dbg_peb_buf' buffer
completely. And the need for this arises because we want to change
to dynamic debugging control instead of compile-time control, i.e.,
we are going to kill the CONFIG_MTD_UBI_DEBUG_PARANOID Kconfig
option, which would mean that 'ubi->dbg_peb_buf' is always allocated,
which would be wasteful.

Thus, we are getting rid of 'ubi->dbg_peb_buf', and this is a
preparation for that.
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>

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>

This patch turns static function 'check_pattern()' into a non-static
'ubi_check_pattern()'. This is just a preparation for the chages which
are coming in the next patches.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Currently UBI has one small flaw - when we read EC or VID header, but find only
0xFF bytes, we return UBI_IO_FF and do not report whether we had bit-flips or
not. In case of the VID header, the scanning code adds this PEB to the free list,
even though there were bit-flips.

Imagine the following situation: we start writing VID header to a PEB and have a
power cut, so the PEB becomes unstable. When we scan and read the PEB, we get
a bit-flip. Currently, UBI would just ignore this and treat the PEB as free. This
patch changes UBI behavior and now UBI will schedule this PEB for erasure.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

The 'UBI_IO_PEB_EMPTY' and 'UBI_IO_PEB_FREE' are essentially the same
and mean that there are only 0xFF bytes instead of headers. Simplify
UBI a little by turning them into a single 'UBI_IO_FF' error code.

Also, stop maintaining commentaries in 'ubi_io_read_vid_hdr()' which are
almost identical to commentaries in 'ubi_io_read_ec_hdr()'.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Rename UBI_IO_BAD_HDR_READ into UBI_IO_BAD_HDR_EBADMSG which is presumably more
self-documenting and readable. Indeed, the '_READ' suffix does not tell much and
even confuses, while '_EBADMSG' tells about uncorrectable ECC error, because we
use -EBADMSG all over the place to represent ECC errors.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This patch introduces the %UBI_IO_BAD_HDR_READ return code for
the I/O level function. We will use this code in order to distinguish
between "corrupted header possibly because this is non-ubi data" and
"corrupted header possibly because of real data corruption and ECC error".

So far this patch does not introduce any functional change, just a
preparation.

This patch is pased on a patch from
Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reviewed-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Tested-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>

We do not really need 2 separate error codes for indicating bad VID
and bad EC headers (UBI_IO_BAD_EC_HDR, UBI_IO_BAD_VID_HDR), it is
enough to have only one UBI_IO_BAD_HDR return code.

This patch does not introduce any functional change, only some
code simplification.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reviewed-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Tested-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>