- 07 Nov, 2021 1 commit
-
-
Miquel Raynal authored
Core: * Remove obsolete macros only used by the old nand_ecclayout struct * MAINTAINERS: Add entry for Qualcomm NAND controller driver Raw NAND controller drivers: * Arasan: - Prevent an unsupported configuration * Xway, Socrates: plat_nand, Pasemi, Orion, mpc5121, GPIO, Au1550nd, AMS-Delta: - Keep the driver compatible with on-die ECC engines * cs553x, lpc32xx_slc, ndfc, sharpsl, tmio, txx9ndfmc: - Revert the commits: "Fix external use of SW Hamming ECC helper" - And let callers use the bare Hamming helpers * Fsmc: Fix use of SM ORDER * Intel: - Fix potential buffer overflow in probe * xway, vf610, txx9ndfm, tegra, stm32, plat_nand, oxnas, omap, mtk, hisi504, gpmi, gpio, denali, bcm6368, atmel: - Make use of the helper function devm_platform_ioremap_resource{,byname}() Onenand driver: * Samsung: Drop Exynos4 and describe driver in KConfig Raw NAND chip drivers: * Hynix: Add support for H27UCG8T2ETR-BC MLC NAND
-
- 15 Oct, 2021 25 commits
-
-
Zev Weiss authored
Previously, if del_mtd_device() failed with -EBUSY due to a non-zero usecount, a subsequent call to attempt the deletion again would try to remove a debugfs directory that had already been removed and panic. With this change the second call can instead proceed safely. Fixes: e8e3edb9 ("mtd: create per-device and module-scope debugfs entries") Signed-off-by:
Zev Weiss <zev@bewilderbeest.net> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211014203953.5424-1-zev@bewilderbeest.net
-
Cai Huoqing authored
Change the devicetree documentation path to "Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml" since 'cypress,hyperflash.txt' and 'ti,am654-hbmc.txt' have been converted to 'ti,am654-hbmc.yaml'. Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
-
Joachim Wiberg authored
This patch adds support for an optional MTD label for mtd2block emulated MTD devices. Useful when, e.g., testing device images using Qemu. The following line in /etc/fstab can then be used to mount a file system regardless if running on an embedded system, or emulated with block2mtd: mtd:Config /mnt jffs2 noatime,nodiratime 0 0 Kernel command line syntax in the emulated case: block2mtd.block2mtd=/dev/sda,,Config Notice the ',,' it is the optional erase_size, which like before this patch, defaults to PAGE_SIZE when omitted. Hence the strlen() check. Signed-off-by:Joachim Wiberg <troglobit@gmail.com> Signed-off-by:
-
Joachim Wiberg authored
Signed-off-by:
-
Arnd Bergmann authored
drivers/mtd/maps/ixp4xx.c requires MTD_CFI_BE_BYTE_SWAP to be set in order to compile. drivers/mtd/maps/ixp4xx.c:57:4: error: #error CONFIG_MTD_CFI_BE_BYTE_SWAP required This patch avoids the #error output by enforcing the policy in Kconfig. Not sure if this is the right approach, but it helps doing randconfig builds. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Miquel Raynal authored
Under the following conditions: * after rounding up by 4 the number of bytes to transfer (this is related to the controller's internal constraints), * if this (rounded) amount of data is situated beyond the end of the device, * and only in NV-DDR mode, the Arasan NAND controller timeouts. This currently can happen in a particular helper used when picking software ECC algorithms. Let's prevent this situation by refusing to use the NV-DDR interface with software engines. Fixes: 4edde603 ("mtd: rawnand: arasan: Support NV-DDR interface") Signed-off-by:
-
Manivannan Sadhasivam authored
Since I maintain the dt-binding for this controller, I'm stepping forward to maintain the driver also. Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
-
Chris Morgan authored
Add support for the H27UCG8T2ETR-BC MLC NAND. The NAND is used widely in the NTC CHIP, is an MLC type NAND, and is 8GB in size. Neither JEDEC nor ONFI detection identifies it correctly, so the ID is added to the nand_ids.c file. Additionally, per the datasheet this NAND appears to use the same paired pages scheme as the Toshiba TC58TEG5DCLTA00 (dist3), so add support for that to enable use in SLC emulation mode. Tested on a NTC CHIP the device is able to write to a ubifs formatted partition, and then have U-Boot (with proposed patches) boot from a kernel located on that ubifs formatted partition. Signed-off-by:
Chris Morgan <macromorgan@hotmail.com> Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: d525914b ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Cc: Jan Hoffmann <jan@3e8.eu> Cc: Kestrel seventyfour <kestrelseventyfour@gmail.com> Signed-off-by:
Jan Hoffmann <jan@3e8.eu> Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-10-miquel.raynal@bootlin.com
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: b36bf0a0 ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 612e048e ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 8fc6f1f0 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 553508ce ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 6dd09f77 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: f6341f64 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: dbffc8cc ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 59d93473 ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
This reverts commit 56a8d3fd. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
This reverts commit c4b7d7c4. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
This reverts commit 3e09c025. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
This reverts commit 46fcb57e. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
This reverts commit 6a4c5ada. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
This reverts commit 3d227a0b. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. Enhancing the implementation of the rawnand_ecc_sw_* helpers to support both cases, when the ECC object is instantiated and when it is not is a quite elegant way to solve this situation. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper. Following this change, most of the fixes sent in [2] can now be safely reverted. Only the fsmc fix will need to be kept because there is actually something specific to the driver to do in its ->correct() helper. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.com/Signed-off-by:
-
Miquel Raynal authored
The introduction of the generic ECC engine API lead to a number of changes in various drivers which broke some of them. Here is a typical example: I expected the SM_ORDER option to be handled by the Hamming ECC engine internals. Problem: the fsmc driver does not instantiate (yet) a real ECC engine object so we had to use a 'bare' ECC helper instead of the shiny rawnand functions. However, when not intializing this engine properly and using the bare helpers, we do not get the SM ORDER feature handled automatically. It looks like this was lost in the process so let's ensure we use the right SM ORDER now. Fixes: ad9ffdce ("mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper") Cc: stable@vger.kernel.org Signed-off-by:
-
- 28 Sep, 2021 1 commit
-
-
Krzysztof Kozlowski authored
None of supported Samsung Exynos4 SoCs (Exynos4210, Exynos4412) seem to use OneNAND driver so drop it. Describe better which driver applies to which SoC, to make configuring kernel for Samsung SoC easier. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
- 14 Sep, 2021 13 commits
-
-
Colin Ian King authored
The pointer eb is being assigned a value that is never read, it is being updated later on. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Evgeny Novikov authored
ebu_nand_probe() read the value of u32 variable "cs" from the device firmware description and used it as the index for array ebu_host->cs that can contain MAX_CS (2) elements at most. That could result in a buffer overflow and various bad consequences later. Fix the potential buffer overflow by restricting values of "cs" with MAX_CS in probe. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 0b1039f0 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by:
Evgeny Novikov <novikov@ispras.ru> Co-developed-by:
Kirill Shilimanov <kirill.shilimanov@huawei.com> Signed-off-by:
Anton Vasilyev <vasilyev@ispras.ru> Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
Christophe Kerello <christophe.kerello@foss.st.com> Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
