Michal Suchanek [Tue, 18 Aug 2015 15:34:09 +0000 (15:34 +0000)]
mtd: ofpart: move ofpart partitions to a dedicated dt node
Parsing direct subnodes of a mtd device as partitions is unreliable
since the mtd device is also part of its bus subsystem and can contain
bus data in subnodes.
Move ofpart data to a subnode of its own so it is clear which data is
part of the partition layout.
Signed-off-by: Michal Suchanek <hramrach@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Michal Suchanek [Wed, 28 Oct 2015 22:48:06 +0000 (15:48 -0700)]
doc: dt: mtd: support partitions in a special 'partitions' subnode
To avoid conflict with other drivers using subnodes of the mtd device
create only one ofpart-specific node rather than any number of
arbitrary partition subnodes.
Signed-off-by: Michal Suchanek <hramrach@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Anup Patel [Fri, 30 Oct 2015 06:59:20 +0000 (12:29 +0530)]
mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.
This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.
Signed-off-by: Anup Patel <anup.patel@broadcom.com> Reviewed-by: Ray Jui <rjui@broadcom.com> Reviewed-by: Scott Branden <sbranden@broadcom.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Brian Norris [Sun, 11 Oct 2015 20:03:47 +0000 (13:03 -0700)]
mtd: mtdpart: Do not fail mtd probe when parsing partitions fails
Due to wrong assumption in ofpart ofpart fails on Exynos on SPI chips
with no partitions because the subnode containing controller data
confuses the ofpart parser.
Thus compiling in ofpart support automatically fails probing any SPI NOR
flash without partitions on Exynos.
Compiling in a partitioning scheme should not cause probe of otherwise
valid device to fail.
Instead, let's do the following:
* try parsers until one succeeds
* if no parser succeeds, report the first error we saw
* even in the failure case, allow MTD to probe, with fallback
partitions or no partitions at all -- the master device will still be
registered
Issue report and comments initially by Michal Suchanek.
Reported-by: Michal Suchanek <hramrach@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Han Xu [Fri, 23 Oct 2015 18:18:28 +0000 (13:18 -0500)]
mtd: fsl-quadspi: fix macro collision problems with READ/WRITE
Change the READ/WRITE to FSL_READ/FSL_WRITE to resolve any possible
namespace collisions with READ/WRITE macros (e.g., from <linux/fs.h>).
Problems have been seen, for example, on mips:
>> drivers/mtd/spi-nor/fsl-quadspi.c:186:5: error: 'LUT_0' undeclared (first use in this function)
((LUT_##ins) << INSTR0_SHIFT))
^
>> drivers/mtd/spi-nor/fsl-quadspi.c:188:30: note: in expansion of macro 'LUT0'
On SPARC:
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
drivers/mtd/spi-nor/fsl-quadspi.c:369:1: error: 'LUT_0' undeclared (first use in this function)
drivers/mtd/spi-nor/fsl-quadspi.c:418:1: error: pasting "LUT_" and "(" does not give a valid preprocessing token
drivers/mtd/spi-nor/fsl-quadspi.c:418:2: error: implicit declaration of function 'LUT_'
And surely on others.
Fixes: d26a22d06708 ("mtd: fsl-quadspi: allow building for other ARCHes with COMPILE_TEST") Reported-by: Guenter Roeck <linux@roeck-us.net> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Han Xu <b45815@freescale.com>
[Brian: rewrote commit description] Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Brian Norris [Mon, 1 Jun 2015 23:17:20 +0000 (16:17 -0700)]
mtd: warn when registering the same master many times
When CONFIG_MTD_PARTITIONED_MASTER=y, it is fatal to call
mtd_device_parse_register() twice on the same MTD, as we try to register
the same device/kobject multipile times.
When CONFIG_MTD_PARTITIONED_MASTER=n, calling
mtd_device_parse_register() is more of just a nuisance, as we can mostly
navigate around any conflicting actions.
But anyway, doing so is a Bad Thing (TM), and we should complain loudly
for any drivers that try to do this.
Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Richard Weinberger <richard@nod.at>
Brian Norris [Mon, 1 Jun 2015 23:17:19 +0000 (16:17 -0700)]
mtd: fixup corner case error handling in mtd_device_parse_register()
Since commit 3efe41be224c ("mtd: implement common reboot notifier
boilerplate"), we might try to register a reboot notifier for an MTD
that failed to register. Let's avoid this by making the error path
clearer.
Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Richard Weinberger <richard@nod.at>
Shraddha Barke [Thu, 22 Oct 2015 14:59:54 +0000 (20:29 +0530)]
mtd: tests: Replace timeval with ktime_t
Changes the 32-bit time type timeval to the 64-bit time type
ktime_t, since 32-bit systems using struct timeval will break in the
year 2038. Correspondingly change do_gettimeofday() to ktime_get()
since ktime_get returns a ktime_t, but do_gettimeofday returns a
struct timeval.Here, ktime_get() is used instead of ktime_get_real()
since ktime_get() uses monotonic clock.
Stefan Roese [Mon, 19 Oct 2015 06:40:13 +0000 (08:40 +0200)]
mtd: fsmc_nand: Add BCH4 SW ECC support for SPEAr600
This patch adds support for 4-bit ECC BCH4 for the SPEAr600 SoC. This can
be used by boards equipped with a NAND chip that requires 4-bit ECC
strength. The SPEAr600 HW ECC only supports 1-bit ECC strength.
To enable SW BCH4, you need to specify this in your nand controller
DT node:
Alex Smith [Tue, 6 Oct 2015 13:52:07 +0000 (14:52 +0100)]
mtd: nand: increase ready wait timeout and report timeouts
If nand_wait_ready() times out, this is silently ignored, and its
caller will then proceed to read from/write to the chip before it is
ready. This can potentially result in corruption with no indication as
to why.
While a 20ms timeout seems like it should be plenty enough, certain
behaviour can cause it to timeout much earlier than expected. The
situation which prompted this change was that CPU 0, which is
responsible for updating jiffies, was holding interrupts disabled
for a fairly long time while writing to the console during a printk,
causing several jiffies updates to be delayed. If CPU 1 happens to
enter the timeout loop in nand_wait_ready() just before CPU 0 re-
enables interrupts and updates jiffies, CPU 1 will immediately time
out when the delayed jiffies updates are made. The result of this is
that nand_wait_ready() actually waits less time than the NAND chip
would normally take to be ready, and then read_page() proceeds to
read out bad data from the chip.
The situation described above may seem unlikely, but in fact it can be
reproduced almost every boot on the MIPS Creator Ci20.
Therefore, this patch increases the timeout to 400ms. This should be
enough to cover cases where jiffies updates get delayed. In nand_wait()
the timeout was previously chosen based on whether erasing or
programming. This is changed to be 400ms unconditionally as well to
avoid similar problems there. nand_wait() is also slightly refactored
to be consistent with nand_wait{,_status}_ready(). These changes should
have no effect during normal operation.
Debugging this was made more difficult by the misleading comment above
nand_wait_ready() stating "The timeout is caught later" - no timeout was
ever reported, leading me away from the real source of the problem.
Therefore, a pr_warn() is added when a timeout does occur so that it is
easier to pinpoint similar problems in future.
Signed-off-by: Alex Smith <alex.smith@imgtec.com> Signed-off-by: Harvey Hunt <harvey.hunt@imgtec.com> Reviewed-by: Niklas Cassel <niklas.cassel@axis.com> Cc: Alex Smith <alex@alex-smith.me.uk> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Niklas Cassel <niklas.cassel@axis.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The problem is that if the very last device_create_file() fails, then we
are beyond the end of the array. Actually, any time i == 3 then there
is a problem. We can fix this an simplify the code at the same time by
moving the !ret conditions out of the for loops and using a goto
instead.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Antoine Ténart [Wed, 21 Oct 2015 08:29:03 +0000 (10:29 +0200)]
mtd: pxa3xx_nand: rework flash detection and timing setup
Rework the pxa3xx_nand driver to allow using functions exported by the
nand framework to detect the flash and the timings. Then setup the
timings using the helpers previously added.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Antoine Ténart [Wed, 21 Oct 2015 08:29:02 +0000 (10:29 +0200)]
mtd: pxa3xx_nand: add helpers to setup the timings
Add helpers to setup the timings in the pxa3xx driver. These helpers
allow to either make use of the nand framework nand_sdr_timings or the
pxa3xx specific pxa3xx_nand_host, for compatibility reasons.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Antoine Ténart [Wed, 21 Oct 2015 08:29:00 +0000 (10:29 +0200)]
mtd: pxa3xx_nand: fix some compile issues on non-ARM arches
Using readsl() result in a build error on i386. Fix this by using
ioread32_rep() instead, to allow compile testing the pxa3xx nand driver
on other architectures later.
Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Brian Norris [Mon, 19 Oct 2015 19:22:57 +0000 (12:22 -0700)]
mtd: maps: rbtx4939-flash: fix compile error
We got the syntax wrong here. Compile tested this time!
Error:
drivers/mtd/maps/rbtx4939-flash.c: In function 'rbtx4939_flash_probe':
>> drivers/mtd/maps/rbtx4939-flash.c:99:11: error: request for member 'dev' in something not a structure or union
info->mtd.dev.parent = &dev->dev;
^
Fixes: 9aa7e50276c1 ("mtd: maps: rbtx4939-flash: show parent device in sysfs") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Cc: Frans Klaver <fransklaver@gmail.com>
mtd_{suspend,resume}() get called from mtdcore in a class suspend/resume
callback. We don't need to call them again here. In practice, this would
actually work OK, as nand_base actually handles nesting OK -- it just
might print warnings.
Untested, but there are few (no?) users of PM for this driver AFAIK.
Fabio Estevam [Wed, 14 Oct 2015 03:39:44 +0000 (00:39 -0300)]
mtd: fsl-quadspi: Include <linux/sizes.h> to avoid build error
Building for x86 results in the following build errors:
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
>> drivers/mtd/spi-nor/fsl-quadspi.c:355:21: error: 'SZ_16M' undeclared (first use in this function)
if (q->nor_size <= SZ_16M) {
^
drivers/mtd/spi-nor/fsl-quadspi.c:355:21: note: each undeclared identifier is reported only once for each function it appears in
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_read':
>> drivers/mtd/spi-nor/fsl-quadspi.c:208:27: error: 'SZ_4M' undeclared (first use in this function)
#define QUADSPI_MIN_IOMAP SZ_4M
^
>> drivers/mtd/spi-nor/fsl-quadspi.c:845:25: note: in expansion of macro 'QUADSPI_MIN_IOMAP'
q->memmap_len = len > QUADSPI_MIN_IOMAP ? len : QUADSPI_MIN_IOMAP;
Explicitly include <linux/sizes.h> to fix the problem.
Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Brian Norris [Mon, 12 Oct 2015 20:35:15 +0000 (13:35 -0700)]
mtd: fsl-quadspi: fix printk() format warning for size_t
Seen when compile-testing on non-32-bit arch:
CC drivers/mtd/spi-nor/fsl-quadspi.o
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_read':
drivers/mtd/spi-nor/fsl-quadspi.c:873:2: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t' [-Wformat=]
dev_dbg(q->dev, "cmd [%x],read from 0x%p, len:%d\n",
^
Also drop the '0x' prefixing to the '%p' formatter, since %p already
knows how to format pointers appropriately.
Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Han xu <han.xu@freescale.com>
Brian Norris [Tue, 1 Sep 2015 19:57:11 +0000 (12:57 -0700)]
mtd: spi-nor: refactor block protection functions
This code was a bit sloppy, would produce a lot of copy-and-paste, and
did not always provide a sensible interface:
* It didn't validate the length for LOCK and the offset for UNLOCK, so
we were essentially discarding half of the user-supplied data and
assuming what they wanted to lock/unlock
* It didn't do very good error checking
* It didn't make use of the fact that this operation works on
power-of-two dimensions
So, rewrite this to do proper bit arithmetic rather than a bunch of
hard-coded condition tables. Now we have:
* More comments on how this was derived
* Notes on what is (and isn't) supported
* A more exendible function, so we could add support for other
protection ranges
* More accurate locking - e.g., suppose the top quadrant is locked (75%
to 100%); then in the following cases, case (a) will succeed but (b)
will not (return -EINVAL):
(a) user requests lock 3rd quadrant (50% to 75%)
(b) user requests lock 3rd quadrant, minus a few blocks (e.g., 50%
to 73%)
Case (b) *should* fail, since we'd have to lock blocks that weren't
requested. But the old implementation didn't know the difference and
would lock the entire second half (50% to 100%)
This refactoring work will also help enable the addition of
mtd_is_locked() support and potentially the support of bottom boot
protection (TB=1).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Brian Norris [Tue, 1 Sep 2015 19:57:08 +0000 (12:57 -0700)]
mtd: spi-nor: add SPI NOR manufacturer IDs
These are often similar for CFI (parallel NOR) and for SPI NOR, but they
aren't always the same, for various reasons (different namespaces,
company acquisitions and renames, etc.). And some don't have CFI_MFR_*
entries at all.
So let's make a proper place to list the SPI NOR IDs, with all the SPI
NOR specific assumptions and comments.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Boris BREZILLON [Tue, 13 Oct 2015 09:22:18 +0000 (11:22 +0200)]
mtd: nand: pass page number to ecc->write_xxx() methods
The ->read_xxx() methods are all passed the page number the NAND controller
is supposed to read, but ->write_xxx() do not have such a parameter.
This is a problem if we want to properly implement data
scrambling/randomization in order to mitigate MLC sensibility to repeated
pattern: to prevent bitflips in adjacent pages in the same block we need
to avoid repeating the same pattern at the same offset in those pages,
hence the randomizer/scrambler engine need to be passed the page value
in order to adapt its seed accordingly.
Moreover, adding the page parameter to the ->write_xxx() methods add some
consistency to the current API.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> CC: Josh Wu <josh.wu@atmel.com> CC: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> CC: Maxime Ripard <maxime.ripard@free-electrons.com> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Huang Shijie <shijie.huang@arm.com> CC: Stefan Agner <stefan@agner.ch> CC: devel@driverdev.osuosl.org CC: linux-arm-kernel@lists.infradead.org CC: linux-kernel@vger.kernel.org Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Frans Klaver [Wed, 10 Jun 2015 20:38:35 +0000 (22:38 +0200)]
mtd: maps: sa1100-flash: show parent device in sysfs
Fix a bug where mtd parent device symlinks aren't shown in sysfs.
While at it, make use of the default owner value set by mtdcore.
Incidentally, it seems the owner field in the concatenated mtds is not
actually used, so this shouldn't make much of a difference anyway.
Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Frans Klaver [Wed, 10 Jun 2015 20:38:16 +0000 (22:38 +0200)]
mtd: core: set some defaults when dev.parent is set
If a parent device is set, add_mtd_device() has enough knowledge to fill
in some sane default values for the module name and owner. Do so if they
aren't already set.
Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Frans Klaver [Wed, 10 Jun 2015 20:38:15 +0000 (22:38 +0200)]
mtd: core: tone down suggestion that dev.parent should be set
add_mtd_device() has a comment suggesting that the caller should have
set dev.parent. This is required to have the parent device symlink show
up in sysfs, but not for proper operation of the mtd device itself.
Currently we have five drivers registering mtd devices during module
initialization, so they don't actually provide a parent device to link
to. That means we cannot WARN_ON() here, as it would trigger false
positives.
Make the comment a bit less firm in its assertion that dev.parent should
be set.
Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Anup Patel [Fri, 2 Oct 2015 17:56:42 +0000 (23:26 +0530)]
mtd: brcmnand: Fix pointer type-cast in brcmnand_write()
We should always type-cast pointer to "long" or "unsigned long"
because size of pointer is same as machine word size. This will
avoid pointer type-cast issues on both 32bit and 64bit systems.
This patch fixes pointer type-cast issue in brcmnand_write()
as-per above info.
Signed-off-by: Anup Patel <anup.patel@broadcom.com> Reviewed-by: Vikram Prakash <vikramp@broadcom.com> Reviewed-by: Ray Jui <rjui@broadcom.com> Reviewed-by: Scott Branden <sbranden@broadcom.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>