Commit Graph

1121 Commits

Author SHA1 Message Date
Linus Torvalds 3fb561b1e0 - added support for more BCM47XX based devices
- added MIPS support for brcmstb PCIe controller
 - added Loongson 2K1000 reset driver
 - removed board support for rbtx4938/rbtx4939
 - removed support for TX4939 SoCs
 - fixes and cleanups
 -----BEGIN PGP SIGNATURE-----
 
 iQJOBAABCAA4FiEEbt46xwy6kEcDOXoUeZbBVTGwZHAFAmHhNi8aHHRzYm9nZW5k
 QGFscGhhLmZyYW5rZW4uZGUACgkQeZbBVTGwZHDjGBAAogFGgNYUSzLUHQfGdBcx
 fk/Lo+psvZ03cz5i9L4+7D0N3/K55/GXhSvDIHMhbYX41qklCy/ie+hxp3rwbjD3
 RTLV3D4YdoJkcn+lPcKgtvGxKXjLE0A2ho/TmrAce2mvrei3BWu7dDmJC0WFjmt7
 SZeg3ALjEdYVObO3vaN3pBMuuUuNvYS8DlLadzGwx1rDPHxGOZBri025bl9g6I+m
 rQHSTa3p5DY4VsqEOXy1fUZchys1pZC6D7Ja4FPracnxYF0F4jLoWVhN+xt4QpcW
 Q6o4+ykIDuL6kEKOwfTB094CeumIZSpcEwIKRYorIHeApG/XdgVBxJfcsaxBxI7V
 4KYBkxG93AWwsp9CtxGEfOADoX3XnRbMZk58d6pVW7KUPXNin73jghxkc4vmaK1R
 9lDyiq8RC8sh+HA5jkksCmf4otXstVlZGxNMKG3/qJy62pqEuFOIoB1Q8hN15c7w
 HlFM7ZFf/6ZWVWm3dSKdB+hZNWTBVL2ucH9bf4s6f408Mj2sMMRIuFUKH/zJzVZZ
 SeXy+tv5BcWbU+1EdaHzQJWM69iBCxasNyhPJkk3Hq+vqZdjkdPruzD3pVxdm169
 E6cBUSWjwrJTt8EsBWKb1+hzjZk56Brff+9AlhbLWSChto/4SJmT/wZWGvTC2hqS
 GBIIDNnd2G5k5xhuVs6qQIM=
 =wsIG
 -----END PGP SIGNATURE-----

Merge tag 'mips_5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux

Pull MIPS updates from Thomas Bogendoerfer:

 - add support for more BCM47XX based devices

 - add MIPS support for brcmstb PCIe controller

 - add Loongson 2K1000 reset driver

 - remove board support for rbtx4938/rbtx4939

 - remove support for TX4939 SoCs

 - fixes and cleanups

* tag 'mips_5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: (59 commits)
  MIPS: ath79: drop _machine_restart again
  PCI: brcmstb: Augment driver for MIPs SOCs
  MIPS: bmips: Remove obsolete DMA mapping support
  MIPS: bmips: Add support PCIe controller device nodes
  dt-bindings: PCI: Add compatible string for Brcmstb 74[23]5 MIPs SOCs
  MIPS: compressed: Fix build with ZSTD compression
  MIPS: BCM47XX: Add support for Netgear WN2500RP v1 & v2
  MIPS: BCM47XX: Add support for Netgear R6300 v1
  MIPS: BCM47XX: Add LEDs and buttons for Asus RTN-10U
  MIPS: BCM47XX: Add board entry for Linksys WRT320N v1
  MIPS: BCM47XX: Define Linksys WRT310N V2 buttons
  MIPS: Remove duplicated include in local.h
  MIPS: retire "asm/llsc.h"
  MIPS: rework local_t operation on MIPS64
  MIPS: fix local_{add,sub}_return on MIPS64
  mips/pci: remove redundant ret variable
  MIPS: Loongson64: Add missing of_node_put() in ls2k_reset_init()
  MIPS: new Kconfig option ZBOOT_LOAD_ADDRESS
  MIPS: enable both vmlinux.gz.itb and vmlinuz for generic
  MIPS: signal: Return immediately if call fails
  ...
2022-01-14 15:08:36 +01:00
Linus Torvalds 3ceff4ea07 sound updates for 5.17-rc1
It's a relatively calm development cycle, but still lots of updates in
 the driver side like Intel SOF.  Below are some highlights:
 
 * ALSA / ASoC core:
 - A new kselftest for ALSA control API
 - PCM NO_REWINDS support
 - Potential race fixes around control removals
 - Unify x86 SG-buffer memory allocation code
 - Cleanups and race fixes for ASoC DPCM locking
 
 * ASoC:
 - Refinements and cleanups around the delay() APIs
 - Wider use of dev_err_probe().
 - Continuing cleanups and improvements to the SOF code
 - Support for pin switches in simple-card derived cards
 - Support for AMD Renoir ACP, Asahi Kasei Microdevices AKM4375, Intel
   systems using NAU8825 and MAX98390, Mediatek MT8915, nVidia Tegra20
   S/PDIF, Qualcomm systems using ALC5682I-VS and Texas Instruments
   TLV320ADC3xxx
 
 * HD-audio / USB-audio:
 - Fix deadlock at HD-audio codec unbinding
 - Fixes for Tegra194 HD-audio, new HDA support for CS35L41 codec
 - Quirks for Lenovo and HP machines, Gigabyte mobo, Bose device
 
 * Misc:
 - Fix virmidi drain behavior
 
 Note that the merge of CS35L41 codec support is still half-baked, and
 at least one ACPI change is missing.  Although this won't hinder the
 kernel build itself, we're going to catch up before RC1.
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmHgHvgOHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE9/JBAAk1qY+2GE7a2j/dRW31rv2JxS3iMnCIdnp/Hn
 c0mArt8iEDPXbgmQ2b+tnuqh5GSz073UPCorxkEdAkYisbGSzk22VnfWsNwbSEgC
 p8Tqt8ma1blQWUYGzszQEN9u9BCLaMr1cO/ORZmD/f7hSq5W42Q8IYLTb1/9gdax
 +pJyBg8Y52PAKURnKWzmDoasJeDoQauxZ9R0g3BgQHj8Hb3QHQonyqKxJlyFac/e
 RyV7YycM2ES3Dj4u7TReRd9hdKeuzc2Wg8qYVC3x/9dzhKpvDM3Tg5ONw/58jW4x
 G6tuEj5SeEKH2LRQYTOLYScz9lVUalv97PCsq5LkQrDLqrO3hT+vxQpRdBZefRIQ
 +cKBd9GReRlQW9XCDrUs9ZuWtl1cyta8T3mk3WhTvjUcTlr1vd+TcyRoQvNhFNVH
 LaTjD1526Yra8BxyzSe7tyHhvOIvRWwjzSfwCyYV9097wV82+rOReqHyMDhN7Djc
 NbBQvoIh7v1Yo+hOYE3RUUhS5h+CJH8l43J1pWNODjXVYivYTzCOizDdJ8ktRaHE
 gpQ1vAM4pW1R5mQsyIwj6G9B1bclYboVBjlE9SXCpT3vmDneIWuLUmNV89gyNW+p
 96B3dL4BoCTyBtGYBtow2Es+/rX2dEWtM6pvOSHhRDoWL586Snr2lXDEbAQ9uZF9
 zpq1uqs=
 =csTR
 -----END PGP SIGNATURE-----

Merge tag 'sound-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound updates from Takashi Iwai:
 "It's a relatively calm development cycle, but still lots of updates in
  the driver side like Intel SOF. Below are some highlights:

  ALSA / ASoC core:
   - A new kselftest for ALSA control API
   - PCM NO_REWINDS support
   - Potential race fixes around control removals
   - Unify x86 SG-buffer memory allocation code
   - Cleanups and race fixes for ASoC DPCM locking

  ASoC:
   - Refinements and cleanups around the delay() APIs
   - Wider use of dev_err_probe().
   - Continuing cleanups and improvements to the SOF code
   - Support for pin switches in simple-card derived cards
   - Support for AMD Renoir ACP, Asahi Kasei Microdevices AKM4375, Intel
     systems using NAU8825 and MAX98390, Mediatek MT8915, nVidia Tegra20
     S/PDIF, Qualcomm systems using ALC5682I-VS and Texas Instruments
     TLV320ADC3xxx

  HD-audio / USB-audio:
   - Fix deadlock at HD-audio codec unbinding
   - Fixes for Tegra194 HD-audio, new HDA support for CS35L41 codec
   - Quirks for Lenovo and HP machines, Gigabyte mobo, Bose device

  Misc:
   - Fix virmidi drain behavior

  Note that the merge of CS35L41 codec support is still half-baked, and
  at least one ACPI change is missing. Although this won't hinder the
  kernel build itself, we're going to catch up before RC1"

* tag 'sound-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (415 commits)
  ALSA: hda: intel-dsp-config: reorder the config table
  ALSA: hda: intel-dsp-config: add JasperLake support
  ALSA: hda: cs35l41: fix double free on error in probe()
  ALSA: hda: Fix dependencies of CS35L41 on SPI/I2C buses
  ALSA: hda: Fix dependency on ASoC cs35l41 codec
  ASoC: cs35l41: Add support for hibernate memory retention mode
  ASoC: cs35l41: Update handling of test key registers
  ALSA: intel_hdmi: Check for error num after setting mask
  ASoC: wcd9335: Keep a RX port value for each SLIM RX mux
  ASoC: amd: acp: acp-mach: Change default RT1019 amp dev id
  ALSA: virmidi: Remove duplicated code
  ALSA: seq: virmidi: Add a drain operation
  ASoC: topology: Fix typo
  ASoC: fsl_asrc: refine the check of available clock divider
  ASoC: Intel: bytcr_rt5640: Add support for external GPIO jack-detect
  ASoC: Intel: bytcr_rt5640: Support retrieving the codec IRQ from the AMCR0F28 ACPI dev
  ASoC: rt5640: Add support for boards with an external jack-detect GPIO
  ASoC: rt5640: Allow snd_soc_component_set_jack() to override the codec IRQ
  ASoC: rt5640: Change jack_work to a delayed_work
  ASoC: rt5640: Fix possible NULL pointer deref on resume
  ...
2022-01-14 14:55:38 +01:00
Linus Torvalds c01d85c219 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:
 * 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
  ...
2022-01-11 11:35:28 -08:00
Linus Torvalds e85195d5bf ARM: SoC driver updates for v5.17
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
  ...
2022-01-10 08:13:52 -08:00
Thomas Bogendoerfer fc5bb239d5 MIPS: TXX9: Remove TX4939 SoC support
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>
2022-01-02 14:12:03 +01:00
Miquel Raynal 9ce47e43a0 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
 -----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>
2021-12-31 13:31:34 +01:00
Miquel Raynal 2997e48716 Memory controller drivers for v5.17 - OMAP GPMC
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>
2021-12-31 12:45:57 +01:00
Lad Prabhakar ecb78b290b mtd: rawnand: gpmi: Use platform_get_irq_byname() to get the interrupt
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
2021-12-22 17:26:03 +01:00
Lad Prabhakar 3b2af5c617 mtd: rawnand: omap_elm: Use platform_get_irq() to get the interrupt
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
2021-12-22 17:26:01 +01:00
Roger Quadros dbcb124ace mtd: rawnand: omap2: Select GPMC device driver for ARCH_K3
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>
2021-12-22 16:51:43 +01:00
Roger Quadros f2f8115fe8 memory: omap-gpmc: Use a compatible match table when checking for NAND controller
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>
2021-12-22 16:51:14 +01:00
Miquel Raynal d8701fe890 mtd: rawnand: renesas: Add new NAND controller driver
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
2021-12-21 18:06:35 +01:00
Minghao Chi 35a441eea7 mtd: rawnand: gpmi: remove unneeded variable
Return status directly from function called.

Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211213112627.436745-1-chi.minghao@zte.com.cn
2021-12-17 11:26:07 +01:00
Roger Quadros 44d73223fe mtd: rawnand: omap2: drop unused variable
devsize is not used anywhere in code. Drop it.

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-7-rogerq@kernel.org
2021-12-17 11:26:05 +01:00
Roger Quadros 4695a3cf00 mtd: rawnand: omap2: fix force_8bit flag behaviour for DMA mode
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
2021-12-17 11:26:03 +01:00
Roger Quadros 0137c74ad8 mtd: rawnand: omap2: Add compatible for AM64 SoC
AM64 SoC contains the GPMC NAND controller. Add compatible for it.

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-5-rogerq@kernel.org
2021-12-17 11:26:01 +01:00
Roger Quadros a9e849efca mtd: rawnand: omap2: move to exec_op interface
Stop using legacy interface and move to the exec_op interface.

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-4-rogerq@kernel.org
2021-12-17 11:25:59 +01:00
Roger Quadros 35da0c4545 mtd: rawnand: omap2: Allow build on K3 platforms
K3 platforms come with GPMC. Enable GPMC build for
K3 platforms.

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-3-rogerq@kernel.org
2021-12-17 11:25:58 +01:00
Arnd Bergmann 03de6b2738 dmaengine: qcom-adm: stop abusing slave_id config
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>
2021-12-17 11:23:56 +05:30
Dmitry Osipenko 6902dc2fd5 mtd: rawnand: tegra: Add runtime PM and OPP support
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>
2021-12-16 14:05:24 +01:00
Miquel Raynal 67b967ddd9 mtd: Introduce an expert mode for forensics and debugging purposes
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
2021-12-09 17:51:59 +01:00
Geert Uytterhoeven 33a0da68fb mtd: rawnand: mpc5121: Remove unused variable in ads5121_select_chip()
drivers/mtd/nand/raw/mpc5121_nfc.c: In function ‘ads5121_select_chip’:
drivers/mtd/nand/raw/mpc5121_nfc.c:294:19: warning: unused variable ‘mtd’ [-Wunused-variable]
  294 |  struct mtd_info *mtd = nand_to_mtd(nand);
      |                   ^~~

Fixes: 758b56f58b ("mtd: rawnand: Pass a nand_chip object to chip->select_chip()")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211122132138.3899138-1-geert@linux-m68k.org
2021-12-03 14:34:43 +01:00
Herve Codina 9472335eaa mtd: rawnand: fsmc: Fix timing computation
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
2021-12-03 14:33:45 +01:00
Herve Codina a4ca0c439f mtd: rawnand: fsmc: Take instruction delay into account
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
2021-12-03 14:33:45 +01:00
Herve Codina 36a65982a9 mtd: rawnand: Fix nand_choose_best_timings() on unsupported interface
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
2021-12-03 14:33:44 +01:00
Herve Codina 16d8b628a4 mtd: rawnand: Fix nand_erase_op delay
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
2021-12-03 14:33:44 +01:00
Cai Huoqing 2e69e18aec mtd: rawnand: denali: Add the dependency on HAS_IOMEM
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
2021-12-03 14:33:43 +01:00
Christian Eggers f53d4c109a mtd: rawnand: gpmi: Add ERR007117 protection for nfc_apply_timings
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
2021-11-19 19:43:14 +01:00
Stefan Riedmueller aa1baa0e6c mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6
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
2021-11-19 19:43:14 +01:00
Paul Cercueil 0171480007 mtd: rawnand: ingenic: JZ4740 needs 'oob_first' read page function
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
2021-11-19 19:43:11 +01:00
Paul Cercueil d8466f7301 mtd: rawnand: Export nand_read_page_hwecc_oob_first()
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
2021-11-19 19:43:11 +01:00
Paul Cercueil 0697f8441f mtd: rawnand: davinci: Rewrite function description
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
2021-11-19 19:43:07 +01:00
Paul Cercueil 9c9d709965 mtd: rawnand: davinci: Avoid duplicated page read
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
2021-11-19 19:43:04 +01:00
Paul Cercueil 71e8959150 mtd: rawnand: davinci: Don't calculate ECC when reading page
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
2021-11-19 19:43:00 +01:00
Linus Torvalds 206825f50f 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()
 -----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"
  ...
2021-11-08 11:37:39 -08:00
Miquel Raynal fc9e18f9e9 mtd: rawnand: arasan: Prevent an unsupported configuration
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
2021-10-15 12:24:54 +02:00
Chris Morgan eec417fd31 mtd: rawnand: hynix: Add support for H27UCG8T2ETR-BC MLC NAND
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
2021-10-15 12:24:50 +02:00
Miquel Raynal 6bcd2960af mtd: rawnand: xway: Keep the driver compatible with on-die ECC engines
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
2021-10-15 12:21:31 +02:00
Miquel Raynal b4ebddd654 mtd: rawnand: socrates: Keep the driver compatible with on-die ECC engines
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
2021-10-15 12:21:29 +02:00
Miquel Raynal 325fd539fc mtd: rawnand: plat_nand: Keep the driver compatible with on-die ECC engines
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
2021-10-15 12:21:26 +02:00
Miquel Raynal f16b7d2a5e mtd: rawnand: pasemi: Keep the driver compatible with on-die ECC engines
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
2021-10-15 12:21:24 +02:00
Miquel Raynal 194ac63de6 mtd: rawnand: orion: Keep the driver compatible with on-die ECC engines
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
2021-10-15 12:21:22 +02:00
Miquel Raynal f9d8570b7f mtd: rawnand: mpc5121: Keep the driver compatible with on-die ECC engines
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
2021-10-15 12:21:20 +02:00
Miquel Raynal b5b5b4dc6f mtd: rawnand: gpio: Keep the driver compatible with on-die ECC engines
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
2021-10-15 12:21:18 +02:00
Miquel Raynal 7e3cdba176 mtd: rawnand: au1550nd: Keep the driver compatible with on-die ECC engines
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
2021-10-15 12:21:16 +02:00
Miquel Raynal d707bb74da mtd: rawnand: ams-delta: Keep the driver compatible with on-die ECC engines
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
2021-10-15 12:21:14 +02:00
Miquel Raynal c625823ad8 Revert "mtd: rawnand: cs553x: Fix external use of SW Hamming ECC helper"
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
2021-10-15 12:21:11 +02:00
Miquel Raynal fe972c458f Revert "mtd: rawnand: lpc32xx_slc: Fix external use of SW Hamming ECC helper"
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
2021-10-15 12:21:09 +02:00
Miquel Raynal 8d1e4218a6 Revert "mtd: rawnand: ndfc: Fix external use of SW Hamming ECC helper"
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
2021-10-15 12:21:07 +02:00
Miquel Raynal 1d5f55634c Revert "mtd: rawnand: sharpsl: Fix external use of SW Hamming ECC helper"
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
2021-10-15 12:21:05 +02:00