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].<anonymous>')
    error: unknown field 'data' specified in initializer
    error: unknown field 'addr' specified in initializer

Work around the situation by naming these unions.

Fixes: 8878b126 ("mtd: nand: add ->exec_op() implementation")
Reported-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@free-electrons.com>
Tested-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@free-electrons.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The last/only user of NAND_OWN_BUFFERS (cafe_nand.c) has been reworked.
This flag is no longer needed.
Suggested-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

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: NMiquel Raynal <miquel.raynal@free-electrons.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

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: NBoris Brezillon <boris.brezillon@free-electrons.com>
[miquel.raynal@free-electrons.com: tested, fixed and rebased on nand/next]
Signed-off-by: NMiquel Raynal <miquel.raynal@free-electrons.com>
Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

This is part of the process of removing direct calls to ->cmdfunc()
outside of the core in order to introduce a better interface to execute
NAND operations.

Here we provide several helpers and make use of them to remove all
direct calls to ->cmdfunc(). This way, we can easily modify those
helpers to make use of the new ->exec_op() interface when available.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
[miquel.raynal@free-electrons.com: rebased and fixed some conflicts]
Signed-off-by: NMiquel Raynal <miquel.raynal@free-electrons.com>
Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

It is now unused.
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Reviewed-by: NRichard Weinberger <richard@nod.at>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: NChris Brandt <chris.brandt@renesas.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

C++ comments look wrong in kernel tree. Fix one.
Signed-off-by: NPavel Machek <pavel@ucw.cz>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch extracts some chunks from spi_nor_init_params and spi_nor_scan()
 and moves them into a new spi_nor_init() function.

Indeed, spi_nor_init() regroups all the required SPI flash commands to be
sent to the SPI flash memory before performing any runtime operations
(Fast Read, Page Program, Sector Erase, ...). Hence spi_nor_init():
1) removes the flash protection if applicable for certain vendors.
2) sets the Quad Enable bit, if needed, before using Quad SPI protocols.
3) makes the memory enter its (stateful) 4-byte address mode, if needed,
   for SPI flash memory > 128Mbits not supporting the 4-byte address
   instruction set.

spi_nor_scan() now ends by calling spi_nor_init() once the probe phase has
completed. Further patches could also use spi_nor_init() to implement the
mtd->_resume() handler for the spi-nor framework.
Signed-off-by: NKamal Dasu <kdasu.kdev@gmail.com>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@wedev4u.fr>

There is exactly one board in the kernel that defines platform data
for the GPIO NAND driver.

Use the feature to provide a lookup table for the GPIOs in the board
file so we can convert the driver as a whole to just use GPIO
descriptors.

After this we can cut the use of <linux/of_gpio.h> and use the GPIO
descriptor management from <linux/gpio/consumer.h> alone to grab and use
the GPIOs used in the driver.

I also created a local struct device *dev in the probe() function
because I was getting annoyed with all the &pdev->dev dereferencing.

Cc: arm@kernel.org
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Frans Klaver <fransklaver@gmail.com>
Cc: Gerhard Sittig <gsi@denx.de>
Cc: Jamie Iles <jamie.iles@oracle.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
Acked-by: NJamie Iles <jamie.iles@oracle.com>
Acked-by: NOlof Johansson <olof@lixom.net>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Several drivers check ->chipsize to see if the third row address cycle
is needed.  Instead of embedding magic sizes such as 32MB, 128MB in
drivers, introduce a new flag NAND_ROW_ADDR_3 for clean-up.  Since
nand_scan_ident() knows well about the device, it can handle this
properly.  The flag is set if the row address bit width is greater
than 16.

Delete comments such as "One more address cycle for ..." because
intention is now clear enough from the code.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NWenyou Yang <wenyou.yang@microchip.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

chip->bits_per_cell which is used to determine the NAND cell type
(SLC/MLC) should always have a value != 0.
Complain loudly if the value is 0 in nand_is_slc() to catch use before
correct initialization.
Signed-off-by: NLothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

With the introduction of sharpslpart partition parser we can now read the
offsets from NAND: we specify the list of the parsers as platform data, with
cmdlinepart and ofpart parsers first allowing to override the part. table
written in NAND. This is done in the board files using this driver.

Thus, we need to extend sharpsl_nand_platform_data to consider the partition
parsers.
Signed-off-by: NAndrea Adami <andrea.adami@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

This commit removes hard-coded '8' used for looping into
struct nand_chip.id.data array.

NAND_MAX_ID_LEN has been introduced by Artem Bityutskiy in
53552d22 for defining ids length in nand_flash_ids[] list.

This commit unifies ids length in nand base driver.
Signed-off-by: NJean-Louis Thekekara <jeanlouis.thekekara@parrot.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

When XIP_KERNEL is enabled, some functions are defined in the .data
ELF section because we require them to be in RAM whenever we communicate
with the flash chip. However this causes problems when FTRACE is
enabled and gcc emits calls to __gnu_mcount_nc in the function
prolog:

drivers/built-in.o: In function `cfi_chip_setup':
:(.data+0x272fc): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o
drivers/built-in.o: In function `cfi_probe_chip':
:(.data+0x27de8): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o
/tmp/ccY172rP.s: Assembler messages:
/tmp/ccY172rP.s:70: Warning: ignoring changed section attributes for .data
/tmp/ccY172rP.s: Error: 1 warning, treating warnings as errors
make[5]: *** [drivers/mtd/chips/cfi_probe.o] Error 1
/tmp/ccK4rjeO.s: Assembler messages:
/tmp/ccK4rjeO.s:421: Warning: ignoring changed section attributes for .data
/tmp/ccK4rjeO.s: Error: 1 warning, treating warnings as errors
make[5]: *** [drivers/mtd/chips/cfi_util.o] Error 1
/tmp/ccUvhCYR.s: Assembler messages:
/tmp/ccUvhCYR.s:1895: Warning: ignoring changed section attributes for .data
/tmp/ccUvhCYR.s: Error: 1 warning, treating warnings as errors

Specifically, this does not work because the .data section is not
marked executable, which leads LD to not generate trampolines for
long calls.

This moves the __xipram functions into their own .xiptext section instead.
The section is still placed next to .data and located in RAM but is marked
executable, which avoids the build errors.

Also, we only need to place the XIP functions into a separate section
if both CONFIG_XIP_KERNEL and CONFIG_MTD_XIP are set: When only MTD_XIP
is used, the whole kernel is still in RAM and we do not need to worry
about pulling out the rug under it. When only XIP_KERNEL but not MTD_XIP
is set, the kernel is in some form of ROM, but we never write to it.

Note that MTD_XIP has been broken on ARM since around 2011 or 2012. I
have sent another patch[2] to fix compilation, which I plan to merge
through arm-soc unless there are objections. The obvious alternative
to that would be to completely rip out the MTD_XIP support from the
kernel, since obviously nobody has been using it in a long while.

Link: [1] https://patchwork.kernel.org/patch/8109771/
Link: [2] https://patchwork.kernel.org/patch/9855225/Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

We are planning to share more code between different NAND based
devices (SPI NAND, OneNAND and raw NANDs), but before doing that
we need to move the existing include/linux/mtd/nand.h file into
include/linux/mtd/rawnand.h so we can later create a nand.h header
containing all common structure and function prototypes.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NPeter Pan <peterpandong@micron.com>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Acked-by: NAlexander Sverdlin <alexander.sverdlin@gmail.com>
Acked-by: NWenyou Yang <wenyou.yang@microchip.com>
Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
Acked-by: NHan Xu <han.xu@nxp.com>
Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NShawn Guo <shawnguo@kernel.org>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-By: NHarvey Hunt <harveyhuntnexus@gmail.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NKrzysztof Halasa <khalasa@piap.pl>

Commit 7d70f334 ("mtd: nand: add lock/unlock routines") introduced
support for the Micron LOCK/UNLOCK commands but no one ever used the
nand_lock/unlock() functions.

Remove support for these vendor-specific operations from the core. If
one ever wants to add them back they should be put in nand_micron.c and
mtd->_lock/_unlock should be directly assigned from there instead of
exporting the functions.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

All timings in nand_sdr_timings are expressed in picoseconds but some
of them may not fit in an u32.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Fixes: 204e7ecd ("mtd: nand: Add a few more timings to nand_sdr_timings")
Reported-by: NAlexander Dahl <ada@thorsis.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: NAlexander Dahl <ada@thorsis.com>
Tested-by: NAlexander Dahl <ada@thorsis.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

S25FL{128|256|512}S datasheets say:
"When P_ERR or E_ERR bits are set to one, the WIP bit will remain set to
one indicating the device remains busy and unable to receive new operation
commands. A Clear Status Register (CLSR) command must be received to return
the device to standby mode."

Current spi-nor code works until first error occurs, but write/erase errors
are not just rare hardware failures, they also occur if user tries to flash
write-protected areas. After such attempt no SPI command can be executed
any more and even read fails. This patch adds support for P_ERR and E_ERR
bits in Status Register 1 (so that operation fails immediately and not
after a long timeout) and proper recovery from the error condition.

Tested on Spansion S25FS128S, which is supported by S25FL129P entry.
Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@wedev4u.fr>

Several MTD devices are using debugfs entries created in the root.
This commit provides the means for a standardized subtree, creating
one "mtd" entry at root, and one entry per device inside it, named
after the device.
The tree is registered in add_mtd_device, and released in
del_mtd_device.
Devices docg3, mtdswap and nandsim were updated to use this subtree
instead of custom ones, and their entries were prefixed with the
drivers' names.
Signed-off-by: NMario J. Rugiero <mrugiero@gmail.com>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch adds support to the JESD216 rev B standard and parses the SFDP
tables to dynamically initialize the 'struct spi_nor_flash_parameter'.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@microchip.com>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>

Some devices have partitions that are kind of containers with extra
subpartitions / volumes instead of e.g. a simple filesystem data. To
support such cases we need to first create normal flash device
partitions and then take care of these special ones.

It's very common case for home routers. Depending on the vendor there
are formats like TRX, Seama, TP-Link, WRGG & more. All of them are used
to embed few partitions into a single one / single firmware file.

Ideally all vendors would use some well documented / standardized format
like UBI (and some probably start doing so), but there are still
countless devices on the market using these poor vendor specific
formats.

This patch extends MTD subsystem by allowing to specify list of parsers
that should be tried for a given partition. Supporting such poor formats
is highly unlikely to be the top priority so these changes try to
minimize maintenance cost to the minimum. It reuses existing code for
these new parsers and just adds a one property and one new function.

This implementation requires setting partition parsers in a flash
parser. A proper change of bcm47xxpart will follow and in the future we
will hopefully also find a solution for doing it with ofpart
("fixed-partitions").
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

struct nand_ecc_caps was designed as flexible as possible to support
multiple stepsizes (like sunxi_nand.c).

So, we need to write multiple arrays even for the simplest case.
I guess many controllers support a single stepsize, so here is a
shorthand macro for the case.

It allows to describe like ...

NAND_ECC_CAPS_SINGLE(denali_pci_ecc_caps, denali_calc_ecc_bytes, 512, 8, 15);

... instead of

static const int denali_pci_ecc_strengths[] = {8, 15};
static const struct nand_ecc_step_info denali_pci_ecc_stepinfo = {
        .stepsize = 512,
        .strengths = denali_pci_ecc_strengths,
        .nstrengths = ARRAY_SIZE(denali_pci_ecc_strengths),
};
static const struct nand_ecc_caps denali_pci_ecc_caps = {
        .stepinfos = &denali_pci_ecc_stepinfo,
        .nstepinfos = 1,
        .calc_ecc_bytes = denali_calc_ecc_bytes,
};
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Driver are responsible for setting up ECC parameters correctly.
Those include:
  - Check if ECC parameters specified (usually by DT) are valid
  - Meet the chip's ECC requirement
  - Maximize ECC strength if NAND_ECC_MAXIMIZE flag is set

The logic can be generalized by factoring out common code.

This commit adds 3 helpers to the NAND framework:
nand_check_ecc_caps - Check if preset step_size and strength are valid
nand_match_ecc_req - Match the chip's requirement
nand_maximize_ecc - Maximize the ECC strength

To use the helpers above, a driver needs to provide:
  - Data array of supported ECC step size and strength
  - A hook that calculates ECC bytes from the combination of
    step_size and strength.

By using those helpers, code duplication among drivers will be
reduced.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The ->errstat() hook is no longer implemented NAND controller drivers.
Get rid of it before someone starts abusing it.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Some NAND controllers can assign different NAND timings to different
CS lines. Pass the CS line information to ->setup_data_interface() so
that the NAND controller driver knows which CS line is concerned by
the setup_data_interface() request.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Now that the core NAND subsystem has support for on-die ECC, this commit
brings the necessary code to support on-die ECC on Micron NANDs.

In micron_nand_init(), we detect if the Micron NAND chip supports on-die
ECC mode, by checking a number of conditions:

 - It must be an ONFI NAND
 - It must be a SLC NAND

 - Enabling *and* disabling on-die ECC must work

 - The on-die ECC must be correcting 4 bits per 512 bytes of data. Some
   Micron NAND chips have an on-die ECC able to correct 8 bits per 512
   bytes of data, but they work slightly differently and therefore we
   don't support them in this patch.

Then, if the on-die ECC cannot be disabled (some Micron NAND have on-die
ECC forcefully enabled), we bail out, as we don't support such
NANDs. Indeed, the implementation of raw_read()/raw_write() make the
assumption that on-die ECC can be disabled. Support for Micron NANDs
with on-die ECC forcefully enabled can easily be added, but in the
absence of such HW for testing, we preferred to simply bail out.

If the on-die ECC is supported, and requested in the Device Tree, then
it is indeed enabled, by using custom implementations of the
->read_page(), ->read_page_raw(), ->write_page() and ->write_page_raw()
operation to properly handle the on-die ECC.

In the non-raw functions, we need to enable the internal ECC engine
before issuing the NAND_CMD_READ0 or NAND_CMD_SEQIN commands, which is
why we set the NAND_ECC_CUSTOM_PAGE_ACCESS option at initialization
time (it asks the NAND core to let the NAND driver issue those
commands).
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

A lot of drivers are providing their own ->cmdfunc(), and most of the
time this implementation does not support all possible NAND operations.
But since ->cmdfunc() cannot return an error code, the core has no way
to know that the operation it requested is not supported.

This is a problem we cannot address for all kind of operations with the
current design, but we can prevent these silent failures for the
GET/SET FEATURES operation by overloading the default
->onfi_{set,get}_features() methods with one returning -ENOTSUPP.
Reported-by: NChris Packham <Chris.Packham@alliedtelesis.co.nz>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: NChris Packham <Chris.Packham@alliedtelesis.co.nz>

./drivers/mtd/nand/nand_bbt.c:1: warning: no structured comments found
./include/linux/mtd/nand.h:785: ERROR: Unexpected indentation.
./drivers/mtd/nand/nand_base.c:449: WARNING: Definition list ends without a blank line; unexpected unindent.
./drivers/mtd/nand/nand_base.c:1161: ERROR: Unexpected indentation.
./drivers/mtd/nand/nand_base.c:1162: WARNING: Block quote ends without a blank line; unexpected unindent.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This patch starts adding support to Octo SPI protocols (SPI x-y-8).

Op codes for Fast Read and/or Page Program operations using Octo SPI
protocols are not known yet (no JEDEC specification has defined them yet)
but we'd rather introduce the Octo SPI protocols now so it's done as it
should be.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>

This patch introduces support to Double Transfer Rate (DTR) SPI protocols.
DTR is used only for Fast Read operations.

According to manufacturer datasheets, whatever the number of I/O lines
used during instruction (x) and address/mode/dummy (y) clock cycles, DTR
is used only during data (z) clock cycles of SPI x-y-z protocols.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>

This patch changes the prototype of spi_nor_scan(): its 3rd parameter
is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor
framework about the actual hardware capabilities supported by the SPI
controller and its driver.

Besides, this patch also introduces a new 'struct spi_nor_flash_parameter'
telling the spi-nor framework about the hardware capabilities supported by
the SPI flash memory and the associated settings required to use those
hardware caps.

Then, to improve the readability of spi_nor_scan(), the discovery of the
memory settings and the memory initialization are now split into two
dedicated functions.

1 - spi_nor_init_params()

The spi_nor_init_params() function is responsible for initializing the
'struct spi_nor_flash_parameter'. Currently this structure is filled with
legacy values but further patches will allow to override some parameter
values dynamically, for instance by reading the JESD216 Serial Flash
Discoverable Parameter (SFDP) tables from the SPI memory.
The spi_nor_init_params() function only deals with the hardware
capabilities of the SPI flash memory: especially it doesn't care about
the hardware capabilities supported by the SPI controller.

2 - spi_nor_setup()

The second function is called once the 'struct spi_nor_flash_parameter'
has been initialized by spi_nor_init_params().
With both 'struct spi_nor_flash_parameter' and 'struct spi_nor_hwcaps',
the new argument of spi_nor_scan(), spi_nor_setup() computes the best
match between hardware caps supported by both the (Q)SPI memory and
controller hence selecting the relevant settings for (Fast) Read and Page
Program operations.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>

The nand_read_page_raw() and nand_write_page_raw() functions might be
re-used by vendor-specific implementations of the read_page/write_page
functions. Instead of having vendor-specific code duplicate this code,
it is much better to export those functions and allow them to be
re-used.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

A number of NAND flashes have a capability called "on-die ECC" where the
NAND chip itself is capable of detecting and correcting errors.

Linux already has support for using the ECC implementation of the NAND
controller, or a software based ECC implementation, but not for using
the ECC implementation of the NAND controller. However, such an
implementation is sometimes useful in situations where the NAND
controller provides ECC algorithms that are not strong enough for the
NAND chip used on the system. A typical case is a NAND chip that
requires a 4-bit ECC, while the NAND controller only provides a 1-bit
ECC algorithm.

This commit introduces the support for the NAND_ECC_ON_DIE ECC mode:

 - Parsing of the "on-die" value for the "nand-ecc-mode" Device Tree
   property

 - Handling NAND_ECC_ON_DIE case in nand_scan_tail(). The idea is that
   the vendor specific code for the NAND chip must implement
   ->read_page() and ->write_page(). It may optionally provide its own
   ->read_page_raw() and ->write_page_raw() as well. For OOB operation,
   we assume the standard operations are good enough, but they can be
   overridden by the vendor specific code if needed.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

In some cases, nand_do_{read,write}_ops is passed with unaligned
ops->datbuf.  Drivers using DMA will be unhappy about unaligned
buffer.

The new struct member, buf_align, represents the minimum alignment
the driver require for the buffer.  If the buffer passed from the
upper MTD layer does not have enough alignment, nand_do_*_ops will
use bufpoi.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The comment for ecc.read_page() requires that it should return
"0 if bitflips uncorrectable".

Actually, drivers could return positive values when uncorrectable
bitflips occur.  For example, nand_read_page_swecc() is the case.
If ecc.correct() returns -EBADMSG for the first ECC sector, and
a positive value for the second one, nand_read_page_swecc() returns
a positive max_bitflips and increments ecc_stats.failed for the same
page.

The requirement can be relaxed by tweaking nand_do_read_ops().
Move the max_bitflips calculation below the retry.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The last/only user of the chip->write_page() hook (the Atmel NAND
controller driver) has been reworked and is no longer specifying a custom
->write_page() implementation.
Drop this hook before someone else start abusing it.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

MTD already allocates backing_dev_info dynamically. Convert it to use
generic infrastructure for this including proper refcounting. We drop
mtd->backing_dev_info as its only use was to pass mtd_bdi pointer from
one file into another and if we wanted to keep that in a clean way, we'd
have to make mtd hold and drop bdi reference as needed which seems
pointless for passing one global pointer...

CC: David Woodhouse <dwmw2@infradead.org>
CC: Brian Norris <computersforpeace@gmail.com>
CC: linux-mtd@lists.infradead.org
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJan Kara <jack@suse.cz>
Signed-off-by: NJens Axboe <axboe@fb.com>