* mtdchar: Prevent unbounded allocation in MEMWRITE ioctl
* gen_probe: Use bitmap_zalloc() when applicable
* Introduce an expert mode for forensics and debugging purposes
* Clear out unregistered devices a bit more
* Provide unique name for nvmem device
* Remove unused header file <linux/mtd/latch-addr-flash.h>
* Fixed breaking list in __mtd_del_partition.
MTD device changes:
* sst25l, mchp48l640, mchp23k256, dataflash:
- Warn about failure to unregister mtd device
Raw NAND core changes:
* Export nand_read_page_hwecc_oob_first()
GPMC memory controller for OMAP2 NAND controller changes:
* GPMC:
- Add support for AM64 SoC and allow build on K3 platforms
- Use a compatible match table when checking for NAND controller
- Use platform_get_irq() to get the interrupt
Raw NAND controller changes:
* OMAP2 NAND controller:
- Document the missing 'rb-gpios' DT property
- Drop unused variable
- Fix force_8bit flag behaviour for DMA mode
- Move to exec_op interface
- Use platform_get_irq() to get the interrupt
* Renesas:
- Add new NAND controller driver with its bindings and MAINTAINERS entry
* Onenand:
- Remove redundant variable ooblen
* MPC5121:
- Remove unused variable in ads5121_select_chip()
* GPMI:
- Add ERR007117 protection for nfc_apply_timings
- Remove explicit default gpmi clock setting for i.MX6
- Use platform_get_irq_byname() to get the interrupt
- Remove unneeded variable
* Ingenic:
- JZ4740 needs 'oob_first' read page function
* Davinci:
- Rewrite function description
- Avoid duplicated page read
- Don't calculate ECC when reading page
SPI NOR core changes:
* Add Pratyush as SPI NOR co-maintainer.
* Flash parameters initialization was done in a spaghetti way. Clean
flash parameters initialization.
* Rework the flash_info flags and clarify where one should be used.
* Initialize all flash parameters based on JESD216 SFDP where possible.
Flash parameters and settings that are SFDP discoverable should not be
duplicated via flash_info flags at flash declaration.
* Remove debugfs entries that duplicate sysfs entries.
SPI NOR manufacturer driver changes:
* Use late_init() hook in various drivers to make it clear that those
flash parameters are either not declared in the JESD216 SFDP standard,
or the SFDP tables which define those flash parameters are not defined
by the flash.
* Fix mtd size for s3an flashes.
* Write 2 bytes when disabling Octal DTR mode: 1 byte long transactions are
not allowed in 8D-8D-8D mode.
Hyperbus changes:
* Couple of fixes in Renesas hyperbus rpc-if driver to avoid crash on
module remove and for missing check for error value in probe.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmHO+g8ACgkQJWrqGEe9
VoRW1AgAjFC58ARNBw7asYerGyiUWv7b8RjPIRWZqmcSQ6D5m20cGNBTa15c2NrC
v0dNMf2+3FrCECso6wKPbkEbLt9lHjlMmt+AdlraV0QvHBXrJq/Tc2p2ATI5kTqq
WaP4oCx1mccgO+IrEIiGikOcFx/TLBBJEk+U0Anbm16eia9Cjw+uD/q7X2HbF5xQ
MOFZyQ+rAVqkM8tCh6VHhCpX85pn9pj2ZdouOhPWsqjULaGqDbUopC70YPZLVJyx
9u4xHFaVLVae6AS5Gitser2ie8klypTN/H+1weSao43GGmwIrT0wK0mCOVIm90Zd
4frlpnt4QE/IIAKgAm+HxkWg+KV9qg==
=E8lV
-----END PGP SIGNATURE-----
Merge tag 'mtd/for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull MTD updates from Miquel Raynal:
"MTD core changes:
- mtdchar: Prevent unbounded allocation in MEMWRITE ioctl
- gen_probe: Use bitmap_zalloc() when applicable
- Introduce an expert mode for forensics and debugging purposes
- Clear out unregistered devices a bit more
- Provide unique name for nvmem device
- Remove unused header file <linux/mtd/latch-addr-flash.h>
- Fixed breaking list in __mtd_del_partition.
MTD device changes:
- Warn about failure to unregister mtd device in sst25l, mchp48l640,
mchp23k256, and dataflash drivers.
Raw NAND core changes:
- Export nand_read_page_hwecc_oob_first()
GPMC memory controller for OMAP2 NAND controller changes:
- Add support for AM64 SoC and allow build on K3 platforms
- Use a compatible match table when checking for NAND controller
- Use platform_get_irq() to get the interrupt
Raw NAND controller changes:
- OMAP2 NAND controller:
- Document the missing 'rb-gpios' DT property
- Drop unused variable
- Fix force_8bit flag behaviour for DMA mode
- Move to exec_op interface
- Use platform_get_irq() to get the interrupt
- Renesas:
- Add new NAND controller driver with its bindings and MAINTAINERS entry
- Onenand:
- Remove redundant variable ooblen
- MPC5121:
- Remove unused variable in ads5121_select_chip()
- GPMI:
- Add ERR007117 protection for nfc_apply_timings
- Remove explicit default gpmi clock setting for i.MX6
- Use platform_get_irq_byname() to get the interrupt
- Remove unneeded variable
- Ingenic:
- JZ4740 needs 'oob_first' read page function
- Davinci:
- Rewrite function description
- Avoid duplicated page read
- Don't calculate ECC when reading page
SPI NOR core changes:
- Add Pratyush as SPI NOR co-maintainer.
- Flash parameters initialization was done in a spaghetti way. Clean
flash parameters initialization.
- Rework the flash_info flags and clarify where one should be used.
- Initialize all flash parameters based on JESD216 SFDP where
possible. Flash parameters and settings that are SFDP discoverable
should not be duplicated via flash_info flags at flash declaration.
- Remove debugfs entries that duplicate sysfs entries.
SPI NOR manufacturer driver changes:
- Use late_init() hook in various drivers to make it clear that those
flash parameters are either not declared in the JESD216 SFDP
standard, or the SFDP tables which define those flash parameters
are not defined by the flash.
- Fix mtd size for s3an flashes.
- Write 2 bytes when disabling Octal DTR mode: 1 byte long
transactions are not allowed in 8D-8D-8D mode.
Hyperbus changes:
- Couple of fixes in Renesas hyperbus rpc-if driver to avoid crash on
module remove and for missing check for error value in probe"
* tag 'mtd/for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (71 commits)
mtd: spi-nor: Remove debugfs entries that duplicate sysfs entries
mtd: spi-nor: micron-st: write 2 bytes when disabling Octal DTR mode
mtd: spi-nor: spansion: write 2 bytes when disabling Octal DTR mode
mtd: spi-nor: core: use 2 data bytes for template ops
mtd: spi-nor: Constify part specific fixup hooks
mtd: spi-nor: core: Remove reference to spi-nor.c
mtd: rawnand: gpmi: Use platform_get_irq_byname() to get the interrupt
mtd: rawnand: omap_elm: Use platform_get_irq() to get the interrupt
mtd: rawnand: omap2: Select GPMC device driver for ARCH_K3
memory: omap-gpmc: Use a compatible match table when checking for NAND controller
memory: omap-gpmc: Add support for GPMC on AM64 SoC
dt-bindings: memory-controllers: ti,gpmc: Add compatible for AM64
memory: omap-gpmc: Use platform_get_irq() to get the interrupt
MAINTAINERS: Add an entry for Renesas NAND controller
mtd: rawnand: renesas: Add new NAND controller driver
dt-bindings: mtd: renesas: Describe Renesas R-Car Gen3 & RZ/N1 NAND controller
mtd: rawnand: gpmi: remove unneeded variable
mtd: rawnand: omap2: drop unused variable
mtd: rawnand: omap2: fix force_8bit flag behaviour for DMA mode
mtd: rawnand: omap2: Add compatible for AM64 SoC
...
There are cleanups and minor bugfixes across several SoC specific
drivers, for Qualcomm, Samsung, NXP i.MX, AT91, Tegra, Keystone,
Renesas, ZynqMP
Noteworthy new features are:
- The op-tee firmware driver gains support for asynchronous
notifications from secure-world firmware.
- Qualcomm platforms gain support for new SoC types in various
drivers: power domain, cache controller, RPM sleep, soc-info
- Samsung SoC drivers gain support for new SoCs in ChipID and PMU,
as well as a new USIv2 driver that handles various types of
serial communiction (uart, i2c, spi)
- Renesas adds support for R-Car S4-8 (R8A779F0) in multiple
drivers, as well as memory controller support for RZ/G2L
(R9A07G044).
- Apple M1 gains support for the PMGR power management driver
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmHDpK8ACgkQmmx57+YA
GNmUqhAAnaxXJeu+dfWanrAAeH1MKju/uxB6bogtwrAc928BaqmeZfiAqsT9KsWu
FhkWSGRu+y74fct4zkD3xfl0V2ROSrSjcvrWVu0GJPnXoOLKDZ1RbdZDnfXbwowa
4urL5HeOtKYUpLjw7z8EQ43SHZba7CsiImGcF/4OtHW1hNGNIlU/Mym93lFT5Xdq
HwDrktBWWVvBkCnxVGJjMwGGSCJbowIsPK8p8xr4CqML4Vdcx89qKB8cnCOg8Bgo
YqzcJCTOY9K5qXI8D20GaTJCP5vCPxMgmeFn4LgWa+h9iJrt+g4J8zA1qGw92nwJ
W2uRu/6YkCC2HMiyExuxkJNPKbFRbOqAm7lA/ZzuFpFU5RowACIrlwm4ZR/4UFDG
fzrt3ZfNLRu33QxqhKY0jWGeHu729+RE2kpQ4FXveFmrtRIWnuX70/+NQFVhm+qy
EBgXmlWNhTh2tcgfEzPja52+5h3SYKk6/J44266i/34x5eLDvmuRADzCVpLUmbPS
G5UHVkWHZPJne6ZJQ+yz+o2h6BjcpCTvPRbt2/KkSOo9S0Qj4/XrOUHBAofy3odH
Tdiba6lXMHZqvLlOOrMyJ0qdv26FJyJaSg5Wqhq45G1YCW5Xjc+cYzZggJBvBpIh
thyN4b9jqfTnAZzKB6LCBUmEF2A7gXkuW9oXzNUkKtVzYluu1aQ=
=tlZT
-----END PGP SIGNATURE-----
Merge tag 'drivers-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC driver updates from Arnd Bergmann:
"There are cleanups and minor bugfixes across several SoC specific
drivers, for Qualcomm, Samsung, NXP i.MX, AT91, Tegra, Keystone,
Renesas, ZynqMP
Noteworthy new features are:
- The op-tee firmware driver gains support for asynchronous
notifications from secure-world firmware.
- Qualcomm platforms gain support for new SoC types in various
drivers: power domain, cache controller, RPM sleep, soc-info
- Samsung SoC drivers gain support for new SoCs in ChipID and PMU, as
well as a new USIv2 driver that handles various types of serial
communiction (uart, i2c, spi)
- Renesas adds support for R-Car S4-8 (R8A779F0) in multiple drivers,
as well as memory controller support for RZ/G2L (R9A07G044).
- Apple M1 gains support for the PMGR power management driver"
* tag 'drivers-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (94 commits)
soc: qcom: rpmh-rsc: Fix typo in a comment
soc: qcom: socinfo: Add SM6350 and SM7225
dt-bindings: arm: msm: Don't mark LLCC interrupt as required
dt-bindings: firmware: scm: Add SM6350 compatible
dt-bindings: arm: msm: Add LLCC for SM6350
soc: qcom: rpmhpd: Sort power-domain definitions and lists
soc: qcom: rpmhpd: Remove mx/cx relationship on sc7280
soc: qcom: rpmhpd: Rename rpmhpd struct names
soc: qcom: rpmhpd: sm8450: Add the missing .peer for sm8450_cx_ao
soc: qcom: socinfo: add SM8450 ID
soc: qcom: rpmhpd: Add SM8450 power domains
dt-bindings: power: rpmpd: Add SM8450 to rpmpd binding
soc: qcom: smem: Update max processor count
dt-bindings: arm: qcom: Document SM8450 SoC and boards
dt-bindings: firmware: scm: Add SM8450 compatible
dt-bindings: arm: cpus: Add kryo780 compatible
soc: qcom: rpmpd: Add support for sm6125
dt-bindings: qcom-rpmpd: Add sm6125 power domains
soc: qcom: aoss: constify static struct thermal_cooling_device_ops
PM: AVS: qcom-cpr: Use div64_ul instead of do_div
...
After removal of RBTX4939 board support remove code for the TX4939 SoC.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
* Export nand_read_page_hwecc_oob_first()
GPMC memory controller for OMAP2 NAND controller:
* GPMC:
- Add support for AM64 SoC and allow build on K3 platforms
- Use a compatible match table when checking for NAND controller
- Use platform_get_irq() to get the interrupt
Raw NAND controller drivers:
* OMAP2 NAND controller:
- Document the missing 'rb-gpios' DT property
- Drop unused variable
- Fix force_8bit flag behaviour for DMA mode
- Move to exec_op interface
- Use platform_get_irq() to get the interrupt
* Renesas:
- Add new NAND controller driver with its bindings and MAINTAINERS entry
* Onenand:
- Remove redundant variable ooblen
* MPC5121:
- Remove unused variable in ads5121_select_chip()
* GPMI:
- Add ERR007117 protection for nfc_apply_timings
- Remove explicit default gpmi clock setting for i.MX6
- Use platform_get_irq_byname() to get the interrupt
- Remove unneeded variable
* Ingenic:
- JZ4740 needs 'oob_first' read page function
* Davinci:
- Rewrite function description
- Avoid duplicated page read
- Don't calculate ECC when reading page
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmHO9D0ACgkQJWrqGEe9
VoRglwf/SsGcY+7vlBM1VSbUMIF/j5/xuigHIW6AxiN/hu672GMVi7nP7aHg4t3m
DpO5X6ngYFHyW79uksRfwSun/JF1mOqF4De9zhs+cy8hlV12tgEmUNB3cbv4kuFQ
e/N8/mlNrNJ2oQ1C3G3HWe3sngh2vrkhuG49t7M2TJaGAo7V4RW3z9+glNpWMb7m
YIj6gXPjPx7vuEWv80GBUcWNKBzNdRVkrQnj3C2I/ZCslnwYWBLBQxX/U9/KDkPH
7i7MgeknAlV0G/W4TfnNSAKiWOcmWdbmuJ/lOWv4+skdXoMb0/rlC6kvJqOLvbF6
2nUrc9yFTwkNfVTGJm5eWJ0yDUHMgA==
=DQck
-----END PGP SIGNATURE-----
Merge tag 'nand/for-5.17' into mtd/next
Raw NAND core:
* Export nand_read_page_hwecc_oob_first()
GPMC memory controller for OMAP2 NAND controller:
* GPMC:
- Add support for AM64 SoC and allow build on K3 platforms
- Use a compatible match table when checking for NAND controller
- Use platform_get_irq() to get the interrupt
Raw NAND controller drivers:
* OMAP2 NAND controller:
- Document the missing 'rb-gpios' DT property
- Drop unused variable
- Fix force_8bit flag behaviour for DMA mode
- Move to exec_op interface
- Use platform_get_irq() to get the interrupt
* Renesas:
- Add new NAND controller driver with its bindings and MAINTAINERS entry
* Onenand:
- Remove redundant variable ooblen
* MPC5121:
- Remove unused variable in ads5121_select_chip()
* GPMI:
- Add ERR007117 protection for nfc_apply_timings
- Remove explicit default gpmi clock setting for i.MX6
- Use platform_get_irq_byname() to get the interrupt
- Remove unneeded variable
* Ingenic:
- JZ4740 needs 'oob_first' read page function
* Davinci:
- Rewrite function description
- Avoid duplicated page read
- Don't calculate ECC when reading page
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
1. Add support for AM64 SoC.
2. Minor improvement: use platform_get_irq().
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmHFq0cQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD18wsD/0efj2Ex0um0R1w8RyesHbQZW3XNOApncRY
52vNV77QDtrgOwZpMIU0t+WW0vAqBQ9vXxZ8J/XtsyfkYHymGJLBzLClVeddXRv/
mOrnVYnNxpySRBDJnbzXge2w53U2mCnIJHe490/y3RlNKmxibvRUGcaR8egDaRmu
JyIjKgMqC5S4D0/qIYm3EgvWG6t2bEHF3E/wAlbBaCZMFQgIu5+rEAKzfIbCBFPs
O1EleSe56Tx8XVi47s0yB9bolWQabIx6+ED0hi6VsDiOJNgMaVaLbU1hzusO3pvv
V5qLoXJnOVbyzNFmUpWUylplX8SImCdZl/U/T0KQsYihc74J1JjS6OBuBzXqNX93
w/uG5x5cXSEELWOU+WuhLzgfxCHDyT/bmRW/gTtgmvPa3xxphom1kJcmKjslp6Bi
o8P/kvIdweixEM3EorOalD0ztX0q5eWNoJ/I9ObYNqgh3ls2BjyWzV5oe42/oFXE
B24zmZuNHt5XAcATTGcTEjZCZCBWErdMTwZnIV7gXSh5p3kvDPSMwrqP+wFvNjyg
O8Ifd1fqnIXVLtFVqN/mHbUfEyZrkjVcjxSBkb5p9nB2gtfa7BMJhvyA+rxZOBte
MmKpVt9DFZ17I6mmAywXVVnMePut6bJ8Fqq6E4ewuza3aAOXB2i2nrDGcu75gn3k
UEJ0ZwQCnQ==
=eb46
-----END PGP SIGNATURE-----
Merge tag 'memory-controller-drv-omap-5.17' into nand/next
Memory controller drivers for v5.17 - OMAP GPMC
1. Add support for AM64 SoC.
2. Minor improvement: use platform_get_irq().
[miquel.raynal@bootlin.com: A first commit introduced a new omap
compatible and another moved the IDs to a header which created a
conflict: moving the new ID as well in the header fixed it.]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
platform_get_resource_byname(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq_byname().
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211221212609.31290-3-prabhakar.mahadev-lad.rj@bp.renesas.com
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq().
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211221212609.31290-2-prabhakar.mahadev-lad.rj@bp.renesas.com
The GPMC device driver is required for NAND controller
to work on K3 Architecture. Select it if required.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20211221131757.2030-5-rogerq@kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
As more compatibles can be added to the GPMC NAND controller driver
use a compatible match table.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20211221131757.2030-4-rogerq@kernel.org
[krzysztof: remove "is_nand" variable]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Introduce Renesas NAND controller driver which currently supports the
following features on R-Car Gen3 and RZ/N1 SoCs:
- All ONFI timing modes
- Different configurations of its internal ECC controller
- On-die (not tested) and software ECC support
- Several chips (not tested)
- Subpage accesses
- DMA and PIO
This controller was originally provided by Evatronix before being bought
by Cadence.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/linux-mtd/20211217142033.353599-3-miquel.raynal@bootlin.com
In DMA mode we were not considering the force_8bit flag.
Fix it by using regular non-DMA 8-bit I/O if force_8bit flag is set.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211209090458.24830-6-rogerq@kernel.org
The slave_id was previously used to pick one DMA slave instead of another,
but this is now done through the DMA descriptors in device tree.
For the qcom_adm driver, the configuration is documented in the DT
binding to contain a tuple of device identifier and a "crci" field,
but the implementation ends up using only a single cell for identifying
the slave, with the crci getting passed in nonstandard properties of
the device, and passed through the dma driver using the old slave_id
field. Part of the problem apparently is that the nand driver ends up
using only a single DMA request ID, but requires distinct values for
"crci" depending on the type of transfer.
Change both the dmaengine driver and the two slave drivers to allow
the documented binding to work in addition to the ad-hoc passing
of crci values. In order to no longer abuse the slave_id field, pass
the data using the "peripheral_config" mechanism instead.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20211122222203.4103644-9-arnd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The NAND on Tegra belongs to the core power domain and we're going to
enable GENPD support for the core domain. Now NAND must be resumed using
runtime PM API in order to initialize the NAND power state. Add runtime PM
and OPP support to the NAND driver.
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When developping NAND controller drivers or when debugging filesystem
corruptions, it is quite common to need hacking locally into the
MTD/NAND core in order to get access to the content of the bad
blocks. Instead of having multiple implementations out there let's
provide a simple yet effective specific MTD-wide debugfs entry to fully
disable these checks on purpose.
A warning is added to inform the user when this mode gets enabled.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211118114659.1282855-1-miquel.raynal@bootlin.com
Variable ooblen is being initialized with a value that is never read.
The variable is never used after this, so it is redundant and can be
removed.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211205230729.79337-1-colin.i.king@gmail.com
Under certain circumstances, the timing settings calculated by
the FSMC NAND controller driver were inaccurate.
These settings led to incorrect data reads or fallback to
timing mode 0 depending on the NAND chip used.
The timing computation did not take into account the following
constraint given in SPEAr3xx reference manual:
twait >= tCEA - (tset * TCLK) + TOUTDEL + TINDEL
Enhance the timings calculation by taking into account this
additional constraint.
This change has no impact on slow timing modes such as mode 0.
Indeed, on mode 0, computed values are the same with and
without the patch.
NANDs which previously stayed in mode 0 because of fallback to
mode 0 can now work at higher speeds and NANDs which were not
working at all because of the corrupted data work at high
speeds without troubles.
Overall improvement on a Micron/MT29F1G08 (flash_speed tool):
mode0 mode3
eraseblock write speed 3220 KiB/s 4511 KiB/s
eraseblock read speed 4491 KiB/s 7529 KiB/s
Fixes: d9fb079571 ("mtd: nand: fsmc: add support for SDR timings")
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-5-herve.codina@bootlin.com
The FSMC NAND controller should apply a delay after the
instruction has been issued on the bus.
The FSMC NAND controller driver did not handle this delay.
Add this waiting delay in the FSMC NAND controller driver.
Fixes: 4da712e702 ("mtd: nand: fsmc: use ->exec_op()")
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-4-herve.codina@bootlin.com
When the NV-DDR interface is not supported by the NAND chip,
the value of onfi->nvddr_timing_modes is 0. In this case,
the best_mode variable value in nand_choose_best_nvddr_timings()
is -1. The last for-loop is skipped and the function returns an
uninitialized value.
If this returned value is 0, the nand_choose_best_sdr_timings()
is not executed and no 'best timing' are set. This leads the host
controller and the NAND chip working at default mode 0 timing
even if a better timing can be used.
Fix this uninitialized returned value.
nand_choose_best_sdr_timings() is pretty similar to
nand_choose_best_nvddr_timings(). Even if onfi->sdr_timing_modes
should never be seen as 0, nand_choose_best_sdr_timings() returned
value is fixed.
Fixes: a9ecc8c814 ("mtd: rawnand: Choose the best timings, NV-DDR included")
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-3-herve.codina@bootlin.com
NAND_OP_CMD() expects a delay parameter in nanoseconds.
The delay value is wrongly given in milliseconds.
Fix the conversion macro used in order to set this
delay in nanoseconds.
Fixes: d7a773e881 ("mtd: rawnand: Access SDR and NV-DDR timings through a common macro")
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-2-herve.codina@bootlin.com
The helper function devm_platform_ioremap_resource_xxx()
needs HAS_IOMEM enabled, so add the dependency on HAS_IOMEM.
Fixes: 5f14a8ca1b ("mtd: rawnand: denali: Make use of the helper function devm_platform_ioremap_resource_byname()")
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211109134758.417-1-caihuoqing@baidu.com
gpmi_io clock needs to be gated off when changing the parent/dividers of
enfc_clk_root (i.MX6Q/i.MX6UL) respectively qspi2_clk_root (i.MX6SX).
Otherwise this rate change can lead to an unresponsive GPMI core which
results in DMA timeouts and failed driver probe:
[ 4.072318] gpmi-nand 112000.gpmi-nand: DMA timeout, last DMA
...
[ 4.370355] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -110
...
[ 4.375988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
[ 4.381524] gpmi-nand 112000.gpmi-nand: Error in ECC-based read: -22
[ 4.387988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
[ 4.393535] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
...
Other than stated in i.MX 6 erratum ERR007117, it should be sufficient
to gate only gpmi_io because all other bch/nand clocks are derived from
different clock roots.
The i.MX6 reference manuals state that changing clock muxers can cause
glitches but are silent about changing dividers. But tests showed that
these glitches can definitely happen on i.MX6ULL. For i.MX7D/8MM in turn,
the manual guarantees that no glitches can happen when changing
dividers.
Co-developed-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Signed-off-by: Christian Eggers <ceggers@arri.de>
Cc: stable@vger.kernel.org
Acked-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211102202022.15551-2-ceggers@arri.de
There is no need to explicitly set the default gpmi clock rate during
boot for the i.MX 6 since this is done during nand_detect anyway.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Cc: stable@vger.kernel.org
Acked-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211102202022.15551-1-ceggers@arri.de
The ECC engine on the JZ4740 SoC requires the ECC data to be read before
the page; using the default page reading function does not work. Indeed,
the old JZ4740 NAND driver (removed in 5.4) did use the 'OOB first' flag
that existed back then.
Use the newly created nand_read_page_hwecc_oob_first() to address this
issue.
This issue was not found when the new ingenic-nand driver was developed,
most likely because the Device Tree used had the nand-ecc-mode set to
"hw_oob_first", which seems to not be supported anymore.
Cc: <stable@vger.kernel.org> # v5.2
Fixes: a0ac778eb8 ("mtd: rawnand: ingenic: Add support for the JZ4740")
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211016132228.40254-5-paul@crapouillou.net
Move the function nand_read_page_hwecc_oob_first() (previously
nand_davinci_read_page_hwecc_oob_first()) to nand_base.c, and export it
as a GPL symbol, so that it can be used by more modules.
Cc: <stable@vger.kernel.org> # v5.2
Fixes: a0ac778eb8 ("mtd: rawnand: ingenic: Add support for the JZ4740")
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211016132228.40254-4-paul@crapouillou.net
The original comment that describes the function
nand_davinci_read_page_hwecc_oob_first() is very obscure and it is hard
to understand what it is for.
Cc: <stable@vger.kernel.org> # v5.2
Fixes: a0ac778eb8 ("mtd: rawnand: ingenic: Add support for the JZ4740")
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211016132228.40254-3-paul@crapouillou.net
The function nand_davinci_read_page_hwecc_oob_first() first reads the
OOB data, extracts the ECC information, programs the ECC hardware before
reading the actual data in a loop.
Right after the OOB data was read, it called nand_read_page_op() to
reset the read cursor to the beginning of the page. This caused the
first page to be read twice: in that call, and later in the loop.
Address that issue by changing the call to nand_read_page_op() to
nand_change_read_column_op(), which will only reset the read cursor.
Cc: <stable@vger.kernel.org> # v5.2
Fixes: a0ac778eb8 ("mtd: rawnand: ingenic: Add support for the JZ4740")
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211016132228.40254-2-paul@crapouillou.net
The function nand_davinci_read_page_hwecc_oob_first() does read the ECC
data from the OOB area. Therefore it does not need to calculate the ECC
as it is already available.
Cc: <stable@vger.kernel.org> # v5.2
Fixes: a0ac778eb8 ("mtd: rawnand: ingenic: Add support for the JZ4740")
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211016132228.40254-1-paul@crapouillou.net
* Remove obsolete macros only used by the old nand_ecclayout struct
* Don't remove debugfs directory if device is in use
* MAINTAINERS:
- Add entry for Qualcomm NAND controller driver
- Update the devicetree documentation path of hyperbus
MTD devices:
* block2mtd:
- Add support for an optional custom MTD label
- Minor refactor to avoid hard coded constant
* mtdswap: Remove redundant assignment of pointer eb
CFI:
* Fixup CFI on ixp4xx
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 drivers:
* Samsung: Drop Exynos4 and describe driver in KConfig
Raw NAND chip drivers:
* Hynix: Add support for H27UCG8T2ETR-BC MLC NAND
SPI NOR core:
* Add spi-nor device tree binding under SPI NOR maintainers
SPI NOR manufacturer drivers:
* Enable locking for n25q128a13
SPI NOR controller drivers:
* Use devm_platform_ioremap_resource_byname()
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmGIAdEACgkQJWrqGEe9
VoQHEAgAkFvFxIOyPSwAJfyeEklWmGSh+cm+X9EqWxZ5d6iwFE3FZH4X4XiqdyVY
+rzy37o6Tp3pQVYDqxmPM8GGoHy8wYPR5h/U1IozbBaNeCJma1HyK4Sjb/cuX1eQ
23EM1pWT8N9CbRG2S9mz5C9uHcP9mImtyvU4WhTLKOEc9XGbpuj+k1cacSuEEbeF
rZklOa7tvUiOFIDfr7Kf+DfxbpYabgB2dJgWPEtZmKmefWMiODHgvBJo0MT6MKr7
kOlIkgq5zYIFRNaxApWLI3JmH9+lsw6MHBe+cCqemV6q2OZlMV/5VGFElEywJt+4
L3VmlJQpMiCEMo2Cgc1jigHKryk4Xw==
=h6o3
-----END PGP SIGNATURE-----
Merge tag 'mtd/for-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull mtd updates from Miquel Raynal:
"Core:
- Remove obsolete macros only used by the old nand_ecclayout struct
- Don't remove debugfs directory if device is in use
- MAINTAINERS:
- Add entry for Qualcomm NAND controller driver
- Update the devicetree documentation path of hyperbus
MTD devices:
- block2mtd:
- Add support for an optional custom MTD label
- Minor refactor to avoid hard coded constant
- mtdswap: Remove redundant assignment of pointer eb
CFI:
- Fixup CFI on ixp4xx
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 drivers:
- Samsung: Drop Exynos4 and describe driver in KConfig
Raw NAND chip drivers:
- Hynix: Add support for H27UCG8T2ETR-BC MLC NAND
SPI NOR core:
- Add spi-nor device tree binding under SPI NOR maintainers
SPI NOR manufacturer drivers:
- Enable locking for n25q128a13
SPI NOR controller drivers:
- Use devm_platform_ioremap_resource_byname()"
* tag 'mtd/for-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (50 commits)
mtd: core: don't remove debugfs directory if device is in use
MAINTAINERS: Update the devicetree documentation path of hyperbus
mtd: block2mtd: add support for an optional custom MTD label
mtd: block2mtd: minor refactor to avoid hard coded constant
mtd: fixup CFI on ixp4xx
mtd: rawnand: arasan: Prevent an unsupported configuration
MAINTAINERS: Add entry for Qualcomm NAND controller driver
mtd: rawnand: hynix: Add support for H27UCG8T2ETR-BC MLC NAND
mtd: rawnand: xway: Keep the driver compatible with on-die ECC engines
mtd: rawnand: socrates: Keep the driver compatible with on-die ECC engines
mtd: rawnand: plat_nand: Keep the driver compatible with on-die ECC engines
mtd: rawnand: pasemi: Keep the driver compatible with on-die ECC engines
mtd: rawnand: orion: Keep the driver compatible with on-die ECC engines
mtd: rawnand: mpc5121: Keep the driver compatible with on-die ECC engines
mtd: rawnand: gpio: Keep the driver compatible with on-die ECC engines
mtd: rawnand: au1550nd: Keep the driver compatible with on-die ECC engines
mtd: rawnand: ams-delta: Keep the driver compatible with on-die ECC engines
Revert "mtd: rawnand: cs553x: Fix external use of SW Hamming ECC helper"
Revert "mtd: rawnand: lpc32xx_slc: Fix external use of SW Hamming ECC helper"
Revert "mtd: rawnand: ndfc: Fix external use of SW Hamming ECC helper"
...
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: 4edde60314 ("mtd: rawnand: arasan: Support NV-DDR interface")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211008163640.1753821-1-miquel.raynal@bootlin.com
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 <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210930162402.344-1-macroalpha82@gmail.com
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: d525914b5b ("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: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Jan Hoffmann <jan@3e8.eu>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-10-miquel.raynal@bootlin.com
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: b36bf0a0fe ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-9-miquel.raynal@bootlin.com
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: 612e048e6a ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-8-miquel.raynal@bootlin.com
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: 8fc6f1f042 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-7-miquel.raynal@bootlin.com
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: 553508cec2 ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-6-miquel.raynal@bootlin.com
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: 6dd09f775b ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-5-miquel.raynal@bootlin.com
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: f6341f6448 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-4-miquel.raynal@bootlin.com
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: dbffc8ccdf ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-3-miquel.raynal@bootlin.com
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: 59d9347332 ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-2-miquel.raynal@bootlin.com
This reverts commit 56a8d3fd1f.
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.com
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-9-miquel.raynal@bootlin.com
This reverts commit c4b7d7c480.
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.com
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-8-miquel.raynal@bootlin.com
This reverts commit 3e09c02525.
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.com
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-7-miquel.raynal@bootlin.com
This reverts commit 46fcb57e6b.
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.com
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-6-miquel.raynal@bootlin.com
This reverts commit 6a4c5ada57.
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.com
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-5-miquel.raynal@bootlin.com
This reverts commit 3d227a0b0c.
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.com
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-4-miquel.raynal@bootlin.com
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 <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-3-miquel.raynal@bootlin.com
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: ad9ffdce45 ("mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-2-miquel.raynal@bootlin.com
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: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210924133223.111930-1-krzysztof.kozlowski@canonical.com
From QPIC V2 onwards there is a separate register to read
last code word "QPIC_NAND_READ_LOCATION_LAST_CW_n".
qcom_nandc_read_cw_raw() is used to read only one code word
at a time. If we will configure number of code words to 1 in
in QPIC_NAND_DEV0_CFG0 register then QPIC controller thinks
its reading the last code word, since from QPIC V2 onwards
we are having separate register to read the last code word,
we have to configure "QPIC_NAND_READ_LOCATION_LAST_CW_n"
register to fetch data from controller buffer to system
memory.
Fixes: 503ee5aad4 ("mtd: rawnand: qcom: update last code word register")
Cc: stable@kernel.org
Signed-off-by: Md Sadre Alam <mdalam@codeaurora.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/1630998357-1359-1-git-send-email-mdalam@codeaurora.org
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: 0b1039f016 ("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: Kirill Shilimanov <kirill.shilimanov@huawei.com>
Co-developed-by: Anton Vasilyev <vasilyev@ispras.ru>
Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210903082653.16441-1-novikov@ispras.ru
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074252.9633-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074245.9583-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074237.9533-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074230.9483-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Reviewed-by: Christophe Kerello <christophe.kerello@foss.st.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074222.9433-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074215.9383-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074207.9333-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074200.9283-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074153.9233-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074145.9183-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074138.9133-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074130.9083-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074123.9033-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074116.8983-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074108.8933-1-caihuoqing@baidu.com
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Reviewed-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210901074031.8883-1-caihuoqing@baidu.com
Merge more updates from Andrew Morton:
"147 patches, based on 7d2a07b769.
Subsystems affected by this patch series: mm (memory-hotplug, rmap,
ioremap, highmem, cleanups, secretmem, kfence, damon, and vmscan),
alpha, percpu, procfs, misc, core-kernel, MAINTAINERS, lib,
checkpatch, epoll, init, nilfs2, coredump, fork, pids, criu, kconfig,
selftests, ipc, and scripts"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (94 commits)
scripts: check_extable: fix typo in user error message
mm/workingset: correct kernel-doc notations
ipc: replace costly bailout check in sysvipc_find_ipc()
selftests/memfd: remove unused variable
Kconfig.debug: drop selecting non-existing HARDLOCKUP_DETECTOR_ARCH
configs: remove the obsolete CONFIG_INPUT_POLLDEV
prctl: allow to setup brk for et_dyn executables
pid: cleanup the stale comment mentioning pidmap_init().
kernel/fork.c: unexport get_{mm,task}_exe_file
coredump: fix memleak in dump_vma_snapshot()
fs/coredump.c: log if a core dump is aborted due to changed file permissions
nilfs2: use refcount_dec_and_lock() to fix potential UAF
nilfs2: fix memory leak in nilfs_sysfs_delete_snapshot_group
nilfs2: fix memory leak in nilfs_sysfs_create_snapshot_group
nilfs2: fix memory leak in nilfs_sysfs_delete_##name##_group
nilfs2: fix memory leak in nilfs_sysfs_create_##name##_group
nilfs2: fix NULL pointer in nilfs_##name##_attr_release
nilfs2: fix memory leak in nilfs_sysfs_create_device_group
trap: cleanup trap_init()
init: move usermodehelper_enable() to populate_rootfs()
...
HZ unit conversion macros are available in units.h, use them and remove
the duplicate definition.
Link: https://lkml.kernel.org/r/20210816114732.1834145-10-daniel.lezcano@linaro.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Christian Eggers <ceggers@arri.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Lukasz Luba <lukasz.luba@arm.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* blkdevs:
- Simplify the refcounting in blktrans_{open, release}
- Simplify blktrans_getgeo
- Remove blktrans_ref_mutex
- Simplify blktrans_dev_get
- Use lockdep_assert_held
- Don't hold del_mtd_blktrans_dev in blktrans_{open, release}
* ftl:
- Don't cast away the type when calling add_mtd_blktrans_dev
- Don't cast away the type when calling add_mtd_blktrans_dev
- Use container_of() rather than cast
- Fix use-after-free
- Add discard support
- Allow use of MTD_RAM for testing purposes
* concat:
- Check _read, _write callbacks existence before assignment
- Judge callback existence based on the master
* maps:
- Maps: remove dead MTD map driver for PMC-Sierra MSP boards
* mtdblock:
- Warn if added for a NAND device
- Add comment about UBI block devices
- Update old JFFS2 mention in Kconfig
* partitions:
- Redboot: convert to YAML
NAND core changes:
* Repair Miquel Raynal's email address in MAINTAINERS
* Fix a couple of spelling mistakes in Kconfig
* bbt: Skip bad blocks when searching for the BBT in NAND
* Remove never changed ret variable
Raw NAND changes:
* cafe: Fix a resource leak in the error handling path of 'cafe_nand_probe()'
* intel: Fix error handling in probe
* omap: Fix kernel doc warning on 'calcuate' typo
* gpmc: Fix the ECC bytes vs. OOB bytes equation
SPI-NAND core changes:
* Properly fill the OOB area.
* Fix comment
SPI-NAND drivers changes:
* macronix: Add Quad support for serial NAND flash
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmExS1gACgkQJWrqGEe9
VoSZcAf/SsUDpp/lqc+no4R+eUR/CWrbr3AKu2JjjgCJt0HK++Fy8LQU3FEjn9E8
CNBWYqIVVit1XhqGu192wh0ESsHGlNwjicB3Ul4/RFFC4WKs68kQe0gQrU6z/95V
jaTOW+B7PZh6MFbQROUVI97Cs3OTd8vCE3L2SgIW6krk8tnOEyddlgFsWLISjk6g
Ut1I473653fJAcr5OXEFJLWF+01q2azR9AiAkfKC47IUekTRJqjK2YJpAhsdf4hi
xqazp79sbcNXSHCgOOQv4/f03+SAiufRcNgztwrSWw2fdCg0csBC9ACwmdhhGGfd
7uFn+/Q3sVDOKTN7aAWW1KnykKXsJw==
=JFrk
-----END PGP SIGNATURE-----
Merge tag 'mtd/for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull MTD updates from Miquel Raynal:
"MTD changes:
- blkdevs:
- Simplify the refcounting in blktrans_{open, release}
- Simplify blktrans_getgeo
- Remove blktrans_ref_mutex
- Simplify blktrans_dev_get
- Use lockdep_assert_held
- Don't hold del_mtd_blktrans_dev in blktrans_{open, release}
- ftl:
- Don't cast away the type when calling add_mtd_blktrans_dev
- Don't cast away the type when calling add_mtd_blktrans_dev
- Use container_of() rather than cast
- Fix use-after-free
- Add discard support
- Allow use of MTD_RAM for testing purposes
- concat:
- Check _read, _write callbacks existence before assignment
- Judge callback existence based on the master
- maps:
- Maps: remove dead MTD map driver for PMC-Sierra MSP boards
- mtdblock:
- Warn if added for a NAND device
- Add comment about UBI block devices
- Update old JFFS2 mention in Kconfig
- partitions:
- Redboot: convert to YAML
NAND core changes:
- Repair Miquel Raynal's email address in MAINTAINERS
- Fix a couple of spelling mistakes in Kconfig
- bbt: Skip bad blocks when searching for the BBT in NAND
- Remove never changed ret variable
Raw NAND changes:
- cafe: Fix a resource leak in the error handling path of 'cafe_nand_probe()'
- intel: Fix error handling in probe
- omap: Fix kernel doc warning on 'calcuate' typo
- gpmc: Fix the ECC bytes vs. OOB bytes equation
SPI-NAND core changes:
- Properly fill the OOB area.
- Fix comment
SPI-NAND drivers changes:
- macronix: Add Quad support for serial NAND flash"
* tag 'mtd/for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (30 commits)
mtd: rawnand: cafe: Fix a resource leak in the error handling path of 'cafe_nand_probe()'
mtd_blkdevs: simplify the refcounting in blktrans_{open, release}
mtd_blkdevs: simplify blktrans_getgeo
mtd_blkdevs: remove blktrans_ref_mutex
mtd_blkdevs: simplify blktrans_dev_get
mtd/rfd_ftl: don't cast away the type when calling add_mtd_blktrans_dev
mtd/ftl: don't cast away the type when calling add_mtd_blktrans_dev
mtd_blkdevs: use lockdep_assert_held
mtd_blkdevs: don't hold del_mtd_blktrans_dev in blktrans_{open, release}
mtd: rawnand: intel: Fix error handling in probe
mtd: mtdconcat: Check _read, _write callbacks existence before assignment
mtd: mtdconcat: Judge callback existence based on the master
mtd: maps: remove dead MTD map driver for PMC-Sierra MSP boards
mtd: rfd_ftl: use container_of() rather than cast
mtd: rfd_ftl: fix use-after-free
mtd: rfd_ftl: add discard support
mtd: rfd_ftl: allow use of MTD_RAM for testing purposes
mtdblock: Warn if added for a NAND device
mtd: spinand: macronix: Add Quad support for serial NAND flash
mtdblock: Add comment about UBI block devices
...
A successful 'init_rs_non_canonical()' call should be balanced by a
corresponding 'free_rs()' call in the error handling path of the probe, as
already done in the remove function.
Update the error handling path accordingly.
Fixes: 8c61b7a7f4 ("[MTD] [NAND] Use rslib for CAFÉ ECC")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/fd313d3fb787458bcc73189e349f481133a2cdc9.1629532640.git.christophe.jaillet@wanadoo.fr
ebu_nand_probe() did not invoke ebu_dma_cleanup() and
clk_disable_unprepare() on some error handling paths. The patch fixes
that.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 0b1039f016 ("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: Kirill Shilimanov <kirill.shilimanov@huawei.com>
Co-developed-by: Anton Vasilyev <vasilyev@ispras.ru>
Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210817092930.23040-1-novikov@ispras.ru
Adding FLAG "SPINAND_HAS_QE_BIT" for Quad mode support on Macronix
Serial Flash.
Validated via normal(default) and QUAD mode by read, erase, read back,
on Xilinx Zynq PicoZed FPGA board which included Macronix
SPI Host(drivers/spi/spi-mxic.c).
Signed-off-by: Jaime Liao <jaimeliao@mxic.com.tw>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/1628472472-32008-1-git-send-email-jaimeliao@mxic.com.tw
The ret variable used for returning value in the function
`meson_nfc_rw_cmd_prepare_and_execute` is never change after initialising.
Therefore, we can remove it safely and return 0 at the end of the function.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210803113300.24230-1-wangborong@cdjrlc.com
Fix a trivial typo which is reported after enabling W=1 level of warnings:
drivers/mtd/nand/raw/omap2.c:927: warning: expecting prototype
for omap_calcuate_ecc(). Prototype was for omap_calculate_ecc() instead
Signed-off-by: Vladimir Molokov <vladimir@molokov.se>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210801205909.7102-1-vladimir@molokov.se
The comment in spinand_write_to_cache_op() says that
spinand_ondie_ecc_prepare_io_req() should 0xff fill the OOB
area but it doesn't.
This causes the OOB area to get filled with zeros
and anytime the first page in a block the bad block marker
is cleared and it becomes a bad block on the next boot.
This was observed on Longsys FORSEE branded parts and
might be specific to these parts.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210617110842.2358461-1-daniel@0x0f.com
Due to 14f97f0b8e, the rawnand platforms without "secure-regions"
property defined in DT fails to probe. The issue is,
of_get_nand_secure_regions() errors out if
of_property_count_elems_of_size() returns a negative error code.
If the "secure-regions" property is not present in DT, then also we'll
get -EINVAL from of_property_count_elems_of_size() but it should not
be treated as an error for platforms not declaring "secure-regions"
in DT.
So fix this behaviour by checking for the existence of that property in
DT and return 0 if it is not present.
Fixes: 14f97f0b8e ("mtd: rawnand: Add a check in of_get_nand_secure_regions()")
Reported-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Martin Kaiser <martin@kaiser.cx>
Tested-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210727062813.32619-1-manivannan.sadhasivam@linaro.org
The blocks containing the bad block table can become bad as well. So
make sure to skip any blocks that are marked bad when searching for the
bad block table.
Otherwise in very rare cases where two BBT blocks wear out it might
happen that an obsolete BBT is used instead of a newer available
version.
This only applies to drivers which make use of a bad block marker in flash.
Other drivers won't be able to identify bad BBT blocks and thus can't skip
these.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210625123821.207458-1-s.riedmueller@phytec.de
Check for whether of_property_count_elems_of_size() returns a negative
error code.
Fixes: 13b8976827 ("mtd: rawnand: Add support for secure regions in NAND memory")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/YMtQFXE0F1w7mUh+@mwanda
* Convert list_for_each to entry variant
* Use MTD_DEVICE_ATTR_RO/RW() helper macros
* Remove unnecessary OOM messages
* Potential NULL dereference in mtd_otp_size()
* Fix freeing of otp_info buffer
* Create partname and partid debug files for child MTDs
* tests:
- Remove redundant assignment to err
- Fix error return code in mtd_oobtest_init()
* Add OTP NVMEM provider support
* Allow specifying of_node
* Convert sysfs sprintf/snprintf family to sysfs_emit
Bindings changes:
* Convert ti,am654-hbmc.txt to YAML schema
* spi-nor: add otp property
* Add OTP bindings
* add YAML schema for the generic MTD bindings
* Add brcm,trx-magic
MTD device drivers changes:
* Add support for microchip 48l640 EERAM
* Remove superfluous "break"
* sm_ftl:
- Fix alignment of block comment
* nftl:
- Return -ENOMEM when kmalloc failed
* nftlcore:
- Remove set but rewrite variables
* phram:
- Fix error return code in phram_setup()
* plat-ram:
- Remove redundant dev_err call in platram_probe()
MTD parsers changes:
* Qcom:
- Fix leaking of partition name
* Redboot:
- Fix style issues
- Seek fis-index-block in the right node
* trx:
- Allow to use TRX parser on Mediatek SoCs
- Allow to specify brcm, trx-magic in DT
Raw NAND core:
* Allow SDR timings to be nacked
* Bring support for NV-DDR timings which involved a number of small
preparation changes to bring new helpers, properly introduce NV-DDR
structures, fill them, differenciate them and pick the best timing set.
* Add the necessary infrastructure to parse the new gpio-cs property
which aims at enlarging the number of available CS when a hardware
controller is too constrained.
* Update dead URL
* Silence static checker warning in nand_setup_interface()
* BBT:
- Fix corner case in bad block table handling
* onfi:
- Use more recent ONFI specification wording
- Use the BIT() macro when possible
Raw NAND controller drivers:
* Atmel:
- Ensure the data interface is supported.
* Arasan:
- Finer grain NV-DDR configuration
- Rename the data interface register
- Use the right DMA mask
- Leverage additional GPIO CS
- Ensure proper configuration for the asserted target
- Add support for the NV-DDR interface
- Fix a macro parameter
* brcmnand:
- Convert bindings to json-schema
* OMAP:
- Various fixes and style improvements
- Add larger page NAND chips support
* PL35X:
- New driver
* QCOM:
- Avoid writing to obsolete register
- Delete an unneeded bool conversion
- Allow override of partition parser
* Marvell:
- Minor documentation correction
- Add missing clk_disable_unprepare() on error in marvell_nfc_resume()
* R852:
- Use DEVICE_ATTR_RO() helper macro
* MTK:
- Remove redundant dev_err call in mtk_ecc_probe()
* HISI504:
- Remove redundant dev_err call in probe
SPI-NAND core:
* Light reorganisation for the introduction of a core resume handler
* Fix double counting of ECC stats
SPI-NAND manufacturer drivers:
* Macronix:
- Add support for serial NAND flash
SPI NOR core changes:
* Ability to dump SFDP tables via sysfs
* Support for erasing OTP regions on Winbond and similar flashes
* Few API doc updates and fixes
* Locking support for MX25L12805D
SPI NOR controller drivers changes:
* Use SPI_MODE_X_MASK in nxp-spifi
* Intel Alder Lake-M SPI serial flash support
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmDcT+IACgkQJWrqGEe9
VoT5Sgf/dt92XA5K2SYNh58KPUwemB9DtkukmniGjo9AqSQwuzHxik3ITHBbFvwP
cSj5PAGoI+zpc+VQz+XuZF1Bsmxaqhy5c0aaJ9TZai2W6keB91in7nJPAhmAI5o2
4zhtAZ9qKp4pOwhFqn6jTd5+l38ok50go3HB4Ibw4UlLuvbUEv11DUcXGKnaAadH
tmXZALf65YAJVruPb4yw+cv7BVVgOPQL8C8ILtsrue7Zgya3JT1205Zbfdjo+X0v
Kl2gh7gGh1YLqzuLLBDUiDnfLIfiu/WTnPqxtqCULR9cLG4oXybXHZe9OsrP8E+P
T68+K8VvT5LKbGh47/OoUfLvrDguCA==
=XVaS
-----END PGP SIGNATURE-----
Merge tag 'mtd/for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull MTD updates from Richard Weinberger:
"MTD core changes:
- Convert list_for_each to entry variant
- Use MTD_DEVICE_ATTR_RO/RW() helper macros
- Remove unnecessary OOM messages
- Potential NULL dereference in mtd_otp_size()
- Fix freeing of otp_info buffer
- Create partname and partid debug files for child MTDs
- tests:
- Remove redundant assignment to err
- Fix error return code in mtd_oobtest_init()
- Add OTP NVMEM provider support
- Allow specifying of_node
- Convert sysfs sprintf/snprintf family to sysfs_emit
Bindings changes:
- Convert ti,am654-hbmc.txt to YAML schema
- spi-nor: add otp property
- Add OTP bindings
- add YAML schema for the generic MTD bindings
- Add brcm,trx-magic
MTD device drivers changes:
- Add support for microchip 48l640 EERAM
- Remove superfluous "break"
- sm_ftl:
- Fix alignment of block comment
- nftl:
- Return -ENOMEM when kmalloc failed
- nftlcore:
- Remove set but rewrite variables
- phram:
- Fix error return code in phram_setup()
- plat-ram:
- Remove redundant dev_err call in platram_probe()
MTD parsers changes:
- Qcom:
- Fix leaking of partition name
- Redboot:
- Fix style issues
- Seek fis-index-block in the right node
- trx:
- Allow to use TRX parser on Mediatek SoCs
- Allow to specify brcm, trx-magic in DT
Raw NAND core:
- Allow SDR timings to be nacked
- Bring support for NV-DDR timings which involved a number of small
preparation changes to bring new helpers, properly introduce NV-DDR
structures, fill them, differenciate them and pick the best timing
set.
- Add the necessary infrastructure to parse the new gpio-cs property
which aims at enlarging the number of available CS when a hardware
controller is too constrained.
- Update dead URL
- Silence static checker warning in nand_setup_interface()
- BBT:
- Fix corner case in bad block table handling
- onfi:
- Use more recent ONFI specification wording
- Use the BIT() macro when possible
Raw NAND controller drivers:
- Atmel:
- Ensure the data interface is supported.
- Arasan:
- Finer grain NV-DDR configuration
- Rename the data interface register
- Use the right DMA mask
- Leverage additional GPIO CS
- Ensure proper configuration for the asserted target
- Add support for the NV-DDR interface
- Fix a macro parameter
- brcmnand:
- Convert bindings to json-schema
- OMAP:
- Various fixes and style improvements
- Add larger page NAND chips support
- PL35X:
- New driver
- QCOM:
- Avoid writing to obsolete register
- Delete an unneeded bool conversion
- Allow override of partition parser
- Marvell:
- Minor documentation correction
- Add missing clk_disable_unprepare() on error in
marvell_nfc_resume()
- R852:
- Use DEVICE_ATTR_RO() helper macro
- MTK:
- Remove redundant dev_err call in mtk_ecc_probe()
- HISI504:
- Remove redundant dev_err call in probe
SPI-NAND core:
- Light reorganisation for the introduction of a core resume handler
- Fix double counting of ECC stats
SPI-NAND manufacturer drivers:
- Macronix:
- Add support for serial NAND flash
SPI NOR core changes:
- Ability to dump SFDP tables via sysfs
- Support for erasing OTP regions on Winbond and similar flashes
- Few API doc updates and fixes
- Locking support for MX25L12805D
SPI NOR controller drivers changes:
- Use SPI_MODE_X_MASK in nxp-spifi
- Intel Alder Lake-M SPI serial flash support"
* tag 'mtd/for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (125 commits)
mtd: spi-nor: remove redundant continue statement
mtd: rawnand: omap: Add larger page NAND chips support
mtd: rawnand: omap: Various style fixes
mtd: rawnand: omap: Check return values
mtd: rawnand: omap: Rename a macro
mtd: rawnand: omap: Aggregate the HW configuration of the ELM
mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller
dt-bindings: mtd: pl353-nand: Describe this hardware controller
MAINTAINERS: Add PL353 NAND controller entry
mtd: rawnand: qcom: avoid writing to obsolete register
mtd: rawnand: marvell: Minor documentation correction
mtd: rawnand: r852: use DEVICE_ATTR_RO() helper macro
mtd: spinand: add SPI-NAND MTD resume handler
mtd: spinand: Add spinand_init_flash() helper
mtd: spinand: add spinand_read_cfg() helper
mtd: rawnand: marvell: add missing clk_disable_unprepare() on error in marvell_nfc_resume()
mtd: rawnand: arasan: Finer grain NV-DDR configuration
mtd: rawnand: arasan: Rename the data interface register
mtd: rawnand: onfi: Fix endianness when reading NV-DDR values
mtd: rawnand: arasan: Use the right DMA mask
...
* Allow SDR timings to be nacked
* Bring support for NV-DDR timings which involved a number of small
preparation changes to bring new helpers, properly introduce NV-DDR
structures, fill them, differenciate them and pick the best timing set.
* Add the necessary infrastructure to parse the new gpio-cs property
which aims at enlarging the number of available CS when a hardware
controller is too constrained.
* Update dead URL
* Silence static checker warning in nand_setup_interface()
* BBT:
- Fix corner case in bad block table handling
* onfi:
- Use more recent ONFI specification wording
- Use the BIT() macro when possible
Raw NAND controller drivers:
* Atmel:
- Ensure the data interface is supported.
* Arasan:
- Finer grain NV-DDR configuration
- Rename the data interface register
- Use the right DMA mask
- Leverage additional GPIO CS
- Ensure proper configuration for the asserted target
- Add support for the NV-DDR interface
- Fix a macro parameter
* brcmnand:
- Convert bindings to json-schema
* OMAP:
- Various fixes and style improvements
- Add larger page NAND chips support
* PL35X:
- New driver
* QCOM:
- Avoid writing to obsolete register
- Delete an unneeded bool conversion
- Allow override of partition parser
* Marvell:
- Minor documentation correction
- Add missing clk_disable_unprepare() on error in marvell_nfc_resume()
* R852:
- Use DEVICE_ATTR_RO() helper macro
* MTK:
- Remove redundant dev_err call in mtk_ecc_probe()
* HISI504:
- Remove redundant dev_err call in probe
SPI-NAND core:
* Light reorganisation for the introduction of a core resume handler
* Fix double counting of ECC stats
SPI-NAND manufacturer drivers:
* Macronix:
- Add support for serial NAND flash
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmDS290ACgkQJWrqGEe9
VoS77wgAgKnqfFwbqzdSecVmXai9roSNHi/aMpVJvvLHSTCV35iCcNNtrz0Jno56
t/8twVPPZUI6f3vPXk5+NjKRCb8Oif3oU+tNxqG6mwzrBRf5R80pYCMm+HGPWZaK
+MolqGAbgFO088DTK5fGNtmbnb5fPT174RKRBGEH5NgK5M1q95uF8fIjBXDcjVe2
hvAyoqqC7i/bp40sxRtglgBpYYz+KUjCX11JvJPa5IuVU+8ezZSKJLSo5/CtgIKJ
mRQ8p8myiUjZngcnebjTrAA5AwQ13ai9ofKG0pHkdxwOq4lSRNgKou0Hk5+oq+s0
BFEuXnUrdnJNU7+XV+kAqBoT6WOFzg==
=I/9X
-----END PGP SIGNATURE-----
Merge tag 'nand/for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux into mtd/next
Raw NAND core:
* Allow SDR timings to be nacked
* Bring support for NV-DDR timings which involved a number of small
preparation changes to bring new helpers, properly introduce NV-DDR
structures, fill them, differenciate them and pick the best timing set.
* Add the necessary infrastructure to parse the new gpio-cs property
which aims at enlarging the number of available CS when a hardware
controller is too constrained.
* Update dead URL
* Silence static checker warning in nand_setup_interface()
* BBT:
- Fix corner case in bad block table handling
* onfi:
- Use more recent ONFI specification wording
- Use the BIT() macro when possible
Raw NAND controller drivers:
* Atmel:
- Ensure the data interface is supported.
* Arasan:
- Finer grain NV-DDR configuration
- Rename the data interface register
- Use the right DMA mask
- Leverage additional GPIO CS
- Ensure proper configuration for the asserted target
- Add support for the NV-DDR interface
- Fix a macro parameter
* brcmnand:
- Convert bindings to json-schema
* OMAP:
- Various fixes and style improvements
- Add larger page NAND chips support
* PL35X:
- New driver
* QCOM:
- Avoid writing to obsolete register
- Delete an unneeded bool conversion
- Allow override of partition parser
* Marvell:
- Minor documentation correction
- Add missing clk_disable_unprepare() on error in marvell_nfc_resume()
* R852:
- Use DEVICE_ATTR_RO() helper macro
* MTK:
- Remove redundant dev_err call in mtk_ecc_probe()
* HISI504:
- Remove redundant dev_err call in probe
SPI-NAND core:
* Light reorganisation for the introduction of a core resume handler
* Fix double counting of ECC stats
SPI-NAND manufacturer drivers:
* Macronix:
- Add support for serial NAND flash
There is no reason to be limited to 4kiB page NAND chips just because
this is the maximum length the ELM is able to handle in one go. Just
call the ELM several times and it will process as many data as needed.
Here we introduce the concept of ECC page (which is at most 4kiB). The
ELM will be sought as many times as there are ECC pages.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Ryan Barnett <ryan.barnett@collins.com>
Link: https://lore.kernel.org/linux-mtd/20210610134906.3503303-6-miquel.raynal@bootlin.com
The macro BADBLOCK_MARKER_LENGTH is pretty long and could be reduced to
BBM_LEN which is more handy to use in the code.
This is a purely cosmetic change and is only done to avoid further
change to contain 100+ char lines just because of this definition.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210610134906.3503303-3-miquel.raynal@bootlin.com
This hardware controller is embedded in XilinX Zynq-7000 SoCs and has
partial support for Hamming ECC correction.
This work is inspired from the original contributions of Punnaiah
Choudary Kalluri and Naga Sureshkumar Relli.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Michael Walle <michael@walle.cc> [on zynq-7000]
Link: https://lore.kernel.org/linux-mtd/20210610082040.2075611-19-miquel.raynal@bootlin.com
After power up, all SPI NAND's blocks are locked. Only read operations
are allowed, write and erase operations are forbidden.
The SPI NAND framework unlocks all the blocks during its initialization.
During a standby low power, the memory is powered down, losing its
configuration.
During the resume, the QSPI driver state is restored but the SPI NAND
framework does not reconfigured the memory.
This patch adds SPI-NAND MTD PM handlers for resume ops.
SPI NAND resume op re-initializes SPI NAND flash to its probed state.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210602094913.26472-4-patrice.chotard@foss.st.com
Linus Torvalds