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>

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>

The drivers' _read() method, absent an error, returns a non-negative integer
indicating the maximum number of bit errors that were corrected in any one
region comprising an ecc step.  MTD returns -EUCLEAN if this is >=
bitflip_threshold, 0 otherwise.  If bitflip_threshold is zero, the comparison is
not made since these devices lack ECC and always return zero in the non-error
case (thanks Brian)¹.  Note that this is a subtle change to the driver
interface.

This and the preceding patches in this set were tested with ubi on top of the
nandsim and docg4 devices, running the ubi test io_basic from mtd-utils.

¹ http://lists.infradead.org/pipermail/linux-mtd/2012-March/040468.htmlSigned-off-by: NMike Dunn <mikedunn@newsguy.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NBrian Norris <computersforpeace@gmail.com>
Ivan Djelic <ivan.djelic@parrot.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch adds sanity checks that ensure that drivers for controllers with
hardware ECC set the 'strength' element in struct nand_ecc_ctrl.  Also stylistic
changes to the line that calculates strength for software ECC.

This v2 simplifies the check.  Thanks Brian!¹

¹ http://lists.infradead.org/pipermail/linux-mtd/2012-April/040890.htmlSigned-off-by: NMike Dunn <mikedunn@newsguy.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>

The ecc.read_page() method for nand drivers is changed to return the maximum
number of bitflips that were corrected on any one region covering an ecc step,
This patch doesn't change what the nand code returns to mtd.

This v2 includes the change to the fsl_ifc_nand driver requested by Scott¹.

¹ http://lists.infradead.org/pipermail/linux-mtd/2012-April/040883.htmlSigned-off-by: NMike Dunn <mikedunn@newsguy.com>
Acked-by (freescale changes): Scott Wood <scottwood@freescale.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

ecc_strength element of mtd_info will be the strength of one ecc step, not of
the entire writesize, as was previously planned.  This is the appropriate way
because, as was pointed out¹, bit errors in excess of the strength of one
step can cause a hard error if they all occur within the same ecc region.

¹ http://lists.infradead.org/pipermail/linux-mtd/2012-March/040313.htmlSigned-off-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>

To make sure the NAND chip is properly programmed we need a status
command before each page write. When CONFIG_MTD_NAND_VERIFY_WRITE=y this
assumption is broken when writing multiple pages consecutively. This
patch fixes this.
Signed-off-by: NBastian Hecht <hechtb@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Some not-supported nand chips may pass the current parsing code,
and get the wrong page size and oob size. Sometimes, it's hard to notice
that you get the wrong values, because there is no warning or error.

So it's useful to print out the page size and oob size in the end of
the parsing function. We can check these values with the datasheet of the nand
chip as soon as possible.

Artem: amend the print a bit
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>

Initialization of 'erase_info->fail_addr' to MTD_FAIL_ADDR_UNKNOWN prior
erase operation is duplicated accross several MTD drivers, and also taken
care of by some MTD users as well.

Harmonize it: initialize 'fail_addr' within 'mtd_erase()' 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>