All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v6 00/28] External ECC engines & Macronix support
@ 2021-12-16 11:16 ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Hello all,

Here is a new iteration for this big series, this time I am reincluding
the initial binding changes because they changed very slightly and at
least it gives reviewers a better understanding of the entire work
again.

Once I'll get Rob's ack on the final DT change I will apply (in a topic
branch) all the patches until "mtd: nand: ecc: Provide a helper to
retrieve a pipelined engine device", which brings everything that is
needed to support external engines, as well as the Macronix example.

I will need further acknowledgments for the second half which brings
support for pipelined engines (even though I hope we are close to an
agreement now).

Cheers,
Miquèl

Changes in v6:
* Re-include the first patches because a few things have changed in the
  bindings. These are only style changes as Rob asked to group every
  property above or below the description field, which I applied to all
  the binding commits, but without any further update.
* Created a spi-mem capabilities structure. Put that one in the spi-mem
  ops strucure and ensured that all the controllers provided one.
* Created a default "no-caps" empty instance that controller drivers can
  point to by default.
* Dropped the spi_mem_generic_defaults_op() intermediate helper entirely
  (not needed anymore).

Changes in v5:
* Moved a helper in the core as it seems that it will be useful for
  other ECC engines as well (Xiangsheng Hou for Mediatek will need it).
* Changed the parameters of the spi_mem_generic_supports_op() function
  in order to take a structure as input instead of a list of arguments,
  which will be much easier to complement in the future if ever needed.

Changes in v4:
* The first half of the series has been left aside (all the binding
  changes + the external mode in the Macronix driver), now let's focus
  on the pipelined mode.
* Added the ecc_en spi_mem_op structure parameter in a dedicated commit.
* Introduced a new helper for supporting generically the supported ops.
* Used this new helper in the macronix driver.
* By default all the other drivers would refuse a spi_mem_op with ecc_en
  enabled.

Changes in v3:
* Added Mark's R-by.
* Added a commit changing the initialization order between the dirmaps
  and the ECC engine so that the core might now if we are using a
  pipelined engine or not.
* Stopped creating additional dirmaps with ECC if the engine is not a
  pipelined engine.
* Solved the kernel test robot reports. In particular, I added a
  dependency on MTD_NAND_ECC to Macronix SPI controller driver.
* Added a patch to clean the NAND controller yaml file before moving
  some bits to nand-chip.yaml. This addresses the comments made by Rob
  about the useless allOf's.
* Used platform_get_irq_byname_optional() in order to avoid useless
  warnings when there is no IRQ.

Changes in v2:
* Fixed the bindings and added Rob's acks when relevant.
* Added locking in the ECC engine driver.
* Brought more changes in the core in order to bring the ECC information
  into the spi_mem_op structure with the idea of avoiding any races
  between parallel calls on the same engine.
* Reorganized the ECC driver entirely in order to have a per-engine mxic
  structure plus a per-NAND context. This lead to a number of changes
  internally which cannot all be listed.

Changes since the RFC:
* Rebased on top of v5.15-rc1.
* Fixed the dirmap configuration.
* Added the various tags received.
* Fixed the bindings as reported by the robots.
* Fixed the return value of the helper counting bitflips.
* Included a fix from Jaime Liao in the external pattern logic.
* Added the yaml conversion of Macronix SPI controller description.
* Added the yaml conversion of the SPI-NAND description.
* Created a nand-chip.yaml file to share properties between SPI-NAND and
  raw NAND.

Mason Yang (1):
  mtd: spinand: macronix: Use random program load

Miquel Raynal (27):
  dt-bindings: mtd: nand-controller: Fix the reg property description
  dt-bindings: mtd: nand-controller: Fix a comment in the examples
  dt-bindings: mtd: nand-controller: Harmonize the property types
  dt-bindings: mtd: nand-chip: Create a NAND chip description
  dt-bindings: mtd: spi-nand: Convert spi-nand description file to yaml
  dt-bindings: vendor-prefixes: Clarify Macronix prefix
  dt-bindings: spi: mxic: The interrupt property is not mandatory
  dt-bindings: spi: mxic: Convert to yaml
  dt-bindings: spi: mxic: Document the nand-ecc-engine property
  dt-bindings: mtd: Describe Macronix NAND ECC engine
  mtd: nand: ecc: Add infrastructure to support hardware engines
  mtd: nand: Add a new helper to retrieve the ECC context
  mtd: nand: mxic-ecc: Add Macronix external ECC engine support
  mtd: nand: ecc: Provide a helper to retrieve a pilelined engine device
  mtd: nand: mxic-ecc: Support SPI pipelined mode
  mtd: spinand: Delay a little bit the dirmap creation
  spi: spi-mem: Fix a DTR related check in spi_mem_dtr_supports_op()
  spi: spi-mem: Introduce a capability structure
  spi: spi-mem: Fill the spi-mem controller capabilities of all the
    drivers
  spi: spi-mem: Kill the spi_mem_dtr_supports_op() helper
  spi: spi-mem: Add an ecc_en parameter to the spi_mem_op structure
  mtd: spinand: Create direct mapping descriptors for ECC operations
  spi: mxic: Fix the transmit path
  spi: mxic: Create a helper to configure the controller before an
    operation
  spi: mxic: Create a helper to ease the start of an operation
  spi: mxic: Add support for direct mapping
  spi: mxic: Add support for pipelined ECC operations

 .../bindings/mtd/mxicy,nand-ecc-engine.yaml   |  77 ++
 .../devicetree/bindings/mtd/nand-chip.yaml    |  70 ++
 .../bindings/mtd/nand-controller.yaml         |  72 +-
 .../devicetree/bindings/mtd/spi-nand.txt      |   5 -
 .../devicetree/bindings/mtd/spi-nand.yaml     |  27 +
 .../bindings/spi/mxicy,mx25f0a-spi.yaml       |  65 ++
 .../devicetree/bindings/spi/spi-mxic.txt      |  34 -
 .../devicetree/bindings/vendor-prefixes.yaml  |   3 +
 drivers/mtd/nand/Kconfig                      |   6 +
 drivers/mtd/nand/Makefile                     |   1 +
 drivers/mtd/nand/core.c                       |  10 +-
 drivers/mtd/nand/ecc-mxic.c                   | 871 ++++++++++++++++++
 drivers/mtd/nand/ecc.c                        | 119 +++
 drivers/mtd/nand/spi/core.c                   |  51 +-
 drivers/mtd/nand/spi/macronix.c               |   2 +-
 drivers/spi/Kconfig                           |   2 +-
 drivers/spi/atmel-quadspi.c                   |   3 +-
 drivers/spi/spi-bcm-qspi.c                    |   1 +
 drivers/spi/spi-cadence-quadspi.c             |  10 +-
 drivers/spi/spi-dw-core.c                     |   1 +
 drivers/spi/spi-fsl-qspi.c                    |   1 +
 drivers/spi/spi-hisi-sfc-v3xx.c               |   1 +
 drivers/spi/spi-mem.c                         |  33 +-
 drivers/spi/spi-mtk-nor.c                     |   3 +-
 drivers/spi/spi-mxic.c                        | 340 +++++--
 drivers/spi/spi-npcm-fiu.c                    |   1 +
 drivers/spi/spi-nxp-fspi.c                    |   1 +
 drivers/spi/spi-rockchip-sfc.c                |   1 +
 drivers/spi/spi-rpc-if.c                      |   1 +
 drivers/spi/spi-stm32-qspi.c                  |   1 +
 drivers/spi/spi-ti-qspi.c                     |   1 +
 drivers/spi/spi-zynq-qspi.c                   |   1 +
 drivers/spi/spi-zynqmp-gqspi.c                |   1 +
 drivers/spi/spi.c                             |   3 +
 include/linux/mtd/nand-ecc-mxic.h             |  49 +
 include/linux/mtd/nand.h                      |  34 +
 include/linux/mtd/spinand.h                   |   2 +
 include/linux/spi/spi-mem.h                   |  27 +-
 38 files changed, 1727 insertions(+), 204 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml
 create mode 100644 Documentation/devicetree/bindings/mtd/nand-chip.yaml
 delete mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.yaml
 create mode 100644 Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
 delete mode 100644 Documentation/devicetree/bindings/spi/spi-mxic.txt
 create mode 100644 drivers/mtd/nand/ecc-mxic.c
 create mode 100644 include/linux/mtd/nand-ecc-mxic.h

-- 
2.27.0


^ permalink raw reply	[flat|nested] 119+ messages in thread

* [PATCH v6 00/28] External ECC engines & Macronix support
@ 2021-12-16 11:16 ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Hello all,

Here is a new iteration for this big series, this time I am reincluding
the initial binding changes because they changed very slightly and at
least it gives reviewers a better understanding of the entire work
again.

Once I'll get Rob's ack on the final DT change I will apply (in a topic
branch) all the patches until "mtd: nand: ecc: Provide a helper to
retrieve a pipelined engine device", which brings everything that is
needed to support external engines, as well as the Macronix example.

I will need further acknowledgments for the second half which brings
support for pipelined engines (even though I hope we are close to an
agreement now).

Cheers,
Miquèl

Changes in v6:
* Re-include the first patches because a few things have changed in the
  bindings. These are only style changes as Rob asked to group every
  property above or below the description field, which I applied to all
  the binding commits, but without any further update.
* Created a spi-mem capabilities structure. Put that one in the spi-mem
  ops strucure and ensured that all the controllers provided one.
* Created a default "no-caps" empty instance that controller drivers can
  point to by default.
* Dropped the spi_mem_generic_defaults_op() intermediate helper entirely
  (not needed anymore).

Changes in v5:
* Moved a helper in the core as it seems that it will be useful for
  other ECC engines as well (Xiangsheng Hou for Mediatek will need it).
* Changed the parameters of the spi_mem_generic_supports_op() function
  in order to take a structure as input instead of a list of arguments,
  which will be much easier to complement in the future if ever needed.

Changes in v4:
* The first half of the series has been left aside (all the binding
  changes + the external mode in the Macronix driver), now let's focus
  on the pipelined mode.
* Added the ecc_en spi_mem_op structure parameter in a dedicated commit.
* Introduced a new helper for supporting generically the supported ops.
* Used this new helper in the macronix driver.
* By default all the other drivers would refuse a spi_mem_op with ecc_en
  enabled.

Changes in v3:
* Added Mark's R-by.
* Added a commit changing the initialization order between the dirmaps
  and the ECC engine so that the core might now if we are using a
  pipelined engine or not.
* Stopped creating additional dirmaps with ECC if the engine is not a
  pipelined engine.
* Solved the kernel test robot reports. In particular, I added a
  dependency on MTD_NAND_ECC to Macronix SPI controller driver.
* Added a patch to clean the NAND controller yaml file before moving
  some bits to nand-chip.yaml. This addresses the comments made by Rob
  about the useless allOf's.
* Used platform_get_irq_byname_optional() in order to avoid useless
  warnings when there is no IRQ.

Changes in v2:
* Fixed the bindings and added Rob's acks when relevant.
* Added locking in the ECC engine driver.
* Brought more changes in the core in order to bring the ECC information
  into the spi_mem_op structure with the idea of avoiding any races
  between parallel calls on the same engine.
* Reorganized the ECC driver entirely in order to have a per-engine mxic
  structure plus a per-NAND context. This lead to a number of changes
  internally which cannot all be listed.

Changes since the RFC:
* Rebased on top of v5.15-rc1.
* Fixed the dirmap configuration.
* Added the various tags received.
* Fixed the bindings as reported by the robots.
* Fixed the return value of the helper counting bitflips.
* Included a fix from Jaime Liao in the external pattern logic.
* Added the yaml conversion of Macronix SPI controller description.
* Added the yaml conversion of the SPI-NAND description.
* Created a nand-chip.yaml file to share properties between SPI-NAND and
  raw NAND.

Mason Yang (1):
  mtd: spinand: macronix: Use random program load

Miquel Raynal (27):
  dt-bindings: mtd: nand-controller: Fix the reg property description
  dt-bindings: mtd: nand-controller: Fix a comment in the examples
  dt-bindings: mtd: nand-controller: Harmonize the property types
  dt-bindings: mtd: nand-chip: Create a NAND chip description
  dt-bindings: mtd: spi-nand: Convert spi-nand description file to yaml
  dt-bindings: vendor-prefixes: Clarify Macronix prefix
  dt-bindings: spi: mxic: The interrupt property is not mandatory
  dt-bindings: spi: mxic: Convert to yaml
  dt-bindings: spi: mxic: Document the nand-ecc-engine property
  dt-bindings: mtd: Describe Macronix NAND ECC engine
  mtd: nand: ecc: Add infrastructure to support hardware engines
  mtd: nand: Add a new helper to retrieve the ECC context
  mtd: nand: mxic-ecc: Add Macronix external ECC engine support
  mtd: nand: ecc: Provide a helper to retrieve a pilelined engine device
  mtd: nand: mxic-ecc: Support SPI pipelined mode
  mtd: spinand: Delay a little bit the dirmap creation
  spi: spi-mem: Fix a DTR related check in spi_mem_dtr_supports_op()
  spi: spi-mem: Introduce a capability structure
  spi: spi-mem: Fill the spi-mem controller capabilities of all the
    drivers
  spi: spi-mem: Kill the spi_mem_dtr_supports_op() helper
  spi: spi-mem: Add an ecc_en parameter to the spi_mem_op structure
  mtd: spinand: Create direct mapping descriptors for ECC operations
  spi: mxic: Fix the transmit path
  spi: mxic: Create a helper to configure the controller before an
    operation
  spi: mxic: Create a helper to ease the start of an operation
  spi: mxic: Add support for direct mapping
  spi: mxic: Add support for pipelined ECC operations

 .../bindings/mtd/mxicy,nand-ecc-engine.yaml   |  77 ++
 .../devicetree/bindings/mtd/nand-chip.yaml    |  70 ++
 .../bindings/mtd/nand-controller.yaml         |  72 +-
 .../devicetree/bindings/mtd/spi-nand.txt      |   5 -
 .../devicetree/bindings/mtd/spi-nand.yaml     |  27 +
 .../bindings/spi/mxicy,mx25f0a-spi.yaml       |  65 ++
 .../devicetree/bindings/spi/spi-mxic.txt      |  34 -
 .../devicetree/bindings/vendor-prefixes.yaml  |   3 +
 drivers/mtd/nand/Kconfig                      |   6 +
 drivers/mtd/nand/Makefile                     |   1 +
 drivers/mtd/nand/core.c                       |  10 +-
 drivers/mtd/nand/ecc-mxic.c                   | 871 ++++++++++++++++++
 drivers/mtd/nand/ecc.c                        | 119 +++
 drivers/mtd/nand/spi/core.c                   |  51 +-
 drivers/mtd/nand/spi/macronix.c               |   2 +-
 drivers/spi/Kconfig                           |   2 +-
 drivers/spi/atmel-quadspi.c                   |   3 +-
 drivers/spi/spi-bcm-qspi.c                    |   1 +
 drivers/spi/spi-cadence-quadspi.c             |  10 +-
 drivers/spi/spi-dw-core.c                     |   1 +
 drivers/spi/spi-fsl-qspi.c                    |   1 +
 drivers/spi/spi-hisi-sfc-v3xx.c               |   1 +
 drivers/spi/spi-mem.c                         |  33 +-
 drivers/spi/spi-mtk-nor.c                     |   3 +-
 drivers/spi/spi-mxic.c                        | 340 +++++--
 drivers/spi/spi-npcm-fiu.c                    |   1 +
 drivers/spi/spi-nxp-fspi.c                    |   1 +
 drivers/spi/spi-rockchip-sfc.c                |   1 +
 drivers/spi/spi-rpc-if.c                      |   1 +
 drivers/spi/spi-stm32-qspi.c                  |   1 +
 drivers/spi/spi-ti-qspi.c                     |   1 +
 drivers/spi/spi-zynq-qspi.c                   |   1 +
 drivers/spi/spi-zynqmp-gqspi.c                |   1 +
 drivers/spi/spi.c                             |   3 +
 include/linux/mtd/nand-ecc-mxic.h             |  49 +
 include/linux/mtd/nand.h                      |  34 +
 include/linux/mtd/spinand.h                   |   2 +
 include/linux/spi/spi-mem.h                   |  27 +-
 38 files changed, 1727 insertions(+), 204 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml
 create mode 100644 Documentation/devicetree/bindings/mtd/nand-chip.yaml
 delete mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.yaml
 create mode 100644 Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
 delete mode 100644 Documentation/devicetree/bindings/spi/spi-mxic.txt
 create mode 100644 drivers/mtd/nand/ecc-mxic.c
 create mode 100644 include/linux/mtd/nand-ecc-mxic.h

-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* [PATCH v6 01/28] dt-bindings: mtd: nand-controller: Fix the reg property description
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

The reg property of a NAND device always references the chip-select(s).
The ready/busy lines are described in the nand-rb property. I believe
this was a harmless copy/paste error during the conversion to yaml.

Fixes: 212e49693592 ("dt-bindings: mtd: Add YAML schemas for the generic NAND options")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/mtd/nand-controller.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index bd217e6f5018..811f03978fc6 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -55,7 +55,7 @@ patternProperties:
     properties:
       reg:
         description:
-          Contains the native Ready/Busy IDs.
+          Contains the chip-select IDs.
 
       nand-ecc-engine:
         allOf:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 01/28] dt-bindings: mtd: nand-controller: Fix the reg property description
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

The reg property of a NAND device always references the chip-select(s).
The ready/busy lines are described in the nand-rb property. I believe
this was a harmless copy/paste error during the conversion to yaml.

Fixes: 212e49693592 ("dt-bindings: mtd: Add YAML schemas for the generic NAND options")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/mtd/nand-controller.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index bd217e6f5018..811f03978fc6 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -55,7 +55,7 @@ patternProperties:
     properties:
       reg:
         description:
-          Contains the native Ready/Busy IDs.
+          Contains the chip-select IDs.
 
       nand-ecc-engine:
         allOf:
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 02/28] dt-bindings: mtd: nand-controller: Fix a comment in the examples
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

The controller properties should be in the controller 'parent' node,
while properties in the children nodes are specific to the NAND
*chip*. This error was already present during the yaml conversion.

Fixes: 2d472aba15ff ("mtd: nand: document the NAND controller/NAND chip DT representation")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/mtd/nand-controller.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index 811f03978fc6..5cd144a9ec99 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -184,7 +184,7 @@ examples:
         nand-use-soft-ecc-engine;
         nand-ecc-algo = "bch";
 
-        /* controller specific properties */
+        /* NAND chip specific properties */
       };
 
       nand@1 {
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 02/28] dt-bindings: mtd: nand-controller: Fix a comment in the examples
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

The controller properties should be in the controller 'parent' node,
while properties in the children nodes are specific to the NAND
*chip*. This error was already present during the yaml conversion.

Fixes: 2d472aba15ff ("mtd: nand: document the NAND controller/NAND chip DT representation")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/mtd/nand-controller.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index 811f03978fc6..5cd144a9ec99 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -184,7 +184,7 @@ examples:
         nand-use-soft-ecc-engine;
         nand-ecc-algo = "bch";
 
-        /* controller specific properties */
+        /* NAND chip specific properties */
       };
 
       nand@1 {
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 03/28] dt-bindings: mtd: nand-controller: Harmonize the property types
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Harmonize the different properties in this file by:
* dropping the non-necessary allOf's
* always defining the keywords in the following order:
    - first the "description" (when relevant),
    - then the "type"/"$ref" and the other generic keywords ("enum",
      "default", etc).

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 .../bindings/mtd/nand-controller.yaml         | 26 +++++++++----------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index 5cd144a9ec99..a4fa65e872a5 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -39,8 +39,6 @@ properties:
   ranges: true
 
   cs-gpios:
-    minItems: 1
-    maxItems: 8
     description:
       Array of chip-select available to the controller. The first
       entries are a 1:1 mapping of the available chip-select on the
@@ -48,6 +46,8 @@ properties:
       chip-select as needed may follow and should be phandles of GPIO
       lines. 'reg' entries of the NAND chip subnodes become indexes of
       this array when this property is present.
+    minItems: 1
+    maxItems: 8
 
 patternProperties:
   "^nand@[a-f0-9]$":
@@ -58,8 +58,6 @@ patternProperties:
           Contains the chip-select IDs.
 
       nand-ecc-engine:
-        allOf:
-          - $ref: /schemas/types.yaml#/definitions/phandle
         description: |
           A phandle on the hardware ECC engine if any. There are
           basically three possibilities:
@@ -69,24 +67,24 @@ patternProperties:
           case the phandle should reference the node itself.
           3/ The ECC engine is external, in this case the phandle should
           reference the specific ECC engine node.
+        $ref: /schemas/types.yaml#/definitions/phandle
 
       nand-use-soft-ecc-engine:
-        type: boolean
         description: Use a software ECC engine.
+        type: boolean
 
       nand-no-ecc-engine:
-        type: boolean
         description: Do not use any ECC correction.
+        type: boolean
 
       nand-ecc-placement:
-        allOf:
-          - $ref: /schemas/types.yaml#/definitions/string
-          - enum: [ oob, interleaved ]
         description:
           Location of the ECC bytes. This location is unknown by default
           but can be explicitly set to "oob", if all ECC bytes are
           known to be stored in the OOB area, or "interleaved" if ECC
           bytes will be interleaved with regular data in the main area.
+        $ref: /schemas/types.yaml#/definitions/string
+        enum: [ oob, interleaved ]
 
       nand-ecc-algo:
         description:
@@ -102,7 +100,6 @@ patternProperties:
         default: 8
 
       nand-on-flash-bbt:
-        $ref: /schemas/types.yaml#/definitions/flag
         description:
           With this property, the OS will search the device for a Bad
           Block Table (BBT). If not found, it will create one, reserve
@@ -111,6 +108,7 @@ patternProperties:
           few pages of all the blocks will be scanned at boot time to
           find Bad Block Markers (BBM). These markers will help to
           build a volatile BBT in RAM.
+        $ref: /schemas/types.yaml#/definitions/flag
 
       nand-ecc-strength:
         description:
@@ -125,7 +123,6 @@ patternProperties:
         minimum: 1
 
       nand-ecc-maximize:
-        $ref: /schemas/types.yaml#/definitions/flag
         description:
           Whether or not the ECC strength should be maximized. The
           maximum ECC strength is both controller and chip
@@ -134,18 +131,19 @@ patternProperties:
           constraint into account. This is particularly useful when
           only the in-band area is used by the upper layers, and you
           want to make your NAND as reliable as possible.
+        $ref: /schemas/types.yaml#/definitions/flag
 
       nand-is-boot-medium:
-        $ref: /schemas/types.yaml#/definitions/flag
         description:
           Whether or not the NAND chip is a boot medium. Drivers might
           use this information to select ECC algorithms supported by
           the boot ROM or similar restrictions.
+        $ref: /schemas/types.yaml#/definitions/flag
 
       nand-rb:
-        $ref: /schemas/types.yaml#/definitions/uint32-array
         description:
           Contains the native Ready/Busy IDs.
+        $ref: /schemas/types.yaml#/definitions/uint32-array
 
       rb-gpios:
         description:
@@ -155,11 +153,11 @@ patternProperties:
           should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
 
       secure-regions:
-        $ref: /schemas/types.yaml#/definitions/uint64-matrix
         description:
           Regions in the NAND chip which are protected using a secure element
           like Trustzone. This property contains the start address and size of
           the secure regions present.
+        $ref: /schemas/types.yaml#/definitions/uint64-matrix
 
     required:
       - reg
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 03/28] dt-bindings: mtd: nand-controller: Harmonize the property types
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Harmonize the different properties in this file by:
* dropping the non-necessary allOf's
* always defining the keywords in the following order:
    - first the "description" (when relevant),
    - then the "type"/"$ref" and the other generic keywords ("enum",
      "default", etc).

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 .../bindings/mtd/nand-controller.yaml         | 26 +++++++++----------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index 5cd144a9ec99..a4fa65e872a5 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -39,8 +39,6 @@ properties:
   ranges: true
 
   cs-gpios:
-    minItems: 1
-    maxItems: 8
     description:
       Array of chip-select available to the controller. The first
       entries are a 1:1 mapping of the available chip-select on the
@@ -48,6 +46,8 @@ properties:
       chip-select as needed may follow and should be phandles of GPIO
       lines. 'reg' entries of the NAND chip subnodes become indexes of
       this array when this property is present.
+    minItems: 1
+    maxItems: 8
 
 patternProperties:
   "^nand@[a-f0-9]$":
@@ -58,8 +58,6 @@ patternProperties:
           Contains the chip-select IDs.
 
       nand-ecc-engine:
-        allOf:
-          - $ref: /schemas/types.yaml#/definitions/phandle
         description: |
           A phandle on the hardware ECC engine if any. There are
           basically three possibilities:
@@ -69,24 +67,24 @@ patternProperties:
           case the phandle should reference the node itself.
           3/ The ECC engine is external, in this case the phandle should
           reference the specific ECC engine node.
+        $ref: /schemas/types.yaml#/definitions/phandle
 
       nand-use-soft-ecc-engine:
-        type: boolean
         description: Use a software ECC engine.
+        type: boolean
 
       nand-no-ecc-engine:
-        type: boolean
         description: Do not use any ECC correction.
+        type: boolean
 
       nand-ecc-placement:
-        allOf:
-          - $ref: /schemas/types.yaml#/definitions/string
-          - enum: [ oob, interleaved ]
         description:
           Location of the ECC bytes. This location is unknown by default
           but can be explicitly set to "oob", if all ECC bytes are
           known to be stored in the OOB area, or "interleaved" if ECC
           bytes will be interleaved with regular data in the main area.
+        $ref: /schemas/types.yaml#/definitions/string
+        enum: [ oob, interleaved ]
 
       nand-ecc-algo:
         description:
@@ -102,7 +100,6 @@ patternProperties:
         default: 8
 
       nand-on-flash-bbt:
-        $ref: /schemas/types.yaml#/definitions/flag
         description:
           With this property, the OS will search the device for a Bad
           Block Table (BBT). If not found, it will create one, reserve
@@ -111,6 +108,7 @@ patternProperties:
           few pages of all the blocks will be scanned at boot time to
           find Bad Block Markers (BBM). These markers will help to
           build a volatile BBT in RAM.
+        $ref: /schemas/types.yaml#/definitions/flag
 
       nand-ecc-strength:
         description:
@@ -125,7 +123,6 @@ patternProperties:
         minimum: 1
 
       nand-ecc-maximize:
-        $ref: /schemas/types.yaml#/definitions/flag
         description:
           Whether or not the ECC strength should be maximized. The
           maximum ECC strength is both controller and chip
@@ -134,18 +131,19 @@ patternProperties:
           constraint into account. This is particularly useful when
           only the in-band area is used by the upper layers, and you
           want to make your NAND as reliable as possible.
+        $ref: /schemas/types.yaml#/definitions/flag
 
       nand-is-boot-medium:
-        $ref: /schemas/types.yaml#/definitions/flag
         description:
           Whether or not the NAND chip is a boot medium. Drivers might
           use this information to select ECC algorithms supported by
           the boot ROM or similar restrictions.
+        $ref: /schemas/types.yaml#/definitions/flag
 
       nand-rb:
-        $ref: /schemas/types.yaml#/definitions/uint32-array
         description:
           Contains the native Ready/Busy IDs.
+        $ref: /schemas/types.yaml#/definitions/uint32-array
 
       rb-gpios:
         description:
@@ -155,11 +153,11 @@ patternProperties:
           should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
 
       secure-regions:
-        $ref: /schemas/types.yaml#/definitions/uint64-matrix
         description:
           Regions in the NAND chip which are protected using a secure element
           like Trustzone. This property contains the start address and size of
           the secure regions present.
+        $ref: /schemas/types.yaml#/definitions/uint64-matrix
 
     required:
       - reg
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 04/28] dt-bindings: mtd: nand-chip: Create a NAND chip description
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

Move the NAND chip description out of the NAND controller file. Indeed,
a subsequent part of the properties supported by a raw NAND chip are
also supported by SPI-NAND chips. So let's create a generic NAND chip
description which will be pulled by nand-controller.yaml and later by
spi-nand.yaml as well.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/mtd/nand-chip.yaml    | 70 +++++++++++++++++++
 .../bindings/mtd/nand-controller.yaml         | 50 +------------
 2 files changed, 72 insertions(+), 48 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/nand-chip.yaml

diff --git a/Documentation/devicetree/bindings/mtd/nand-chip.yaml b/Documentation/devicetree/bindings/mtd/nand-chip.yaml
new file mode 100644
index 000000000000..97ac3a3fbb52
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/nand-chip.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/nand-chip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAND Chip and NAND Controller Generic Binding
+
+maintainers:
+  - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description: |
+  This file covers the generic description of a NAND chip. It implies that the
+  bus interface should not be taken into account: both raw NAND devices and
+  SPI-NAND devices are concerned by this description.
+
+properties:
+  reg:
+    description:
+      Contains the chip-select IDs.
+
+  nand-ecc-engine:
+    description: |
+      A phandle on the hardware ECC engine if any. There are
+      basically three possibilities:
+      1/ The ECC engine is part of the NAND controller, in this
+      case the phandle should reference the parent node.
+      2/ The ECC engine is part of the NAND part (on-die), in this
+      case the phandle should reference the node itself.
+      3/ The ECC engine is external, in this case the phandle should
+      reference the specific ECC engine node.
+    $ref: /schemas/types.yaml#/definitions/phandle
+
+  nand-use-soft-ecc-engine:
+    description: Use a software ECC engine.
+    type: boolean
+
+  nand-no-ecc-engine:
+    description: Do not use any ECC correction.
+    type: boolean
+
+  nand-ecc-algo:
+    description:
+      Desired ECC algorithm.
+    $ref: /schemas/types.yaml#/definitions/string
+    enum: [hamming, bch, rs]
+
+  nand-ecc-strength:
+    description:
+      Maximum number of bits that can be corrected per ECC step.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 1
+
+  nand-ecc-step-size:
+    description:
+      Number of data bytes covered by a single ECC step.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 1
+
+  secure-regions:
+    description:
+      Regions in the NAND chip which are protected using a secure element
+      like Trustzone. This property contains the start address and size of
+      the secure regions present.
+    $ref: /schemas/types.yaml#/definitions/uint64-matrix
+
+required:
+  - reg
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index a4fa65e872a5..33855eb48a79 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -52,31 +52,13 @@ properties:
 patternProperties:
   "^nand@[a-f0-9]$":
     type: object
+    $ref: "nand-chip.yaml#"
+
     properties:
       reg:
         description:
           Contains the chip-select IDs.
 
-      nand-ecc-engine:
-        description: |
-          A phandle on the hardware ECC engine if any. There are
-          basically three possibilities:
-          1/ The ECC engine is part of the NAND controller, in this
-          case the phandle should reference the parent node.
-          2/ The ECC engine is part of the NAND part (on-die), in this
-          case the phandle should reference the node itself.
-          3/ The ECC engine is external, in this case the phandle should
-          reference the specific ECC engine node.
-        $ref: /schemas/types.yaml#/definitions/phandle
-
-      nand-use-soft-ecc-engine:
-        description: Use a software ECC engine.
-        type: boolean
-
-      nand-no-ecc-engine:
-        description: Do not use any ECC correction.
-        type: boolean
-
       nand-ecc-placement:
         description:
           Location of the ECC bytes. This location is unknown by default
@@ -86,12 +68,6 @@ patternProperties:
         $ref: /schemas/types.yaml#/definitions/string
         enum: [ oob, interleaved ]
 
-      nand-ecc-algo:
-        description:
-          Desired ECC algorithm.
-        $ref: /schemas/types.yaml#/definitions/string
-        enum: [hamming, bch, rs]
-
       nand-bus-width:
         description:
           Bus width to the NAND chip
@@ -110,18 +86,6 @@ patternProperties:
           build a volatile BBT in RAM.
         $ref: /schemas/types.yaml#/definitions/flag
 
-      nand-ecc-strength:
-        description:
-          Maximum number of bits that can be corrected per ECC step.
-        $ref: /schemas/types.yaml#/definitions/uint32
-        minimum: 1
-
-      nand-ecc-step-size:
-        description:
-          Number of data bytes covered by a single ECC step.
-        $ref: /schemas/types.yaml#/definitions/uint32
-        minimum: 1
-
       nand-ecc-maximize:
         description:
           Whether or not the ECC strength should be maximized. The
@@ -152,13 +116,6 @@ patternProperties:
           Ready/Busy pins. Active state refers to the NAND ready state and
           should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
 
-      secure-regions:
-        description:
-          Regions in the NAND chip which are protected using a secure element
-          like Trustzone. This property contains the start address and size of
-          the secure regions present.
-        $ref: /schemas/types.yaml#/definitions/uint64-matrix
-
     required:
       - reg
 
@@ -179,9 +136,6 @@ examples:
 
       nand@0 {
         reg = <0>; /* Native CS */
-        nand-use-soft-ecc-engine;
-        nand-ecc-algo = "bch";
-
         /* NAND chip specific properties */
       };
 
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 04/28] dt-bindings: mtd: nand-chip: Create a NAND chip description
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

Move the NAND chip description out of the NAND controller file. Indeed,
a subsequent part of the properties supported by a raw NAND chip are
also supported by SPI-NAND chips. So let's create a generic NAND chip
description which will be pulled by nand-controller.yaml and later by
spi-nand.yaml as well.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/mtd/nand-chip.yaml    | 70 +++++++++++++++++++
 .../bindings/mtd/nand-controller.yaml         | 50 +------------
 2 files changed, 72 insertions(+), 48 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/nand-chip.yaml

diff --git a/Documentation/devicetree/bindings/mtd/nand-chip.yaml b/Documentation/devicetree/bindings/mtd/nand-chip.yaml
new file mode 100644
index 000000000000..97ac3a3fbb52
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/nand-chip.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/nand-chip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAND Chip and NAND Controller Generic Binding
+
+maintainers:
+  - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description: |
+  This file covers the generic description of a NAND chip. It implies that the
+  bus interface should not be taken into account: both raw NAND devices and
+  SPI-NAND devices are concerned by this description.
+
+properties:
+  reg:
+    description:
+      Contains the chip-select IDs.
+
+  nand-ecc-engine:
+    description: |
+      A phandle on the hardware ECC engine if any. There are
+      basically three possibilities:
+      1/ The ECC engine is part of the NAND controller, in this
+      case the phandle should reference the parent node.
+      2/ The ECC engine is part of the NAND part (on-die), in this
+      case the phandle should reference the node itself.
+      3/ The ECC engine is external, in this case the phandle should
+      reference the specific ECC engine node.
+    $ref: /schemas/types.yaml#/definitions/phandle
+
+  nand-use-soft-ecc-engine:
+    description: Use a software ECC engine.
+    type: boolean
+
+  nand-no-ecc-engine:
+    description: Do not use any ECC correction.
+    type: boolean
+
+  nand-ecc-algo:
+    description:
+      Desired ECC algorithm.
+    $ref: /schemas/types.yaml#/definitions/string
+    enum: [hamming, bch, rs]
+
+  nand-ecc-strength:
+    description:
+      Maximum number of bits that can be corrected per ECC step.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 1
+
+  nand-ecc-step-size:
+    description:
+      Number of data bytes covered by a single ECC step.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 1
+
+  secure-regions:
+    description:
+      Regions in the NAND chip which are protected using a secure element
+      like Trustzone. This property contains the start address and size of
+      the secure regions present.
+    $ref: /schemas/types.yaml#/definitions/uint64-matrix
+
+required:
+  - reg
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index a4fa65e872a5..33855eb48a79 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -52,31 +52,13 @@ properties:
 patternProperties:
   "^nand@[a-f0-9]$":
     type: object
+    $ref: "nand-chip.yaml#"
+
     properties:
       reg:
         description:
           Contains the chip-select IDs.
 
-      nand-ecc-engine:
-        description: |
-          A phandle on the hardware ECC engine if any. There are
-          basically three possibilities:
-          1/ The ECC engine is part of the NAND controller, in this
-          case the phandle should reference the parent node.
-          2/ The ECC engine is part of the NAND part (on-die), in this
-          case the phandle should reference the node itself.
-          3/ The ECC engine is external, in this case the phandle should
-          reference the specific ECC engine node.
-        $ref: /schemas/types.yaml#/definitions/phandle
-
-      nand-use-soft-ecc-engine:
-        description: Use a software ECC engine.
-        type: boolean
-
-      nand-no-ecc-engine:
-        description: Do not use any ECC correction.
-        type: boolean
-
       nand-ecc-placement:
         description:
           Location of the ECC bytes. This location is unknown by default
@@ -86,12 +68,6 @@ patternProperties:
         $ref: /schemas/types.yaml#/definitions/string
         enum: [ oob, interleaved ]
 
-      nand-ecc-algo:
-        description:
-          Desired ECC algorithm.
-        $ref: /schemas/types.yaml#/definitions/string
-        enum: [hamming, bch, rs]
-
       nand-bus-width:
         description:
           Bus width to the NAND chip
@@ -110,18 +86,6 @@ patternProperties:
           build a volatile BBT in RAM.
         $ref: /schemas/types.yaml#/definitions/flag
 
-      nand-ecc-strength:
-        description:
-          Maximum number of bits that can be corrected per ECC step.
-        $ref: /schemas/types.yaml#/definitions/uint32
-        minimum: 1
-
-      nand-ecc-step-size:
-        description:
-          Number of data bytes covered by a single ECC step.
-        $ref: /schemas/types.yaml#/definitions/uint32
-        minimum: 1
-
       nand-ecc-maximize:
         description:
           Whether or not the ECC strength should be maximized. The
@@ -152,13 +116,6 @@ patternProperties:
           Ready/Busy pins. Active state refers to the NAND ready state and
           should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
 
-      secure-regions:
-        description:
-          Regions in the NAND chip which are protected using a secure element
-          like Trustzone. This property contains the start address and size of
-          the secure regions present.
-        $ref: /schemas/types.yaml#/definitions/uint64-matrix
-
     required:
       - reg
 
@@ -179,9 +136,6 @@ examples:
 
       nand@0 {
         reg = <0>; /* Native CS */
-        nand-use-soft-ecc-engine;
-        nand-ecc-algo = "bch";
-
         /* NAND chip specific properties */
       };
 
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 05/28] dt-bindings: mtd: spi-nand: Convert spi-nand description file to yaml
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

Let's get rid of spi-nand.txt by converting it to yaml schema. While at
converting this file, let's actually pull all the generic properties
from nand-chip.yaml which might apply to a SPI-NAND chip.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/mtd/spi-nand.txt      |  5 ----
 .../devicetree/bindings/mtd/spi-nand.yaml     | 27 +++++++++++++++++++
 2 files changed, 27 insertions(+), 5 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.yaml

diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt b/Documentation/devicetree/bindings/mtd/spi-nand.txt
deleted file mode 100644
index 8b51f3b6d55c..000000000000
--- a/Documentation/devicetree/bindings/mtd/spi-nand.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-SPI NAND flash
-
-Required properties:
-- compatible: should be "spi-nand"
-- reg: should encode the chip-select line used to access the NAND chip
diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.yaml b/Documentation/devicetree/bindings/mtd/spi-nand.yaml
new file mode 100644
index 000000000000..431faac518a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/spi-nand.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/spi-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPI-NAND flash device tree bindings
+
+maintainers:
+  - Miquel Raynal <miquel.raynal@bootlin.com>
+
+allOf:
+  - $ref: "nand-chip.yaml#"
+
+properties:
+  compatible:
+    const: spi-nand
+
+  reg:
+    description: Encode the chip-select line on the SPI bus
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 05/28] dt-bindings: mtd: spi-nand: Convert spi-nand description file to yaml
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

Let's get rid of spi-nand.txt by converting it to yaml schema. While at
converting this file, let's actually pull all the generic properties
from nand-chip.yaml which might apply to a SPI-NAND chip.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/mtd/spi-nand.txt      |  5 ----
 .../devicetree/bindings/mtd/spi-nand.yaml     | 27 +++++++++++++++++++
 2 files changed, 27 insertions(+), 5 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.yaml

diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt b/Documentation/devicetree/bindings/mtd/spi-nand.txt
deleted file mode 100644
index 8b51f3b6d55c..000000000000
--- a/Documentation/devicetree/bindings/mtd/spi-nand.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-SPI NAND flash
-
-Required properties:
-- compatible: should be "spi-nand"
-- reg: should encode the chip-select line used to access the NAND chip
diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.yaml b/Documentation/devicetree/bindings/mtd/spi-nand.yaml
new file mode 100644
index 000000000000..431faac518a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/spi-nand.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/spi-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPI-NAND flash device tree bindings
+
+maintainers:
+  - Miquel Raynal <miquel.raynal@bootlin.com>
+
+allOf:
+  - $ref: "nand-chip.yaml#"
+
+properties:
+  compatible:
+    const: spi-nand
+
+  reg:
+    description: Encode the chip-select line on the SPI bus
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 06/28] dt-bindings: vendor-prefixes: Clarify Macronix prefix
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

When looking at compatible prefixes, Macronix is sometimes referred as
"mxicy":
- mxicy,mx25r1635f
- mxicy,mx25u6435f
- mxicy,mx25v8035f
- mxicy,mx25f0a-spi
and sometimes as "mxic":
- mxic,multi-itfc-v009-nand-controller
- mxic,enable-randomizer-otp

The oldest prefix that is also the one preferred by Macronix engineers
is "mxicy", so document the other one and mark it deprecated.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index a867f7102c35..93d65dc3746c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -774,6 +774,9 @@ patternProperties:
     description: Mundo Reader S.L.
   "^murata,.*":
     description: Murata Manufacturing Co., Ltd.
+  "^mxic,.*":
+    description: Macronix International Co., Ltd.
+    deprecated: true
   "^mxicy,.*":
     description: Macronix International Co., Ltd.
   "^myir,.*":
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 06/28] dt-bindings: vendor-prefixes: Clarify Macronix prefix
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

When looking at compatible prefixes, Macronix is sometimes referred as
"mxicy":
- mxicy,mx25r1635f
- mxicy,mx25u6435f
- mxicy,mx25v8035f
- mxicy,mx25f0a-spi
and sometimes as "mxic":
- mxic,multi-itfc-v009-nand-controller
- mxic,enable-randomizer-otp

The oldest prefix that is also the one preferred by Macronix engineers
is "mxicy", so document the other one and mark it deprecated.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index a867f7102c35..93d65dc3746c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -774,6 +774,9 @@ patternProperties:
     description: Mundo Reader S.L.
   "^murata,.*":
     description: Murata Manufacturing Co., Ltd.
+  "^mxic,.*":
+    description: Macronix International Co., Ltd.
+    deprecated: true
   "^mxicy,.*":
     description: Macronix International Co., Ltd.
   "^myir,.*":
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 07/28] dt-bindings: spi: mxic: The interrupt property is not mandatory
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

The interrupt property is not mandatory at all, this property should not
be part of the required properties list, so move it into the optional
properties list.

Fixes: 326e5c8d4a87 ("dt-binding: spi: Document Macronix controller bindings")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 Documentation/devicetree/bindings/spi/spi-mxic.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-mxic.txt b/Documentation/devicetree/bindings/spi/spi-mxic.txt
index 529f2dab2648..7bcbb229b78b 100644
--- a/Documentation/devicetree/bindings/spi/spi-mxic.txt
+++ b/Documentation/devicetree/bindings/spi/spi-mxic.txt
@@ -8,11 +8,13 @@ Required properties:
 - reg: should contain 2 entries, one for the registers and one for the direct
        mapping area
 - reg-names: should contain "regs" and "dirmap"
-- interrupts: interrupt line connected to the SPI controller
 - clock-names: should contain "ps_clk", "send_clk" and "send_dly_clk"
 - clocks: should contain 3 entries for the "ps_clk", "send_clk" and
 	  "send_dly_clk" clocks
 
+Optional properties:
+- interrupts: interrupt line connected to the SPI controller
+
 Example:
 
 	spi@43c30000 {
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 07/28] dt-bindings: spi: mxic: The interrupt property is not mandatory
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

The interrupt property is not mandatory at all, this property should not
be part of the required properties list, so move it into the optional
properties list.

Fixes: 326e5c8d4a87 ("dt-binding: spi: Document Macronix controller bindings")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 Documentation/devicetree/bindings/spi/spi-mxic.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-mxic.txt b/Documentation/devicetree/bindings/spi/spi-mxic.txt
index 529f2dab2648..7bcbb229b78b 100644
--- a/Documentation/devicetree/bindings/spi/spi-mxic.txt
+++ b/Documentation/devicetree/bindings/spi/spi-mxic.txt
@@ -8,11 +8,13 @@ Required properties:
 - reg: should contain 2 entries, one for the registers and one for the direct
        mapping area
 - reg-names: should contain "regs" and "dirmap"
-- interrupts: interrupt line connected to the SPI controller
 - clock-names: should contain "ps_clk", "send_clk" and "send_dly_clk"
 - clocks: should contain 3 entries for the "ps_clk", "send_clk" and
 	  "send_dly_clk" clocks
 
+Optional properties:
+- interrupts: interrupt line connected to the SPI controller
+
 Example:
 
 	spi@43c30000 {
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 08/28] dt-bindings: spi: mxic: Convert to yaml
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

Straightforward conversion from regular text to yaml schema of the
Macronix SPI controller DT bindings.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 .../bindings/spi/mxicy,mx25f0a-spi.yaml       | 60 +++++++++++++++++++
 .../devicetree/bindings/spi/spi-mxic.txt      | 36 -----------
 2 files changed, 60 insertions(+), 36 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
 delete mode 100644 Documentation/devicetree/bindings/spi/spi-mxic.txt

diff --git a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
new file mode 100644
index 000000000000..f20d100b4a68
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/mxicy,mx25f0a-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Macronix SPI controller device tree bindings
+
+maintainers:
+  - Miquel Raynal <miquel.raynal@bootlin.com>
+
+allOf:
+  - $ref: "spi-controller.yaml#"
+
+properties:
+  compatible:
+    const: mxicy,mx25f0a-spi
+
+  reg:
+    minItems: 2
+    maxItems: 2
+
+  reg-names:
+    items:
+      - const: regs
+      - const: dirmap
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    minItems: 3
+    maxItems: 3
+
+  clock-names:
+    items:
+      - const: send_clk
+      - const: send_dly_clk
+      - const: ps_clk
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    spi@43c30000 {
+      compatible = "mxicy,mx25f0a-spi";
+      reg = <0x43c30000 0x10000>, <0xa0000000 0x20000000>;
+      reg-names = "regs", "dirmap";
+      clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 18>;
+      clock-names = "send_clk", "send_dly_clk", "ps_clk";
+      #address-cells = <1>;
+      #size-cells = <0>;
+    };
diff --git a/Documentation/devicetree/bindings/spi/spi-mxic.txt b/Documentation/devicetree/bindings/spi/spi-mxic.txt
deleted file mode 100644
index 7bcbb229b78b..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-mxic.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Macronix SPI controller Device Tree Bindings
---------------------------------------------
-
-Required properties:
-- compatible: should be "mxicy,mx25f0a-spi"
-- #address-cells: should be 1
-- #size-cells: should be 0
-- reg: should contain 2 entries, one for the registers and one for the direct
-       mapping area
-- reg-names: should contain "regs" and "dirmap"
-- clock-names: should contain "ps_clk", "send_clk" and "send_dly_clk"
-- clocks: should contain 3 entries for the "ps_clk", "send_clk" and
-	  "send_dly_clk" clocks
-
-Optional properties:
-- interrupts: interrupt line connected to the SPI controller
-
-Example:
-
-	spi@43c30000 {
-		compatible = "mxicy,mx25f0a-spi";
-		reg = <0x43c30000 0x10000>, <0xa0000000 0x20000000>;
-		reg-names = "regs", "dirmap";
-		clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 18>;
-		clock-names = "send_clk", "send_dly_clk", "ps_clk";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		flash@0 {
-			compatible = "jedec,spi-nor";
-			reg = <0>;
-			spi-max-frequency = <25000000>;
-			spi-tx-bus-width = <4>;
-			spi-rx-bus-width = <4>;
-		};
-	};
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 08/28] dt-bindings: spi: mxic: Convert to yaml
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

Straightforward conversion from regular text to yaml schema of the
Macronix SPI controller DT bindings.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 .../bindings/spi/mxicy,mx25f0a-spi.yaml       | 60 +++++++++++++++++++
 .../devicetree/bindings/spi/spi-mxic.txt      | 36 -----------
 2 files changed, 60 insertions(+), 36 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
 delete mode 100644 Documentation/devicetree/bindings/spi/spi-mxic.txt

diff --git a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
new file mode 100644
index 000000000000..f20d100b4a68
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/mxicy,mx25f0a-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Macronix SPI controller device tree bindings
+
+maintainers:
+  - Miquel Raynal <miquel.raynal@bootlin.com>
+
+allOf:
+  - $ref: "spi-controller.yaml#"
+
+properties:
+  compatible:
+    const: mxicy,mx25f0a-spi
+
+  reg:
+    minItems: 2
+    maxItems: 2
+
+  reg-names:
+    items:
+      - const: regs
+      - const: dirmap
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    minItems: 3
+    maxItems: 3
+
+  clock-names:
+    items:
+      - const: send_clk
+      - const: send_dly_clk
+      - const: ps_clk
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    spi@43c30000 {
+      compatible = "mxicy,mx25f0a-spi";
+      reg = <0x43c30000 0x10000>, <0xa0000000 0x20000000>;
+      reg-names = "regs", "dirmap";
+      clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 18>;
+      clock-names = "send_clk", "send_dly_clk", "ps_clk";
+      #address-cells = <1>;
+      #size-cells = <0>;
+    };
diff --git a/Documentation/devicetree/bindings/spi/spi-mxic.txt b/Documentation/devicetree/bindings/spi/spi-mxic.txt
deleted file mode 100644
index 7bcbb229b78b..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-mxic.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Macronix SPI controller Device Tree Bindings
---------------------------------------------
-
-Required properties:
-- compatible: should be "mxicy,mx25f0a-spi"
-- #address-cells: should be 1
-- #size-cells: should be 0
-- reg: should contain 2 entries, one for the registers and one for the direct
-       mapping area
-- reg-names: should contain "regs" and "dirmap"
-- clock-names: should contain "ps_clk", "send_clk" and "send_dly_clk"
-- clocks: should contain 3 entries for the "ps_clk", "send_clk" and
-	  "send_dly_clk" clocks
-
-Optional properties:
-- interrupts: interrupt line connected to the SPI controller
-
-Example:
-
-	spi@43c30000 {
-		compatible = "mxicy,mx25f0a-spi";
-		reg = <0x43c30000 0x10000>, <0xa0000000 0x20000000>;
-		reg-names = "regs", "dirmap";
-		clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 18>;
-		clock-names = "send_clk", "send_dly_clk", "ps_clk";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		flash@0 {
-			compatible = "jedec,spi-nor";
-			reg = <0>;
-			spi-max-frequency = <25000000>;
-			spi-tx-bus-width = <4>;
-			spi-rx-bus-width = <4>;
-		};
-	};
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 09/28] dt-bindings: spi: mxic: Document the nand-ecc-engine property
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

This SPI controller supports interacting with an external ECC
engine. The nand-ecc-engine property already exist in the NAND world but
also applies to SPI controller nodes which have external correction
capabilities like Macronix's.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
index f20d100b4a68..9202c44b4478 100644
--- a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
@@ -38,6 +38,11 @@ properties:
       - const: send_dly_clk
       - const: ps_clk
 
+  nand-ecc-engine:
+    description: NAND ECC engine used by the SPI controller in order to perform
+      on-the-fly correction when using a SPI-NAND memory.
+    $ref: /schemas/types.yaml#/definitions/phandle
+
 required:
   - compatible
   - reg
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 09/28] dt-bindings: spi: mxic: Document the nand-ecc-engine property
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

This SPI controller supports interacting with an external ECC
engine. The nand-ecc-engine property already exist in the NAND world but
also applies to SPI controller nodes which have external correction
capabilities like Macronix's.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
index f20d100b4a68..9202c44b4478 100644
--- a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
@@ -38,6 +38,11 @@ properties:
       - const: send_dly_clk
       - const: ps_clk
 
+  nand-ecc-engine:
+    description: NAND ECC engine used by the SPI controller in order to perform
+      on-the-fly correction when using a SPI-NAND memory.
+    $ref: /schemas/types.yaml#/definitions/phandle
+
 required:
   - compatible
   - reg
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 10/28] dt-bindings: mtd: Describe Macronix NAND ECC engine
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

Describe Macronix NAND ECC engine. This engine may be used as an
external engine or can be pipelined with either a raw NAND controller or
a SPI controller. Both hardware designs with a SPI controller are shown
in the examples.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 .../bindings/mtd/mxicy,nand-ecc-engine.yaml   | 77 +++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml

diff --git a/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml b/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml
new file mode 100644
index 000000000000..804479999ccb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/mxicy,nand-ecc-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Macronix NAND ECC engine device tree bindings
+
+maintainers:
+  - Miquel Raynal <miquel.raynal@bootlin.com>
+
+properties:
+  compatible:
+    const: mxicy,nand-ecc-engine-rev3
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    /* External configuration */
+    spi_controller0: spi@43c30000 {
+        compatible = "mxicy,mx25f0a-spi";
+        reg = <0x43c30000 0x10000>, <0xa0000000 0x4000000>;
+        reg-names = "regs", "dirmap";
+        clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 15>;
+        clock-names = "send_clk", "send_dly_clk", "ps_clk";
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        flash@0 {
+            compatible = "spi-nand";
+            reg = <0>;
+            nand-ecc-engine = <&ecc_engine0>;
+        };
+    };
+
+    ecc_engine0: ecc@43c40000 {
+        compatible = "mxicy,nand-ecc-engine-rev3";
+        reg = <0x43c40000 0x10000>;
+    };
+
+  - |
+    /* Pipelined configuration */
+    spi_controller1: spi@43c30000 {
+        compatible = "mxicy,mx25f0a-spi";
+        reg = <0x43c30000 0x10000>, <0xa0000000 0x4000000>;
+        reg-names = "regs", "dirmap";
+        clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 15>;
+        clock-names = "send_clk", "send_dly_clk", "ps_clk";
+        #address-cells = <1>;
+        #size-cells = <0>;
+        nand-ecc-engine = <&ecc_engine1>;
+
+        flash@0 {
+            compatible = "spi-nand";
+            reg = <0>;
+            nand-ecc-engine = <&spi_controller1>;
+        };
+    };
+
+    ecc_engine1: ecc@43c40000 {
+        compatible = "mxicy,nand-ecc-engine-rev3";
+        reg = <0x43c40000 0x10000>;
+    };
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 10/28] dt-bindings: mtd: Describe Macronix NAND ECC engine
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Rob Herring

Describe Macronix NAND ECC engine. This engine may be used as an
external engine or can be pipelined with either a raw NAND controller or
a SPI controller. Both hardware designs with a SPI controller are shown
in the examples.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 .../bindings/mtd/mxicy,nand-ecc-engine.yaml   | 77 +++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml

diff --git a/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml b/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml
new file mode 100644
index 000000000000..804479999ccb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/mxicy,nand-ecc-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Macronix NAND ECC engine device tree bindings
+
+maintainers:
+  - Miquel Raynal <miquel.raynal@bootlin.com>
+
+properties:
+  compatible:
+    const: mxicy,nand-ecc-engine-rev3
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    /* External configuration */
+    spi_controller0: spi@43c30000 {
+        compatible = "mxicy,mx25f0a-spi";
+        reg = <0x43c30000 0x10000>, <0xa0000000 0x4000000>;
+        reg-names = "regs", "dirmap";
+        clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 15>;
+        clock-names = "send_clk", "send_dly_clk", "ps_clk";
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        flash@0 {
+            compatible = "spi-nand";
+            reg = <0>;
+            nand-ecc-engine = <&ecc_engine0>;
+        };
+    };
+
+    ecc_engine0: ecc@43c40000 {
+        compatible = "mxicy,nand-ecc-engine-rev3";
+        reg = <0x43c40000 0x10000>;
+    };
+
+  - |
+    /* Pipelined configuration */
+    spi_controller1: spi@43c30000 {
+        compatible = "mxicy,mx25f0a-spi";
+        reg = <0x43c30000 0x10000>, <0xa0000000 0x4000000>;
+        reg-names = "regs", "dirmap";
+        clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 15>;
+        clock-names = "send_clk", "send_dly_clk", "ps_clk";
+        #address-cells = <1>;
+        #size-cells = <0>;
+        nand-ecc-engine = <&ecc_engine1>;
+
+        flash@0 {
+            compatible = "spi-nand";
+            reg = <0>;
+            nand-ecc-engine = <&spi_controller1>;
+        };
+    };
+
+    ecc_engine1: ecc@43c40000 {
+        compatible = "mxicy,nand-ecc-engine-rev3";
+        reg = <0x43c40000 0x10000>;
+    };
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 11/28] mtd: spinand: macronix: Use random program load
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Mason Yang, Miquel Raynal

From: Mason Yang <masonccyang@mxic.com.tw>

Macronix SPI-NAND chips might benefit from an external ECC
engine. Such an engine might need to access random columns, thus needing
to use random commands (0x84 instead of 0x02).

Signed-off-by: Mason Yang <masonccyang@mxic.com.tw>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/spi/macronix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c
index 3f31f1381a62..dce835132a1e 100644
--- a/drivers/mtd/nand/spi/macronix.c
+++ b/drivers/mtd/nand/spi/macronix.c
@@ -20,7 +20,7 @@ static SPINAND_OP_VARIANTS(read_cache_variants,
 
 static SPINAND_OP_VARIANTS(write_cache_variants,
 		SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
-		SPINAND_PROG_LOAD(true, 0, NULL, 0));
+		SPINAND_PROG_LOAD(false, 0, NULL, 0));
 
 static SPINAND_OP_VARIANTS(update_cache_variants,
 		SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 11/28] mtd: spinand: macronix: Use random program load
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Mason Yang, Miquel Raynal

From: Mason Yang <masonccyang@mxic.com.tw>

Macronix SPI-NAND chips might benefit from an external ECC
engine. Such an engine might need to access random columns, thus needing
to use random commands (0x84 instead of 0x02).

Signed-off-by: Mason Yang <masonccyang@mxic.com.tw>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/spi/macronix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c
index 3f31f1381a62..dce835132a1e 100644
--- a/drivers/mtd/nand/spi/macronix.c
+++ b/drivers/mtd/nand/spi/macronix.c
@@ -20,7 +20,7 @@ static SPINAND_OP_VARIANTS(read_cache_variants,
 
 static SPINAND_OP_VARIANTS(write_cache_variants,
 		SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
-		SPINAND_PROG_LOAD(true, 0, NULL, 0));
+		SPINAND_PROG_LOAD(false, 0, NULL, 0));
 
 static SPINAND_OP_VARIANTS(update_cache_variants,
 		SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 12/28] mtd: nand: ecc: Add infrastructure to support hardware engines
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Add the necessary helpers to register/unregister hardware ECC engines
that will be called from ECC engine drivers.

Also add helpers to get the right engine from the user
perspective. Keep a reference of the in use ECC engine in order to
prevent modules to be unloaded. Put the reference when the engine gets
retired.

A static list of hardware (only) ECC engines is setup to keep track of
the registered engines.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/core.c  | 10 +++--
 drivers/mtd/nand/ecc.c   | 88 ++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/nand.h | 28 +++++++++++++
 3 files changed, 123 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/core.c b/drivers/mtd/nand/core.c
index df9646685c91..5628bd410f7e 100644
--- a/drivers/mtd/nand/core.c
+++ b/drivers/mtd/nand/core.c
@@ -232,7 +232,9 @@ static int nanddev_get_ecc_engine(struct nand_device *nand)
 		nand->ecc.engine = nand_ecc_get_on_die_hw_engine(nand);
 		break;
 	case NAND_ECC_ENGINE_TYPE_ON_HOST:
-		pr_err("On-host hardware ECC engines not supported yet\n");
+		nand->ecc.engine = nand_ecc_get_on_host_hw_engine(nand);
+		if (PTR_ERR(nand->ecc.engine) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
 		break;
 	default:
 		pr_err("Missing ECC engine type\n");
@@ -252,7 +254,7 @@ static int nanddev_put_ecc_engine(struct nand_device *nand)
 {
 	switch (nand->ecc.ctx.conf.engine_type) {
 	case NAND_ECC_ENGINE_TYPE_ON_HOST:
-		pr_err("On-host hardware ECC engines not supported yet\n");
+		nand_ecc_put_on_host_hw_engine(nand);
 		break;
 	case NAND_ECC_ENGINE_TYPE_NONE:
 	case NAND_ECC_ENGINE_TYPE_SOFT:
@@ -297,7 +299,9 @@ int nanddev_ecc_engine_init(struct nand_device *nand)
 	/* Look for the ECC engine to use */
 	ret = nanddev_get_ecc_engine(nand);
 	if (ret) {
-		pr_err("No ECC engine found\n");
+		if (ret != -EPROBE_DEFER)
+			pr_err("No ECC engine found\n");
+
 		return ret;
 	}
 
diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
index 6c43dfda01d4..078f5ec38de3 100644
--- a/drivers/mtd/nand/ecc.c
+++ b/drivers/mtd/nand/ecc.c
@@ -96,6 +96,12 @@
 #include <linux/module.h>
 #include <linux/mtd/nand.h>
 #include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+
+static LIST_HEAD(on_host_hw_engines);
+static DEFINE_MUTEX(on_host_hw_engines_mutex);
 
 /**
  * nand_ecc_init_ctx - Init the ECC engine context
@@ -611,6 +617,88 @@ struct nand_ecc_engine *nand_ecc_get_on_die_hw_engine(struct nand_device *nand)
 }
 EXPORT_SYMBOL(nand_ecc_get_on_die_hw_engine);
 
+int nand_ecc_register_on_host_hw_engine(struct nand_ecc_engine *engine)
+{
+	struct nand_ecc_engine *item;
+
+	if (!engine)
+		return -EINVAL;
+
+	/* Prevent multiple registrations of one engine */
+	list_for_each_entry(item, &on_host_hw_engines, node)
+		if (item == engine)
+			return 0;
+
+	mutex_lock(&on_host_hw_engines_mutex);
+	list_add_tail(&engine->node, &on_host_hw_engines);
+	mutex_unlock(&on_host_hw_engines_mutex);
+
+	return 0;
+}
+EXPORT_SYMBOL(nand_ecc_register_on_host_hw_engine);
+
+int nand_ecc_unregister_on_host_hw_engine(struct nand_ecc_engine *engine)
+{
+	if (!engine)
+		return -EINVAL;
+
+	mutex_lock(&on_host_hw_engines_mutex);
+	list_del(&engine->node);
+	mutex_unlock(&on_host_hw_engines_mutex);
+
+	return 0;
+}
+EXPORT_SYMBOL(nand_ecc_unregister_on_host_hw_engine);
+
+static struct nand_ecc_engine *nand_ecc_match_on_host_hw_engine(struct device *dev)
+{
+	struct nand_ecc_engine *item;
+
+	list_for_each_entry(item, &on_host_hw_engines, node)
+		if (item->dev == dev)
+			return item;
+
+	return NULL;
+}
+
+struct nand_ecc_engine *nand_ecc_get_on_host_hw_engine(struct nand_device *nand)
+{
+	struct nand_ecc_engine *engine = NULL;
+	struct device *dev = &nand->mtd.dev;
+	struct platform_device *pdev;
+	struct device_node *np;
+
+	if (list_empty(&on_host_hw_engines))
+		return NULL;
+
+	/* Check for an explicit nand-ecc-engine property */
+	np = of_parse_phandle(dev->of_node, "nand-ecc-engine", 0);
+	if (np) {
+		pdev = of_find_device_by_node(np);
+		if (!pdev)
+			return ERR_PTR(-EPROBE_DEFER);
+
+		engine = nand_ecc_match_on_host_hw_engine(&pdev->dev);
+		platform_device_put(pdev);
+		of_node_put(np);
+
+		if (!engine)
+			return ERR_PTR(-EPROBE_DEFER);
+	}
+
+	if (engine)
+		get_device(engine->dev);
+
+	return engine;
+}
+EXPORT_SYMBOL(nand_ecc_get_on_host_hw_engine);
+
+void nand_ecc_put_on_host_hw_engine(struct nand_device *nand)
+{
+	put_device(nand->ecc.engine->dev);
+}
+EXPORT_SYMBOL(nand_ecc_put_on_host_hw_engine);
+
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
 MODULE_DESCRIPTION("Generic ECC engine");
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 32fc7edf65b3..4ddd20fe9c9e 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -263,12 +263,36 @@ struct nand_ecc_engine_ops {
 			     struct nand_page_io_req *req);
 };
 
+/**
+ * enum nand_ecc_engine_integration - How the NAND ECC engine is integrated
+ * @NAND_ECC_ENGINE_INTEGRATION_INVALID: Invalid value
+ * @NAND_ECC_ENGINE_INTEGRATION_PIPELINED: Pipelined engine, performs on-the-fly
+ *                                         correction, does not need to copy
+ *                                         data around
+ * @NAND_ECC_ENGINE_INTEGRATION_EXTERNAL: External engine, needs to bring the
+ *                                        data into its own area before use
+ */
+enum nand_ecc_engine_integration {
+	NAND_ECC_ENGINE_INTEGRATION_INVALID,
+	NAND_ECC_ENGINE_INTEGRATION_PIPELINED,
+	NAND_ECC_ENGINE_INTEGRATION_EXTERNAL,
+};
+
 /**
  * struct nand_ecc_engine - ECC engine abstraction for NAND devices
+ * @dev: Host device
+ * @node: Private field for registration time
  * @ops: ECC engine operations
+ * @integration: How the engine is integrated with the host
+ *               (only relevant on %NAND_ECC_ENGINE_TYPE_ON_HOST engines)
+ * @priv: Private data
  */
 struct nand_ecc_engine {
+	struct device *dev;
+	struct list_head node;
 	struct nand_ecc_engine_ops *ops;
+	enum nand_ecc_engine_integration integration;
+	void *priv;
 };
 
 void of_get_nand_ecc_user_config(struct nand_device *nand);
@@ -279,8 +303,12 @@ int nand_ecc_prepare_io_req(struct nand_device *nand,
 int nand_ecc_finish_io_req(struct nand_device *nand,
 			   struct nand_page_io_req *req);
 bool nand_ecc_is_strong_enough(struct nand_device *nand);
+int nand_ecc_register_on_host_hw_engine(struct nand_ecc_engine *engine);
+int nand_ecc_unregister_on_host_hw_engine(struct nand_ecc_engine *engine);
 struct nand_ecc_engine *nand_ecc_get_sw_engine(struct nand_device *nand);
 struct nand_ecc_engine *nand_ecc_get_on_die_hw_engine(struct nand_device *nand);
+struct nand_ecc_engine *nand_ecc_get_on_host_hw_engine(struct nand_device *nand);
+void nand_ecc_put_on_host_hw_engine(struct nand_device *nand);
 
 #if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING)
 struct nand_ecc_engine *nand_ecc_sw_hamming_get_engine(void);
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 12/28] mtd: nand: ecc: Add infrastructure to support hardware engines
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Add the necessary helpers to register/unregister hardware ECC engines
that will be called from ECC engine drivers.

Also add helpers to get the right engine from the user
perspective. Keep a reference of the in use ECC engine in order to
prevent modules to be unloaded. Put the reference when the engine gets
retired.

A static list of hardware (only) ECC engines is setup to keep track of
the registered engines.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/core.c  | 10 +++--
 drivers/mtd/nand/ecc.c   | 88 ++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/nand.h | 28 +++++++++++++
 3 files changed, 123 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/core.c b/drivers/mtd/nand/core.c
index df9646685c91..5628bd410f7e 100644
--- a/drivers/mtd/nand/core.c
+++ b/drivers/mtd/nand/core.c
@@ -232,7 +232,9 @@ static int nanddev_get_ecc_engine(struct nand_device *nand)
 		nand->ecc.engine = nand_ecc_get_on_die_hw_engine(nand);
 		break;
 	case NAND_ECC_ENGINE_TYPE_ON_HOST:
-		pr_err("On-host hardware ECC engines not supported yet\n");
+		nand->ecc.engine = nand_ecc_get_on_host_hw_engine(nand);
+		if (PTR_ERR(nand->ecc.engine) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
 		break;
 	default:
 		pr_err("Missing ECC engine type\n");
@@ -252,7 +254,7 @@ static int nanddev_put_ecc_engine(struct nand_device *nand)
 {
 	switch (nand->ecc.ctx.conf.engine_type) {
 	case NAND_ECC_ENGINE_TYPE_ON_HOST:
-		pr_err("On-host hardware ECC engines not supported yet\n");
+		nand_ecc_put_on_host_hw_engine(nand);
 		break;
 	case NAND_ECC_ENGINE_TYPE_NONE:
 	case NAND_ECC_ENGINE_TYPE_SOFT:
@@ -297,7 +299,9 @@ int nanddev_ecc_engine_init(struct nand_device *nand)
 	/* Look for the ECC engine to use */
 	ret = nanddev_get_ecc_engine(nand);
 	if (ret) {
-		pr_err("No ECC engine found\n");
+		if (ret != -EPROBE_DEFER)
+			pr_err("No ECC engine found\n");
+
 		return ret;
 	}
 
diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
index 6c43dfda01d4..078f5ec38de3 100644
--- a/drivers/mtd/nand/ecc.c
+++ b/drivers/mtd/nand/ecc.c
@@ -96,6 +96,12 @@
 #include <linux/module.h>
 #include <linux/mtd/nand.h>
 #include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+
+static LIST_HEAD(on_host_hw_engines);
+static DEFINE_MUTEX(on_host_hw_engines_mutex);
 
 /**
  * nand_ecc_init_ctx - Init the ECC engine context
@@ -611,6 +617,88 @@ struct nand_ecc_engine *nand_ecc_get_on_die_hw_engine(struct nand_device *nand)
 }
 EXPORT_SYMBOL(nand_ecc_get_on_die_hw_engine);
 
+int nand_ecc_register_on_host_hw_engine(struct nand_ecc_engine *engine)
+{
+	struct nand_ecc_engine *item;
+
+	if (!engine)
+		return -EINVAL;
+
+	/* Prevent multiple registrations of one engine */
+	list_for_each_entry(item, &on_host_hw_engines, node)
+		if (item == engine)
+			return 0;
+
+	mutex_lock(&on_host_hw_engines_mutex);
+	list_add_tail(&engine->node, &on_host_hw_engines);
+	mutex_unlock(&on_host_hw_engines_mutex);
+
+	return 0;
+}
+EXPORT_SYMBOL(nand_ecc_register_on_host_hw_engine);
+
+int nand_ecc_unregister_on_host_hw_engine(struct nand_ecc_engine *engine)
+{
+	if (!engine)
+		return -EINVAL;
+
+	mutex_lock(&on_host_hw_engines_mutex);
+	list_del(&engine->node);
+	mutex_unlock(&on_host_hw_engines_mutex);
+
+	return 0;
+}
+EXPORT_SYMBOL(nand_ecc_unregister_on_host_hw_engine);
+
+static struct nand_ecc_engine *nand_ecc_match_on_host_hw_engine(struct device *dev)
+{
+	struct nand_ecc_engine *item;
+
+	list_for_each_entry(item, &on_host_hw_engines, node)
+		if (item->dev == dev)
+			return item;
+
+	return NULL;
+}
+
+struct nand_ecc_engine *nand_ecc_get_on_host_hw_engine(struct nand_device *nand)
+{
+	struct nand_ecc_engine *engine = NULL;
+	struct device *dev = &nand->mtd.dev;
+	struct platform_device *pdev;
+	struct device_node *np;
+
+	if (list_empty(&on_host_hw_engines))
+		return NULL;
+
+	/* Check for an explicit nand-ecc-engine property */
+	np = of_parse_phandle(dev->of_node, "nand-ecc-engine", 0);
+	if (np) {
+		pdev = of_find_device_by_node(np);
+		if (!pdev)
+			return ERR_PTR(-EPROBE_DEFER);
+
+		engine = nand_ecc_match_on_host_hw_engine(&pdev->dev);
+		platform_device_put(pdev);
+		of_node_put(np);
+
+		if (!engine)
+			return ERR_PTR(-EPROBE_DEFER);
+	}
+
+	if (engine)
+		get_device(engine->dev);
+
+	return engine;
+}
+EXPORT_SYMBOL(nand_ecc_get_on_host_hw_engine);
+
+void nand_ecc_put_on_host_hw_engine(struct nand_device *nand)
+{
+	put_device(nand->ecc.engine->dev);
+}
+EXPORT_SYMBOL(nand_ecc_put_on_host_hw_engine);
+
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
 MODULE_DESCRIPTION("Generic ECC engine");
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 32fc7edf65b3..4ddd20fe9c9e 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -263,12 +263,36 @@ struct nand_ecc_engine_ops {
 			     struct nand_page_io_req *req);
 };
 
+/**
+ * enum nand_ecc_engine_integration - How the NAND ECC engine is integrated
+ * @NAND_ECC_ENGINE_INTEGRATION_INVALID: Invalid value
+ * @NAND_ECC_ENGINE_INTEGRATION_PIPELINED: Pipelined engine, performs on-the-fly
+ *                                         correction, does not need to copy
+ *                                         data around
+ * @NAND_ECC_ENGINE_INTEGRATION_EXTERNAL: External engine, needs to bring the
+ *                                        data into its own area before use
+ */
+enum nand_ecc_engine_integration {
+	NAND_ECC_ENGINE_INTEGRATION_INVALID,
+	NAND_ECC_ENGINE_INTEGRATION_PIPELINED,
+	NAND_ECC_ENGINE_INTEGRATION_EXTERNAL,
+};
+
 /**
  * struct nand_ecc_engine - ECC engine abstraction for NAND devices
+ * @dev: Host device
+ * @node: Private field for registration time
  * @ops: ECC engine operations
+ * @integration: How the engine is integrated with the host
+ *               (only relevant on %NAND_ECC_ENGINE_TYPE_ON_HOST engines)
+ * @priv: Private data
  */
 struct nand_ecc_engine {
+	struct device *dev;
+	struct list_head node;
 	struct nand_ecc_engine_ops *ops;
+	enum nand_ecc_engine_integration integration;
+	void *priv;
 };
 
 void of_get_nand_ecc_user_config(struct nand_device *nand);
@@ -279,8 +303,12 @@ int nand_ecc_prepare_io_req(struct nand_device *nand,
 int nand_ecc_finish_io_req(struct nand_device *nand,
 			   struct nand_page_io_req *req);
 bool nand_ecc_is_strong_enough(struct nand_device *nand);
+int nand_ecc_register_on_host_hw_engine(struct nand_ecc_engine *engine);
+int nand_ecc_unregister_on_host_hw_engine(struct nand_ecc_engine *engine);
 struct nand_ecc_engine *nand_ecc_get_sw_engine(struct nand_device *nand);
 struct nand_ecc_engine *nand_ecc_get_on_die_hw_engine(struct nand_device *nand);
+struct nand_ecc_engine *nand_ecc_get_on_host_hw_engine(struct nand_device *nand);
+void nand_ecc_put_on_host_hw_engine(struct nand_device *nand);
 
 #if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING)
 struct nand_ecc_engine *nand_ecc_sw_hamming_get_engine(void);
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 13/28] mtd: nand: Add a new helper to retrieve the ECC context
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Introduce nand_to_ecc_ctx() which will allow to easily jump to the
private pointer of an ECC context given a NAND device. This is very
handy, from the prepare or finish ECC hook, to get the internal context
out of the NAND device object.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/linux/mtd/nand.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 4ddd20fe9c9e..b617efa0a881 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -990,6 +990,11 @@ int nanddev_markbad(struct nand_device *nand, const struct nand_pos *pos);
 int nanddev_ecc_engine_init(struct nand_device *nand);
 void nanddev_ecc_engine_cleanup(struct nand_device *nand);
 
+static inline void *nand_to_ecc_ctx(struct nand_device *nand)
+{
+	return nand->ecc.ctx.priv;
+}
+
 /* BBT related functions */
 enum nand_bbt_block_status {
 	NAND_BBT_BLOCK_STATUS_UNKNOWN,
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 13/28] mtd: nand: Add a new helper to retrieve the ECC context
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Introduce nand_to_ecc_ctx() which will allow to easily jump to the
private pointer of an ECC context given a NAND device. This is very
handy, from the prepare or finish ECC hook, to get the internal context
out of the NAND device object.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/linux/mtd/nand.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 4ddd20fe9c9e..b617efa0a881 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -990,6 +990,11 @@ int nanddev_markbad(struct nand_device *nand, const struct nand_pos *pos);
 int nanddev_ecc_engine_init(struct nand_device *nand);
 void nanddev_ecc_engine_cleanup(struct nand_device *nand);
 
+static inline void *nand_to_ecc_ctx(struct nand_device *nand)
+{
+	return nand->ecc.ctx.priv;
+}
+
 /* BBT related functions */
 enum nand_bbt_block_status {
 	NAND_BBT_BLOCK_STATUS_UNKNOWN,
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 14/28] mtd: nand: mxic-ecc: Add Macronix external ECC engine support
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Some SPI-NAND chips do not support on-die ECC. For these chips,
correction must apply on the SPI controller end. In order to avoid
doing all the calculations by software, Macronix provides a specific
engine that can offload the intensive work.

Add Macronix ECC engine support, this engine can work in conjunction
with a SPI controller and a raw NAND controller, it can be pipelined
or external and supports linear and syndrome layouts.

Right now the simplest configuration is supported: SPI controller
external and linear ECC engine.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/Kconfig    |   6 +
 drivers/mtd/nand/Makefile   |   1 +
 drivers/mtd/nand/ecc-mxic.c | 692 ++++++++++++++++++++++++++++++++++++
 3 files changed, 699 insertions(+)
 create mode 100644 drivers/mtd/nand/ecc-mxic.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index b40455234cbd..8431292ff49d 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -46,6 +46,12 @@ config MTD_NAND_ECC_SW_BCH
 	  ECC codes. They are used with NAND devices requiring more than 1 bit
 	  of error correction.
 
+config MTD_NAND_ECC_MXIC
+	bool "Macronix external hardware ECC engine"
+	select MTD_NAND_ECC
+	help
+	  This enables support for the hardware ECC engine from Macronix.
+
 endmenu
 
 endmenu
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1c0b46960eb1..a4e6b7ae0614 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -10,3 +10,4 @@ obj-y	+= spi/
 nandcore-$(CONFIG_MTD_NAND_ECC) += ecc.o
 nandcore-$(CONFIG_MTD_NAND_ECC_SW_HAMMING) += ecc-sw-hamming.o
 nandcore-$(CONFIG_MTD_NAND_ECC_SW_BCH) += ecc-sw-bch.o
+nandcore-$(CONFIG_MTD_NAND_ECC_MXIC) += ecc-mxic.o
diff --git a/drivers/mtd/nand/ecc-mxic.c b/drivers/mtd/nand/ecc-mxic.c
new file mode 100644
index 000000000000..ea88a411ed70
--- /dev/null
+++ b/drivers/mtd/nand/ecc-mxic.c
@@ -0,0 +1,692 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Support for Macronix external hardware ECC engine for NAND devices, also
+ * called DPE for Data Processing Engine.
+ *
+ * Copyright © 2019 Macronix
+ * Author: Miquel Raynal <miquel.raynal@bootlin.com>
+ */
+
+#include <linux/dma-mapping.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mutex.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+/* DPE Configuration */
+#define DP_CONFIG 0x00
+#define   ECC_EN BIT(0)
+#define   ECC_TYP(idx) (((idx) << 3) & GENMASK(6, 3))
+/* DPE Interrupt Status */
+#define INTRPT_STS 0x04
+#define   TRANS_CMPLT BIT(0)
+#define   SDMA_MAIN BIT(1)
+#define   SDMA_SPARE BIT(2)
+#define   ECC_ERR BIT(3)
+#define   TO_SPARE BIT(4)
+#define   TO_MAIN BIT(5)
+/* DPE Interrupt Status Enable */
+#define INTRPT_STS_EN 0x08
+/* DPE Interrupt Signal Enable */
+#define INTRPT_SIG_EN 0x0C
+/* Host Controller Configuration */
+#define HC_CONFIG 0x10
+#define   MEM2MEM BIT(4) /* TRANS_TYP_IO in the spec */
+#define   ECC_PACKED 0 /* LAYOUT_TYP_INTEGRATED in the spec */
+#define   ECC_INTERLEAVED BIT(2) /* LAYOUT_TYP_DISTRIBUTED in the spec */
+#define   BURST_TYP_FIXED 0
+#define   BURST_TYP_INCREASING BIT(0)
+/* Host Controller Slave Address */
+#define HC_SLV_ADDR 0x14
+/* ECC Chunk Size */
+#define CHUNK_SIZE 0x20
+/* Main Data Size */
+#define MAIN_SIZE 0x24
+/* Spare Data Size */
+#define SPARE_SIZE 0x28
+#define   META_SZ(reg) ((reg) & GENMASK(7, 0))
+#define   PARITY_SZ(reg) (((reg) & GENMASK(15, 8)) >> 8)
+#define   RSV_SZ(reg) (((reg) & GENMASK(23, 16)) >> 16)
+#define   SPARE_SZ(reg) ((reg) >> 24)
+/* ECC Chunk Count */
+#define CHUNK_CNT 0x30
+/* SDMA Control */
+#define SDMA_CTRL 0x40
+#define   WRITE_NAND 0
+#define   READ_NAND BIT(1)
+#define   CONT_NAND BIT(29)
+#define   CONT_SYSM BIT(30) /* Continue System Memory? */
+#define   SDMA_STRT BIT(31)
+/* SDMA Address of Main Data */
+#define SDMA_MAIN_ADDR 0x44
+/* SDMA Address of Spare Data */
+#define SDMA_SPARE_ADDR 0x48
+/* DPE Version Number */
+#define DP_VER 0xD0
+#define   DP_VER_OFFSET 16
+
+/* Status bytes between each chunk of spare data */
+#define STAT_BYTES 4
+#define   NO_ERR 0x00
+#define   MAX_CORR_ERR 0x28
+#define   UNCORR_ERR 0xFE
+#define   ERASED_CHUNK 0xFF
+
+struct mxic_ecc_engine {
+	struct device *dev;
+	void __iomem *regs;
+	int irq;
+	struct completion complete;
+	struct nand_ecc_engine external_engine;
+	struct mutex lock;
+};
+
+struct mxic_ecc_ctx {
+	/* ECC machinery */
+	unsigned int data_step_sz;
+	unsigned int oob_step_sz;
+	unsigned int parity_sz;
+	unsigned int meta_sz;
+	u8 *status;
+	int steps;
+
+	/* DMA boilerplate */
+	struct nand_ecc_req_tweak_ctx req_ctx;
+	u8 *oobwithstat;
+	struct scatterlist sg[2];
+	struct nand_page_io_req *req;
+};
+
+static struct mxic_ecc_engine *ext_ecc_eng_to_mxic(struct nand_ecc_engine *eng)
+{
+	return container_of(eng, struct mxic_ecc_engine, external_engine);
+}
+
+static struct mxic_ecc_engine *nand_to_mxic(struct nand_device *nand)
+{
+	struct nand_ecc_engine *eng = nand->ecc.engine;
+
+	return ext_ecc_eng_to_mxic(eng);
+}
+
+static int mxic_ecc_ooblayout_ecc(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_device *nand = mtd_to_nanddev(mtd);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+
+	if (section < 0 || section >= ctx->steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * ctx->oob_step_sz) + ctx->meta_sz;
+	oobregion->length = ctx->parity_sz;
+
+	return 0;
+}
+
+static int mxic_ecc_ooblayout_free(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	struct nand_device *nand = mtd_to_nanddev(mtd);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+
+	if (section < 0 || section >= ctx->steps)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 2;
+		oobregion->length = ctx->meta_sz - 2;
+	} else {
+		oobregion->offset = section * ctx->oob_step_sz;
+		oobregion->length = ctx->meta_sz;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops mxic_ecc_ooblayout_ops = {
+	.ecc = mxic_ecc_ooblayout_ecc,
+	.free = mxic_ecc_ooblayout_free,
+};
+
+static void mxic_ecc_disable_engine(struct mxic_ecc_engine *mxic)
+{
+	u32 reg;
+
+	reg = readl(mxic->regs + DP_CONFIG);
+	reg &= ~ECC_EN;
+	writel(reg, mxic->regs + DP_CONFIG);
+}
+
+static void mxic_ecc_enable_engine(struct mxic_ecc_engine *mxic)
+{
+	u32 reg;
+
+	reg = readl(mxic->regs + DP_CONFIG);
+	reg |= ECC_EN;
+	writel(reg, mxic->regs + DP_CONFIG);
+}
+
+static void mxic_ecc_disable_int(struct mxic_ecc_engine *mxic)
+{
+	writel(0, mxic->regs + INTRPT_SIG_EN);
+}
+
+static void mxic_ecc_enable_int(struct mxic_ecc_engine *mxic)
+{
+	writel(TRANS_CMPLT, mxic->regs + INTRPT_SIG_EN);
+}
+
+static irqreturn_t mxic_ecc_isr(int irq, void *dev_id)
+{
+	struct mxic_ecc_engine *mxic = dev_id;
+	u32 sts;
+
+	sts = readl(mxic->regs + INTRPT_STS);
+	if (!sts)
+		return IRQ_NONE;
+
+	if (sts & TRANS_CMPLT)
+		complete(&mxic->complete);
+
+	writel(sts, mxic->regs + INTRPT_STS);
+
+	return IRQ_HANDLED;
+}
+
+static int mxic_ecc_init_ctx(struct nand_device *nand, struct device *dev)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct nand_ecc_props *conf = &nand->ecc.ctx.conf;
+	struct nand_ecc_props *reqs = &nand->ecc.requirements;
+	struct nand_ecc_props *user = &nand->ecc.user_conf;
+	struct mtd_info *mtd = nanddev_to_mtd(nand);
+	int step_size = 0, strength = 0, desired_correction = 0, steps, idx;
+	int possible_strength[] = {4, 8, 40, 48};
+	int spare_size[] = {32, 32, 96, 96};
+	struct mxic_ecc_ctx *ctx;
+	u32 spare_reg;
+	int ret;
+
+	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	nand->ecc.ctx.priv = ctx;
+
+	/* Only large page NAND chips may use BCH */
+	if (mtd->oobsize < 64) {
+		pr_err("BCH cannot be used with small page NAND chips\n");
+		return -EINVAL;
+	}
+
+	mtd_set_ooblayout(mtd, &mxic_ecc_ooblayout_ops);
+
+	/* Enable all status bits */
+	writel(TRANS_CMPLT | SDMA_MAIN | SDMA_SPARE | ECC_ERR |
+	       TO_SPARE | TO_MAIN, mxic->regs + INTRPT_STS_EN);
+
+	/* Configure the correction depending on the NAND device topology */
+	if (user->step_size && user->strength) {
+		step_size = user->step_size;
+		strength = user->strength;
+	} else if (reqs->step_size && reqs->strength) {
+		step_size = reqs->step_size;
+		strength = reqs->strength;
+	}
+
+	if (step_size && strength) {
+		steps = mtd->writesize / step_size;
+		desired_correction = steps * strength;
+	}
+
+	/* Step size is fixed to 1kiB, strength may vary (4 possible values) */
+	conf->step_size = SZ_1K;
+	steps = mtd->writesize / conf->step_size;
+
+	ctx->status = devm_kzalloc(dev, steps * sizeof(u8), GFP_KERNEL);
+	if (!ctx->status)
+		return -ENOMEM;
+
+	if (desired_correction) {
+		strength = desired_correction / steps;
+
+		for (idx = 0; idx < ARRAY_SIZE(possible_strength); idx++)
+			if (possible_strength[idx] >= strength)
+				break;
+
+		idx = min_t(unsigned int, idx,
+			    ARRAY_SIZE(possible_strength) - 1);
+	} else {
+		/* Missing data, maximize the correction */
+		idx = ARRAY_SIZE(possible_strength) - 1;
+	}
+
+	/* Tune the selected strength until it fits in the OOB area */
+	for (; idx >= 0; idx--) {
+		if (spare_size[idx] * steps <= mtd->oobsize)
+			break;
+	}
+
+	/* This engine cannot be used with this NAND device */
+	if (idx < 0)
+		return -EINVAL;
+
+	/* Configure the engine for the desired strength */
+	writel(ECC_TYP(idx), mxic->regs + DP_CONFIG);
+	conf->strength = possible_strength[idx];
+	spare_reg = readl(mxic->regs + SPARE_SIZE);
+
+	ctx->steps = steps;
+	ctx->data_step_sz = mtd->writesize / steps;
+	ctx->oob_step_sz = mtd->oobsize / steps;
+	ctx->parity_sz = PARITY_SZ(spare_reg);
+	ctx->meta_sz = META_SZ(spare_reg);
+
+	/* Ensure buffers will contain enough bytes to store the STAT_BYTES */
+	ctx->req_ctx.oob_buffer_size = nanddev_per_page_oobsize(nand) +
+					(ctx->steps * STAT_BYTES);
+	ret = nand_ecc_init_req_tweaking(&ctx->req_ctx, nand);
+	if (ret)
+		return ret;
+
+	ctx->oobwithstat = kmalloc(mtd->oobsize + (ctx->steps * STAT_BYTES),
+				   GFP_KERNEL);
+	if (!ctx->oobwithstat) {
+		ret = -ENOMEM;
+		goto cleanup_req_tweak;
+	}
+
+	sg_init_table(ctx->sg, 2);
+
+	/* Configuration dump and sanity checks */
+	dev_err(dev, "DPE version number: %d\n",
+		readl(mxic->regs + DP_VER) >> DP_VER_OFFSET);
+	dev_err(dev, "Chunk size: %d\n", readl(mxic->regs + CHUNK_SIZE));
+	dev_err(dev, "Main size: %d\n", readl(mxic->regs + MAIN_SIZE));
+	dev_err(dev, "Spare size: %d\n", SPARE_SZ(spare_reg));
+	dev_err(dev, "Rsv size: %ld\n", RSV_SZ(spare_reg));
+	dev_err(dev, "Parity size: %d\n", ctx->parity_sz);
+	dev_err(dev, "Meta size: %d\n", ctx->meta_sz);
+
+	if ((ctx->meta_sz + ctx->parity_sz + RSV_SZ(spare_reg)) !=
+	    SPARE_SZ(spare_reg)) {
+		dev_err(dev, "Wrong OOB configuration: %d + %d + %ld != %d\n",
+			ctx->meta_sz, ctx->parity_sz, RSV_SZ(spare_reg),
+			SPARE_SZ(spare_reg));
+		ret = -EINVAL;
+		goto free_oobwithstat;
+	}
+
+	if (ctx->oob_step_sz != SPARE_SZ(spare_reg)) {
+		dev_err(dev, "Wrong OOB configuration: %d != %d\n",
+			ctx->oob_step_sz, SPARE_SZ(spare_reg));
+		ret = -EINVAL;
+		goto free_oobwithstat;
+	}
+
+	return 0;
+
+free_oobwithstat:
+	kfree(ctx->oobwithstat);
+cleanup_req_tweak:
+	nand_ecc_cleanup_req_tweaking(&ctx->req_ctx);
+
+	return ret;
+}
+
+static int mxic_ecc_init_ctx_external(struct nand_device *nand)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct device *dev = nand->ecc.engine->dev;
+	int ret;
+
+	dev_info(dev, "Macronix ECC engine in external mode\n");
+
+	ret = mxic_ecc_init_ctx(nand, dev);
+	if (ret)
+		return ret;
+
+	/* Trigger each step manually */
+	writel(1, mxic->regs + CHUNK_CNT);
+	writel(BURST_TYP_INCREASING | ECC_PACKED | MEM2MEM,
+	       mxic->regs + HC_CONFIG);
+
+	return 0;
+}
+
+static void mxic_ecc_cleanup_ctx(struct nand_device *nand)
+{
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+
+	if (ctx) {
+		nand_ecc_cleanup_req_tweaking(&ctx->req_ctx);
+		kfree(ctx->oobwithstat);
+	}
+}
+
+static int mxic_ecc_data_xfer_wait_for_completion(struct mxic_ecc_engine *mxic)
+{
+	u32 val;
+	int ret;
+
+	if (mxic->irq) {
+		reinit_completion(&mxic->complete);
+		mxic_ecc_enable_int(mxic);
+		ret = wait_for_completion_timeout(&mxic->complete,
+						  msecs_to_jiffies(1000));
+		mxic_ecc_disable_int(mxic);
+	} else {
+		ret = readl_poll_timeout(mxic->regs + INTRPT_STS, val,
+					 val & TRANS_CMPLT, 10, USEC_PER_SEC);
+		writel(val, mxic->regs + INTRPT_STS);
+	}
+
+	if (ret) {
+		dev_err(mxic->dev, "Timeout on data xfer completion (sts 0x%08x)\n", val);
+		return -ETIMEDOUT;
+	}
+
+	return 0;
+}
+
+static int mxic_ecc_process_data(struct mxic_ecc_engine *mxic,
+				 unsigned int direction)
+{
+	unsigned int dir = (direction == NAND_PAGE_READ) ?
+			   READ_NAND : WRITE_NAND;
+	int ret;
+
+	mxic_ecc_enable_engine(mxic);
+
+	/* Trigger processing */
+	writel(SDMA_STRT | dir, mxic->regs + SDMA_CTRL);
+
+	/* Wait for completion */
+	ret = mxic_ecc_data_xfer_wait_for_completion(mxic);
+
+	mxic_ecc_disable_engine(mxic);
+
+	return ret;
+}
+
+static void mxic_ecc_extract_status_bytes(struct mxic_ecc_ctx *ctx)
+{
+	u8 *buf = ctx->oobwithstat;
+	int next_stat_pos;
+	int step;
+
+	/* Extract the ECC status */
+	for (step = 0; step < ctx->steps; step++) {
+		next_stat_pos = ctx->oob_step_sz +
+				((STAT_BYTES + ctx->oob_step_sz) * step);
+
+		ctx->status[step] = buf[next_stat_pos];
+	}
+}
+
+static void mxic_ecc_reconstruct_oobbuf(struct mxic_ecc_ctx *ctx,
+					u8 *dst, const u8 *src)
+{
+	int step;
+
+	/* Reconstruct the OOB buffer linearly (without the ECC status bytes) */
+	for (step = 0; step < ctx->steps; step++)
+		memcpy(dst + (step * ctx->oob_step_sz),
+		       src + (step * (ctx->oob_step_sz + STAT_BYTES)),
+		       ctx->oob_step_sz);
+}
+
+static void mxic_ecc_add_room_in_oobbuf(struct mxic_ecc_ctx *ctx,
+					u8 *dst, const u8 *src)
+{
+	int step;
+
+	/* Add some space in the OOB buffer for the status bytes */
+	for (step = 0; step < ctx->steps; step++)
+		memcpy(dst + (step * (ctx->oob_step_sz + STAT_BYTES)),
+		       src + (step * ctx->oob_step_sz),
+		       ctx->oob_step_sz);
+}
+
+static int mxic_ecc_count_biterrs(struct mxic_ecc_engine *mxic,
+				  struct nand_device *nand)
+{
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+	struct mtd_info *mtd = nanddev_to_mtd(nand);
+	struct device *dev = mxic->dev;
+	unsigned int max_bf = 0;
+	bool failure = false;
+	int step;
+
+	for (step = 0; step < ctx->steps; step++) {
+		u8 stat = ctx->status[step];
+
+		if (stat == NO_ERR) {
+			dev_dbg(dev, "ECC step %d: no error\n", step);
+		} else if (stat == ERASED_CHUNK) {
+			dev_dbg(dev, "ECC step %d: erased\n", step);
+		} else if (stat == UNCORR_ERR || stat > MAX_CORR_ERR) {
+			dev_dbg(dev, "ECC step %d: uncorrectable\n", step);
+			mtd->ecc_stats.failed++;
+			failure = true;
+		} else {
+			dev_dbg(dev, "ECC step %d: %d bits corrected\n",
+				step, stat);
+			max_bf = max_t(unsigned int, max_bf, stat);
+			mtd->ecc_stats.corrected += stat;
+		}
+	}
+
+	return failure ? -EBADMSG : max_bf;
+}
+
+/* External ECC engine helpers */
+static int mxic_ecc_prepare_io_req_external(struct nand_device *nand,
+					    struct nand_page_io_req *req)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+	struct mtd_info *mtd = nanddev_to_mtd(nand);
+	int offset, nents, step, ret;
+
+	if (req->mode == MTD_OPS_RAW)
+		return 0;
+
+	nand_ecc_tweak_req(&ctx->req_ctx, req);
+	ctx->req = req;
+
+	if (req->type == NAND_PAGE_READ)
+		return 0;
+
+	mxic_ecc_add_room_in_oobbuf(ctx, ctx->oobwithstat,
+				    ctx->req->oobbuf.out);
+
+	sg_set_buf(&ctx->sg[0], req->databuf.out, req->datalen);
+	sg_set_buf(&ctx->sg[1], ctx->oobwithstat,
+		   req->ooblen + (ctx->steps * STAT_BYTES));
+
+	nents = dma_map_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+	if (!nents)
+		return -EINVAL;
+
+	mutex_lock(&mxic->lock);
+
+	for (step = 0; step < ctx->steps; step++) {
+		writel(sg_dma_address(&ctx->sg[0]) + (step * ctx->data_step_sz),
+		       mxic->regs + SDMA_MAIN_ADDR);
+		writel(sg_dma_address(&ctx->sg[1]) + (step * (ctx->oob_step_sz + STAT_BYTES)),
+		       mxic->regs + SDMA_SPARE_ADDR);
+		ret = mxic_ecc_process_data(mxic, ctx->req->type);
+		if (ret)
+			break;
+	}
+
+	mutex_unlock(&mxic->lock);
+
+	dma_unmap_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+
+	/* Retrieve the calculated ECC bytes */
+	for (step = 0; step < ctx->steps; step++) {
+		offset = ctx->meta_sz + (step * ctx->oob_step_sz);
+		mtd_ooblayout_get_eccbytes(mtd,
+					   (u8 *)ctx->req->oobbuf.out + offset,
+					   ctx->oobwithstat + (step * STAT_BYTES),
+					   step * ctx->parity_sz,
+					   ctx->parity_sz);
+	}
+
+	return ret;
+}
+
+static int mxic_ecc_finish_io_req_external(struct nand_device *nand,
+					   struct nand_page_io_req *req)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+	int nents, step, ret;
+
+	if (req->mode == MTD_OPS_RAW)
+		return 0;
+
+	if (req->type == NAND_PAGE_WRITE) {
+		nand_ecc_restore_req(&ctx->req_ctx, req);
+		return 0;
+	}
+
+	/* Copy the OOB buffer and add room for the ECC engine status bytes */
+	mxic_ecc_add_room_in_oobbuf(ctx, ctx->oobwithstat, ctx->req->oobbuf.in);
+
+	sg_set_buf(&ctx->sg[0], req->databuf.in, req->datalen);
+	sg_set_buf(&ctx->sg[1], ctx->oobwithstat,
+		   req->ooblen + (ctx->steps * STAT_BYTES));
+	nents = dma_map_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+	if (!nents)
+		return -EINVAL;
+
+	mutex_lock(&mxic->lock);
+
+	for (step = 0; step < ctx->steps; step++) {
+		writel(sg_dma_address(&ctx->sg[0]) + (step * ctx->data_step_sz),
+		       mxic->regs + SDMA_MAIN_ADDR);
+		writel(sg_dma_address(&ctx->sg[1]) + (step * (ctx->oob_step_sz + STAT_BYTES)),
+		       mxic->regs + SDMA_SPARE_ADDR);
+		ret = mxic_ecc_process_data(mxic, ctx->req->type);
+		if (ret)
+			break;
+	}
+
+	mutex_unlock(&mxic->lock);
+
+	dma_unmap_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+
+	/* Extract the status bytes and reconstruct the buffer */
+	mxic_ecc_extract_status_bytes(ctx);
+	mxic_ecc_reconstruct_oobbuf(ctx, ctx->req->oobbuf.in, ctx->oobwithstat);
+
+	nand_ecc_restore_req(&ctx->req_ctx, req);
+
+	return mxic_ecc_count_biterrs(mxic, nand);
+}
+
+static struct nand_ecc_engine_ops mxic_ecc_engine_external_ops = {
+	.init_ctx = mxic_ecc_init_ctx_external,
+	.cleanup_ctx = mxic_ecc_cleanup_ctx,
+	.prepare_io_req = mxic_ecc_prepare_io_req_external,
+	.finish_io_req = mxic_ecc_finish_io_req_external,
+};
+
+static int mxic_ecc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mxic_ecc_engine *mxic;
+	int ret;
+
+	mxic = devm_kzalloc(&pdev->dev, sizeof(*mxic), GFP_KERNEL);
+	if (!mxic)
+		return -ENOMEM;
+
+	mxic->dev = &pdev->dev;
+
+	/*
+	 * Both memory regions for the ECC engine itself and the AXI slave
+	 * address are mandatory.
+	 */
+	mxic->regs = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(mxic->regs)) {
+		dev_err(&pdev->dev, "Missing memory region\n");
+		return PTR_ERR(mxic->regs);
+	}
+
+	mxic_ecc_disable_engine(mxic);
+	mxic_ecc_disable_int(mxic);
+
+	/* IRQ is optional yet much more efficient */
+	mxic->irq = platform_get_irq_byname_optional(pdev, "ecc-engine");
+	if (mxic->irq > 0) {
+		ret = devm_request_irq(&pdev->dev, mxic->irq, mxic_ecc_isr, 0,
+				       "mxic-ecc", mxic);
+		if (ret)
+			return ret;
+	} else {
+		dev_info(dev, "Invalid or missing IRQ, fallback to polling\n");
+		mxic->irq = 0;
+	}
+
+	mutex_init(&mxic->lock);
+
+	/*
+	 * In external mode, the device is the ECC engine. In pipelined mode,
+	 * the device is the host controller. The device is used to match the
+	 * right ECC engine based on the DT properties.
+	 */
+	mxic->external_engine.dev = &pdev->dev;
+	mxic->external_engine.integration = NAND_ECC_ENGINE_INTEGRATION_EXTERNAL;
+	mxic->external_engine.ops = &mxic_ecc_engine_external_ops;
+
+	nand_ecc_register_on_host_hw_engine(&mxic->external_engine);
+
+	platform_set_drvdata(pdev, mxic);
+
+	return 0;
+}
+
+static int mxic_ecc_remove(struct platform_device *pdev)
+{
+	struct mxic_ecc_engine *mxic = platform_get_drvdata(pdev);
+
+	nand_ecc_unregister_on_host_hw_engine(&mxic->external_engine);
+
+	return 0;
+}
+
+static const struct of_device_id mxic_ecc_of_ids[] = {
+	{
+		.compatible = "mxicy,nand-ecc-engine-rev3",
+	},
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mxic_ecc_of_ids);
+
+static struct platform_driver mxic_ecc_driver = {
+	.driver	= {
+		.name = "mxic-nand-ecc-engine",
+		.of_match_table = mxic_ecc_of_ids,
+	},
+	.probe = mxic_ecc_probe,
+	.remove	= mxic_ecc_remove,
+};
+module_platform_driver(mxic_ecc_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
+MODULE_DESCRIPTION("Macronix NAND hardware ECC controller");
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 14/28] mtd: nand: mxic-ecc: Add Macronix external ECC engine support
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Some SPI-NAND chips do not support on-die ECC. For these chips,
correction must apply on the SPI controller end. In order to avoid
doing all the calculations by software, Macronix provides a specific
engine that can offload the intensive work.

Add Macronix ECC engine support, this engine can work in conjunction
with a SPI controller and a raw NAND controller, it can be pipelined
or external and supports linear and syndrome layouts.

Right now the simplest configuration is supported: SPI controller
external and linear ECC engine.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/Kconfig    |   6 +
 drivers/mtd/nand/Makefile   |   1 +
 drivers/mtd/nand/ecc-mxic.c | 692 ++++++++++++++++++++++++++++++++++++
 3 files changed, 699 insertions(+)
 create mode 100644 drivers/mtd/nand/ecc-mxic.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index b40455234cbd..8431292ff49d 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -46,6 +46,12 @@ config MTD_NAND_ECC_SW_BCH
 	  ECC codes. They are used with NAND devices requiring more than 1 bit
 	  of error correction.
 
+config MTD_NAND_ECC_MXIC
+	bool "Macronix external hardware ECC engine"
+	select MTD_NAND_ECC
+	help
+	  This enables support for the hardware ECC engine from Macronix.
+
 endmenu
 
 endmenu
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1c0b46960eb1..a4e6b7ae0614 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -10,3 +10,4 @@ obj-y	+= spi/
 nandcore-$(CONFIG_MTD_NAND_ECC) += ecc.o
 nandcore-$(CONFIG_MTD_NAND_ECC_SW_HAMMING) += ecc-sw-hamming.o
 nandcore-$(CONFIG_MTD_NAND_ECC_SW_BCH) += ecc-sw-bch.o
+nandcore-$(CONFIG_MTD_NAND_ECC_MXIC) += ecc-mxic.o
diff --git a/drivers/mtd/nand/ecc-mxic.c b/drivers/mtd/nand/ecc-mxic.c
new file mode 100644
index 000000000000..ea88a411ed70
--- /dev/null
+++ b/drivers/mtd/nand/ecc-mxic.c
@@ -0,0 +1,692 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Support for Macronix external hardware ECC engine for NAND devices, also
+ * called DPE for Data Processing Engine.
+ *
+ * Copyright © 2019 Macronix
+ * Author: Miquel Raynal <miquel.raynal@bootlin.com>
+ */
+
+#include <linux/dma-mapping.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mutex.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+/* DPE Configuration */
+#define DP_CONFIG 0x00
+#define   ECC_EN BIT(0)
+#define   ECC_TYP(idx) (((idx) << 3) & GENMASK(6, 3))
+/* DPE Interrupt Status */
+#define INTRPT_STS 0x04
+#define   TRANS_CMPLT BIT(0)
+#define   SDMA_MAIN BIT(1)
+#define   SDMA_SPARE BIT(2)
+#define   ECC_ERR BIT(3)
+#define   TO_SPARE BIT(4)
+#define   TO_MAIN BIT(5)
+/* DPE Interrupt Status Enable */
+#define INTRPT_STS_EN 0x08
+/* DPE Interrupt Signal Enable */
+#define INTRPT_SIG_EN 0x0C
+/* Host Controller Configuration */
+#define HC_CONFIG 0x10
+#define   MEM2MEM BIT(4) /* TRANS_TYP_IO in the spec */
+#define   ECC_PACKED 0 /* LAYOUT_TYP_INTEGRATED in the spec */
+#define   ECC_INTERLEAVED BIT(2) /* LAYOUT_TYP_DISTRIBUTED in the spec */
+#define   BURST_TYP_FIXED 0
+#define   BURST_TYP_INCREASING BIT(0)
+/* Host Controller Slave Address */
+#define HC_SLV_ADDR 0x14
+/* ECC Chunk Size */
+#define CHUNK_SIZE 0x20
+/* Main Data Size */
+#define MAIN_SIZE 0x24
+/* Spare Data Size */
+#define SPARE_SIZE 0x28
+#define   META_SZ(reg) ((reg) & GENMASK(7, 0))
+#define   PARITY_SZ(reg) (((reg) & GENMASK(15, 8)) >> 8)
+#define   RSV_SZ(reg) (((reg) & GENMASK(23, 16)) >> 16)
+#define   SPARE_SZ(reg) ((reg) >> 24)
+/* ECC Chunk Count */
+#define CHUNK_CNT 0x30
+/* SDMA Control */
+#define SDMA_CTRL 0x40
+#define   WRITE_NAND 0
+#define   READ_NAND BIT(1)
+#define   CONT_NAND BIT(29)
+#define   CONT_SYSM BIT(30) /* Continue System Memory? */
+#define   SDMA_STRT BIT(31)
+/* SDMA Address of Main Data */
+#define SDMA_MAIN_ADDR 0x44
+/* SDMA Address of Spare Data */
+#define SDMA_SPARE_ADDR 0x48
+/* DPE Version Number */
+#define DP_VER 0xD0
+#define   DP_VER_OFFSET 16
+
+/* Status bytes between each chunk of spare data */
+#define STAT_BYTES 4
+#define   NO_ERR 0x00
+#define   MAX_CORR_ERR 0x28
+#define   UNCORR_ERR 0xFE
+#define   ERASED_CHUNK 0xFF
+
+struct mxic_ecc_engine {
+	struct device *dev;
+	void __iomem *regs;
+	int irq;
+	struct completion complete;
+	struct nand_ecc_engine external_engine;
+	struct mutex lock;
+};
+
+struct mxic_ecc_ctx {
+	/* ECC machinery */
+	unsigned int data_step_sz;
+	unsigned int oob_step_sz;
+	unsigned int parity_sz;
+	unsigned int meta_sz;
+	u8 *status;
+	int steps;
+
+	/* DMA boilerplate */
+	struct nand_ecc_req_tweak_ctx req_ctx;
+	u8 *oobwithstat;
+	struct scatterlist sg[2];
+	struct nand_page_io_req *req;
+};
+
+static struct mxic_ecc_engine *ext_ecc_eng_to_mxic(struct nand_ecc_engine *eng)
+{
+	return container_of(eng, struct mxic_ecc_engine, external_engine);
+}
+
+static struct mxic_ecc_engine *nand_to_mxic(struct nand_device *nand)
+{
+	struct nand_ecc_engine *eng = nand->ecc.engine;
+
+	return ext_ecc_eng_to_mxic(eng);
+}
+
+static int mxic_ecc_ooblayout_ecc(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_device *nand = mtd_to_nanddev(mtd);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+
+	if (section < 0 || section >= ctx->steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * ctx->oob_step_sz) + ctx->meta_sz;
+	oobregion->length = ctx->parity_sz;
+
+	return 0;
+}
+
+static int mxic_ecc_ooblayout_free(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	struct nand_device *nand = mtd_to_nanddev(mtd);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+
+	if (section < 0 || section >= ctx->steps)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 2;
+		oobregion->length = ctx->meta_sz - 2;
+	} else {
+		oobregion->offset = section * ctx->oob_step_sz;
+		oobregion->length = ctx->meta_sz;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops mxic_ecc_ooblayout_ops = {
+	.ecc = mxic_ecc_ooblayout_ecc,
+	.free = mxic_ecc_ooblayout_free,
+};
+
+static void mxic_ecc_disable_engine(struct mxic_ecc_engine *mxic)
+{
+	u32 reg;
+
+	reg = readl(mxic->regs + DP_CONFIG);
+	reg &= ~ECC_EN;
+	writel(reg, mxic->regs + DP_CONFIG);
+}
+
+static void mxic_ecc_enable_engine(struct mxic_ecc_engine *mxic)
+{
+	u32 reg;
+
+	reg = readl(mxic->regs + DP_CONFIG);
+	reg |= ECC_EN;
+	writel(reg, mxic->regs + DP_CONFIG);
+}
+
+static void mxic_ecc_disable_int(struct mxic_ecc_engine *mxic)
+{
+	writel(0, mxic->regs + INTRPT_SIG_EN);
+}
+
+static void mxic_ecc_enable_int(struct mxic_ecc_engine *mxic)
+{
+	writel(TRANS_CMPLT, mxic->regs + INTRPT_SIG_EN);
+}
+
+static irqreturn_t mxic_ecc_isr(int irq, void *dev_id)
+{
+	struct mxic_ecc_engine *mxic = dev_id;
+	u32 sts;
+
+	sts = readl(mxic->regs + INTRPT_STS);
+	if (!sts)
+		return IRQ_NONE;
+
+	if (sts & TRANS_CMPLT)
+		complete(&mxic->complete);
+
+	writel(sts, mxic->regs + INTRPT_STS);
+
+	return IRQ_HANDLED;
+}
+
+static int mxic_ecc_init_ctx(struct nand_device *nand, struct device *dev)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct nand_ecc_props *conf = &nand->ecc.ctx.conf;
+	struct nand_ecc_props *reqs = &nand->ecc.requirements;
+	struct nand_ecc_props *user = &nand->ecc.user_conf;
+	struct mtd_info *mtd = nanddev_to_mtd(nand);
+	int step_size = 0, strength = 0, desired_correction = 0, steps, idx;
+	int possible_strength[] = {4, 8, 40, 48};
+	int spare_size[] = {32, 32, 96, 96};
+	struct mxic_ecc_ctx *ctx;
+	u32 spare_reg;
+	int ret;
+
+	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	nand->ecc.ctx.priv = ctx;
+
+	/* Only large page NAND chips may use BCH */
+	if (mtd->oobsize < 64) {
+		pr_err("BCH cannot be used with small page NAND chips\n");
+		return -EINVAL;
+	}
+
+	mtd_set_ooblayout(mtd, &mxic_ecc_ooblayout_ops);
+
+	/* Enable all status bits */
+	writel(TRANS_CMPLT | SDMA_MAIN | SDMA_SPARE | ECC_ERR |
+	       TO_SPARE | TO_MAIN, mxic->regs + INTRPT_STS_EN);
+
+	/* Configure the correction depending on the NAND device topology */
+	if (user->step_size && user->strength) {
+		step_size = user->step_size;
+		strength = user->strength;
+	} else if (reqs->step_size && reqs->strength) {
+		step_size = reqs->step_size;
+		strength = reqs->strength;
+	}
+
+	if (step_size && strength) {
+		steps = mtd->writesize / step_size;
+		desired_correction = steps * strength;
+	}
+
+	/* Step size is fixed to 1kiB, strength may vary (4 possible values) */
+	conf->step_size = SZ_1K;
+	steps = mtd->writesize / conf->step_size;
+
+	ctx->status = devm_kzalloc(dev, steps * sizeof(u8), GFP_KERNEL);
+	if (!ctx->status)
+		return -ENOMEM;
+
+	if (desired_correction) {
+		strength = desired_correction / steps;
+
+		for (idx = 0; idx < ARRAY_SIZE(possible_strength); idx++)
+			if (possible_strength[idx] >= strength)
+				break;
+
+		idx = min_t(unsigned int, idx,
+			    ARRAY_SIZE(possible_strength) - 1);
+	} else {
+		/* Missing data, maximize the correction */
+		idx = ARRAY_SIZE(possible_strength) - 1;
+	}
+
+	/* Tune the selected strength until it fits in the OOB area */
+	for (; idx >= 0; idx--) {
+		if (spare_size[idx] * steps <= mtd->oobsize)
+			break;
+	}
+
+	/* This engine cannot be used with this NAND device */
+	if (idx < 0)
+		return -EINVAL;
+
+	/* Configure the engine for the desired strength */
+	writel(ECC_TYP(idx), mxic->regs + DP_CONFIG);
+	conf->strength = possible_strength[idx];
+	spare_reg = readl(mxic->regs + SPARE_SIZE);
+
+	ctx->steps = steps;
+	ctx->data_step_sz = mtd->writesize / steps;
+	ctx->oob_step_sz = mtd->oobsize / steps;
+	ctx->parity_sz = PARITY_SZ(spare_reg);
+	ctx->meta_sz = META_SZ(spare_reg);
+
+	/* Ensure buffers will contain enough bytes to store the STAT_BYTES */
+	ctx->req_ctx.oob_buffer_size = nanddev_per_page_oobsize(nand) +
+					(ctx->steps * STAT_BYTES);
+	ret = nand_ecc_init_req_tweaking(&ctx->req_ctx, nand);
+	if (ret)
+		return ret;
+
+	ctx->oobwithstat = kmalloc(mtd->oobsize + (ctx->steps * STAT_BYTES),
+				   GFP_KERNEL);
+	if (!ctx->oobwithstat) {
+		ret = -ENOMEM;
+		goto cleanup_req_tweak;
+	}
+
+	sg_init_table(ctx->sg, 2);
+
+	/* Configuration dump and sanity checks */
+	dev_err(dev, "DPE version number: %d\n",
+		readl(mxic->regs + DP_VER) >> DP_VER_OFFSET);
+	dev_err(dev, "Chunk size: %d\n", readl(mxic->regs + CHUNK_SIZE));
+	dev_err(dev, "Main size: %d\n", readl(mxic->regs + MAIN_SIZE));
+	dev_err(dev, "Spare size: %d\n", SPARE_SZ(spare_reg));
+	dev_err(dev, "Rsv size: %ld\n", RSV_SZ(spare_reg));
+	dev_err(dev, "Parity size: %d\n", ctx->parity_sz);
+	dev_err(dev, "Meta size: %d\n", ctx->meta_sz);
+
+	if ((ctx->meta_sz + ctx->parity_sz + RSV_SZ(spare_reg)) !=
+	    SPARE_SZ(spare_reg)) {
+		dev_err(dev, "Wrong OOB configuration: %d + %d + %ld != %d\n",
+			ctx->meta_sz, ctx->parity_sz, RSV_SZ(spare_reg),
+			SPARE_SZ(spare_reg));
+		ret = -EINVAL;
+		goto free_oobwithstat;
+	}
+
+	if (ctx->oob_step_sz != SPARE_SZ(spare_reg)) {
+		dev_err(dev, "Wrong OOB configuration: %d != %d\n",
+			ctx->oob_step_sz, SPARE_SZ(spare_reg));
+		ret = -EINVAL;
+		goto free_oobwithstat;
+	}
+
+	return 0;
+
+free_oobwithstat:
+	kfree(ctx->oobwithstat);
+cleanup_req_tweak:
+	nand_ecc_cleanup_req_tweaking(&ctx->req_ctx);
+
+	return ret;
+}
+
+static int mxic_ecc_init_ctx_external(struct nand_device *nand)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct device *dev = nand->ecc.engine->dev;
+	int ret;
+
+	dev_info(dev, "Macronix ECC engine in external mode\n");
+
+	ret = mxic_ecc_init_ctx(nand, dev);
+	if (ret)
+		return ret;
+
+	/* Trigger each step manually */
+	writel(1, mxic->regs + CHUNK_CNT);
+	writel(BURST_TYP_INCREASING | ECC_PACKED | MEM2MEM,
+	       mxic->regs + HC_CONFIG);
+
+	return 0;
+}
+
+static void mxic_ecc_cleanup_ctx(struct nand_device *nand)
+{
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+
+	if (ctx) {
+		nand_ecc_cleanup_req_tweaking(&ctx->req_ctx);
+		kfree(ctx->oobwithstat);
+	}
+}
+
+static int mxic_ecc_data_xfer_wait_for_completion(struct mxic_ecc_engine *mxic)
+{
+	u32 val;
+	int ret;
+
+	if (mxic->irq) {
+		reinit_completion(&mxic->complete);
+		mxic_ecc_enable_int(mxic);
+		ret = wait_for_completion_timeout(&mxic->complete,
+						  msecs_to_jiffies(1000));
+		mxic_ecc_disable_int(mxic);
+	} else {
+		ret = readl_poll_timeout(mxic->regs + INTRPT_STS, val,
+					 val & TRANS_CMPLT, 10, USEC_PER_SEC);
+		writel(val, mxic->regs + INTRPT_STS);
+	}
+
+	if (ret) {
+		dev_err(mxic->dev, "Timeout on data xfer completion (sts 0x%08x)\n", val);
+		return -ETIMEDOUT;
+	}
+
+	return 0;
+}
+
+static int mxic_ecc_process_data(struct mxic_ecc_engine *mxic,
+				 unsigned int direction)
+{
+	unsigned int dir = (direction == NAND_PAGE_READ) ?
+			   READ_NAND : WRITE_NAND;
+	int ret;
+
+	mxic_ecc_enable_engine(mxic);
+
+	/* Trigger processing */
+	writel(SDMA_STRT | dir, mxic->regs + SDMA_CTRL);
+
+	/* Wait for completion */
+	ret = mxic_ecc_data_xfer_wait_for_completion(mxic);
+
+	mxic_ecc_disable_engine(mxic);
+
+	return ret;
+}
+
+static void mxic_ecc_extract_status_bytes(struct mxic_ecc_ctx *ctx)
+{
+	u8 *buf = ctx->oobwithstat;
+	int next_stat_pos;
+	int step;
+
+	/* Extract the ECC status */
+	for (step = 0; step < ctx->steps; step++) {
+		next_stat_pos = ctx->oob_step_sz +
+				((STAT_BYTES + ctx->oob_step_sz) * step);
+
+		ctx->status[step] = buf[next_stat_pos];
+	}
+}
+
+static void mxic_ecc_reconstruct_oobbuf(struct mxic_ecc_ctx *ctx,
+					u8 *dst, const u8 *src)
+{
+	int step;
+
+	/* Reconstruct the OOB buffer linearly (without the ECC status bytes) */
+	for (step = 0; step < ctx->steps; step++)
+		memcpy(dst + (step * ctx->oob_step_sz),
+		       src + (step * (ctx->oob_step_sz + STAT_BYTES)),
+		       ctx->oob_step_sz);
+}
+
+static void mxic_ecc_add_room_in_oobbuf(struct mxic_ecc_ctx *ctx,
+					u8 *dst, const u8 *src)
+{
+	int step;
+
+	/* Add some space in the OOB buffer for the status bytes */
+	for (step = 0; step < ctx->steps; step++)
+		memcpy(dst + (step * (ctx->oob_step_sz + STAT_BYTES)),
+		       src + (step * ctx->oob_step_sz),
+		       ctx->oob_step_sz);
+}
+
+static int mxic_ecc_count_biterrs(struct mxic_ecc_engine *mxic,
+				  struct nand_device *nand)
+{
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+	struct mtd_info *mtd = nanddev_to_mtd(nand);
+	struct device *dev = mxic->dev;
+	unsigned int max_bf = 0;
+	bool failure = false;
+	int step;
+
+	for (step = 0; step < ctx->steps; step++) {
+		u8 stat = ctx->status[step];
+
+		if (stat == NO_ERR) {
+			dev_dbg(dev, "ECC step %d: no error\n", step);
+		} else if (stat == ERASED_CHUNK) {
+			dev_dbg(dev, "ECC step %d: erased\n", step);
+		} else if (stat == UNCORR_ERR || stat > MAX_CORR_ERR) {
+			dev_dbg(dev, "ECC step %d: uncorrectable\n", step);
+			mtd->ecc_stats.failed++;
+			failure = true;
+		} else {
+			dev_dbg(dev, "ECC step %d: %d bits corrected\n",
+				step, stat);
+			max_bf = max_t(unsigned int, max_bf, stat);
+			mtd->ecc_stats.corrected += stat;
+		}
+	}
+
+	return failure ? -EBADMSG : max_bf;
+}
+
+/* External ECC engine helpers */
+static int mxic_ecc_prepare_io_req_external(struct nand_device *nand,
+					    struct nand_page_io_req *req)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+	struct mtd_info *mtd = nanddev_to_mtd(nand);
+	int offset, nents, step, ret;
+
+	if (req->mode == MTD_OPS_RAW)
+		return 0;
+
+	nand_ecc_tweak_req(&ctx->req_ctx, req);
+	ctx->req = req;
+
+	if (req->type == NAND_PAGE_READ)
+		return 0;
+
+	mxic_ecc_add_room_in_oobbuf(ctx, ctx->oobwithstat,
+				    ctx->req->oobbuf.out);
+
+	sg_set_buf(&ctx->sg[0], req->databuf.out, req->datalen);
+	sg_set_buf(&ctx->sg[1], ctx->oobwithstat,
+		   req->ooblen + (ctx->steps * STAT_BYTES));
+
+	nents = dma_map_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+	if (!nents)
+		return -EINVAL;
+
+	mutex_lock(&mxic->lock);
+
+	for (step = 0; step < ctx->steps; step++) {
+		writel(sg_dma_address(&ctx->sg[0]) + (step * ctx->data_step_sz),
+		       mxic->regs + SDMA_MAIN_ADDR);
+		writel(sg_dma_address(&ctx->sg[1]) + (step * (ctx->oob_step_sz + STAT_BYTES)),
+		       mxic->regs + SDMA_SPARE_ADDR);
+		ret = mxic_ecc_process_data(mxic, ctx->req->type);
+		if (ret)
+			break;
+	}
+
+	mutex_unlock(&mxic->lock);
+
+	dma_unmap_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+
+	/* Retrieve the calculated ECC bytes */
+	for (step = 0; step < ctx->steps; step++) {
+		offset = ctx->meta_sz + (step * ctx->oob_step_sz);
+		mtd_ooblayout_get_eccbytes(mtd,
+					   (u8 *)ctx->req->oobbuf.out + offset,
+					   ctx->oobwithstat + (step * STAT_BYTES),
+					   step * ctx->parity_sz,
+					   ctx->parity_sz);
+	}
+
+	return ret;
+}
+
+static int mxic_ecc_finish_io_req_external(struct nand_device *nand,
+					   struct nand_page_io_req *req)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+	int nents, step, ret;
+
+	if (req->mode == MTD_OPS_RAW)
+		return 0;
+
+	if (req->type == NAND_PAGE_WRITE) {
+		nand_ecc_restore_req(&ctx->req_ctx, req);
+		return 0;
+	}
+
+	/* Copy the OOB buffer and add room for the ECC engine status bytes */
+	mxic_ecc_add_room_in_oobbuf(ctx, ctx->oobwithstat, ctx->req->oobbuf.in);
+
+	sg_set_buf(&ctx->sg[0], req->databuf.in, req->datalen);
+	sg_set_buf(&ctx->sg[1], ctx->oobwithstat,
+		   req->ooblen + (ctx->steps * STAT_BYTES));
+	nents = dma_map_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+	if (!nents)
+		return -EINVAL;
+
+	mutex_lock(&mxic->lock);
+
+	for (step = 0; step < ctx->steps; step++) {
+		writel(sg_dma_address(&ctx->sg[0]) + (step * ctx->data_step_sz),
+		       mxic->regs + SDMA_MAIN_ADDR);
+		writel(sg_dma_address(&ctx->sg[1]) + (step * (ctx->oob_step_sz + STAT_BYTES)),
+		       mxic->regs + SDMA_SPARE_ADDR);
+		ret = mxic_ecc_process_data(mxic, ctx->req->type);
+		if (ret)
+			break;
+	}
+
+	mutex_unlock(&mxic->lock);
+
+	dma_unmap_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+
+	/* Extract the status bytes and reconstruct the buffer */
+	mxic_ecc_extract_status_bytes(ctx);
+	mxic_ecc_reconstruct_oobbuf(ctx, ctx->req->oobbuf.in, ctx->oobwithstat);
+
+	nand_ecc_restore_req(&ctx->req_ctx, req);
+
+	return mxic_ecc_count_biterrs(mxic, nand);
+}
+
+static struct nand_ecc_engine_ops mxic_ecc_engine_external_ops = {
+	.init_ctx = mxic_ecc_init_ctx_external,
+	.cleanup_ctx = mxic_ecc_cleanup_ctx,
+	.prepare_io_req = mxic_ecc_prepare_io_req_external,
+	.finish_io_req = mxic_ecc_finish_io_req_external,
+};
+
+static int mxic_ecc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mxic_ecc_engine *mxic;
+	int ret;
+
+	mxic = devm_kzalloc(&pdev->dev, sizeof(*mxic), GFP_KERNEL);
+	if (!mxic)
+		return -ENOMEM;
+
+	mxic->dev = &pdev->dev;
+
+	/*
+	 * Both memory regions for the ECC engine itself and the AXI slave
+	 * address are mandatory.
+	 */
+	mxic->regs = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(mxic->regs)) {
+		dev_err(&pdev->dev, "Missing memory region\n");
+		return PTR_ERR(mxic->regs);
+	}
+
+	mxic_ecc_disable_engine(mxic);
+	mxic_ecc_disable_int(mxic);
+
+	/* IRQ is optional yet much more efficient */
+	mxic->irq = platform_get_irq_byname_optional(pdev, "ecc-engine");
+	if (mxic->irq > 0) {
+		ret = devm_request_irq(&pdev->dev, mxic->irq, mxic_ecc_isr, 0,
+				       "mxic-ecc", mxic);
+		if (ret)
+			return ret;
+	} else {
+		dev_info(dev, "Invalid or missing IRQ, fallback to polling\n");
+		mxic->irq = 0;
+	}
+
+	mutex_init(&mxic->lock);
+
+	/*
+	 * In external mode, the device is the ECC engine. In pipelined mode,
+	 * the device is the host controller. The device is used to match the
+	 * right ECC engine based on the DT properties.
+	 */
+	mxic->external_engine.dev = &pdev->dev;
+	mxic->external_engine.integration = NAND_ECC_ENGINE_INTEGRATION_EXTERNAL;
+	mxic->external_engine.ops = &mxic_ecc_engine_external_ops;
+
+	nand_ecc_register_on_host_hw_engine(&mxic->external_engine);
+
+	platform_set_drvdata(pdev, mxic);
+
+	return 0;
+}
+
+static int mxic_ecc_remove(struct platform_device *pdev)
+{
+	struct mxic_ecc_engine *mxic = platform_get_drvdata(pdev);
+
+	nand_ecc_unregister_on_host_hw_engine(&mxic->external_engine);
+
+	return 0;
+}
+
+static const struct of_device_id mxic_ecc_of_ids[] = {
+	{
+		.compatible = "mxicy,nand-ecc-engine-rev3",
+	},
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mxic_ecc_of_ids);
+
+static struct platform_driver mxic_ecc_driver = {
+	.driver	= {
+		.name = "mxic-nand-ecc-engine",
+		.of_match_table = mxic_ecc_of_ids,
+	},
+	.probe = mxic_ecc_probe,
+	.remove	= mxic_ecc_remove,
+};
+module_platform_driver(mxic_ecc_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
+MODULE_DESCRIPTION("Macronix NAND hardware ECC controller");
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 15/28] mtd: nand: ecc: Provide a helper to retrieve a pilelined engine device
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

In a pipelined engine situation, we might either have the host which
internally has support for error correction, or have it using an
external hardware block for this purpose. In the former case, the host
is also the ECC engine. In the latter case, it is not. In order to get
the right pointers on the right devices (for example: in order to devm_*
allocate variables), let's introduce this helper which can safely be
called by pipelined ECC engines in order to retrieve the right device
structure.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/ecc.c   | 31 +++++++++++++++++++++++++++++++
 include/linux/mtd/nand.h |  1 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
index 078f5ec38de3..5250764cedee 100644
--- a/drivers/mtd/nand/ecc.c
+++ b/drivers/mtd/nand/ecc.c
@@ -699,6 +699,37 @@ void nand_ecc_put_on_host_hw_engine(struct nand_device *nand)
 }
 EXPORT_SYMBOL(nand_ecc_put_on_host_hw_engine);
 
+/*
+ * In the case of a pipelined engine, the device registering the ECC
+ * engine is not necessarily the ECC engine itself but may be a host controller.
+ * It is then useful to provide a helper to retrieve the right device object
+ * which actually represents the ECC engine.
+ */
+struct device *nand_ecc_get_engine_dev(struct device *host)
+{
+	struct platform_device *ecc_pdev;
+	struct device_node *np;
+
+	/*
+	 * If the device node contains this property, it means we need to follow
+	 * it in order to get the right ECC engine device we are looking for.
+	 */
+	np = of_parse_phandle(host->of_node, "nand-ecc-engine", 0);
+	if (!np)
+		return host;
+
+	ecc_pdev = of_find_device_by_node(np);
+	if (!ecc_pdev) {
+		of_node_put(np);
+		return NULL;
+	}
+
+	platform_device_put(ecc_pdev);
+	of_node_put(np);
+
+	return &ecc_pdev->dev;
+}
+
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
 MODULE_DESCRIPTION("Generic ECC engine");
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index b617efa0a881..615b3e3a3920 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -309,6 +309,7 @@ struct nand_ecc_engine *nand_ecc_get_sw_engine(struct nand_device *nand);
 struct nand_ecc_engine *nand_ecc_get_on_die_hw_engine(struct nand_device *nand);
 struct nand_ecc_engine *nand_ecc_get_on_host_hw_engine(struct nand_device *nand);
 void nand_ecc_put_on_host_hw_engine(struct nand_device *nand);
+struct device *nand_ecc_get_engine_dev(struct device *host);
 
 #if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING)
 struct nand_ecc_engine *nand_ecc_sw_hamming_get_engine(void);
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 15/28] mtd: nand: ecc: Provide a helper to retrieve a pilelined engine device
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

In a pipelined engine situation, we might either have the host which
internally has support for error correction, or have it using an
external hardware block for this purpose. In the former case, the host
is also the ECC engine. In the latter case, it is not. In order to get
the right pointers on the right devices (for example: in order to devm_*
allocate variables), let's introduce this helper which can safely be
called by pipelined ECC engines in order to retrieve the right device
structure.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/ecc.c   | 31 +++++++++++++++++++++++++++++++
 include/linux/mtd/nand.h |  1 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
index 078f5ec38de3..5250764cedee 100644
--- a/drivers/mtd/nand/ecc.c
+++ b/drivers/mtd/nand/ecc.c
@@ -699,6 +699,37 @@ void nand_ecc_put_on_host_hw_engine(struct nand_device *nand)
 }
 EXPORT_SYMBOL(nand_ecc_put_on_host_hw_engine);
 
+/*
+ * In the case of a pipelined engine, the device registering the ECC
+ * engine is not necessarily the ECC engine itself but may be a host controller.
+ * It is then useful to provide a helper to retrieve the right device object
+ * which actually represents the ECC engine.
+ */
+struct device *nand_ecc_get_engine_dev(struct device *host)
+{
+	struct platform_device *ecc_pdev;
+	struct device_node *np;
+
+	/*
+	 * If the device node contains this property, it means we need to follow
+	 * it in order to get the right ECC engine device we are looking for.
+	 */
+	np = of_parse_phandle(host->of_node, "nand-ecc-engine", 0);
+	if (!np)
+		return host;
+
+	ecc_pdev = of_find_device_by_node(np);
+	if (!ecc_pdev) {
+		of_node_put(np);
+		return NULL;
+	}
+
+	platform_device_put(ecc_pdev);
+	of_node_put(np);
+
+	return &ecc_pdev->dev;
+}
+
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
 MODULE_DESCRIPTION("Generic ECC engine");
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index b617efa0a881..615b3e3a3920 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -309,6 +309,7 @@ struct nand_ecc_engine *nand_ecc_get_sw_engine(struct nand_device *nand);
 struct nand_ecc_engine *nand_ecc_get_on_die_hw_engine(struct nand_device *nand);
 struct nand_ecc_engine *nand_ecc_get_on_host_hw_engine(struct nand_device *nand);
 void nand_ecc_put_on_host_hw_engine(struct nand_device *nand);
+struct device *nand_ecc_get_engine_dev(struct device *host);
 
 #if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING)
 struct nand_ecc_engine *nand_ecc_sw_hamming_get_engine(void);
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 16/28] mtd: nand: mxic-ecc: Support SPI pipelined mode
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Introduce the support for another possible configuration: the ECC
engine may work as DMA master (pipelined) and move itself the data
to/from the NAND chip into the buffer, applying the necessary
corrections/computations on the fly.

This driver offers an ECC engine implementation that must be
instatiated from a SPI controller driver.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/ecc-mxic.c       | 181 +++++++++++++++++++++++++++++-
 include/linux/mtd/nand-ecc-mxic.h |  49 ++++++++
 2 files changed, 229 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/mtd/nand-ecc-mxic.h

diff --git a/drivers/mtd/nand/ecc-mxic.c b/drivers/mtd/nand/ecc-mxic.c
index ea88a411ed70..3d2d20a6d465 100644
--- a/drivers/mtd/nand/ecc-mxic.c
+++ b/drivers/mtd/nand/ecc-mxic.c
@@ -16,6 +16,7 @@
 #include <linux/module.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/nand.h>
+#include <linux/mtd/nand-ecc-mxic.h>
 #include <linux/mutex.h>
 #include <linux/of_device.h>
 #include <linux/of_platform.h>
@@ -40,7 +41,9 @@
 #define INTRPT_SIG_EN 0x0C
 /* Host Controller Configuration */
 #define HC_CONFIG 0x10
+#define   DEV2MEM 0 /* TRANS_TYP_DMA in the spec */
 #define   MEM2MEM BIT(4) /* TRANS_TYP_IO in the spec */
+#define   MAPPING BIT(5) /* TRANS_TYP_MAPPING in the spec */
 #define   ECC_PACKED 0 /* LAYOUT_TYP_INTEGRATED in the spec */
 #define   ECC_INTERLEAVED BIT(2) /* LAYOUT_TYP_DISTRIBUTED in the spec */
 #define   BURST_TYP_FIXED 0
@@ -87,6 +90,7 @@ struct mxic_ecc_engine {
 	int irq;
 	struct completion complete;
 	struct nand_ecc_engine external_engine;
+	struct nand_ecc_engine pipelined_engine;
 	struct mutex lock;
 };
 
@@ -104,6 +108,7 @@ struct mxic_ecc_ctx {
 	u8 *oobwithstat;
 	struct scatterlist sg[2];
 	struct nand_page_io_req *req;
+	unsigned int pageoffs;
 };
 
 static struct mxic_ecc_engine *ext_ecc_eng_to_mxic(struct nand_ecc_engine *eng)
@@ -111,11 +116,19 @@ static struct mxic_ecc_engine *ext_ecc_eng_to_mxic(struct nand_ecc_engine *eng)
 	return container_of(eng, struct mxic_ecc_engine, external_engine);
 }
 
+static struct mxic_ecc_engine *pip_ecc_eng_to_mxic(struct nand_ecc_engine *eng)
+{
+	return container_of(eng, struct mxic_ecc_engine, pipelined_engine);
+}
+
 static struct mxic_ecc_engine *nand_to_mxic(struct nand_device *nand)
 {
 	struct nand_ecc_engine *eng = nand->ecc.engine;
 
-	return ext_ecc_eng_to_mxic(eng);
+	if (eng->integration == NAND_ECC_ENGINE_INTEGRATION_EXTERNAL)
+		return ext_ecc_eng_to_mxic(eng);
+	else
+		return pip_ecc_eng_to_mxic(eng);
 }
 
 static int mxic_ecc_ooblayout_ecc(struct mtd_info *mtd, int section,
@@ -364,6 +377,38 @@ static int mxic_ecc_init_ctx_external(struct nand_device *nand)
 	return 0;
 }
 
+static int mxic_ecc_init_ctx_pipelined(struct nand_device *nand)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct mxic_ecc_ctx *ctx;
+	struct device *dev;
+	int ret;
+
+	dev = nand_ecc_get_engine_dev(nand->ecc.engine->dev);
+	if (!dev)
+		return -EINVAL;
+
+	dev_info(dev, "Macronix ECC engine in pipelined/mapping mode\n");
+
+	ret = mxic_ecc_init_ctx(nand, dev);
+	if (ret)
+		return ret;
+
+	ctx = nand_to_ecc_ctx(nand);
+
+	/* All steps should be handled in one go directly by the internal DMA */
+	writel(ctx->steps, mxic->regs + CHUNK_CNT);
+
+	/*
+	 * Interleaved ECC scheme cannot be used otherwise factory bad block
+	 * markers would be lost. A packed layout is mandatory.
+	 */
+	writel(BURST_TYP_INCREASING | ECC_PACKED | MAPPING,
+	       mxic->regs + HC_CONFIG);
+
+	return 0;
+}
+
 static void mxic_ecc_cleanup_ctx(struct nand_device *nand)
 {
 	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
@@ -419,6 +464,18 @@ static int mxic_ecc_process_data(struct mxic_ecc_engine *mxic,
 	return ret;
 }
 
+int mxic_ecc_process_data_pipelined(struct nand_ecc_engine *eng,
+				    unsigned int direction, dma_addr_t dirmap)
+{
+	struct mxic_ecc_engine *mxic = pip_ecc_eng_to_mxic(eng);
+
+	if (dirmap)
+		writel(dirmap, mxic->regs + HC_SLV_ADDR);
+
+	return mxic_ecc_process_data(mxic, direction);
+}
+EXPORT_SYMBOL_GPL(mxic_ecc_process_data_pipelined);
+
 static void mxic_ecc_extract_status_bytes(struct mxic_ecc_ctx *ctx)
 {
 	u8 *buf = ctx->oobwithstat;
@@ -598,6 +655,65 @@ static int mxic_ecc_finish_io_req_external(struct nand_device *nand,
 	return mxic_ecc_count_biterrs(mxic, nand);
 }
 
+/* Pipelined ECC engine helpers */
+static int mxic_ecc_prepare_io_req_pipelined(struct nand_device *nand,
+					     struct nand_page_io_req *req)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+	int nents;
+
+	if (req->mode == MTD_OPS_RAW)
+		return 0;
+
+	nand_ecc_tweak_req(&ctx->req_ctx, req);
+	ctx->req = req;
+
+	/* Copy the OOB buffer and add room for the ECC engine status bytes */
+	mxic_ecc_add_room_in_oobbuf(ctx, ctx->oobwithstat, ctx->req->oobbuf.in);
+
+	sg_set_buf(&ctx->sg[0], req->databuf.in, req->datalen);
+	sg_set_buf(&ctx->sg[1], ctx->oobwithstat,
+		   req->ooblen + (ctx->steps * STAT_BYTES));
+
+	nents = dma_map_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+	if (!nents)
+		return -EINVAL;
+
+	mutex_lock(&mxic->lock);
+
+	writel(sg_dma_address(&ctx->sg[0]), mxic->regs + SDMA_MAIN_ADDR);
+	writel(sg_dma_address(&ctx->sg[1]), mxic->regs + SDMA_SPARE_ADDR);
+
+	return 0;
+}
+
+static int mxic_ecc_finish_io_req_pipelined(struct nand_device *nand,
+					    struct nand_page_io_req *req)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+	int ret = 0;
+
+	if (req->mode == MTD_OPS_RAW)
+		return 0;
+
+	mutex_unlock(&mxic->lock);
+
+	dma_unmap_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+
+	if (req->type == NAND_PAGE_READ) {
+		mxic_ecc_extract_status_bytes(ctx);
+		mxic_ecc_reconstruct_oobbuf(ctx, ctx->req->oobbuf.in,
+					    ctx->oobwithstat);
+		ret = mxic_ecc_count_biterrs(mxic, nand);
+	}
+
+	nand_ecc_restore_req(&ctx->req_ctx, req);
+
+	return ret;
+}
+
 static struct nand_ecc_engine_ops mxic_ecc_engine_external_ops = {
 	.init_ctx = mxic_ecc_init_ctx_external,
 	.cleanup_ctx = mxic_ecc_cleanup_ctx,
@@ -605,6 +721,69 @@ static struct nand_ecc_engine_ops mxic_ecc_engine_external_ops = {
 	.finish_io_req = mxic_ecc_finish_io_req_external,
 };
 
+static struct nand_ecc_engine_ops mxic_ecc_engine_pipelined_ops = {
+	.init_ctx = mxic_ecc_init_ctx_pipelined,
+	.cleanup_ctx = mxic_ecc_cleanup_ctx,
+	.prepare_io_req = mxic_ecc_prepare_io_req_pipelined,
+	.finish_io_req = mxic_ecc_finish_io_req_pipelined,
+};
+
+struct nand_ecc_engine_ops *mxic_ecc_get_pipelined_ops(void)
+{
+	return &mxic_ecc_engine_pipelined_ops;
+}
+EXPORT_SYMBOL_GPL(mxic_ecc_get_pipelined_ops);
+
+static struct platform_device *
+mxic_ecc_get_pdev(struct platform_device *spi_pdev)
+{
+	struct platform_device *eng_pdev;
+	struct device_node *np;
+
+	/* Retrieve the nand-ecc-engine phandle */
+	np = of_parse_phandle(spi_pdev->dev.of_node, "nand-ecc-engine", 0);
+	if (!np)
+		return NULL;
+
+	/* Jump to the engine's device node */
+	eng_pdev = of_find_device_by_node(np);
+	of_node_put(np);
+
+	return eng_pdev;
+}
+
+void mxic_ecc_put_pipelined_engine(struct nand_ecc_engine *eng)
+{
+	struct mxic_ecc_engine *mxic = pip_ecc_eng_to_mxic(eng);
+
+	platform_device_put(to_platform_device(mxic->dev));
+}
+EXPORT_SYMBOL_GPL(mxic_ecc_put_pipelined_engine);
+
+struct nand_ecc_engine *
+mxic_ecc_get_pipelined_engine(struct platform_device *spi_pdev)
+{
+	struct platform_device *eng_pdev;
+	struct mxic_ecc_engine *mxic;
+
+	eng_pdev = mxic_ecc_get_pdev(spi_pdev);
+	if (!eng_pdev)
+		return ERR_PTR(-ENODEV);
+
+	mxic = platform_get_drvdata(eng_pdev);
+	if (!mxic) {
+		platform_device_put(eng_pdev);
+		return ERR_PTR(-EPROBE_DEFER);
+	}
+
+	return &mxic->pipelined_engine;
+}
+EXPORT_SYMBOL_GPL(mxic_ecc_get_pipelined_engine);
+
+/*
+ * Only the external ECC engine is exported as the pipelined is SoC specific, so
+ * it is registered directly by the drivers that wrap it.
+ */
 static int mxic_ecc_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
diff --git a/include/linux/mtd/nand-ecc-mxic.h b/include/linux/mtd/nand-ecc-mxic.h
new file mode 100644
index 000000000000..f3aa1ac82aed
--- /dev/null
+++ b/include/linux/mtd/nand-ecc-mxic.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright © 2019 Macronix
+ * Author: Miquèl Raynal <miquel.raynal@bootlin.com>
+ *
+ * Header for the Macronix external ECC engine.
+ */
+
+#ifndef __MTD_NAND_ECC_MXIC_H__
+#define __MTD_NAND_ECC_MXIC_H__
+
+#include <linux/platform_device.h>
+#include <linux/device.h>
+
+struct mxic_ecc_engine;
+
+#if IS_ENABLED(CONFIG_MTD_NAND_ECC_MXIC)
+
+struct nand_ecc_engine_ops *mxic_ecc_get_pipelined_ops(void);
+struct nand_ecc_engine *mxic_ecc_get_pipelined_engine(struct platform_device *spi_pdev);
+void mxic_ecc_put_pipelined_engine(struct nand_ecc_engine *eng);
+int mxic_ecc_process_data_pipelined(struct nand_ecc_engine *eng,
+				    unsigned int direction, dma_addr_t dirmap);
+
+#else /* !CONFIG_MTD_NAND_ECC_MXIC */
+
+static inline struct nand_ecc_engine_ops *mxic_ecc_get_pipelined_ops(void)
+{
+	return NULL;
+}
+
+static inline struct nand_ecc_engine *
+mxic_ecc_get_pipelined_engine(struct platform_device *spi_pdev)
+{
+	return ERR_PTR(-EOPNOTSUPP);
+}
+
+static inline void mxic_ecc_put_pipelined_engine(struct nand_ecc_engine *eng) {}
+
+static inline int mxic_ecc_process_data_pipelined(struct nand_ecc_engine *eng,
+						  unsigned int direction,
+						  dma_addr_t dirmap)
+{
+	return -EOPNOTSUPP;
+}
+
+#endif /* CONFIG_MTD_NAND_ECC_MXIC */
+
+#endif /* __MTD_NAND_ECC_MXIC_H__ */
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 16/28] mtd: nand: mxic-ecc: Support SPI pipelined mode
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Introduce the support for another possible configuration: the ECC
engine may work as DMA master (pipelined) and move itself the data
to/from the NAND chip into the buffer, applying the necessary
corrections/computations on the fly.

This driver offers an ECC engine implementation that must be
instatiated from a SPI controller driver.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/ecc-mxic.c       | 181 +++++++++++++++++++++++++++++-
 include/linux/mtd/nand-ecc-mxic.h |  49 ++++++++
 2 files changed, 229 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/mtd/nand-ecc-mxic.h

diff --git a/drivers/mtd/nand/ecc-mxic.c b/drivers/mtd/nand/ecc-mxic.c
index ea88a411ed70..3d2d20a6d465 100644
--- a/drivers/mtd/nand/ecc-mxic.c
+++ b/drivers/mtd/nand/ecc-mxic.c
@@ -16,6 +16,7 @@
 #include <linux/module.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/nand.h>
+#include <linux/mtd/nand-ecc-mxic.h>
 #include <linux/mutex.h>
 #include <linux/of_device.h>
 #include <linux/of_platform.h>
@@ -40,7 +41,9 @@
 #define INTRPT_SIG_EN 0x0C
 /* Host Controller Configuration */
 #define HC_CONFIG 0x10
+#define   DEV2MEM 0 /* TRANS_TYP_DMA in the spec */
 #define   MEM2MEM BIT(4) /* TRANS_TYP_IO in the spec */
+#define   MAPPING BIT(5) /* TRANS_TYP_MAPPING in the spec */
 #define   ECC_PACKED 0 /* LAYOUT_TYP_INTEGRATED in the spec */
 #define   ECC_INTERLEAVED BIT(2) /* LAYOUT_TYP_DISTRIBUTED in the spec */
 #define   BURST_TYP_FIXED 0
@@ -87,6 +90,7 @@ struct mxic_ecc_engine {
 	int irq;
 	struct completion complete;
 	struct nand_ecc_engine external_engine;
+	struct nand_ecc_engine pipelined_engine;
 	struct mutex lock;
 };
 
@@ -104,6 +108,7 @@ struct mxic_ecc_ctx {
 	u8 *oobwithstat;
 	struct scatterlist sg[2];
 	struct nand_page_io_req *req;
+	unsigned int pageoffs;
 };
 
 static struct mxic_ecc_engine *ext_ecc_eng_to_mxic(struct nand_ecc_engine *eng)
@@ -111,11 +116,19 @@ static struct mxic_ecc_engine *ext_ecc_eng_to_mxic(struct nand_ecc_engine *eng)
 	return container_of(eng, struct mxic_ecc_engine, external_engine);
 }
 
+static struct mxic_ecc_engine *pip_ecc_eng_to_mxic(struct nand_ecc_engine *eng)
+{
+	return container_of(eng, struct mxic_ecc_engine, pipelined_engine);
+}
+
 static struct mxic_ecc_engine *nand_to_mxic(struct nand_device *nand)
 {
 	struct nand_ecc_engine *eng = nand->ecc.engine;
 
-	return ext_ecc_eng_to_mxic(eng);
+	if (eng->integration == NAND_ECC_ENGINE_INTEGRATION_EXTERNAL)
+		return ext_ecc_eng_to_mxic(eng);
+	else
+		return pip_ecc_eng_to_mxic(eng);
 }
 
 static int mxic_ecc_ooblayout_ecc(struct mtd_info *mtd, int section,
@@ -364,6 +377,38 @@ static int mxic_ecc_init_ctx_external(struct nand_device *nand)
 	return 0;
 }
 
+static int mxic_ecc_init_ctx_pipelined(struct nand_device *nand)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct mxic_ecc_ctx *ctx;
+	struct device *dev;
+	int ret;
+
+	dev = nand_ecc_get_engine_dev(nand->ecc.engine->dev);
+	if (!dev)
+		return -EINVAL;
+
+	dev_info(dev, "Macronix ECC engine in pipelined/mapping mode\n");
+
+	ret = mxic_ecc_init_ctx(nand, dev);
+	if (ret)
+		return ret;
+
+	ctx = nand_to_ecc_ctx(nand);
+
+	/* All steps should be handled in one go directly by the internal DMA */
+	writel(ctx->steps, mxic->regs + CHUNK_CNT);
+
+	/*
+	 * Interleaved ECC scheme cannot be used otherwise factory bad block
+	 * markers would be lost. A packed layout is mandatory.
+	 */
+	writel(BURST_TYP_INCREASING | ECC_PACKED | MAPPING,
+	       mxic->regs + HC_CONFIG);
+
+	return 0;
+}
+
 static void mxic_ecc_cleanup_ctx(struct nand_device *nand)
 {
 	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
@@ -419,6 +464,18 @@ static int mxic_ecc_process_data(struct mxic_ecc_engine *mxic,
 	return ret;
 }
 
+int mxic_ecc_process_data_pipelined(struct nand_ecc_engine *eng,
+				    unsigned int direction, dma_addr_t dirmap)
+{
+	struct mxic_ecc_engine *mxic = pip_ecc_eng_to_mxic(eng);
+
+	if (dirmap)
+		writel(dirmap, mxic->regs + HC_SLV_ADDR);
+
+	return mxic_ecc_process_data(mxic, direction);
+}
+EXPORT_SYMBOL_GPL(mxic_ecc_process_data_pipelined);
+
 static void mxic_ecc_extract_status_bytes(struct mxic_ecc_ctx *ctx)
 {
 	u8 *buf = ctx->oobwithstat;
@@ -598,6 +655,65 @@ static int mxic_ecc_finish_io_req_external(struct nand_device *nand,
 	return mxic_ecc_count_biterrs(mxic, nand);
 }
 
+/* Pipelined ECC engine helpers */
+static int mxic_ecc_prepare_io_req_pipelined(struct nand_device *nand,
+					     struct nand_page_io_req *req)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+	int nents;
+
+	if (req->mode == MTD_OPS_RAW)
+		return 0;
+
+	nand_ecc_tweak_req(&ctx->req_ctx, req);
+	ctx->req = req;
+
+	/* Copy the OOB buffer and add room for the ECC engine status bytes */
+	mxic_ecc_add_room_in_oobbuf(ctx, ctx->oobwithstat, ctx->req->oobbuf.in);
+
+	sg_set_buf(&ctx->sg[0], req->databuf.in, req->datalen);
+	sg_set_buf(&ctx->sg[1], ctx->oobwithstat,
+		   req->ooblen + (ctx->steps * STAT_BYTES));
+
+	nents = dma_map_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+	if (!nents)
+		return -EINVAL;
+
+	mutex_lock(&mxic->lock);
+
+	writel(sg_dma_address(&ctx->sg[0]), mxic->regs + SDMA_MAIN_ADDR);
+	writel(sg_dma_address(&ctx->sg[1]), mxic->regs + SDMA_SPARE_ADDR);
+
+	return 0;
+}
+
+static int mxic_ecc_finish_io_req_pipelined(struct nand_device *nand,
+					    struct nand_page_io_req *req)
+{
+	struct mxic_ecc_engine *mxic = nand_to_mxic(nand);
+	struct mxic_ecc_ctx *ctx = nand_to_ecc_ctx(nand);
+	int ret = 0;
+
+	if (req->mode == MTD_OPS_RAW)
+		return 0;
+
+	mutex_unlock(&mxic->lock);
+
+	dma_unmap_sg(mxic->dev, ctx->sg, 2, DMA_BIDIRECTIONAL);
+
+	if (req->type == NAND_PAGE_READ) {
+		mxic_ecc_extract_status_bytes(ctx);
+		mxic_ecc_reconstruct_oobbuf(ctx, ctx->req->oobbuf.in,
+					    ctx->oobwithstat);
+		ret = mxic_ecc_count_biterrs(mxic, nand);
+	}
+
+	nand_ecc_restore_req(&ctx->req_ctx, req);
+
+	return ret;
+}
+
 static struct nand_ecc_engine_ops mxic_ecc_engine_external_ops = {
 	.init_ctx = mxic_ecc_init_ctx_external,
 	.cleanup_ctx = mxic_ecc_cleanup_ctx,
@@ -605,6 +721,69 @@ static struct nand_ecc_engine_ops mxic_ecc_engine_external_ops = {
 	.finish_io_req = mxic_ecc_finish_io_req_external,
 };
 
+static struct nand_ecc_engine_ops mxic_ecc_engine_pipelined_ops = {
+	.init_ctx = mxic_ecc_init_ctx_pipelined,
+	.cleanup_ctx = mxic_ecc_cleanup_ctx,
+	.prepare_io_req = mxic_ecc_prepare_io_req_pipelined,
+	.finish_io_req = mxic_ecc_finish_io_req_pipelined,
+};
+
+struct nand_ecc_engine_ops *mxic_ecc_get_pipelined_ops(void)
+{
+	return &mxic_ecc_engine_pipelined_ops;
+}
+EXPORT_SYMBOL_GPL(mxic_ecc_get_pipelined_ops);
+
+static struct platform_device *
+mxic_ecc_get_pdev(struct platform_device *spi_pdev)
+{
+	struct platform_device *eng_pdev;
+	struct device_node *np;
+
+	/* Retrieve the nand-ecc-engine phandle */
+	np = of_parse_phandle(spi_pdev->dev.of_node, "nand-ecc-engine", 0);
+	if (!np)
+		return NULL;
+
+	/* Jump to the engine's device node */
+	eng_pdev = of_find_device_by_node(np);
+	of_node_put(np);
+
+	return eng_pdev;
+}
+
+void mxic_ecc_put_pipelined_engine(struct nand_ecc_engine *eng)
+{
+	struct mxic_ecc_engine *mxic = pip_ecc_eng_to_mxic(eng);
+
+	platform_device_put(to_platform_device(mxic->dev));
+}
+EXPORT_SYMBOL_GPL(mxic_ecc_put_pipelined_engine);
+
+struct nand_ecc_engine *
+mxic_ecc_get_pipelined_engine(struct platform_device *spi_pdev)
+{
+	struct platform_device *eng_pdev;
+	struct mxic_ecc_engine *mxic;
+
+	eng_pdev = mxic_ecc_get_pdev(spi_pdev);
+	if (!eng_pdev)
+		return ERR_PTR(-ENODEV);
+
+	mxic = platform_get_drvdata(eng_pdev);
+	if (!mxic) {
+		platform_device_put(eng_pdev);
+		return ERR_PTR(-EPROBE_DEFER);
+	}
+
+	return &mxic->pipelined_engine;
+}
+EXPORT_SYMBOL_GPL(mxic_ecc_get_pipelined_engine);
+
+/*
+ * Only the external ECC engine is exported as the pipelined is SoC specific, so
+ * it is registered directly by the drivers that wrap it.
+ */
 static int mxic_ecc_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
diff --git a/include/linux/mtd/nand-ecc-mxic.h b/include/linux/mtd/nand-ecc-mxic.h
new file mode 100644
index 000000000000..f3aa1ac82aed
--- /dev/null
+++ b/include/linux/mtd/nand-ecc-mxic.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright © 2019 Macronix
+ * Author: Miquèl Raynal <miquel.raynal@bootlin.com>
+ *
+ * Header for the Macronix external ECC engine.
+ */
+
+#ifndef __MTD_NAND_ECC_MXIC_H__
+#define __MTD_NAND_ECC_MXIC_H__
+
+#include <linux/platform_device.h>
+#include <linux/device.h>
+
+struct mxic_ecc_engine;
+
+#if IS_ENABLED(CONFIG_MTD_NAND_ECC_MXIC)
+
+struct nand_ecc_engine_ops *mxic_ecc_get_pipelined_ops(void);
+struct nand_ecc_engine *mxic_ecc_get_pipelined_engine(struct platform_device *spi_pdev);
+void mxic_ecc_put_pipelined_engine(struct nand_ecc_engine *eng);
+int mxic_ecc_process_data_pipelined(struct nand_ecc_engine *eng,
+				    unsigned int direction, dma_addr_t dirmap);
+
+#else /* !CONFIG_MTD_NAND_ECC_MXIC */
+
+static inline struct nand_ecc_engine_ops *mxic_ecc_get_pipelined_ops(void)
+{
+	return NULL;
+}
+
+static inline struct nand_ecc_engine *
+mxic_ecc_get_pipelined_engine(struct platform_device *spi_pdev)
+{
+	return ERR_PTR(-EOPNOTSUPP);
+}
+
+static inline void mxic_ecc_put_pipelined_engine(struct nand_ecc_engine *eng) {}
+
+static inline int mxic_ecc_process_data_pipelined(struct nand_ecc_engine *eng,
+						  unsigned int direction,
+						  dma_addr_t dirmap)
+{
+	return -EOPNOTSUPP;
+}
+
+#endif /* CONFIG_MTD_NAND_ECC_MXIC */
+
+#endif /* __MTD_NAND_ECC_MXIC_H__ */
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 17/28] mtd: spinand: Delay a little bit the dirmap creation
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

As we will soon tweak the dirmap creation to act a little bit
differently depending on the picked ECC engine, we need to initialize
dirmaps after ECC engines. This should not have any effect as dirmaps
are not yet used at this point.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/spi/core.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 7027c09925e2..715cad26fdef 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -1209,14 +1209,6 @@ static int spinand_init(struct spinand_device *spinand)
 	if (ret)
 		goto err_free_bufs;
 
-	ret = spinand_create_dirmaps(spinand);
-	if (ret) {
-		dev_err(dev,
-			"Failed to create direct mappings for read/write operations (err = %d)\n",
-			ret);
-		goto err_manuf_cleanup;
-	}
-
 	ret = nanddev_init(nand, &spinand_ops, THIS_MODULE);
 	if (ret)
 		goto err_manuf_cleanup;
@@ -1251,6 +1243,14 @@ static int spinand_init(struct spinand_device *spinand)
 	mtd->ecc_strength = nanddev_get_ecc_conf(nand)->strength;
 	mtd->ecc_step_size = nanddev_get_ecc_conf(nand)->step_size;
 
+	ret = spinand_create_dirmaps(spinand);
+	if (ret) {
+		dev_err(dev,
+			"Failed to create direct mappings for read/write operations (err = %d)\n",
+			ret);
+		goto err_cleanup_ecc_engine;
+	}
+
 	return 0;
 
 err_cleanup_ecc_engine:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 17/28] mtd: spinand: Delay a little bit the dirmap creation
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

As we will soon tweak the dirmap creation to act a little bit
differently depending on the picked ECC engine, we need to initialize
dirmaps after ECC engines. This should not have any effect as dirmaps
are not yet used at this point.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/spi/core.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 7027c09925e2..715cad26fdef 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -1209,14 +1209,6 @@ static int spinand_init(struct spinand_device *spinand)
 	if (ret)
 		goto err_free_bufs;
 
-	ret = spinand_create_dirmaps(spinand);
-	if (ret) {
-		dev_err(dev,
-			"Failed to create direct mappings for read/write operations (err = %d)\n",
-			ret);
-		goto err_manuf_cleanup;
-	}
-
 	ret = nanddev_init(nand, &spinand_ops, THIS_MODULE);
 	if (ret)
 		goto err_manuf_cleanup;
@@ -1251,6 +1243,14 @@ static int spinand_init(struct spinand_device *spinand)
 	mtd->ecc_strength = nanddev_get_ecc_conf(nand)->strength;
 	mtd->ecc_step_size = nanddev_get_ecc_conf(nand)->step_size;
 
+	ret = spinand_create_dirmaps(spinand);
+	if (ret) {
+		dev_err(dev,
+			"Failed to create direct mappings for read/write operations (err = %d)\n",
+			ret);
+		goto err_cleanup_ecc_engine;
+	}
+
 	return 0;
 
 err_cleanup_ecc_engine:
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 18/28] spi: spi-mem: Fix a DTR related check in spi_mem_dtr_supports_op()
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Boris Brezillon

It seems that the number of command bytes must be "2" only when the
command itself is sent in DTR mode. The current logic checks if the
number of command bytes is "2" when any of the cycles is a DTR cycle. It
is likely that so far no device was actually mixing DTR/non-DTR cycles
in the same operation, explaining why this was left undetected until
now.

Fixes: 539cf68cd51b ("spi: spi-mem: add spi_mem_dtr_supports_op()")
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/spi/spi-mem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 37f4443ce9a0..c4da0c9b05e9 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -163,7 +163,7 @@ static bool spi_mem_check_buswidth(struct spi_mem *mem,
 bool spi_mem_dtr_supports_op(struct spi_mem *mem,
 			     const struct spi_mem_op *op)
 {
-	if (op->cmd.nbytes != 2)
+	if (op->cmd.dtr && op->cmd.nbytes != 2)
 		return false;
 
 	return spi_mem_check_buswidth(mem, op);
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 18/28] spi: spi-mem: Fix a DTR related check in spi_mem_dtr_supports_op()
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Boris Brezillon

It seems that the number of command bytes must be "2" only when the
command itself is sent in DTR mode. The current logic checks if the
number of command bytes is "2" when any of the cycles is a DTR cycle. It
is likely that so far no device was actually mixing DTR/non-DTR cycles
in the same operation, explaining why this was left undetected until
now.

Fixes: 539cf68cd51b ("spi: spi-mem: add spi_mem_dtr_supports_op()")
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/spi/spi-mem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 37f4443ce9a0..c4da0c9b05e9 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -163,7 +163,7 @@ static bool spi_mem_check_buswidth(struct spi_mem *mem,
 bool spi_mem_dtr_supports_op(struct spi_mem *mem,
 			     const struct spi_mem_op *op)
 {
-	if (op->cmd.nbytes != 2)
+	if (op->cmd.dtr && op->cmd.nbytes != 2)
 		return false;
 
 	return spi_mem_check_buswidth(mem, op);
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 19/28] spi: spi-mem: Introduce a capability structure
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Create a spi_controller_mem_caps structure and put it within the
spi_controller_mem_ops structure as these are highly related. So far the
only field in this structure is the support for dtr operations, but soon
we will add another parameter.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/linux/spi/spi-mem.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 85e2ff7b840d..42f3850610b5 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -220,6 +220,14 @@ static inline void *spi_mem_get_drvdata(struct spi_mem *mem)
 	return mem->drvpriv;
 }
 
+/**
+ * struct spi_controller_mem_caps - SPI memory controller capabilities
+ * @dtr: Supports DTR operations
+ */
+struct spi_controller_mem_caps {
+	bool dtr;
+};
+
 /**
  * struct spi_controller_mem_ops - SPI memory operations
  * @adjust_op_size: shrink the data xfer of an operation to match controller's
@@ -253,6 +261,7 @@ static inline void *spi_mem_get_drvdata(struct spi_mem *mem)
  * @poll_status: poll memory device status until (status & mask) == match or
  *               when the timeout has expired. It fills the data buffer with
  *               the last status value.
+ * @caps: controller capabilities for the handling of the above operations.
  *
  * This interface should be implemented by SPI controllers providing an
  * high-level interface to execute SPI memory operation, which is usually the
@@ -283,6 +292,7 @@ struct spi_controller_mem_ops {
 			   unsigned long initial_delay_us,
 			   unsigned long polling_rate_us,
 			   unsigned long timeout_ms);
+	const struct spi_controller_mem_caps *caps;
 };
 
 /**
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 19/28] spi: spi-mem: Introduce a capability structure
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Create a spi_controller_mem_caps structure and put it within the
spi_controller_mem_ops structure as these are highly related. So far the
only field in this structure is the support for dtr operations, but soon
we will add another parameter.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/linux/spi/spi-mem.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 85e2ff7b840d..42f3850610b5 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -220,6 +220,14 @@ static inline void *spi_mem_get_drvdata(struct spi_mem *mem)
 	return mem->drvpriv;
 }
 
+/**
+ * struct spi_controller_mem_caps - SPI memory controller capabilities
+ * @dtr: Supports DTR operations
+ */
+struct spi_controller_mem_caps {
+	bool dtr;
+};
+
 /**
  * struct spi_controller_mem_ops - SPI memory operations
  * @adjust_op_size: shrink the data xfer of an operation to match controller's
@@ -253,6 +261,7 @@ static inline void *spi_mem_get_drvdata(struct spi_mem *mem)
  * @poll_status: poll memory device status until (status & mask) == match or
  *               when the timeout has expired. It fills the data buffer with
  *               the last status value.
+ * @caps: controller capabilities for the handling of the above operations.
  *
  * This interface should be implemented by SPI controllers providing an
  * high-level interface to execute SPI memory operation, which is usually the
@@ -283,6 +292,7 @@ struct spi_controller_mem_ops {
 			   unsigned long initial_delay_us,
 			   unsigned long polling_rate_us,
 			   unsigned long timeout_ms);
+	const struct spi_controller_mem_caps *caps;
 };
 
 /**
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Update all the spi controller drivers registering spi-mem operations to
provide a spi-mem capabilities structure.

For most of them, it is just a matter of referencing the newly created
spi_mem_no_caps empty structure. Only Cadence and Macronix SPI
controller drivers support DTR operations, so these two need to define
a non-empty set of capabilities.

Prevent any new controller to register a set of spi-mem operations
without a capabilities structure.

So far these capabilities are not used by the core, this is just a
preparation change.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/spi/atmel-quadspi.c       | 3 ++-
 drivers/spi/spi-bcm-qspi.c        | 1 +
 drivers/spi/spi-cadence-quadspi.c | 5 +++++
 drivers/spi/spi-dw-core.c         | 1 +
 drivers/spi/spi-fsl-qspi.c        | 1 +
 drivers/spi/spi-hisi-sfc-v3xx.c   | 1 +
 drivers/spi/spi-mem.c             | 3 +++
 drivers/spi/spi-mtk-nor.c         | 3 ++-
 drivers/spi/spi-mxic.c            | 5 +++++
 drivers/spi/spi-npcm-fiu.c        | 1 +
 drivers/spi/spi-nxp-fspi.c        | 1 +
 drivers/spi/spi-rockchip-sfc.c    | 1 +
 drivers/spi/spi-rpc-if.c          | 1 +
 drivers/spi/spi-stm32-qspi.c      | 1 +
 drivers/spi/spi-ti-qspi.c         | 1 +
 drivers/spi/spi-zynq-qspi.c       | 1 +
 drivers/spi/spi-zynqmp-gqspi.c    | 1 +
 drivers/spi/spi.c                 | 3 +++
 include/linux/spi/spi-mem.h       | 1 +
 19 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
index 95d4fa32c299..7d43ed8d124d 100644
--- a/drivers/spi/atmel-quadspi.c
+++ b/drivers/spi/atmel-quadspi.c
@@ -466,7 +466,8 @@ static const char *atmel_qspi_get_name(struct spi_mem *spimem)
 static const struct spi_controller_mem_ops atmel_qspi_mem_ops = {
 	.supports_op = atmel_qspi_supports_op,
 	.exec_op = atmel_qspi_exec_op,
-	.get_name = atmel_qspi_get_name
+	.get_name = atmel_qspi_get_name,
+	.caps = &spi_mem_no_caps,
 };
 
 static int atmel_qspi_setup(struct spi_device *spi)
diff --git a/drivers/spi/spi-bcm-qspi.c b/drivers/spi/spi-bcm-qspi.c
index a78e56f566dd..c43d46ea2534 100644
--- a/drivers/spi/spi-bcm-qspi.c
+++ b/drivers/spi/spi-bcm-qspi.c
@@ -1258,6 +1258,7 @@ static void bcm_qspi_hw_uninit(struct bcm_qspi *qspi)
 
 static const struct spi_controller_mem_ops bcm_qspi_mem_ops = {
 	.exec_op = bcm_qspi_exec_mem_op,
+	.caps = &spi_mem_no_caps,
 };
 
 struct bcm_qspi_data {
diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 101cc71bffa7..0622c7db52e6 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1388,10 +1388,15 @@ static const char *cqspi_get_name(struct spi_mem *mem)
 	return devm_kasprintf(dev, GFP_KERNEL, "%s.%d", dev_name(dev), mem->spi->chip_select);
 }
 
+const struct spi_controller_mem_caps cqspi_mem_caps = {
+	.dtr = true,
+};
+
 static const struct spi_controller_mem_ops cqspi_mem_ops = {
 	.exec_op = cqspi_exec_mem_op,
 	.get_name = cqspi_get_name,
 	.supports_op = cqspi_supports_mem_op,
+	.caps = &cqspi_mem_caps,
 };
 
 static int cqspi_setup_flash(struct cqspi_st *cqspi)
diff --git a/drivers/spi/spi-dw-core.c b/drivers/spi/spi-dw-core.c
index a305074c482e..896e299a8c51 100644
--- a/drivers/spi/spi-dw-core.c
+++ b/drivers/spi/spi-dw-core.c
@@ -759,6 +759,7 @@ static void dw_spi_init_mem_ops(struct dw_spi *dws)
 		dws->mem_ops.adjust_op_size = dw_spi_adjust_mem_op_size;
 		dws->mem_ops.supports_op = dw_spi_supports_mem_op;
 		dws->mem_ops.exec_op = dw_spi_exec_mem_op;
+		dws->mem_ops.caps = &spi_mem_no_caps;
 		if (!dws->max_mem_freq)
 			dws->max_mem_freq = dws->max_freq;
 	}
diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c
index 9851551ebbe0..420d6d77c989 100644
--- a/drivers/spi/spi-fsl-qspi.c
+++ b/drivers/spi/spi-fsl-qspi.c
@@ -838,6 +838,7 @@ static const struct spi_controller_mem_ops fsl_qspi_mem_ops = {
 	.supports_op = fsl_qspi_supports_op,
 	.exec_op = fsl_qspi_exec_op,
 	.get_name = fsl_qspi_get_name,
+	.caps = &spi_mem_no_caps,
 };
 
 static int fsl_qspi_probe(struct platform_device *pdev)
diff --git a/drivers/spi/spi-hisi-sfc-v3xx.c b/drivers/spi/spi-hisi-sfc-v3xx.c
index d3a23b1c2a4c..88eb061b7eb7 100644
--- a/drivers/spi/spi-hisi-sfc-v3xx.c
+++ b/drivers/spi/spi-hisi-sfc-v3xx.c
@@ -372,6 +372,7 @@ static const struct spi_controller_mem_ops hisi_sfc_v3xx_mem_ops = {
 	.adjust_op_size = hisi_sfc_v3xx_adjust_op_size,
 	.supports_op = hisi_sfc_v3xx_supports_op,
 	.exec_op = hisi_sfc_v3xx_exec_op,
+	.caps = &spi_mem_no_caps,
 };
 
 static irqreturn_t hisi_sfc_v3xx_isr(int irq, void *data)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index c4da0c9b05e9..bfd5c6b2db0a 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -160,6 +160,9 @@ static bool spi_mem_check_buswidth(struct spi_mem *mem,
 	return true;
 }
 
+const struct spi_controller_mem_caps spi_mem_no_caps = {};
+EXPORT_SYMBOL_GPL(spi_mem_no_caps);
+
 bool spi_mem_dtr_supports_op(struct spi_mem *mem,
 			     const struct spi_mem_op *op)
 {
diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
index 41e7b341d261..444b36d94c6d 100644
--- a/drivers/spi/spi-mtk-nor.c
+++ b/drivers/spi/spi-mtk-nor.c
@@ -740,7 +740,8 @@ static size_t mtk_max_msg_size(struct spi_device *spi)
 static const struct spi_controller_mem_ops mtk_nor_mem_ops = {
 	.adjust_op_size = mtk_nor_adjust_op_size,
 	.supports_op = mtk_nor_supports_op,
-	.exec_op = mtk_nor_exec_op
+	.exec_op = mtk_nor_exec_op,
+	.caps = &spi_mem_no_caps,
 };
 
 static const struct of_device_id mtk_nor_match[] = {
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 45889947afed..8f8530bd3779 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -443,9 +443,14 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 	return ret;
 }
 
+const struct spi_controller_mem_caps mxic_spi_mem_caps = {
+	.dtr = true,
+};
+
 static const struct spi_controller_mem_ops mxic_spi_mem_ops = {
 	.supports_op = mxic_spi_mem_supports_op,
 	.exec_op = mxic_spi_mem_exec_op,
+	.caps = &mxic_spi_mem_caps,
 };
 
 static void mxic_spi_set_cs(struct spi_device *spi, bool lvl)
diff --git a/drivers/spi/spi-npcm-fiu.c b/drivers/spi/spi-npcm-fiu.c
index b62471ab6d7f..fc90180412e3 100644
--- a/drivers/spi/spi-npcm-fiu.c
+++ b/drivers/spi/spi-npcm-fiu.c
@@ -661,6 +661,7 @@ static const struct spi_controller_mem_ops npcm_fiu_mem_ops = {
 	.dirmap_create = npcm_fiu_dirmap_create,
 	.dirmap_read = npcm_fiu_direct_read,
 	.dirmap_write = npcm_fiu_direct_write,
+	.caps = &spi_mem_no_caps,
 };
 
 static const struct of_device_id npcm_fiu_dt_ids[] = {
diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
index a66fa97046ee..bca0ccc20865 100644
--- a/drivers/spi/spi-nxp-fspi.c
+++ b/drivers/spi/spi-nxp-fspi.c
@@ -1082,6 +1082,7 @@ static const struct spi_controller_mem_ops nxp_fspi_mem_ops = {
 	.supports_op = nxp_fspi_supports_op,
 	.exec_op = nxp_fspi_exec_op,
 	.get_name = nxp_fspi_get_name,
+	.caps = &spi_mem_no_caps,
 };
 
 static int nxp_fspi_probe(struct platform_device *pdev)
diff --git a/drivers/spi/spi-rockchip-sfc.c b/drivers/spi/spi-rockchip-sfc.c
index a46b38544027..9f3f748fc724 100644
--- a/drivers/spi/spi-rockchip-sfc.c
+++ b/drivers/spi/spi-rockchip-sfc.c
@@ -533,6 +533,7 @@ static int rockchip_sfc_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *o
 static const struct spi_controller_mem_ops rockchip_sfc_mem_ops = {
 	.exec_op = rockchip_sfc_exec_mem_op,
 	.adjust_op_size = rockchip_sfc_adjust_op_size,
+	.caps = &spi_mem_no_caps,
 };
 
 static irqreturn_t rockchip_sfc_irq_handler(int irq, void *dev_id)
diff --git a/drivers/spi/spi-rpc-if.c b/drivers/spi/spi-rpc-if.c
index c53138ce0030..2317de928bbd 100644
--- a/drivers/spi/spi-rpc-if.c
+++ b/drivers/spi/spi-rpc-if.c
@@ -125,6 +125,7 @@ static const struct spi_controller_mem_ops rpcif_spi_mem_ops = {
 	.exec_op	= rpcif_spi_mem_exec_op,
 	.dirmap_create	= rpcif_spi_mem_dirmap_create,
 	.dirmap_read	= rpcif_spi_mem_dirmap_read,
+	.caps		= &spi_mem_no_caps,
 };
 
 static int rpcif_spi_probe(struct platform_device *pdev)
diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index 27f35aa2d746..163abc0eae05 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -677,6 +677,7 @@ static const struct spi_controller_mem_ops stm32_qspi_mem_ops = {
 	.dirmap_create	= stm32_qspi_dirmap_create,
 	.dirmap_read	= stm32_qspi_dirmap_read,
 	.poll_status	= stm32_qspi_poll_status,
+	.caps		= &spi_mem_no_caps,
 };
 
 static int stm32_qspi_probe(struct platform_device *pdev)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index e06aafe169e0..062dd834d837 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -655,6 +655,7 @@ static int ti_qspi_exec_mem_op(struct spi_mem *mem,
 static const struct spi_controller_mem_ops ti_qspi_mem_ops = {
 	.exec_op = ti_qspi_exec_mem_op,
 	.adjust_op_size = ti_qspi_adjust_op_size,
+	.caps = &spi_mem_no_caps,
 };
 
 static int ti_qspi_start_transfer_one(struct spi_master *master,
diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
index cfa222c9bd5e..2f8b2bc94e63 100644
--- a/drivers/spi/spi-zynq-qspi.c
+++ b/drivers/spi/spi-zynq-qspi.c
@@ -615,6 +615,7 @@ static int zynq_qspi_exec_mem_op(struct spi_mem *mem,
 static const struct spi_controller_mem_ops zynq_qspi_mem_ops = {
 	.supports_op = zynq_qspi_supports_op,
 	.exec_op = zynq_qspi_exec_mem_op,
+	.caps = &spi_mem_no_caps,
 };
 
 /**
diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 328b6559bb19..f7e53d4aabd2 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -1082,6 +1082,7 @@ static const struct dev_pm_ops zynqmp_qspi_dev_pm_ops = {
 
 static const struct spi_controller_mem_ops zynqmp_qspi_mem_ops = {
 	.exec_op = zynqmp_qspi_exec_op,
+	.caps = &spi_mem_no_caps,
 };
 
 /**
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 57e2499ec1ed..58c5cb985431 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2747,6 +2747,9 @@ static int spi_controller_check_ops(struct spi_controller *ctlr)
 	if (ctlr->mem_ops) {
 		if (!ctlr->mem_ops->exec_op)
 			return -EINVAL;
+
+		if (!ctlr->mem_ops->caps)
+			return -EINVAL;
 	} else if (!ctlr->transfer && !ctlr->transfer_one &&
 		   !ctlr->transfer_one_message) {
 		return -EINVAL;
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 42f3850610b5..5f728f3113bd 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -366,6 +366,7 @@ bool spi_mem_dtr_supports_op(struct spi_mem *mem,
 
 int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op);
 
+const struct spi_controller_mem_caps spi_mem_no_caps;
 bool spi_mem_supports_op(struct spi_mem *mem,
 			 const struct spi_mem_op *op);
 
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Update all the spi controller drivers registering spi-mem operations to
provide a spi-mem capabilities structure.

For most of them, it is just a matter of referencing the newly created
spi_mem_no_caps empty structure. Only Cadence and Macronix SPI
controller drivers support DTR operations, so these two need to define
a non-empty set of capabilities.

Prevent any new controller to register a set of spi-mem operations
without a capabilities structure.

So far these capabilities are not used by the core, this is just a
preparation change.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/spi/atmel-quadspi.c       | 3 ++-
 drivers/spi/spi-bcm-qspi.c        | 1 +
 drivers/spi/spi-cadence-quadspi.c | 5 +++++
 drivers/spi/spi-dw-core.c         | 1 +
 drivers/spi/spi-fsl-qspi.c        | 1 +
 drivers/spi/spi-hisi-sfc-v3xx.c   | 1 +
 drivers/spi/spi-mem.c             | 3 +++
 drivers/spi/spi-mtk-nor.c         | 3 ++-
 drivers/spi/spi-mxic.c            | 5 +++++
 drivers/spi/spi-npcm-fiu.c        | 1 +
 drivers/spi/spi-nxp-fspi.c        | 1 +
 drivers/spi/spi-rockchip-sfc.c    | 1 +
 drivers/spi/spi-rpc-if.c          | 1 +
 drivers/spi/spi-stm32-qspi.c      | 1 +
 drivers/spi/spi-ti-qspi.c         | 1 +
 drivers/spi/spi-zynq-qspi.c       | 1 +
 drivers/spi/spi-zynqmp-gqspi.c    | 1 +
 drivers/spi/spi.c                 | 3 +++
 include/linux/spi/spi-mem.h       | 1 +
 19 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
index 95d4fa32c299..7d43ed8d124d 100644
--- a/drivers/spi/atmel-quadspi.c
+++ b/drivers/spi/atmel-quadspi.c
@@ -466,7 +466,8 @@ static const char *atmel_qspi_get_name(struct spi_mem *spimem)
 static const struct spi_controller_mem_ops atmel_qspi_mem_ops = {
 	.supports_op = atmel_qspi_supports_op,
 	.exec_op = atmel_qspi_exec_op,
-	.get_name = atmel_qspi_get_name
+	.get_name = atmel_qspi_get_name,
+	.caps = &spi_mem_no_caps,
 };
 
 static int atmel_qspi_setup(struct spi_device *spi)
diff --git a/drivers/spi/spi-bcm-qspi.c b/drivers/spi/spi-bcm-qspi.c
index a78e56f566dd..c43d46ea2534 100644
--- a/drivers/spi/spi-bcm-qspi.c
+++ b/drivers/spi/spi-bcm-qspi.c
@@ -1258,6 +1258,7 @@ static void bcm_qspi_hw_uninit(struct bcm_qspi *qspi)
 
 static const struct spi_controller_mem_ops bcm_qspi_mem_ops = {
 	.exec_op = bcm_qspi_exec_mem_op,
+	.caps = &spi_mem_no_caps,
 };
 
 struct bcm_qspi_data {
diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 101cc71bffa7..0622c7db52e6 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1388,10 +1388,15 @@ static const char *cqspi_get_name(struct spi_mem *mem)
 	return devm_kasprintf(dev, GFP_KERNEL, "%s.%d", dev_name(dev), mem->spi->chip_select);
 }
 
+const struct spi_controller_mem_caps cqspi_mem_caps = {
+	.dtr = true,
+};
+
 static const struct spi_controller_mem_ops cqspi_mem_ops = {
 	.exec_op = cqspi_exec_mem_op,
 	.get_name = cqspi_get_name,
 	.supports_op = cqspi_supports_mem_op,
+	.caps = &cqspi_mem_caps,
 };
 
 static int cqspi_setup_flash(struct cqspi_st *cqspi)
diff --git a/drivers/spi/spi-dw-core.c b/drivers/spi/spi-dw-core.c
index a305074c482e..896e299a8c51 100644
--- a/drivers/spi/spi-dw-core.c
+++ b/drivers/spi/spi-dw-core.c
@@ -759,6 +759,7 @@ static void dw_spi_init_mem_ops(struct dw_spi *dws)
 		dws->mem_ops.adjust_op_size = dw_spi_adjust_mem_op_size;
 		dws->mem_ops.supports_op = dw_spi_supports_mem_op;
 		dws->mem_ops.exec_op = dw_spi_exec_mem_op;
+		dws->mem_ops.caps = &spi_mem_no_caps;
 		if (!dws->max_mem_freq)
 			dws->max_mem_freq = dws->max_freq;
 	}
diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c
index 9851551ebbe0..420d6d77c989 100644
--- a/drivers/spi/spi-fsl-qspi.c
+++ b/drivers/spi/spi-fsl-qspi.c
@@ -838,6 +838,7 @@ static const struct spi_controller_mem_ops fsl_qspi_mem_ops = {
 	.supports_op = fsl_qspi_supports_op,
 	.exec_op = fsl_qspi_exec_op,
 	.get_name = fsl_qspi_get_name,
+	.caps = &spi_mem_no_caps,
 };
 
 static int fsl_qspi_probe(struct platform_device *pdev)
diff --git a/drivers/spi/spi-hisi-sfc-v3xx.c b/drivers/spi/spi-hisi-sfc-v3xx.c
index d3a23b1c2a4c..88eb061b7eb7 100644
--- a/drivers/spi/spi-hisi-sfc-v3xx.c
+++ b/drivers/spi/spi-hisi-sfc-v3xx.c
@@ -372,6 +372,7 @@ static const struct spi_controller_mem_ops hisi_sfc_v3xx_mem_ops = {
 	.adjust_op_size = hisi_sfc_v3xx_adjust_op_size,
 	.supports_op = hisi_sfc_v3xx_supports_op,
 	.exec_op = hisi_sfc_v3xx_exec_op,
+	.caps = &spi_mem_no_caps,
 };
 
 static irqreturn_t hisi_sfc_v3xx_isr(int irq, void *data)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index c4da0c9b05e9..bfd5c6b2db0a 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -160,6 +160,9 @@ static bool spi_mem_check_buswidth(struct spi_mem *mem,
 	return true;
 }
 
+const struct spi_controller_mem_caps spi_mem_no_caps = {};
+EXPORT_SYMBOL_GPL(spi_mem_no_caps);
+
 bool spi_mem_dtr_supports_op(struct spi_mem *mem,
 			     const struct spi_mem_op *op)
 {
diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
index 41e7b341d261..444b36d94c6d 100644
--- a/drivers/spi/spi-mtk-nor.c
+++ b/drivers/spi/spi-mtk-nor.c
@@ -740,7 +740,8 @@ static size_t mtk_max_msg_size(struct spi_device *spi)
 static const struct spi_controller_mem_ops mtk_nor_mem_ops = {
 	.adjust_op_size = mtk_nor_adjust_op_size,
 	.supports_op = mtk_nor_supports_op,
-	.exec_op = mtk_nor_exec_op
+	.exec_op = mtk_nor_exec_op,
+	.caps = &spi_mem_no_caps,
 };
 
 static const struct of_device_id mtk_nor_match[] = {
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 45889947afed..8f8530bd3779 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -443,9 +443,14 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 	return ret;
 }
 
+const struct spi_controller_mem_caps mxic_spi_mem_caps = {
+	.dtr = true,
+};
+
 static const struct spi_controller_mem_ops mxic_spi_mem_ops = {
 	.supports_op = mxic_spi_mem_supports_op,
 	.exec_op = mxic_spi_mem_exec_op,
+	.caps = &mxic_spi_mem_caps,
 };
 
 static void mxic_spi_set_cs(struct spi_device *spi, bool lvl)
diff --git a/drivers/spi/spi-npcm-fiu.c b/drivers/spi/spi-npcm-fiu.c
index b62471ab6d7f..fc90180412e3 100644
--- a/drivers/spi/spi-npcm-fiu.c
+++ b/drivers/spi/spi-npcm-fiu.c
@@ -661,6 +661,7 @@ static const struct spi_controller_mem_ops npcm_fiu_mem_ops = {
 	.dirmap_create = npcm_fiu_dirmap_create,
 	.dirmap_read = npcm_fiu_direct_read,
 	.dirmap_write = npcm_fiu_direct_write,
+	.caps = &spi_mem_no_caps,
 };
 
 static const struct of_device_id npcm_fiu_dt_ids[] = {
diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
index a66fa97046ee..bca0ccc20865 100644
--- a/drivers/spi/spi-nxp-fspi.c
+++ b/drivers/spi/spi-nxp-fspi.c
@@ -1082,6 +1082,7 @@ static const struct spi_controller_mem_ops nxp_fspi_mem_ops = {
 	.supports_op = nxp_fspi_supports_op,
 	.exec_op = nxp_fspi_exec_op,
 	.get_name = nxp_fspi_get_name,
+	.caps = &spi_mem_no_caps,
 };
 
 static int nxp_fspi_probe(struct platform_device *pdev)
diff --git a/drivers/spi/spi-rockchip-sfc.c b/drivers/spi/spi-rockchip-sfc.c
index a46b38544027..9f3f748fc724 100644
--- a/drivers/spi/spi-rockchip-sfc.c
+++ b/drivers/spi/spi-rockchip-sfc.c
@@ -533,6 +533,7 @@ static int rockchip_sfc_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *o
 static const struct spi_controller_mem_ops rockchip_sfc_mem_ops = {
 	.exec_op = rockchip_sfc_exec_mem_op,
 	.adjust_op_size = rockchip_sfc_adjust_op_size,
+	.caps = &spi_mem_no_caps,
 };
 
 static irqreturn_t rockchip_sfc_irq_handler(int irq, void *dev_id)
diff --git a/drivers/spi/spi-rpc-if.c b/drivers/spi/spi-rpc-if.c
index c53138ce0030..2317de928bbd 100644
--- a/drivers/spi/spi-rpc-if.c
+++ b/drivers/spi/spi-rpc-if.c
@@ -125,6 +125,7 @@ static const struct spi_controller_mem_ops rpcif_spi_mem_ops = {
 	.exec_op	= rpcif_spi_mem_exec_op,
 	.dirmap_create	= rpcif_spi_mem_dirmap_create,
 	.dirmap_read	= rpcif_spi_mem_dirmap_read,
+	.caps		= &spi_mem_no_caps,
 };
 
 static int rpcif_spi_probe(struct platform_device *pdev)
diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index 27f35aa2d746..163abc0eae05 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -677,6 +677,7 @@ static const struct spi_controller_mem_ops stm32_qspi_mem_ops = {
 	.dirmap_create	= stm32_qspi_dirmap_create,
 	.dirmap_read	= stm32_qspi_dirmap_read,
 	.poll_status	= stm32_qspi_poll_status,
+	.caps		= &spi_mem_no_caps,
 };
 
 static int stm32_qspi_probe(struct platform_device *pdev)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index e06aafe169e0..062dd834d837 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -655,6 +655,7 @@ static int ti_qspi_exec_mem_op(struct spi_mem *mem,
 static const struct spi_controller_mem_ops ti_qspi_mem_ops = {
 	.exec_op = ti_qspi_exec_mem_op,
 	.adjust_op_size = ti_qspi_adjust_op_size,
+	.caps = &spi_mem_no_caps,
 };
 
 static int ti_qspi_start_transfer_one(struct spi_master *master,
diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
index cfa222c9bd5e..2f8b2bc94e63 100644
--- a/drivers/spi/spi-zynq-qspi.c
+++ b/drivers/spi/spi-zynq-qspi.c
@@ -615,6 +615,7 @@ static int zynq_qspi_exec_mem_op(struct spi_mem *mem,
 static const struct spi_controller_mem_ops zynq_qspi_mem_ops = {
 	.supports_op = zynq_qspi_supports_op,
 	.exec_op = zynq_qspi_exec_mem_op,
+	.caps = &spi_mem_no_caps,
 };
 
 /**
diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 328b6559bb19..f7e53d4aabd2 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -1082,6 +1082,7 @@ static const struct dev_pm_ops zynqmp_qspi_dev_pm_ops = {
 
 static const struct spi_controller_mem_ops zynqmp_qspi_mem_ops = {
 	.exec_op = zynqmp_qspi_exec_op,
+	.caps = &spi_mem_no_caps,
 };
 
 /**
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 57e2499ec1ed..58c5cb985431 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2747,6 +2747,9 @@ static int spi_controller_check_ops(struct spi_controller *ctlr)
 	if (ctlr->mem_ops) {
 		if (!ctlr->mem_ops->exec_op)
 			return -EINVAL;
+
+		if (!ctlr->mem_ops->caps)
+			return -EINVAL;
 	} else if (!ctlr->transfer && !ctlr->transfer_one &&
 		   !ctlr->transfer_one_message) {
 		return -EINVAL;
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 42f3850610b5..5f728f3113bd 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -366,6 +366,7 @@ bool spi_mem_dtr_supports_op(struct spi_mem *mem,
 
 int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op);
 
+const struct spi_controller_mem_caps spi_mem_no_caps;
 bool spi_mem_supports_op(struct spi_mem *mem,
 			 const struct spi_mem_op *op);
 
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 21/28] spi: spi-mem: Kill the spi_mem_dtr_supports_op() helper
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Now that spi_mem_default_supports_op() has access to the static
controller capabilities (related to memory operations), let's use this
new information in order to derive if the operation is supported or
not by the controller. This way, there is no need for the
spi_mem_dtr_supports_op() helper anymore.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/spi/spi-cadence-quadspi.c |  5 +----
 drivers/spi/spi-mem.c             | 27 +++++++++++++--------------
 drivers/spi/spi-mxic.c            | 10 +---------
 include/linux/spi/spi-mem.h       | 11 -----------
 4 files changed, 15 insertions(+), 38 deletions(-)

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 0622c7db52e6..24198e085011 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1252,10 +1252,7 @@ static bool cqspi_supports_mem_op(struct spi_mem *mem,
 	if (!(all_true || all_false))
 		return false;
 
-	if (all_true)
-		return spi_mem_dtr_supports_op(mem, op);
-	else
-		return spi_mem_default_supports_op(mem, op);
+	return spi_mem_default_supports_op(mem, op);
 }
 
 static int cqspi_of_get_flash_pdata(struct platform_device *pdev,
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index bfd5c6b2db0a..aae1bc655299 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -163,24 +163,23 @@ static bool spi_mem_check_buswidth(struct spi_mem *mem,
 const struct spi_controller_mem_caps spi_mem_no_caps = {};
 EXPORT_SYMBOL_GPL(spi_mem_no_caps);
 
-bool spi_mem_dtr_supports_op(struct spi_mem *mem,
-			     const struct spi_mem_op *op)
-{
-	if (op->cmd.dtr && op->cmd.nbytes != 2)
-		return false;
-
-	return spi_mem_check_buswidth(mem, op);
-}
-EXPORT_SYMBOL_GPL(spi_mem_dtr_supports_op);
-
 bool spi_mem_default_supports_op(struct spi_mem *mem,
 				 const struct spi_mem_op *op)
 {
-	if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
-		return false;
+	struct spi_controller *ctlr = mem->spi->controller;
+	bool op_is_dtr =
+		op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr;
 
-	if (op->cmd.nbytes != 1)
-		return false;
+	if (op_is_dtr) {
+		if (!ctlr->mem_ops->caps->dtr)
+			return false;
+
+		if (op->cmd.dtr && op->cmd.nbytes != 2)
+			return false;
+	} else {
+		if (op->cmd.nbytes != 1)
+			return false;
+	}
 
 	return spi_mem_check_buswidth(mem, op);
 }
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 8f8530bd3779..8c8c929c87b5 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -335,8 +335,6 @@ static int mxic_spi_data_xfer(struct mxic_spi *mxic, const void *txbuf,
 static bool mxic_spi_mem_supports_op(struct spi_mem *mem,
 				     const struct spi_mem_op *op)
 {
-	bool all_false;
-
 	if (op->data.buswidth > 8 || op->addr.buswidth > 8 ||
 	    op->dummy.buswidth > 8 || op->cmd.buswidth > 8)
 		return false;
@@ -348,13 +346,7 @@ static bool mxic_spi_mem_supports_op(struct spi_mem *mem,
 	if (op->addr.nbytes > 7)
 		return false;
 
-	all_false = !op->cmd.dtr && !op->addr.dtr && !op->dummy.dtr &&
-		    !op->data.dtr;
-
-	if (all_false)
-		return spi_mem_default_supports_op(mem, op);
-	else
-		return spi_mem_dtr_supports_op(mem, op);
+	return spi_mem_default_supports_op(mem, op);
 }
 
 static int mxic_spi_mem_exec_op(struct spi_mem *mem,
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 5f728f3113bd..b413c8667af7 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -329,10 +329,6 @@ void spi_controller_dma_unmap_mem_op_data(struct spi_controller *ctlr,
 
 bool spi_mem_default_supports_op(struct spi_mem *mem,
 				 const struct spi_mem_op *op);
-
-bool spi_mem_dtr_supports_op(struct spi_mem *mem,
-			     const struct spi_mem_op *op);
-
 #else
 static inline int
 spi_controller_dma_map_mem_op_data(struct spi_controller *ctlr,
@@ -355,13 +351,6 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,
 {
 	return false;
 }
-
-static inline
-bool spi_mem_dtr_supports_op(struct spi_mem *mem,
-			     const struct spi_mem_op *op)
-{
-	return false;
-}
 #endif /* CONFIG_SPI_MEM */
 
 int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op);
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 21/28] spi: spi-mem: Kill the spi_mem_dtr_supports_op() helper
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Now that spi_mem_default_supports_op() has access to the static
controller capabilities (related to memory operations), let's use this
new information in order to derive if the operation is supported or
not by the controller. This way, there is no need for the
spi_mem_dtr_supports_op() helper anymore.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/spi/spi-cadence-quadspi.c |  5 +----
 drivers/spi/spi-mem.c             | 27 +++++++++++++--------------
 drivers/spi/spi-mxic.c            | 10 +---------
 include/linux/spi/spi-mem.h       | 11 -----------
 4 files changed, 15 insertions(+), 38 deletions(-)

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 0622c7db52e6..24198e085011 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1252,10 +1252,7 @@ static bool cqspi_supports_mem_op(struct spi_mem *mem,
 	if (!(all_true || all_false))
 		return false;
 
-	if (all_true)
-		return spi_mem_dtr_supports_op(mem, op);
-	else
-		return spi_mem_default_supports_op(mem, op);
+	return spi_mem_default_supports_op(mem, op);
 }
 
 static int cqspi_of_get_flash_pdata(struct platform_device *pdev,
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index bfd5c6b2db0a..aae1bc655299 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -163,24 +163,23 @@ static bool spi_mem_check_buswidth(struct spi_mem *mem,
 const struct spi_controller_mem_caps spi_mem_no_caps = {};
 EXPORT_SYMBOL_GPL(spi_mem_no_caps);
 
-bool spi_mem_dtr_supports_op(struct spi_mem *mem,
-			     const struct spi_mem_op *op)
-{
-	if (op->cmd.dtr && op->cmd.nbytes != 2)
-		return false;
-
-	return spi_mem_check_buswidth(mem, op);
-}
-EXPORT_SYMBOL_GPL(spi_mem_dtr_supports_op);
-
 bool spi_mem_default_supports_op(struct spi_mem *mem,
 				 const struct spi_mem_op *op)
 {
-	if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
-		return false;
+	struct spi_controller *ctlr = mem->spi->controller;
+	bool op_is_dtr =
+		op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr;
 
-	if (op->cmd.nbytes != 1)
-		return false;
+	if (op_is_dtr) {
+		if (!ctlr->mem_ops->caps->dtr)
+			return false;
+
+		if (op->cmd.dtr && op->cmd.nbytes != 2)
+			return false;
+	} else {
+		if (op->cmd.nbytes != 1)
+			return false;
+	}
 
 	return spi_mem_check_buswidth(mem, op);
 }
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 8f8530bd3779..8c8c929c87b5 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -335,8 +335,6 @@ static int mxic_spi_data_xfer(struct mxic_spi *mxic, const void *txbuf,
 static bool mxic_spi_mem_supports_op(struct spi_mem *mem,
 				     const struct spi_mem_op *op)
 {
-	bool all_false;
-
 	if (op->data.buswidth > 8 || op->addr.buswidth > 8 ||
 	    op->dummy.buswidth > 8 || op->cmd.buswidth > 8)
 		return false;
@@ -348,13 +346,7 @@ static bool mxic_spi_mem_supports_op(struct spi_mem *mem,
 	if (op->addr.nbytes > 7)
 		return false;
 
-	all_false = !op->cmd.dtr && !op->addr.dtr && !op->dummy.dtr &&
-		    !op->data.dtr;
-
-	if (all_false)
-		return spi_mem_default_supports_op(mem, op);
-	else
-		return spi_mem_dtr_supports_op(mem, op);
+	return spi_mem_default_supports_op(mem, op);
 }
 
 static int mxic_spi_mem_exec_op(struct spi_mem *mem,
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 5f728f3113bd..b413c8667af7 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -329,10 +329,6 @@ void spi_controller_dma_unmap_mem_op_data(struct spi_controller *ctlr,
 
 bool spi_mem_default_supports_op(struct spi_mem *mem,
 				 const struct spi_mem_op *op);
-
-bool spi_mem_dtr_supports_op(struct spi_mem *mem,
-			     const struct spi_mem_op *op);
-
 #else
 static inline int
 spi_controller_dma_map_mem_op_data(struct spi_controller *ctlr,
@@ -355,13 +351,6 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,
 {
 	return false;
 }
-
-static inline
-bool spi_mem_dtr_supports_op(struct spi_mem *mem,
-			     const struct spi_mem_op *op)
-{
-	return false;
-}
 #endif /* CONFIG_SPI_MEM */
 
 int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op);
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 22/28] spi: spi-mem: Add an ecc_en parameter to the spi_mem_op structure
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Soon the SPI-NAND core will need a way to request a SPI controller to
enable ECC support for a given operation. This is because of the
pipelined integration of certain ECC engines, which are directly managed
by the SPI controller itself.

Introduce a spi_mem_op additional field for this purpose: ecc_en.

So far this field is left unset and checked to be false by all
the SPI controller drivers in their ->supports_op() hook, as they all
call spi_mem_default_supports_op().

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/spi/spi-mem.c       | 5 +++++
 include/linux/spi/spi-mem.h | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index aae1bc655299..e1c912c811a0 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -181,6 +181,11 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,
 			return false;
 	}
 
+	if (op->ecc_en) {
+		if (!ctlr->mem_ops->caps->ecc)
+			return false;
+	}
+
 	return spi_mem_check_buswidth(mem, op);
 }
 EXPORT_SYMBOL_GPL(spi_mem_default_supports_op);
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index b413c8667af7..4fee978dc1b9 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -94,6 +94,7 @@ enum spi_mem_data_dir {
  *		 operation does not involve transferring data
  * @data.buf.in: input buffer (must be DMA-able)
  * @data.buf.out: output buffer (must be DMA-able)
+ * @ecc_en: error correction is required
  */
 struct spi_mem_op {
 	struct {
@@ -126,6 +127,8 @@ struct spi_mem_op {
 			const void *out;
 		} buf;
 	} data;
+
+	bool ecc_en;
 };
 
 #define SPI_MEM_OP(__cmd, __addr, __dummy, __data)		\
@@ -223,9 +226,11 @@ static inline void *spi_mem_get_drvdata(struct spi_mem *mem)
 /**
  * struct spi_controller_mem_caps - SPI memory controller capabilities
  * @dtr: Supports DTR operations
+ * @ecc: Supports operations with error correction
  */
 struct spi_controller_mem_caps {
 	bool dtr;
+	bool ecc;
 };
 
 /**
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 22/28] spi: spi-mem: Add an ecc_en parameter to the spi_mem_op structure
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Soon the SPI-NAND core will need a way to request a SPI controller to
enable ECC support for a given operation. This is because of the
pipelined integration of certain ECC engines, which are directly managed
by the SPI controller itself.

Introduce a spi_mem_op additional field for this purpose: ecc_en.

So far this field is left unset and checked to be false by all
the SPI controller drivers in their ->supports_op() hook, as they all
call spi_mem_default_supports_op().

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/spi/spi-mem.c       | 5 +++++
 include/linux/spi/spi-mem.h | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index aae1bc655299..e1c912c811a0 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -181,6 +181,11 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,
 			return false;
 	}
 
+	if (op->ecc_en) {
+		if (!ctlr->mem_ops->caps->ecc)
+			return false;
+	}
+
 	return spi_mem_check_buswidth(mem, op);
 }
 EXPORT_SYMBOL_GPL(spi_mem_default_supports_op);
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index b413c8667af7..4fee978dc1b9 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -94,6 +94,7 @@ enum spi_mem_data_dir {
  *		 operation does not involve transferring data
  * @data.buf.in: input buffer (must be DMA-able)
  * @data.buf.out: output buffer (must be DMA-able)
+ * @ecc_en: error correction is required
  */
 struct spi_mem_op {
 	struct {
@@ -126,6 +127,8 @@ struct spi_mem_op {
 			const void *out;
 		} buf;
 	} data;
+
+	bool ecc_en;
 };
 
 #define SPI_MEM_OP(__cmd, __addr, __dummy, __data)		\
@@ -223,9 +226,11 @@ static inline void *spi_mem_get_drvdata(struct spi_mem *mem)
 /**
  * struct spi_controller_mem_caps - SPI memory controller capabilities
  * @dtr: Supports DTR operations
+ * @ecc: Supports operations with error correction
  */
 struct spi_controller_mem_caps {
 	bool dtr;
+	bool ecc;
 };
 
 /**
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 23/28] mtd: spinand: Create direct mapping descriptors for ECC operations
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

In order for pipelined ECC engines to be able to enable/disable the ECC
engine only when needed and avoid races when future parallel-operations
will be supported, we need to provide the information about the use of
the ECC engine in the direct mapping hooks. As direct mapping
configurations are meant to be static, it is best to create two new
mappings: one for regular 'raw' accesses and one for accesses involving
correction. It is up to the driver to use or not the new ECC enable
boolean contained in the spi-mem operation.

As dirmaps are not free (they consume a few pages of MMIO address space)
and because these extra entries are only meant to be used by pipelined
engines, let's limit their use to this specific type of engine and save
a bit of memory with all the other setups.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/spi/core.c | 35 +++++++++++++++++++++++++++++++++--
 include/linux/mtd/spinand.h |  2 ++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 715cad26fdef..eb999e47e978 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -381,7 +381,10 @@ static int spinand_read_from_cache_op(struct spinand_device *spinand,
 		}
 	}
 
-	rdesc = spinand->dirmaps[req->pos.plane].rdesc;
+	if (req->mode == MTD_OPS_RAW)
+		rdesc = spinand->dirmaps[req->pos.plane].rdesc;
+	else
+		rdesc = spinand->dirmaps[req->pos.plane].rdesc_ecc;
 
 	while (nbytes) {
 		ret = spi_mem_dirmap_read(rdesc, column, nbytes, buf);
@@ -452,7 +455,10 @@ static int spinand_write_to_cache_op(struct spinand_device *spinand,
 			       req->ooblen);
 	}
 
-	wdesc = spinand->dirmaps[req->pos.plane].wdesc;
+	if (req->mode == MTD_OPS_RAW)
+		wdesc = spinand->dirmaps[req->pos.plane].wdesc;
+	else
+		wdesc = spinand->dirmaps[req->pos.plane].wdesc_ecc;
 
 	while (nbytes) {
 		ret = spi_mem_dirmap_write(wdesc, column, nbytes, buf);
@@ -866,6 +872,31 @@ static int spinand_create_dirmap(struct spinand_device *spinand,
 
 	spinand->dirmaps[plane].rdesc = desc;
 
+	if (nand->ecc.engine->integration != NAND_ECC_ENGINE_INTEGRATION_PIPELINED) {
+		spinand->dirmaps[plane].wdesc_ecc = spinand->dirmaps[plane].wdesc;
+		spinand->dirmaps[plane].rdesc_ecc = spinand->dirmaps[plane].rdesc;
+
+		return 0;
+	}
+
+	info.op_tmpl = *spinand->op_templates.update_cache;
+	info.op_tmpl.ecc_en = true;
+	desc = devm_spi_mem_dirmap_create(&spinand->spimem->spi->dev,
+					  spinand->spimem, &info);
+	if (IS_ERR(desc))
+		return PTR_ERR(desc);
+
+	spinand->dirmaps[plane].wdesc_ecc = desc;
+
+	info.op_tmpl = *spinand->op_templates.read_cache;
+	info.op_tmpl.ecc_en = true;
+	desc = devm_spi_mem_dirmap_create(&spinand->spimem->spi->dev,
+					  spinand->spimem, &info);
+	if (IS_ERR(desc))
+		return PTR_ERR(desc);
+
+	spinand->dirmaps[plane].rdesc_ecc = desc;
+
 	return 0;
 }
 
diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
index 6988956b8492..3aa28240a77f 100644
--- a/include/linux/mtd/spinand.h
+++ b/include/linux/mtd/spinand.h
@@ -389,6 +389,8 @@ struct spinand_info {
 struct spinand_dirmap {
 	struct spi_mem_dirmap_desc *wdesc;
 	struct spi_mem_dirmap_desc *rdesc;
+	struct spi_mem_dirmap_desc *wdesc_ecc;
+	struct spi_mem_dirmap_desc *rdesc_ecc;
 };
 
 /**
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 23/28] mtd: spinand: Create direct mapping descriptors for ECC operations
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

In order for pipelined ECC engines to be able to enable/disable the ECC
engine only when needed and avoid races when future parallel-operations
will be supported, we need to provide the information about the use of
the ECC engine in the direct mapping hooks. As direct mapping
configurations are meant to be static, it is best to create two new
mappings: one for regular 'raw' accesses and one for accesses involving
correction. It is up to the driver to use or not the new ECC enable
boolean contained in the spi-mem operation.

As dirmaps are not free (they consume a few pages of MMIO address space)
and because these extra entries are only meant to be used by pipelined
engines, let's limit their use to this specific type of engine and save
a bit of memory with all the other setups.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/spi/core.c | 35 +++++++++++++++++++++++++++++++++--
 include/linux/mtd/spinand.h |  2 ++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 715cad26fdef..eb999e47e978 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -381,7 +381,10 @@ static int spinand_read_from_cache_op(struct spinand_device *spinand,
 		}
 	}
 
-	rdesc = spinand->dirmaps[req->pos.plane].rdesc;
+	if (req->mode == MTD_OPS_RAW)
+		rdesc = spinand->dirmaps[req->pos.plane].rdesc;
+	else
+		rdesc = spinand->dirmaps[req->pos.plane].rdesc_ecc;
 
 	while (nbytes) {
 		ret = spi_mem_dirmap_read(rdesc, column, nbytes, buf);
@@ -452,7 +455,10 @@ static int spinand_write_to_cache_op(struct spinand_device *spinand,
 			       req->ooblen);
 	}
 
-	wdesc = spinand->dirmaps[req->pos.plane].wdesc;
+	if (req->mode == MTD_OPS_RAW)
+		wdesc = spinand->dirmaps[req->pos.plane].wdesc;
+	else
+		wdesc = spinand->dirmaps[req->pos.plane].wdesc_ecc;
 
 	while (nbytes) {
 		ret = spi_mem_dirmap_write(wdesc, column, nbytes, buf);
@@ -866,6 +872,31 @@ static int spinand_create_dirmap(struct spinand_device *spinand,
 
 	spinand->dirmaps[plane].rdesc = desc;
 
+	if (nand->ecc.engine->integration != NAND_ECC_ENGINE_INTEGRATION_PIPELINED) {
+		spinand->dirmaps[plane].wdesc_ecc = spinand->dirmaps[plane].wdesc;
+		spinand->dirmaps[plane].rdesc_ecc = spinand->dirmaps[plane].rdesc;
+
+		return 0;
+	}
+
+	info.op_tmpl = *spinand->op_templates.update_cache;
+	info.op_tmpl.ecc_en = true;
+	desc = devm_spi_mem_dirmap_create(&spinand->spimem->spi->dev,
+					  spinand->spimem, &info);
+	if (IS_ERR(desc))
+		return PTR_ERR(desc);
+
+	spinand->dirmaps[plane].wdesc_ecc = desc;
+
+	info.op_tmpl = *spinand->op_templates.read_cache;
+	info.op_tmpl.ecc_en = true;
+	desc = devm_spi_mem_dirmap_create(&spinand->spimem->spi->dev,
+					  spinand->spimem, &info);
+	if (IS_ERR(desc))
+		return PTR_ERR(desc);
+
+	spinand->dirmaps[plane].rdesc_ecc = desc;
+
 	return 0;
 }
 
diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
index 6988956b8492..3aa28240a77f 100644
--- a/include/linux/mtd/spinand.h
+++ b/include/linux/mtd/spinand.h
@@ -389,6 +389,8 @@ struct spinand_info {
 struct spinand_dirmap {
 	struct spi_mem_dirmap_desc *wdesc;
 	struct spi_mem_dirmap_desc *rdesc;
+	struct spi_mem_dirmap_desc *wdesc_ecc;
+	struct spi_mem_dirmap_desc *rdesc_ecc;
 };
 
 /**
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 24/28] spi: mxic: Fix the transmit path
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, stable,
	Mason Yang, Zhengxun Li

By working with external hardware ECC engines, we figured out that
Under certain circumstances, it is needed for the SPI controller to
check INT_TX_EMPTY and INT_RX_NOT_EMPTY in both receive and transmit
path (not only in the receive path). The delay penalty being
negligible, move this code in the common path.

Fixes: b942d80b0a39 ("spi: Add MXIC controller driver")
Cc: stable@vger.kernel.org
Suggested-by: Mason Yang <masonccyang@mxic.com.tw>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Zhengxun Li <zhengxunli@mxic.com.tw>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-mxic.c | 28 ++++++++++++----------------
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 8c8c929c87b5..3d6561a3ff8b 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -304,25 +304,21 @@ static int mxic_spi_data_xfer(struct mxic_spi *mxic, const void *txbuf,
 
 		writel(data, mxic->regs + TXD(nbytes % 4));
 
+		ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
+					 sts & INT_TX_EMPTY, 0, USEC_PER_SEC);
+		if (ret)
+			return ret;
+
+		ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
+					 sts & INT_RX_NOT_EMPTY, 0,
+					 USEC_PER_SEC);
+		if (ret)
+			return ret;
+
+		data = readl(mxic->regs + RXD);
 		if (rxbuf) {
-			ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
-						 sts & INT_TX_EMPTY, 0,
-						 USEC_PER_SEC);
-			if (ret)
-				return ret;
-
-			ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
-						 sts & INT_RX_NOT_EMPTY, 0,
-						 USEC_PER_SEC);
-			if (ret)
-				return ret;
-
-			data = readl(mxic->regs + RXD);
 			data >>= (8 * (4 - nbytes));
 			memcpy(rxbuf + pos, &data, nbytes);
-			WARN_ON(readl(mxic->regs + INT_STS) & INT_RX_NOT_EMPTY);
-		} else {
-			readl(mxic->regs + RXD);
 		}
 		WARN_ON(readl(mxic->regs + INT_STS) & INT_RX_NOT_EMPTY);
 
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 24/28] spi: mxic: Fix the transmit path
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, stable,
	Mason Yang, Zhengxun Li

By working with external hardware ECC engines, we figured out that
Under certain circumstances, it is needed for the SPI controller to
check INT_TX_EMPTY and INT_RX_NOT_EMPTY in both receive and transmit
path (not only in the receive path). The delay penalty being
negligible, move this code in the common path.

Fixes: b942d80b0a39 ("spi: Add MXIC controller driver")
Cc: stable@vger.kernel.org
Suggested-by: Mason Yang <masonccyang@mxic.com.tw>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Zhengxun Li <zhengxunli@mxic.com.tw>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-mxic.c | 28 ++++++++++++----------------
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 8c8c929c87b5..3d6561a3ff8b 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -304,25 +304,21 @@ static int mxic_spi_data_xfer(struct mxic_spi *mxic, const void *txbuf,
 
 		writel(data, mxic->regs + TXD(nbytes % 4));
 
+		ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
+					 sts & INT_TX_EMPTY, 0, USEC_PER_SEC);
+		if (ret)
+			return ret;
+
+		ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
+					 sts & INT_RX_NOT_EMPTY, 0,
+					 USEC_PER_SEC);
+		if (ret)
+			return ret;
+
+		data = readl(mxic->regs + RXD);
 		if (rxbuf) {
-			ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
-						 sts & INT_TX_EMPTY, 0,
-						 USEC_PER_SEC);
-			if (ret)
-				return ret;
-
-			ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
-						 sts & INT_RX_NOT_EMPTY, 0,
-						 USEC_PER_SEC);
-			if (ret)
-				return ret;
-
-			data = readl(mxic->regs + RXD);
 			data >>= (8 * (4 - nbytes));
 			memcpy(rxbuf + pos, &data, nbytes);
-			WARN_ON(readl(mxic->regs + INT_STS) & INT_RX_NOT_EMPTY);
-		} else {
-			readl(mxic->regs + RXD);
 		}
 		WARN_ON(readl(mxic->regs + INT_STS) & INT_RX_NOT_EMPTY);
 
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 25/28] spi: mxic: Create a helper to configure the controller before an operation
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Create the mxic_spi_set_hc_cfg() helper to configure the HC_CFG
register. This helper will soon be used by the dirmap implementation and
having this code factorized out earlier will clarify this addition.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-mxic.c | 31 +++++++++++++++++++------------
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 3d6561a3ff8b..950319dc54dc 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -280,6 +280,22 @@ static void mxic_spi_hw_init(struct mxic_spi *mxic)
 	       mxic->regs + HC_CFG);
 }
 
+static u32 mxic_spi_prep_hc_cfg(struct spi_device *spi, u32 flags)
+{
+	int nio = 1;
+
+	if (spi->mode & (SPI_TX_OCTAL | SPI_RX_OCTAL))
+		nio = 8;
+	else if (spi->mode & (SPI_TX_QUAD | SPI_RX_QUAD))
+		nio = 4;
+	else if (spi->mode & (SPI_TX_DUAL | SPI_RX_DUAL))
+		nio = 2;
+
+	return flags | HC_CFG_NIO(nio) |
+	       HC_CFG_TYPE(spi->chip_select, HC_CFG_TYPE_SPI_NOR) |
+	       HC_CFG_SLV_ACT(spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1);
+}
+
 static int mxic_spi_data_xfer(struct mxic_spi *mxic, const void *txbuf,
 			      void *rxbuf, unsigned int len)
 {
@@ -349,7 +365,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 				const struct spi_mem_op *op)
 {
 	struct mxic_spi *mxic = spi_master_get_devdata(mem->spi->master);
-	int nio = 1, i, ret;
+	int i, ret;
 	u32 ss_ctrl;
 	u8 addr[8], cmd[2];
 
@@ -357,18 +373,9 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 	if (ret)
 		return ret;
 
-	if (mem->spi->mode & (SPI_TX_OCTAL | SPI_RX_OCTAL))
-		nio = 8;
-	else if (mem->spi->mode & (SPI_TX_QUAD | SPI_RX_QUAD))
-		nio = 4;
-	else if (mem->spi->mode & (SPI_TX_DUAL | SPI_RX_DUAL))
-		nio = 2;
-
-	writel(HC_CFG_NIO(nio) |
-	       HC_CFG_TYPE(mem->spi->chip_select, HC_CFG_TYPE_SPI_NOR) |
-	       HC_CFG_SLV_ACT(mem->spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1) |
-	       HC_CFG_MAN_CS_EN,
+	writel(mxic_spi_prep_hc_cfg(mem->spi, HC_CFG_MAN_CS_EN),
 	       mxic->regs + HC_CFG);
+
 	writel(HC_EN_BIT, mxic->regs + HC_EN);
 
 	ss_ctrl = OP_CMD_BYTES(op->cmd.nbytes) |
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 25/28] spi: mxic: Create a helper to configure the controller before an operation
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Create the mxic_spi_set_hc_cfg() helper to configure the HC_CFG
register. This helper will soon be used by the dirmap implementation and
having this code factorized out earlier will clarify this addition.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-mxic.c | 31 +++++++++++++++++++------------
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 3d6561a3ff8b..950319dc54dc 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -280,6 +280,22 @@ static void mxic_spi_hw_init(struct mxic_spi *mxic)
 	       mxic->regs + HC_CFG);
 }
 
+static u32 mxic_spi_prep_hc_cfg(struct spi_device *spi, u32 flags)
+{
+	int nio = 1;
+
+	if (spi->mode & (SPI_TX_OCTAL | SPI_RX_OCTAL))
+		nio = 8;
+	else if (spi->mode & (SPI_TX_QUAD | SPI_RX_QUAD))
+		nio = 4;
+	else if (spi->mode & (SPI_TX_DUAL | SPI_RX_DUAL))
+		nio = 2;
+
+	return flags | HC_CFG_NIO(nio) |
+	       HC_CFG_TYPE(spi->chip_select, HC_CFG_TYPE_SPI_NOR) |
+	       HC_CFG_SLV_ACT(spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1);
+}
+
 static int mxic_spi_data_xfer(struct mxic_spi *mxic, const void *txbuf,
 			      void *rxbuf, unsigned int len)
 {
@@ -349,7 +365,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 				const struct spi_mem_op *op)
 {
 	struct mxic_spi *mxic = spi_master_get_devdata(mem->spi->master);
-	int nio = 1, i, ret;
+	int i, ret;
 	u32 ss_ctrl;
 	u8 addr[8], cmd[2];
 
@@ -357,18 +373,9 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 	if (ret)
 		return ret;
 
-	if (mem->spi->mode & (SPI_TX_OCTAL | SPI_RX_OCTAL))
-		nio = 8;
-	else if (mem->spi->mode & (SPI_TX_QUAD | SPI_RX_QUAD))
-		nio = 4;
-	else if (mem->spi->mode & (SPI_TX_DUAL | SPI_RX_DUAL))
-		nio = 2;
-
-	writel(HC_CFG_NIO(nio) |
-	       HC_CFG_TYPE(mem->spi->chip_select, HC_CFG_TYPE_SPI_NOR) |
-	       HC_CFG_SLV_ACT(mem->spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1) |
-	       HC_CFG_MAN_CS_EN,
+	writel(mxic_spi_prep_hc_cfg(mem->spi, HC_CFG_MAN_CS_EN),
 	       mxic->regs + HC_CFG);
+
 	writel(HC_EN_BIT, mxic->regs + HC_EN);
 
 	ss_ctrl = OP_CMD_BYTES(op->cmd.nbytes) |
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 26/28] spi: mxic: Create a helper to ease the start of an operation
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Create the mxic_spi_mem_prep_op_cfg() helper to provide the content to
write to the register controlling the next IO command. This helper will
soon be used by the dirmap implementation and having this code
factorized out earlier will clarify this addition.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-mxic.c | 53 +++++++++++++++++++++++-------------------
 1 file changed, 29 insertions(+), 24 deletions(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 950319dc54dc..d3bef2b24ad6 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -296,6 +296,33 @@ static u32 mxic_spi_prep_hc_cfg(struct spi_device *spi, u32 flags)
 	       HC_CFG_SLV_ACT(spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1);
 }
 
+static u32 mxic_spi_mem_prep_op_cfg(const struct spi_mem_op *op)
+{
+	u32 cfg = OP_CMD_BYTES(op->cmd.nbytes) |
+		  OP_CMD_BUSW(fls(op->cmd.buswidth) - 1) |
+		  (op->cmd.dtr ? OP_CMD_DDR : 0);
+
+	if (op->addr.nbytes)
+		cfg |= OP_ADDR_BYTES(op->addr.nbytes) |
+		       OP_ADDR_BUSW(fls(op->addr.buswidth) - 1) |
+		       (op->addr.dtr ? OP_ADDR_DDR : 0);
+
+	if (op->dummy.nbytes)
+		cfg |= OP_DUMMY_CYC(op->dummy.nbytes);
+
+	if (op->data.nbytes) {
+		cfg |= OP_DATA_BUSW(fls(op->data.buswidth) - 1) |
+		       (op->data.dtr ? OP_DATA_DDR : 0);
+		if (op->data.dir == SPI_MEM_DATA_IN) {
+			cfg |= OP_READ;
+			if (op->data.dtr)
+				cfg |= OP_DQS_EN;
+		}
+	}
+
+	return cfg;
+}
+
 static int mxic_spi_data_xfer(struct mxic_spi *mxic, const void *txbuf,
 			      void *rxbuf, unsigned int len)
 {
@@ -366,7 +393,6 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 {
 	struct mxic_spi *mxic = spi_master_get_devdata(mem->spi->master);
 	int i, ret;
-	u32 ss_ctrl;
 	u8 addr[8], cmd[2];
 
 	ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
@@ -378,29 +404,8 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 
 	writel(HC_EN_BIT, mxic->regs + HC_EN);
 
-	ss_ctrl = OP_CMD_BYTES(op->cmd.nbytes) |
-		  OP_CMD_BUSW(fls(op->cmd.buswidth) - 1) |
-		  (op->cmd.dtr ? OP_CMD_DDR : 0);
-
-	if (op->addr.nbytes)
-		ss_ctrl |= OP_ADDR_BYTES(op->addr.nbytes) |
-			   OP_ADDR_BUSW(fls(op->addr.buswidth) - 1) |
-			   (op->addr.dtr ? OP_ADDR_DDR : 0);
-
-	if (op->dummy.nbytes)
-		ss_ctrl |= OP_DUMMY_CYC(op->dummy.nbytes);
-
-	if (op->data.nbytes) {
-		ss_ctrl |= OP_DATA_BUSW(fls(op->data.buswidth) - 1) |
-			   (op->data.dtr ? OP_DATA_DDR : 0);
-		if (op->data.dir == SPI_MEM_DATA_IN) {
-			ss_ctrl |= OP_READ;
-			if (op->data.dtr)
-				ss_ctrl |= OP_DQS_EN;
-		}
-	}
-
-	writel(ss_ctrl, mxic->regs + SS_CTRL(mem->spi->chip_select));
+	writel(mxic_spi_mem_prep_op_cfg(op),
+	       mxic->regs + SS_CTRL(mem->spi->chip_select));
 
 	writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
 	       mxic->regs + HC_CFG);
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 26/28] spi: mxic: Create a helper to ease the start of an operation
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Create the mxic_spi_mem_prep_op_cfg() helper to provide the content to
write to the register controlling the next IO command. This helper will
soon be used by the dirmap implementation and having this code
factorized out earlier will clarify this addition.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-mxic.c | 53 +++++++++++++++++++++++-------------------
 1 file changed, 29 insertions(+), 24 deletions(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 950319dc54dc..d3bef2b24ad6 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -296,6 +296,33 @@ static u32 mxic_spi_prep_hc_cfg(struct spi_device *spi, u32 flags)
 	       HC_CFG_SLV_ACT(spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1);
 }
 
+static u32 mxic_spi_mem_prep_op_cfg(const struct spi_mem_op *op)
+{
+	u32 cfg = OP_CMD_BYTES(op->cmd.nbytes) |
+		  OP_CMD_BUSW(fls(op->cmd.buswidth) - 1) |
+		  (op->cmd.dtr ? OP_CMD_DDR : 0);
+
+	if (op->addr.nbytes)
+		cfg |= OP_ADDR_BYTES(op->addr.nbytes) |
+		       OP_ADDR_BUSW(fls(op->addr.buswidth) - 1) |
+		       (op->addr.dtr ? OP_ADDR_DDR : 0);
+
+	if (op->dummy.nbytes)
+		cfg |= OP_DUMMY_CYC(op->dummy.nbytes);
+
+	if (op->data.nbytes) {
+		cfg |= OP_DATA_BUSW(fls(op->data.buswidth) - 1) |
+		       (op->data.dtr ? OP_DATA_DDR : 0);
+		if (op->data.dir == SPI_MEM_DATA_IN) {
+			cfg |= OP_READ;
+			if (op->data.dtr)
+				cfg |= OP_DQS_EN;
+		}
+	}
+
+	return cfg;
+}
+
 static int mxic_spi_data_xfer(struct mxic_spi *mxic, const void *txbuf,
 			      void *rxbuf, unsigned int len)
 {
@@ -366,7 +393,6 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 {
 	struct mxic_spi *mxic = spi_master_get_devdata(mem->spi->master);
 	int i, ret;
-	u32 ss_ctrl;
 	u8 addr[8], cmd[2];
 
 	ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
@@ -378,29 +404,8 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 
 	writel(HC_EN_BIT, mxic->regs + HC_EN);
 
-	ss_ctrl = OP_CMD_BYTES(op->cmd.nbytes) |
-		  OP_CMD_BUSW(fls(op->cmd.buswidth) - 1) |
-		  (op->cmd.dtr ? OP_CMD_DDR : 0);
-
-	if (op->addr.nbytes)
-		ss_ctrl |= OP_ADDR_BYTES(op->addr.nbytes) |
-			   OP_ADDR_BUSW(fls(op->addr.buswidth) - 1) |
-			   (op->addr.dtr ? OP_ADDR_DDR : 0);
-
-	if (op->dummy.nbytes)
-		ss_ctrl |= OP_DUMMY_CYC(op->dummy.nbytes);
-
-	if (op->data.nbytes) {
-		ss_ctrl |= OP_DATA_BUSW(fls(op->data.buswidth) - 1) |
-			   (op->data.dtr ? OP_DATA_DDR : 0);
-		if (op->data.dir == SPI_MEM_DATA_IN) {
-			ss_ctrl |= OP_READ;
-			if (op->data.dtr)
-				ss_ctrl |= OP_DQS_EN;
-		}
-	}
-
-	writel(ss_ctrl, mxic->regs + SS_CTRL(mem->spi->chip_select));
+	writel(mxic_spi_mem_prep_op_cfg(op),
+	       mxic->regs + SS_CTRL(mem->spi->chip_select));
 
 	writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
 	       mxic->regs + HC_CFG);
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 27/28] spi: mxic: Add support for direct mapping
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Zhengxun Li

Implement the ->dirmap_create() and ->dirmap_read/write() hooks to
provide a fast path for read and write accesses.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Zhengxun Li <zhengxunli@mxic.com.tw>
Reviewed-by: Zhengxun Li <zhengxunli@mxic.com.tw>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-mxic.c | 112 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 109 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index d3bef2b24ad6..df2daea4d5ee 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -172,6 +172,11 @@ struct mxic_spi {
 	struct clk *send_dly_clk;
 	void __iomem *regs;
 	u32 cur_speed_hz;
+	struct {
+		void __iomem *map;
+		dma_addr_t dma;
+		size_t size;
+	} linear;
 };
 
 static int mxic_spi_clk_enable(struct mxic_spi *mxic)
@@ -296,7 +301,8 @@ static u32 mxic_spi_prep_hc_cfg(struct spi_device *spi, u32 flags)
 	       HC_CFG_SLV_ACT(spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1);
 }
 
-static u32 mxic_spi_mem_prep_op_cfg(const struct spi_mem_op *op)
+static u32 mxic_spi_mem_prep_op_cfg(const struct spi_mem_op *op,
+				    unsigned int data_len)
 {
 	u32 cfg = OP_CMD_BYTES(op->cmd.nbytes) |
 		  OP_CMD_BUSW(fls(op->cmd.buswidth) - 1) |
@@ -310,7 +316,8 @@ static u32 mxic_spi_mem_prep_op_cfg(const struct spi_mem_op *op)
 	if (op->dummy.nbytes)
 		cfg |= OP_DUMMY_CYC(op->dummy.nbytes);
 
-	if (op->data.nbytes) {
+	/* Direct mapping data.nbytes field is not populated */
+	if (data_len) {
 		cfg |= OP_DATA_BUSW(fls(op->data.buswidth) - 1) |
 		       (op->data.dtr ? OP_DATA_DDR : 0);
 		if (op->data.dir == SPI_MEM_DATA_IN) {
@@ -371,6 +378,77 @@ static int mxic_spi_data_xfer(struct mxic_spi *mxic, const void *txbuf,
 	return 0;
 }
 
+static ssize_t mxic_spi_mem_dirmap_read(struct spi_mem_dirmap_desc *desc,
+					u64 offs, size_t len, void *buf)
+{
+	struct mxic_spi *mxic = spi_master_get_devdata(desc->mem->spi->master);
+	int ret;
+	u32 sts;
+
+	if (WARN_ON(offs + desc->info.offset + len > U32_MAX))
+		return -EINVAL;
+
+	writel(mxic_spi_prep_hc_cfg(desc->mem->spi, 0), mxic->regs + HC_CFG);
+
+	writel(mxic_spi_mem_prep_op_cfg(&desc->info.op_tmpl, len),
+	       mxic->regs + LRD_CFG);
+	writel(desc->info.offset + offs, mxic->regs + LRD_ADDR);
+	len = min_t(size_t, len, mxic->linear.size);
+	writel(len, mxic->regs + LRD_RANGE);
+	writel(LMODE_CMD0(desc->info.op_tmpl.cmd.opcode) |
+	       LMODE_SLV_ACT(desc->mem->spi->chip_select) |
+	       LMODE_EN,
+	       mxic->regs + LRD_CTRL);
+
+	memcpy_fromio(buf, mxic->linear.map, len);
+
+	writel(INT_LRD_DIS, mxic->regs + INT_STS);
+	writel(0, mxic->regs + LRD_CTRL);
+
+	ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
+				 sts & INT_LRD_DIS, 0, USEC_PER_SEC);
+	if (ret)
+		return ret;
+
+	return len;
+}
+
+static ssize_t mxic_spi_mem_dirmap_write(struct spi_mem_dirmap_desc *desc,
+					 u64 offs, size_t len,
+					 const void *buf)
+{
+	struct mxic_spi *mxic = spi_master_get_devdata(desc->mem->spi->master);
+	u32 sts;
+	int ret;
+
+	if (WARN_ON(offs + desc->info.offset + len > U32_MAX))
+		return -EINVAL;
+
+	writel(mxic_spi_prep_hc_cfg(desc->mem->spi, 0), mxic->regs + HC_CFG);
+
+	writel(mxic_spi_mem_prep_op_cfg(&desc->info.op_tmpl, len),
+	       mxic->regs + LWR_CFG);
+	writel(desc->info.offset + offs, mxic->regs + LWR_ADDR);
+	len = min_t(size_t, len, mxic->linear.size);
+	writel(len, mxic->regs + LWR_RANGE);
+	writel(LMODE_CMD0(desc->info.op_tmpl.cmd.opcode) |
+	       LMODE_SLV_ACT(desc->mem->spi->chip_select) |
+	       LMODE_EN,
+	       mxic->regs + LWR_CTRL);
+
+	memcpy_toio(mxic->linear.map, buf, len);
+
+	writel(INT_LWR_DIS, mxic->regs + INT_STS);
+	writel(0, mxic->regs + LWR_CTRL);
+
+	ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
+				 sts & INT_LWR_DIS, 0, USEC_PER_SEC);
+	if (ret)
+		return ret;
+
+	return len;
+}
+
 static bool mxic_spi_mem_supports_op(struct spi_mem *mem,
 				     const struct spi_mem_op *op)
 {
@@ -388,6 +466,22 @@ static bool mxic_spi_mem_supports_op(struct spi_mem *mem,
 	return spi_mem_default_supports_op(mem, op);
 }
 
+static int mxic_spi_mem_dirmap_create(struct spi_mem_dirmap_desc *desc)
+{
+	struct mxic_spi *mxic = spi_master_get_devdata(desc->mem->spi->master);
+
+	if (!mxic->linear.map)
+		return -EINVAL;
+
+	if (desc->info.offset + desc->info.length > U32_MAX)
+		return -EINVAL;
+
+	if (!mxic_spi_mem_supports_op(desc->mem, &desc->info.op_tmpl))
+		return -EOPNOTSUPP;
+
+	return 0;
+}
+
 static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 				const struct spi_mem_op *op)
 {
@@ -404,7 +498,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 
 	writel(HC_EN_BIT, mxic->regs + HC_EN);
 
-	writel(mxic_spi_mem_prep_op_cfg(op),
+	writel(mxic_spi_mem_prep_op_cfg(op, op->data.nbytes),
 	       mxic->regs + SS_CTRL(mem->spi->chip_select));
 
 	writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
@@ -450,6 +544,9 @@ const struct spi_controller_mem_caps mxic_spi_mem_caps = {
 static const struct spi_controller_mem_ops mxic_spi_mem_ops = {
 	.supports_op = mxic_spi_mem_supports_op,
 	.exec_op = mxic_spi_mem_exec_op,
+	.dirmap_create = mxic_spi_mem_dirmap_create,
+	.dirmap_read = mxic_spi_mem_dirmap_read,
+	.dirmap_write = mxic_spi_mem_dirmap_write,
 	.caps = &mxic_spi_mem_caps,
 };
 
@@ -580,6 +677,15 @@ static int mxic_spi_probe(struct platform_device *pdev)
 	if (IS_ERR(mxic->regs))
 		return PTR_ERR(mxic->regs);
 
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dirmap");
+	mxic->linear.map = devm_ioremap_resource(&pdev->dev, res);
+	if (!IS_ERR(mxic->linear.map)) {
+		mxic->linear.dma = res->start;
+		mxic->linear.size = resource_size(res);
+	} else {
+		mxic->linear.map = NULL;
+	}
+
 	pm_runtime_enable(&pdev->dev);
 	master->auto_runtime_pm = true;
 
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 27/28] spi: mxic: Add support for direct mapping
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal, Zhengxun Li

Implement the ->dirmap_create() and ->dirmap_read/write() hooks to
provide a fast path for read and write accesses.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Zhengxun Li <zhengxunli@mxic.com.tw>
Reviewed-by: Zhengxun Li <zhengxunli@mxic.com.tw>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-mxic.c | 112 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 109 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index d3bef2b24ad6..df2daea4d5ee 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -172,6 +172,11 @@ struct mxic_spi {
 	struct clk *send_dly_clk;
 	void __iomem *regs;
 	u32 cur_speed_hz;
+	struct {
+		void __iomem *map;
+		dma_addr_t dma;
+		size_t size;
+	} linear;
 };
 
 static int mxic_spi_clk_enable(struct mxic_spi *mxic)
@@ -296,7 +301,8 @@ static u32 mxic_spi_prep_hc_cfg(struct spi_device *spi, u32 flags)
 	       HC_CFG_SLV_ACT(spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1);
 }
 
-static u32 mxic_spi_mem_prep_op_cfg(const struct spi_mem_op *op)
+static u32 mxic_spi_mem_prep_op_cfg(const struct spi_mem_op *op,
+				    unsigned int data_len)
 {
 	u32 cfg = OP_CMD_BYTES(op->cmd.nbytes) |
 		  OP_CMD_BUSW(fls(op->cmd.buswidth) - 1) |
@@ -310,7 +316,8 @@ static u32 mxic_spi_mem_prep_op_cfg(const struct spi_mem_op *op)
 	if (op->dummy.nbytes)
 		cfg |= OP_DUMMY_CYC(op->dummy.nbytes);
 
-	if (op->data.nbytes) {
+	/* Direct mapping data.nbytes field is not populated */
+	if (data_len) {
 		cfg |= OP_DATA_BUSW(fls(op->data.buswidth) - 1) |
 		       (op->data.dtr ? OP_DATA_DDR : 0);
 		if (op->data.dir == SPI_MEM_DATA_IN) {
@@ -371,6 +378,77 @@ static int mxic_spi_data_xfer(struct mxic_spi *mxic, const void *txbuf,
 	return 0;
 }
 
+static ssize_t mxic_spi_mem_dirmap_read(struct spi_mem_dirmap_desc *desc,
+					u64 offs, size_t len, void *buf)
+{
+	struct mxic_spi *mxic = spi_master_get_devdata(desc->mem->spi->master);
+	int ret;
+	u32 sts;
+
+	if (WARN_ON(offs + desc->info.offset + len > U32_MAX))
+		return -EINVAL;
+
+	writel(mxic_spi_prep_hc_cfg(desc->mem->spi, 0), mxic->regs + HC_CFG);
+
+	writel(mxic_spi_mem_prep_op_cfg(&desc->info.op_tmpl, len),
+	       mxic->regs + LRD_CFG);
+	writel(desc->info.offset + offs, mxic->regs + LRD_ADDR);
+	len = min_t(size_t, len, mxic->linear.size);
+	writel(len, mxic->regs + LRD_RANGE);
+	writel(LMODE_CMD0(desc->info.op_tmpl.cmd.opcode) |
+	       LMODE_SLV_ACT(desc->mem->spi->chip_select) |
+	       LMODE_EN,
+	       mxic->regs + LRD_CTRL);
+
+	memcpy_fromio(buf, mxic->linear.map, len);
+
+	writel(INT_LRD_DIS, mxic->regs + INT_STS);
+	writel(0, mxic->regs + LRD_CTRL);
+
+	ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
+				 sts & INT_LRD_DIS, 0, USEC_PER_SEC);
+	if (ret)
+		return ret;
+
+	return len;
+}
+
+static ssize_t mxic_spi_mem_dirmap_write(struct spi_mem_dirmap_desc *desc,
+					 u64 offs, size_t len,
+					 const void *buf)
+{
+	struct mxic_spi *mxic = spi_master_get_devdata(desc->mem->spi->master);
+	u32 sts;
+	int ret;
+
+	if (WARN_ON(offs + desc->info.offset + len > U32_MAX))
+		return -EINVAL;
+
+	writel(mxic_spi_prep_hc_cfg(desc->mem->spi, 0), mxic->regs + HC_CFG);
+
+	writel(mxic_spi_mem_prep_op_cfg(&desc->info.op_tmpl, len),
+	       mxic->regs + LWR_CFG);
+	writel(desc->info.offset + offs, mxic->regs + LWR_ADDR);
+	len = min_t(size_t, len, mxic->linear.size);
+	writel(len, mxic->regs + LWR_RANGE);
+	writel(LMODE_CMD0(desc->info.op_tmpl.cmd.opcode) |
+	       LMODE_SLV_ACT(desc->mem->spi->chip_select) |
+	       LMODE_EN,
+	       mxic->regs + LWR_CTRL);
+
+	memcpy_toio(mxic->linear.map, buf, len);
+
+	writel(INT_LWR_DIS, mxic->regs + INT_STS);
+	writel(0, mxic->regs + LWR_CTRL);
+
+	ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
+				 sts & INT_LWR_DIS, 0, USEC_PER_SEC);
+	if (ret)
+		return ret;
+
+	return len;
+}
+
 static bool mxic_spi_mem_supports_op(struct spi_mem *mem,
 				     const struct spi_mem_op *op)
 {
@@ -388,6 +466,22 @@ static bool mxic_spi_mem_supports_op(struct spi_mem *mem,
 	return spi_mem_default_supports_op(mem, op);
 }
 
+static int mxic_spi_mem_dirmap_create(struct spi_mem_dirmap_desc *desc)
+{
+	struct mxic_spi *mxic = spi_master_get_devdata(desc->mem->spi->master);
+
+	if (!mxic->linear.map)
+		return -EINVAL;
+
+	if (desc->info.offset + desc->info.length > U32_MAX)
+		return -EINVAL;
+
+	if (!mxic_spi_mem_supports_op(desc->mem, &desc->info.op_tmpl))
+		return -EOPNOTSUPP;
+
+	return 0;
+}
+
 static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 				const struct spi_mem_op *op)
 {
@@ -404,7 +498,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 
 	writel(HC_EN_BIT, mxic->regs + HC_EN);
 
-	writel(mxic_spi_mem_prep_op_cfg(op),
+	writel(mxic_spi_mem_prep_op_cfg(op, op->data.nbytes),
 	       mxic->regs + SS_CTRL(mem->spi->chip_select));
 
 	writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
@@ -450,6 +544,9 @@ const struct spi_controller_mem_caps mxic_spi_mem_caps = {
 static const struct spi_controller_mem_ops mxic_spi_mem_ops = {
 	.supports_op = mxic_spi_mem_supports_op,
 	.exec_op = mxic_spi_mem_exec_op,
+	.dirmap_create = mxic_spi_mem_dirmap_create,
+	.dirmap_read = mxic_spi_mem_dirmap_read,
+	.dirmap_write = mxic_spi_mem_dirmap_write,
 	.caps = &mxic_spi_mem_caps,
 };
 
@@ -580,6 +677,15 @@ static int mxic_spi_probe(struct platform_device *pdev)
 	if (IS_ERR(mxic->regs))
 		return PTR_ERR(mxic->regs);
 
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dirmap");
+	mxic->linear.map = devm_ioremap_resource(&pdev->dev, res);
+	if (!IS_ERR(mxic->linear.map)) {
+		mxic->linear.dma = res->start;
+		mxic->linear.size = resource_size(res);
+	} else {
+		mxic->linear.map = NULL;
+	}
+
 	pm_runtime_enable(&pdev->dev);
 	master->auto_runtime_pm = true;
 
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 28/28] spi: mxic: Add support for pipelined ECC operations
  2021-12-16 11:16 ` Miquel Raynal
@ 2021-12-16 11:16   ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Some SPI-NAND chips do not have a proper on-die ECC engine providing
error correction/detection. This is particularly an issue on embedded
devices with limited resources because all the computations must
happen in software, unless an external hardware engine is provided.

These external engines are new and can be of two categories: external
or pipelined. Macronix is providing both, the former being already
supported. The second, however, is very SoC implementation dependent
and must be instantiated by the SPI host controller directly.

An entire subsystem has been contributed to support these engines which
makes the insertion into another subsystem such as SPI quite
straightforward without the need for a lot of specific functions.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/Kconfig    |   2 +-
 drivers/spi/spi-mxic.c | 113 ++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 112 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 83e352b0c8f9..bff75629e872 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -856,7 +856,7 @@ config SPI_SYNQUACER
 
 config SPI_MXIC
 	tristate "Macronix MX25F0A SPI controller"
-	depends on SPI_MASTER
+	depends on SPI_MASTER && MTD_NAND_ECC
 	help
 	  This selects the Macronix MX25F0A SPI controller driver.
 
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index df2daea4d5ee..969e02b324c6 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -12,6 +12,8 @@
 #include <linux/io.h>
 #include <linux/iopoll.h>
 #include <linux/module.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/nand-ecc-mxic.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/spi/spi.h>
@@ -167,6 +169,7 @@
 #define HW_TEST(x)		(0xe0 + ((x) * 4))
 
 struct mxic_spi {
+	struct device *dev;
 	struct clk *ps_clk;
 	struct clk *send_clk;
 	struct clk *send_dly_clk;
@@ -177,6 +180,12 @@ struct mxic_spi {
 		dma_addr_t dma;
 		size_t size;
 	} linear;
+
+	struct {
+		bool use_pipelined_conf;
+		struct nand_ecc_engine *pipelined_engine;
+		void *ctx;
+	} ecc;
 };
 
 static int mxic_spi_clk_enable(struct mxic_spi *mxic)
@@ -400,7 +409,15 @@ static ssize_t mxic_spi_mem_dirmap_read(struct spi_mem_dirmap_desc *desc,
 	       LMODE_EN,
 	       mxic->regs + LRD_CTRL);
 
-	memcpy_fromio(buf, mxic->linear.map, len);
+	if (mxic->ecc.use_pipelined_conf && desc->info.op_tmpl.ecc_en) {
+		ret = mxic_ecc_process_data_pipelined(mxic->ecc.pipelined_engine,
+						      NAND_PAGE_READ,
+						      mxic->linear.dma + offs);
+		if (ret)
+			return ret;
+	} else {
+		memcpy_fromio(buf, mxic->linear.map, len);
+	}
 
 	writel(INT_LRD_DIS, mxic->regs + INT_STS);
 	writel(0, mxic->regs + LRD_CTRL);
@@ -436,7 +453,15 @@ static ssize_t mxic_spi_mem_dirmap_write(struct spi_mem_dirmap_desc *desc,
 	       LMODE_EN,
 	       mxic->regs + LWR_CTRL);
 
-	memcpy_toio(mxic->linear.map, buf, len);
+	if (mxic->ecc.use_pipelined_conf && desc->info.op_tmpl.ecc_en) {
+		ret = mxic_ecc_process_data_pipelined(mxic->ecc.pipelined_engine,
+						      NAND_PAGE_WRITE,
+						      mxic->linear.dma + offs);
+		if (ret)
+			return ret;
+	} else {
+		memcpy_toio(mxic->linear.map, buf, len);
+	}
 
 	writel(INT_LWR_DIS, mxic->regs + INT_STS);
 	writel(0, mxic->regs + LWR_CTRL);
@@ -539,6 +564,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 
 const struct spi_controller_mem_caps mxic_spi_mem_caps = {
 	.dtr = true,
+	.ecc = true,
 };
 
 static const struct spi_controller_mem_ops mxic_spi_mem_ops = {
@@ -612,6 +638,80 @@ static int mxic_spi_transfer_one(struct spi_master *master,
 	return 0;
 }
 
+/* ECC wrapper */
+static int mxic_spi_mem_ecc_init_ctx(struct nand_device *nand)
+{
+	struct nand_ecc_engine_ops *ops = mxic_ecc_get_pipelined_ops();
+	struct mxic_spi *mxic = nand->ecc.engine->priv;
+
+	mxic->ecc.use_pipelined_conf = true;
+
+	return ops->init_ctx(nand);
+}
+
+static void mxic_spi_mem_ecc_cleanup_ctx(struct nand_device *nand)
+{
+	struct nand_ecc_engine_ops *ops = mxic_ecc_get_pipelined_ops();
+	struct mxic_spi *mxic = nand->ecc.engine->priv;
+
+	mxic->ecc.use_pipelined_conf = false;
+
+	ops->cleanup_ctx(nand);
+}
+
+static int mxic_spi_mem_ecc_prepare_io_req(struct nand_device *nand,
+					   struct nand_page_io_req *req)
+{
+	struct nand_ecc_engine_ops *ops = mxic_ecc_get_pipelined_ops();
+
+	return ops->prepare_io_req(nand, req);
+}
+
+static int mxic_spi_mem_ecc_finish_io_req(struct nand_device *nand,
+					  struct nand_page_io_req *req)
+{
+	struct nand_ecc_engine_ops *ops = mxic_ecc_get_pipelined_ops();
+
+	return ops->finish_io_req(nand, req);
+}
+
+static struct nand_ecc_engine_ops mxic_spi_mem_ecc_engine_pipelined_ops = {
+	.init_ctx = mxic_spi_mem_ecc_init_ctx,
+	.cleanup_ctx = mxic_spi_mem_ecc_cleanup_ctx,
+	.prepare_io_req = mxic_spi_mem_ecc_prepare_io_req,
+	.finish_io_req = mxic_spi_mem_ecc_finish_io_req,
+};
+
+static void mxic_spi_mem_ecc_remove(struct mxic_spi *mxic)
+{
+	if (mxic->ecc.pipelined_engine) {
+		mxic_ecc_put_pipelined_engine(mxic->ecc.pipelined_engine);
+		nand_ecc_unregister_on_host_hw_engine(mxic->ecc.pipelined_engine);
+	}
+}
+
+static int mxic_spi_mem_ecc_probe(struct platform_device *pdev,
+				  struct mxic_spi *mxic)
+{
+	struct nand_ecc_engine *eng;
+
+	if (!mxic_ecc_get_pipelined_ops())
+		return -EOPNOTSUPP;
+
+	eng = mxic_ecc_get_pipelined_engine(pdev);
+	if (IS_ERR(eng))
+		return PTR_ERR(eng);
+
+	eng->dev = &pdev->dev;
+	eng->integration = NAND_ECC_ENGINE_INTEGRATION_PIPELINED;
+	eng->ops = &mxic_spi_mem_ecc_engine_pipelined_ops;
+	eng->priv = mxic;
+	mxic->ecc.pipelined_engine = eng;
+	nand_ecc_register_on_host_hw_engine(eng);
+
+	return 0;
+}
+
 static int __maybe_unused mxic_spi_runtime_suspend(struct device *dev)
 {
 	struct spi_master *master = dev_get_drvdata(dev);
@@ -657,6 +757,7 @@ static int mxic_spi_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, master);
 
 	mxic = spi_master_get_devdata(master);
+	mxic->dev = &pdev->dev;
 
 	master->dev.of_node = pdev->dev.of_node;
 
@@ -702,6 +803,12 @@ static int mxic_spi_probe(struct platform_device *pdev)
 
 	mxic_spi_hw_init(mxic);
 
+	ret = mxic_spi_mem_ecc_probe(pdev, mxic);
+	if (ret == -EPROBE_DEFER) {
+		pm_runtime_disable(&pdev->dev);
+		return ret;
+	}
+
 	ret = spi_register_master(master);
 	if (ret) {
 		dev_err(&pdev->dev, "spi_register_master failed\n");
@@ -714,8 +821,10 @@ static int mxic_spi_probe(struct platform_device *pdev)
 static int mxic_spi_remove(struct platform_device *pdev)
 {
 	struct spi_master *master = platform_get_drvdata(pdev);
+	struct mxic_spi *mxic = spi_master_get_devdata(master);
 
 	pm_runtime_disable(&pdev->dev);
+	mxic_spi_mem_ecc_remove(mxic);
 	spi_unregister_master(master);
 
 	return 0;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [PATCH v6 28/28] spi: mxic: Add support for pipelined ECC operations
@ 2021-12-16 11:16   ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 11:16 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Miquel Raynal

Some SPI-NAND chips do not have a proper on-die ECC engine providing
error correction/detection. This is particularly an issue on embedded
devices with limited resources because all the computations must
happen in software, unless an external hardware engine is provided.

These external engines are new and can be of two categories: external
or pipelined. Macronix is providing both, the former being already
supported. The second, however, is very SoC implementation dependent
and must be instantiated by the SPI host controller directly.

An entire subsystem has been contributed to support these engines which
makes the insertion into another subsystem such as SPI quite
straightforward without the need for a lot of specific functions.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/Kconfig    |   2 +-
 drivers/spi/spi-mxic.c | 113 ++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 112 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 83e352b0c8f9..bff75629e872 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -856,7 +856,7 @@ config SPI_SYNQUACER
 
 config SPI_MXIC
 	tristate "Macronix MX25F0A SPI controller"
-	depends on SPI_MASTER
+	depends on SPI_MASTER && MTD_NAND_ECC
 	help
 	  This selects the Macronix MX25F0A SPI controller driver.
 
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index df2daea4d5ee..969e02b324c6 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -12,6 +12,8 @@
 #include <linux/io.h>
 #include <linux/iopoll.h>
 #include <linux/module.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/nand-ecc-mxic.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/spi/spi.h>
@@ -167,6 +169,7 @@
 #define HW_TEST(x)		(0xe0 + ((x) * 4))
 
 struct mxic_spi {
+	struct device *dev;
 	struct clk *ps_clk;
 	struct clk *send_clk;
 	struct clk *send_dly_clk;
@@ -177,6 +180,12 @@ struct mxic_spi {
 		dma_addr_t dma;
 		size_t size;
 	} linear;
+
+	struct {
+		bool use_pipelined_conf;
+		struct nand_ecc_engine *pipelined_engine;
+		void *ctx;
+	} ecc;
 };
 
 static int mxic_spi_clk_enable(struct mxic_spi *mxic)
@@ -400,7 +409,15 @@ static ssize_t mxic_spi_mem_dirmap_read(struct spi_mem_dirmap_desc *desc,
 	       LMODE_EN,
 	       mxic->regs + LRD_CTRL);
 
-	memcpy_fromio(buf, mxic->linear.map, len);
+	if (mxic->ecc.use_pipelined_conf && desc->info.op_tmpl.ecc_en) {
+		ret = mxic_ecc_process_data_pipelined(mxic->ecc.pipelined_engine,
+						      NAND_PAGE_READ,
+						      mxic->linear.dma + offs);
+		if (ret)
+			return ret;
+	} else {
+		memcpy_fromio(buf, mxic->linear.map, len);
+	}
 
 	writel(INT_LRD_DIS, mxic->regs + INT_STS);
 	writel(0, mxic->regs + LRD_CTRL);
@@ -436,7 +453,15 @@ static ssize_t mxic_spi_mem_dirmap_write(struct spi_mem_dirmap_desc *desc,
 	       LMODE_EN,
 	       mxic->regs + LWR_CTRL);
 
-	memcpy_toio(mxic->linear.map, buf, len);
+	if (mxic->ecc.use_pipelined_conf && desc->info.op_tmpl.ecc_en) {
+		ret = mxic_ecc_process_data_pipelined(mxic->ecc.pipelined_engine,
+						      NAND_PAGE_WRITE,
+						      mxic->linear.dma + offs);
+		if (ret)
+			return ret;
+	} else {
+		memcpy_toio(mxic->linear.map, buf, len);
+	}
 
 	writel(INT_LWR_DIS, mxic->regs + INT_STS);
 	writel(0, mxic->regs + LWR_CTRL);
@@ -539,6 +564,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 
 const struct spi_controller_mem_caps mxic_spi_mem_caps = {
 	.dtr = true,
+	.ecc = true,
 };
 
 static const struct spi_controller_mem_ops mxic_spi_mem_ops = {
@@ -612,6 +638,80 @@ static int mxic_spi_transfer_one(struct spi_master *master,
 	return 0;
 }
 
+/* ECC wrapper */
+static int mxic_spi_mem_ecc_init_ctx(struct nand_device *nand)
+{
+	struct nand_ecc_engine_ops *ops = mxic_ecc_get_pipelined_ops();
+	struct mxic_spi *mxic = nand->ecc.engine->priv;
+
+	mxic->ecc.use_pipelined_conf = true;
+
+	return ops->init_ctx(nand);
+}
+
+static void mxic_spi_mem_ecc_cleanup_ctx(struct nand_device *nand)
+{
+	struct nand_ecc_engine_ops *ops = mxic_ecc_get_pipelined_ops();
+	struct mxic_spi *mxic = nand->ecc.engine->priv;
+
+	mxic->ecc.use_pipelined_conf = false;
+
+	ops->cleanup_ctx(nand);
+}
+
+static int mxic_spi_mem_ecc_prepare_io_req(struct nand_device *nand,
+					   struct nand_page_io_req *req)
+{
+	struct nand_ecc_engine_ops *ops = mxic_ecc_get_pipelined_ops();
+
+	return ops->prepare_io_req(nand, req);
+}
+
+static int mxic_spi_mem_ecc_finish_io_req(struct nand_device *nand,
+					  struct nand_page_io_req *req)
+{
+	struct nand_ecc_engine_ops *ops = mxic_ecc_get_pipelined_ops();
+
+	return ops->finish_io_req(nand, req);
+}
+
+static struct nand_ecc_engine_ops mxic_spi_mem_ecc_engine_pipelined_ops = {
+	.init_ctx = mxic_spi_mem_ecc_init_ctx,
+	.cleanup_ctx = mxic_spi_mem_ecc_cleanup_ctx,
+	.prepare_io_req = mxic_spi_mem_ecc_prepare_io_req,
+	.finish_io_req = mxic_spi_mem_ecc_finish_io_req,
+};
+
+static void mxic_spi_mem_ecc_remove(struct mxic_spi *mxic)
+{
+	if (mxic->ecc.pipelined_engine) {
+		mxic_ecc_put_pipelined_engine(mxic->ecc.pipelined_engine);
+		nand_ecc_unregister_on_host_hw_engine(mxic->ecc.pipelined_engine);
+	}
+}
+
+static int mxic_spi_mem_ecc_probe(struct platform_device *pdev,
+				  struct mxic_spi *mxic)
+{
+	struct nand_ecc_engine *eng;
+
+	if (!mxic_ecc_get_pipelined_ops())
+		return -EOPNOTSUPP;
+
+	eng = mxic_ecc_get_pipelined_engine(pdev);
+	if (IS_ERR(eng))
+		return PTR_ERR(eng);
+
+	eng->dev = &pdev->dev;
+	eng->integration = NAND_ECC_ENGINE_INTEGRATION_PIPELINED;
+	eng->ops = &mxic_spi_mem_ecc_engine_pipelined_ops;
+	eng->priv = mxic;
+	mxic->ecc.pipelined_engine = eng;
+	nand_ecc_register_on_host_hw_engine(eng);
+
+	return 0;
+}
+
 static int __maybe_unused mxic_spi_runtime_suspend(struct device *dev)
 {
 	struct spi_master *master = dev_get_drvdata(dev);
@@ -657,6 +757,7 @@ static int mxic_spi_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, master);
 
 	mxic = spi_master_get_devdata(master);
+	mxic->dev = &pdev->dev;
 
 	master->dev.of_node = pdev->dev.of_node;
 
@@ -702,6 +803,12 @@ static int mxic_spi_probe(struct platform_device *pdev)
 
 	mxic_spi_hw_init(mxic);
 
+	ret = mxic_spi_mem_ecc_probe(pdev, mxic);
+	if (ret == -EPROBE_DEFER) {
+		pm_runtime_disable(&pdev->dev);
+		return ret;
+	}
+
 	ret = spi_register_master(master);
 	if (ret) {
 		dev_err(&pdev->dev, "spi_register_master failed\n");
@@ -714,8 +821,10 @@ static int mxic_spi_probe(struct platform_device *pdev)
 static int mxic_spi_remove(struct platform_device *pdev)
 {
 	struct spi_master *master = platform_get_drvdata(pdev);
+	struct mxic_spi *mxic = spi_master_get_devdata(master);
 
 	pm_runtime_disable(&pdev->dev);
+	mxic_spi_mem_ecc_remove(mxic);
 	spi_unregister_master(master);
 
 	return 0;
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-16 15:52     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 15:52 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Boris Brezillon

Hello all,

> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> index c4da0c9b05e9..bfd5c6b2db0a 100644
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
> @@ -160,6 +160,9 @@ static bool spi_mem_check_buswidth(struct spi_mem *mem,
>  	return true;
>  }
>  
> +const struct spi_controller_mem_caps spi_mem_no_caps = {};
> +EXPORT_SYMBOL_GPL(spi_mem_no_caps);

As suggested by Boris on IRC, we might just find a way to avoid
defining this empty structure and requesting all drivers to provide one.

As it turns out, there is no per-controller spi-mem initialization
where we could provide a default set of capabilities, but I believe we
could hide the little extra complexity with something like:

#define spi_mem_controller_is_capable(mem, cap) \
	((mem)->ctlr->caps && (mem)->ctrl->caps->##cap)

And using the above helper in spi_mem_default_supports_op(), which
would transparently handle the !caps situation.

> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 57e2499ec1ed..58c5cb985431 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -2747,6 +2747,9 @@ static int spi_controller_check_ops(struct spi_controller *ctlr)
>  	if (ctlr->mem_ops) {
>  		if (!ctlr->mem_ops->exec_op)
>  			return -EINVAL;
> +
> +		if (!ctlr->mem_ops->caps)
> +			return -EINVAL;
>  	} else if (!ctlr->transfer && !ctlr->transfer_one &&
>  		   !ctlr->transfer_one_message) {
>  		return -EINVAL;
> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> index 42f3850610b5..5f728f3113bd 100644
> --- a/include/linux/spi/spi-mem.h
> +++ b/include/linux/spi/spi-mem.h
> @@ -366,6 +366,7 @@ bool spi_mem_dtr_supports_op(struct spi_mem *mem,
>  
>  int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op);
>  
> +const struct spi_controller_mem_caps spi_mem_no_caps;
>  bool spi_mem_supports_op(struct spi_mem *mem,
>  			 const struct spi_mem_op *op);
>  


Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 15:52     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-16 15:52 UTC (permalink / raw)
  To: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, linux-mtd,
	Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Boris Brezillon

Hello all,

> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> index c4da0c9b05e9..bfd5c6b2db0a 100644
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
> @@ -160,6 +160,9 @@ static bool spi_mem_check_buswidth(struct spi_mem *mem,
>  	return true;
>  }
>  
> +const struct spi_controller_mem_caps spi_mem_no_caps = {};
> +EXPORT_SYMBOL_GPL(spi_mem_no_caps);

As suggested by Boris on IRC, we might just find a way to avoid
defining this empty structure and requesting all drivers to provide one.

As it turns out, there is no per-controller spi-mem initialization
where we could provide a default set of capabilities, but I believe we
could hide the little extra complexity with something like:

#define spi_mem_controller_is_capable(mem, cap) \
	((mem)->ctlr->caps && (mem)->ctrl->caps->##cap)

And using the above helper in spi_mem_default_supports_op(), which
would transparently handle the !caps situation.

> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 57e2499ec1ed..58c5cb985431 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -2747,6 +2747,9 @@ static int spi_controller_check_ops(struct spi_controller *ctlr)
>  	if (ctlr->mem_ops) {
>  		if (!ctlr->mem_ops->exec_op)
>  			return -EINVAL;
> +
> +		if (!ctlr->mem_ops->caps)
> +			return -EINVAL;
>  	} else if (!ctlr->transfer && !ctlr->transfer_one &&
>  		   !ctlr->transfer_one_message) {
>  		return -EINVAL;
> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> index 42f3850610b5..5f728f3113bd 100644
> --- a/include/linux/spi/spi-mem.h
> +++ b/include/linux/spi/spi-mem.h
> @@ -366,6 +366,7 @@ bool spi_mem_dtr_supports_op(struct spi_mem *mem,
>  
>  int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op);
>  
> +const struct spi_controller_mem_caps spi_mem_no_caps;
>  bool spi_mem_supports_op(struct spi_mem *mem,
>  			 const struct spi_mem_op *op);
>  


Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
  2021-12-16 11:16   ` Miquel Raynal
  (?)
@ 2021-12-16 18:00     ` kernel test robot
  -1 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 18:00 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

Hi Miquel,

I love your patch! Yet something to improve:

[auto build test ERROR on broonie-spi/for-next]
[also build test ERROR on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: arm-buildonly-randconfig-r006-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170120.4tAlxDnn-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/gigadevice.o: in function `.LANCHOR0':
>> gigadevice.c:(.rodata+0x464): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/macronix.o: in function `.LANCHOR0':
   macronix.c:(.rodata+0x8d4): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/micron.o: in function `.LANCHOR0':
   micron.c:(.rodata+0x4cc): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/paragon.o: in function `.LANCHOR0':
   paragon.c:(.rodata+0x144): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/toshiba.o: in function `.LANCHOR0':
   toshiba.c:(.rodata+0x664): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/winbond.o:(.rodata+0x114): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
--
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/sfdp.o: in function `.LANCHOR0':
>> sfdp.c:(.rodata+0x278): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/swp.o: in function `.LANCHOR0':
   swp.c:(.rodata+0x24): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/otp.o: in function `.LANCHOR0':
   otp.c:(.rodata+0xc): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/sysfs.o:(.rodata+0x14): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/atmel.o: in function `.LANCHOR0':
   atmel.c:(.rodata+0x3d0): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/catalyst.o:(.rodata+0x178): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/eon.o:(.rodata+0x370): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/esmt.o:(.rodata+0xe8): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/everspin.o:(.rodata+0x130): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/fujitsu.o:(.rodata+0x58): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/gigadevice.o:(.rodata+0x250): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/intel.o:(.rodata+0xe8): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/issi.o:(.rodata+0x458): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/macronix.o:(.rodata+0x800): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/micron-st.o:(.rodata+0xe88): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/spansion.o:(.rodata+0x9b0): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/sst.o: in function `.LANCHOR0':
   sst.c:(.rodata+0x48c): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/winbond.o: in function `.LANCHOR0':
   winbond.c:(.rodata+0x978): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/xilinx.o:(.rodata+0x188): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/xmc.o:(.rodata+0xa0): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 18:00     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 18:00 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

Hi Miquel,

I love your patch! Yet something to improve:

[auto build test ERROR on broonie-spi/for-next]
[also build test ERROR on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: arm-buildonly-randconfig-r006-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170120.4tAlxDnn-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/gigadevice.o: in function `.LANCHOR0':
>> gigadevice.c:(.rodata+0x464): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/macronix.o: in function `.LANCHOR0':
   macronix.c:(.rodata+0x8d4): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/micron.o: in function `.LANCHOR0':
   micron.c:(.rodata+0x4cc): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/paragon.o: in function `.LANCHOR0':
   paragon.c:(.rodata+0x144): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/toshiba.o: in function `.LANCHOR0':
   toshiba.c:(.rodata+0x664): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/winbond.o:(.rodata+0x114): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
--
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/sfdp.o: in function `.LANCHOR0':
>> sfdp.c:(.rodata+0x278): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/swp.o: in function `.LANCHOR0':
   swp.c:(.rodata+0x24): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/otp.o: in function `.LANCHOR0':
   otp.c:(.rodata+0xc): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/sysfs.o:(.rodata+0x14): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/atmel.o: in function `.LANCHOR0':
   atmel.c:(.rodata+0x3d0): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/catalyst.o:(.rodata+0x178): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/eon.o:(.rodata+0x370): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/esmt.o:(.rodata+0xe8): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/everspin.o:(.rodata+0x130): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/fujitsu.o:(.rodata+0x58): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/gigadevice.o:(.rodata+0x250): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/intel.o:(.rodata+0xe8): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/issi.o:(.rodata+0x458): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/macronix.o:(.rodata+0x800): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/micron-st.o:(.rodata+0xe88): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/spansion.o:(.rodata+0x9b0): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/sst.o: in function `.LANCHOR0':
   sst.c:(.rodata+0x48c): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/winbond.o: in function `.LANCHOR0':
   winbond.c:(.rodata+0x978): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/xilinx.o:(.rodata+0x188): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/xmc.o:(.rodata+0xa0): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 18:00     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 18:00 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 6977 bytes --]

Hi Miquel,

I love your patch! Yet something to improve:

[auto build test ERROR on broonie-spi/for-next]
[also build test ERROR on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: arm-buildonly-randconfig-r006-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170120.4tAlxDnn-lkp(a)intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/gigadevice.o: in function `.LANCHOR0':
>> gigadevice.c:(.rodata+0x464): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/macronix.o: in function `.LANCHOR0':
   macronix.c:(.rodata+0x8d4): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/micron.o: in function `.LANCHOR0':
   micron.c:(.rodata+0x4cc): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/paragon.o: in function `.LANCHOR0':
   paragon.c:(.rodata+0x144): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/toshiba.o: in function `.LANCHOR0':
   toshiba.c:(.rodata+0x664): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/nand/spi/winbond.o:(.rodata+0x114): multiple definition of `spi_mem_no_caps'; drivers/mtd/nand/spi/core.o:core.c:(.rodata+0x2e8): first defined here
--
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/sfdp.o: in function `.LANCHOR0':
>> sfdp.c:(.rodata+0x278): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/swp.o: in function `.LANCHOR0':
   swp.c:(.rodata+0x24): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/otp.o: in function `.LANCHOR0':
   otp.c:(.rodata+0xc): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/sysfs.o:(.rodata+0x14): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/atmel.o: in function `.LANCHOR0':
   atmel.c:(.rodata+0x3d0): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/catalyst.o:(.rodata+0x178): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/eon.o:(.rodata+0x370): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/esmt.o:(.rodata+0xe8): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/everspin.o:(.rodata+0x130): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/fujitsu.o:(.rodata+0x58): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/gigadevice.o:(.rodata+0x250): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/intel.o:(.rodata+0xe8): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/issi.o:(.rodata+0x458): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/macronix.o:(.rodata+0x800): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/micron-st.o:(.rodata+0xe88): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/spansion.o:(.rodata+0x9b0): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/sst.o: in function `.LANCHOR0':
   sst.c:(.rodata+0x48c): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/winbond.o: in function `.LANCHOR0':
   winbond.c:(.rodata+0x978): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/xilinx.o:(.rodata+0x188): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here
   arm-linux-gnueabi-ld: drivers/mtd/spi-nor/xmc.o:(.rodata+0xa0): multiple definition of `spi_mem_no_caps'; drivers/mtd/spi-nor/core.o:core.c:(.rodata+0xfbc): first defined here

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
  2021-12-16 11:16   ` Miquel Raynal
  (?)
@ 2021-12-16 18:21     ` kernel test robot
  -1 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 18:21 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: llvm, kbuild-all

Hi Miquel,

I love your patch! Yet something to improve:

[auto build test ERROR on broonie-spi/for-next]
[also build test ERROR on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: hexagon-randconfig-r045-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170259.JPoGT6na-lkp@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project dd245bab9fbb364faa1581e4f92ba3119a872fba)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=hexagon SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at gigadevice.c
   >>> mtd/nand/spi/gigadevice.o:(.rodata+0x35C) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at macronix.c
   >>> mtd/nand/spi/macronix.o:(.rodata+0x83C) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at sysfs.c
   >>> mtd/spi-nor/sysfs.o:(.rodata+0x14) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at atmel.c
   >>> mtd/spi-nor/atmel.o:(.rodata+0x370) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at catalyst.c
   >>> mtd/spi-nor/catalyst.o:(.rodata+0x178) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at eon.c
   >>> mtd/spi-nor/eon.o:(.rodata+0x370) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at esmt.c
   >>> mtd/spi-nor/esmt.o:(.rodata+0xE8) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at everspin.c
   >>> mtd/spi-nor/everspin.o:(.rodata+0x130) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at fujitsu.c
   >>> mtd/spi-nor/fujitsu.o:(.rodata+0x58) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at gigadevice.c
   >>> mtd/spi-nor/gigadevice.o:(.rodata+0x250) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at intel.c
   >>> mtd/spi-nor/intel.o:(.rodata+0xE8) in archive drivers/built-in.a
..

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 18:21     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 18:21 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: llvm, kbuild-all

Hi Miquel,

I love your patch! Yet something to improve:

[auto build test ERROR on broonie-spi/for-next]
[also build test ERROR on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: hexagon-randconfig-r045-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170259.JPoGT6na-lkp@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project dd245bab9fbb364faa1581e4f92ba3119a872fba)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=hexagon SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at gigadevice.c
   >>> mtd/nand/spi/gigadevice.o:(.rodata+0x35C) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at macronix.c
   >>> mtd/nand/spi/macronix.o:(.rodata+0x83C) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at sysfs.c
   >>> mtd/spi-nor/sysfs.o:(.rodata+0x14) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at atmel.c
   >>> mtd/spi-nor/atmel.o:(.rodata+0x370) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at catalyst.c
   >>> mtd/spi-nor/catalyst.o:(.rodata+0x178) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at eon.c
   >>> mtd/spi-nor/eon.o:(.rodata+0x370) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at esmt.c
   >>> mtd/spi-nor/esmt.o:(.rodata+0xE8) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at everspin.c
   >>> mtd/spi-nor/everspin.o:(.rodata+0x130) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at fujitsu.c
   >>> mtd/spi-nor/fujitsu.o:(.rodata+0x58) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at gigadevice.c
   >>> mtd/spi-nor/gigadevice.o:(.rodata+0x250) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at intel.c
   >>> mtd/spi-nor/intel.o:(.rodata+0xE8) in archive drivers/built-in.a
..

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 18:21     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 18:21 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 4714 bytes --]

Hi Miquel,

I love your patch! Yet something to improve:

[auto build test ERROR on broonie-spi/for-next]
[also build test ERROR on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: hexagon-randconfig-r045-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170259.JPoGT6na-lkp(a)intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project dd245bab9fbb364faa1581e4f92ba3119a872fba)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=hexagon SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at gigadevice.c
   >>> mtd/nand/spi/gigadevice.o:(.rodata+0x35C) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at macronix.c
   >>> mtd/nand/spi/macronix.o:(.rodata+0x83C) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at sysfs.c
   >>> mtd/spi-nor/sysfs.o:(.rodata+0x14) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at atmel.c
   >>> mtd/spi-nor/atmel.o:(.rodata+0x370) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at catalyst.c
   >>> mtd/spi-nor/catalyst.o:(.rodata+0x178) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at eon.c
   >>> mtd/spi-nor/eon.o:(.rodata+0x370) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at esmt.c
   >>> mtd/spi-nor/esmt.o:(.rodata+0xE8) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at everspin.c
   >>> mtd/spi-nor/everspin.o:(.rodata+0x130) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at fujitsu.c
   >>> mtd/spi-nor/fujitsu.o:(.rodata+0x58) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at gigadevice.c
   >>> mtd/spi-nor/gigadevice.o:(.rodata+0x250) in archive drivers/built-in.a
--
>> ld.lld: error: duplicate symbol: spi_mem_no_caps
   >>> defined at core.c
   >>> mtd/nand/spi/core.o:(spi_mem_no_caps) in archive drivers/built-in.a
   >>> defined at intel.c
   >>> mtd/spi-nor/intel.o:(.rodata+0xE8) in archive drivers/built-in.a
..

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
  2021-12-16 11:16   ` Miquel Raynal
  (?)
@ 2021-12-16 18:52     ` kernel test robot
  -1 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 18:52 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

Hi Miquel,

I love your patch! Yet something to improve:

[auto build test ERROR on broonie-spi/for-next]
[also build test ERROR on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: openrisc-randconfig-r036-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170204.FjtWNBvt-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=openrisc SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> or1k-linux-ld: drivers/spi/spi-dw-core.o:(.rodata+0x0): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here
   or1k-linux-ld: drivers/spi/spi-dw-dma.o:(.rodata+0x30): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here
   or1k-linux-ld: drivers/spi/spi-nxp-fspi.o:(.rodata+0x51c): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here
   or1k-linux-ld: drivers/spi/spi-zynqmp-gqspi.o:(.rodata+0x20c): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 18:52     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 18:52 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

Hi Miquel,

I love your patch! Yet something to improve:

[auto build test ERROR on broonie-spi/for-next]
[also build test ERROR on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: openrisc-randconfig-r036-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170204.FjtWNBvt-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=openrisc SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> or1k-linux-ld: drivers/spi/spi-dw-core.o:(.rodata+0x0): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here
   or1k-linux-ld: drivers/spi/spi-dw-dma.o:(.rodata+0x30): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here
   or1k-linux-ld: drivers/spi/spi-nxp-fspi.o:(.rodata+0x51c): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here
   or1k-linux-ld: drivers/spi/spi-zynqmp-gqspi.o:(.rodata+0x20c): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 18:52     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 18:52 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]

Hi Miquel,

I love your patch! Yet something to improve:

[auto build test ERROR on broonie-spi/for-next]
[also build test ERROR on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: openrisc-randconfig-r036-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170204.FjtWNBvt-lkp(a)intel.com/config)
compiler: or1k-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=openrisc SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> or1k-linux-ld: drivers/spi/spi-dw-core.o:(.rodata+0x0): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here
   or1k-linux-ld: drivers/spi/spi-dw-dma.o:(.rodata+0x30): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here
   or1k-linux-ld: drivers/spi/spi-nxp-fspi.o:(.rodata+0x51c): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here
   or1k-linux-ld: drivers/spi/spi-zynqmp-gqspi.o:(.rodata+0x20c): multiple definition of `spi_mem_no_caps'; drivers/spi/spi.o:(.rodata+0x40): first defined here

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 119+ messages in thread

* [RFC PATCH] spi: spi-mem: mxic_spi_mem_caps can be static
  2021-12-16 11:16   ` Miquel Raynal
  (?)
@ 2021-12-16 20:10     ` kernel test robot
  -1 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:10 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

drivers/spi/spi-mxic.c:446:38: warning: symbol 'mxic_spi_mem_caps' was not declared. Should it be static?

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: kernel test robot <lkp@intel.com>
---
 spi-mxic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 8f8530bd37794..e137b1ec85d40 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -443,7 +443,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 	return ret;
 }
 
-const struct spi_controller_mem_caps mxic_spi_mem_caps = {
+static const struct spi_controller_mem_caps mxic_spi_mem_caps = {
 	.dtr = true,
 };
 

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [RFC PATCH] spi: spi-mem: mxic_spi_mem_caps can be static
@ 2021-12-16 20:10     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:10 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

drivers/spi/spi-mxic.c:446:38: warning: symbol 'mxic_spi_mem_caps' was not declared. Should it be static?

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: kernel test robot <lkp@intel.com>
---
 spi-mxic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 8f8530bd37794..e137b1ec85d40 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -443,7 +443,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 	return ret;
 }
 
-const struct spi_controller_mem_caps mxic_spi_mem_caps = {
+static const struct spi_controller_mem_caps mxic_spi_mem_caps = {
 	.dtr = true,
 };
 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [RFC PATCH] spi: spi-mem: mxic_spi_mem_caps can be static
@ 2021-12-16 20:10     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:10 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

drivers/spi/spi-mxic.c:446:38: warning: symbol 'mxic_spi_mem_caps' was not declared. Should it be static?

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: kernel test robot <lkp@intel.com>
---
 spi-mxic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 8f8530bd37794..e137b1ec85d40 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -443,7 +443,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
 	return ret;
 }
 
-const struct spi_controller_mem_caps mxic_spi_mem_caps = {
+static const struct spi_controller_mem_caps mxic_spi_mem_caps = {
 	.dtr = true,
 };
 

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
  2021-12-16 11:16   ` Miquel Raynal
  (?)
@ 2021-12-16 20:14     ` kernel test robot
  -1 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:14 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

Hi Miquel,

I love your patch! Perhaps something to improve:

[auto build test WARNING on broonie-spi/for-next]
[also build test WARNING on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: i386-randconfig-s031-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170416.Ew8eShY1-lkp@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/spi/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
   drivers/spi/spi-mxic.c: note: in included file:
   include/linux/spi/spi-mem.h:369:38: sparse: sparse: symbol 'spi_mem_no_caps' was not declared. Should it be static?
>> drivers/spi/spi-mxic.c:446:38: sparse: sparse: symbol 'mxic_spi_mem_caps' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 20:14     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:14 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

Hi Miquel,

I love your patch! Perhaps something to improve:

[auto build test WARNING on broonie-spi/for-next]
[also build test WARNING on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: i386-randconfig-s031-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170416.Ew8eShY1-lkp@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/spi/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
   drivers/spi/spi-mxic.c: note: in included file:
   include/linux/spi/spi-mem.h:369:38: sparse: sparse: symbol 'spi_mem_no_caps' was not declared. Should it be static?
>> drivers/spi/spi-mxic.c:446:38: sparse: sparse: symbol 'mxic_spi_mem_caps' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 20:14     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:14 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

Hi Miquel,

I love your patch! Perhaps something to improve:

[auto build test WARNING on broonie-spi/for-next]
[also build test WARNING on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: i386-randconfig-s031-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170416.Ew8eShY1-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/spi/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
   drivers/spi/spi-mxic.c: note: in included file:
   include/linux/spi/spi-mem.h:369:38: sparse: sparse: symbol 'spi_mem_no_caps' was not declared. Should it be static?
>> drivers/spi/spi-mxic.c:446:38: sparse: sparse: symbol 'mxic_spi_mem_caps' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 119+ messages in thread

* [RFC PATCH] spi: spi-mem: cqspi_mem_caps can be static
  2021-12-16 11:16   ` Miquel Raynal
  (?)
@ 2021-12-16 20:14     ` kernel test robot
  -1 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:14 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

drivers/spi/spi-cadence-quadspi.c:1592:38: warning: symbol 'cqspi_mem_caps' was not declared. Should it be static?

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: kernel test robot <lkp@intel.com>
---
 spi-cadence-quadspi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index bc7ae56fe565fb..ca05ab4d0c5923 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1589,7 +1589,7 @@ static const char *cqspi_get_name(struct spi_mem *mem)
 	return devm_kasprintf(dev, GFP_KERNEL, "%s.%d", dev_name(dev), mem->spi->chip_select);
 }
 
-const struct spi_controller_mem_caps cqspi_mem_caps = {
+static const struct spi_controller_mem_caps cqspi_mem_caps = {
 	.dtr = true,
 };
 

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [RFC PATCH] spi: spi-mem: cqspi_mem_caps can be static
@ 2021-12-16 20:14     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:14 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

drivers/spi/spi-cadence-quadspi.c:1592:38: warning: symbol 'cqspi_mem_caps' was not declared. Should it be static?

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: kernel test robot <lkp@intel.com>
---
 spi-cadence-quadspi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index bc7ae56fe565fb..ca05ab4d0c5923 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1589,7 +1589,7 @@ static const char *cqspi_get_name(struct spi_mem *mem)
 	return devm_kasprintf(dev, GFP_KERNEL, "%s.%d", dev_name(dev), mem->spi->chip_select);
 }
 
-const struct spi_controller_mem_caps cqspi_mem_caps = {
+static const struct spi_controller_mem_caps cqspi_mem_caps = {
 	.dtr = true,
 };
 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* [RFC PATCH] spi: spi-mem: cqspi_mem_caps can be static
@ 2021-12-16 20:14     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:14 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

drivers/spi/spi-cadence-quadspi.c:1592:38: warning: symbol 'cqspi_mem_caps' was not declared. Should it be static?

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: kernel test robot <lkp@intel.com>
---
 spi-cadence-quadspi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index bc7ae56fe565fb..ca05ab4d0c5923 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1589,7 +1589,7 @@ static const char *cqspi_get_name(struct spi_mem *mem)
 	return devm_kasprintf(dev, GFP_KERNEL, "%s.%d", dev_name(dev), mem->spi->chip_select);
 }
 
-const struct spi_controller_mem_caps cqspi_mem_caps = {
+static const struct spi_controller_mem_caps cqspi_mem_caps = {
 	.dtr = true,
 };
 

^ permalink raw reply related	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
  2021-12-16 11:16   ` Miquel Raynal
  (?)
@ 2021-12-16 20:24     ` kernel test robot
  -1 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:24 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

Hi Miquel,

I love your patch! Perhaps something to improve:

[auto build test WARNING on broonie-spi/for-next]
[also build test WARNING on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: i386-randconfig-s002-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170429.LyEKzvra-lkp@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/spi/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
   drivers/spi/spi-cadence-quadspi.c: note: in included file:
   include/linux/spi/spi-mem.h:369:38: sparse: sparse: symbol 'spi_mem_no_caps' was not declared. Should it be static?
>> drivers/spi/spi-cadence-quadspi.c:1592:38: sparse: sparse: symbol 'cqspi_mem_caps' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 20:24     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:24 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: kbuild-all

Hi Miquel,

I love your patch! Perhaps something to improve:

[auto build test WARNING on broonie-spi/for-next]
[also build test WARNING on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: i386-randconfig-s002-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170429.LyEKzvra-lkp@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/spi/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
   drivers/spi/spi-cadence-quadspi.c: note: in included file:
   include/linux/spi/spi-mem.h:369:38: sparse: sparse: symbol 'spi_mem_no_caps' was not declared. Should it be static?
>> drivers/spi/spi-cadence-quadspi.c:1592:38: sparse: sparse: symbol 'cqspi_mem_caps' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers
@ 2021-12-16 20:24     ` kernel test robot
  0 siblings, 0 replies; 119+ messages in thread
From: kernel test robot @ 2021-12-16 20:24 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]

Hi Miquel,

I love your patch! Perhaps something to improve:

[auto build test WARNING on broonie-spi/for-next]
[also build test WARNING on mtd/nand/next mtd/mtd/next mtd/mtd/fixes v5.16-rc5 next-20211215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: i386-randconfig-s002-20211216 (https://download.01.org/0day-ci/archive/20211217/202112170429.LyEKzvra-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Miquel-Raynal/External-ECC-engines-Macronix-support/20211216-191821
        git checkout bf16b56f7a0cc5aa237129a6b8bd216dc2632c8b
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/spi/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
   drivers/spi/spi-cadence-quadspi.c: note: in included file:
   include/linux/spi/spi-mem.h:369:38: sparse: sparse: symbol 'spi_mem_no_caps' was not declared. Should it be static?
>> drivers/spi/spi-cadence-quadspi.c:1592:38: sparse: sparse: symbol 'cqspi_mem_caps' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 03/28] dt-bindings: mtd: nand-controller: Harmonize the property types
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-16 21:09     ` Rob Herring
  -1 siblings, 0 replies; 119+ messages in thread
From: Rob Herring @ 2021-12-16 21:09 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Richard Weinberger, Tudor Ambarus, linux-mtd, Julien Su,
	Mark Brown, Vignesh Raghavendra, linux-spi, devicetree,
	Jaime Liao, Thomas Petazzoni, Pratyush Yadav, Rob Herring,
	Michael Walle

On Thu, 16 Dec 2021 12:16:29 +0100, Miquel Raynal wrote:
> Harmonize the different properties in this file by:
> * dropping the non-necessary allOf's
> * always defining the keywords in the following order:
>     - first the "description" (when relevant),
>     - then the "type"/"$ref" and the other generic keywords ("enum",
>       "default", etc).
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  .../bindings/mtd/nand-controller.yaml         | 26 +++++++++----------
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 03/28] dt-bindings: mtd: nand-controller: Harmonize the property types
@ 2021-12-16 21:09     ` Rob Herring
  0 siblings, 0 replies; 119+ messages in thread
From: Rob Herring @ 2021-12-16 21:09 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Richard Weinberger, Tudor Ambarus, linux-mtd, Julien Su,
	Mark Brown, Vignesh Raghavendra, linux-spi, devicetree,
	Jaime Liao, Thomas Petazzoni, Pratyush Yadav, Rob Herring,
	Michael Walle

On Thu, 16 Dec 2021 12:16:29 +0100, Miquel Raynal wrote:
> Harmonize the different properties in this file by:
> * dropping the non-necessary allOf's
> * always defining the keywords in the following order:
>     - first the "description" (when relevant),
>     - then the "type"/"$ref" and the other generic keywords ("enum",
>       "default", etc).
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  .../bindings/mtd/nand-controller.yaml         | 26 +++++++++----------
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 16/28] mtd: nand: mxic-ecc: Support SPI pipelined mode
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:52     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:52 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:42 UTC, Miquel Raynal wrote:
> Introduce the support for another possible configuration: the ECC
> engine may work as DMA master (pipelined) and move itself the data
> to/from the NAND chip into the buffer, applying the necessary
> corrections/computations on the fly.
> 
> This driver offers an ECC engine implementation that must be
> instatiated from a SPI controller driver.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 16/28] mtd: nand: mxic-ecc: Support SPI pipelined mode
@ 2021-12-17 15:52     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:52 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:42 UTC, Miquel Raynal wrote:
> Introduce the support for another possible configuration: the ECC
> engine may work as DMA master (pipelined) and move itself the data
> to/from the NAND chip into the buffer, applying the necessary
> corrections/computations on the fly.
> 
> This driver offers an ECC engine implementation that must be
> instatiated from a SPI controller driver.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 15/28] mtd: nand: ecc: Provide a helper to retrieve a pilelined engine device
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:52     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:52 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:41 UTC, Miquel Raynal wrote:
> In a pipelined engine situation, we might either have the host which
> internally has support for error correction, or have it using an
> external hardware block for this purpose. In the former case, the host
> is also the ECC engine. In the latter case, it is not. In order to get
> the right pointers on the right devices (for example: in order to devm_*
> allocate variables), let's introduce this helper which can safely be
> called by pipelined ECC engines in order to retrieve the right device
> structure.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 15/28] mtd: nand: ecc: Provide a helper to retrieve a pilelined engine device
@ 2021-12-17 15:52     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:52 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:41 UTC, Miquel Raynal wrote:
> In a pipelined engine situation, we might either have the host which
> internally has support for error correction, or have it using an
> external hardware block for this purpose. In the former case, the host
> is also the ECC engine. In the latter case, it is not. In order to get
> the right pointers on the right devices (for example: in order to devm_*
> allocate variables), let's introduce this helper which can safely be
> called by pipelined ECC engines in order to retrieve the right device
> structure.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 14/28] mtd: nand: mxic-ecc: Add Macronix external ECC engine support
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:53     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:40 UTC, Miquel Raynal wrote:
> Some SPI-NAND chips do not support on-die ECC. For these chips,
> correction must apply on the SPI controller end. In order to avoid
> doing all the calculations by software, Macronix provides a specific
> engine that can offload the intensive work.
> 
> Add Macronix ECC engine support, this engine can work in conjunction
> with a SPI controller and a raw NAND controller, it can be pipelined
> or external and supports linear and syndrome layouts.
> 
> Right now the simplest configuration is supported: SPI controller
> external and linear ECC engine.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 14/28] mtd: nand: mxic-ecc: Add Macronix external ECC engine support
@ 2021-12-17 15:53     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:40 UTC, Miquel Raynal wrote:
> Some SPI-NAND chips do not support on-die ECC. For these chips,
> correction must apply on the SPI controller end. In order to avoid
> doing all the calculations by software, Macronix provides a specific
> engine that can offload the intensive work.
> 
> Add Macronix ECC engine support, this engine can work in conjunction
> with a SPI controller and a raw NAND controller, it can be pipelined
> or external and supports linear and syndrome layouts.
> 
> Right now the simplest configuration is supported: SPI controller
> external and linear ECC engine.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 13/28] mtd: nand: Add a new helper to retrieve the ECC context
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:53     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:39 UTC, Miquel Raynal wrote:
> Introduce nand_to_ecc_ctx() which will allow to easily jump to the
> private pointer of an ECC context given a NAND device. This is very
> handy, from the prepare or finish ECC hook, to get the internal context
> out of the NAND device object.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 13/28] mtd: nand: Add a new helper to retrieve the ECC context
@ 2021-12-17 15:53     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:39 UTC, Miquel Raynal wrote:
> Introduce nand_to_ecc_ctx() which will allow to easily jump to the
> private pointer of an ECC context given a NAND device. This is very
> handy, from the prepare or finish ECC hook, to get the internal context
> out of the NAND device object.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 12/28] mtd: nand: ecc: Add infrastructure to support hardware engines
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:53     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:38 UTC, Miquel Raynal wrote:
> Add the necessary helpers to register/unregister hardware ECC engines
> that will be called from ECC engine drivers.
> 
> Also add helpers to get the right engine from the user
> perspective. Keep a reference of the in use ECC engine in order to
> prevent modules to be unloaded. Put the reference when the engine gets
> retired.
> 
> A static list of hardware (only) ECC engines is setup to keep track of
> the registered engines.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 12/28] mtd: nand: ecc: Add infrastructure to support hardware engines
@ 2021-12-17 15:53     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:38 UTC, Miquel Raynal wrote:
> Add the necessary helpers to register/unregister hardware ECC engines
> that will be called from ECC engine drivers.
> 
> Also add helpers to get the right engine from the user
> perspective. Keep a reference of the in use ECC engine in order to
> prevent modules to be unloaded. Put the reference when the engine gets
> retired.
> 
> A static list of hardware (only) ECC engines is setup to keep track of
> the registered engines.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 11/28] mtd: spinand: macronix: Use random program load
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:53     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Mason Yang

On Thu, 2021-12-16 at 11:16:37 UTC, Miquel Raynal wrote:
> From: Mason Yang <masonccyang@mxic.com.tw>
> 
> Macronix SPI-NAND chips might benefit from an external ECC
> engine. Such an engine might need to access random columns, thus needing
> to use random commands (0x84 instead of 0x02).
> 
> Signed-off-by: Mason Yang <masonccyang@mxic.com.tw>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 11/28] mtd: spinand: macronix: Use random program load
@ 2021-12-17 15:53     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Mason Yang

On Thu, 2021-12-16 at 11:16:37 UTC, Miquel Raynal wrote:
> From: Mason Yang <masonccyang@mxic.com.tw>
> 
> Macronix SPI-NAND chips might benefit from an external ECC
> engine. Such an engine might need to access random columns, thus needing
> to use random commands (0x84 instead of 0x02).
> 
> Signed-off-by: Mason Yang <masonccyang@mxic.com.tw>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 10/28] dt-bindings: mtd: Describe Macronix NAND ECC engine
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:53     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:36 UTC, Miquel Raynal wrote:
> Describe Macronix NAND ECC engine. This engine may be used as an
> external engine or can be pipelined with either a raw NAND controller or
> a SPI controller. Both hardware designs with a SPI controller are shown
> in the examples.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 10/28] dt-bindings: mtd: Describe Macronix NAND ECC engine
@ 2021-12-17 15:53     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:36 UTC, Miquel Raynal wrote:
> Describe Macronix NAND ECC engine. This engine may be used as an
> external engine or can be pipelined with either a raw NAND controller or
> a SPI controller. Both hardware designs with a SPI controller are shown
> in the examples.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 09/28] dt-bindings: spi: mxic: Document the nand-ecc-engine property
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:53     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:35 UTC, Miquel Raynal wrote:
> This SPI controller supports interacting with an external ECC
> engine. The nand-ecc-engine property already exist in the NAND world but
> also applies to SPI controller nodes which have external correction
> capabilities like Macronix's.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 09/28] dt-bindings: spi: mxic: Document the nand-ecc-engine property
@ 2021-12-17 15:53     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:35 UTC, Miquel Raynal wrote:
> This SPI controller supports interacting with an external ECC
> engine. The nand-ecc-engine property already exist in the NAND world but
> also applies to SPI controller nodes which have external correction
> capabilities like Macronix's.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 08/28] dt-bindings: spi: mxic: Convert to yaml
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:53     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:34 UTC, Miquel Raynal wrote:
> Straightforward conversion from regular text to yaml schema of the
> Macronix SPI controller DT bindings.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 08/28] dt-bindings: spi: mxic: Convert to yaml
@ 2021-12-17 15:53     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:34 UTC, Miquel Raynal wrote:
> Straightforward conversion from regular text to yaml schema of the
> Macronix SPI controller DT bindings.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 07/28] dt-bindings: spi: mxic: The interrupt property is not mandatory
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:53     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:33 UTC, Miquel Raynal wrote:
> The interrupt property is not mandatory at all, this property should not
> be part of the required properties list, so move it into the optional
> properties list.
> 
> Fixes: 326e5c8d4a87 ("dt-binding: spi: Document Macronix controller bindings")
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 07/28] dt-bindings: spi: mxic: The interrupt property is not mandatory
@ 2021-12-17 15:53     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:53 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:33 UTC, Miquel Raynal wrote:
> The interrupt property is not mandatory at all, this property should not
> be part of the required properties list, so move it into the optional
> properties list.
> 
> Fixes: 326e5c8d4a87 ("dt-binding: spi: Document Macronix controller bindings")
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 06/28] dt-bindings: vendor-prefixes: Clarify Macronix prefix
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:54     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:32 UTC, Miquel Raynal wrote:
> When looking at compatible prefixes, Macronix is sometimes referred as
> "mxicy":
> - mxicy,mx25r1635f
> - mxicy,mx25u6435f
> - mxicy,mx25v8035f
> - mxicy,mx25f0a-spi
> and sometimes as "mxic":
> - mxic,multi-itfc-v009-nand-controller
> - mxic,enable-randomizer-otp
> 
> The oldest prefix that is also the one preferred by Macronix engineers
> is "mxicy", so document the other one and mark it deprecated.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 06/28] dt-bindings: vendor-prefixes: Clarify Macronix prefix
@ 2021-12-17 15:54     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:32 UTC, Miquel Raynal wrote:
> When looking at compatible prefixes, Macronix is sometimes referred as
> "mxicy":
> - mxicy,mx25r1635f
> - mxicy,mx25u6435f
> - mxicy,mx25v8035f
> - mxicy,mx25f0a-spi
> and sometimes as "mxic":
> - mxic,multi-itfc-v009-nand-controller
> - mxic,enable-randomizer-otp
> 
> The oldest prefix that is also the one preferred by Macronix engineers
> is "mxicy", so document the other one and mark it deprecated.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 05/28] dt-bindings: mtd: spi-nand: Convert spi-nand description file to yaml
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:54     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:31 UTC, Miquel Raynal wrote:
> Let's get rid of spi-nand.txt by converting it to yaml schema. While at
> converting this file, let's actually pull all the generic properties
> from nand-chip.yaml which might apply to a SPI-NAND chip.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 05/28] dt-bindings: mtd: spi-nand: Convert spi-nand description file to yaml
@ 2021-12-17 15:54     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:31 UTC, Miquel Raynal wrote:
> Let's get rid of spi-nand.txt by converting it to yaml schema. While at
> converting this file, let's actually pull all the generic properties
> from nand-chip.yaml which might apply to a SPI-NAND chip.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 04/28] dt-bindings: mtd: nand-chip: Create a NAND chip description
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:54     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:30 UTC, Miquel Raynal wrote:
> Move the NAND chip description out of the NAND controller file. Indeed,
> a subsequent part of the properties supported by a raw NAND chip are
> also supported by SPI-NAND chips. So let's create a generic NAND chip
> description which will be pulled by nand-controller.yaml and later by
> spi-nand.yaml as well.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 04/28] dt-bindings: mtd: nand-chip: Create a NAND chip description
@ 2021-12-17 15:54     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:30 UTC, Miquel Raynal wrote:
> Move the NAND chip description out of the NAND controller file. Indeed,
> a subsequent part of the properties supported by a raw NAND chip are
> also supported by SPI-NAND chips. So let's create a generic NAND chip
> description which will be pulled by nand-controller.yaml and later by
> spi-nand.yaml as well.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 03/28] dt-bindings: mtd: nand-controller: Harmonize the property types
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:54     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:29 UTC, Miquel Raynal wrote:
> Harmonize the different properties in this file by:
> * dropping the non-necessary allOf's
> * always defining the keywords in the following order:
>     - first the "description" (when relevant),
>     - then the "type"/"$ref" and the other generic keywords ("enum",
>       "default", etc).
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 03/28] dt-bindings: mtd: nand-controller: Harmonize the property types
@ 2021-12-17 15:54     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni

On Thu, 2021-12-16 at 11:16:29 UTC, Miquel Raynal wrote:
> Harmonize the different properties in this file by:
> * dropping the non-necessary allOf's
> * always defining the keywords in the following order:
>     - first the "description" (when relevant),
>     - then the "type"/"$ref" and the other generic keywords ("enum",
>       "default", etc).
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 02/28] dt-bindings: mtd: nand-controller: Fix a comment in the examples
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:54     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:28 UTC, Miquel Raynal wrote:
> The controller properties should be in the controller 'parent' node,
> while properties in the children nodes are specific to the NAND
> *chip*. This error was already present during the yaml conversion.
> 
> Fixes: 2d472aba15ff ("mtd: nand: document the NAND controller/NAND chip DT representation")
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Acked-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 02/28] dt-bindings: mtd: nand-controller: Fix a comment in the examples
@ 2021-12-17 15:54     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:28 UTC, Miquel Raynal wrote:
> The controller properties should be in the controller 'parent' node,
> while properties in the children nodes are specific to the NAND
> *chip*. This error was already present during the yaml conversion.
> 
> Fixes: 2d472aba15ff ("mtd: nand: document the NAND controller/NAND chip DT representation")
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Acked-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 01/28] dt-bindings: mtd: nand-controller: Fix the reg property description
  2021-12-16 11:16   ` Miquel Raynal
@ 2021-12-17 15:54     ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:27 UTC, Miquel Raynal wrote:
> The reg property of a NAND device always references the chip-select(s).
> The ready/busy lines are described in the nand-rb property. I believe
> this was a harmless copy/paste error during the conversion to yaml.
> 
> Fixes: 212e49693592 ("dt-bindings: mtd: Add YAML schemas for the generic NAND options")
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Acked-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 01/28] dt-bindings: mtd: nand-controller: Fix the reg property description
@ 2021-12-17 15:54     ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2021-12-17 15:54 UTC (permalink / raw)
  To: Miquel Raynal, Mark Brown, linux-spi, Richard Weinberger,
	Vignesh Raghavendra, Tudor Ambarus, Pratyush Yadav,
	Michael Walle, linux-mtd, Rob Herring, devicetree
  Cc: Julien Su, Jaime Liao, Thomas Petazzoni, Rob Herring

On Thu, 2021-12-16 at 11:16:27 UTC, Miquel Raynal wrote:
> The reg property of a NAND device always references the chip-select(s).
> The ready/busy lines are described in the nand-rb property. I believe
> this was a harmless copy/paste error during the conversion to yaml.
> 
> Fixes: 212e49693592 ("dt-bindings: mtd: Add YAML schemas for the generic NAND options")
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Acked-by: Rob Herring <robh@kernel.org>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 14/28] mtd: nand: mxic-ecc: Add Macronix external ECC engine support
  2021-12-16 11:16   ` Miquel Raynal
@ 2022-02-22 10:39     ` Geert Uytterhoeven
  -1 siblings, 0 replies; 119+ messages in thread
From: Geert Uytterhoeven @ 2022-02-22 10:39 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, MTD Maling List,
	Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Julien Su, Jaime Liao, Thomas Petazzoni

Hi Miquel,

On Thu, Dec 16, 2021 at 12:48 PM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
> Some SPI-NAND chips do not support on-die ECC. For these chips,
> correction must apply on the SPI controller end. In order to avoid
> doing all the calculations by software, Macronix provides a specific
> engine that can offload the intensive work.
>
> Add Macronix ECC engine support, this engine can work in conjunction
> with a SPI controller and a raw NAND controller, it can be pipelined
> or external and supports linear and syndrome layouts.
>
> Right now the simplest configuration is supported: SPI controller
> external and linear ECC engine.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Thanks for your patch!

> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -46,6 +46,12 @@ config MTD_NAND_ECC_SW_BCH
>           ECC codes. They are used with NAND devices requiring more than 1 bit
>           of error correction.
>
> +config MTD_NAND_ECC_MXIC
> +       bool "Macronix external hardware ECC engine"
> +       select MTD_NAND_ECC
> +       help
> +         This enables support for the hardware ECC engine from Macronix.

I guess this is a licensable IP core, which can appear anywhere, so
we don't have a proper platform dependency to add here?

> +
>  endmenu
>
>  endmenu

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 14/28] mtd: nand: mxic-ecc: Add Macronix external ECC engine support
@ 2022-02-22 10:39     ` Geert Uytterhoeven
  0 siblings, 0 replies; 119+ messages in thread
From: Geert Uytterhoeven @ 2022-02-22 10:39 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, MTD Maling List,
	Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Julien Su, Jaime Liao, Thomas Petazzoni

Hi Miquel,

On Thu, Dec 16, 2021 at 12:48 PM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
> Some SPI-NAND chips do not support on-die ECC. For these chips,
> correction must apply on the SPI controller end. In order to avoid
> doing all the calculations by software, Macronix provides a specific
> engine that can offload the intensive work.
>
> Add Macronix ECC engine support, this engine can work in conjunction
> with a SPI controller and a raw NAND controller, it can be pipelined
> or external and supports linear and syndrome layouts.
>
> Right now the simplest configuration is supported: SPI controller
> external and linear ECC engine.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Thanks for your patch!

> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -46,6 +46,12 @@ config MTD_NAND_ECC_SW_BCH
>           ECC codes. They are used with NAND devices requiring more than 1 bit
>           of error correction.
>
> +config MTD_NAND_ECC_MXIC
> +       bool "Macronix external hardware ECC engine"
> +       select MTD_NAND_ECC
> +       help
> +         This enables support for the hardware ECC engine from Macronix.

I guess this is a licensable IP core, which can appear anywhere, so
we don't have a proper platform dependency to add here?

> +
>  endmenu
>
>  endmenu

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 14/28] mtd: nand: mxic-ecc: Add Macronix external ECC engine support
  2022-02-22 10:39     ` Geert Uytterhoeven
@ 2022-02-22 10:41       ` Miquel Raynal
  -1 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2022-02-22 10:41 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, MTD Maling List,
	Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Julien Su, Jaime Liao, Thomas Petazzoni

Hi Geert,

geert@linux-m68k.org wrote on Tue, 22 Feb 2022 11:39:34 +0100:

> Hi Miquel,
> 
> On Thu, Dec 16, 2021 at 12:48 PM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> > Some SPI-NAND chips do not support on-die ECC. For these chips,
> > correction must apply on the SPI controller end. In order to avoid
> > doing all the calculations by software, Macronix provides a specific
> > engine that can offload the intensive work.
> >
> > Add Macronix ECC engine support, this engine can work in conjunction
> > with a SPI controller and a raw NAND controller, it can be pipelined
> > or external and supports linear and syndrome layouts.
> >
> > Right now the simplest configuration is supported: SPI controller
> > external and linear ECC engine.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>  
> 
> Thanks for your patch!
> 
> > --- a/drivers/mtd/nand/Kconfig
> > +++ b/drivers/mtd/nand/Kconfig
> > @@ -46,6 +46,12 @@ config MTD_NAND_ECC_SW_BCH
> >           ECC codes. They are used with NAND devices requiring more than 1 bit
> >           of error correction.
> >
> > +config MTD_NAND_ECC_MXIC
> > +       bool "Macronix external hardware ECC engine"
> > +       select MTD_NAND_ECC
> > +       help
> > +         This enables support for the hardware ECC engine from Macronix.  
> 
> I guess this is a licensable IP core, which can appear anywhere, so
> we don't have a proper platform dependency to add here?

Yes, I am not aware of any limitation on that side.

Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: [PATCH v6 14/28] mtd: nand: mxic-ecc: Add Macronix external ECC engine support
@ 2022-02-22 10:41       ` Miquel Raynal
  0 siblings, 0 replies; 119+ messages in thread
From: Miquel Raynal @ 2022-02-22 10:41 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Mark Brown, linux-spi, Richard Weinberger, Vignesh Raghavendra,
	Tudor Ambarus, Pratyush Yadav, Michael Walle, MTD Maling List,
	Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Julien Su, Jaime Liao, Thomas Petazzoni

Hi Geert,

geert@linux-m68k.org wrote on Tue, 22 Feb 2022 11:39:34 +0100:

> Hi Miquel,
> 
> On Thu, Dec 16, 2021 at 12:48 PM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> > Some SPI-NAND chips do not support on-die ECC. For these chips,
> > correction must apply on the SPI controller end. In order to avoid
> > doing all the calculations by software, Macronix provides a specific
> > engine that can offload the intensive work.
> >
> > Add Macronix ECC engine support, this engine can work in conjunction
> > with a SPI controller and a raw NAND controller, it can be pipelined
> > or external and supports linear and syndrome layouts.
> >
> > Right now the simplest configuration is supported: SPI controller
> > external and linear ECC engine.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>  
> 
> Thanks for your patch!
> 
> > --- a/drivers/mtd/nand/Kconfig
> > +++ b/drivers/mtd/nand/Kconfig
> > @@ -46,6 +46,12 @@ config MTD_NAND_ECC_SW_BCH
> >           ECC codes. They are used with NAND devices requiring more than 1 bit
> >           of error correction.
> >
> > +config MTD_NAND_ECC_MXIC
> > +       bool "Macronix external hardware ECC engine"
> > +       select MTD_NAND_ECC
> > +       help
> > +         This enables support for the hardware ECC engine from Macronix.  
> 
> I guess this is a licensable IP core, which can appear anywhere, so
> we don't have a proper platform dependency to add here?

Yes, I am not aware of any limitation on that side.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 119+ messages in thread

end of thread, other threads:[~2022-02-22 10:42 UTC | newest]

Thread overview: 119+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-16 11:16 [PATCH v6 00/28] External ECC engines & Macronix support Miquel Raynal
2021-12-16 11:16 ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 01/28] dt-bindings: mtd: nand-controller: Fix the reg property description Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:54   ` Miquel Raynal
2021-12-17 15:54     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 02/28] dt-bindings: mtd: nand-controller: Fix a comment in the examples Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:54   ` Miquel Raynal
2021-12-17 15:54     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 03/28] dt-bindings: mtd: nand-controller: Harmonize the property types Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 21:09   ` Rob Herring
2021-12-16 21:09     ` Rob Herring
2021-12-17 15:54   ` Miquel Raynal
2021-12-17 15:54     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 04/28] dt-bindings: mtd: nand-chip: Create a NAND chip description Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:54   ` Miquel Raynal
2021-12-17 15:54     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 05/28] dt-bindings: mtd: spi-nand: Convert spi-nand description file to yaml Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:54   ` Miquel Raynal
2021-12-17 15:54     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 06/28] dt-bindings: vendor-prefixes: Clarify Macronix prefix Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:54   ` Miquel Raynal
2021-12-17 15:54     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 07/28] dt-bindings: spi: mxic: The interrupt property is not mandatory Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:53   ` Miquel Raynal
2021-12-17 15:53     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 08/28] dt-bindings: spi: mxic: Convert to yaml Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:53   ` Miquel Raynal
2021-12-17 15:53     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 09/28] dt-bindings: spi: mxic: Document the nand-ecc-engine property Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:53   ` Miquel Raynal
2021-12-17 15:53     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 10/28] dt-bindings: mtd: Describe Macronix NAND ECC engine Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:53   ` Miquel Raynal
2021-12-17 15:53     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 11/28] mtd: spinand: macronix: Use random program load Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:53   ` Miquel Raynal
2021-12-17 15:53     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 12/28] mtd: nand: ecc: Add infrastructure to support hardware engines Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:53   ` Miquel Raynal
2021-12-17 15:53     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 13/28] mtd: nand: Add a new helper to retrieve the ECC context Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:53   ` Miquel Raynal
2021-12-17 15:53     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 14/28] mtd: nand: mxic-ecc: Add Macronix external ECC engine support Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:53   ` Miquel Raynal
2021-12-17 15:53     ` Miquel Raynal
2022-02-22 10:39   ` Geert Uytterhoeven
2022-02-22 10:39     ` Geert Uytterhoeven
2022-02-22 10:41     ` Miquel Raynal
2022-02-22 10:41       ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 15/28] mtd: nand: ecc: Provide a helper to retrieve a pilelined engine device Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:52   ` Miquel Raynal
2021-12-17 15:52     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 16/28] mtd: nand: mxic-ecc: Support SPI pipelined mode Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-17 15:52   ` Miquel Raynal
2021-12-17 15:52     ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 17/28] mtd: spinand: Delay a little bit the dirmap creation Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 18/28] spi: spi-mem: Fix a DTR related check in spi_mem_dtr_supports_op() Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 19/28] spi: spi-mem: Introduce a capability structure Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 15:52   ` Miquel Raynal
2021-12-16 15:52     ` Miquel Raynal
2021-12-16 18:00   ` kernel test robot
2021-12-16 18:00     ` kernel test robot
2021-12-16 18:00     ` kernel test robot
2021-12-16 18:21   ` kernel test robot
2021-12-16 18:21     ` kernel test robot
2021-12-16 18:21     ` kernel test robot
2021-12-16 18:52   ` kernel test robot
2021-12-16 18:52     ` kernel test robot
2021-12-16 18:52     ` kernel test robot
2021-12-16 20:10   ` [RFC PATCH] spi: spi-mem: mxic_spi_mem_caps can be static kernel test robot
2021-12-16 20:10     ` kernel test robot
2021-12-16 20:10     ` kernel test robot
2021-12-16 20:14   ` [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers kernel test robot
2021-12-16 20:14     ` kernel test robot
2021-12-16 20:14     ` kernel test robot
2021-12-16 20:14   ` [RFC PATCH] spi: spi-mem: cqspi_mem_caps can be static kernel test robot
2021-12-16 20:14     ` kernel test robot
2021-12-16 20:14     ` kernel test robot
2021-12-16 20:24   ` [PATCH v6 20/28] spi: spi-mem: Fill the spi-mem controller capabilities of all the drivers kernel test robot
2021-12-16 20:24     ` kernel test robot
2021-12-16 20:24     ` kernel test robot
2021-12-16 11:16 ` [PATCH v6 21/28] spi: spi-mem: Kill the spi_mem_dtr_supports_op() helper Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 22/28] spi: spi-mem: Add an ecc_en parameter to the spi_mem_op structure Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 23/28] mtd: spinand: Create direct mapping descriptors for ECC operations Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 24/28] spi: mxic: Fix the transmit path Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 25/28] spi: mxic: Create a helper to configure the controller before an operation Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 26/28] spi: mxic: Create a helper to ease the start of " Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 27/28] spi: mxic: Add support for direct mapping Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal
2021-12-16 11:16 ` [PATCH v6 28/28] spi: mxic: Add support for pipelined ECC operations Miquel Raynal
2021-12-16 11:16   ` Miquel Raynal

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.