summaryrefslogtreecommitdiff
path: root/drivers/mtd/nand
AgeCommit message (Collapse)Author
2021-01-20mtd: rawnand: omap: Use BCH private fields in the specific OOB layoutMiquel Raynal
The OMAP driver may leverage software BCH logic to locate errors while using its own hardware to detect the presence of errors. This is achieved with a "mixed" mode which initializes manually the software BCH internal logic while providing its own OOB layout. The issue here comes from the fact that the BCH driver has been updated to only use generic NAND objects, and no longer depend on raw NAND structures as it is usable from SPI-NAND as well. However, at the end of the BCH context initialization, the driver checks the validity of the OOB layout. At this stage, the raw NAND fields have not been populated yet while being used by the layout helpers, leading to an invalid layout. The chosen solution here is to include the BCH structure definition and to refer to the BCH fields directly (de-referenced as a const pointer here) to know as early as possible the number of steps and ECC bytes which have been chosen. Note: I don't know which commit exactly triggered the error, but the entire migration to a generic BCH driver got merged in one go, so this should not be a problem for stable backports. Reported-by: Adam Ford <aford173@gmail.com> Fixes: 80fe603160a4 ("mtd: nand: ecc-bch: Stop using raw NAND structures") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit-28.dts Link: https://lore.kernel.org/linux-mtd/20210119155510.5655-1-miquel.raynal@bootlin.com
2021-01-14mtd: spinand: Fix MTD_OPS_AUTO_OOB requestsMiquel Raynal
The initial change breaking the logic is commit 3d1f08b032dc ("mtd: spinand: Use the external ECC engine logic") It inadvertently dropped proper OOB support while doing something else. Shortly later, half of it got re-integrated by commit 868cbe2a6dce ("mtd: spinand: Fix OOB read") (pointing by the way to a more early change which had nothing to do with the issue). Problem is, this commit failed to revert the faulty change entirely and missed the logic handling MTD_OPS_AUTO_OOB requests. Let's fix this mess by re-inserting the missing part now. Fixes: 868cbe2a6dce ("mtd: spinand: Fix OOB read") Reported-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210107083813.24283-1-miquel.raynal@bootlin.com
2021-01-14mtd: rawnand: intel: check the mtd name only after setting the variableMartin Blumenstingl
Move the check for mtd->name after the mtd variable has actually been initialized. While here, also drop the NULL assignment to the mtd variable as it's overwritten later on anyways and the NULL value is never read. Fixes: 0b1039f016e8a3 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210106140943.98072-1-martin.blumenstingl@googlemail.com
2021-01-14mtd: rawnand: nandsim: Fix the logic when selecting Hamming soft ECC engineMiquel Raynal
I have been fooled by the logic picking the right ECC engine which is spread across two functions: *init_module() and *_attach(). I thought this driver was not impacted by the recent changes around the ECC engines DT parsing logic but in fact it is. Reported-by: kernel test robot <oliver.sang@intel.com> Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210104093057.31178-1-miquel.raynal@bootlin.com
2021-01-04mtd: rawnand: gpmi: fix dst bit offset when extracting raw payloadSean Nyekjaer
Re-add the multiply by 8 to "step * eccsize" to correct the destination bit offset when extracting the data payload in gpmi_ecc_read_page_raw(). Fixes: e5e5631cc889 ("mtd: rawnand: gpmi: Use nand_extract_bits()") Cc: stable@vger.kernel.org Reported-by: Martin Hundebøll <martin@geanix.com> Signed-off-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201221100013.2715675-1-sean@geanix.com
2020-12-16Merge tag 'mtd/for-5.11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD updates from Miquel Raynal: "MTD core: - Fix refcounting for unpartitioned MTDs - Fix misspelled function parameter 'section' - Remove unneeded break - cmdline parser: Fix parsing of part-names with colons - mtdpart: Fix misdocumented function parameter 'mtd' MTD devices: - phram: - Allow the user to set the erase page size - File headers are not good candidates for kernel-doc - physmap-bt1-rom: Fix __iomem addrspace removal warning - plat-ram: correctly free memory on error path in platram_probe() - powernv_flash: Add function names to headers and fix 'dev' - docg3: Fix kernel-doc 'bad line' and 'excessive doc' issues UBI cleanup fixes: - gluebi: Fix misnamed function parameter documentation - wl: Fix a couple of kernel-doc issues - eba: Fix a couple of misdocumentation issues - kapi: Correct documentation for 'ubi_leb_read_sg's 'sgl' parameter - Document 'ubi_num' in struct mtd_dev_param Generic NAND core ECC management: - Add an I/O request tweaking mechanism - Entire rework of the software BCH ECC driver, creation of a real ECC engine, getting rid of raw NAND structures, migration to more generic prototypes, misc fixes and style cleanup. Moved now to the Generic NAND layer. - Entire rework of the software Hamming ECC driver, creation of a real ECC engine, getting rid of raw NAND structures, misc renames, comment updates, cleanup, and style fixes. Moved now to the generic NAND layer. - Necessary plumbing at the NAND level to retrieve generic NAND ECC engines (softwares and on-die). - Update of the bindings. Raw NAND core: - Geting rid of the chip->ecc.priv entry. - Fix miscellaneous typos in kernel-doc Raw NAND controller drivers: - Arasan: Document 'anfc_op's 'buf' member - AU1550: Ensure the presence of the right includes - Brcmnand: Demote non-conformant kernel-doc headers - Cafe: Remove superfluous param doc and add another - Davinci: Do not use extra dereferencing - Diskonchip: Marking unused variables as __always_unused - GPMI: - Fix the driver only sense CS0 R/B issue - Fix the random DMA timeout issue - Use a single line for of_device_id - Use of_device_get_match_data() - Fix reference count leak in gpmi ops - Cleanup makefile - Fix binding matching of clocks on different SoCs - Ingenic: remove redundant get_device() in ingenic_ecc_get() - Intel LGM: New NAND controller driver - Marvell: Drop useless line - Meson: - Fix a resource leak in init - Fix meson_nfc_dma_buffer_release() arguments - mxc: - Use device_get_match_data() - Use a single line for of_device_id - Remove platform data support - Omap: - Fix a bunch of kernel-doc misdemeanours - Finish ELM half populated function header, demote empty ones - s3c2410: Add documentation for 2 missing struct members - Sunxi: Document 'sunxi_nfc's 'caps' member - Qcom: - Add support for SDX55 - Support for IPQ6018 QPIC NAND controller - Fix DMA sync on FLASH_STATUS register read - Rockchip: New NAND controller driver for RK3308, RK2928 and others - Sunxi: Add MDMA support ONENAND: - bbt: Fix expected kernel-doc formatting - Fix some kernel-doc misdemeanours - Fix expected kernel-doc formatting - Use mtd->oops_panic_write as condition SPI-NAND core: - Creation of a SPI-NAND on-die ECC engine - Move ECC related definitions earlier in the driver - Fix typo in comment - Fill a default ECC provider/algorithm - Remove outdated comment - Fix OOB read - Allow the case where there is no ECC engine - Use the external ECC engine logic SPI-NAND chip drivers: - Micron: - Add support for MT29F2G01AAAED - Use more specific names - Macronix: - Add support for MX35LFxG24AD - Add support for MX35LFxGE4AD - Toshiba: Demote non-conformant kernel-doc header SPI-NOR core: - Initial support for stateful Octal DTR mode using volatile settings - Preliminary support for JEDEC 251 (xSPI) and JEDEC 216D standards - Support for Cypress Semper flash - Support to specify ECC block size of SPI NOR flashes - Fixes to avoid clearing of non-volatile Block Protection bits at probe - hisi-sfc: Demote non-conformant kernel-doc" * tag 'mtd/for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (120 commits) mtd: spinand: macronix: Add support for MX35LFxG24AD mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others dt-bindings: mtd: Describe Rockchip RK3xxx NAND flash controller mtd: rawnand: gpmi: Use a single line for of_device_id mtd: rawnand: gpmi: Fix the random DMA timeout issue mtd: rawnand: gpmi: Fix the driver only sense CS0 R/B issue mtd: rawnand: qcom: Add NAND controller support for SDX55 dt-bindings: qcom_nandc: Add SDX55 QPIC NAND documentation mtd: rawnand: mxc: Use a single line for of_device_id mtd: rawnand: mxc: Use device_get_match_data() mtd: rawnand: meson: Fix a resource leak in init mtd: rawnand: gpmi: Use of_device_get_match_data() mtd: rawnand: Add NAND controller support on Intel LGM SoC dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC mtd: spinand: micron: Add support for MT29F2G01AAAED mtd: spinand: micron: Use more specific names mtd: rawnand: gpmi: fix reference count leak in gpmi ops dt-bindings: mtd: gpmi-nand: Fix matching of clocks on different SoCs mtd: spinand: macronix: Add support for MX35LFxGE4AD mtd: plat-ram: correctly free memory on error path in platram_probe() ...
2020-12-16Merge tags 'spi-nor/for-5.11' and 'nand/for-5.11' into mtd/nextMiquel Raynal
SPI NOR core changes: - Initial support for stateful Octal DTR mode using volatile settings - Preliminary support for JEDEC 251 (xSPI) and JEDEC 216D standards - Support for Cypress Semper flash - Support to specify ECC block size of SPI NOR flashes - Fixes to avoid clearing of non-volatile Block Protection bits at probe Generic NAND core: * ECC management: - Add an I/O request tweaking mechanism - Entire rework of the software BCH ECC driver, creation of a real ECC engine, getting rid of raw NAND structures, migration to more generic prototypes, misc fixes and style cleanup. Moved now to the Generic NAND layer. - Entire rework of the software Hamming ECC driver, creation of a real ECC engine, getting rid of raw NAND structures, misc renames, comment updates, cleanup, and style fixes. Moved now to the generic NAND layer. - Necessary plumbing at the NAND level to retrieve generic NAND ECC engines (softwares and on-die). - Update of the bindings. Raw NAND core: * Geting rid of the chip->ecc.priv entry. * Fix miscellaneous typos in kernel-doc Raw NAND controller drivers: * AU1550: Ensure the presence of the right includes * Davinci: Do not use extra dereferencing * GPMI: - Fix the driver only sense CS0 R/B issue - Fix the random DMA timeout issue - Use a single line for of_device_id - Use of_device_get_match_data() - Fix reference count leak in gpmi ops - Cleanup makefile - Fix binding matching of clocks on different SoCs * Ingenic: remove redundant get_device() in ingenic_ecc_get() * Intel LGM: New NAND controller driver * Marvell: Drop useless line * Meson: - Fix a resource leak in init - Fix meson_nfc_dma_buffer_release() arguments * mxc: - Use device_get_match_data() - Use a single line for of_device_id - Remove platform data support * Qcom: - Add support for SDX55 - Support for IPQ6018 QPIC NAND controller - Fix DMA sync on FLASH_STATUS register read * Rockchip: New NAND controller driver for RK3308, RK2928 and others * Sunxi: Add MDMA support SPI-NAND core: * Creation of a SPI-NAND on-die ECC engine * Move ECC related definitions earlier in the driver * Fix typo in comment * Fill a default ECC provider/algorithm * Remove outdated comment * Fix OOB read * Allow the case where there is no ECC engine * Use the external ECC engine logic SPI-NAND chip drivers: * Micron: - Add support for MT29F2G01AAAED - Use more specific names * Macronix: - Add support for MX35LFxG24AD - Add support for MX35LFxGE4AD Others: * onenand: Use mtd->oops_panic_write as condition * plat-ram: correctly free memory on error path in platram_probe()
2020-12-11mtd: rawnand: xway: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: d525914b5bd8 ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-10-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: socrates: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: b36bf0a0fe5d ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-9-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: plat_nand: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 612e048e6aab ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-8-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: pasemi: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 8fc6f1f042b2 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-7-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: orion: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Reported-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Fixes: 553508cec2e8 ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-6-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: mpc5121: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 6dd09f775b72 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-5-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: gpio: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: f6341f6448e0 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-4-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: au1550: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: dbffc8ccdf3a ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-3-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: ams-delta: Do not force a particular software ECC engineMiquel Raynal
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") kind of broke the logic around the initialization of several ECC engines. Unfortunately, the fix (which indeed moved the ECC initialization to the right place) did not take into account the fact that a different ECC algorithm could have been used thanks to a DT property, considering the "Hamming" algorithm entry a configuration while it was only a default. Add the necessary logic to be sure Hamming keeps being only a default. Fixes: 59d93473323a ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-2-miquel.raynal@bootlin.com
2020-12-10mtd: spinand: macronix: Add support for MX35LFxG24ADYouChing Lin
The Macronix MX35LF1G24AD(/2G24AD/4G24AD) are 3V, 1G/2G/4Gbit serial SLC NAND flash device (without on-die ECC). Validated by read, erase, read back, write, read back on Xilinx Zynq PicoZed FPGA board which included Macronix SPI Host(drivers/spi/spi-mxic.c) & S/W BCH ecc(drivers/mtd/nand/ecc-sw-bch.c) with bug fixing patch (mtd: nand: ecc-bch: Fix the size of calc_buf/code_buf of the BCH). Signed-off-by: YouChing Lin <ycllin@mxic.com.tw> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1607570529-22341-3-git-send-email-ycllin@mxic.com.tw
2020-12-10mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and othersYifeng Zhao
This driver supports Rockchip NFC (NAND Flash Controller) found on RK3308, RK2928, RKPX30, RV1108 and other SOCs. The driver has been tested using 8-bit NAND interface on the ARM based RK3308 platform. Support Rockchip SoCs and NFC versions: - PX30 and RK3326(NFCv900). ECC: 16/40/60/70 bits/1KB. CLOCK: ahb and nfc. - RK3308 and RV1108(NFCv800). ECC: 16 bits/1KB. CLOCK: ahb and nfc. - RK3036 and RK3128(NFCv622). ECC: 16/24/40/60 bits/1KB. CLOCK: ahb and nfc. - RK3066, RK3188 and RK2928(NFCv600). ECC: 16/24/40/60 bits/1KB. CLOCK: ahb. Supported features: - Read full page data by DMA. - Support HW ECC(one step is 1KB). - Support 2 - 32K page size. - Support 8 CS(depend on SoCs) Limitations: - No support for the ecc step size is 512. - Untested on some SoCs. - No support for subpages. - No support for the builtin randomizer. - The original bad block mask is not supported. It is recommended to use the BBT(bad block table). Suggested-by: Johan Jonker <jbx6244@gmail.com> Signed-off-by: Yifeng Zhao <yifeng.zhao@rock-chips.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201210002134.5686-3-yifeng.zhao@rock-chips.com
2020-12-10mtd: rawnand: gpmi: Use a single line for of_device_idFabio Estevam
The .compatible and .data pairs can be stored in a single line, which makes the code more concise. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201208221243.3255-1-festevam@gmail.com
2020-12-10mtd: rawnand: gpmi: Fix the random DMA timeout issueHan Xu
To get better performance, current gpmi driver collected and chained all small DMA transfers in gpmi_nfc_exec_op, the whole chain triggered and wait for complete at the end. But some random DMA timeout found in this new driver, with the help of ftrace, we found the root cause is as follows: Take gpmi_ecc_read_page() as an example, gpmi_nfc_exec_op collected 6 DMA transfers and the DMA chain triggered at the end. It waits for bch completion and check jiffies if it's timeout. The typical function graph shown below, 63.216351 | 1) | gpmi_ecc_read_page() { 63.216352 | 1) 0.750 us | gpmi_bch_layout_std(); 63.216354 | 1) | gpmi_nfc_exec_op() { 63.216355 | 1) | gpmi_chain_command() { 63.216356 | 1) | mxs_dma_prep_slave_sg() { 63.216357 | 1) | /* mxs chan ccw idx: 0 */ 63.216358 | 1) 1.750 us | } 63.216359 | 1) | mxs_dma_prep_slave_sg() { 63.216360 | 1) | /* mxs chan ccw idx: 1 */ 63.216361 | 1) 2.000 us | } 63.216361 | 1) 6.500 us | } 63.216362 | 1) | gpmi_chain_command() { 63.216363 | 1) | mxs_dma_prep_slave_sg() { 63.216364 | 1) | /* mxs chan ccw idx: 2 */ 63.216365 | 1) 1.750 us | } 63.216366 | 1) | mxs_dma_prep_slave_sg() { 63.216367 | 1) | /* mxs chan ccw idx: 3 */ 63.216367 | 1) 1.750 us | } 63.216368 | 1) 5.875 us | } 63.216369 | 1) | /* gpmi_chain_wait_ready */ 63.216370 | 1) | mxs_dma_prep_slave_sg() { 63.216372 | 1) | /* mxs chan ccw idx: 4 */ 63.216373 | 1) 3.000 us | } 63.216374 | 1) | /* gpmi_chain_data_read */ 63.216376 | 1) | mxs_dma_prep_slave_sg() { 63.216377 | 1) | /* mxs chan ccw idx: 5 */ 63.216378 | 1) 2.000 us | } 63.216379 | 1) 1.125 us | mxs_dma_tx_submit(); 63.216381 | 1) 1.000 us | mxs_dma_enable_chan(); 63.216712 | 0) 2.625 us | mxs_dma_int_handler(); 63.216717 | 0) 4.250 us | bch_irq(); 63.216723 | 0) 1.250 us | mxs_dma_tasklet(); 63.216723 | 1) | /* jiffies left 250 */ 63.216725 | 1) ! 372.000 us | } 63.216726 | 1) 2.625 us | gpmi_count_bitflips(); 63.216730 | 1) ! 379.125 us | } but it's not gurantee that bch irq handled always after dma irq handled, sometimes bch_irq comes first and gpmi_nfc_exec_op won't wait anymore, another gpmi_nfc_exec_op may get invoked before last DMA chain IRQ handled, this messed up the next DMA chain and causes DMA timeout. Check the trace log when issue happened. 63.218923 | 1) | gpmi_ecc_read_page() { 63.218924 | 1) 0.625 us | gpmi_bch_layout_std(); 63.218926 | 1) | gpmi_nfc_exec_op() { 63.218927 | 1) | gpmi_chain_command() { 63.218928 | 1) | mxs_dma_prep_slave_sg() { 63.218929 | 1) | /* mxs chan ccw idx: 0 */ 63.218929 | 1) 1.625 us | } 63.218931 | 1) | mxs_dma_prep_slave_sg() { 63.218931 | 1) | /* mxs chan ccw idx: 1 */ 63.218932 | 1) 1.750 us | } 63.218933 | 1) 5.875 us | } 63.218934 | 1) | gpmi_chain_command() { 63.218934 | 1) | mxs_dma_prep_slave_sg() { 63.218935 | 1) | /* mxs chan ccw idx: 2 */ 63.218936 | 1) 1.875 us | } 63.218937 | 1) | mxs_dma_prep_slave_sg() { 63.218938 | 1) | /* mxs chan ccw idx: 3 */ 63.218939 | 1) 1.625 us | } 63.218939 | 1) 5.875 us | } 63.218940 | 1) | /* gpmi_chain_wait_ready */ 63.218941 | 1) | mxs_dma_prep_slave_sg() { 63.218942 | 1) | /* mxs chan ccw idx: 4 */ 63.218942 | 1) 1.625 us | } 63.218943 | 1) | /* gpmi_chain_data_read */ 63.218944 | 1) | mxs_dma_prep_slave_sg() { 63.218945 | 1) | /* mxs chan ccw idx: 5 */ 63.218947 | 1) 2.375 us | } 63.218948 | 1) 0.625 us | mxs_dma_tx_submit(); 63.218949 | 1) 1.000 us | mxs_dma_enable_chan(); 63.219276 | 0) 5.125 us | bch_irq(); <---- 63.219283 | 1) | /* jiffies left 250 */ 63.219285 | 1) ! 358.625 us | } 63.219286 | 1) 2.750 us | gpmi_count_bitflips(); 63.219289 | 1) ! 366.000 us | } 63.219290 | 1) | gpmi_ecc_read_page() { 63.219291 | 1) 0.750 us | gpmi_bch_layout_std(); 63.219293 | 1) | gpmi_nfc_exec_op() { 63.219294 | 1) | gpmi_chain_command() { 63.219295 | 1) | mxs_dma_prep_slave_sg() { 63.219295 | 0) 1.875 us | mxs_dma_int_handler(); <---- 63.219296 | 1) | /* mxs chan ccw idx: 6 */ 63.219297 | 1) 2.250 us | } 63.219298 | 1) | mxs_dma_prep_slave_sg() { 63.219298 | 0) 1.000 us | mxs_dma_tasklet(); 63.219299 | 1) | /* mxs chan ccw idx: 0 */ 63.219300 | 1) 1.625 us | } 63.219300 | 1) 6.375 us | } 63.219301 | 1) | gpmi_chain_command() { 63.219302 | 1) | mxs_dma_prep_slave_sg() { 63.219303 | 1) | /* mxs chan ccw idx: 1 */ 63.219304 | 1) 1.625 us | } 63.219305 | 1) | mxs_dma_prep_slave_sg() { 63.219306 | 1) | /* mxs chan ccw idx: 2 */ 63.219306 | 1) 1.875 us | } 63.219307 | 1) 6.000 us | } 63.219308 | 1) | /* gpmi_chain_wait_ready */ 63.219308 | 1) | mxs_dma_prep_slave_sg() { 63.219309 | 1) | /* mxs chan ccw idx: 3 */ 63.219310 | 1) 2.000 us | } 63.219311 | 1) | /* gpmi_chain_data_read */ 63.219312 | 1) | mxs_dma_prep_slave_sg() { 63.219313 | 1) | /* mxs chan ccw idx: 4 */ 63.219314 | 1) 1.750 us | } 63.219315 | 1) 0.625 us | mxs_dma_tx_submit(); 63.219316 | 1) 0.875 us | mxs_dma_enable_chan(); 64.224227 | 1) | /* jiffies left 0 */ In the first gpmi_nfc_exec_op, bch_irq comes first and gpmi_nfc_exec_op exits, but DMA IRQ still not happened yet until the middle of following gpmi_nfc_exec_op, the first DMA transfer index get messed and DMA get timeout. To fix the issue, when there is bch ops in DMA chain, the gpmi_nfc_exec_op should wait for both completions rather than bch completion only. Fixes: ef347c0cfd61 ("mtd: rawnand: gpmi: Implement exec_op") Signed-off-by: Han Xu <han.xu@nxp.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/20201209035104.22679-3-han.xu@nxp.com
2020-12-10mtd: rawnand: gpmi: Fix the driver only sense CS0 R/B issueHan Xu
Set the GPMI CTRL1 GANGED_RDYBUSY bit so driver can sense the R/B signal from all CS. For the NAND chip MT29F64G08AFAAAWP, only the first chip detected without the patch. [ 3.764118] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770613] nand: Micron MT29F64G08AFAAAWP [ 3.774752] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOB size: 448 [ 3.786421] Bad block table found at page 524160, version 0x01 [ 3.792730] Bad block table found at page 524032, version 0x01 After applying the patch [ 3.764445] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770941] nand: Micron MT29F64G08AFAAAWP [ 3.775080] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOB size: 448 [ 3.784390] nand: 2 chips detected [ 3.790900] Bad block table found at page 524160, version 0x01 [ 3.796776] Bad block table found at page 1048448, version 0x01 Signed-off-by: Han Xu <han.xu@nxp.com> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201209035104.22679-2-han.xu@nxp.com
2020-12-10mtd: rawnand: qcom: Add NAND controller support for SDX55Manivannan Sadhasivam
SDX55 uses QPIC version 2.0.0 IP for the NAND controller support. In this version, DEV_CMD_* registers are moved to operational state, hence CPU access in BAM mode is restricted. So, skip accessing these registers and also use a different config for reading ONFI parameters. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201126085705.48399-3-manivannan.sadhasivam@linaro.org
2020-12-10mtd: rawnand: mxc: Use a single line for of_device_idFabio Estevam
The .compatible and .data pairs can be stored in a single line, which makes the code more concise. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201204145818.32739-2-festevam@gmail.com
2020-12-10mtd: rawnand: mxc: Use device_get_match_data()Fabio Estevam
The retrieval of driver data can be a bit simplified by using device_get_match_data(), so switch to it. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201204145818.32739-1-festevam@gmail.com
2020-12-10mtd: rawnand: meson: Fix a resource leak in initDan Carpenter
Call clk_disable_unprepare(nfc->phase_rx) if the clk_set_rate() function fails to avoid a resource leak. Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/X8ikVCnUsfTpffFB@mwanda
2020-12-10mtd: rawnand: gpmi: Use of_device_get_match_data()Fabio Estevam
The retrieval of driver data via of_device_get_match_data() can make the code simpler. Use of_device_get_match_data() to simplify the code. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201126030946.2058-1-festevam@gmail.com
2020-12-10mtd: rawnand: Add NAND controller support on Intel LGM SoCRamuthevar Vadivel Murugan
This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201110012333.18647-3-vadivel.muruganx.ramuthevar@linux.intel.com
2020-12-10mtd: spinand: micron: Add support for MT29F2G01AAAEDThirumalesha Narasimhappa
The MT29F2G01AAAED is a single die, 2Gb Micron SPI NAND Flash with 4-bit ECC Signed-off-by: Thirumalesha Narasimhappa <nthirumalesha7@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201108113735.2533-3-nthirumalesha7@gmail.com
2020-12-10mtd: spinand: micron: Use more specific namesThirumalesha Narasimhappa
Rename the read/write/update of SPINAND_OP_VARIANTS() to more specialized names. Signed-off-by: Thirumalesha Narasimhappa <nthirumalesha7@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201108113735.2533-2-nthirumalesha7@gmail.com
2020-12-10mtd: rawnand: gpmi: fix reference count leak in gpmi opsZhang Qilong
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: 5bc6bb603b4d0 ("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
2020-12-10mtd: spinand: macronix: Add support for MX35LFxGE4ADYouChing Lin
The Macronix MX35LF2GE4AD / MX35LF4GE4AD are 3V, 2G / 4Gbit serial SLC NAND flash device (with on-die ECC). Validated by read, erase, read back, write, read back and nandtest on Xilinx Zynq PicoZed FPGA board which included Macronix SPI Host (drivers/spi/spi-mxic.c). Signed-off-by: YouChing Lin <ycllin@mxic.com.tw> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1604561020-13499-1-git-send-email-ycllin@mxic.com.tw
2020-12-10mtd: onenand: Use mtd->oops_panic_write as conditionThomas Gleixner
struct mtd_info has a flag oops_panic_write which is set when the write operation is issued via the panic_write() callback. That allows controller drivers to distinguish the panic write from a regular write. Replace the open coded 'in_interrupt() | oops_in_progress' checks with a check for that flag. in_interrupt() is an unrealiable indicator anyway as it covers all sorts of atomic contexts not only hard and soft interrupt service routines. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Tudor Ambarus <tudor.ambarus@microchip.com> Cc: Richard Weinberger <richard@nod.at> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: linux-mtd@lists.infradead.org Cc: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113141422.2214771-1-bigeasy@linutronix.de
2020-12-10mtd: rawnand: marvell: Drop useless lineMiquel Raynal
The raw NAND core now declares the on host ECC engine being the default if none is provided in the DT. Drop this line doing exactly the same from the Marvell driver. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113124114.449-1-miquel.raynal@bootlin.com
2020-12-10mtd: rawnand: davinci: Do not use extra dereferencingMiquel Raynal
When the nand_chip structure is already available, there is no need to dereference it through the info pointer. Use the chip pointer directly in this case. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113124045.32743-1-miquel.raynal@bootlin.com
2020-12-10mtd: rawnand: au1550: Ensure the presence of the right includesMiquel Raynal
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
2020-12-10mtd: nand: Change dependency between the NAND and ECC coresMiquel Raynal
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
2020-12-10mtd: rawnand: mxc: Remove platform data supportFabio Estevam
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
2020-12-10mtd: rawnand: ingenic: remove redundant get_device() in ingenic_ecc_get()Yu Kuai
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: 15de8c6efd0e("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 <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201031105439.2304211-1-yukuai3@huawei.com
2020-12-10mtd: nand: ecc-hamming: Clarify the logic around rp17Miquel Raynal
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
2020-12-10mtd: rawnand: sunxi: Add MDMA supportManuel Dipolt
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
2020-12-10mtd: rawnand: meson: fix meson_nfc_dma_buffer_release() argumentsSergei Antonov
Arguments 'infolen' and 'datalen' to meson_nfc_dma_buffer_release() were mixed up. Fixes: 8fae856c53500 ("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: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201028094940.11765-1-saproj@gmail.com
2020-12-10mtd: rawnand: fix a kernel-doc markupMauro Carvalho Chehab
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: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/9ed47a57d12c40e73a9b01612ee119d39baa6236.1603469755.git.mchehab+huawei@kernel.org
2020-12-10mtd: rawnand: qcom: Support for IPQ6018 QPIC NAND controllerKathiravan T
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: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1602566124-13456-3-git-send-email-kathirav@codeaurora.org
2020-12-10mtd: rawnand: qcom: Fix DMA sync on FLASH_STATUS register readPraveenkumar I
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: 5bc36b2bf6e2 ("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: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1602230872-25616-1-git-send-email-ipkumar@codeaurora.org
2020-12-10mtd: rawnand: gpmi: cleanup makefileMarco Felsch
The extra gpmi_nand.o object is not needed anymore since commit 3045f8e36963 ("mtd: rawnand: gpmi: move all driver code into single file"). Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201007134533.31390-1-m.felsch@pengutronix.de
2020-12-10mtd: spinand: Remove outdated commentMiquel Raynal
This comment is no longer true so drop it. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-7-miquel.raynal@bootlin.com
2020-12-10mtd: spinand: Fix OOB readMiquel Raynal
So far OOB have never been used in SPI-NAND, add the missing memcpy to make it work properly. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-6-miquel.raynal@bootlin.com
2020-12-10mtd: spinand: Allow the case where there is no ECC engineMiquel Raynal
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
2020-12-10mtd: spinand: Use the external ECC engine logicMiquel Raynal
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
2020-12-10mtd: nand: Add helpers to manage ECC engines and configurationsMiquel Raynal
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-01 23:32:01 +0000