Marek Vasut | 3 Sep 18:35 2015
Picon
Picon

[PATCH V2 1/2] mtd: spi-nor: Decouple SPI NOR's device_node from controller device

The problem this patch is trying to address is such, that SPI NOR flash
devices attached to a dedicated SPI NOR controller cannot read their
properties from the associated struct device_node.

A couple of facts first:
1) Each SPI NOR flash has a struct spi_nor associated with it.
2) Each SPI NOR flash has certain device properties associated
   with it, for example the OF property 'm25p,fast-read' is a
   good pick. These properties are used by the SPI NOR core to
   select which opcodes are sent to such SPI NOR flash. These
   properties are coming from spi_nor .dev->of_node .

The problem is, that for SPI NOR controllers, the struct spi_nor .dev
element points to the struct device of the SPI NOR controller, not the
SPI NOR flash. Therefore, the associated dev->of_node also is the
one of the controller and therefore the SPI NOR core code is trying to
parse the SPI NOR controller's properties, not the properties of the
SPI NOR flash.

Note: The m25p80 driver is not affected, because the controller and
      the flash are the same device, so the associated device_node
      of the controller and the flash are the same.

This patch adjusts the SPI NOR core such that the device_node is not
picked from spi_nor .dev directly, but from a new separate spi_nor
.flash_node element. This let's the SPI NOR controller drivers set up
a different spi_nor .flash_node element for each SPI NOR flash.

This patch also fixes the controller drivers to be compatible with
this modification and correctly set the spi_nor .flash_node element.
(Continue reading)

Boris Brezillon | 3 Sep 18:03 2015

[RESEND PATCH v3 0/5] mtd: nand: properly handle bitflips in erased pages

Hello Brian,

Sorry for the noise, the previous submission was containing duplicate
patches :-/.

Here is a new version of the generic 'bitflips in erased pages' series.

I slightly modified the second patch of the previous series to address some
of your concerns and optimize a bit in case some implementations already
fix bitflips in erased pages.

If you're not happy with the changes in patches 2 to 5, could you at least
consider taking the first one?

This patch series aims at providing a common logic to check for bitflips
in erased pages.

Currently each driver is implementing its own logic to check for bitflips
in erased pages. Not only this create code duplication, but most of these
implementations are incorrect.
Here are a few aspects that are often left aside in those implementations:
1/ they do not check OOB bytes when checking for the ff pattern, which
   means they can consider a page as empty while the MTD user actually
   wanted to write almost ff with a few bits to zero
2/ they check for the ff pattern on the whole page, while ECC actually
   works on smaller chunks (usually 512 or 1024 bytes chunks)
3/ they use random bitflip thresholds to decide whether a page/chunk is
   erased or not. IMO this threshold should be set to ECC strength (or
   at least something correlated to this parameter)

(Continue reading)

Boris Brezillon | 3 Sep 17:58 2015

[PATCH v3 0/5] mtd: nand: properly handle bitflips in erased pages

Hello Brian,

Here is a new version of the generic 'bitflips in erased pages' series.

I slightly modified the second patch of the previous series to address some
of your concerns and optimize a bit in case some implementations already
fix bitflips in erased pages.

If you're not happy with the changes in patches 2 to 5, could you at least
consider taking the first one?

This patch series aims at providing a common logic to check for bitflips
in erased pages.

Currently each driver is implementing its own logic to check for bitflips
in erased pages. Not only this create code duplication, but most of these
implementations are incorrect.
Here are a few aspects that are often left aside in those implementations:
1/ they do not check OOB bytes when checking for the ff pattern, which
   means they can consider a page as empty while the MTD user actually
   wanted to write almost ff with a few bits to zero
2/ they check for the ff pattern on the whole page, while ECC actually
   works on smaller chunks (usually 512 or 1024 bytes chunks)
3/ they use random bitflip thresholds to decide whether a page/chunk is
   erased or not. IMO this threshold should be set to ECC strength (or
   at least something correlated to this parameter)

The approach taken in this series is to provide two helper functions to
check for bitflips in erased pages. Each driver that needs to check for
such cases can then call the nand_check_erased_ecc_chunk() function, and
(Continue reading)

Andrea Scian | 3 Sep 16:15 2015
Picon

[RFC] MTD BoF at ELCE 2015 [was [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions]


Dear Boris, Richard and all the other MTD developers,

I take the idea from a nearly-one-month-ago-thread to ask for comment 
about what Richard proposed at that time.

Il 06/08/2015 11:42, Richard Weinberger ha scritto:
 >
 > Am 06.08.2015 um 11:19 schrieb Boris Brezillon:
 >>> I think this needs more discussion.
 >>>
 >>> Boris, Brian, will you be at Embedded Linux Conference Europe
 >>> in Dublin?
 >>> Maybe we can discuss these issues (data retention, ff-checks,
 >>> etc...) in person and figure out where to address them.
 >>> I really want to avoid ad-hoc solutions. :)
 >>
 >> I'll be at ELCE and I'd be happy to discuss all these NAND/MTD/UBI
 >> related issues with you, though I think we should keep discussing
 >> those problems on the ML too.
 >
 > Sure, I did not recommend a secret meeting. ;-)
 > But often a face to face conversation is better for brain storming.
 >

I'll be at ELCE too and I'll be glad to meet all of you.
For sure I'll attend to Richard presentation!

I'm wondering if we can organize something like a mini-summit or BoF 
about MTD/UBI.
(Continue reading)

Brian Norris | 3 Sep 01:43 2015
Picon

[PATCH] mtd: spi-nor: fix NULL dereference when no match found in spi_nor_ids[]

Commit 06bb6f5a69df ("mtd: spi-nor: stop (ab)using struct
spi_device_id") converted an array into a pointer, which means that
we should be checking if the pointer goes anywhere, not whether the C
string is empty. To do the latter means we dereference a NULL pointer
when we reach the terminating entry, for which 'name' is now NULL
instead of an array { 0, 0, ... }.

Sample crash:

[    1.101371] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    1.109457] pgd = c0004000
[    1.112157] [00000000] *pgd=00000000
[    1.115736] Internal error: Oops: 5 [#1] SMP ARM
[    1.120345] Modules linked in:
[    1.123405] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.2.0-next-20150902+ #61
[    1.130611] Hardware name: Rockchip (Device Tree)
[    1.135306] task: ee0b8d40 ti: ee0ba000 task.ti: ee0ba000
[    1.140697] PC is at spi_nor_scan+0x90/0x8c4
[    1.144958] LR is at spi_nor_scan+0xa4/0x8c4
...
[    1.504112] [<c03cc2e0>] (spi_nor_scan) from [<c03cb188>] (m25p_probe+0xc8/0x11c)
[    1.511583] [<c03cb188>] (m25p_probe) from [<c03cd9d8>] (spi_drv_probe+0x60/0x7c)
[    1.519055] [<c03cd9d8>] (spi_drv_probe) from [<c037faa0>] (driver_probe_device+0x1a0/0x444)
[    1.527478] [<c037faa0>] (driver_probe_device) from [<c037fec8>] (__device_attach_driver+0x94/0xa0)
[    1.536507] [<c037fec8>] (__device_attach_driver) from [<c037db3c>] (bus_for_each_drv+0x94/0xa4)
[    1.545277] [<c037db3c>] (bus_for_each_drv) from [<c037f7e4>] (__device_attach+0xa4/0x144)
[    1.553526] [<c037f7e4>] (__device_attach) from [<c0380058>] (device_initial_probe+0x1c/0x20)
[    1.562035] [<c0380058>] (device_initial_probe) from [<c037ec88>] (bus_probe_device+0x38/0x94)
[    1.570631] [<c037ec88>] (bus_probe_device) from [<c037ccf4>] (device_add+0x430/0x558)
[    1.578534] [<c037ccf4>] (device_add) from [<c03d0240>] (spi_add_device+0xe4/0x174)
(Continue reading)

Joakim Tjernlund | 2 Sep 17:31 2015
Picon

JFFS2 shared readonly mmap not supported?

Tried to used perf on JFFS2 and it fails because of shared readonly mmap:
  ptr = mmap(NULL, size, PROT_READ, MAP_SHARED,0, fd);

(errno says EINVAL here)

I wonder in not this combo should work?
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Ricard Wanderlof | 2 Sep 12:00 2015
Picon

[PATCH] nand: evatronix_nand: Support for Evatronix NANDFLASH-CTRL NAND flash controller


Add support for the Evatronix NANDFLASH-CTRL NAND flash controller

The Evatronix NANDFLASH-CTRL is a NAND flash controller IP, which is 
available in various configurations. The IP takes care of virtually all of 
the low-level flash chip communication so that the driver doesn't have to 
worry about it, on the other hand, specific NAND flash chip support can be 
limited by the IP configuration.

This driver supports the following IP configuration: 1 flash chip per 
bank, 2 banks. 8-bit parallel flash interface. No support for synchronous 
NAND chips or ToggleMode or ClearNAND chips. Hardware BCH error correction 
with a correction capability of 4, 8, 16, 24 or 32 bits per 256, 512 or 
1024 bytes ECC block.

The driver supports flash chips with 4 or 5 byte addressing, but not 
small-page (512 byte) flash chips.

Tested in both a software as well as hardware (RTL level) simulated
environment, but not tested on real silicon as yet.

Signed-off-by Ricard Wanderlof <ricardw <at> axis.com>
---
 .../devicetree/bindings/mtd/evatronix-nand.txt     |   41 +
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 drivers/mtd/nand/Kconfig                           |    6 +
 drivers/mtd/nand/Makefile                          |    1 +
 drivers/mtd/nand/evatronix_nand.c                  | 1874 ++++++++++++++++++++
 5 files changed, 1923 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/evatronix-nand.txt
(Continue reading)

Stefan Roese | 2 Sep 11:53 2015
Picon
Picon

[PATCH] mtd: nand: fsmc: 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:

	nand-ecc-mode = "soft_bch";

Tested on a custom SPEAr600 board.

Signed-off-by: Stefan Roese <sr <at> denx.de>
Cc: Linus Walleij <linus.walleij <at> linaro.org>
Cc: Viresh Kumar <viresh.kumar <at> linaro.org>
Cc: Brian Norris <computersforpeace <at> gmail.com>
---
 drivers/mtd/nand/fsmc_nand.c | 72 ++++++++++++++++++++++++++++++++------------
 include/linux/mtd/fsmc.h     |  2 ++
 2 files changed, 54 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index 793872f..3e01288 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
 <at>  <at>  -29,9 +29,11  <at>  <at> 
 #include <linux/types.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/nand.h>
+#include <linux/mtd/nand_bch.h>
 #include <linux/mtd/nand_ecc.h>
(Continue reading)

Brian Norris | 1 Sep 21:57 2015
Picon

[PATCH 00/10] mtd: spi-nor: cleanups + block protection support updates

[Note: as this is sent out during the merge window, it's based on the
semi-unofficial l2-mtd.git/next branch, which is targeting 4.4, not 4.3]

Hi all,

I've been reviewing various spi-nor drivers as well as working with some
Winbond flash to support new locking features. The former helped point out a
few more things that could use some improvement, and the latter suggested that
we have some glaring oversights in the spi-nor lock/unlock code.

<side note>
Some helpful companion code, for mtd-utils:

 http://lists.infradead.org/pipermail/linux-mtd/2015-August/061526.html

This extends the flash_lock tool so that you can more easily test specific
ranges, using:

  # flash_lock --lock /dev/mtdX <offset> <block-count>
  # flash_lock --unlock /dev/mtdX <offset> <block-count>
  # flash_lock --islocked /dev/mtdX <offset> <block-count>
</side note>

The first half of this series is fairly self-explanatory. The second might take
a bit of thought, as a formulaic approach is a little more subtle than a
table-based approach, so I tried to copy the relevant portions distilled from a
few datasheets and include comments. Please shout if anything deserves more
explanation or looks funny to you.

Highlights:
(Continue reading)

Brian Norris | 1 Sep 00:34 2015
Picon

[PATCH mtd-utils 00/11] flash_{un,}lock upgrades

Hi,

I've done a bit of work to make the flash_lock tool more useful, in order to
help test some new SPI NOR block protection features. Of note:

 * added getopt support
 * further unified flash_unlock and flash_lock -- the only difference now is
   their default feature, and both binaries contain support for all features
 * add support for MEMISLOCKED, so we can query arbitrary regions for
   protection status
 * mtdinfo -M already can dump some block lock information, but you get a
   little more flexibility using flash_lock --info, so both seem worth having
   IMO

Unsolved issues:

 * the MEM{LOCK,UNLOCK,ISLOCKED} ioctls all still use the out-dated 32-bit
   erase_info_user struct, which means they'll have problems supporting >=4GB
   flash. This isn't a mtd-utils problem, per se, and at the moment, Linux NAND
   (the only (?) candidate for >=4GB flash) support doesn't implement any of
   the locking APIs. But just an observation I ran across.
 * Deprecation plan: it would make sense to deprecate and remove flash_unlock
   eventually (in favor of 'flash_lock --unlock'), but this isn't really
   pressing, so I don't see a good reason to spend much effort on it.

Enjoy,
Brian

Brian Norris (11):
  flash_{un,}lock: nest optional parameters in help message
(Continue reading)

Brian Norris | 28 Aug 18:05 2015
Picon

[PATCH mtd-utils] don't include system headers in dependency files

System library headers are not strictly part of our build. If they are
changing beneath our feet, then we probably have bigger problems.

Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
Suggested-by: Mike Frysinger <vapier <at> gentoo.org>
---
 common.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common.mk b/common.mk
index 7c09ab0a46d0..6bfe8de85953 100644
--- a/common.mk
+++ b/common.mk
 <at>  <at>  -80,7 +80,7  <at>  <at>  ifneq ($(BUILDDIR),$(CURDIR))
 	$(Q)mkdir -p $(dir $ <at> )
 endif
 	$(call BECHO,CC)
-	$(Q)$(CC) $(CPPFLAGS) $(CFLAGS) -c -o $ <at>  $< -g -MD -MF $(BUILDDIR)/.$(<F).dep
+	$(Q)$(CC) $(CPPFLAGS) $(CFLAGS) -c -o $ <at>  $< -g -MMD -MF $(BUILDDIR)/.$(<F).dep

 .SUFFIXES:

--

-- 
2.5.0.457.gab17608

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

(Continue reading)


Gmane