This partially reverts commit 1696e6bc
("mtd: nand: kill NAND_NO_READRDY").

In that patch I overlooked a few things.

The original documentation for NAND_NO_READRDY included "True for all
large page devices, as they do not support autoincrement." I was
conflating "not support autoincrement" with the NAND_NO_AUTOINCR option,
which was in fact doing nothing. So, when I dropped NAND_NO_AUTOINCR, I
concluded that I then could harmlessly drop NAND_NO_READRDY. But of
course the fact the NAND_NO_AUTOINCR was doing nothing didn't mean
NAND_NO_READRDY was doing nothing...

So, NAND_NO_READRDY is re-introduced as NAND_NEED_READRDY and applied
only to those few remaining small-page NAND which needed it in the first
place.

Cc: stable@kernel.org [3.5+]
Reported-by: NAlexander Shiyan <shc_work@mail.ru>
Tested-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The panic_nand_wait() expects the timeo in ms and not in jiffies.
But in nand_wait(), the timeo for panic_nand_wait() is assigned with
wrong value(jiffies + some delay). The timeo should be set like the
panic_nand_write() does.

This patch passes timeo in ms to panic_nand_wait().
And this patch also passes timeo in jiffies(converted by msecs_to_jiffies)
to time_before() which makes the code more readable.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Commit ff3206b2 ('mtd: nand: onfi need 
to be probed in 8 bits mode') adds a WARN if the onfi probe is in 16 
bits mode. This allows to detect driver that need to be fixed, but this 
is a bit noisy¹. Transform the WARN in a pr_err.

¹ http://article.gmane.org/gmane.linux.ports.arm.omap/91317Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The simple example provided in the comments for nand_id_has_period()
actually has a period of 3, not 2. Silly mistake...
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

- NAND_CMD_READID want an address that it is not scaled on x16 device (it is always 0x20)
- NAND_CMD_PARAM want 8 bits data
Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

The driver call nand_scan_ident in 8 bit mode, then
readid or onfi detection are done (and detect bus width).
The driver should update its bus width before calling nand_scan_tail.

This work because readid and onfi are read work 8 byte mode.

Note that nand_scan_ident send command (NAND_CMD_RESET, NAND_CMD_READID, NAND_CMD_PARAM), address and read data
The ONFI specificication is not very clear for x16 device if high byte of address should be driven to 0,
but according to [1] it should be ok to not drive it during autodetection.

[1]
3.3.2. Target Initialization

[...]
The Read ID and Read Parameter Page commands only use the lower 8-bits of the data bus.
The host shall not issue commands that use a word data width on x16 devices until the host
determines the device supports a 16-bit data bus width in the parameter page.
Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This help to detect bad flash identification in case the size is not present
on the name (ONFI).
Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

nand_wait_ready timeout should not assume HZ=100.
Make it independent of HZ value by using msecs_to_jiffies.
Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

There are two reasons to remove the "chip" parameter in nand_get_device():

[1] The nand_release_device() does not have the "chip" parameter.
[2] We can get the nand_chip by the mtd->priv field.

This patch removes the "chip" parameter in nand_get_device().
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

The nand_get_device() does not select the chip, but nand_release_device()
does de-select the chip. It is really strange.

With the current code, nand_sync() will de-select the chip, even if the chip
has never been selected.

To make the balance of select/de-select chip, it's better to remove the
de-select chip code in nand_release_device() which makes the code more
clear.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Correct spelling typo in printk within drivers/mtd/tests.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

When we scan several nand chips with nand_scan(), such as
     .......................
      nand_scan(*, 2);
     .......................

In nand_scan_ident(), the maxchips will become 2, so the current code
will select chip 1 to read the device ID. But the chip 0 is still
selected in this case.

To make the logic clear, we'd better de-select the chip when it is not used.

This patch de-select the nand chip if it is not used any more.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This patch allow to detect buggy driver/hardware with
bad RnB (dev_ready) management or when timeout occurs in polling mode.

This works when dev_ready is set or not set.
There are 2 methods to wait for an erase/program command completion:

1. Wait until nand RnB pin goes high (that's what chip->dev_ready usually does)
2. Poll the device: send a status (0x70) command and read status byte in a loop
   until bit NAND_STATUS_READY is set

In all cases, you should send a status command after completion, to check if
the operation was successful. And if the operation completed, the status should
have bit NAND_STATUS_READY set.
Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Use the NAND_STATUS_FAIL to replace the hardcode "0x01",
which make the code more readable.
Signed-off-by: NHuang Shijie <shijie8@gmail.com>
Acked-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This patch fixes errors seen in identifying old Samsung SLC, due to the
following commits:

    commit e2d3a35e
    mtd: nand: detect Samsung K9GBG08U0A, K9GAG08U0F ID

    commit e3b88bd6
    mtd: nand: add generic READ ID length calculation functions

Some Samsung NAND with "5-byte" ID really appear to have 6-byte IDs, with
wraparound like:

  Samsung K9K8G08U0D
  ec d3 51 95 58 ec ec d3

  Samsung K9F1G08U0C
  ec f1 00 95 40 ec ec f1

  Samsung K9F2G08U0B
  ec da 10 95 44 00 ec da

This bad wraparound makes it hard to reliably detect the difference
between Samsung SLC with 5-byte ID and Samsung SLC with 6-byte ID.

The fix is to, for now, only use the new Samsung table for MLC. We
cannot support the new SLC (K9FAG08U0M) until Samsung gives better ID
decode information.

Note that this applies in addition to the previous regression fix:

    commit bc86cf7a
    mtd: nand: fix Samsung SLC NAND identification regression

Together, these patches completely restore the previous detection
behavior so that we cannot see any more regressions in Samsung SLC NAND
(finger crossed). With luck, I can get a hold of a Samsung
representative and stop having to cross my fingers eventually.
Reported-by: NSylwester Nawrocki <sylvester.nawrocki@gmail.com>
Tested-by: NSylwester Nawrocki <sylvester.nawrocki@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

A combination of the following two commits caused a regression in 3.7-rc1
when identifying some Samsung NAND, so that some previously working NAND
were no longer detected properly:

    commit e3b88bd6
    mtd: nand: add generic READ ID length calculation functions

    commit e2d3a35e
    mtd: nand: detect Samsung K9GBG08U0A, K9GAG08U0F ID

Particularly, a regression was seen on Samsung K9F2G08U0B, with the
following full 8-byte READ ID string:

    ec da 10 95 44 00 ec da

The basic problem is that Samsung manufactures both SLC and MLC NAND
that use a non-standard decoding table for deriving information from
their IDs. I have heuristically determined that all the chips that use
the new table have ID strings which wrap around after the 6th byte.
Unfortunately, I overlooked the fact that some older Samsung SLC (which
use a different decoding table) have "5 byte ID strings" which also wrap
around after the 6th byte.

This patch re-introduces a distinction between these old and new Samsung
NAND by checking that the 6th byte is non-zero, allowing both old and
new Samsung NAND to be detected properly.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NBrian Norris <computersforpeace@gmail.com>
Reported-by: NMarek Vasut <marex@denx.de>
Tested-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

A combination of the following two commits caused a regression in 3.7-rc1
when identifying some Samsung NAND, so that some previously working NAND
were no longer detected properly:

    commit e3b88bd6
    mtd: nand: add generic READ ID length calculation functions

    commit e2d3a35e
    mtd: nand: detect Samsung K9GBG08U0A, K9GAG08U0F ID

Particularly, a regression was seen on Samsung K9F2G08U0B, with the
following full 8-byte READ ID string:

    ec da 10 95 44 00 ec da

The basic problem is that Samsung manufactures both SLC and MLC NAND
that use a non-standard decoding table for deriving information from
their IDs. I have heuristically determined that all the chips that use
the new table have ID strings which wrap around after the 6th byte.
Unfortunately, I overlooked the fact that some older Samsung SLC (which
use a different decoding table) have "5 byte ID strings" which also wrap
around after the 6th byte.

This patch re-introduces a distinction between these old and new Samsung
NAND by checking that the 6th byte is non-zero, allowing both old and
new Samsung NAND to be detected properly.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NBrian Norris <computersforpeace@gmail.com>
Reported-by: NMarek Vasut <marex@denx.de>
Tested-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Datasheets for the following Samsung NAND parts (both MLC and SLC) describe
extensions to the Samsung 6-byte extended ID decoding table:

K9GBG08U0A (MLC, 6-byte ID)
K9GAG08U0F (MLC, 6-byte ID)
K9FAG08U0M (SLC, 6-byte ID)

The table found in K9GAG08U0F, p.44, contains a superset of the information
found in other previous datasheets.

This patch adds support for all of these chips, with 512B and 640B OOB sizes.
It also changes the detection pattern such that this table applies to all
Samsung 6-byte ID NAND, not just MLC. This is safe, according to the NAND
parameter data I have collected:

Note that nand_base.c does not yet support the bad block marker scheme defined
for these chips (i.e., scan 1st and last page for BB markers).
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Hynix has introduced a new ID decoding scheme for their newer MLC, some of
which don't support ONFI. The following devices all follow the pattern given in
the datasheet for Hynix H27UBG8T2B, p.22:

Hynix H27UAG8T2A
Hynix H27UBG8T2A
Hynix H27UBG8T2B
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

When decoding the extended ID bytes of a NAND chip, we have to calculate the ID
length according to some heuristic patterns (e.g., Does the ID wrap around?
Does it end in trailing zeros?). Currently, these heuristics are built into
complicated if/else blocks that can be hard to understand.

Now, these checks can be done generically in a function, making them more
robust and reusable. In fact, this sort of calculation is needed in future
additions to nand_base.c. And with this advancement, we get the added benefit
of a more readable "extended ID decode".
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

When detecting NAND parameters, the code gets a little ugly so that the
logic is obscured. Try to remedy that by moving code to separate functions
that have well-defined purposes.

This patch splits out the simple ID decode functionality, where all the
information regarding NAND size/blocksize/pagesize/oobsize/busw is encoded in
the first two bytes of the ID string.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

When detecting NAND parameters, the code gets a little ugly so that the
logic is obscured. Try to remedy that by moving code to separate functions
that have well-defined purposes.

This patch splits out the extended ID decode functionality, which handles
decoding the 3rd-8th ID bytes to determine NAND device parameters.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

When detecting NAND parameters, the code gets a little ugly so that the
logic is obscured. Try to remedy that by moving code to separate functions
that have well-defined purposes.

This patch splits the bad block marker options detection into its own function,
away from the other parameters (e.g., chip size, page size, etc.).
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Instead of reading 2 bytes then later 8 bytes, we can simply read all 8
bytes from the start.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

We don't actually use the 'ret' variable; we set it, test it, and then it dies.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Add the set-features(0xef)/get-features(0xee) helpers for ONFI nand.
Also add the necessary macros.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Added a NAND device flag for subpage read support. Previously this was
hard coded based on large page and soft ECC.
Updated base NAND driver to use the new subpage read flag if the NAND is
large page and soft ECC.
Signed-off-by: NJeff Westfahl <jeff.westfahl@ni.com>
Reviewed-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Just as Artem suggested:

"Both UBI and JFFS2 are able to read verify what they wrote already.
There are also MTD tests which do this verification. So I think there
is no reason to keep this in the NAND layer, let alone wasting RAM in
the driver to support this feature. Besides, it does not work for sub-pages
and many drivers have it broken. It hurts more than it provides benefits."

So kill MTD_NAND_VERIFY_WRITE entirely.
Signed-off-by: NHuang Shijie <shijie8@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The NAND_CHIPOPTIONS_MSK has limited utility and is causing real bugs. It
silently masks off at least one flag that might be set by the driver
(NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND driver and possibly
others.

Really, as long as driver writers exercise a small amount of care with
NAND_* options, this mask is not necessary at all; it was only here to
prevent certain options from accidentally being set by the driver. But the
original thought turns out to be a bad idea occasionally. Thus, kill it.

Note, this patch fixes some major gpmi-nand breakage.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NHuang Shijie <shijie8@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Use the MTD_OPS_PLACE_OOB to replace the hard code "0".
Make the code more readable.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Acked-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

There is an implemention of hardware ECC write page function which may return an
error indication.
For instance, using Atmel HW PMECC to write one page into a nand flash, the hardware
engine will compute the BCH ecc code for this page. so we need read a the
status register to theck whether the ecc code is generated.
But we cannot assume the status register always can be ready, for example,
incorrect hardware configuration or hardware issue, in such case we need
write_page() to return a error code.

Since the definition of 'write_page' function in struct nand_ecc_ctrl is 'void'.
So this patch will:
  1. add return 'int' value for 'write_page' function.
  2. to be consitent, add return 'int' value for 'write_page_raw' fuctions too.
  3. add code to test the return value, and if negative, indicate an
  error happend when write page with ECC.
  4. fix the compile warning in all impacted nand flash driver.

Note: I couldn't compile-test all of these easily, as some had ARCH dependencies.
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

According to its documentation, the NAND_NO_READRDY option is always used
when autoincrement is not supported. Autoincrement support was recently
dropped, so we can drop this options as well (defaulting to "no read ready
check").
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

As of edbc4540 [mtd: driver _read() returns max_bitflips; mtd_read()
returns -EUCLEAN], 'mtd->bitflip_threshold' must be set for mtd devices
having ECC, prior any 'mtd_read()' call.
Otherwise, 'mtd_read()' will falsely return -EUCLEAN.

Normally, 'mtd->bitflip_threshold' is initialized when the MTD is added.

However, this is too late for NAND MTDs, as 'scan_bbt()' is invoked
prior the existing initialization of 'mtd->bitflip_threshold'.

This is a problem since 'scan_bbt()' calls 'mtd_read()', in the case
of a flash-based bad block table.
It resulted in a falsely reported bitflips indication during BBT read,
which lead to constant scrubbing of the flash BBT blocks.

Initialize 'mtd->bitflip_threshold' to its default value (if not already
set by the driver), prior to invocation of 'scan_bbt()'.
Reported-by: NSascha Hauer <s.hauer@pengutronix.de>
Tested-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Apparently, there is an implementor of 'read_oob' which may return an
error inidication (e.g. docg4_read_oob may return -EIO).

Test the return value of 'read_oob/read_oob_raw', and if negative,
propagate the error, so it's returned by the '_read_oob' interface.
Signed-off-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

As of [mtd: nand: remove autoincrement 'sndcmd' code], the
NAND_CMD_READ0 command is issued unconditionally.

Thus, read_oob/read_oob_raw's 'sndcmd' argument is no longer needed, as
well as their return code.

Remove the 'sndcmd' parameter, and set the return code to 0.
Signed-off-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Don't read/write OOB if the caller doesn't require it.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

We now have an interface for notifying the nand_ecc_ctrl functions when OOB
data must be returned to the upper layers and when it may be left untouched.
This patch fills in the 'oob_required' parameter properly from
nand_do_{read,write}_ops. When utilized properly in the lower layers, this
parameter can improve performance and/or reduce complexity for NAND HW and SW
that can simply avoid transferring the OOB data.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
Acked-by: NJiandong Zheng <jdzheng@broadcom.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

New NAND controllers can perform read/write via HW engines which don't expose
OOB data in their DMA mode. To reflect this, we should rework the nand_chip /
nand_ecc_ctrl interfaces that assume that drivers will always read/write OOB
data in the nand_chip.oob_poi buffer. A better interface includes a boolean
argument that explicitly tells the callee when OOB data is requested by the
calling layer (for reading/writing to/from nand_chip.oob_poi).

This patch adds the 'oob_required' parameter to each relevant {read,write}_page
interface; all 'oob_required' parameters are left unused for now. The next
patch will set the parameter properly in the nand_base.c callers, and follow-up
patches will make use of 'oob_required' in some of the callee functions.

Note that currently, there is no harm in ignoring the 'oob_required' parameter
and *always* utilizing nand_chip.oob_poi, but there can be
performance/complexity/design benefits from avoiding filling oob_poi in the
common case. I will try to implement this for some drivers which can be ported
easily.

Note: I couldn't compile-test all of these easily, as some had ARCH
dependencies.

[dwmw2: Merge later 1/0 vs. true/false cleanup]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
Acked-by: NJiandong Zheng <jdzheng@broadcom.com>
Acked-by: NMike Dunn <mikedunn@newsguy.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

No drivers use auto-increment NAND, so kill the NO_AUTOINCR option entirely.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The NAND_NO_AUTOINCR option is always set, so we will kill the option and make
"no autoincrement" the default behavior for nand_base.c. Thus, we should remove
the code which decides whether or not to send the NAND_CMD_READ0 command.
Instead, we unconditionally send the command.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>