The NAND framework provides several helpers to query timing modes supported
by a NAND chip, but this implies that all NAND controller drivers have
to implement the same timings selection dance. Also currently NAND
devices can be resetted at arbitrary places which also resets the timing
for ONFI chips to timing mode 0.

Provide a common logic to select the best timings based on ONFI or
->onfi_timing_mode_default information. Hook this into nand_reset()
to make sure the new timing is applied each time during a reset.

NAND controller willing to support timings adjustment should just
implement the ->setup_data_interface() method.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

The nand layer will need ONFI mode 0 to use it as timing mode
before and right after reset.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

onfi_init_data_interface() initializes a data interface with
values from a given ONFI mode.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

struct nand_data_interface is the designated type to pass to
the NAND drivers to configure the timing. To simplify further
patches convert the onfi_sdr_timings array from type struct
nand_sdr_timings nand_data_interface.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

When NAND devices are resetted some initialization may have to be done,
like for example they have to be configured for the timing mode that
shall be used. To get a common place where this initialization can be
implemented create a nand_reset() function. This currently only issues
a NAND_CMD_RESET to the NAND device. The places issuing this command
manually are replaced with a call to nand_reset().
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Some Keystone devices (e.g. K2G) include a OMAP NAND IP.
Allow the NAND driver to be usable for both
Keystone and OMAP devices.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

This patch adds big endian and ONFI support for various iProc based
SoCs that use the core brcmstb NAND controller

This patch was originally implemented by Prafulla Kota
<prafulla.kota@broadcom.com> and fully tested on iProc based NS2 SVK
Signed-off-by: NPrafulla Kota <prafulla.kota@broadcom.com>
Signed-off-by: NRay Jui <ray.jui@broadcom.com>
Reviewed-by: NKamal Dasu <kdasu.kdev@gmail.com>
Acked-by: NKamal Dasu <kdasu.kdev@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

If erasing or writing the BBT fails, we should mark the current BBT
block as bad and use the BBT descriptor to scan for the next available
unused block in the BBT. We should only return a failure if there isn't
any space left.
Signed-off-by: NKyle Roeschley <kyle.roeschley@ni.com>
Suggested-by: NJeff Westfahl <jeff.westfahl@ni.com>
Tested-by: NKyle Roeschley <kyle.roeschley@ni.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

This clarifies the write_bbt() function by removing the write label
and simplifying the error/exit path.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: NKyle Roeschley <kyle.roeschley@ni.com>

In the ONFI spec, the tRR_min entry is defined before the tRST_max one.
Reoder the definition to make it easier to review.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

ONFI 4.0 spec defines different values for the tADL_min timing.
Since we don't want to have different timings depending on the ONFI
version, we just set tADL_min to the maximum value (the one specified
in the ONFI 4.0 spec).
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

change the way to calculate pagesize to get correct free oob space for
legacy_set_geometry function.
Signed-off-by: NHan Xu <han.xu@nxp.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Some build tools noticed that 'cookie' is being set but not used. Might
as well catch the errors here and handle them the same way we handle
other DMA prep steps.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The driver registered for CPU frequency transitions to recalculate its
clock when ARM clock frequency changes (ratio between frequencies of
ARM's parent clock (fclk) and clock for peripherals remains fixed).

This is needed only on S3C24xx platform when cpufreq driver is enabled
so limit the ifdef to respective cpufreq Kconfig.
Suggested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Using "goto" and "switch" statement only makes it harder to follow
control flow and doesn't bring any advantages. Rewrite the code to avoid
using "goto".
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

If no user specified chip->select_chip() function is provided, code in
nand_base.c will automatically set this hook to nand_select_chip(),
which in turn depends on chip->cmd_ctrl() hook being valid. Not
providing both of those functions in NAND controller driver (for example
by mistake) will result in a bit cryptic segfault. Same is true for
chip->cmdfunc().

To avoid the above scenario add a check in nand_scan_dent and error out
if cmd_ctrl() is not provided.
Suggested-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Suggested-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Config MTD_NAND_FSL_IFC is already located inside 'if MTD_NAND'
statment, so there's no need to explicitly specify it as a dependency.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

MTD_NAND_FSL_ELBC selects FSL_LBC that in turn depends on FSL_SOC, so
depending on PPC instead of FSL_SOC leads to this message:

	  warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC &&
	  MTD_NAND_FSL_UPM) selects FSL_LBC which has unmet direct
	  dependencies (FSL_SOC)

when doing

	  make ARCH=powerpc \
	       CROSS_COMPILE=powerpc-e500v2-linux-gnuspe- \
	       allmodconfig"

Changing dependency to FSL_SOC fixes that.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The code to initialize a struct nand_hw_control is duplicated across
several drivers. Factorize it using an inline function.
Signed-off-by: NMarc Gonzalez <marc_gonzalez@sigmadesigns.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The use of config_enabled() against config options is ambiguous.  In
practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the
author might have used it for the meaning of IS_ENABLED().  Using
IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc.  makes the intention
clearer.

This commit replaces config_enabled() with IS_ENABLED() where possible.
This commit is only touching bool config options.

I noticed two cases where config_enabled() is used against a tristate
option:

 - config_enabled(CONFIG_HWMON)
  [ drivers/net/wireless/ath/ath10k/thermal.c ]

 - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)
  [ drivers/gpu/drm/gma500/opregion.c ]

I did not touch them because they should be converted to IS_BUILTIN()
in order to keep the logic, but I was not sure it was the authors'
intention.

Link: http://lkml.kernel.org/r/1465215656-20569-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NKees Cook <keescook@chromium.org>
Cc: Stas Sergeev <stsp@list.ru>
Cc: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Joshua Kinard <kumba@gentoo.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: "Dmitry V. Levin" <ldv@altlinux.org>
Cc: yu-cheng yu <yu-cheng.yu@intel.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Will Drewry <wad@chromium.org>
Cc: Nikolay Martynov <mar.kolya@gmail.com>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Cc: Rafal Milecki <zajec5@gmail.com>
Cc: James Cowgill <James.Cowgill@imgtec.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Alex Smith <alex.smith@imgtec.com>
Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
Cc: Qais Yousef <qais.yousef@imgtec.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Tony Wu <tung7970@gmail.com>
Cc: Huaitong Han <huaitong.han@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Andrea Gelmini <andrea.gelmini@gelma.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Rabin Vincent <rabin@rab.in>
Cc: "Maciej W. Rozycki" <macro@imgtec.com>
Cc: David Daney <david.daney@cavium.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

...don't waste memory by allocating one sizeof(int) per
PEB.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Since PEB erasure is asynchornous it can happen that there is
more than one Fastmap on the MTD. This is fine because the attach logic
will pick the Fastmap data structure with the highest sequence number.

On a not so well configured MTD stack spurious ECC errors are common.
Causes can be different, bad hardware, wrong operating modes, etc...
If the most current Fastmap renders bad due to ECC errors UBI might
pick an older Fastmap to attach from.
While this can only happen on an anyway broken setup it will show
completely different sympthoms and makes finding the root cause much
more difficult.
So, be debug friendly and fall back to scanning mode of we're facing
an ECC error while scanning for Fastmap.

Cc: <stable@vger.kernel.org>
Signed-off-by: NRichard Weinberger <richard@nod.at>

This helps to detect cases where an user copies an UBI image to
another target with different bad blocks.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Introduce a new list to the UBI attach information
object to be able to deal better with old and corrupted
Fastmap eraseblocks.
Also move more Fastmap specific code into fastmap.c.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Signed-off-by: NRichard Weinberger <richard@nod.at>

This makes the logic more easy to follow.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Signed-off-by: NRichard Weinberger <richard@nod.at>

When the volume resize operation shrinks a volume,
LEBs will be unmapped. Since unmapping will not erase these
LEBs immediately we have to wait for that operation to finish.
Otherwise in case of a power cut right after writing the new
volume table the UBI attach process can find more LEBs than the
volume table knows. This will render the UBI image unattachable.

Fix this issue by waiting for erase to complete and write the new
volume table afterward.

Cc: <stable@vger.kernel.org>
Reported-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

We cannot use ubi_* logging functions before the UBI
object is initialized.

Cc: <stable@vger.kernel.org>
Fixes: 32608703 ("UBI: Extend UBI layer debug/messaging capabilities")
Signed-off-by: NRichard Weinberger <richard@nod.at>

There is no need to call get/put on the module
reference in gluebi_get/put_device() callbacks.
Since mtd->owner is the gluebi module itself
mtdcore.c will take care of proper refcounting
in __get/put_mtd_device() before executing the
callbacks.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Install the UBI device object before we arm sysfs.
Otherwise udev tries to read sysfs attributes before UBI is ready and
udev rules will not match.

Cc: <stable@vger.kernel.org>
Signed-off-by: NIosif Harutyunov <iharutyunov@sonicwall.com>
[rw: massaged commit message]
Signed-off-by: NRichard Weinberger <richard@nod.at>

When reading the vid hdr from the device UBI always reads a whole
page. Instead, read only the data we actually need and speed up
attachment of UBI devices by potentially making use of reading
subpages if the NAND driver supports it.

Since the VID header may be at offset vid_hdr_shift in the page and
we can only read from the beginning of a page we have to add that
offset to the read size.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NRichard Weinberger <richard@nod.at>

This controller driver is used only on ARM but is mostly written
portably so it can build on other arch'es. Unfortunately, at least x86
doesn't provibe readsl()/writesl() accessors. We could possibly fix this
issue in the future by using io{read,write}32_rep() instead, but let's
just drop the architectures we aren't using for now.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Remove duplicated include.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

nand_do_write_ops() determines if it is writing a partial page with the
formula:
	part_pagewr = (column || writelen < (mtd->writesize - 1))

When 'writelen' is exactly 1 byte less than the NAND page size the formula
equates to zero, so the code doesn't process it as a partial write,
although it should.
As a consequence the function remains in the while(1) loop with 'writelen'
becoming 0xffffffff and iterating endlessly.

The bug may not be easy to reproduce in Linux since user space tools
usually force the padding or round-up the write size to a page-size
multiple.
This was discovered in U-Boot where the issue can be reproduced by
writing any size that is 1 byte less than a page-size multiple.
For example, on a NAND with 2K page (0x800):
	=> nand erase.part <partition>
	=> nand write $loadaddr <partition> 7ff

[Editor's note: the bug was added in commit 29072b96, but moved
around in commit 66507c7b ("mtd: nand: Add support to use nand_base
poi databuf as bounce buffer")]

Fixes: 29072b96 ("[MTD] NAND: add subpage write support")
Signed-off-by: NHector Palacios <hector.palacios@digi.com>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

We dropped strict MIPS dependency for bcm47xxsflash driver in:
commit 5651d6aa ("mtd: bcm47xxsflash: use ioremap_cache() instead of
KSEG0ADDR()") but using ioremap_cache still limits building it to few
selected architectures only.

A recent commit 57d8f7dd ("bcma: allow enabling serial flash support
on non-MIPS SoCs") automatically dropped MIPS dependency for
MTD_BCM47XXSFLASH which broke building e.g. on powerpc and cris.

The bcma change is alright as it doesn't break building bcma code in any
way. MTD_BCM47XXSFLASH on the other hand should be limited to archs
which need it and can build it (by providing ioremap_cache).

Fixes: 57d8f7dd ("bcma: allow enabling serial flash support on non-MIPS SoCs")
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Acked-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

For years now we support writing to BCMA SoC serial flash, so don't
describe this driver as providing read-only support anymore.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add support for the Cadence QSPI controller. This controller is
present in the Altera SoCFPGA SoCs and this driver has been tested
on the Cyclone V SoC.
Signed-off-by: NGraham Moore <grmoore@opensource.altera.com>
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Alan Tull <atull@opensource.altera.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Graham Moore <grmoore@opensource.altera.com>
Cc: Vignesh R <vigneshr@ti.com>
Cc: Yves Vandervennet <yvanderv@opensource.altera.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Change the BUG_ON() condition in brcmnand_send_cmd() which checks for
the interrupt status "controller ready" bit to a WARN_ON.

There is no good reason to kill the system when this condition occur
because we could have systems which listed the NAND controller as
available (e.g: from Device Tree), but the NAND chip could be
malfunctioning and not responding.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Acked-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NKamal Dasu <kdasu.kdev@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

There is a cut and paste issue here.  The bug is that we are allocating
more memory than necessary for msp_maps.  We should be allocating enough
space for a map_info struct (144 bytes) but we instead allocate enough
for an mtd_info struct (1840 bytes).  It's a small waste.

The other part of this is not harmful but when we allocated msp_flash
then we allocated enough space fro a map_info pointer instead of an
mtd_info pointer.  But since pointers are the same size it works out
fine.

Anyway, I decided to clean up all three allocations a bit to make them
a bit more consistent and clear.

Fixes: 68aa0fa8 ('[MTD] PMC MSP71xx flash/rootfs mappings')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>