- 31 May, 2020 18 commits
-
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-21-miquel.raynal@bootlin.com
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
Not sure nand_cleanup() is the right function to call here but in any case it is not nand_release(). Indeed, even a comment says that calling nand_release() is a bit of a hack as there is no MTD device to unregister. So switch to nand_cleanup() for now and drop this comment. There is no Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f9 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if it did not intruce any bug. Fixes: d44154f9 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-12-miquel.raynal@bootlin.com
-
Miquel Raynal authored
Denali driver keeps track of devices with a list. Delete items of this list as long as they are not in use anymore. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
- 26 May, 2020 2 commits
-
-
Miquel Raynal authored
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Let's stop using nand_release() by calling mtd_device_unregister() and nand_cleanup() directly. Signed-off-by:
-
Miquel Raynal authored
Add support for the hardware ECC BCH engine. Please mind that this engine has an important limitation: BCH implementation does not inform the user when an uncorrectable ECC error occurs. To workaround this, we avoid using the hardware engine in the read path and do the computation with the software BCH implementation, which is faster than mixing hardware (for correction) and software (for verification). Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200519074549.23673-9-miquel.raynal@bootlin.com
-
- 24 May, 2020 20 commits
-
-
Miquel Raynal authored
Add the Arasan NAND controller driver. This brings only NAND controller support. The ECC engine being a bit subtle, hardware ECC support will be added in a second time. This work is based on contributions from Naga Sureshkumar Relli. Signed-off-by:
-
Miquel Raynal authored
Document the Arasan NAND controller bindings. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/linux-mtd/20200519074549.23673-7-miquel.raynal@bootlin.com
-
Miquel Raynal authored
Fill a new entry for the Arasan NAND controller. Signed-off-by:
-
Miquel Raynal authored
There are cases where ECC bytes are not byte-aligned. Indeed, BCH implies using a number of ECC bits, which are not always a multiple of 8. We then need a helper like nand_extract_bits() to extract these syndromes from a buffer. Signed-off-by:
-
Miquel Raynal authored
The main NAND read page function can loop over "page reads" many times in if the reading reports uncorrectable error(s) and if the chip supports the read_retry feature. In this case, the number of bitflips is summarized between attempts. Fix this by re-initializing the entire mtd_ecc_stats object each time we retry. Suggested-by:
-
Miquel Raynal authored
It seems that several hardware ECC engine use a swapped representation of bytes compared to software. This might having to do with how the ECC engine is wired to the NAND controller or the order the bits are passed to the hardware BCH logic. This means that when the software BCH engine is working in conjunction with data generated with hardware, sometimes we might need to swap the bits inside bytes, eg: 0x0A = b0000_1010 -> b0101_0000 = 0x50 Make it possible by adding a boolean to the BCH initialization routine. Regarding the implementation itself, this is a rather simple approach that can probably be enhanced in the future by preparing the ->a_{mod,pow}_tab tables with the swapping in mind. Suggested-by: -
Miquel Raynal authored
There are four exported functions, all suffixed by _bch, which is clearly not the norm. Let's rename them by prefixing them with bch_ instead. This is a mechanical change: init_bch -> bch_init free_bch -> bch_free encode_bch -> bch_encode decode_bch -> bch_decode Signed-off-by: -
Miquel Raynal authored
There are controllers not able to just read data cycles on the bus. There are controllers not able to do a change column. If we want to support both, we need to check which operation is supported first. This is the exact same mechanism that is in use for parameter page reads (ONFI/JEDEC) as the same problem occurs. Speed testing does not show any throughput penalty so we do not optimize more than that. However it is likely that, in the future, a more robust and exhaustive test will run at boot time to avoid re-checking what is supported and what is not at every call. Signed-off-by:
-
Boris Brezillon authored
The CM-X270 board has been removed, we can remove the custom NAND driver as well. Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Boris Brezillon authored
Mimic what's done in nand_soft_waitrdy() and add one to the jiffies timeout so we don't end up waiting less than actually required. Reported-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Fixes: b0e137ad ("mtd: rawnand: Provide helper for polling GPIO R/B pin") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Boris Brezillon authored
Now that exec_op() is implemented we can get rid of the legacy interface implementation. Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
-
Boris Brezillon authored
Implement exec_op() so we can later get rid of the legacy interface implementation. Signed-off-by:
-
Boris Brezillon authored
We can use info->current_cs directly instead of doing this weird IO_ADDR_{R,W} re-assignment dance. Signed-off-by: -
Boris Brezillon authored
Let's not rely on the dummy_controller embedded in nand_chip.legacy and explicitly inherit from nand_controller instead. Signed-off-by:
-
Álvaro Fernández Rojas authored
The current code checks that the whole OOB area is erased. This is a problem when JFFS2 cleanmarkers are added to the OOB, since it will fail due to the usable OOB bytes not being 0xff. Correct this by only checking that data and ECC bytes aren't 0xff. Fixes: 02b88eea ("mtd: brcmnand: Add check for erased page bitflips") Signed-off-by:
Álvaro Fernández Rojas <noltari@gmail.com> Signed-off-by:
-
Álvaro Fernández Rojas authored
The current code generates 8 oob sections: S1 1-5 ECC 6-8 S2 9-15 S3 16-21 ECC 22-24 S4 25-31 S5 32-37 ECC 38-40 S6 41-47 S7 48-53 ECC 54-56 S8 57-63 Change it by merging continuous sections: S1 1-5 ECC 6-8 S2 9-21 ECC 22-24 S3 25-37 ECC 38-40 S4 41-53 ECC 54-56 S5 57-63 Signed-off-by:
-
Álvaro Fernández Rojas authored
First 2 bytes are used in large-page nand. Fixes: ef5eeea6 ("mtd: nand: brcm: switch to mtd_ooblayout_ops") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Xiaolei's address is bouncing, remove him from MAINTAINERS and mark the driver he was maintaining, Mediatek's, as orphaned. Signed-off-by:
-
Miquel Raynal authored
Piotr's address is bouncing, remove him from MAINTAINERS and mark the driver he was maintaining, Cadence's, as orphaned. Signed-off-by:
-
Boris Brezillon authored
Some controller using the instruction parse infrastructure might need to know which CS a specific sub-operation is targeting. Let's propagate this information. Signed-off-by:
-
