None of the board files are overloading those hooks, so let's drop them
from struct platform_nand_ctrl.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

None of the existing drivers are overloading the ->scan_bbt() method,
let's get rid of it and replace calls to ->scan_bbt() by
nand_create_bbt() ones.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Rename nand_default_bbt() into nand_create_bbt() and pass it a nand_chip
object to prepare removal of the chip->scan_bbt() hook.

We add a temporary nand_default_bbt() wrapper which will be dropped
after the removal of ->scan_bbt().
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

struct device_node is defined in linux/of.h. Let's include this file
instead of having a forward declaration of this struct.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

struct mtd_info is defined in linux/mtd/mtd.h which is included
at the beginning of nand_base.c, there's thus no need for the
forward declaration of mtd_info.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

nand_do_read() is a static function implemented in nand_base.c. There's
no good reason to expose its prototype in rawnand.h.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Function nand_ecc_choose_conf() will be help for all the cases, so
other helper functions can be made static.

nand_check_ecc_caps(): Invoke nand_ecc_choose_conf() with
                       both chip->ecc.size and chip->ecc.strength
                       value set.

nand_maximize_ecc(): Invoke nand_ecc_choose_conf() with
                     NAND_ECC_MAXIMIZE flag.

nand_match_ecc_req(): Invoke nand_ecc_choose_conf() with either
                      chip->ecc.size or chip->ecc.strength value
                      set and without NAND_ECC_MAXIMIZE flag.

CC: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NAbhishek Sahu <absahu@codeaurora.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

commit 2c8f8afa ("mtd: nand: add generic helpers to check,
match, maximize ECC settings") provides generic helpers which
drivers can use for setting up ECC parameters.

Since same board can have different ECC strength nand chips so
following is the logic for setting up ECC strength and ECC step
size, which can be used by most of the drivers.

1. If both ECC step size and ECC strength are already set
   (usually by DT) then just check whether this setting
   is supported by NAND controller.
2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength
   supported by NAND controller.
3. Otherwise, try to match the ECC step size and ECC strength closest
   to the chip's requirement. If available OOB size can't fit the chip
   requirement then select maximum ECC strength which can be fit with
   available OOB size.

This patch introduces nand_ecc_choose_conf function which calls the
required helper functions for the above logic. The drivers can use
this single function instead of calling the 3 helper functions
individually.
Signed-off-by: NAbhishek Sahu <absahu@codeaurora.org>
Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Add defines for the ONFI version bits and use them in
nand_flash_detect_onfi().
Signed-off-by: NChris Packham <chris.packham@alliedtelesis.co.nz>
Reviewed-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

This is called after the ONFI parameter page checksum is verified
and allows us to override the contents of the parameter page.
Suggested-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NChris Packham <chris.packham@alliedtelesis.co.nz>
Reviewed-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Allow to define a NAND chip as a boot device. This can be helpful
for the selection of the ECC algorithm and strength in case the boot
ROM supports only a subset of controller provided options.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Reviewed-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Add Reed-Solomon (RS) to the enumeration of ECC algorithms.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Reviewed-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

The __DIVIDE() macro checks whether it is called with a 32-bit or 64-bit
dividend, to select the appropriate divide-and-round-up routine.
As the check uses the ternary operator, the result will always be
promoted to a type that can hold both results, i.e. unsigned long long.

When using this result in a division on a 32-bit system, this may lead
to link errors like:

    ERROR: "__udivdi3" [drivers/mtd/nand/raw/nand.ko] undefined!

Fix this by casting the result of the division to the type of the
dividend.

Fixes: 8878b126 ("mtd: nand: add ->exec_op() implementation")
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Gets rid of those warnings and better document the parameters.

  ./include/linux/mtd/rawnand.h:752: warning: Function parameter or member 'timings.sdr' not described in 'nand_data_interface'
  ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf' not described in 'nand_op_data_instr'
  ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf.in' not described in 'nand_op_data_instr'
  ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf.out' not described in 'nand_op_data_instr'
  ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx' not described in 'nand_op_instr'
  ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.cmd' not described in 'nand_op_instr'
  ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.addr' not described in 'nand_op_instr'
  ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.data' not described in 'nand_op_instr'
  ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.waitrdy' not described in 'nand_op_instr'
  ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx' not described in 'nand_op_parser_pattern_elem'
  ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx.addr' not described in 'nand_op_parser_pattern_elem'
  ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx.data' not described in 'nand_op_parser_pattern_elem'
  ./include/linux/mtd/rawnand.h:1313: warning: Function parameter or member 'manufacturer.desc' not described in 'nand_chip'
  ./include/linux/mtd/rawnand.h:1313: warning: Function parameter or member 'manufacturer.priv' not described in 'nand_chip'

  ./include/linux/mtd/rawnand.h:848: WARNING: Unexpected indentation.
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

As part of the work of migrating all the drivers to nand_scan(), and
because nand_scan() does not provide a way to pass an ID table, rename
the function nand_scan_with_ids() and add a third parameter to give a
flash ID table (like what was done with nand_scan_ident()).

Create a nand_scan() helper that is just a wrapper of
nand_scan_with_ids(), passing NULL as the ID table. This way a
controller drivers can continue using nand_scan() transparently.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

The NAND chip parameter page is statically allocated within the
nand_chip structure, which reserves a lot of space. Even not ONFI nor
JEDEC chips have it embedded. Also, only a few parameters are actually
read from the parameter page after the detection.

Now that there is a small nand_parameters structure that hold all needed
ONFI parameters, remove the ONFI page from the nand_chip structure by
just allocating it during the identification phase and removing it right
after.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

The NAND chip parameter page is statically allocated within the
nand_chip structure, which reserves a lot of space. Even not ONFI nor
JEDEC chips have it embedded. Also, only a few parameters are actually
read from the parameter page after the detection.

Now that there is a small nand_parameters structure that can held
generic parameters, remove the JEDEC page from the nand_chip structure
by just allocating it during the identification phase and removing it
right after.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

If SET/GET_FEATURES is available (from the parameter page), use a
bitmap to declare what feature is actually supported.

Initialize the bitmap in the core to support timing changes (only
feature used by the core), also add support for Micron specific features
used in Micron initialization code (in the init routine).
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

The NAND chip parameter page is statically allocated within the
nand_chip structure, which reserves a lot of space. Even not ONFI nor
JEDEC chips have it embedded. Also, only a few parameters are actually
read from the parameter page after the detection.

ONFI-related parameters that will be used outside from the
identification function are stored in a separate onfi_parameters
structure embedded in nand_parameters, this small structure that
already hold generic parameters.

For now, the onfi_parameters structure is allocated statically. However,
after some deep rework in the NAND framework, it will be possible to do
dynamic allocations from the NAND identification phase, and this
strcuture will then be dynamically allocated when needed.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

The NAND chip parameter page is statically allocated within the
nand_chip structure, which reserves a lot of space. Even not ONFI nor
JEDEC chips have it embedded. Also, only a few parameters are actually
read from the parameter page after the detection.

To prepare to the removal of such huge structure, a small NAND parameter
structure is allocated statically and contains only very few members
that are generic to all chips and actually used elsewhere in the code.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Prepare the fact that some features managed by GET/SET_FEATURES could be
overloaded by vendor code. To handle this logic, use new wrappers
instead of directly call the ->get/set_features() hooks.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

SET/GET FEATURES are flagged ONFI-compliant because of their name. This
is not accurate as non-ONFI NAND chips support it and use it.

Rename the hooks and helpers to remove the "onfi" prefix.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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>

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>

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>

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>