linux-stable.git/drivers/mtd, branch v4.19.3

mtd: docg3: don't set conflicting BCH_CONST_PARAMS option

2018-11-21T08:19:19+00:00

commit be2e1c9dcf76886a83fb1c433a316e26d4ca2550 upstream.

I noticed during the creation of another bugfix that the BCH_CONST_PARAMS
option that is set by DOCG3 breaks setting variable parameters for any
other users of the BCH library code.

The only other user we have today is the MTD_NAND software BCH
implementation (most flash controllers use hardware BCH these days
and are not affected). I considered removing BCH_CONST_PARAMS entirely
because of the inherent conflict, but according to the description in
lib/bch.c there is a significant performance benefit in keeping it.

To avoid the immediate problem of the conflict between MTD_NAND_BCH
and DOCG3, this only sets the constant parameters if MTD_NAND_BCH
is disabled, which should fix the problem for all cases that
are affected. This should also work for all stable kernels.

Note that there is only one machine that actually seems to use the
DOCG3 driver (arch/arm/mach-pxa/mioa701.c), so most users should have
the driver disabled, but it almost certainly shows up if we wanted
to test random kernels on machines that use software BCH in MTD.

Fixes: d13d19ece39f ("mtd: docg3: add ECC correction code")
Cc: stable@vger.kernel.org
Cc: Robert Jarzmik 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: cadence-quadspi: Return error code in cqspi_direct_read_execute()

2018-11-21T08:19:19+00:00

commit 91d7b67000c6e9bd605624079fee5a084238ad92 upstream.

We return 0 unconditionally in 'cqspi_direct_read_execute()'.
However, 'ret' is set to some error codes in several error handling
paths.

Return 'ret' instead to propagate the error code.

Fixes: ffa639e069fb ("mtd: spi-nor: cadence-quadspi: Add DMA support for direct mode reads")
Cc: 
Signed-off-by: Christophe JAILLET 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: atmel: Fix potential NULL pointer dereference

2018-11-13T19:08:24+00:00

[ Upstream commit fbed20280d912449cfb40c382cb55e3d11502587 ]

There is a potential execution path in which function
of_find_compatible_node() returns NULL. In such a case,
we end up having a NULL pointer dereference when accessing
pointer *nfc_np* in function of_clk_get().

So, we better don't take any chances and fix this by null
checking pointer *nfc_np* before calling of_clk_get().

Addresses-Coverity-ID: 1473052 ("Dereference null return value")
Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
Signed-off-by: Gustavo A. R. Silva 
Reviewed-by: Boris Brezillon 
Acked-by: Tudor Ambarus 
Signed-off-by: Miquel Raynal 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: denali: set SPARE_AREA_SKIP_BYTES register to 8 if unset

2018-11-13T19:08:23+00:00

[ Upstream commit 0d55c668b218a1db68b5044bce4de74e1bd0f0c8 ]

NAND devices need additional data area (OOB) for error correction,
but it is also used for Bad Block Marker (BBM).  In many cases, the
first byte in OOB is used for BBM, but the location actually depends
on chip vendors.  The NAND controller should preserve the precious
BBM to keep track of bad blocks.

In Denali IP, the SPARE_AREA_SKIP_BYTES register is used to specify
the number of bytes to skip from the start of OOB.  The ECC engine
will automatically skip the specified number of bytes when it gets
access to OOB area.

The same value for SPARE_AREA_SKIP_BYTES should be used between
firmware and the operating system if you intend to use the NAND
device across the control hand-off.

In fact, the current denali.c code expects firmware to have already
set the SPARE_AREA_SKIP_BYTES register, then reads the value out.

If no firmware (or bootloader) has initialized the controller, the
register value is zero, which is the default after power-on-reset.
In other words, the Linux driver cannot initialize the controller
by itself.

Some possible solutions are:

 [1] Add a DT property to specify the skipped bytes in OOB
 [2] Associate the preferred value with compatible
 [3] Hard-code the default value in the driver

My first attempt was [1], but in the review process, [3] was suggested
as a counter-implementation.
(https://lore.kernel.org/patchwork/patch/983055/)

The default value 8 was chosen to match to the boot ROM of the UniPhier
platform.  The preferred value may vary by platform.  If so, please
trade up to a different solution.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Boris Brezillon 
Signed-off-by: Miquel Raynal 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: fsl-quadspi: Don't let -EINVAL on the bus

2018-11-13T19:08:15+00:00

commit 000412276370a9bcfec73b3752ceefd9a927f1db upstream.

fsl_qspi_get_seqid() may return -EINVAL, but fsl_qspi_init_ahb_read()
doesn't check for error codes with the result that -EINVAL could find
itself signalled over the bus.

In conjunction with the LS1046A SoC's A-009283 errata
("Illegal accesses to SPI flash memory can result in a system hang")
this illegal access to SPI flash memory results in a system hang
if userspace attempts reading later on.

Avoid this by always checking fsl_qspi_get_seqid()'s return value
and bail out otherwise.

Fixes: e46ecda764dc ("mtd: spi-nor: Add Freescale QuadSPI driver")
Cc: stable@vger.kernel.org
Signed-off-by: Ahmad Fatoum 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: intel-spi: Add support for Intel Ice Lake SPI serial flash

2018-11-13T19:08:15+00:00

commit 42460c31ae96cbad5ae226ee6c10bd8d70d764ae upstream.

Intel Ice Lake exposes the SPI serial flash controller as a PCI device
in the same way than Intel Denverton. Add Ice Lake SPI serial flash PCI
ID to the driver list of supported devices.

Signed-off-by: Mika Westerberg 
Acked-by: Marek Vasut 
Cc: stable@vger.kernel.org
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: fsl-quadspi: fix read error for flash size larger than 16MB

2018-11-13T19:08:15+00:00

commit 41fe242979e463d6ad251077ded01b825a330b7e upstream.

If the size of spi-nor flash is larger than 16MB, the read_opcode
is set to SPINOR_OP_READ_1_1_4_4B, and fsl_qspi_get_seqid() will
return -EINVAL when cmd is SPINOR_OP_READ_1_1_4_4B. This can
cause read operation fail.

Fixes: e46ecda764dc ("mtd: spi-nor: Add Freescale QuadSPI driver")
Cc: 
Signed-off-by: Liu Xiang 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: maps: gpio-addr-flash: Fix ioremapped size

2018-11-13T19:08:14+00:00

commit 6c925b333368cda4e1b0513b07f72316c0e7edd7 upstream.

We should only iomap the area of the chip that is memory mapped.
Otherwise we could be mapping devices beyond the memory space or that
belong to other devices.

Signed-off-by: Ricardo Ribalda Delgado 
Fixes: ebd71e3a4861 ("mtd: maps: gpio-addr-flash: fix warnings and make more portable")
Cc: 
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

mtd: rawnand: marvell: fix the IRQ handler complete() condition

2018-11-13T19:08:14+00:00

commit 53c83b59759c1ee213f5ffa194909daee8902a28 upstream.

With the current implementation, the complete() in the IRQ handler is
supposed to be called only if the register status has one or the other
RDY bit set. Other events might trigger an interrupt as well if
enabled, but should not end-up with a complete() call.

For this purpose, the code was checking if the other bits were set, in
this case complete() was not called. This is wrong as two events might
happen in a very tight time-frame and if the NDSR status read reports
two bits set (eg. RDY(0) and RDDREQ) at the same time, complete() was
not called.

This logic would lead to timeouts in marvell_nfc_wait_op() and has
been observed on PXA boards (NFCv1) in the Hamming write path.

Fixes: 02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver")
Cc: stable@vger.kernel.org
Reported-by: Daniel Mack 
Signed-off-by: Miquel Raynal 
Tested-by: Daniel Mack 
Signed-off-by: Greg Kroah-Hartman

mtd: devices: m25p80: Make sure the buffer passed in op is DMA-able

2018-09-18T08:17:48+00:00

As documented in spi-mem.h, spi_mem_op->data.buf.{in,out} must be
DMA-able, and commit 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx()
API") failed to follow this rule as buffers passed to
->{read,write}_reg() are usually placed on the stack.

Fix that by allocating a scratch buffer and copying the data around.

Fixes: 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx() API")
Reported-by: Jarkko Nikula 
Cc: 
Signed-off-by: Boris Brezillon 
Tested-by: Jarkko Nikula 
Reviewed-by: Jarkko Nikula