Powerpc powernv platforms allow access to certain system flash devices
through a firmwarwe interface. This change adds an mtd driver for these
flash devices.

Minor updates from Jeremy Kerr and Joel Stanley.

Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Reviewed-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

COMPILE_TEST allows us to build this driver on other arch'es. But not
all arch'es have the right I/O accessors -- particularly, x86 is missing
readsl() and writesl().

So just restrict this driver to ARCH_STI. It's still buildable for a
multiplatform ARM kernel, so it can get decent compile coverage.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>

I hear that this driver should depend on ARCH_STI, and that "SH" is not
actually a real symbol. At the same time, let's allow compile-testing on
other ARCH'es.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Huang Shijie <b32955@freescale.com>

Use the new SPI nor framework, and rewrite the m25p80:
 (0) remove all the NOR comands.
 (1) change the m25p->command to an array.
 (2) implement the necessary hooks, such as m25p80_read/m25p80_write.

Tested with the m25p32.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Acked-by: Marek Vasut <marex@denx.de>
[Brian: rebased]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

This is a new driver. It's used to communicate with a special type of
optimised Serial Flash Controller called the FSM. The FSM uses a subset
of the SPI protocol to communicate with supported NOR-Flash devices.

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Remove the compile-time option for FAST_READ, since we have run-time
support for detecting it. This refactors the logic for enabling
fast-read, such that for DT-enabled devices, we honor the
"m25p,fast-read" property but for non-DT devices, we default to using
FAST_READ whenever the flash device supports it.

Normal READ and FAST_READ differ only in the following:

  * FAST_READ supports SPI higher clock frequencies [1]

  * number of dummy cycles; FAST_READ requires 8 dummy cycles (whereas
    READ requires 0) to allow the flash sufficient setup time, even when
    running at higher clock speeds

Thus, for flash chips which support FAST_READ, there is otherwise no
limiting reason why we cannot use the FAST_READ opcode instead of READ.
It simply allows the SPI controller to run at higher clock rates. So
theoretically, nobody should be needing the compile-time option anyway.

  [1] I have a Spansion S25FL128S datasheet which says:

    "The maximum operating clock frequency for the READ command is 50
    MHz."

  And:

    "The maximum operating clock frequency for FAST READ command is 133
    MHz."

Signed-off-by: Brian Norris <computersforpeace@gmail.com>

This patch proposes to remove kernel configuration parameters
defined in drivers/mtd/devices/Kconfig, but used nowhere
in the makefiles and source code (except in comments).

Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

The MTD subsystem has historically tried to be as configurable as possible. The
side-effect of this is that its configuration menu is rather large, and we are
gradually shrinking it. For example, we recently merged partitions support with
the mtdcore.

This patch does the next step - it merges the mtdchar module to mtdcore. And in
this case this is not only about eliminating too fine-grained separation and
simplifying the configuration menu. This is also about eliminating seemingly
useless kernel module.

Indeed, mtdchar is a module that allows user-space making use of MTD devices
via /dev/mtd* character devices. If users do not enable it, they simply cannot
use MTD devices at all. They cannot read or write the flash contents. Is it a
sane and useful setup? I believe not. And everyone just enables mtdchar.

Having mtdchar separate is also a little bit harmful. People sometimes miss the
fact that they need to enable an additional configuration option to have
user-space MTD interfaces, and then they wonder why on earth the kernel does
not allow using the flash? They spend time asking around.

Thus, let's just get rid of this module and make it part of mtd core.

Note, mtdchar had additional configuration option to enable OTP interfaces,
which are present on some flashes. I removed that option as well - it saves a
really tiny amount space.

[dwmw2: Strictly speaking, you can mount file systems on MTD devices just
        fine without the mtdchar (or mtdblock) devices; you just can't do
        other manipulations directly on the underlying device. But still I
        agree that it makes sense to make this unconditional. And Yay! we
        get to kill off an instance of checking CONFIG_foo_MODULE, which is
        an abomination that should never happen.]

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

These drivers are deprecated for very long time, and we have a different driver
for these called "diskonchip". Thus, kill the ancient cruft.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>