Jumping to 'map_failed' label is not correct at these points, as it misses to
disable the clocks that were previously enabled.
Jump to 'irq_failed' label instead that will correctly disable the clocks.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Han Xu <han.xu@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The if and the else branch code are identical - so the condition has no
effect on the effective code. This patch removes the condition and the
duplicated code and updates the documentation as suggested by
Roger Quadros <rogerq@ti.com>.
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Reviewed-by: Pekon Gupta <pekon@pek-sem.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Use the GPIO descriptor API instead of the deprecated legacy GPIO API to
manage the busy GPIO.
The patch updates both the jz4740 nand driver and the only user of the driver
the qi-lb60 board driver.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Previously, we requested that drivers pass ecc.size and ecc.bytes when
using NAND_ECC_SOFT_BCH. However, a driver is likely to only know the ECC
strength required for its NAND, so each driver would need to perform a
strength-to-bytes calculation.
Avoid duplicating this calculation in each driver by asking drivers to
pass ecc.size and ecc.strength so that the strength-to-bytes calculation
need only be implemented once.
This reverts/generalizes this commit:
mtd: nand: Base BCH ECC bytes on required strength
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The recently added mtd_mmap_capabilities can be used from loadable
modules, in particular romfs, but is not exported, so we get
ERROR: "mtd_mmap_capabilities" [fs/romfs/romfs.ko] undefined!
This adds the missing export.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: b4caecd480 ("fs: introduce f_op->mmap_capabilities for nommu mmap support")
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Fastmap can miss a PEB if it is in the protection queue
and not jet in the used tree.
Treat every protected PEB as used.
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
UBI uses positive function return codes internally, and should not propagate
them up, except in the place this path fixes. Here is the original bug report
from Dan Carpenter:
The problem is really in ubi_eba_read_leb().
drivers/mtd/ubi/eba.c
412 err = ubi_io_read_vid_hdr(ubi, pnum, vid_hdr, 1);
413 if (err && err != UBI_IO_BITFLIPS) {
414 if (err > 0) {
415 /*
416 * The header is either absent or corrupted.
417 * The former case means there is a bug -
418 * switch to read-only mode just in case.
419 * The latter case means a real corruption - we
420 * may try to recover data. FIXME: but this is
421 * not implemented.
422 */
423 if (err == UBI_IO_BAD_HDR_EBADMSG ||
424 err == UBI_IO_BAD_HDR) {
425 ubi_warn("corrupted VID header at PEB %d, LEB %d:%d",
426 pnum, vol_id, lnum);
427 err = -EBADMSG;
428 } else
429 ubi_ro_mode(ubi);
On this path we return UBI_IO_FF and UBI_IO_FF_BITFLIPS and it
eventually gets passed to ERR_PTR(). We probably dereference the bad
pointer and oops. At that point we've gone read only so it was already
a bad situation...
430 }
431 goto out_free;
432 } else if (err == UBI_IO_BITFLIPS)
433 scrub = 1;
434
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Let's prefix UBI messages with 'ubiX' instead of 'UBI-X' - this is more
consistent with the way we name UBI devices.
Also, commit "32608703 UBI: Extend UBI layer debug/messaging capabilities"
added the function name print to 'ubi_msg()' - lets revert this change, since
these messages are supposed to be just informative messages, and not debugging
messages.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Adds a new set of functions to deal with scatter gather.
ubi_eba_read_leb_sg() will read from a LEB into a scatter gather list.
The new data structure struct ubi_sgl will be used within UBI to
hold the scatter gather list itself and metadata to have a cursor
within the list.
Signed-off-by: Richard Weinberger <richard@nod.at>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
UBI_METAONLY is a new open mode for UBI volumes, it indicates
that only meta data is being changed.
Meta data in terms of UBI volumes means data which is stored in the
UBI volume table but not on the volume itself.
While it does not interfere with UBI_READONLY and UBI_READWRITE
it is not allowed to use UBI_METAONLY together with UBI_EXCLUSIVE.
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: Andrew Murray <amurray@embedded-bits.co.uk>
Signed-off-by: Richard Weinberger <richard@nod.at>
Tested-by: Guido Martínez <guido@vanguardiasur.com.ar>
Reviewed-by: Guido Martínez <guido@vanguardiasur.com.ar>
Tested-by: Christoph Fritz <chf.fritz@googlemail.com>
Tested-by: Andrew Murray <amurray@embedded-bits.co.uk>
The MTD API reports -EUCLEAN only if the maximum number of bitflips
found in any ECC block exceeds a certain threshold. This is done to
avoid excessive -EUCLEAN reports to MTD users, which may induce
additional scrubbing of data, even when the ECC algorithm in use is
perfectly capable of handling the bitflips.
This threshold can be controlled by user-space (via sysfs), to allow
users to determine what they are willing to tolerate in their
application. But it still helps to have sane defaults.
In recent discussion [1], it was pointed out that our default threshold
is equal to the correction strength. That means that we won't actually
report any -EUCLEAN (i.e., "bitflips were corrected") errors until there
are almost too many to handle. It was determined that 3/4 of the
correction strength is probably a better default.
[1] http://lists.infradead.org/pipermail/linux-mtd/2015-January/057259.html
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <shijie.huang@intel.com>
Since "BDI: Provide backing device capability information [try #3]" the
backing_dev_info structure also provides flags for the kind of mmap
operation available in a nommu environment, which is entirely unrelated
to it's original purpose.
Introduce a new nommu-only file operation to provide this information to
the nommu mmap code instead. Splitting this from the backing_dev_info
structure allows to remove lots of backing_dev_info instance that aren't
otherwise needed, and entirely gets rid of the concept of providing a
backing_dev_info for a character device. It also removes the need for
the mtd_inodefs filesystem.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Tejun Heo <tj@kernel.org>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Since in SAMA5D4 chip, the PMECC can correct bit flips in erased page.
So we add a DT property to indicate this hardware character.
If the PMECC support correct bitflip erased page (all data are 0xff).
Then we can use the PMECC correct the page and skip the erased page
check.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
atmel_nand_pmecc_read_page() will return the total bitflips in this
page. This is incorrect.
As one nand page includes multiple ecc sectors, that will cause the
returned total bitflips exceed ecc capablity.
So this patch will make pmecc_correct() return the max bitflips of all
sectors in the page. That also makes atmel_nand_pmecc_read_page() return
the max bitflips.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
When removing the fsl-quadspi module and running 'cat /proc/mtd' afterwards,
we see garbage data like:
$ rmmod fsl-quadspi
$ cat /proc/mtd
dev: size erasesize name
mtd0: 00000000 00000000 "(null)"
mtd0: 00000000 00000000 "(null)"
mtd0: 00000000 00000000 "(null)"
...
mtd0: a22296c6c756e28 00000000 "(null)"
mtd0: a22296c6c756e28 3064746d "(null)"
If we continue doing multiple module load/unload operations, then it will also
lead to a kernel crash.
The reason for this is due to the wrong mtd index used in
mtd_device_unregister() in the remove function.
We need to keep the mtd unregister index aligned with the one used in the probe
function, which means we need to take into account the 'has_second_chip'
property. By doing so we can guarantee that the mtd index is the same in the
registration and unregistration functions.
With this patch applied we can load/unload the fsl-quadspi driver several times
and it will result in no crash.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Huang Shijie <shijie.huang@intel.com>
Tested-by: Frank Li <Frank.Li@freescale.com>
Acked-by: Allen Xu <han.xu@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
In initialization routine, mtd_info->owner is overwritten by memset()
just after being initialized. This can be fixed by moving memset() calls
to just before setting mtd_info->owner. But the memory region is allocated
by kmalloc, so we can fix it by using kzalloc instead of kmalloc.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Jonathan McDowell <noodles@earth.li>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
i.mx6 sx support turn off fastmix and megamix power.
qpsi controller can be turned off and all status lost when suspend/resume.
add suspend/resume functions and reset qspi controller when resume.
Signed-off-by: Allen Xu <b45815@freescale.com>
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Acked-by: Huang Shijie <shijie.huang@intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
drivers/mtd/devices/st_spi_fsm.c:1647:17:
warning: comparison between signed and unsigned integer expressions
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
ST's Common Clk Framework is now available. This patch ensures the FSM
makes use of it by obtaining and enabling the EMI clock. If system fails
to provide the EMI clock, we bomb out.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Under certain conditions, the SPI-FSM Controller can be left in a state where
the data FIFO is not entirely empty. This can lead to problems where subsequent
data transfers appear to have been shifted by a number of unidentified bytes.
One simple example would be an errant FSM sequence which loaded more data to the
FIFO than was read by the host. Another more interesting case results from an
obscure artefact in the FSM Controller. When switching from data transfers in
x4 or x2 mode to data transfers in x1 mode, extraneous bytes will appear in the
FIFO, unless the previous data transfer was a multiple of 32 cycles (i.e. 8
bytes for x2, and 16 bytes for x4). This applies equally whether FSM is being
operated directly by a S/W driver, or by the SPI boot-controller in FSM-Boot
mode. Furthermore, data in the FIFO not only survive a transition between
FSM-Boot and FSM, but also a S/W reset of IP block [1].
By taking certain precautions, it is possible to prevent the driver from causing
this type of problem (e.g. ensuring that the host and programmed sequence
agree on the transfer size, and restricting transfer sizes to multiples of
32-cycles [2]). However, at the point the driver is loaded, no assumptions can be
made regarding the state of the FIFO. Even if previous S/W drivers have behaved
correctly, it is impossible to control the number of transactions serviced by
the controller operating in FSM-Boot.
To address this problem, we ensure the FIFO is cleared during initialisation,
before performing any FSM operations. Previously, the fsm_clear_fifo() code was
capable of detecting and clearing any unwanted 32-bit words from the FIFO. This
patch extends the capability to handle an arbitrary number of bytes present in
the FIFO [3]. Now that the issue is better understood, we also remove the calls
to fsm_clear_fifo() following the fsm_read() and fsm_write() operations.
The process of actually clearing the FIFO deserves a mention. While the FIFO
may contain any number of bytes, the SPI_FAST_SEQ_STA register only reports the
number of complete 32-bit words present. Furthermore, data can only be drained
from the FIFO by reading complete 32-bit words. With this in mind, a two stage
process is used to the clear the FIFO:
1. Read any complete 32-bit words from the FIFO, as reported by the
SPI_FAST_SEQ_STA register.
2. Mop up any remaining bytes. At this point, it is not known if there
are 0, 1, 2, or 3 bytes in the FIFO. To handle all cases, a dummy
FSM sequence is used to load one byte at a time, until a complete
32-bit word is formed; at most, 4 bytes will need to be loaded.
[1] Although this issue has existed since early versions of the SPI-FSM
controller, its full extent only emerged recently as a consequence of the
targetpacks starting to use FSM-Boot(x4) as the default configuration.
[2] The requirement to restrict transfers to multiples of 32 cycles was found
empirically back when DUAL and QUAD mode support was added. The current
analysis now gives a satisfactory explanation for this requirement.
[3] Theoretically, it is possible for the FIFO to contain an arbitrary number of
bits. However, since there are no known use-cases that leave incomplete
bytes in the FIFO, only words and bytes are considered here.
Signed-off-by: Angus Clark <angus.clark@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
UBI needs to know the physical erase block size, even on read-only
devices, since it defines the on-device layout. Use a device-tree
provided value to support previously written UBI on read-only NOR.
UBI also needs a non-zero writebufsize, so we set it to one.
Note: This was implemented because hardware write-protected CFI
NOR cannot be probed for the physical erase block size.
Signed-off-by: Joe Schultz <jschultz@xes-inc.ccom>
Signed-off-by: Aaron Sierra <asierra@xes-inc.ccom>
[Brian: removed unneeded #ifdef, note 'optional' erase-size property]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Previously, when probing a CFI chip which was write-protected at the
hardware level, the probe would fail due to the fact it could not put
the chip into QUERY mode. This would result in no MTD devices being
created.
Add a fallback to probe using the map_rom driver if the user-selected
probe fails.
Signed-off-by: Joe Schultz <jschultz@xes-inc.com>
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Commit 7854d3f749 ("mtd: spelling, capitalization, uniformity") added
a correctly spelled line, but failed to remove the wrongly spelled one.
Commit 064a7694b5 ("mtd: Fix typo mtd/tests") then fixed the spelling
again, but left the duplication.
Fixes: 7854d3f749 ("mtd: spelling, capitalization, uniformity")
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add nand_shutdown to wait for current nand operations to finish and prevent
further operations by changing the nand flash state to FL_SHUTDOWN.
This is addressing a problem observed during reboot tests using UBIFS
root file system: NAND erase operations that are in progress during
system reboot/shutdown are causing partial erased blocks. Although UBI should
be able to detect and recover from this error, this change will avoid
the creation of partial erased blocks on reboot in the middle of a NAND erase
operation.
Signed-off-by: Scott Branden <sbranden@broadcom.com>
Tested-by: Scott Branden <sbranden@broadcom.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
cfi_cmdset_000{1,2}.c already implement their own reboot notifiers, and
we're going to add one for NAND. Let's put the boilerplate in one place.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Scott Branden <sbranden@broadcom.com>
The global lock mtdblks_lock was used to protect the original mtdblks
array to avoid race conditions. As the mtdblks array was already gone,
but the mtdblks_lock is left, and it causes latency when open/release dev.
So we need to remove it here.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
SquashFS is supposed to use magic defined as SQUASHFS_MAGIC. What we
were supporting so far (SQSH_MAGIC) is something ZTE specific.
This patch adds support for Xiaomi R1D.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Some devices like Netgear WNR1000v3 or WGR614v10 have partitions aligned
to 0x1000. Using bigger blocksize stopped us from detecting some parts.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash, enabling or disabling quad I/O protocol can be
done By two methods, which are to use EVCR (Enhanced Volatile
Configuration Register) and the ENTER QUAD I/O MODE command. There is no
difference between these two methods. Unfortunately, for some Micron SPI
NOR flashes, there no ENTER Quad I/O command (35h), such as n25q064. But
for all current Micron SPI NOR, if it support quad I/O mode, using EVCR
definitely be supported. It is a recommended method to enable Quad I/O
mode by EVCR, Quad I/O protocol bit 7. When EVCR bit 7 is reset to 0,
the SPI NOR flash will operate in quad I/O mode.
This patch has been tested on N25Q512A and MT25TL256BAA1ESF. Micron SPI
NOR of spi_nor_ids[] table all support this method.
Signed-off-by: Bean Huo <beanhuo@micron.com>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
mx28evk board has a socket for NAND flash that comes with no NAND flash
populated, and then we get this message on every boot:
[ 1.657603] gpmi-nand 8000c000.gpmi-nand: driver registration failed: -19
which is not very helpful, so get rid of this error message.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Pull MTD updates from Brian Norris:
"Summary:
- Add device tree support for DoC3
- SPI NOR:
Refactoring, for better layering between spi-nor.c and its
driver users (e.g., m25p80.c)
New flash device support
Support 6-byte ID strings
- NAND:
New NAND driver for Allwinner SoC's (sunxi)
GPMI NAND: add support for raw (no ECC) access, for testing
purposes
Add ATO manufacturer ID
A few odd driver fixes
- MTD tests:
Allow testers to compensate for OOB bitflips in oobtest
Fix a torturetest regression
- nandsim: Support longer ID byte strings
And more"
* tag 'for-linus-20141215' of git://git.infradead.org/linux-mtd: (63 commits)
mtd: tests: abort torturetest on erase errors
mtd: physmap_of: fix potential NULL dereference
mtd: spi-nor: allow NULL as chip name and try to auto detect it
mtd: nand: gpmi: add raw oob access functions
mtd: nand: gpmi: add proper raw access support
mtd: nand: gpmi: add gpmi_copy_bits function
mtd: spi-nor: factor out write_enable() for erase commands
mtd: spi-nor: add support for s25fl128s
mtd: spi-nor: remove the jedec_id/ext_id
mtd: spi-nor: add id/id_len for flash_info{}
mtd: nand: correct the comment of function nand_block_isreserved()
jffs2: Drop bogus if in comment
mtd: atmel_nand: replace memcpy32_toio/memcpy32_fromio with memcpy
mtd: cafe_nand: drop duplicate .write_page implementation
mtd: m25p80: Add support for serial flash Spansion S25FL132K
MTD: m25p80: fix inconsistency in m25p_ids compared to spi_nor_ids
mtd: spi-nor: improve wait-till-ready timeout loop
mtd: delete unnecessary checks before two function calls
mtd: nand: omap: Fix NAND enumeration on 3430 LDP
mtd: nand: add ATO manufacturer info
...
Pull driver core update from Greg KH:
"Here's the set of driver core patches for 3.19-rc1.
They are dominated by the removal of the .owner field in platform
drivers. They touch a lot of files, but they are "simple" changes,
just removing a line in a structure.
Other than that, a few minor driver core and debugfs changes. There
are some ath9k patches coming in through this tree that have been
acked by the wireless maintainers as they relied on the debugfs
changes.
Everything has been in linux-next for a while"
* tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
fs: debugfs: add forward declaration for struct device type
firmware class: Deletion of an unnecessary check before the function call "vunmap"
firmware loader: fix hung task warning dump
devcoredump: provide a one-way disable function
device: Add dev_<level>_once variants
ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
ath: use seq_file api for ath9k debugfs files
debugfs: add helper function to create device related seq_file
drivers/base: cacheinfo: remove noisy error boot message
Revert "core: platform: add warning if driver has no owner"
drivers: base: support cpu cache information interface to userspace via sysfs
drivers: base: add cpu_device_create to support per-cpu devices
topology: replace custom attribute macros with standard DEVICE_ATTR*
cpumask: factor out show_cpumap into separate helper function
driver core: Fix unbalanced device reference in drivers_probe
driver core: fix race with userland in device_add()
sysfs/kernfs: make read requests on pre-alloc files use the buffer.
sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
fs: sysfs: return EGBIG on write if offset is larger than file size
...
The torture test should quit once it actually induces an error in the
flash. This step was accidentally removed during refactoring.
Without this fix, the torturetest just continues infinitely, or until
the maximum cycle count is reached. e.g.:
...
[ 7619.218171] mtd_test: error -5 while erasing EB 100
[ 7619.297981] mtd_test: error -5 while erasing EB 100
[ 7619.377953] mtd_test: error -5 while erasing EB 100
[ 7619.457998] mtd_test: error -5 while erasing EB 100
[ 7619.537990] mtd_test: error -5 while erasing EB 100
...
Fixes: 6cf78358c9 ("mtd: mtd_torturetest: use mtd_test helpers")
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <stable@vger.kernel.org>
On device remove, when testing the cmtd field of an of_flash
struct to decide whether it is a concatenated device or not,
we get a false positive on cmtd == NULL, and dereference it
subsequently. This may occur if of_flash_remove() is called
from the cleanup path of of_flash_probe().
Instead, test for NULL first, and only then perform the test
for a concatenated device.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This will allow spi-nor users to plainly use JEDEC to detect flash chip.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Several MTD users (either in user or kernel space) expect a valid raw
access support to NAND chip devices.
This is particularly true for testing tools which are often touching the
data stored in a NAND chip in raw mode to artificially generate errors.
The GPMI drivers do not implemenent raw access functions, and thus rely on
default HW_ECC scheme implementation.
The default implementation consider the data and OOB area as properly
separated in their respective NAND section, which is not true for the GPMI
controller.
In this driver/controller some OOB data are stored at the beginning of the
NAND data area (these data are called metadata in the driver), then ECC
bytes are interleaved with data chunk (which is similar to the
HW_ECC_SYNDROME scheme), and eventually the remaining bytes are used as
OOB data.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Huang Shijie <shijie8@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add a new function to copy bits (not bytes) from a memory region to
another one.
This function is similar to memcpy except it acts at bit level.
It is needed to implement GPMI raw access functions and adapt to the
hardware ECC engine which does not pad ECC bits to the next byte boundary.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Huang Shijie <shijie8@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
