commit 
fc9e18f9e987ad46722dad53adab1c12148c213c upstream.
Under the following conditions:
* after rounding up by 4 the number of bytes to transfer (this is
  related to the controller's internal constraints),
* if this (rounded) amount of data is situated beyond the end of the
  device,
* and only in NV-DDR mode,
the Arasan NAND controller timeouts.
This currently can happen in a particular helper used when picking
software ECC algorithms. Let's prevent this situation by refusing to use
the NV-DDR interface with software engines.
Fixes: 4edde6031458 ("mtd: rawnand: arasan: Support NV-DDR interface")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211008163640.1753821-1-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
                nvddr = nand_get_nvddr_timings(conf);
                if (IS_ERR(nvddr))
                        return PTR_ERR(nvddr);
+
+               /*
+                * The controller only supports data payload requests which are
+                * a multiple of 4. In practice, most data accesses are 4-byte
+                * aligned and this is not an issue. However, rounding up will
+                * simply be refused by the controller if we reached the end of
+                * the device *and* we are using the NV-DDR interface(!). In
+                * this situation, unaligned data requests ending at the device
+                * boundary will confuse the controller and cannot be performed.
+                *
+                * This is something that happens in nand_read_subpage() when
+                * selecting software ECC support and must be avoided.
+                */
+               if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT)
+                       return -ENOTSUPP;
        } else {
                sdr = nand_get_sdr_timings(conf);
                if (IS_ERR(sdr))