Rafał Miłecki | 25 Apr 12:41 2015
Picon

[PATCH] mtd: spi-nor: Properly set SECT_4K for recently added flashes

Few recently added entries are missing SECT_4K flag despite of these
flashes supporting 4 KiB erase sectors and 0x20 erase command.
Also add a comment to help avoiding such mistakes in the future.

Signed-off-by: Rafał Miłecki <zajec5 <at> gmail.com>
Cc: Knut Wohlrab <knut.wohlrab <at> de.bosch.com>
Cc: Huang Shijie <shijie.huang <at> intel.com>
Cc: Shengzhou Liu <shengzhou.liu <at> freescale.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index cd173e5..7a6a373 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
 <at>  <at>  -513,6 +513,13  <at>  <at>  static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
 /* NOTE: double check command sets and memory organization when you add
  * more nor chips.  This current list focusses on newer chips, which
  * have been converging on command sets which including JEDEC ID.
+ *
+ * All newly added entries should describe *hardware* and should use SECT_4K
+ * (or SECT_4K_PMC) if hardware supports erasing 4 KiB sectors. For usage
+ * scenarios excluding small sectors there is config option that can be
+ * disabled: CONFIG_MTD_SPI_NOR_USE_4K_SECTORS.
+ * For historical (and compatibility) reasons (before we got above config) some
+ * old entries may be missing 4K flag.
  */
 static const struct spi_device_id spi_nor_ids[] = {
 	/* Atmel -- some are (confusingly) marketed as "DataFlash" */
(Continue reading)

Rafał Miłecki | 25 Apr 12:01 2015
Picon

[PATCH] mtd: spi-nor: Add support for Spansion S25FL164K

It's an 8 MiB flash with 4 KiB erase sectors.

Signed-off-by: Rafał Miłecki <zajec5 <at> gmail.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 14a5d23..cd173e5 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
 <at>  <at>  -614,6 +614,7  <at>  <at>  static const struct spi_device_id spi_nor_ids[] = {
 	{ "s25fl016k",  INFO(0xef4015,      0,  64 * 1024,  32, SECT_4K) },
 	{ "s25fl064k",  INFO(0xef4017,      0,  64 * 1024, 128, SECT_4K) },
 	{ "s25fl132k",  INFO(0x014016,      0,  64 * 1024,  64, 0) },
+	{ "s25fl164k",  INFO(0x014017,      0,  64 * 1024, 128, SECT_4K) },

 	/* SST -- large erase sizes are "overlays", "sectors" are 4K */
 	{ "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K | SST_WRITE) },
--

-- 
1.8.4.5

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Jörg Krause | 24 Apr 22:51 2015

[PATCH 1/2] serve_image: do not include error.h

serve_image does not use anything from it and it is not available with all
C libraries, e.g. musl.

Signed-off-by: Jörg Krause <joerg.krause <at> embedded.rocks>
---
 serve_image.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/serve_image.c b/serve_image.c
index 38549a1..4f0e946 100644
--- a/serve_image.c
+++ b/serve_image.c
 <at>  <at>  -3,7 +3,6  <at>  <at> 

 #include <time.h>
 #include <errno.h>
-#include <error.h>
 #include <netdb.h>
 #include <stdio.h>
 #include <stdlib.h>
--

-- 
2.3.6

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Ricard Wanderlof | 24 Apr 15:08 2015
Picon

process prioritization and mtd access


I have a question related to process prioritization and mtd access. 
Prioritization and scheduling are not areas which I'm too familiar with 
so I'm not too sure exactly how to phrase this.  

Say we have two processes running at different priorities, with their 
respective binaries in a filesystem residing on an mtd device.

Now, assuming that the processes binaries have been loaded into memory, we 
see that process prioritization works as expected. However, while the 
system is paging data in from the respective binaries in the flash, both 
processes seem to get the same priority. This means that the low priority 
process tends to block the high priority process, which is not what we 
want.

There is an I/O prioritization mechanism for block devices, but mtd 
devices are not block devices so it can't be used. I don't know if it 
would apply in this case anyway.

Is there some form of mechanism to handle this on a file system level?

I can't recall seeing anything about this down at the mtd layer, at least 
not in the NAND parts which I'm the most familiar with.

Anyone have any pointers?

/Ricard
--

-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
(Continue reading)

Haikun Wang | 24 Apr 12:27 2015

[PATCH 2/2 v1] mtd: spi-nor: fsl-quadspi: Enable support big endian registers

Check endianness before accessing register and swap the data if QSPI
register is big endian.

Signed-off-by: Haikun Wang <haikun.wang <at> freescale.com>
---
 drivers/mtd/spi-nor/fsl-quadspi.c | 137 ++++++++++++++++++++++----------------
 1 file changed, 80 insertions(+), 57 deletions(-)

diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index 1742de9..15c7252 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
 <at>  <at>  -191,6 +191,8  <at>  <at> 
 #define SEQID_EN4B		10
 #define SEQID_BRWR		11

+#define FSL_QSPI_FLAG_REGMAP_BE	(1 << 0)
+
 enum fsl_qspi_devtype {
 	FSL_QUADSPI_VYBRID,
 	FSL_QUADSPI_IMX6SX,
 <at>  <at>  -202,6 +204,7  <at>  <at>  struct fsl_qspi_devtype_data {
 	int rxfifo;
 	int txfifo;
 	int ahb_buf_size;
+	u32 flags;
 };

 static struct fsl_qspi_devtype_data vybrid_data = {
 <at>  <at>  -222,6 +225,7  <at>  <at>  static struct fsl_qspi_devtype_data ls1_data = {
(Continue reading)

Haikun Wang | 24 Apr 12:26 2015

[PATCH 1/2 v1] mtd: spi-nor: fsl-quadspi: Enable LS1021 support

Add LS1021 QSPI chip special information

Signed-off-by: Haikun Wang <haikun.wang <at> freescale.com>
---
 drivers/mtd/spi-nor/fsl-quadspi.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index 5d5d362..1742de9 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
 <at>  <at>  -194,6 +194,7  <at>  <at> 
 enum fsl_qspi_devtype {
 	FSL_QUADSPI_VYBRID,
 	FSL_QUADSPI_IMX6SX,
+	FSL_QUADSPI_LS1,
 };

 struct fsl_qspi_devtype_data {
 <at>  <at>  -217,6 +218,12  <at>  <at>  static struct fsl_qspi_devtype_data imx6sx_data = {
 	.ahb_buf_size = 1024
 };

+static struct fsl_qspi_devtype_data ls1_data = {
+	.devtype = FSL_QUADSPI_LS1,
+	.rxfifo = 128,
+	.txfifo = 64;
+};
+
 #define FSL_QSPI_MAX_CHIP	4
(Continue reading)

Jörg Krause | 24 Apr 00:12 2015

[PATCH 1/3] include/common.h: fix build against musl

Like uClibc version older than (not yet released) 0.9.34 musl does not have
a rpmatch() implementation.

uClibc defines both __UCLIBC__ and __GLIBC__. So first check for uCibc and its
version and then for a non glibc implementation (like musl). Note, musl does
not define __MUSL__.

Signed-off-by: Jörg Krause <joerg.krause <at> embedded.rocks>
---
 include/common.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/common.h b/include/common.h
index 9b8804a..fb0ca83 100644
--- a/include/common.h
+++ b/include/common.h
 <at>  <at>  -117,11 +117,12  <at>  <at>  extern "C" {
 	fprintf(stderr, "%s: warning!: " fmt "\n", PROGRAM_NAME, ##__VA_ARGS__); \
 } while(0)

-#if defined(__UCLIBC__)
-/* uClibc versions before 0.9.34 don't have rpmatch() */
-#if __UCLIBC_MAJOR__ == 0 && \
+/* uClibc versions before 0.9.34 and musl don't have rpmatch() */
+#if defined(__UCLIBC__) && \
+		(__UCLIBC_MAJOR__ == 0 && \
 		(__UCLIBC_MINOR__ < 9 || \
-		(__UCLIBC_MINOR__ == 9 && __UCLIBC_SUBLEVEL__ < 34))
+		(__UCLIBC_MINOR__ == 9 && __UCLIBC_SUBLEVEL__ < 34))) || \
+	!defined(__GLIBC__)
(Continue reading)

Miss Noleta | 23 Apr 16:48 2015
Picon

HELLO


Hi,
Happy New Day,
Am Miss Noleta Voss, I will so much appreciate your kind reply
for i have some thing very important to talk with you...
kindly reply me

                     Yours Noleta Voss

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

Han Xu | 23 Apr 07:45 2015
Picon

What is the status of these patches

Hi Brain,

I was wondering what is the status of these fsl qspi patches? Thanks.

http://patchwork.ozlabs.org/patch/343237/

http://patchwork.ozlabs.org/patch/343235/

http://patchwork.ozlabs.org/patch/343229/

http://patchwork.ozlabs.org/patch/343238/

http://patchwork.ozlabs.org/patch/343231/

http://patchwork.ozlabs.org/patch/343239/

http://patchwork.ozlabs.org/patch/343232/

http://patchwork.ozlabs.org/patch/343234/

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

Ronald Wahl | 22 Apr 14:37 2015

[RFC][PATCH] mtd: cfi_cmdset_0001.c: Take lock when determining block lock status.

Determining block lock status modifies chip status without taking lock.
This can lead to hanging flash operations

Signed-off-by: Ronald Wahl <ronald.wahl <at> raritan.com>
---

Not sure is this patch is efficient in the suspend/resume path since the lock
is then taken and released for every flash block. This is also the reason why
I split out a separate do_getlockstatus_oneblock_unlocked() routine. Maybe we
need to take the lock separately in the suspend/resume path and then call this
_unlocked variant for each flash block.

In my own use case I do not use suspend resume so I just ignored this. So the
question is: Is the patch usable in it's current form respective what needs to
change.

 drivers/mtd/chips/cfi_cmdset_0001.c | 29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index 286b97a..cad687f 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
 <at>  <at>  -2044,10 +2044,10  <at>  <at>  static void cfi_intelext_sync (struct mtd_info *mtd)
 	}
 }

-static int __xipram do_getlockstatus_oneblock(struct map_info *map,
-						struct flchip *chip,
-						unsigned long adr,
(Continue reading)

Ezequiel Garcia | 22 Apr 14:30 2015
Ezequiel Garcia <ezequiel.garcia <at> imgtec.com>

Subject: [PATCH] UBI: block: Add missing cache flushes

[PATCH] UBI: block: Add missing cache flushes

From: Kevin Cernekee <cernekee <at> chromium.org>

Block drivers are responsible for calling flush_dcache_page() on each
BIO request. This operation keeps the I$ coherent with the D$ on
architectures that don't have hardware coherency support. Without this
flush, random crashes are seen when executing user programs from an ext4
filesystem backed by a ubiblock device.

This patch is based on the change implemented in commit 2d4dc890b5c8
("block: add helpers to run flush_dcache_page() against a bio and a
request's pages").

Fixes: 9d54c8a33eec ("UBI: R/O block driver on top of UBI volumes")
Signed-off-by: Kevin Cernekee <cernekee <at> chromium.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia <at> imgtec.com>
---
 drivers/mtd/ubi/block.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
index db2c05b..c9eb78f 100644
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
 <at>  <at>  -310,6 +310,8  <at>  <at>  static void ubiblock_do_work(struct work_struct *work)
 	blk_rq_map_sg(req->q, req, pdu->usgl.sg);

 	ret = ubiblock_read(pdu);
+	rq_flush_dcache_pages(req);
+
 	blk_mq_end_request(req, ret);
(Continue reading)


Gmane