- 10 Dec, 2020 33 commits
-
-
Fabio Estevam authored
i.MX is a devicetree-only platform now and the existing platform data support in this driver was only useful for old non-devicetree platforms. Get rid of the platform data support since it is no longer used. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201110121908.19400-1-festevam@gmail.com
-
Yu Kuai authored
of_find_device_by_node() already takes a reference to the device, and ingenic_ecc_release() will drop the reference. So, the get_device() in ingenic_ecc_get() is redundand. Fixes: 15de8c6e("mtd: rawnand: ingenic: Separate top-level and SoC specific code") Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Acked-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Miquel Raynal authored
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:
-
Manuel Dipolt authored
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:
-
Sergei Antonov authored
Arguments 'infolen' and 'datalen' to meson_nfc_dma_buffer_release() were mixed up. Fixes: 8fae856c ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Cc: stable@vger.kernel.org Signed-off-by:
Sergei Antonov <saproj@gmail.com> Acked-by:
Liang Yang <liang.yang@amlogic.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Some identifiers have different names between their prototypes and the kernel-doc markup. Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Kathiravan T authored
Add the compatible string for IPQ6018 QPIC NAND controller version 1.5.0. It's properties are same as IPQ8074, so reuse the same. Signed-off-by:
Kathiravan T <kathirav@codeaurora.org> Signed-off-by:
-
Kathiravan T authored
Add the binding for the QPIC NAND used on IPQ6018 SoC. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Praveenkumar I authored
After each codeword NAND_FLASH_STATUS is read for possible operational failures. But there is no DMA sync for CPU operation before reading it and this leads to incorrect or older copy of DMA buffer in reg_read_buf. This patch adds the DMA sync on reg_read_buf for CPU before reading it. Fixes: 5bc36b2b ("mtd: rawnand: qcom: check for operation errors in case of raw read") Cc: stable@vger.kernel.org Signed-off-by:
Praveenkumar I <ipkumar@codeaurora.org> Signed-off-by:
-
Marco Felsch authored
The extra gpmi_nand.o object is not needed anymore since commit 3045f8e3 ("mtd: rawnand: gpmi: move all driver code into single file"). Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
-
Miquel Raynal authored
This comment is no longer true so drop it. Signed-off-by:
-
Miquel Raynal authored
So far OOB have never been used in SPI-NAND, add the missing memcpy to make it work properly. Fixes: 7529df46 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
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 authored
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 authored
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 authored
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 authored
The SPI-NAND layer default is on-die ECC because until now it was the only one supported. New SPI-NAND chip flavors might use something else as ECC engine provider but this will always be the default if the user does not choose explicitly something else. Signed-off-by:
-
Miquel Raynal authored
Before making use of the ECC engines, we must retrieve them. Add the necessary boilerplate. Signed-off-by:
-
Miquel Raynal authored
Make use of the existing functions taken from the SPI-NAND core to instantiate an on-die ECC engine specific to the SPI-NAND core. The next step will be to tweak the core to use this object instead of calling the helpers directly. Signed-off-by:
-
Miquel Raynal authored
Prepare the creation of a SPI-NAND on-die ECC engine by gathering the ECC-related code earlier enough in the core to avoid the need for forward declarations. The next step is to actually create that engine by implementing the generic ECC interface. Signed-off-by:
-
Miquel Raynal authored
One comment in the SPI-NAND core is not very clear, fix it to ease the understanding of what the block does. Signed-off-by:
-
Miquel Raynal authored
Before making use of the ECC engines, we must retrieve them. Add the boilerplate for the ones already available: software engines (Hamming and BCH). Signed-off-by:
-
Miquel Raynal authored
Let's continue introducing the generic ECC engine abstraction in the NAND subsystem by instantiating a second ECC engine: software Hamming. Signed-off-by:
-
Miquel Raynal authored
There is no reason to always embed the software Hamming ECC engine implementation. By default it is (with raw NAND), but we can let the user decide. Signed-off-by:
-
Miquel Raynal authored
Most of the includes are simply useless, drop them. Signed-off-by:
-
Miquel Raynal authored
This code is meant to be reused by the SPI-NAND core. Now that the driver has been cleaned and reorganized, use a generic ECC engine object to store the driver's data instead of accessing members of the nand_chip structure. This means adding proper init/cleanup helpers. Signed-off-by:
-
Miquel Raynal authored
Prefix by ecc_sw_hamming_ the functions which should be internal only but are exported for "raw" operations. Prefix by nand_ecc_sw_hamming_ the other functions which will be used in the context of the declaration of an Hamming proper ECC engine object. Signed-off-by:
-
Miquel Raynal authored
Various style fixes. There is not functional change. Signed-off-by:
-
Miquel Raynal authored
Some functions should never have been exported (the ones prefixed by __*), in this case simply drop the documentation, we never want anybody to use this function from the outside. For the other functions, enhance the style. Signed-off-by:
-
Miquel Raynal authored
The include file pretends being the header for "ECC algorithm", while it is just the header for the Hamming implementation. Make this clear by rewording the sentence. Do the same with the module description. Signed-off-by:
-
Miquel Raynal authored
Hamming ECC code might be later re-used by the SPI NAND layer. Signed-off-by:
-
Miquel Raynal authored
nand_ecc_ctrl embeds a private pointer which only has a meaning in the sunxi driver. This structure will soon be deprecated, but as this field is actually not needed, let's just drop it. Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-11-miquel.raynal@bootlin.com
-
Miquel Raynal authored
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:
-
- 30 Nov, 2020 7 commits
-
-
Miquel Raynal authored
This code is meant to be reused by the SPI-NAND core. Now that the driver has been cleaned and reorganized, use a generic ECC engine object to store the driver's data instead of accessing members of the nand_chip structure. Signed-off-by:
-
Miquel Raynal authored
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 authored
Like for any other compilation option, use the IS_ENABLED() macro instead of hardcoding it. By droping this helper we can get rid of the BCH header in nandsim.c. Signed-off-by:
-
Miquel Raynal authored
When a function is not available, returning -ENOTSUPP makes much more sense than returning -1. Signed-off-by:
-
Miquel Raynal authored
The NAND BCH control structure has nothing to do outside of this driver, all users of the nand_bch_init/free() functions just save it to chip->ecc.priv so do it in this driver directly and return a regular error code instead. Signed-off-by:
-
Miquel Raynal authored
Fix function headers, capitals and reword a little bit the comments to make this driver more readable. There is not functional change. Signed-off-by:
-
Miquel Raynal authored
BCH ECC code might be later re-used by the SPI NAND layer. Signed-off-by:
-
