Miquel Raynal [Tue, 19 May 2020 13:00:15 +0000 (15:00 +0200)]
mtd: rawnand: plat_nand: Fix the probe error path
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible, hence pointing it as the commit to
fix for backporting purposes, even if this commit is not introducing
any bug.
Miquel Raynal [Tue, 19 May 2020 13:00:13 +0000 (15:00 +0200)]
mtd: rawnand: pasemi: Fix the probe error path
nand_cleanup() is supposed to be called on error after a successful
call to nand_scan() to free all NAND resources.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible, hence pointing it as the commit to
fix for backporting purposes, even if this commit is not introducing
any bug.
Miquel Raynal [Tue, 19 May 2020 13:00:06 +0000 (15:00 +0200)]
mtd: rawnand: orion: Fix the probe error path
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("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 this commit is not
introducing any bug.
Miquel Raynal [Tue, 19 May 2020 13:00:00 +0000 (15:00 +0200)]
mtd: rawnand: mtk: Fix the probe error path
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates the introduction of nand_cleanup() in
commit d44154f969a4 ("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 this commit is not
introducing any bug.
Miquel Raynal [Tue, 19 May 2020 12:59:54 +0000 (14:59 +0200)]
mtd: rawnand: ingenic: Fix the probe error path
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. Hence, pointing it as the commit to
fix for backporting purposes, even if this commit is not introducing
any bug makes sense.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: stable@vger.kernel.org Cc: Paul Cercueil <paul@crapouillou.net> Cc: Harvey Hunt <harveyhuntnexus@gmail.com> Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-22-miquel.raynal@bootlin.com
Miquel Raynal [Tue, 19 May 2020 12:59:45 +0000 (14:59 +0200)]
mtd: rawnand: diskonchip: Fix the probe error path
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 d44154f969a4 ("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.
Miquel Raynal [Tue, 19 May 2020 07:45:49 +0000 (09:45 +0200)]
mtd: rawnand: arasan: Support the hardware BCH ECC engine
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).
Miquel Raynal [Tue, 19 May 2020 07:45:48 +0000 (09:45 +0200)]
mtd: rawnand: arasan: Add new Arasan NAND controller
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.
Miquel Raynal [Tue, 19 May 2020 07:45:45 +0000 (09:45 +0200)]
mtd: rawnand: Add nand_extract_bits()
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.
Miquel Raynal [Tue, 19 May 2020 07:45:44 +0000 (09:45 +0200)]
mtd: rawnand: Ensure the number of bitflips is consistent
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.
Miquel Raynal [Tue, 19 May 2020 07:45:43 +0000 (09:45 +0200)]
lib/bch: Allow easy bit swapping
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.
Miquel Raynal [Tue, 19 May 2020 13:08:34 +0000 (15:08 +0200)]
mtd: rawnand: micron: Adapt the PAGE READ flow to constraint controllers
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.
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.
Boris Brezillon [Tue, 5 May 2020 10:13:35 +0000 (12:13 +0200)]
mtd: rawnand: Propage CS selection to sub operations
Some controller using the instruction parse infrastructure might need
to know which CS a specific sub-operation is targeting. Let's propagate
this information.
Christophe Kerello [Tue, 12 May 2020 11:47:47 +0000 (13:47 +0200)]
mtd: rawnand: stm32_fmc2: cosmetic change to use nfc instead of fmc2 where relevant
This patch renames functions and local variables.
This cleanup is done to get all functions starting by stm32_fmc2_nfc
in the FMC2 raw NAND driver when all functions will start by
stm32_fmc2_ebi in the FMC2 EBI driver.
Christophe Kerello [Wed, 6 May 2020 09:11:12 +0000 (11:11 +0200)]
mtd: rawnand: stm32_fmc2: use FMC2_TIMEOUT_MS for timeouts
This patch removes the constant FMC2_TIMEOUT_US.
FMC2_TIMEOUT_MS will be used each time that we need to wait (except
when the timeout value is set by the framework).
It was seen, during stress tests with the sequencer in an overloaded
system, that we could be close to 1 second, even if we never met this
value. To be safe, FMC2_TIMEOUT_MS is set to 5 seconds.
Boris Brezillon [Fri, 1 May 2020 14:39:16 +0000 (16:39 +0200)]
mtd: rawnand: diskonchip: Implement exec_op()
Implement exec_op() so we can later get rid of the legacy
implementation.
It's worth noting that the new implementation assert/deassert the CE
pin on each operation, which might not be necessary. We also dropped
the extra reset done at chip selection time on DOC2001plus. If it's
needed we really should do something smarter, because having a reset
everytime we access the chip is not that great perf-wise.
Boris Brezillon [Fri, 1 May 2020 14:39:13 +0000 (16:39 +0200)]
mtd: rawnand: diskonchip: Make sure doc2001plus_readbuf() works for single byte reads
Single byte accesses normally go through read_byte() but we are about
to use this function in the exec_op() implementation and thus needs to
prepare for single byte reads.
Boris Brezillon [Mon, 11 May 2020 06:49:15 +0000 (08:49 +0200)]
mtd: rawnand: Add a NAND_NO_BBM_QUIRK flag
Some controllers with embedded ECC engines override the BBM marker with
data or ECC bytes, thus making bad block detection through bad block
marker impossible. Let's flag those chips so the core knows it shouldn't
check the BBM and consider all blocks good.
This should allow us to get rid of two implementers of the
legacy.block_bad() hook.
Miquel Raynal [Thu, 7 May 2020 10:52:41 +0000 (12:52 +0200)]
mtd: rawnand: micron: Allow controllers to overload raw accessors
Some controller drivers do not support executing regular
nand_read/write_page_raw() helpers. For that, we created
nand_monolithic_read/write_page_raw() alternatives. Let's now allow
the driver to overload the ECC ->read/write_page_raw() hooks when
these hooks are supported.
Miquel Raynal [Thu, 7 May 2020 10:52:40 +0000 (12:52 +0200)]
mtd: rawnand: Allow controllers to overload soft ECC hooks
Some controller drivers do not support executing regular
nand_read/write_page_raw() helpers. For that, we created
nand_monolithic_read/write_page_raw() alternatives. Let's now allow
the driver to overload the ECC ->read/write_page_raw() hooks.
The current nand_read/write_page_raw() helpers are already widely used
but do not fit the purpose of "constrained" controllers which cannot,
for instance, separate command/address cycles with data cycles.
Workaround this issue by proposing alternative helpers that can be
used by these controller drivers instead.
Miquel Raynal [Thu, 7 May 2020 10:52:38 +0000 (12:52 +0200)]
mtd: rawnand: jedec: Adapt the parameter page read to constraint controllers
We already know that there are controllers not able to read the three
copies of the parameter page in one go. The workaround was to first
request the controller to assert command and address cycles on the
NAND bus to trigger a parameter page read, and then do a read
operation for each page.
But there are also controllers which are not able to split the
parameter page read between the command/address cycles and the actual
data operation.
Let's use a regular PARAMETER PAGE READ operation for the first
iteration and use eithe a CHANGE READ COLUMN or a simple DATA READ
operation for the following copies, depending on what the controller
supports. The default for non-exec-op compliant drivers remains
unchanged: use a SIMPLE READ.
Miquel Raynal [Thu, 7 May 2020 10:52:37 +0000 (12:52 +0200)]
mtd: rawnand: onfi: Adapt the parameter page read to constraint controllers
We already know that there are controllers not able to read the three
copies of the parameter page in one go. The workaround was to first
request the controller to assert command and address cycles on the
NAND bus to trigger a parameter page read, and then do a simple read
operation for each page.
But there are also controllers which are not able to split the
parameter page read between the command/address cycles and the actual
data operation.
Let's use a regular PARAMETER PAGE READ operation for the first
iteration and use either a CHANGE READ COLUMN or a simple DATA READ
operation for the following copies, depending on what the controller
supports. The default behavior for non-exec-op compliant drivers
remains the same: DATA READ.
Miquel Raynal [Thu, 7 May 2020 10:52:36 +0000 (12:52 +0200)]
mtd: rawnand: Give the possibility to verify a read operation is supported
This can be used to discriminate between two path in the parameter
page detection: use data_in cycles (like before) if supported, use the
CHANGE READ COLUMN command otherwise.
Miquel Raynal [Thu, 7 May 2020 10:52:34 +0000 (12:52 +0200)]
mtd: rawnand: Avoid indirect access to ->data_buf()
The logic in nand_do_read_ops() is to use a bufpoi variable, either
set to the original buffer, or set to a bounce buffer which in the end
happens to be chip->data_buf depending on the value of the
use_bounce_buf boolean. This is not a reason to call chip->data_buf
directly when we know that we are using the bounce buffer. Let's use
bufpoi instead to be consistent.
Miquel Raynal [Thu, 7 May 2020 10:52:33 +0000 (12:52 +0200)]
mtd: rawnand: Rename the use_bufpoi variables
Both in nand_do_read_ops() and nand_do_write_ops() there is a boolean
called use_bufpoi which is set to true in case of unaligned request or
when there is a need for a DMA-able buffer. It basically means "use a
bounce buffer".
Depending on the value of use_bufpoi, the bufpoi variable is always
used and will either point to the original buffer or to the nand_chip
structure "internal data buffer" (this buffer is allocated with
kmalloc() on purpose so that it will be DMA-compliant).
In all cases bufpoi is used so the boolean name is misleading. Rename
use_bufpoi to be use_bouce_buf to be more accurate.
Miquel Raynal [Thu, 7 May 2020 10:52:31 +0000 (12:52 +0200)]
mtd: rawnand: Rename a NAND chip option
NAND controller drivers can set the NAND_USE_BOUNCE_BUFFER flag to a
chip 'option' field. With this flag, the core is responsible of
providing DMA-able buffers.
The current behavior is to not force the use of a bounce buffer when
the core thinks this is not needed. So in the end the name is a bit
misleading, because in theory we will always have a DMA buffer but in
practice it will not always be a bounce buffer.
Rename this flag NAND_USES_DMA to be more accurate.
Boris Brezillon [Sun, 3 May 2020 15:53:41 +0000 (17:53 +0200)]
ubi: Relax the 'no MLC' rule and allow MLCs operating in SLC mode
The MTD layer provides an SLC mode (purely software emulation of SLC
behavior) addressing the paired-pages corruption issue, which was the
main reason for refusing attaching MLC NANDs to UBI.
Relax this rule and allow partitions that have the
MTD_EMULATE_SLC_ON_MLC flag set to be attached.
Boris Brezillon [Sun, 3 May 2020 15:53:38 +0000 (17:53 +0200)]
dt-bindings: mtd: partition: Document the slc-mode property
Add a boolean property to force a specific partition attached to an MLC
NAND to be accessed in an emulated SLC mode this making this partition
immune to paired-pages corruptions.
Boris Brezillon [Fri, 1 May 2020 09:06:47 +0000 (11:06 +0200)]
mtd: rawnand: cs553x: Declare controllers instead of NAND chips
The CS553x companion chip embeds 4 NAND controllers. Declare them as
NAND controllers instead of NAND chips. That's done in preparation
of the transition to exec_op().
projects / users / jedix / linux-maple.git / log