linux-toradex.git/include/linux/mtd, branch v4.16-rc4

Merge tag 'nand/for-4.16' of git://git.infradead.org/linux-mtd into mtd/next

2018-01-29T08:58:36+00:00

Pull NAND changes from Boris Brezillon:

"
  Core changes:
  * Fix NAND_CMD_NONE handling in nand_command[_lp]() hooks
  * Introduce the ->exec_op() infrastructure
  * Rework NAND buffers handling
  * Fix ECC requirements for K9F4G08U0D
  * Fix nand_do_read_oob() to return the number of bitflips
  * Mark K9F1G08U0E as not supporting subpage writes

  Driver changes:
  * MTK: Rework the driver to support new IP versions
  * OMAP OneNAND: Full rework to use new APIs (libgpio, dmaengine) and fix
    DT support
  * Marvell: Add a new driver to replace the pxa3xx one
"

Merge tag 'spi-nor/for-4.16' of git://git.infradead.org/linux-mtd into mtd/next

2018-01-29T08:55:14+00:00

Pull spi-nor changes from Cyrille Pitchen:

"
  This pull-request contains the following notable changes:

  Core changes:
  * Add support to new ISSI and Cypress/Spansion memory parts.
  * Fix support of Micron memories by checking error bits in the FSR.
  * Fix update of block-protection bits by reading back the SR.
  * Restore the internal state of the SPI flash memory when removing the
    device.

  Driver changes:
  * Maintenance for Freescale, Intel and Metiatek drivers.
  * Add support of the direct access mode for the Cadence QSPI controller.
"

mtd: nand: Fix build issues due to an anonymous union

2018-01-20T09:39:02+00:00

GCC-4.4.4 raises errors when assigning a parameter in an anonymous
union, leading to this kind of failure:

drivers/mtd/nand/marvell_nand.c:1936:
    warning: missing braces around initializer
    warning: (near initialization for '(anonymous)[1].')
    error: unknown field 'data' specified in initializer
    error: unknown field 'addr' specified in initializer

Work around the situation by naming these unions.

Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation")
Reported-by: Andrew Morton 
Signed-off-by: Miquel Raynal 
Tested-by: Andrew Morton 
Signed-off-by: Boris Brezillon

mtd: Add an helper to make erase request aligned on ->erasesize

2018-01-06T14:09:54+00:00

There's currently nothing forcing alignment of einfo->addr and
einfo->len on mtd->erasesize. Since we don't know if automatically
aligning those field in mtd_erase() will hurt some drivers, we add an
helper function to let drivers that need such an alignment explicitly
ask for it.

Signed-off-by: Boris Brezillon 
Reviewed-by: Miquel Raynal

mtd: cfi: convert inline functions to macros

2017-12-18T08:52:59+00:00

The map_word_() functions, dating back to linux-2.6.8, try to perform
bitwise operations on a 'map_word' structure. This may have worked
with compilers that were current then (gcc-3.4 or earlier), but end
up being rather inefficient on any version I could try now (gcc-4.4 or
higher). Specifically we hit a problem analyzed in gcc PR81715 where we
fail to reuse the stack space for local variables.

This can be seen immediately in the stack consumption for
cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
can be up to 2200 bytes. Changing the inline functions into macros brings
this down to 1280 bytes.  Without KASAN, the same problem exists, but
the stack consumption is lower to start with, my patch shrinks it from
920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
structures for each call to one of these helpers.

With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
but nobody uses that yet, so we should still work around it in mainline
kernels and probably backport the workaround to stable kernels as well.
We had a couple of other functions that suffered from the same gcc bug,
and all of those had a simpler workaround involving dummy variables
in the inline function. Unfortunately that did not work here, the
macro hack was the best I could come up with.

It would also be helpful to have someone to a little performance testing
on the patch, to see how much it helps in terms of CPU utilitzation.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann 
Acked-by: Richard Weinberger 
Signed-off-by: Boris Brezillon

mtd: nand: add ->exec_op() implementation

2017-12-16T13:40:26+00:00

Introduce a new interface to instruct NAND controllers to send specific
NAND operations. The new interface takes the form of a single method
called ->exec_op(). This method is designed to replace ->cmd_ctrl(),
->cmdfunc() and ->read/write_byte/word/buf() hooks.

->exec_op() is passed a set of instructions describing the operation
to execute. Each instruction has a type (ADDR, CMD, DATA, WAITRDY)
and delay. The delay is here to help simple controllers wait enough
time between each instruction, advanced controllers with integrated
timings control can ignore these delays.

Controllers that natively support complex operations (operations
formed of several instructions) can use the NAND op parser
infrastructure. This infrastructure allows controller drivers to
describe the sequence of instructions they support (called
nand_op_pattern) and a hook for each of these supported sequences. The
core then tries to find the best match for a given NAND operation, and
calls the associated hook.

Various other helpers are also added to ease NAND controller drivers
writing.

This new interface should ease support of vendor specific operations
in that NAND manufacturer drivers now have a way to check if the
controller they are connected to supports a specific operation, and
complain or refuse to probe the NAND chip when that's not the case.

Suggested-by: Boris Brezillon 
Signed-off-by: Miquel Raynal 
Signed-off-by: Boris Brezillon

mtd: nand: squash struct nand_buffers into struct nand_chip

2017-12-14T12:34:19+00:00

struct nand_buffers is malloc'ed in nand_scan_tail() just for
containing three pointers.  Squash this struct into nand_chip.

Move and rename as follows:

  chip->buffers->ecccalc   ->  chip->ecc.calc_buf
  chip->buffers->ecccode   ->  chip->ecc.code_buf
  chip->buffers->databuf   ->  chip->data_buf

Signed-off-by: Masahiro Yamada 
Signed-off-by: Boris Brezillon

mtd: nand: remove unused NAND_OWN_BUFFERS flag

2017-12-14T12:34:19+00:00

The last/only user of NAND_OWN_BUFFERS (cafe_nand.c) has been reworked.
This flag is no longer needed.

Suggested-by: Boris Brezillon 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Boris Brezillon

mtd: nand: provide valid ->data_interface during NAND detection

2017-12-14T12:34:18+00:00

Right now, the chip->data_interface field is populated in
nand_scan_tail(), so after the whole NAND detection has taken place.
This is fine because these timings are not yet used by the core so
early in the probe process, but the situation is about to change with
the introduction of ->exec_op().

Also, by convention, nand_scan_ident() is not supposed to allocate
resources, only nand_scan_tail() can, so this prevent us from
allocating and initializing the data_interface object in
nand_scan_ident().

In order to solve this problem, directly embed a data_interface object
in nand_chip so that we don't have to allocate it, and initialize it to
ONFI SDR mode 0 at the very beginning of nand_scan_ident().

Signed-off-by: Miquel Raynal 
Signed-off-by: Boris Brezillon

mtd: nand: force drivers to explicitly send READ/PROG commands

2017-12-14T12:34:17+00:00

The core currently send the READ0 and SEQIN+PAGEPROG commands in
nand_do_read/write_ops(). This is inconsistent with
->read/write_oob[_raw]() hooks behavior which are expected to send
these commands.

There's already a flag (NAND_ECC_CUSTOM_PAGE_ACCESS) to inform the core
that a specific controller wants to send the READ/SEQIN+PAGEPROG
commands on its own, but it's an opt-in flag, and existing drivers are
unlikely to be updated to pass it.

Moreover, some controllers cannot dissociate the READ/PAGEPROG commands
from the associated data transfer and ECC engine activation, and
developers have to hack things in their ->cmdfunc() implementation to
handle such complex cases, or have to accept the perf penalty of sending
twice the same command.
To address this problem we are planning on adding a new interface which
is passed all information about a NAND operation (including the amount
of data to transfer) and replacing all calls to ->cmdfunc() to calls to
this new ->exec_op() hook. But, in order to do that, we need to have all
->cmdfunc() calls placed near their associated ->read/write_buf/byte()
calls.

Modify the core and relevant drivers to make NAND_ECC_CUSTOM_PAGE_ACCESS
the default case, and remove this flag.

Signed-off-by: Boris Brezillon 
[miquel.raynal@free-electrons.com: tested, fixed and rebased on nand/next]
Signed-off-by: Miquel Raynal 
Acked-by: Masahiro Yamada