pm_runtime_get_sync() will increment pm usage at first and it
will resume the device later. If runtime of the device has
error or device is in inaccessible state(or other error state),
resume operation will fail. If we do not call put operation to
decrease the reference, it will result in reference leak in
the two functions(gpmi_init and gpmi_nfc_exec_op). Moreover,
this device cannot enter the idle state and always stay busy or
other non-idle state later. So we fixed it through adding
pm_runtime_put_noidle.
Fixes: 5bc6bb603b ("mtd: rawnand: gpmi: Fix suspend/resume problem")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Acked-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201107110552.1568742-1-zhangqilong3@huawei.com
If an error happens in mtd_device_parse_register or mtd_device_register,
memory allocated for struct platram_info is leaked.
Make platram_probe() call platram_remove() on all error paths
after struct platram_info allocation to correctly free resources.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Baskov Evgeiny <baskov@ispras.ru>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201113160537.899-1-baskov@ispras.ru
While working a bit on this driver I dropped the platform includes and
commented a few lines just to verify the correctness of my changes. It
appeared the following:
drivers/mtd/nand/raw/au1550nd.c: In function ‘au1550nd_waitrdy’:
drivers/mtd/nand/raw/au1550nd.c:130:3: error: implicit declaration of function ‘usleep_range’ [-Werror=implicit-function-declaration]
usleep_range(10, 100);
^~~~~~~~~~~~
drivers/mtd/nand/raw/au1550nd.c: In function ‘au1550nd_exec_instr’:
drivers/mtd/nand/raw/au1550nd.c:188:3: error: implicit declaration of function ‘ndelay’ [-Werror=implicit-function-declaration]
ndelay(instr->delay_ns);
^~~~~~
I think the delay.h header should be included in this file and not
come from one of its platform includes, so let's add it here.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201113124021.32675-1-miquel.raynal@bootlin.com
The NAND ECC core is included in the generic NAND core when it is
compiled in.
Different software ECC engines drivers will select the NAND ECC core
and thus also have a dependency on the NAND core. Using a "depends on"
between the two leads to possible cases (not real cases, but created
by robots) where one is still unselected because of the "select does
not verifies depends on" game:
WARNING: unmet direct dependencies detected for MTD_NAND_ECC
Depends on [n]: MTD [=m] && MTD_NAND_CORE [=n]
Selected by [m]:
- MTD_NAND_ECC_SW_HAMMING [=y] && MTD [=m]
- MTD_NAND_ECC_SW_BCH [=y] && MTD [=m]
Fix this by using a select instead.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Link: https://lore.kernel.org/linux-mtd/20201113123945.32592-1-miquel.raynal@bootlin.com
Moving files around produced the following warnings:
Error: Cannot open file drivers/mtd/nand/raw/nand_ecc.c
Error: Cannot open file drivers/mtd/nand/raw/nand_ecc.c
Fix one by just dropping the reference because it is not relevant, the
other by using a better noun instead of a file name.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201113123831.32429-1-miquel.raynal@bootlin.com
This code has been written in 2008 and is fine, but in order to keep
robots happy, I think it's time to change a little bit this code just
to clarify the different possible values of eccsize_mult. Indeed, this
variable may only take the value 1 or 2 because step_size, in the case
of the software Hamming ECC engine may only be 256 or 512. Depending
on the value of eccsize_mult, an extra rp17 variable is set, or not
and triggers the following warning:
smatch warnings:
ecc_sw_hamming_calculate() error: uninitialized symbol 'rp17'.
As highlighted by Dan Carpenter, if the only possible values for
eccsize_mult are 1 and 2, then the code is fine, but "it's hard to
tell just from looking".
So instead of shifting step_size, let's use a ternary condition to
assign to eccsize_mult the only two possible values and clarify the
driver's logic.
Now that the situation is clarified for humans, ensure rp17 is
initialized to 0 to keep compilers and robots silent as well.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201030172333.28390-1-miquel.raynal@bootlin.com
This patch enables NAND MDMA (MBUS DMA) mode for
the Allwinner SoCs A23/A33/H3.
The DMA transfer method gets sets now to MBUS DMA as default for
the sun8i-a23-nand-controller (till now DMA transfer was executed
via the shared DMA engine).
The main advantage is more bandwidth for the users of the shared DMA
engine and also that the MBUS DMA setup requires less configuration
effort. For example you don't need to define a dedicated DMA channel
in the device-tree any more.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Manuel Dipolt <manuel.dipolt@robart.cc>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/154840787.280672.1602517282173.JavaMail.zimbra@robart.cc
Even if this is not supposed to happen, there is no reason to fail the
probe if it was explicitly requested to use no ECC engine at all (for
instance, during development). This condition is met by just
commenting out the error on the OOB free bytes count after the
assignation of an ECC engine if none was provided (any other situation
would error out much earlier anyway).
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-5-miquel.raynal@bootlin.com
Now that all the logic is available in the NAND core, let's use it
from the SPI-NAND core. Right now there is no functional change as the
default ECC engine for SPI-NANDs is set to 'on-die', but user can now
use software correction if they want to by just setting the right
properties in the DT.
Also note that the OOB layout handling is removed from the SPI-NAND
core as each ECC engine is supposed to handle it by it's own; users
should not be aware of that.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-4-miquel.raynal@bootlin.com
This property does not describe very well its purpose: it describes
the ECC engine type. Deprecate it in favor of nand-ecc-engine which
points to either the NAND part itself in case of on-die ECC, or to the
parent node in case of an integrated ECC engine in the NAND controller
(previously referred as "hardware") or to another node in case of an
external controller. Other "modes" (none/software) are achieved with
the new nand-use-soft-ecc-engine and nand-no-ecc-engine properties.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-3-miquel.raynal@bootlin.com
Add the logic in the NAND core to find the right ECC engine depending
on the NAND chip requirements and the user desires. Right now, the
choice may be made between (more will come):
* software Hamming
* software BCH
* on-die (SPI-NAND devices only)
Once the ECC engine has been found, the ECC engine must be
configured.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-2-miquel.raynal@bootlin.com
Let's continue introducing the generic ECC engine abstraction in the
NAND subsystem by instantiating a first ECC engine: the software
BCH one.
While at it, make a very tidy ecc_sw_bch_init() function and move all
the sanity checks and user input management in
nand_ecc_sw_bch_init_ctx(). This second helper will be called from the
raw RAND core.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-10-miquel.raynal@bootlin.com
These functions must be usable by the main NAND core, so their names
must be technology-agnostic as well as the parameters. Hence, we pass
a generic nand_device instead of a raw nand_chip structure.
As it seems that changing the raw NAND functions to always pass a
generic NAND device is a lost of time, we prefer to create dedicated
raw NAND wrappers that will be useful in the near future to do the
translation.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-8-miquel.raynal@bootlin.com
