* [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-09-14 17:10 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:10 UTC (permalink / raw)
To: Brian Norris
Cc: Geert Uytterhoeven, Andrew Lunn, Jason Cooper, linux-spi,
Huang Shijie, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
The first patch in the series restores the module aliases to m25p80, but
it does so by duplicating the list of names. This should be suitable
for stable, but it isn't viable in the longer term.
The following patches change the spi-nor interface so that this
duplication is no longer necessary. This includes removing
spi_nor::read_id, but it could be re-added after this with a different
interface, e.g. returning a flash_info structure (which would need to be
defined in spi_nor.h).
Ben.
Ben Hutchings (5):
m25p80,spi-nor: Fix module aliases for m25p80
spi-nor: Remove spi_nor::read_id operation
spi-nor: Make spi_nor_scan() take a chip type name, not an
spi_device_id
spi-nor: Replace struct spi_device_id with struct flash_info
m25p80,spi-nor: Share the list of supported chip type names again
drivers/mtd/devices/m25p80.c | 13 +-
drivers/mtd/spi-nor/fsl-quadspi.c | 7 +-
drivers/mtd/spi-nor/spi-nor.c | 383 +++++++++++++++++++-------------------
include/linux/mtd/spi-nor.h | 87 +++++++--
4 files changed, 279 insertions(+), 211 deletions(-)
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-09-14 17:10 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:10 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Geert Uytterhoeven, Huang Shijie, linux-arm-kernel,
debian-kernel
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
The first patch in the series restores the module aliases to m25p80, but
it does so by duplicating the list of names. This should be suitable
for stable, but it isn't viable in the longer term.
The following patches change the spi-nor interface so that this
duplication is no longer necessary. This includes removing
spi_nor::read_id, but it could be re-added after this with a different
interface, e.g. returning a flash_info structure (which would need to be
defined in spi_nor.h).
Ben.
Ben Hutchings (5):
m25p80,spi-nor: Fix module aliases for m25p80
spi-nor: Remove spi_nor::read_id operation
spi-nor: Make spi_nor_scan() take a chip type name, not an
spi_device_id
spi-nor: Replace struct spi_device_id with struct flash_info
m25p80,spi-nor: Share the list of supported chip type names again
drivers/mtd/devices/m25p80.c | 13 +-
drivers/mtd/spi-nor/fsl-quadspi.c | 7 +-
drivers/mtd/spi-nor/spi-nor.c | 383 +++++++++++++++++++-------------------
include/linux/mtd/spi-nor.h | 87 +++++++--
4 files changed, 279 insertions(+), 211 deletions(-)
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-09-14 17:10 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:10 UTC (permalink / raw)
To: linux-arm-kernel
The first patch in the series restores the module aliases to m25p80, but
it does so by duplicating the list of names. This should be suitable
for stable, but it isn't viable in the longer term.
The following patches change the spi-nor interface so that this
duplication is no longer necessary. This includes removing
spi_nor::read_id, but it could be re-added after this with a different
interface, e.g. returning a flash_info structure (which would need to be
defined in spi_nor.h).
Ben.
Ben Hutchings (5):
m25p80,spi-nor: Fix module aliases for m25p80
spi-nor: Remove spi_nor::read_id operation
spi-nor: Make spi_nor_scan() take a chip type name, not an
spi_device_id
spi-nor: Replace struct spi_device_id with struct flash_info
m25p80,spi-nor: Share the list of supported chip type names again
drivers/mtd/devices/m25p80.c | 13 +-
drivers/mtd/spi-nor/fsl-quadspi.c | 7 +-
drivers/mtd/spi-nor/spi-nor.c | 383 +++++++++++++++++++-------------------
include/linux/mtd/spi-nor.h | 87 +++++++--
4 files changed, 279 insertions(+), 211 deletions(-)
--
Ben Hutchings
The world is coming to an end. Please log off.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140914/e8d08292/attachment.sig>
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
2014-09-14 17:10 ` Ben Hutchings
(?)
@ 2014-09-14 17:11 ` Ben Hutchings
-1 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: Brian Norris
Cc: Geert Uytterhoeven, Andrew Lunn, Jason Cooper, linux-spi,
Huang Shijie, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 6476 bytes --]
m25p80's device ID table is now spi_nor_ids, defined in spi-nor. The
MODULE_DEVICE_TABLE() macro doesn't work with extern definitions, but
its use was also removed at the same time. Now if m25p80 is built as
a module it doesn't get the necessary aliases to be loaded
automatically.
A clean solution to this will involve defining the list of device
IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
API, but this is quite a large change.
As a quick fix suitable for stable, copy the device IDs back into
m25p80.
Fixes: 03e296f613af ("mtd: m25p80: use the SPI nor framework")
Cc: stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # 3.16
Signed-off-by: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
---
drivers/mtd/devices/m25p80.c | 58 +++++++++++++++++++++++++++++++++++++++++--
drivers/mtd/spi-nor/spi-nor.c | 5 ++--
include/linux/mtd/spi-nor.h | 3 +--
3 files changed, 59 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index ed7e0a1b..3f0fe86 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -196,6 +196,7 @@ static int m25p_probe(struct spi_device *spi)
struct m25p *flash;
struct spi_nor *nor;
enum read_mode mode = SPI_NOR_NORMAL;
+ const struct spi_device_id *id;
int ret;
flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
@@ -223,7 +224,10 @@ static int m25p_probe(struct spi_device *spi)
mode = SPI_NOR_QUAD;
else if (spi->mode & SPI_RX_DUAL)
mode = SPI_NOR_DUAL;
- ret = spi_nor_scan(nor, spi_get_device_id(spi), mode);
+ id = spi_nor_match_id(spi_get_device_id(spi)->name);
+ if (WARN_ON(!id))
+ return -ENODEV;
+ ret = spi_nor_scan(nor, id, mode);
if (ret)
return ret;
@@ -245,12 +249,62 @@ static int m25p_remove(struct spi_device *spi)
}
+/*
+ * XXX This needs to be kept in sync with spi_nor_ids. We can't share
+ * it with spi-nor, because if this is built as a module then modpost
+ * won't be able to read it and add appropriate aliases.
+ */
+static const struct spi_device_id m25p_ids[] = {
+ {"at25fs010"}, {"at25fs040"}, {"at25df041a"}, {"at25df321a"},
+ {"at25df641"}, {"at26f004"}, {"at26df081a"}, {"at26df161a"},
+ {"at26df321"}, {"at45db081d"},
+ {"en25f32"}, {"en25p32"}, {"en25q32b"}, {"en25p64"},
+ {"en25q64"}, {"en25qh128"}, {"en25qh256"},
+ {"f25l32pa"},
+ {"mr25h256"}, {"mr25h10"},
+ {"gd25q32"}, {"gd25q64"},
+ {"160s33b"}, {"320s33b"}, {"640s33b"},
+ {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"}, {"mx25l1606e"},
+ {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
+ {"mx25l12855e"},{"mx25l25635e"},{"mx25l25655e"},{"mx66l51235l"},
+ {"mx66l1g55g"},
+ {"n25q064"}, {"n25q128a11"}, {"n25q128a13"}, {"n25q256a"},
+ {"n25q512a"}, {"n25q512ax3"}, {"n25q00"},
+ {"pm25lv512"}, {"pm25lv010"}, {"pm25lq032"},
+ {"s25sl032p"}, {"s25sl064p"}, {"s25fl256s0"}, {"s25fl256s1"},
+ {"s25fl512s"}, {"s70fl01gs"}, {"s25sl12800"}, {"s25sl12801"},
+ {"s25fl129p0"}, {"s25fl129p1"}, {"s25sl004a"}, {"s25sl008a"},
+ {"s25sl016a"}, {"s25sl032a"}, {"s25sl064a"}, {"s25fl008k"},
+ {"s25fl016k"}, {"s25fl064k"},
+ {"sst25vf040b"},{"sst25vf080b"},{"sst25vf016b"},{"sst25vf032b"},
+ {"sst25vf064c"},{"sst25wf512"}, {"sst25wf010"}, {"sst25wf020"},
+ {"sst25wf040"},
+ {"m25p05"}, {"m25p10"}, {"m25p20"}, {"m25p40"},
+ {"m25p80"}, {"m25p16"}, {"m25p32"}, {"m25p64"},
+ {"m25p128"}, {"n25q032"},
+ {"m25p05-nonjedec"}, {"m25p10-nonjedec"}, {"m25p20-nonjedec"},
+ {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
+ {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
+ {"m45pe10"}, {"m45pe80"}, {"m45pe16"},
+ {"m25pe20"}, {"m25pe80"}, {"m25pe16"},
+ {"m25px16"}, {"m25px32"}, {"m25px32-s0"}, {"m25px32-s1"},
+ {"m25px64"},
+ {"w25x10"}, {"w25x20"}, {"w25x40"}, {"w25x80"},
+ {"w25x16"}, {"w25x32"}, {"w25q32"}, {"w25q32dw"},
+ {"w25x64"}, {"w25q64"}, {"w25q128"}, {"w25q80"},
+ {"w25q80bl"}, {"w25q128"}, {"w25q256"}, {"cat25c11"},
+ {"cat25c03"}, {"cat25c09"}, {"cat25c17"}, {"cat25128"},
+ { },
+};
+MODULE_DEVICE_TABLE(spi, m25p_ids);
+
+
static struct spi_driver m25p80_driver = {
.driver = {
.name = "m25p80",
.owner = THIS_MODULE,
},
- .id_table = spi_nor_ids,
+ .id_table = m25p_ids,
.probe = m25p_probe,
.remove = m25p_remove,
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 03e0ab8..6b1bda2 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -473,7 +473,7 @@ struct flash_info {
* more nor chips. This current list focusses on newer chips, which
* have been converging on command sets which including JEDEC ID.
*/
-const struct spi_device_id spi_nor_ids[] = {
+static const struct spi_device_id spi_nor_ids[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
{ "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
{ "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
@@ -637,7 +637,6 @@ const struct spi_device_id spi_nor_ids[] = {
{ "cat25128", CAT25_INFO(2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
{ },
};
-EXPORT_SYMBOL_GPL(spi_nor_ids);
static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
{
@@ -1136,7 +1135,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
}
EXPORT_SYMBOL_GPL(spi_nor_scan);
-const struct spi_device_id *spi_nor_match_id(char *name)
+const struct spi_device_id *spi_nor_match_id(const char *name)
{
const struct spi_device_id *id = spi_nor_ids;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 9e6294f..5ec84cc 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -201,7 +201,6 @@ struct spi_nor {
*/
int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
enum read_mode mode);
-extern const struct spi_device_id spi_nor_ids[];
/**
* spi_nor_match_id() - find the spi_device_id by the name
@@ -213,6 +212,6 @@ extern const struct spi_device_id spi_nor_ids[];
* Return: returns the right spi_device_id pointer on success,
* and returns NULL on failure.
*/
-const struct spi_device_id *spi_nor_match_id(char *name);
+const struct spi_device_id *spi_nor_match_id(const char *name);
#endif
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-14 17:11 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Geert Uytterhoeven, Huang Shijie, linux-arm-kernel,
debian-kernel
[-- Attachment #1: Type: text/plain, Size: 6428 bytes --]
m25p80's device ID table is now spi_nor_ids, defined in spi-nor. The
MODULE_DEVICE_TABLE() macro doesn't work with extern definitions, but
its use was also removed at the same time. Now if m25p80 is built as
a module it doesn't get the necessary aliases to be loaded
automatically.
A clean solution to this will involve defining the list of device
IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
API, but this is quite a large change.
As a quick fix suitable for stable, copy the device IDs back into
m25p80.
Fixes: 03e296f613af ("mtd: m25p80: use the SPI nor framework")
Cc: stable <stable@vger.kernel.org> # 3.16
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/mtd/devices/m25p80.c | 58 +++++++++++++++++++++++++++++++++++++++++--
drivers/mtd/spi-nor/spi-nor.c | 5 ++--
include/linux/mtd/spi-nor.h | 3 +--
3 files changed, 59 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index ed7e0a1b..3f0fe86 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -196,6 +196,7 @@ static int m25p_probe(struct spi_device *spi)
struct m25p *flash;
struct spi_nor *nor;
enum read_mode mode = SPI_NOR_NORMAL;
+ const struct spi_device_id *id;
int ret;
flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
@@ -223,7 +224,10 @@ static int m25p_probe(struct spi_device *spi)
mode = SPI_NOR_QUAD;
else if (spi->mode & SPI_RX_DUAL)
mode = SPI_NOR_DUAL;
- ret = spi_nor_scan(nor, spi_get_device_id(spi), mode);
+ id = spi_nor_match_id(spi_get_device_id(spi)->name);
+ if (WARN_ON(!id))
+ return -ENODEV;
+ ret = spi_nor_scan(nor, id, mode);
if (ret)
return ret;
@@ -245,12 +249,62 @@ static int m25p_remove(struct spi_device *spi)
}
+/*
+ * XXX This needs to be kept in sync with spi_nor_ids. We can't share
+ * it with spi-nor, because if this is built as a module then modpost
+ * won't be able to read it and add appropriate aliases.
+ */
+static const struct spi_device_id m25p_ids[] = {
+ {"at25fs010"}, {"at25fs040"}, {"at25df041a"}, {"at25df321a"},
+ {"at25df641"}, {"at26f004"}, {"at26df081a"}, {"at26df161a"},
+ {"at26df321"}, {"at45db081d"},
+ {"en25f32"}, {"en25p32"}, {"en25q32b"}, {"en25p64"},
+ {"en25q64"}, {"en25qh128"}, {"en25qh256"},
+ {"f25l32pa"},
+ {"mr25h256"}, {"mr25h10"},
+ {"gd25q32"}, {"gd25q64"},
+ {"160s33b"}, {"320s33b"}, {"640s33b"},
+ {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"}, {"mx25l1606e"},
+ {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
+ {"mx25l12855e"},{"mx25l25635e"},{"mx25l25655e"},{"mx66l51235l"},
+ {"mx66l1g55g"},
+ {"n25q064"}, {"n25q128a11"}, {"n25q128a13"}, {"n25q256a"},
+ {"n25q512a"}, {"n25q512ax3"}, {"n25q00"},
+ {"pm25lv512"}, {"pm25lv010"}, {"pm25lq032"},
+ {"s25sl032p"}, {"s25sl064p"}, {"s25fl256s0"}, {"s25fl256s1"},
+ {"s25fl512s"}, {"s70fl01gs"}, {"s25sl12800"}, {"s25sl12801"},
+ {"s25fl129p0"}, {"s25fl129p1"}, {"s25sl004a"}, {"s25sl008a"},
+ {"s25sl016a"}, {"s25sl032a"}, {"s25sl064a"}, {"s25fl008k"},
+ {"s25fl016k"}, {"s25fl064k"},
+ {"sst25vf040b"},{"sst25vf080b"},{"sst25vf016b"},{"sst25vf032b"},
+ {"sst25vf064c"},{"sst25wf512"}, {"sst25wf010"}, {"sst25wf020"},
+ {"sst25wf040"},
+ {"m25p05"}, {"m25p10"}, {"m25p20"}, {"m25p40"},
+ {"m25p80"}, {"m25p16"}, {"m25p32"}, {"m25p64"},
+ {"m25p128"}, {"n25q032"},
+ {"m25p05-nonjedec"}, {"m25p10-nonjedec"}, {"m25p20-nonjedec"},
+ {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
+ {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
+ {"m45pe10"}, {"m45pe80"}, {"m45pe16"},
+ {"m25pe20"}, {"m25pe80"}, {"m25pe16"},
+ {"m25px16"}, {"m25px32"}, {"m25px32-s0"}, {"m25px32-s1"},
+ {"m25px64"},
+ {"w25x10"}, {"w25x20"}, {"w25x40"}, {"w25x80"},
+ {"w25x16"}, {"w25x32"}, {"w25q32"}, {"w25q32dw"},
+ {"w25x64"}, {"w25q64"}, {"w25q128"}, {"w25q80"},
+ {"w25q80bl"}, {"w25q128"}, {"w25q256"}, {"cat25c11"},
+ {"cat25c03"}, {"cat25c09"}, {"cat25c17"}, {"cat25128"},
+ { },
+};
+MODULE_DEVICE_TABLE(spi, m25p_ids);
+
+
static struct spi_driver m25p80_driver = {
.driver = {
.name = "m25p80",
.owner = THIS_MODULE,
},
- .id_table = spi_nor_ids,
+ .id_table = m25p_ids,
.probe = m25p_probe,
.remove = m25p_remove,
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 03e0ab8..6b1bda2 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -473,7 +473,7 @@ struct flash_info {
* more nor chips. This current list focusses on newer chips, which
* have been converging on command sets which including JEDEC ID.
*/
-const struct spi_device_id spi_nor_ids[] = {
+static const struct spi_device_id spi_nor_ids[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
{ "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
{ "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
@@ -637,7 +637,6 @@ const struct spi_device_id spi_nor_ids[] = {
{ "cat25128", CAT25_INFO(2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
{ },
};
-EXPORT_SYMBOL_GPL(spi_nor_ids);
static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
{
@@ -1136,7 +1135,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
}
EXPORT_SYMBOL_GPL(spi_nor_scan);
-const struct spi_device_id *spi_nor_match_id(char *name)
+const struct spi_device_id *spi_nor_match_id(const char *name)
{
const struct spi_device_id *id = spi_nor_ids;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 9e6294f..5ec84cc 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -201,7 +201,6 @@ struct spi_nor {
*/
int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
enum read_mode mode);
-extern const struct spi_device_id spi_nor_ids[];
/**
* spi_nor_match_id() - find the spi_device_id by the name
@@ -213,6 +212,6 @@ extern const struct spi_device_id spi_nor_ids[];
* Return: returns the right spi_device_id pointer on success,
* and returns NULL on failure.
*/
-const struct spi_device_id *spi_nor_match_id(char *name);
+const struct spi_device_id *spi_nor_match_id(const char *name);
#endif
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-14 17:11 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: linux-arm-kernel
m25p80's device ID table is now spi_nor_ids, defined in spi-nor. The
MODULE_DEVICE_TABLE() macro doesn't work with extern definitions, but
its use was also removed at the same time. Now if m25p80 is built as
a module it doesn't get the necessary aliases to be loaded
automatically.
A clean solution to this will involve defining the list of device
IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
API, but this is quite a large change.
As a quick fix suitable for stable, copy the device IDs back into
m25p80.
Fixes: 03e296f613af ("mtd: m25p80: use the SPI nor framework")
Cc: stable <stable@vger.kernel.org> # 3.16
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/mtd/devices/m25p80.c | 58 +++++++++++++++++++++++++++++++++++++++++--
drivers/mtd/spi-nor/spi-nor.c | 5 ++--
include/linux/mtd/spi-nor.h | 3 +--
3 files changed, 59 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index ed7e0a1b..3f0fe86 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -196,6 +196,7 @@ static int m25p_probe(struct spi_device *spi)
struct m25p *flash;
struct spi_nor *nor;
enum read_mode mode = SPI_NOR_NORMAL;
+ const struct spi_device_id *id;
int ret;
flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
@@ -223,7 +224,10 @@ static int m25p_probe(struct spi_device *spi)
mode = SPI_NOR_QUAD;
else if (spi->mode & SPI_RX_DUAL)
mode = SPI_NOR_DUAL;
- ret = spi_nor_scan(nor, spi_get_device_id(spi), mode);
+ id = spi_nor_match_id(spi_get_device_id(spi)->name);
+ if (WARN_ON(!id))
+ return -ENODEV;
+ ret = spi_nor_scan(nor, id, mode);
if (ret)
return ret;
@@ -245,12 +249,62 @@ static int m25p_remove(struct spi_device *spi)
}
+/*
+ * XXX This needs to be kept in sync with spi_nor_ids. We can't share
+ * it with spi-nor, because if this is built as a module then modpost
+ * won't be able to read it and add appropriate aliases.
+ */
+static const struct spi_device_id m25p_ids[] = {
+ {"at25fs010"}, {"at25fs040"}, {"at25df041a"}, {"at25df321a"},
+ {"at25df641"}, {"at26f004"}, {"at26df081a"}, {"at26df161a"},
+ {"at26df321"}, {"at45db081d"},
+ {"en25f32"}, {"en25p32"}, {"en25q32b"}, {"en25p64"},
+ {"en25q64"}, {"en25qh128"}, {"en25qh256"},
+ {"f25l32pa"},
+ {"mr25h256"}, {"mr25h10"},
+ {"gd25q32"}, {"gd25q64"},
+ {"160s33b"}, {"320s33b"}, {"640s33b"},
+ {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"}, {"mx25l1606e"},
+ {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
+ {"mx25l12855e"},{"mx25l25635e"},{"mx25l25655e"},{"mx66l51235l"},
+ {"mx66l1g55g"},
+ {"n25q064"}, {"n25q128a11"}, {"n25q128a13"}, {"n25q256a"},
+ {"n25q512a"}, {"n25q512ax3"}, {"n25q00"},
+ {"pm25lv512"}, {"pm25lv010"}, {"pm25lq032"},
+ {"s25sl032p"}, {"s25sl064p"}, {"s25fl256s0"}, {"s25fl256s1"},
+ {"s25fl512s"}, {"s70fl01gs"}, {"s25sl12800"}, {"s25sl12801"},
+ {"s25fl129p0"}, {"s25fl129p1"}, {"s25sl004a"}, {"s25sl008a"},
+ {"s25sl016a"}, {"s25sl032a"}, {"s25sl064a"}, {"s25fl008k"},
+ {"s25fl016k"}, {"s25fl064k"},
+ {"sst25vf040b"},{"sst25vf080b"},{"sst25vf016b"},{"sst25vf032b"},
+ {"sst25vf064c"},{"sst25wf512"}, {"sst25wf010"}, {"sst25wf020"},
+ {"sst25wf040"},
+ {"m25p05"}, {"m25p10"}, {"m25p20"}, {"m25p40"},
+ {"m25p80"}, {"m25p16"}, {"m25p32"}, {"m25p64"},
+ {"m25p128"}, {"n25q032"},
+ {"m25p05-nonjedec"}, {"m25p10-nonjedec"}, {"m25p20-nonjedec"},
+ {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
+ {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
+ {"m45pe10"}, {"m45pe80"}, {"m45pe16"},
+ {"m25pe20"}, {"m25pe80"}, {"m25pe16"},
+ {"m25px16"}, {"m25px32"}, {"m25px32-s0"}, {"m25px32-s1"},
+ {"m25px64"},
+ {"w25x10"}, {"w25x20"}, {"w25x40"}, {"w25x80"},
+ {"w25x16"}, {"w25x32"}, {"w25q32"}, {"w25q32dw"},
+ {"w25x64"}, {"w25q64"}, {"w25q128"}, {"w25q80"},
+ {"w25q80bl"}, {"w25q128"}, {"w25q256"}, {"cat25c11"},
+ {"cat25c03"}, {"cat25c09"}, {"cat25c17"}, {"cat25128"},
+ { },
+};
+MODULE_DEVICE_TABLE(spi, m25p_ids);
+
+
static struct spi_driver m25p80_driver = {
.driver = {
.name = "m25p80",
.owner = THIS_MODULE,
},
- .id_table = spi_nor_ids,
+ .id_table = m25p_ids,
.probe = m25p_probe,
.remove = m25p_remove,
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 03e0ab8..6b1bda2 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -473,7 +473,7 @@ struct flash_info {
* more nor chips. This current list focusses on newer chips, which
* have been converging on command sets which including JEDEC ID.
*/
-const struct spi_device_id spi_nor_ids[] = {
+static const struct spi_device_id spi_nor_ids[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
{ "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
{ "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
@@ -637,7 +637,6 @@ const struct spi_device_id spi_nor_ids[] = {
{ "cat25128", CAT25_INFO(2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
{ },
};
-EXPORT_SYMBOL_GPL(spi_nor_ids);
static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
{
@@ -1136,7 +1135,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
}
EXPORT_SYMBOL_GPL(spi_nor_scan);
-const struct spi_device_id *spi_nor_match_id(char *name)
+const struct spi_device_id *spi_nor_match_id(const char *name)
{
const struct spi_device_id *id = spi_nor_ids;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 9e6294f..5ec84cc 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -201,7 +201,6 @@ struct spi_nor {
*/
int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
enum read_mode mode);
-extern const struct spi_device_id spi_nor_ids[];
/**
* spi_nor_match_id() - find the spi_device_id by the name
@@ -213,6 +212,6 @@ extern const struct spi_device_id spi_nor_ids[];
* Return: returns the right spi_device_id pointer on success,
* and returns NULL on failure.
*/
-const struct spi_device_id *spi_nor_match_id(char *name);
+const struct spi_device_id *spi_nor_match_id(const char *name);
#endif
--
Ben Hutchings
The world is coming to an end. Please log off.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140914/d6454f26/attachment.sig>
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 2/5] spi-nor: Remove spi_nor::read_id operation
2014-09-14 17:10 ` Ben Hutchings
(?)
@ 2014-09-14 17:11 ` Ben Hutchings
-1 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: Brian Norris
Cc: Geert Uytterhoeven, Andrew Lunn, Jason Cooper, linux-spi,
Huang Shijie, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 2277 bytes --]
There is currently no useful way to override the default
implementation of this operation. The returned struct spi_device_id
must have a pointer to struct flash_info in its private data, but this
structure is defined inside spi-nor.
Signed-off-by: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
---
drivers/mtd/spi-nor/spi-nor.c | 4 +---
include/linux/mtd/spi-nor.h | 3 ---
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6b1bda2..6f699c5 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -902,8 +902,6 @@ static int spi_nor_check(struct spi_nor *nor)
return -EINVAL;
}
- if (!nor->read_id)
- nor->read_id = spi_nor_read_id;
if (!nor->wait_till_ready)
nor->wait_till_ready = spi_nor_wait_till_ready;
@@ -952,7 +950,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
if (info->jedec_id) {
const struct spi_device_id *jid;
- jid = nor->read_id(nor);
+ jid = spi_nor_read_id(nor);
if (IS_ERR(jid)) {
return PTR_ERR(jid);
} else if (jid != id) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 5ec84cc..66af67a 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -139,8 +139,6 @@ enum spi_nor_ops {
* @write_xfer: [OPTIONAL] the writefundamental primitive
* @read_reg: [DRIVER-SPECIFIC] read out the register
* @write_reg: [DRIVER-SPECIFIC] write data to the register
- * @read_id: [REPLACEABLE] read out the ID data, and find
- * the proper spi_device_id
* @wait_till_ready: [REPLACEABLE] wait till the NOR becomes ready
* @read: [DRIVER-SPECIFIC] read data from the SPI NOR
* @write: [DRIVER-SPECIFIC] write data to the SPI NOR
@@ -172,7 +170,6 @@ struct spi_nor {
int (*read_reg)(struct spi_nor *nor, u8 opcode, u8 *buf, int len);
int (*write_reg)(struct spi_nor *nor, u8 opcode, u8 *buf, int len,
int write_enable);
- const struct spi_device_id *(*read_id)(struct spi_nor *nor);
int (*wait_till_ready)(struct spi_nor *nor);
int (*read)(struct spi_nor *nor, loff_t from,
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 2/5] spi-nor: Remove spi_nor::read_id operation
@ 2014-09-14 17:11 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Geert Uytterhoeven, Huang Shijie, linux-arm-kernel,
debian-kernel
[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]
There is currently no useful way to override the default
implementation of this operation. The returned struct spi_device_id
must have a pointer to struct flash_info in its private data, but this
structure is defined inside spi-nor.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/mtd/spi-nor/spi-nor.c | 4 +---
include/linux/mtd/spi-nor.h | 3 ---
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6b1bda2..6f699c5 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -902,8 +902,6 @@ static int spi_nor_check(struct spi_nor *nor)
return -EINVAL;
}
- if (!nor->read_id)
- nor->read_id = spi_nor_read_id;
if (!nor->wait_till_ready)
nor->wait_till_ready = spi_nor_wait_till_ready;
@@ -952,7 +950,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
if (info->jedec_id) {
const struct spi_device_id *jid;
- jid = nor->read_id(nor);
+ jid = spi_nor_read_id(nor);
if (IS_ERR(jid)) {
return PTR_ERR(jid);
} else if (jid != id) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 5ec84cc..66af67a 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -139,8 +139,6 @@ enum spi_nor_ops {
* @write_xfer: [OPTIONAL] the writefundamental primitive
* @read_reg: [DRIVER-SPECIFIC] read out the register
* @write_reg: [DRIVER-SPECIFIC] write data to the register
- * @read_id: [REPLACEABLE] read out the ID data, and find
- * the proper spi_device_id
* @wait_till_ready: [REPLACEABLE] wait till the NOR becomes ready
* @read: [DRIVER-SPECIFIC] read data from the SPI NOR
* @write: [DRIVER-SPECIFIC] write data to the SPI NOR
@@ -172,7 +170,6 @@ struct spi_nor {
int (*read_reg)(struct spi_nor *nor, u8 opcode, u8 *buf, int len);
int (*write_reg)(struct spi_nor *nor, u8 opcode, u8 *buf, int len,
int write_enable);
- const struct spi_device_id *(*read_id)(struct spi_nor *nor);
int (*wait_till_ready)(struct spi_nor *nor);
int (*read)(struct spi_nor *nor, loff_t from,
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 2/5] spi-nor: Remove spi_nor::read_id operation
@ 2014-09-14 17:11 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: linux-arm-kernel
There is currently no useful way to override the default
implementation of this operation. The returned struct spi_device_id
must have a pointer to struct flash_info in its private data, but this
structure is defined inside spi-nor.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/mtd/spi-nor/spi-nor.c | 4 +---
include/linux/mtd/spi-nor.h | 3 ---
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6b1bda2..6f699c5 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -902,8 +902,6 @@ static int spi_nor_check(struct spi_nor *nor)
return -EINVAL;
}
- if (!nor->read_id)
- nor->read_id = spi_nor_read_id;
if (!nor->wait_till_ready)
nor->wait_till_ready = spi_nor_wait_till_ready;
@@ -952,7 +950,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
if (info->jedec_id) {
const struct spi_device_id *jid;
- jid = nor->read_id(nor);
+ jid = spi_nor_read_id(nor);
if (IS_ERR(jid)) {
return PTR_ERR(jid);
} else if (jid != id) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 5ec84cc..66af67a 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -139,8 +139,6 @@ enum spi_nor_ops {
* @write_xfer: [OPTIONAL] the writefundamental primitive
* @read_reg: [DRIVER-SPECIFIC] read out the register
* @write_reg: [DRIVER-SPECIFIC] write data to the register
- * @read_id: [REPLACEABLE] read out the ID data, and find
- * the proper spi_device_id
* @wait_till_ready: [REPLACEABLE] wait till the NOR becomes ready
* @read: [DRIVER-SPECIFIC] read data from the SPI NOR
* @write: [DRIVER-SPECIFIC] write data to the SPI NOR
@@ -172,7 +170,6 @@ struct spi_nor {
int (*read_reg)(struct spi_nor *nor, u8 opcode, u8 *buf, int len);
int (*write_reg)(struct spi_nor *nor, u8 opcode, u8 *buf, int len,
int write_enable);
- const struct spi_device_id *(*read_id)(struct spi_nor *nor);
int (*wait_till_ready)(struct spi_nor *nor);
int (*read)(struct spi_nor *nor, loff_t from,
--
Ben Hutchings
The world is coming to an end. Please log off.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140914/2cc952ea/attachment-0001.sig>
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 3/5] spi-nor: Make spi_nor_scan() take a chip type name, not an spi_device_id
2014-09-14 17:10 ` Ben Hutchings
(?)
@ 2014-09-14 17:11 ` Ben Hutchings
-1 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: Brian Norris
Cc: Geert Uytterhoeven, Andrew Lunn, Jason Cooper, linux-spi,
Huang Shijie, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 6211 bytes --]
Drivers currently call spi_nor_match_id() and then spi_nor_scan().
This adds a dependency on struct spi_device_id which we want to
avoid. Make spi_nor_scan() do it for them.
Signed-off-by: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
---
drivers/mtd/devices/m25p80.c | 6 +-----
drivers/mtd/spi-nor/fsl-quadspi.c | 7 +------
drivers/mtd/spi-nor/spi-nor.c | 29 +++++++++++++----------------
include/linux/mtd/spi-nor.h | 21 ++++-----------------
4 files changed, 19 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 3f0fe86..b547c39 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -196,7 +196,6 @@ static int m25p_probe(struct spi_device *spi)
struct m25p *flash;
struct spi_nor *nor;
enum read_mode mode = SPI_NOR_NORMAL;
- const struct spi_device_id *id;
int ret;
flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
@@ -224,10 +223,7 @@ static int m25p_probe(struct spi_device *spi)
mode = SPI_NOR_QUAD;
else if (spi->mode & SPI_RX_DUAL)
mode = SPI_NOR_DUAL;
- id = spi_nor_match_id(spi_get_device_id(spi)->name);
- if (WARN_ON(!id))
- return -ENODEV;
- ret = spi_nor_scan(nor, id, mode);
+ ret = spi_nor_scan(nor, spi_get_device_id(spi)->name, mode);
if (ret)
return ret;
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index 8d659a2..d5269a2 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -881,7 +881,6 @@ static int fsl_qspi_probe(struct platform_device *pdev)
/* iterate the subnodes. */
for_each_available_child_of_node(dev->of_node, np) {
- const struct spi_device_id *id;
char modalias[40];
/* skip the holes */
@@ -909,10 +908,6 @@ static int fsl_qspi_probe(struct platform_device *pdev)
if (of_modalias_node(np, modalias, sizeof(modalias)) < 0)
goto map_failed;
- id = spi_nor_match_id(modalias);
- if (!id)
- goto map_failed;
-
ret = of_property_read_u32(np, "spi-max-frequency",
&q->clk_rate);
if (ret < 0)
@@ -921,7 +916,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
/* set the chip address for READID */
fsl_qspi_set_base_addr(q, nor);
- ret = spi_nor_scan(nor, id, SPI_NOR_QUAD);
+ ret = spi_nor_scan(nor, modalias, SPI_NOR_QUAD);
if (ret)
goto map_failed;
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6f699c5..40d6f70 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -28,6 +28,8 @@
#define JEDEC_MFR(_jedec_id) ((_jedec_id) >> 16)
+static const struct spi_device_id *spi_nor_match_id(const char *name);
+
/*
* Read the status register, returning its value in the location
* Return the status register value.
@@ -908,9 +910,9 @@ static int spi_nor_check(struct spi_nor *nor)
return 0;
}
-int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
- enum read_mode mode)
+int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
{
+ const struct spi_device_id *id = NULL;
struct flash_info *info;
struct flash_platform_data *data;
struct device *dev = nor->dev;
@@ -930,21 +932,17 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
*/
data = dev_get_platdata(dev);
if (data && data->type) {
- const struct spi_device_id *plat_id;
-
- for (i = 0; i < ARRAY_SIZE(spi_nor_ids) - 1; i++) {
- plat_id = &spi_nor_ids[i];
- if (strcmp(data->type, plat_id->name))
- continue;
- break;
- }
-
- if (i < ARRAY_SIZE(spi_nor_ids) - 1)
- id = plat_id;
- else
+ id = spi_nor_match_id(data->type);
+ if (!id)
dev_warn(dev, "unrecognized id %s\n", data->type);
}
+ if (!id && name)
+ id = spi_nor_match_id(name);
+
+ if (!id)
+ return -ENODEV;
+
info = (void *)id->driver_data;
if (info->jedec_id) {
@@ -1133,7 +1131,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
}
EXPORT_SYMBOL_GPL(spi_nor_scan);
-const struct spi_device_id *spi_nor_match_id(const char *name)
+static const struct spi_device_id *spi_nor_match_id(const char *name)
{
const struct spi_device_id *id = spi_nor_ids;
@@ -1144,7 +1142,6 @@ const struct spi_device_id *spi_nor_match_id(const char *name)
}
return NULL;
}
-EXPORT_SYMBOL_GPL(spi_nor_match_id);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Huang Shijie <shijie8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 66af67a..6f92b4b 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -184,31 +184,18 @@ struct spi_nor {
/**
* spi_nor_scan() - scan the SPI NOR
* @nor: the spi_nor structure
- * @id: the spi_device_id provided by the driver
+ * @name: the chip type name
* @mode: the read mode supported by the driver
*
* The drivers can use this fuction to scan the SPI NOR.
* In the scanning, it will try to get all the necessary information to
* fill the mtd_info{} and the spi_nor{}.
*
- * The board may assigns a spi_device_id with @id which be used to compared with
- * the spi_device_id detected by the scanning.
+ * The chip type name can be provided either through platform data or
+ * through the @name parameter. Platform data takes precedence.
*
* Return: 0 for success, others for failure.
*/
-int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
- enum read_mode mode);
-
-/**
- * spi_nor_match_id() - find the spi_device_id by the name
- * @name: the name of the spi_device_id
- *
- * The drivers use this function to find the spi_device_id
- * specified by the @name.
- *
- * Return: returns the right spi_device_id pointer on success,
- * and returns NULL on failure.
- */
-const struct spi_device_id *spi_nor_match_id(const char *name);
+int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
#endif
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 3/5] spi-nor: Make spi_nor_scan() take a chip type name, not an spi_device_id
@ 2014-09-14 17:11 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Geert Uytterhoeven, Huang Shijie, linux-arm-kernel,
debian-kernel
[-- Attachment #1: Type: text/plain, Size: 6157 bytes --]
Drivers currently call spi_nor_match_id() and then spi_nor_scan().
This adds a dependency on struct spi_device_id which we want to
avoid. Make spi_nor_scan() do it for them.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/mtd/devices/m25p80.c | 6 +-----
drivers/mtd/spi-nor/fsl-quadspi.c | 7 +------
drivers/mtd/spi-nor/spi-nor.c | 29 +++++++++++++----------------
include/linux/mtd/spi-nor.h | 21 ++++-----------------
4 files changed, 19 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 3f0fe86..b547c39 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -196,7 +196,6 @@ static int m25p_probe(struct spi_device *spi)
struct m25p *flash;
struct spi_nor *nor;
enum read_mode mode = SPI_NOR_NORMAL;
- const struct spi_device_id *id;
int ret;
flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
@@ -224,10 +223,7 @@ static int m25p_probe(struct spi_device *spi)
mode = SPI_NOR_QUAD;
else if (spi->mode & SPI_RX_DUAL)
mode = SPI_NOR_DUAL;
- id = spi_nor_match_id(spi_get_device_id(spi)->name);
- if (WARN_ON(!id))
- return -ENODEV;
- ret = spi_nor_scan(nor, id, mode);
+ ret = spi_nor_scan(nor, spi_get_device_id(spi)->name, mode);
if (ret)
return ret;
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index 8d659a2..d5269a2 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -881,7 +881,6 @@ static int fsl_qspi_probe(struct platform_device *pdev)
/* iterate the subnodes. */
for_each_available_child_of_node(dev->of_node, np) {
- const struct spi_device_id *id;
char modalias[40];
/* skip the holes */
@@ -909,10 +908,6 @@ static int fsl_qspi_probe(struct platform_device *pdev)
if (of_modalias_node(np, modalias, sizeof(modalias)) < 0)
goto map_failed;
- id = spi_nor_match_id(modalias);
- if (!id)
- goto map_failed;
-
ret = of_property_read_u32(np, "spi-max-frequency",
&q->clk_rate);
if (ret < 0)
@@ -921,7 +916,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
/* set the chip address for READID */
fsl_qspi_set_base_addr(q, nor);
- ret = spi_nor_scan(nor, id, SPI_NOR_QUAD);
+ ret = spi_nor_scan(nor, modalias, SPI_NOR_QUAD);
if (ret)
goto map_failed;
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6f699c5..40d6f70 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -28,6 +28,8 @@
#define JEDEC_MFR(_jedec_id) ((_jedec_id) >> 16)
+static const struct spi_device_id *spi_nor_match_id(const char *name);
+
/*
* Read the status register, returning its value in the location
* Return the status register value.
@@ -908,9 +910,9 @@ static int spi_nor_check(struct spi_nor *nor)
return 0;
}
-int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
- enum read_mode mode)
+int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
{
+ const struct spi_device_id *id = NULL;
struct flash_info *info;
struct flash_platform_data *data;
struct device *dev = nor->dev;
@@ -930,21 +932,17 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
*/
data = dev_get_platdata(dev);
if (data && data->type) {
- const struct spi_device_id *plat_id;
-
- for (i = 0; i < ARRAY_SIZE(spi_nor_ids) - 1; i++) {
- plat_id = &spi_nor_ids[i];
- if (strcmp(data->type, plat_id->name))
- continue;
- break;
- }
-
- if (i < ARRAY_SIZE(spi_nor_ids) - 1)
- id = plat_id;
- else
+ id = spi_nor_match_id(data->type);
+ if (!id)
dev_warn(dev, "unrecognized id %s\n", data->type);
}
+ if (!id && name)
+ id = spi_nor_match_id(name);
+
+ if (!id)
+ return -ENODEV;
+
info = (void *)id->driver_data;
if (info->jedec_id) {
@@ -1133,7 +1131,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
}
EXPORT_SYMBOL_GPL(spi_nor_scan);
-const struct spi_device_id *spi_nor_match_id(const char *name)
+static const struct spi_device_id *spi_nor_match_id(const char *name)
{
const struct spi_device_id *id = spi_nor_ids;
@@ -1144,7 +1142,6 @@ const struct spi_device_id *spi_nor_match_id(const char *name)
}
return NULL;
}
-EXPORT_SYMBOL_GPL(spi_nor_match_id);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Huang Shijie <shijie8@gmail.com>");
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 66af67a..6f92b4b 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -184,31 +184,18 @@ struct spi_nor {
/**
* spi_nor_scan() - scan the SPI NOR
* @nor: the spi_nor structure
- * @id: the spi_device_id provided by the driver
+ * @name: the chip type name
* @mode: the read mode supported by the driver
*
* The drivers can use this fuction to scan the SPI NOR.
* In the scanning, it will try to get all the necessary information to
* fill the mtd_info{} and the spi_nor{}.
*
- * The board may assigns a spi_device_id with @id which be used to compared with
- * the spi_device_id detected by the scanning.
+ * The chip type name can be provided either through platform data or
+ * through the @name parameter. Platform data takes precedence.
*
* Return: 0 for success, others for failure.
*/
-int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
- enum read_mode mode);
-
-/**
- * spi_nor_match_id() - find the spi_device_id by the name
- * @name: the name of the spi_device_id
- *
- * The drivers use this function to find the spi_device_id
- * specified by the @name.
- *
- * Return: returns the right spi_device_id pointer on success,
- * and returns NULL on failure.
- */
-const struct spi_device_id *spi_nor_match_id(const char *name);
+int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
#endif
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 3/5] spi-nor: Make spi_nor_scan() take a chip type name, not an spi_device_id
@ 2014-09-14 17:11 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: linux-arm-kernel
Drivers currently call spi_nor_match_id() and then spi_nor_scan().
This adds a dependency on struct spi_device_id which we want to
avoid. Make spi_nor_scan() do it for them.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/mtd/devices/m25p80.c | 6 +-----
drivers/mtd/spi-nor/fsl-quadspi.c | 7 +------
drivers/mtd/spi-nor/spi-nor.c | 29 +++++++++++++----------------
include/linux/mtd/spi-nor.h | 21 ++++-----------------
4 files changed, 19 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 3f0fe86..b547c39 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -196,7 +196,6 @@ static int m25p_probe(struct spi_device *spi)
struct m25p *flash;
struct spi_nor *nor;
enum read_mode mode = SPI_NOR_NORMAL;
- const struct spi_device_id *id;
int ret;
flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
@@ -224,10 +223,7 @@ static int m25p_probe(struct spi_device *spi)
mode = SPI_NOR_QUAD;
else if (spi->mode & SPI_RX_DUAL)
mode = SPI_NOR_DUAL;
- id = spi_nor_match_id(spi_get_device_id(spi)->name);
- if (WARN_ON(!id))
- return -ENODEV;
- ret = spi_nor_scan(nor, id, mode);
+ ret = spi_nor_scan(nor, spi_get_device_id(spi)->name, mode);
if (ret)
return ret;
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index 8d659a2..d5269a2 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -881,7 +881,6 @@ static int fsl_qspi_probe(struct platform_device *pdev)
/* iterate the subnodes. */
for_each_available_child_of_node(dev->of_node, np) {
- const struct spi_device_id *id;
char modalias[40];
/* skip the holes */
@@ -909,10 +908,6 @@ static int fsl_qspi_probe(struct platform_device *pdev)
if (of_modalias_node(np, modalias, sizeof(modalias)) < 0)
goto map_failed;
- id = spi_nor_match_id(modalias);
- if (!id)
- goto map_failed;
-
ret = of_property_read_u32(np, "spi-max-frequency",
&q->clk_rate);
if (ret < 0)
@@ -921,7 +916,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
/* set the chip address for READID */
fsl_qspi_set_base_addr(q, nor);
- ret = spi_nor_scan(nor, id, SPI_NOR_QUAD);
+ ret = spi_nor_scan(nor, modalias, SPI_NOR_QUAD);
if (ret)
goto map_failed;
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6f699c5..40d6f70 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -28,6 +28,8 @@
#define JEDEC_MFR(_jedec_id) ((_jedec_id) >> 16)
+static const struct spi_device_id *spi_nor_match_id(const char *name);
+
/*
* Read the status register, returning its value in the location
* Return the status register value.
@@ -908,9 +910,9 @@ static int spi_nor_check(struct spi_nor *nor)
return 0;
}
-int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
- enum read_mode mode)
+int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
{
+ const struct spi_device_id *id = NULL;
struct flash_info *info;
struct flash_platform_data *data;
struct device *dev = nor->dev;
@@ -930,21 +932,17 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
*/
data = dev_get_platdata(dev);
if (data && data->type) {
- const struct spi_device_id *plat_id;
-
- for (i = 0; i < ARRAY_SIZE(spi_nor_ids) - 1; i++) {
- plat_id = &spi_nor_ids[i];
- if (strcmp(data->type, plat_id->name))
- continue;
- break;
- }
-
- if (i < ARRAY_SIZE(spi_nor_ids) - 1)
- id = plat_id;
- else
+ id = spi_nor_match_id(data->type);
+ if (!id)
dev_warn(dev, "unrecognized id %s\n", data->type);
}
+ if (!id && name)
+ id = spi_nor_match_id(name);
+
+ if (!id)
+ return -ENODEV;
+
info = (void *)id->driver_data;
if (info->jedec_id) {
@@ -1133,7 +1131,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
}
EXPORT_SYMBOL_GPL(spi_nor_scan);
-const struct spi_device_id *spi_nor_match_id(const char *name)
+static const struct spi_device_id *spi_nor_match_id(const char *name)
{
const struct spi_device_id *id = spi_nor_ids;
@@ -1144,7 +1142,6 @@ const struct spi_device_id *spi_nor_match_id(const char *name)
}
return NULL;
}
-EXPORT_SYMBOL_GPL(spi_nor_match_id);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Huang Shijie <shijie8@gmail.com>");
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 66af67a..6f92b4b 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -184,31 +184,18 @@ struct spi_nor {
/**
* spi_nor_scan() - scan the SPI NOR
* @nor: the spi_nor structure
- * @id: the spi_device_id provided by the driver
+ * @name: the chip type name
* @mode: the read mode supported by the driver
*
* The drivers can use this fuction to scan the SPI NOR.
* In the scanning, it will try to get all the necessary information to
* fill the mtd_info{} and the spi_nor{}.
*
- * The board may assigns a spi_device_id with @id which be used to compared with
- * the spi_device_id detected by the scanning.
+ * The chip type name can be provided either through platform data or
+ * through the @name parameter. Platform data takes precedence.
*
* Return: 0 for success, others for failure.
*/
-int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
- enum read_mode mode);
-
-/**
- * spi_nor_match_id() - find the spi_device_id by the name
- * @name: the name of the spi_device_id
- *
- * The drivers use this function to find the spi_device_id
- * specified by the @name.
- *
- * Return: returns the right spi_device_id pointer on success,
- * and returns NULL on failure.
- */
-const struct spi_device_id *spi_nor_match_id(const char *name);
+int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
#endif
--
Ben Hutchings
The world is coming to an end. Please log off.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140914/b3c0f038/attachment.sig>
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 4/5] spi-nor: Replace struct spi_device_id with struct flash_info
2014-09-14 17:10 ` Ben Hutchings
(?)
@ 2014-09-14 17:11 ` Ben Hutchings
-1 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: Brian Norris
Cc: Geert Uytterhoeven, Andrew Lunn, Jason Cooper, linux-spi,
Huang Shijie, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 23412 bytes --]
spi-nor does not depend on the SPI layer, so its use of struct
spi_device_id adds an unnecessary indirection. Add the chip type name
to struct flash_info and remove the wrapping struct spi_device_id.
Signed-off-by: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
---
drivers/mtd/devices/m25p80.c | 2 +-
drivers/mtd/spi-nor/spi-nor.c | 344 +++++++++++++++++++++---------------------
2 files changed, 172 insertions(+), 174 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index b547c39..271d83f 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -246,7 +246,7 @@ static int m25p_remove(struct spi_device *spi)
/*
- * XXX This needs to be kept in sync with spi_nor_ids. We can't share
+ * XXX This needs to be kept in sync with spi_nor_info. We can't share
* it with spi-nor, because if this is built as a module then modpost
* won't be able to read it and add appropriate aliases.
*/
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 40d6f70..3b88c6b 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -28,8 +28,6 @@
#define JEDEC_MFR(_jedec_id) ((_jedec_id) >> 16)
-static const struct spi_device_id *spi_nor_match_id(const char *name);
-
/*
* Read the status register, returning its value in the location
* Return the status register value.
@@ -425,6 +423,8 @@ err:
}
struct flash_info {
+ const char name[SPI_NAME_SIZE];
+
/* JEDEC id zero means "no ID" (most older chips); otherwise it has
* a high byte of zero plus three data bytes: the manufacturer id,
* then a two byte device id.
@@ -452,201 +452,215 @@ struct flash_info {
#define USE_FSR 0x80 /* use flag status register */
};
-#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
- ((kernel_ulong_t)&(struct flash_info) { \
+#define INFO(_name, _jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ { \
+ .name = (_name), \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = 256, \
.flags = (_flags), \
- })
+ }
-#define CAT25_INFO(_sector_size, _n_sectors, _page_size, _addr_width, _flags) \
- ((kernel_ulong_t)&(struct flash_info) { \
+#define CAT25_INFO(_name, _sector_size, _n_sectors, _page_size, \
+ _addr_width, _flags) \
+ { \
+ .name = (_name), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = (_page_size), \
.addr_width = (_addr_width), \
.flags = (_flags), \
- })
+ }
/* 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.
*/
-static const struct spi_device_id spi_nor_ids[] = {
+static const struct flash_info spi_nor_info[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
- { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
- { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
+ INFO("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
+ INFO("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
- { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
- { "at25df321a", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
- { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
+ INFO("at25df041a", 0x1f4401, 0, 64 * 1024, 8, SECT_4K),
+ INFO("at25df321a", 0x1f4701, 0, 64 * 1024, 64, SECT_4K),
+ INFO("at25df641", 0x1f4800, 0, 64 * 1024, 128, SECT_4K),
- { "at26f004", INFO(0x1f0400, 0, 64 * 1024, 8, SECT_4K) },
- { "at26df081a", INFO(0x1f4501, 0, 64 * 1024, 16, SECT_4K) },
- { "at26df161a", INFO(0x1f4601, 0, 64 * 1024, 32, SECT_4K) },
- { "at26df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
+ INFO("at26f004", 0x1f0400, 0, 64 * 1024, 8, SECT_4K),
+ INFO("at26df081a", 0x1f4501, 0, 64 * 1024, 16, SECT_4K),
+ INFO("at26df161a", 0x1f4601, 0, 64 * 1024, 32, SECT_4K),
+ INFO("at26df321", 0x1f4700, 0, 64 * 1024, 64, SECT_4K),
- { "at45db081d", INFO(0x1f2500, 0, 64 * 1024, 16, SECT_4K) },
+ INFO("at45db081d", 0x1f2500, 0, 64 * 1024, 16, SECT_4K),
/* EON -- en25xxx */
- { "en25f32", INFO(0x1c3116, 0, 64 * 1024, 64, SECT_4K) },
- { "en25p32", INFO(0x1c2016, 0, 64 * 1024, 64, 0) },
- { "en25q32b", INFO(0x1c3016, 0, 64 * 1024, 64, 0) },
- { "en25p64", INFO(0x1c2017, 0, 64 * 1024, 128, 0) },
- { "en25q64", INFO(0x1c3017, 0, 64 * 1024, 128, SECT_4K) },
- { "en25qh128", INFO(0x1c7018, 0, 64 * 1024, 256, 0) },
- { "en25qh256", INFO(0x1c7019, 0, 64 * 1024, 512, 0) },
+ INFO("en25f32", 0x1c3116, 0, 64 * 1024, 64, SECT_4K),
+ INFO("en25p32", 0x1c2016, 0, 64 * 1024, 64, 0),
+ INFO("en25q32b", 0x1c3016, 0, 64 * 1024, 64, 0),
+ INFO("en25p64", 0x1c2017, 0, 64 * 1024, 128, 0),
+ INFO("en25q64", 0x1c3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO("en25qh128", 0x1c7018, 0, 64 * 1024, 256, 0),
+ INFO("en25qh256", 0x1c7019, 0, 64 * 1024, 512, 0),
/* ESMT */
- { "f25l32pa", INFO(0x8c2016, 0, 64 * 1024, 64, SECT_4K) },
+ INFO("f25l32pa", 0x8c2016, 0, 64 * 1024, 64, SECT_4K),
/* Everspin */
- { "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "mr25h10", CAT25_INFO(128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
+ CAT25_INFO("mr25h256", 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("mr25h10", 128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
/* GigaDevice */
- { "gd25q32", INFO(0xc84016, 0, 64 * 1024, 64, SECT_4K) },
- { "gd25q64", INFO(0xc84017, 0, 64 * 1024, 128, SECT_4K) },
+ INFO("gd25q32", 0xc84016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("gd25q64", 0xc84017, 0, 64 * 1024, 128, SECT_4K),
/* Intel/Numonyx -- xxxs33b */
- { "160s33b", INFO(0x898911, 0, 64 * 1024, 32, 0) },
- { "320s33b", INFO(0x898912, 0, 64 * 1024, 64, 0) },
- { "640s33b", INFO(0x898913, 0, 64 * 1024, 128, 0) },
+ INFO("160s33b", 0x898911, 0, 64 * 1024, 32, 0),
+ INFO("320s33b", 0x898912, 0, 64 * 1024, 64, 0),
+ INFO("640s33b", 0x898913, 0, 64 * 1024, 128, 0),
/* Macronix */
- { "mx25l2005a", INFO(0xc22012, 0, 64 * 1024, 4, SECT_4K) },
- { "mx25l4005a", INFO(0xc22013, 0, 64 * 1024, 8, SECT_4K) },
- { "mx25l8005", INFO(0xc22014, 0, 64 * 1024, 16, 0) },
- { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32, SECT_4K) },
- { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, 0) },
- { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64, SECT_4K) },
- { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, 0) },
- { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
- { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
- { "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512, 0) },
- { "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
- { "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ) },
- { "mx66l1g55g", INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) },
+ INFO("mx25l2005a", 0xc22012, 0, 64 * 1024, 4, SECT_4K),
+ INFO("mx25l4005a", 0xc22013, 0, 64 * 1024, 8, SECT_4K),
+ INFO("mx25l8005", 0xc22014, 0, 64 * 1024, 16, 0),
+ INFO("mx25l1606e", 0xc22015, 0, 64 * 1024, 32, SECT_4K),
+ INFO("mx25l3205d", 0xc22016, 0, 64 * 1024, 64, 0),
+ INFO("mx25l3255e", 0xc29e16, 0, 64 * 1024, 64, SECT_4K),
+ INFO("mx25l6405d", 0xc22017, 0, 64 * 1024, 128, 0),
+ INFO("mx25l12805d", 0xc22018, 0, 64 * 1024, 256, 0),
+ INFO("mx25l12855e", 0xc22618, 0, 64 * 1024, 256, 0),
+ INFO("mx25l25635e", 0xc22019, 0, 64 * 1024, 512, 0),
+ INFO("mx25l25655e", 0xc22619, 0, 64 * 1024, 512, 0),
+ INFO("mx66l51235l", 0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ),
+ INFO("mx66l1g55g", 0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ),
/* Micron */
- { "n25q064", INFO(0x20ba17, 0, 64 * 1024, 128, 0) },
- { "n25q128a11", INFO(0x20bb18, 0, 64 * 1024, 256, 0) },
- { "n25q128a13", INFO(0x20ba18, 0, 64 * 1024, 256, 0) },
- { "n25q256a", INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
- { "n25q512a", INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
- { "n25q512ax3", INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
- { "n25q00", INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
+ INFO("n25q064", 0x20ba17, 0, 64 * 1024, 128, 0),
+ INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, 0),
+ INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, 0),
+ INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K),
+ INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K),
+ INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, USE_FSR),
+ INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, USE_FSR),
/* PMC */
- { "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) },
- { "pm25lv010", INFO(0, 0, 32 * 1024, 4, SECT_4K_PMC) },
- { "pm25lq032", INFO(0x7f9d46, 0, 64 * 1024, 64, SECT_4K) },
+ INFO("pm25lv512", 0, 0, 32 * 1024, 2, SECT_4K_PMC),
+ INFO("pm25lv010", 0, 0, 32 * 1024, 4, SECT_4K_PMC),
+ INFO("pm25lq032", 0x7f9d46, 0, 64 * 1024, 64, SECT_4K),
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128, 0) },
- { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
- { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "s70fl01gs", INFO(0x010221, 0x4d00, 256 * 1024, 256, 0) },
- { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
- { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
- { "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024, 64, 0) },
- { "s25fl129p1", INFO(0x012018, 0x4d01, 64 * 1024, 256, 0) },
- { "s25sl004a", INFO(0x010212, 0, 64 * 1024, 8, 0) },
- { "s25sl008a", INFO(0x010213, 0, 64 * 1024, 16, 0) },
- { "s25sl016a", INFO(0x010214, 0, 64 * 1024, 32, 0) },
- { "s25sl032a", INFO(0x010215, 0, 64 * 1024, 64, 0) },
- { "s25sl064a", INFO(0x010216, 0, 64 * 1024, 128, 0) },
- { "s25fl008k", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
- { "s25fl016k", INFO(0xef4015, 0, 64 * 1024, 32, SECT_4K) },
- { "s25fl064k", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
+ INFO("s25sl032p", 0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO("s25sl064p", 0x010216, 0x4d00, 64 * 1024, 128, 0),
+ INFO("s25fl256s0", 0x010219, 0x4d00, 256 * 1024, 128, 0),
+ INFO("s25fl256s1", 0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO("s25fl512s", 0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO("s70fl01gs", 0x010221, 0x4d00, 256 * 1024, 256, 0),
+ INFO("s25sl12800", 0x012018, 0x0300, 256 * 1024, 64, 0),
+ INFO("s25sl12801", 0x012018, 0x0301, 64 * 1024, 256, 0),
+ INFO("s25fl129p0", 0x012018, 0x4d00, 256 * 1024, 64, 0),
+ INFO("s25fl129p1", 0x012018, 0x4d01, 64 * 1024, 256, 0),
+ INFO("s25sl004a", 0x010212, 0, 64 * 1024, 8, 0),
+ INFO("s25sl008a", 0x010213, 0, 64 * 1024, 16, 0),
+ INFO("s25sl016a", 0x010214, 0, 64 * 1024, 32, 0),
+ INFO("s25sl032a", 0x010215, 0, 64 * 1024, 64, 0),
+ INFO("s25sl064a", 0x010216, 0, 64 * 1024, 128, 0),
+ INFO("s25fl008k", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("s25fl016k", 0xef4015, 0, 64 * 1024, 32, SECT_4K),
+ INFO("s25fl064k", 0xef4017, 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) },
- { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) },
- { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) },
- { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
- { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
- { "sst25wf512", INFO(0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE) },
- { "sst25wf010", INFO(0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE) },
- { "sst25wf020", INFO(0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE) },
- { "sst25wf040", INFO(0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) },
+ INFO("sst25vf040b", 0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
+ INFO("sst25vf080b", 0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE),
+ INFO("sst25vf016b", 0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE),
+ INFO("sst25vf032b", 0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE),
+ INFO("sst25vf064c", 0xbf254b, 0, 64 * 1024, 128, SECT_4K),
+ INFO("sst25wf512", 0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE),
+ INFO("sst25wf010", 0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE),
+ INFO("sst25wf020", 0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE),
+ INFO("sst25wf040", 0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
/* ST Microelectronics -- newer production may have feature updates */
- { "m25p05", INFO(0x202010, 0, 32 * 1024, 2, 0) },
- { "m25p10", INFO(0x202011, 0, 32 * 1024, 4, 0) },
- { "m25p20", INFO(0x202012, 0, 64 * 1024, 4, 0) },
- { "m25p40", INFO(0x202013, 0, 64 * 1024, 8, 0) },
- { "m25p80", INFO(0x202014, 0, 64 * 1024, 16, 0) },
- { "m25p16", INFO(0x202015, 0, 64 * 1024, 32, 0) },
- { "m25p32", INFO(0x202016, 0, 64 * 1024, 64, 0) },
- { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
- { "m25p128", INFO(0x202018, 0, 256 * 1024, 64, 0) },
- { "n25q032", INFO(0x20ba16, 0, 64 * 1024, 64, 0) },
-
- { "m25p05-nonjedec", INFO(0, 0, 32 * 1024, 2, 0) },
- { "m25p10-nonjedec", INFO(0, 0, 32 * 1024, 4, 0) },
- { "m25p20-nonjedec", INFO(0, 0, 64 * 1024, 4, 0) },
- { "m25p40-nonjedec", INFO(0, 0, 64 * 1024, 8, 0) },
- { "m25p80-nonjedec", INFO(0, 0, 64 * 1024, 16, 0) },
- { "m25p16-nonjedec", INFO(0, 0, 64 * 1024, 32, 0) },
- { "m25p32-nonjedec", INFO(0, 0, 64 * 1024, 64, 0) },
- { "m25p64-nonjedec", INFO(0, 0, 64 * 1024, 128, 0) },
- { "m25p128-nonjedec", INFO(0, 0, 256 * 1024, 64, 0) },
-
- { "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 0) },
- { "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 0) },
- { "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 0) },
-
- { "m25pe20", INFO(0x208012, 0, 64 * 1024, 4, 0) },
- { "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 0) },
- { "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, SECT_4K) },
-
- { "m25px16", INFO(0x207115, 0, 64 * 1024, 32, SECT_4K) },
- { "m25px32", INFO(0x207116, 0, 64 * 1024, 64, SECT_4K) },
- { "m25px32-s0", INFO(0x207316, 0, 64 * 1024, 64, SECT_4K) },
- { "m25px32-s1", INFO(0x206316, 0, 64 * 1024, 64, SECT_4K) },
- { "m25px64", INFO(0x207117, 0, 64 * 1024, 128, 0) },
- { "m25px80", INFO(0x207114, 0, 64 * 1024, 16, 0) },
+ INFO("m25p05", 0x202010, 0, 32 * 1024, 2, 0),
+ INFO("m25p10", 0x202011, 0, 32 * 1024, 4, 0),
+ INFO("m25p20", 0x202012, 0, 64 * 1024, 4, 0),
+ INFO("m25p40", 0x202013, 0, 64 * 1024, 8, 0),
+ INFO("m25p80", 0x202014, 0, 64 * 1024, 16, 0),
+ INFO("m25p16", 0x202015, 0, 64 * 1024, 32, 0),
+ INFO("m25p32", 0x202016, 0, 64 * 1024, 64, 0),
+ INFO("m25p64", 0x202017, 0, 64 * 1024, 128, 0),
+ INFO("m25p128", 0x202018, 0, 256 * 1024, 64, 0),
+ INFO("n25q032", 0x20ba16, 0, 64 * 1024, 64, 0),
+
+ INFO("m25p05-nonjedec", 0, 0, 32 * 1024, 2, 0),
+ INFO("m25p10-nonjedec", 0, 0, 32 * 1024, 4, 0),
+ INFO("m25p20-nonjedec", 0, 0, 64 * 1024, 4, 0),
+ INFO("m25p40-nonjedec", 0, 0, 64 * 1024, 8, 0),
+ INFO("m25p80-nonjedec", 0, 0, 64 * 1024, 16, 0),
+ INFO("m25p16-nonjedec", 0, 0, 64 * 1024, 32, 0),
+ INFO("m25p32-nonjedec", 0, 0, 64 * 1024, 64, 0),
+ INFO("m25p64-nonjedec", 0, 0, 64 * 1024, 128, 0),
+ INFO("m25p128-nonjedec", 0, 0, 256 * 1024, 64, 0),
+
+ INFO("m45pe10", 0x204011, 0, 64 * 1024, 2, 0),
+ INFO("m45pe80", 0x204014, 0, 64 * 1024, 16, 0),
+ INFO("m45pe16", 0x204015, 0, 64 * 1024, 32, 0),
+
+ INFO("m25pe20", 0x208012, 0, 64 * 1024, 4, 0),
+ INFO("m25pe80", 0x208014, 0, 64 * 1024, 16, 0),
+ INFO("m25pe16", 0x208015, 0, 64 * 1024, 32, SECT_4K),
+
+ INFO("m25px16", 0x207115, 0, 64 * 1024, 32, SECT_4K),
+ INFO("m25px32", 0x207116, 0, 64 * 1024, 64, SECT_4K),
+ INFO("m25px32-s0", 0x207316, 0, 64 * 1024, 64, SECT_4K),
+ INFO("m25px32-s1", 0x206316, 0, 64 * 1024, 64, SECT_4K),
+ INFO("m25px64", 0x207117, 0, 64 * 1024, 128, 0),
/* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
- { "w25x10", INFO(0xef3011, 0, 64 * 1024, 2, SECT_4K) },
- { "w25x20", INFO(0xef3012, 0, 64 * 1024, 4, SECT_4K) },
- { "w25x40", INFO(0xef3013, 0, 64 * 1024, 8, SECT_4K) },
- { "w25x80", INFO(0xef3014, 0, 64 * 1024, 16, SECT_4K) },
- { "w25x16", INFO(0xef3015, 0, 64 * 1024, 32, SECT_4K) },
- { "w25x32", INFO(0xef3016, 0, 64 * 1024, 64, SECT_4K) },
- { "w25q32", INFO(0xef4016, 0, 64 * 1024, 64, SECT_4K) },
- { "w25q32dw", INFO(0xef6016, 0, 64 * 1024, 64, SECT_4K) },
- { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
- { "w25q64", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
- { "w25q80", INFO(0xef5014, 0, 64 * 1024, 16, SECT_4K) },
- { "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
- { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
- { "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K) },
+ INFO("w25x10", 0xef3011, 0, 64 * 1024, 2, SECT_4K),
+ INFO("w25x20", 0xef3012, 0, 64 * 1024, 4, SECT_4K),
+ INFO("w25x40", 0xef3013, 0, 64 * 1024, 8, SECT_4K),
+ INFO("w25x80", 0xef3014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("w25x16", 0xef3015, 0, 64 * 1024, 32, SECT_4K),
+ INFO("w25x32", 0xef3016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("w25q32", 0xef4016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("w25q32dw", 0xef6016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("w25x64", 0xef3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO("w25q64", 0xef4017, 0, 64 * 1024, 128, SECT_4K),
+ INFO("w25q80", 0xef5014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("w25q80bl", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("w25q128", 0xef4018, 0, 64 * 1024, 256, SECT_4K),
+ INFO("w25q256", 0xef4019, 0, 64 * 1024, 512, SECT_4K),
/* Catalyst / On Semiconductor -- non-JEDEC */
- { "cat25c11", CAT25_INFO( 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25c03", CAT25_INFO( 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25c09", CAT25_INFO( 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25c17", CAT25_INFO( 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25128", CAT25_INFO(2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
+ CAT25_INFO("cat25c11", 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25c03", 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25c09", 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25c17", 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25128", 2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
{ },
};
-static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
+static const struct flash_info *spi_nor_info_by_name(const char *name)
+{
+ const struct flash_info *info = spi_nor_info;
+
+ while (info->name[0]) {
+ if (!strcmp(name, info->name))
+ return info;
+ info++;
+ }
+ return NULL;
+}
+
+static const struct flash_info *spi_nor_info_probe(struct spi_nor *nor)
{
int tmp;
u8 id[5];
u32 jedec;
u16 ext_jedec;
- struct flash_info *info;
+ const struct flash_info *info;
tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, 5);
if (tmp < 0) {
@@ -661,11 +675,11 @@ static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
ext_jedec = id[3] << 8 | id[4];
- for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
- info = (void *)spi_nor_ids[tmp].driver_data;
+ for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_info) - 1; tmp++) {
+ info = &spi_nor_info[tmp];
if (info->jedec_id == jedec) {
if (info->ext_id == 0 || info->ext_id == ext_jedec)
- return &spi_nor_ids[tmp];
+ return info;
}
}
dev_err(nor->dev, "unrecognized JEDEC id %06x\n", jedec);
@@ -912,8 +926,7 @@ static int spi_nor_check(struct spi_nor *nor)
int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
{
- const struct spi_device_id *id = NULL;
- struct flash_info *info;
+ const struct flash_info *info = NULL;
struct flash_platform_data *data;
struct device *dev = nor->dev;
struct mtd_info *mtd = nor->mtd;
@@ -932,26 +945,24 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
*/
data = dev_get_platdata(dev);
if (data && data->type) {
- id = spi_nor_match_id(data->type);
- if (!id)
+ info = spi_nor_info_by_name(data->type);
+ if (!info)
dev_warn(dev, "unrecognized id %s\n", data->type);
}
- if (!id && name)
- id = spi_nor_match_id(name);
+ if (!info && name)
+ info = spi_nor_info_by_name(name);
- if (!id)
+ if (!info)
return -ENODEV;
- info = (void *)id->driver_data;
-
if (info->jedec_id) {
- const struct spi_device_id *jid;
+ const struct flash_info *jinfo;
- jid = spi_nor_read_id(nor);
- if (IS_ERR(jid)) {
- return PTR_ERR(jid);
- } else if (jid != id) {
+ jinfo = spi_nor_info_probe(nor);
+ if (IS_ERR(jinfo)) {
+ return PTR_ERR(jinfo);
+ } else if (jinfo != info) {
/*
* JEDEC knows better, so overwrite platform ID. We
* can't trust partitions any longer, but we'll let
@@ -960,9 +971,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
* information, even if it's not 100% accurate.
*/
dev_warn(dev, "found %s, expected %s\n",
- jid->name, id->name);
- id = jid;
- info = (void *)jid->driver_data;
+ jinfo->name, info->name);
+ info = jinfo;
}
}
@@ -1108,7 +1118,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
nor->read_dummy = spi_nor_read_dummy_cycles(nor);
- dev_info(dev, "%s (%lld Kbytes)\n", id->name,
+ dev_info(dev, "%s (%lld Kbytes)\n", info->name,
(long long)mtd->size >> 10);
dev_dbg(dev,
@@ -1131,18 +1141,6 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
}
EXPORT_SYMBOL_GPL(spi_nor_scan);
-static const struct spi_device_id *spi_nor_match_id(const char *name)
-{
- const struct spi_device_id *id = spi_nor_ids;
-
- while (id->name[0]) {
- if (!strcmp(name, id->name))
- return id;
- id++;
- }
- return NULL;
-}
-
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Huang Shijie <shijie8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
MODULE_AUTHOR("Mike Lavender");
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 4/5] spi-nor: Replace struct spi_device_id with struct flash_info
@ 2014-09-14 17:11 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Geert Uytterhoeven, Huang Shijie, linux-arm-kernel,
debian-kernel
[-- Attachment #1: Type: text/plain, Size: 23358 bytes --]
spi-nor does not depend on the SPI layer, so its use of struct
spi_device_id adds an unnecessary indirection. Add the chip type name
to struct flash_info and remove the wrapping struct spi_device_id.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/mtd/devices/m25p80.c | 2 +-
drivers/mtd/spi-nor/spi-nor.c | 344 +++++++++++++++++++++---------------------
2 files changed, 172 insertions(+), 174 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index b547c39..271d83f 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -246,7 +246,7 @@ static int m25p_remove(struct spi_device *spi)
/*
- * XXX This needs to be kept in sync with spi_nor_ids. We can't share
+ * XXX This needs to be kept in sync with spi_nor_info. We can't share
* it with spi-nor, because if this is built as a module then modpost
* won't be able to read it and add appropriate aliases.
*/
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 40d6f70..3b88c6b 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -28,8 +28,6 @@
#define JEDEC_MFR(_jedec_id) ((_jedec_id) >> 16)
-static const struct spi_device_id *spi_nor_match_id(const char *name);
-
/*
* Read the status register, returning its value in the location
* Return the status register value.
@@ -425,6 +423,8 @@ err:
}
struct flash_info {
+ const char name[SPI_NAME_SIZE];
+
/* JEDEC id zero means "no ID" (most older chips); otherwise it has
* a high byte of zero plus three data bytes: the manufacturer id,
* then a two byte device id.
@@ -452,201 +452,215 @@ struct flash_info {
#define USE_FSR 0x80 /* use flag status register */
};
-#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
- ((kernel_ulong_t)&(struct flash_info) { \
+#define INFO(_name, _jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ { \
+ .name = (_name), \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = 256, \
.flags = (_flags), \
- })
+ }
-#define CAT25_INFO(_sector_size, _n_sectors, _page_size, _addr_width, _flags) \
- ((kernel_ulong_t)&(struct flash_info) { \
+#define CAT25_INFO(_name, _sector_size, _n_sectors, _page_size, \
+ _addr_width, _flags) \
+ { \
+ .name = (_name), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = (_page_size), \
.addr_width = (_addr_width), \
.flags = (_flags), \
- })
+ }
/* 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.
*/
-static const struct spi_device_id spi_nor_ids[] = {
+static const struct flash_info spi_nor_info[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
- { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
- { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
+ INFO("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
+ INFO("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
- { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
- { "at25df321a", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
- { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
+ INFO("at25df041a", 0x1f4401, 0, 64 * 1024, 8, SECT_4K),
+ INFO("at25df321a", 0x1f4701, 0, 64 * 1024, 64, SECT_4K),
+ INFO("at25df641", 0x1f4800, 0, 64 * 1024, 128, SECT_4K),
- { "at26f004", INFO(0x1f0400, 0, 64 * 1024, 8, SECT_4K) },
- { "at26df081a", INFO(0x1f4501, 0, 64 * 1024, 16, SECT_4K) },
- { "at26df161a", INFO(0x1f4601, 0, 64 * 1024, 32, SECT_4K) },
- { "at26df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
+ INFO("at26f004", 0x1f0400, 0, 64 * 1024, 8, SECT_4K),
+ INFO("at26df081a", 0x1f4501, 0, 64 * 1024, 16, SECT_4K),
+ INFO("at26df161a", 0x1f4601, 0, 64 * 1024, 32, SECT_4K),
+ INFO("at26df321", 0x1f4700, 0, 64 * 1024, 64, SECT_4K),
- { "at45db081d", INFO(0x1f2500, 0, 64 * 1024, 16, SECT_4K) },
+ INFO("at45db081d", 0x1f2500, 0, 64 * 1024, 16, SECT_4K),
/* EON -- en25xxx */
- { "en25f32", INFO(0x1c3116, 0, 64 * 1024, 64, SECT_4K) },
- { "en25p32", INFO(0x1c2016, 0, 64 * 1024, 64, 0) },
- { "en25q32b", INFO(0x1c3016, 0, 64 * 1024, 64, 0) },
- { "en25p64", INFO(0x1c2017, 0, 64 * 1024, 128, 0) },
- { "en25q64", INFO(0x1c3017, 0, 64 * 1024, 128, SECT_4K) },
- { "en25qh128", INFO(0x1c7018, 0, 64 * 1024, 256, 0) },
- { "en25qh256", INFO(0x1c7019, 0, 64 * 1024, 512, 0) },
+ INFO("en25f32", 0x1c3116, 0, 64 * 1024, 64, SECT_4K),
+ INFO("en25p32", 0x1c2016, 0, 64 * 1024, 64, 0),
+ INFO("en25q32b", 0x1c3016, 0, 64 * 1024, 64, 0),
+ INFO("en25p64", 0x1c2017, 0, 64 * 1024, 128, 0),
+ INFO("en25q64", 0x1c3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO("en25qh128", 0x1c7018, 0, 64 * 1024, 256, 0),
+ INFO("en25qh256", 0x1c7019, 0, 64 * 1024, 512, 0),
/* ESMT */
- { "f25l32pa", INFO(0x8c2016, 0, 64 * 1024, 64, SECT_4K) },
+ INFO("f25l32pa", 0x8c2016, 0, 64 * 1024, 64, SECT_4K),
/* Everspin */
- { "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "mr25h10", CAT25_INFO(128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
+ CAT25_INFO("mr25h256", 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("mr25h10", 128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
/* GigaDevice */
- { "gd25q32", INFO(0xc84016, 0, 64 * 1024, 64, SECT_4K) },
- { "gd25q64", INFO(0xc84017, 0, 64 * 1024, 128, SECT_4K) },
+ INFO("gd25q32", 0xc84016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("gd25q64", 0xc84017, 0, 64 * 1024, 128, SECT_4K),
/* Intel/Numonyx -- xxxs33b */
- { "160s33b", INFO(0x898911, 0, 64 * 1024, 32, 0) },
- { "320s33b", INFO(0x898912, 0, 64 * 1024, 64, 0) },
- { "640s33b", INFO(0x898913, 0, 64 * 1024, 128, 0) },
+ INFO("160s33b", 0x898911, 0, 64 * 1024, 32, 0),
+ INFO("320s33b", 0x898912, 0, 64 * 1024, 64, 0),
+ INFO("640s33b", 0x898913, 0, 64 * 1024, 128, 0),
/* Macronix */
- { "mx25l2005a", INFO(0xc22012, 0, 64 * 1024, 4, SECT_4K) },
- { "mx25l4005a", INFO(0xc22013, 0, 64 * 1024, 8, SECT_4K) },
- { "mx25l8005", INFO(0xc22014, 0, 64 * 1024, 16, 0) },
- { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32, SECT_4K) },
- { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, 0) },
- { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64, SECT_4K) },
- { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, 0) },
- { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
- { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
- { "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512, 0) },
- { "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
- { "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ) },
- { "mx66l1g55g", INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) },
+ INFO("mx25l2005a", 0xc22012, 0, 64 * 1024, 4, SECT_4K),
+ INFO("mx25l4005a", 0xc22013, 0, 64 * 1024, 8, SECT_4K),
+ INFO("mx25l8005", 0xc22014, 0, 64 * 1024, 16, 0),
+ INFO("mx25l1606e", 0xc22015, 0, 64 * 1024, 32, SECT_4K),
+ INFO("mx25l3205d", 0xc22016, 0, 64 * 1024, 64, 0),
+ INFO("mx25l3255e", 0xc29e16, 0, 64 * 1024, 64, SECT_4K),
+ INFO("mx25l6405d", 0xc22017, 0, 64 * 1024, 128, 0),
+ INFO("mx25l12805d", 0xc22018, 0, 64 * 1024, 256, 0),
+ INFO("mx25l12855e", 0xc22618, 0, 64 * 1024, 256, 0),
+ INFO("mx25l25635e", 0xc22019, 0, 64 * 1024, 512, 0),
+ INFO("mx25l25655e", 0xc22619, 0, 64 * 1024, 512, 0),
+ INFO("mx66l51235l", 0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ),
+ INFO("mx66l1g55g", 0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ),
/* Micron */
- { "n25q064", INFO(0x20ba17, 0, 64 * 1024, 128, 0) },
- { "n25q128a11", INFO(0x20bb18, 0, 64 * 1024, 256, 0) },
- { "n25q128a13", INFO(0x20ba18, 0, 64 * 1024, 256, 0) },
- { "n25q256a", INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
- { "n25q512a", INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
- { "n25q512ax3", INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
- { "n25q00", INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
+ INFO("n25q064", 0x20ba17, 0, 64 * 1024, 128, 0),
+ INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, 0),
+ INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, 0),
+ INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K),
+ INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K),
+ INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, USE_FSR),
+ INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, USE_FSR),
/* PMC */
- { "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) },
- { "pm25lv010", INFO(0, 0, 32 * 1024, 4, SECT_4K_PMC) },
- { "pm25lq032", INFO(0x7f9d46, 0, 64 * 1024, 64, SECT_4K) },
+ INFO("pm25lv512", 0, 0, 32 * 1024, 2, SECT_4K_PMC),
+ INFO("pm25lv010", 0, 0, 32 * 1024, 4, SECT_4K_PMC),
+ INFO("pm25lq032", 0x7f9d46, 0, 64 * 1024, 64, SECT_4K),
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128, 0) },
- { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
- { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "s70fl01gs", INFO(0x010221, 0x4d00, 256 * 1024, 256, 0) },
- { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
- { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
- { "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024, 64, 0) },
- { "s25fl129p1", INFO(0x012018, 0x4d01, 64 * 1024, 256, 0) },
- { "s25sl004a", INFO(0x010212, 0, 64 * 1024, 8, 0) },
- { "s25sl008a", INFO(0x010213, 0, 64 * 1024, 16, 0) },
- { "s25sl016a", INFO(0x010214, 0, 64 * 1024, 32, 0) },
- { "s25sl032a", INFO(0x010215, 0, 64 * 1024, 64, 0) },
- { "s25sl064a", INFO(0x010216, 0, 64 * 1024, 128, 0) },
- { "s25fl008k", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
- { "s25fl016k", INFO(0xef4015, 0, 64 * 1024, 32, SECT_4K) },
- { "s25fl064k", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
+ INFO("s25sl032p", 0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO("s25sl064p", 0x010216, 0x4d00, 64 * 1024, 128, 0),
+ INFO("s25fl256s0", 0x010219, 0x4d00, 256 * 1024, 128, 0),
+ INFO("s25fl256s1", 0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO("s25fl512s", 0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO("s70fl01gs", 0x010221, 0x4d00, 256 * 1024, 256, 0),
+ INFO("s25sl12800", 0x012018, 0x0300, 256 * 1024, 64, 0),
+ INFO("s25sl12801", 0x012018, 0x0301, 64 * 1024, 256, 0),
+ INFO("s25fl129p0", 0x012018, 0x4d00, 256 * 1024, 64, 0),
+ INFO("s25fl129p1", 0x012018, 0x4d01, 64 * 1024, 256, 0),
+ INFO("s25sl004a", 0x010212, 0, 64 * 1024, 8, 0),
+ INFO("s25sl008a", 0x010213, 0, 64 * 1024, 16, 0),
+ INFO("s25sl016a", 0x010214, 0, 64 * 1024, 32, 0),
+ INFO("s25sl032a", 0x010215, 0, 64 * 1024, 64, 0),
+ INFO("s25sl064a", 0x010216, 0, 64 * 1024, 128, 0),
+ INFO("s25fl008k", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("s25fl016k", 0xef4015, 0, 64 * 1024, 32, SECT_4K),
+ INFO("s25fl064k", 0xef4017, 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) },
- { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) },
- { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) },
- { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
- { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
- { "sst25wf512", INFO(0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE) },
- { "sst25wf010", INFO(0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE) },
- { "sst25wf020", INFO(0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE) },
- { "sst25wf040", INFO(0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) },
+ INFO("sst25vf040b", 0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
+ INFO("sst25vf080b", 0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE),
+ INFO("sst25vf016b", 0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE),
+ INFO("sst25vf032b", 0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE),
+ INFO("sst25vf064c", 0xbf254b, 0, 64 * 1024, 128, SECT_4K),
+ INFO("sst25wf512", 0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE),
+ INFO("sst25wf010", 0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE),
+ INFO("sst25wf020", 0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE),
+ INFO("sst25wf040", 0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
/* ST Microelectronics -- newer production may have feature updates */
- { "m25p05", INFO(0x202010, 0, 32 * 1024, 2, 0) },
- { "m25p10", INFO(0x202011, 0, 32 * 1024, 4, 0) },
- { "m25p20", INFO(0x202012, 0, 64 * 1024, 4, 0) },
- { "m25p40", INFO(0x202013, 0, 64 * 1024, 8, 0) },
- { "m25p80", INFO(0x202014, 0, 64 * 1024, 16, 0) },
- { "m25p16", INFO(0x202015, 0, 64 * 1024, 32, 0) },
- { "m25p32", INFO(0x202016, 0, 64 * 1024, 64, 0) },
- { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
- { "m25p128", INFO(0x202018, 0, 256 * 1024, 64, 0) },
- { "n25q032", INFO(0x20ba16, 0, 64 * 1024, 64, 0) },
-
- { "m25p05-nonjedec", INFO(0, 0, 32 * 1024, 2, 0) },
- { "m25p10-nonjedec", INFO(0, 0, 32 * 1024, 4, 0) },
- { "m25p20-nonjedec", INFO(0, 0, 64 * 1024, 4, 0) },
- { "m25p40-nonjedec", INFO(0, 0, 64 * 1024, 8, 0) },
- { "m25p80-nonjedec", INFO(0, 0, 64 * 1024, 16, 0) },
- { "m25p16-nonjedec", INFO(0, 0, 64 * 1024, 32, 0) },
- { "m25p32-nonjedec", INFO(0, 0, 64 * 1024, 64, 0) },
- { "m25p64-nonjedec", INFO(0, 0, 64 * 1024, 128, 0) },
- { "m25p128-nonjedec", INFO(0, 0, 256 * 1024, 64, 0) },
-
- { "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 0) },
- { "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 0) },
- { "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 0) },
-
- { "m25pe20", INFO(0x208012, 0, 64 * 1024, 4, 0) },
- { "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 0) },
- { "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, SECT_4K) },
-
- { "m25px16", INFO(0x207115, 0, 64 * 1024, 32, SECT_4K) },
- { "m25px32", INFO(0x207116, 0, 64 * 1024, 64, SECT_4K) },
- { "m25px32-s0", INFO(0x207316, 0, 64 * 1024, 64, SECT_4K) },
- { "m25px32-s1", INFO(0x206316, 0, 64 * 1024, 64, SECT_4K) },
- { "m25px64", INFO(0x207117, 0, 64 * 1024, 128, 0) },
- { "m25px80", INFO(0x207114, 0, 64 * 1024, 16, 0) },
+ INFO("m25p05", 0x202010, 0, 32 * 1024, 2, 0),
+ INFO("m25p10", 0x202011, 0, 32 * 1024, 4, 0),
+ INFO("m25p20", 0x202012, 0, 64 * 1024, 4, 0),
+ INFO("m25p40", 0x202013, 0, 64 * 1024, 8, 0),
+ INFO("m25p80", 0x202014, 0, 64 * 1024, 16, 0),
+ INFO("m25p16", 0x202015, 0, 64 * 1024, 32, 0),
+ INFO("m25p32", 0x202016, 0, 64 * 1024, 64, 0),
+ INFO("m25p64", 0x202017, 0, 64 * 1024, 128, 0),
+ INFO("m25p128", 0x202018, 0, 256 * 1024, 64, 0),
+ INFO("n25q032", 0x20ba16, 0, 64 * 1024, 64, 0),
+
+ INFO("m25p05-nonjedec", 0, 0, 32 * 1024, 2, 0),
+ INFO("m25p10-nonjedec", 0, 0, 32 * 1024, 4, 0),
+ INFO("m25p20-nonjedec", 0, 0, 64 * 1024, 4, 0),
+ INFO("m25p40-nonjedec", 0, 0, 64 * 1024, 8, 0),
+ INFO("m25p80-nonjedec", 0, 0, 64 * 1024, 16, 0),
+ INFO("m25p16-nonjedec", 0, 0, 64 * 1024, 32, 0),
+ INFO("m25p32-nonjedec", 0, 0, 64 * 1024, 64, 0),
+ INFO("m25p64-nonjedec", 0, 0, 64 * 1024, 128, 0),
+ INFO("m25p128-nonjedec", 0, 0, 256 * 1024, 64, 0),
+
+ INFO("m45pe10", 0x204011, 0, 64 * 1024, 2, 0),
+ INFO("m45pe80", 0x204014, 0, 64 * 1024, 16, 0),
+ INFO("m45pe16", 0x204015, 0, 64 * 1024, 32, 0),
+
+ INFO("m25pe20", 0x208012, 0, 64 * 1024, 4, 0),
+ INFO("m25pe80", 0x208014, 0, 64 * 1024, 16, 0),
+ INFO("m25pe16", 0x208015, 0, 64 * 1024, 32, SECT_4K),
+
+ INFO("m25px16", 0x207115, 0, 64 * 1024, 32, SECT_4K),
+ INFO("m25px32", 0x207116, 0, 64 * 1024, 64, SECT_4K),
+ INFO("m25px32-s0", 0x207316, 0, 64 * 1024, 64, SECT_4K),
+ INFO("m25px32-s1", 0x206316, 0, 64 * 1024, 64, SECT_4K),
+ INFO("m25px64", 0x207117, 0, 64 * 1024, 128, 0),
/* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
- { "w25x10", INFO(0xef3011, 0, 64 * 1024, 2, SECT_4K) },
- { "w25x20", INFO(0xef3012, 0, 64 * 1024, 4, SECT_4K) },
- { "w25x40", INFO(0xef3013, 0, 64 * 1024, 8, SECT_4K) },
- { "w25x80", INFO(0xef3014, 0, 64 * 1024, 16, SECT_4K) },
- { "w25x16", INFO(0xef3015, 0, 64 * 1024, 32, SECT_4K) },
- { "w25x32", INFO(0xef3016, 0, 64 * 1024, 64, SECT_4K) },
- { "w25q32", INFO(0xef4016, 0, 64 * 1024, 64, SECT_4K) },
- { "w25q32dw", INFO(0xef6016, 0, 64 * 1024, 64, SECT_4K) },
- { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
- { "w25q64", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
- { "w25q80", INFO(0xef5014, 0, 64 * 1024, 16, SECT_4K) },
- { "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
- { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
- { "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K) },
+ INFO("w25x10", 0xef3011, 0, 64 * 1024, 2, SECT_4K),
+ INFO("w25x20", 0xef3012, 0, 64 * 1024, 4, SECT_4K),
+ INFO("w25x40", 0xef3013, 0, 64 * 1024, 8, SECT_4K),
+ INFO("w25x80", 0xef3014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("w25x16", 0xef3015, 0, 64 * 1024, 32, SECT_4K),
+ INFO("w25x32", 0xef3016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("w25q32", 0xef4016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("w25q32dw", 0xef6016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("w25x64", 0xef3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO("w25q64", 0xef4017, 0, 64 * 1024, 128, SECT_4K),
+ INFO("w25q80", 0xef5014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("w25q80bl", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("w25q128", 0xef4018, 0, 64 * 1024, 256, SECT_4K),
+ INFO("w25q256", 0xef4019, 0, 64 * 1024, 512, SECT_4K),
/* Catalyst / On Semiconductor -- non-JEDEC */
- { "cat25c11", CAT25_INFO( 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25c03", CAT25_INFO( 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25c09", CAT25_INFO( 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25c17", CAT25_INFO( 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25128", CAT25_INFO(2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
+ CAT25_INFO("cat25c11", 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25c03", 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25c09", 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25c17", 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25128", 2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
{ },
};
-static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
+static const struct flash_info *spi_nor_info_by_name(const char *name)
+{
+ const struct flash_info *info = spi_nor_info;
+
+ while (info->name[0]) {
+ if (!strcmp(name, info->name))
+ return info;
+ info++;
+ }
+ return NULL;
+}
+
+static const struct flash_info *spi_nor_info_probe(struct spi_nor *nor)
{
int tmp;
u8 id[5];
u32 jedec;
u16 ext_jedec;
- struct flash_info *info;
+ const struct flash_info *info;
tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, 5);
if (tmp < 0) {
@@ -661,11 +675,11 @@ static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
ext_jedec = id[3] << 8 | id[4];
- for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
- info = (void *)spi_nor_ids[tmp].driver_data;
+ for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_info) - 1; tmp++) {
+ info = &spi_nor_info[tmp];
if (info->jedec_id == jedec) {
if (info->ext_id == 0 || info->ext_id == ext_jedec)
- return &spi_nor_ids[tmp];
+ return info;
}
}
dev_err(nor->dev, "unrecognized JEDEC id %06x\n", jedec);
@@ -912,8 +926,7 @@ static int spi_nor_check(struct spi_nor *nor)
int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
{
- const struct spi_device_id *id = NULL;
- struct flash_info *info;
+ const struct flash_info *info = NULL;
struct flash_platform_data *data;
struct device *dev = nor->dev;
struct mtd_info *mtd = nor->mtd;
@@ -932,26 +945,24 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
*/
data = dev_get_platdata(dev);
if (data && data->type) {
- id = spi_nor_match_id(data->type);
- if (!id)
+ info = spi_nor_info_by_name(data->type);
+ if (!info)
dev_warn(dev, "unrecognized id %s\n", data->type);
}
- if (!id && name)
- id = spi_nor_match_id(name);
+ if (!info && name)
+ info = spi_nor_info_by_name(name);
- if (!id)
+ if (!info)
return -ENODEV;
- info = (void *)id->driver_data;
-
if (info->jedec_id) {
- const struct spi_device_id *jid;
+ const struct flash_info *jinfo;
- jid = spi_nor_read_id(nor);
- if (IS_ERR(jid)) {
- return PTR_ERR(jid);
- } else if (jid != id) {
+ jinfo = spi_nor_info_probe(nor);
+ if (IS_ERR(jinfo)) {
+ return PTR_ERR(jinfo);
+ } else if (jinfo != info) {
/*
* JEDEC knows better, so overwrite platform ID. We
* can't trust partitions any longer, but we'll let
@@ -960,9 +971,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
* information, even if it's not 100% accurate.
*/
dev_warn(dev, "found %s, expected %s\n",
- jid->name, id->name);
- id = jid;
- info = (void *)jid->driver_data;
+ jinfo->name, info->name);
+ info = jinfo;
}
}
@@ -1108,7 +1118,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
nor->read_dummy = spi_nor_read_dummy_cycles(nor);
- dev_info(dev, "%s (%lld Kbytes)\n", id->name,
+ dev_info(dev, "%s (%lld Kbytes)\n", info->name,
(long long)mtd->size >> 10);
dev_dbg(dev,
@@ -1131,18 +1141,6 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
}
EXPORT_SYMBOL_GPL(spi_nor_scan);
-static const struct spi_device_id *spi_nor_match_id(const char *name)
-{
- const struct spi_device_id *id = spi_nor_ids;
-
- while (id->name[0]) {
- if (!strcmp(name, id->name))
- return id;
- id++;
- }
- return NULL;
-}
-
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Huang Shijie <shijie8@gmail.com>");
MODULE_AUTHOR("Mike Lavender");
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 4/5] spi-nor: Replace struct spi_device_id with struct flash_info
@ 2014-09-14 17:11 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: linux-arm-kernel
spi-nor does not depend on the SPI layer, so its use of struct
spi_device_id adds an unnecessary indirection. Add the chip type name
to struct flash_info and remove the wrapping struct spi_device_id.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/mtd/devices/m25p80.c | 2 +-
drivers/mtd/spi-nor/spi-nor.c | 344 +++++++++++++++++++++---------------------
2 files changed, 172 insertions(+), 174 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index b547c39..271d83f 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -246,7 +246,7 @@ static int m25p_remove(struct spi_device *spi)
/*
- * XXX This needs to be kept in sync with spi_nor_ids. We can't share
+ * XXX This needs to be kept in sync with spi_nor_info. We can't share
* it with spi-nor, because if this is built as a module then modpost
* won't be able to read it and add appropriate aliases.
*/
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 40d6f70..3b88c6b 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -28,8 +28,6 @@
#define JEDEC_MFR(_jedec_id) ((_jedec_id) >> 16)
-static const struct spi_device_id *spi_nor_match_id(const char *name);
-
/*
* Read the status register, returning its value in the location
* Return the status register value.
@@ -425,6 +423,8 @@ err:
}
struct flash_info {
+ const char name[SPI_NAME_SIZE];
+
/* JEDEC id zero means "no ID" (most older chips); otherwise it has
* a high byte of zero plus three data bytes: the manufacturer id,
* then a two byte device id.
@@ -452,201 +452,215 @@ struct flash_info {
#define USE_FSR 0x80 /* use flag status register */
};
-#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
- ((kernel_ulong_t)&(struct flash_info) { \
+#define INFO(_name, _jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ { \
+ .name = (_name), \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = 256, \
.flags = (_flags), \
- })
+ }
-#define CAT25_INFO(_sector_size, _n_sectors, _page_size, _addr_width, _flags) \
- ((kernel_ulong_t)&(struct flash_info) { \
+#define CAT25_INFO(_name, _sector_size, _n_sectors, _page_size, \
+ _addr_width, _flags) \
+ { \
+ .name = (_name), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = (_page_size), \
.addr_width = (_addr_width), \
.flags = (_flags), \
- })
+ }
/* 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.
*/
-static const struct spi_device_id spi_nor_ids[] = {
+static const struct flash_info spi_nor_info[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
- { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
- { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
+ INFO("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
+ INFO("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
- { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
- { "at25df321a", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
- { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
+ INFO("at25df041a", 0x1f4401, 0, 64 * 1024, 8, SECT_4K),
+ INFO("at25df321a", 0x1f4701, 0, 64 * 1024, 64, SECT_4K),
+ INFO("at25df641", 0x1f4800, 0, 64 * 1024, 128, SECT_4K),
- { "at26f004", INFO(0x1f0400, 0, 64 * 1024, 8, SECT_4K) },
- { "at26df081a", INFO(0x1f4501, 0, 64 * 1024, 16, SECT_4K) },
- { "at26df161a", INFO(0x1f4601, 0, 64 * 1024, 32, SECT_4K) },
- { "at26df321", INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
+ INFO("at26f004", 0x1f0400, 0, 64 * 1024, 8, SECT_4K),
+ INFO("at26df081a", 0x1f4501, 0, 64 * 1024, 16, SECT_4K),
+ INFO("at26df161a", 0x1f4601, 0, 64 * 1024, 32, SECT_4K),
+ INFO("at26df321", 0x1f4700, 0, 64 * 1024, 64, SECT_4K),
- { "at45db081d", INFO(0x1f2500, 0, 64 * 1024, 16, SECT_4K) },
+ INFO("at45db081d", 0x1f2500, 0, 64 * 1024, 16, SECT_4K),
/* EON -- en25xxx */
- { "en25f32", INFO(0x1c3116, 0, 64 * 1024, 64, SECT_4K) },
- { "en25p32", INFO(0x1c2016, 0, 64 * 1024, 64, 0) },
- { "en25q32b", INFO(0x1c3016, 0, 64 * 1024, 64, 0) },
- { "en25p64", INFO(0x1c2017, 0, 64 * 1024, 128, 0) },
- { "en25q64", INFO(0x1c3017, 0, 64 * 1024, 128, SECT_4K) },
- { "en25qh128", INFO(0x1c7018, 0, 64 * 1024, 256, 0) },
- { "en25qh256", INFO(0x1c7019, 0, 64 * 1024, 512, 0) },
+ INFO("en25f32", 0x1c3116, 0, 64 * 1024, 64, SECT_4K),
+ INFO("en25p32", 0x1c2016, 0, 64 * 1024, 64, 0),
+ INFO("en25q32b", 0x1c3016, 0, 64 * 1024, 64, 0),
+ INFO("en25p64", 0x1c2017, 0, 64 * 1024, 128, 0),
+ INFO("en25q64", 0x1c3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO("en25qh128", 0x1c7018, 0, 64 * 1024, 256, 0),
+ INFO("en25qh256", 0x1c7019, 0, 64 * 1024, 512, 0),
/* ESMT */
- { "f25l32pa", INFO(0x8c2016, 0, 64 * 1024, 64, SECT_4K) },
+ INFO("f25l32pa", 0x8c2016, 0, 64 * 1024, 64, SECT_4K),
/* Everspin */
- { "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "mr25h10", CAT25_INFO(128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
+ CAT25_INFO("mr25h256", 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("mr25h10", 128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
/* GigaDevice */
- { "gd25q32", INFO(0xc84016, 0, 64 * 1024, 64, SECT_4K) },
- { "gd25q64", INFO(0xc84017, 0, 64 * 1024, 128, SECT_4K) },
+ INFO("gd25q32", 0xc84016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("gd25q64", 0xc84017, 0, 64 * 1024, 128, SECT_4K),
/* Intel/Numonyx -- xxxs33b */
- { "160s33b", INFO(0x898911, 0, 64 * 1024, 32, 0) },
- { "320s33b", INFO(0x898912, 0, 64 * 1024, 64, 0) },
- { "640s33b", INFO(0x898913, 0, 64 * 1024, 128, 0) },
+ INFO("160s33b", 0x898911, 0, 64 * 1024, 32, 0),
+ INFO("320s33b", 0x898912, 0, 64 * 1024, 64, 0),
+ INFO("640s33b", 0x898913, 0, 64 * 1024, 128, 0),
/* Macronix */
- { "mx25l2005a", INFO(0xc22012, 0, 64 * 1024, 4, SECT_4K) },
- { "mx25l4005a", INFO(0xc22013, 0, 64 * 1024, 8, SECT_4K) },
- { "mx25l8005", INFO(0xc22014, 0, 64 * 1024, 16, 0) },
- { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32, SECT_4K) },
- { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, 0) },
- { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64, SECT_4K) },
- { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, 0) },
- { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
- { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
- { "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512, 0) },
- { "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
- { "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ) },
- { "mx66l1g55g", INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) },
+ INFO("mx25l2005a", 0xc22012, 0, 64 * 1024, 4, SECT_4K),
+ INFO("mx25l4005a", 0xc22013, 0, 64 * 1024, 8, SECT_4K),
+ INFO("mx25l8005", 0xc22014, 0, 64 * 1024, 16, 0),
+ INFO("mx25l1606e", 0xc22015, 0, 64 * 1024, 32, SECT_4K),
+ INFO("mx25l3205d", 0xc22016, 0, 64 * 1024, 64, 0),
+ INFO("mx25l3255e", 0xc29e16, 0, 64 * 1024, 64, SECT_4K),
+ INFO("mx25l6405d", 0xc22017, 0, 64 * 1024, 128, 0),
+ INFO("mx25l12805d", 0xc22018, 0, 64 * 1024, 256, 0),
+ INFO("mx25l12855e", 0xc22618, 0, 64 * 1024, 256, 0),
+ INFO("mx25l25635e", 0xc22019, 0, 64 * 1024, 512, 0),
+ INFO("mx25l25655e", 0xc22619, 0, 64 * 1024, 512, 0),
+ INFO("mx66l51235l", 0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ),
+ INFO("mx66l1g55g", 0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ),
/* Micron */
- { "n25q064", INFO(0x20ba17, 0, 64 * 1024, 128, 0) },
- { "n25q128a11", INFO(0x20bb18, 0, 64 * 1024, 256, 0) },
- { "n25q128a13", INFO(0x20ba18, 0, 64 * 1024, 256, 0) },
- { "n25q256a", INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
- { "n25q512a", INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
- { "n25q512ax3", INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
- { "n25q00", INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
+ INFO("n25q064", 0x20ba17, 0, 64 * 1024, 128, 0),
+ INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, 0),
+ INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, 0),
+ INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K),
+ INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K),
+ INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, USE_FSR),
+ INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, USE_FSR),
/* PMC */
- { "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) },
- { "pm25lv010", INFO(0, 0, 32 * 1024, 4, SECT_4K_PMC) },
- { "pm25lq032", INFO(0x7f9d46, 0, 64 * 1024, 64, SECT_4K) },
+ INFO("pm25lv512", 0, 0, 32 * 1024, 2, SECT_4K_PMC),
+ INFO("pm25lv010", 0, 0, 32 * 1024, 4, SECT_4K_PMC),
+ INFO("pm25lq032", 0x7f9d46, 0, 64 * 1024, 64, SECT_4K),
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128, 0) },
- { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
- { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "s70fl01gs", INFO(0x010221, 0x4d00, 256 * 1024, 256, 0) },
- { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
- { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
- { "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024, 64, 0) },
- { "s25fl129p1", INFO(0x012018, 0x4d01, 64 * 1024, 256, 0) },
- { "s25sl004a", INFO(0x010212, 0, 64 * 1024, 8, 0) },
- { "s25sl008a", INFO(0x010213, 0, 64 * 1024, 16, 0) },
- { "s25sl016a", INFO(0x010214, 0, 64 * 1024, 32, 0) },
- { "s25sl032a", INFO(0x010215, 0, 64 * 1024, 64, 0) },
- { "s25sl064a", INFO(0x010216, 0, 64 * 1024, 128, 0) },
- { "s25fl008k", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
- { "s25fl016k", INFO(0xef4015, 0, 64 * 1024, 32, SECT_4K) },
- { "s25fl064k", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
+ INFO("s25sl032p", 0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO("s25sl064p", 0x010216, 0x4d00, 64 * 1024, 128, 0),
+ INFO("s25fl256s0", 0x010219, 0x4d00, 256 * 1024, 128, 0),
+ INFO("s25fl256s1", 0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO("s25fl512s", 0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO("s70fl01gs", 0x010221, 0x4d00, 256 * 1024, 256, 0),
+ INFO("s25sl12800", 0x012018, 0x0300, 256 * 1024, 64, 0),
+ INFO("s25sl12801", 0x012018, 0x0301, 64 * 1024, 256, 0),
+ INFO("s25fl129p0", 0x012018, 0x4d00, 256 * 1024, 64, 0),
+ INFO("s25fl129p1", 0x012018, 0x4d01, 64 * 1024, 256, 0),
+ INFO("s25sl004a", 0x010212, 0, 64 * 1024, 8, 0),
+ INFO("s25sl008a", 0x010213, 0, 64 * 1024, 16, 0),
+ INFO("s25sl016a", 0x010214, 0, 64 * 1024, 32, 0),
+ INFO("s25sl032a", 0x010215, 0, 64 * 1024, 64, 0),
+ INFO("s25sl064a", 0x010216, 0, 64 * 1024, 128, 0),
+ INFO("s25fl008k", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("s25fl016k", 0xef4015, 0, 64 * 1024, 32, SECT_4K),
+ INFO("s25fl064k", 0xef4017, 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) },
- { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) },
- { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) },
- { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
- { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
- { "sst25wf512", INFO(0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE) },
- { "sst25wf010", INFO(0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE) },
- { "sst25wf020", INFO(0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE) },
- { "sst25wf040", INFO(0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) },
+ INFO("sst25vf040b", 0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
+ INFO("sst25vf080b", 0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE),
+ INFO("sst25vf016b", 0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE),
+ INFO("sst25vf032b", 0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE),
+ INFO("sst25vf064c", 0xbf254b, 0, 64 * 1024, 128, SECT_4K),
+ INFO("sst25wf512", 0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE),
+ INFO("sst25wf010", 0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE),
+ INFO("sst25wf020", 0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE),
+ INFO("sst25wf040", 0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
/* ST Microelectronics -- newer production may have feature updates */
- { "m25p05", INFO(0x202010, 0, 32 * 1024, 2, 0) },
- { "m25p10", INFO(0x202011, 0, 32 * 1024, 4, 0) },
- { "m25p20", INFO(0x202012, 0, 64 * 1024, 4, 0) },
- { "m25p40", INFO(0x202013, 0, 64 * 1024, 8, 0) },
- { "m25p80", INFO(0x202014, 0, 64 * 1024, 16, 0) },
- { "m25p16", INFO(0x202015, 0, 64 * 1024, 32, 0) },
- { "m25p32", INFO(0x202016, 0, 64 * 1024, 64, 0) },
- { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
- { "m25p128", INFO(0x202018, 0, 256 * 1024, 64, 0) },
- { "n25q032", INFO(0x20ba16, 0, 64 * 1024, 64, 0) },
-
- { "m25p05-nonjedec", INFO(0, 0, 32 * 1024, 2, 0) },
- { "m25p10-nonjedec", INFO(0, 0, 32 * 1024, 4, 0) },
- { "m25p20-nonjedec", INFO(0, 0, 64 * 1024, 4, 0) },
- { "m25p40-nonjedec", INFO(0, 0, 64 * 1024, 8, 0) },
- { "m25p80-nonjedec", INFO(0, 0, 64 * 1024, 16, 0) },
- { "m25p16-nonjedec", INFO(0, 0, 64 * 1024, 32, 0) },
- { "m25p32-nonjedec", INFO(0, 0, 64 * 1024, 64, 0) },
- { "m25p64-nonjedec", INFO(0, 0, 64 * 1024, 128, 0) },
- { "m25p128-nonjedec", INFO(0, 0, 256 * 1024, 64, 0) },
-
- { "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 0) },
- { "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 0) },
- { "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 0) },
-
- { "m25pe20", INFO(0x208012, 0, 64 * 1024, 4, 0) },
- { "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 0) },
- { "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, SECT_4K) },
-
- { "m25px16", INFO(0x207115, 0, 64 * 1024, 32, SECT_4K) },
- { "m25px32", INFO(0x207116, 0, 64 * 1024, 64, SECT_4K) },
- { "m25px32-s0", INFO(0x207316, 0, 64 * 1024, 64, SECT_4K) },
- { "m25px32-s1", INFO(0x206316, 0, 64 * 1024, 64, SECT_4K) },
- { "m25px64", INFO(0x207117, 0, 64 * 1024, 128, 0) },
- { "m25px80", INFO(0x207114, 0, 64 * 1024, 16, 0) },
+ INFO("m25p05", 0x202010, 0, 32 * 1024, 2, 0),
+ INFO("m25p10", 0x202011, 0, 32 * 1024, 4, 0),
+ INFO("m25p20", 0x202012, 0, 64 * 1024, 4, 0),
+ INFO("m25p40", 0x202013, 0, 64 * 1024, 8, 0),
+ INFO("m25p80", 0x202014, 0, 64 * 1024, 16, 0),
+ INFO("m25p16", 0x202015, 0, 64 * 1024, 32, 0),
+ INFO("m25p32", 0x202016, 0, 64 * 1024, 64, 0),
+ INFO("m25p64", 0x202017, 0, 64 * 1024, 128, 0),
+ INFO("m25p128", 0x202018, 0, 256 * 1024, 64, 0),
+ INFO("n25q032", 0x20ba16, 0, 64 * 1024, 64, 0),
+
+ INFO("m25p05-nonjedec", 0, 0, 32 * 1024, 2, 0),
+ INFO("m25p10-nonjedec", 0, 0, 32 * 1024, 4, 0),
+ INFO("m25p20-nonjedec", 0, 0, 64 * 1024, 4, 0),
+ INFO("m25p40-nonjedec", 0, 0, 64 * 1024, 8, 0),
+ INFO("m25p80-nonjedec", 0, 0, 64 * 1024, 16, 0),
+ INFO("m25p16-nonjedec", 0, 0, 64 * 1024, 32, 0),
+ INFO("m25p32-nonjedec", 0, 0, 64 * 1024, 64, 0),
+ INFO("m25p64-nonjedec", 0, 0, 64 * 1024, 128, 0),
+ INFO("m25p128-nonjedec", 0, 0, 256 * 1024, 64, 0),
+
+ INFO("m45pe10", 0x204011, 0, 64 * 1024, 2, 0),
+ INFO("m45pe80", 0x204014, 0, 64 * 1024, 16, 0),
+ INFO("m45pe16", 0x204015, 0, 64 * 1024, 32, 0),
+
+ INFO("m25pe20", 0x208012, 0, 64 * 1024, 4, 0),
+ INFO("m25pe80", 0x208014, 0, 64 * 1024, 16, 0),
+ INFO("m25pe16", 0x208015, 0, 64 * 1024, 32, SECT_4K),
+
+ INFO("m25px16", 0x207115, 0, 64 * 1024, 32, SECT_4K),
+ INFO("m25px32", 0x207116, 0, 64 * 1024, 64, SECT_4K),
+ INFO("m25px32-s0", 0x207316, 0, 64 * 1024, 64, SECT_4K),
+ INFO("m25px32-s1", 0x206316, 0, 64 * 1024, 64, SECT_4K),
+ INFO("m25px64", 0x207117, 0, 64 * 1024, 128, 0),
/* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
- { "w25x10", INFO(0xef3011, 0, 64 * 1024, 2, SECT_4K) },
- { "w25x20", INFO(0xef3012, 0, 64 * 1024, 4, SECT_4K) },
- { "w25x40", INFO(0xef3013, 0, 64 * 1024, 8, SECT_4K) },
- { "w25x80", INFO(0xef3014, 0, 64 * 1024, 16, SECT_4K) },
- { "w25x16", INFO(0xef3015, 0, 64 * 1024, 32, SECT_4K) },
- { "w25x32", INFO(0xef3016, 0, 64 * 1024, 64, SECT_4K) },
- { "w25q32", INFO(0xef4016, 0, 64 * 1024, 64, SECT_4K) },
- { "w25q32dw", INFO(0xef6016, 0, 64 * 1024, 64, SECT_4K) },
- { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
- { "w25q64", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
- { "w25q80", INFO(0xef5014, 0, 64 * 1024, 16, SECT_4K) },
- { "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
- { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
- { "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K) },
+ INFO("w25x10", 0xef3011, 0, 64 * 1024, 2, SECT_4K),
+ INFO("w25x20", 0xef3012, 0, 64 * 1024, 4, SECT_4K),
+ INFO("w25x40", 0xef3013, 0, 64 * 1024, 8, SECT_4K),
+ INFO("w25x80", 0xef3014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("w25x16", 0xef3015, 0, 64 * 1024, 32, SECT_4K),
+ INFO("w25x32", 0xef3016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("w25q32", 0xef4016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("w25q32dw", 0xef6016, 0, 64 * 1024, 64, SECT_4K),
+ INFO("w25x64", 0xef3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO("w25q64", 0xef4017, 0, 64 * 1024, 128, SECT_4K),
+ INFO("w25q80", 0xef5014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("w25q80bl", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO("w25q128", 0xef4018, 0, 64 * 1024, 256, SECT_4K),
+ INFO("w25q256", 0xef4019, 0, 64 * 1024, 512, SECT_4K),
/* Catalyst / On Semiconductor -- non-JEDEC */
- { "cat25c11", CAT25_INFO( 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25c03", CAT25_INFO( 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25c09", CAT25_INFO( 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25c17", CAT25_INFO( 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
- { "cat25128", CAT25_INFO(2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
+ CAT25_INFO("cat25c11", 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25c03", 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25c09", 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25c17", 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO("cat25128", 2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
{ },
};
-static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
+static const struct flash_info *spi_nor_info_by_name(const char *name)
+{
+ const struct flash_info *info = spi_nor_info;
+
+ while (info->name[0]) {
+ if (!strcmp(name, info->name))
+ return info;
+ info++;
+ }
+ return NULL;
+}
+
+static const struct flash_info *spi_nor_info_probe(struct spi_nor *nor)
{
int tmp;
u8 id[5];
u32 jedec;
u16 ext_jedec;
- struct flash_info *info;
+ const struct flash_info *info;
tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, 5);
if (tmp < 0) {
@@ -661,11 +675,11 @@ static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
ext_jedec = id[3] << 8 | id[4];
- for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
- info = (void *)spi_nor_ids[tmp].driver_data;
+ for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_info) - 1; tmp++) {
+ info = &spi_nor_info[tmp];
if (info->jedec_id == jedec) {
if (info->ext_id == 0 || info->ext_id == ext_jedec)
- return &spi_nor_ids[tmp];
+ return info;
}
}
dev_err(nor->dev, "unrecognized JEDEC id %06x\n", jedec);
@@ -912,8 +926,7 @@ static int spi_nor_check(struct spi_nor *nor)
int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
{
- const struct spi_device_id *id = NULL;
- struct flash_info *info;
+ const struct flash_info *info = NULL;
struct flash_platform_data *data;
struct device *dev = nor->dev;
struct mtd_info *mtd = nor->mtd;
@@ -932,26 +945,24 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
*/
data = dev_get_platdata(dev);
if (data && data->type) {
- id = spi_nor_match_id(data->type);
- if (!id)
+ info = spi_nor_info_by_name(data->type);
+ if (!info)
dev_warn(dev, "unrecognized id %s\n", data->type);
}
- if (!id && name)
- id = spi_nor_match_id(name);
+ if (!info && name)
+ info = spi_nor_info_by_name(name);
- if (!id)
+ if (!info)
return -ENODEV;
- info = (void *)id->driver_data;
-
if (info->jedec_id) {
- const struct spi_device_id *jid;
+ const struct flash_info *jinfo;
- jid = spi_nor_read_id(nor);
- if (IS_ERR(jid)) {
- return PTR_ERR(jid);
- } else if (jid != id) {
+ jinfo = spi_nor_info_probe(nor);
+ if (IS_ERR(jinfo)) {
+ return PTR_ERR(jinfo);
+ } else if (jinfo != info) {
/*
* JEDEC knows better, so overwrite platform ID. We
* can't trust partitions any longer, but we'll let
@@ -960,9 +971,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
* information, even if it's not 100% accurate.
*/
dev_warn(dev, "found %s, expected %s\n",
- jid->name, id->name);
- id = jid;
- info = (void *)jid->driver_data;
+ jinfo->name, info->name);
+ info = jinfo;
}
}
@@ -1108,7 +1118,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
nor->read_dummy = spi_nor_read_dummy_cycles(nor);
- dev_info(dev, "%s (%lld Kbytes)\n", id->name,
+ dev_info(dev, "%s (%lld Kbytes)\n", info->name,
(long long)mtd->size >> 10);
dev_dbg(dev,
@@ -1131,18 +1141,6 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
}
EXPORT_SYMBOL_GPL(spi_nor_scan);
-static const struct spi_device_id *spi_nor_match_id(const char *name)
-{
- const struct spi_device_id *id = spi_nor_ids;
-
- while (id->name[0]) {
- if (!strcmp(name, id->name))
- return id;
- id++;
- }
- return NULL;
-}
-
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Huang Shijie <shijie8@gmail.com>");
MODULE_AUTHOR("Mike Lavender");
--
Ben Hutchings
The world is coming to an end. Please log off.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140914/2c9f4918/attachment-0001.sig>
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again
2014-09-14 17:10 ` Ben Hutchings
(?)
@ 2014-09-14 17:11 ` Ben Hutchings
-1 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: Brian Norris
Cc: Geert Uytterhoeven, Andrew Lunn, Jason Cooper, linux-spi,
Huang Shijie, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 25042 bytes --]
Move the list of chip type names to spi-nor.h. To avoid putting all
the chip type information there, we define this list as a macro
SPI_NOR_ENUM_TYPES() that invokes another macro SPI_NOR_ENUM_TYPE()
that must be defined to expand each name to whatever form it's needed.
In spi-nor.c, use it to define enumerators, then use the enumerators
as indices when defining spi_nor_info so that we cannot accidentally
use a name that's not on the list.
This is somewhat complicated by the fact that some names include
hyphens. SPI_NOR_ENUM_TYPE() therefore takes separate string and C
identifier parameters.
Signed-off-by: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
---
drivers/mtd/devices/m25p80.c | 47 +------
drivers/mtd/spi-nor/spi-nor.c | 287 ++++++++++++++++++++++--------------------
include/linux/mtd/spi-nor.h | 72 +++++++++++
3 files changed, 227 insertions(+), 179 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 271d83f..368eb9a 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -245,51 +245,10 @@ static int m25p_remove(struct spi_device *spi)
}
-/*
- * XXX This needs to be kept in sync with spi_nor_info. We can't share
- * it with spi-nor, because if this is built as a module then modpost
- * won't be able to read it and add appropriate aliases.
- */
static const struct spi_device_id m25p_ids[] = {
- {"at25fs010"}, {"at25fs040"}, {"at25df041a"}, {"at25df321a"},
- {"at25df641"}, {"at26f004"}, {"at26df081a"}, {"at26df161a"},
- {"at26df321"}, {"at45db081d"},
- {"en25f32"}, {"en25p32"}, {"en25q32b"}, {"en25p64"},
- {"en25q64"}, {"en25qh128"}, {"en25qh256"},
- {"f25l32pa"},
- {"mr25h256"}, {"mr25h10"},
- {"gd25q32"}, {"gd25q64"},
- {"160s33b"}, {"320s33b"}, {"640s33b"},
- {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"}, {"mx25l1606e"},
- {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
- {"mx25l12855e"},{"mx25l25635e"},{"mx25l25655e"},{"mx66l51235l"},
- {"mx66l1g55g"},
- {"n25q064"}, {"n25q128a11"}, {"n25q128a13"}, {"n25q256a"},
- {"n25q512a"}, {"n25q512ax3"}, {"n25q00"},
- {"pm25lv512"}, {"pm25lv010"}, {"pm25lq032"},
- {"s25sl032p"}, {"s25sl064p"}, {"s25fl256s0"}, {"s25fl256s1"},
- {"s25fl512s"}, {"s70fl01gs"}, {"s25sl12800"}, {"s25sl12801"},
- {"s25fl129p0"}, {"s25fl129p1"}, {"s25sl004a"}, {"s25sl008a"},
- {"s25sl016a"}, {"s25sl032a"}, {"s25sl064a"}, {"s25fl008k"},
- {"s25fl016k"}, {"s25fl064k"},
- {"sst25vf040b"},{"sst25vf080b"},{"sst25vf016b"},{"sst25vf032b"},
- {"sst25vf064c"},{"sst25wf512"}, {"sst25wf010"}, {"sst25wf020"},
- {"sst25wf040"},
- {"m25p05"}, {"m25p10"}, {"m25p20"}, {"m25p40"},
- {"m25p80"}, {"m25p16"}, {"m25p32"}, {"m25p64"},
- {"m25p128"}, {"n25q032"},
- {"m25p05-nonjedec"}, {"m25p10-nonjedec"}, {"m25p20-nonjedec"},
- {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
- {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
- {"m45pe10"}, {"m45pe80"}, {"m45pe16"},
- {"m25pe20"}, {"m25pe80"}, {"m25pe16"},
- {"m25px16"}, {"m25px32"}, {"m25px32-s0"}, {"m25px32-s1"},
- {"m25px64"},
- {"w25x10"}, {"w25x20"}, {"w25x40"}, {"w25x80"},
- {"w25x16"}, {"w25x32"}, {"w25q32"}, {"w25q32dw"},
- {"w25x64"}, {"w25q64"}, {"w25q128"}, {"w25q80"},
- {"w25q80bl"}, {"w25q128"}, {"w25q256"}, {"cat25c11"},
- {"cat25c03"}, {"cat25c09"}, {"cat25c17"}, {"cat25128"},
+#define SPI_NOR_ENUM_TYPE(s, c) { s },
+ SPI_NOR_ENUM_TYPES()
+#undef SPI_NOR_ENUM_TYPE
{ },
};
MODULE_DEVICE_TABLE(spi, m25p_ids);
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 3b88c6b..68fedce 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -452,9 +452,16 @@ struct flash_info {
#define USE_FSR 0x80 /* use flag status register */
};
+enum {
+#define SPI_NOR_ENUM_TYPE(s, c) CHIP_TYPE_ ## c,
+ SPI_NOR_ENUM_TYPES()
+#undef SPI_NOR_ENUM_TYPE
+ CHIP_TYPE_COUNT
+};
+
#define INFO(_name, _jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ [CHIP_TYPE_ ## _name] = \
{ \
- .name = (_name), \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
@@ -465,8 +472,8 @@ struct flash_info {
#define CAT25_INFO(_name, _sector_size, _n_sectors, _page_size, \
_addr_width, _flags) \
+ [CHIP_TYPE_ ## _name] = \
{ \
- .name = (_name), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = (_page_size), \
@@ -477,169 +484,179 @@ struct flash_info {
/* 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 chip type names must be added to __SPI_NOR_ENUM_TYPES in
+ * spi-nor.h before they can be used here (enforced by using the
+ * names to index this array).
*/
static const struct flash_info spi_nor_info[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
- INFO("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
- INFO("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
+ INFO(at25fs010, 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
+ INFO(at25fs040, 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
- INFO("at25df041a", 0x1f4401, 0, 64 * 1024, 8, SECT_4K),
- INFO("at25df321a", 0x1f4701, 0, 64 * 1024, 64, SECT_4K),
- INFO("at25df641", 0x1f4800, 0, 64 * 1024, 128, SECT_4K),
+ INFO(at25df041a, 0x1f4401, 0, 64 * 1024, 8, SECT_4K),
+ INFO(at25df321a, 0x1f4701, 0, 64 * 1024, 64, SECT_4K),
+ INFO(at25df641, 0x1f4800, 0, 64 * 1024, 128, SECT_4K),
- INFO("at26f004", 0x1f0400, 0, 64 * 1024, 8, SECT_4K),
- INFO("at26df081a", 0x1f4501, 0, 64 * 1024, 16, SECT_4K),
- INFO("at26df161a", 0x1f4601, 0, 64 * 1024, 32, SECT_4K),
- INFO("at26df321", 0x1f4700, 0, 64 * 1024, 64, SECT_4K),
+ INFO(at26f004, 0x1f0400, 0, 64 * 1024, 8, SECT_4K),
+ INFO(at26df081a, 0x1f4501, 0, 64 * 1024, 16, SECT_4K),
+ INFO(at26df161a, 0x1f4601, 0, 64 * 1024, 32, SECT_4K),
+ INFO(at26df321, 0x1f4700, 0, 64 * 1024, 64, SECT_4K),
- INFO("at45db081d", 0x1f2500, 0, 64 * 1024, 16, SECT_4K),
+ INFO(at45db081d, 0x1f2500, 0, 64 * 1024, 16, SECT_4K),
/* EON -- en25xxx */
- INFO("en25f32", 0x1c3116, 0, 64 * 1024, 64, SECT_4K),
- INFO("en25p32", 0x1c2016, 0, 64 * 1024, 64, 0),
- INFO("en25q32b", 0x1c3016, 0, 64 * 1024, 64, 0),
- INFO("en25p64", 0x1c2017, 0, 64 * 1024, 128, 0),
- INFO("en25q64", 0x1c3017, 0, 64 * 1024, 128, SECT_4K),
- INFO("en25qh128", 0x1c7018, 0, 64 * 1024, 256, 0),
- INFO("en25qh256", 0x1c7019, 0, 64 * 1024, 512, 0),
+ INFO(en25f32, 0x1c3116, 0, 64 * 1024, 64, SECT_4K),
+ INFO(en25p32, 0x1c2016, 0, 64 * 1024, 64, 0),
+ INFO(en25q32b, 0x1c3016, 0, 64 * 1024, 64, 0),
+ INFO(en25p64, 0x1c2017, 0, 64 * 1024, 128, 0),
+ INFO(en25q64, 0x1c3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(en25qh128, 0x1c7018, 0, 64 * 1024, 256, 0),
+ INFO(en25qh256, 0x1c7019, 0, 64 * 1024, 512, 0),
/* ESMT */
- INFO("f25l32pa", 0x8c2016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(f25l32pa, 0x8c2016, 0, 64 * 1024, 64, SECT_4K),
/* Everspin */
- CAT25_INFO("mr25h256", 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("mr25h10", 128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(mr25h256, 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(mr25h10, 128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
/* GigaDevice */
- INFO("gd25q32", 0xc84016, 0, 64 * 1024, 64, SECT_4K),
- INFO("gd25q64", 0xc84017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(gd25q32, 0xc84016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(gd25q64, 0xc84017, 0, 64 * 1024, 128, SECT_4K),
/* Intel/Numonyx -- xxxs33b */
- INFO("160s33b", 0x898911, 0, 64 * 1024, 32, 0),
- INFO("320s33b", 0x898912, 0, 64 * 1024, 64, 0),
- INFO("640s33b", 0x898913, 0, 64 * 1024, 128, 0),
+ INFO(160s33b, 0x898911, 0, 64 * 1024, 32, 0),
+ INFO(320s33b, 0x898912, 0, 64 * 1024, 64, 0),
+ INFO(640s33b, 0x898913, 0, 64 * 1024, 128, 0),
/* Macronix */
- INFO("mx25l2005a", 0xc22012, 0, 64 * 1024, 4, SECT_4K),
- INFO("mx25l4005a", 0xc22013, 0, 64 * 1024, 8, SECT_4K),
- INFO("mx25l8005", 0xc22014, 0, 64 * 1024, 16, 0),
- INFO("mx25l1606e", 0xc22015, 0, 64 * 1024, 32, SECT_4K),
- INFO("mx25l3205d", 0xc22016, 0, 64 * 1024, 64, 0),
- INFO("mx25l3255e", 0xc29e16, 0, 64 * 1024, 64, SECT_4K),
- INFO("mx25l6405d", 0xc22017, 0, 64 * 1024, 128, 0),
- INFO("mx25l12805d", 0xc22018, 0, 64 * 1024, 256, 0),
- INFO("mx25l12855e", 0xc22618, 0, 64 * 1024, 256, 0),
- INFO("mx25l25635e", 0xc22019, 0, 64 * 1024, 512, 0),
- INFO("mx25l25655e", 0xc22619, 0, 64 * 1024, 512, 0),
- INFO("mx66l51235l", 0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ),
- INFO("mx66l1g55g", 0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ),
+ INFO(mx25l2005a, 0xc22012, 0, 64 * 1024, 4, SECT_4K),
+ INFO(mx25l4005a, 0xc22013, 0, 64 * 1024, 8, SECT_4K),
+ INFO(mx25l8005, 0xc22014, 0, 64 * 1024, 16, 0),
+ INFO(mx25l1606e, 0xc22015, 0, 64 * 1024, 32, SECT_4K),
+ INFO(mx25l3205d, 0xc22016, 0, 64 * 1024, 64, 0),
+ INFO(mx25l3255e, 0xc29e16, 0, 64 * 1024, 64, SECT_4K),
+ INFO(mx25l6405d, 0xc22017, 0, 64 * 1024, 128, 0),
+ INFO(mx25l12805d, 0xc22018, 0, 64 * 1024, 256, 0),
+ INFO(mx25l12855e, 0xc22618, 0, 64 * 1024, 256, 0),
+ INFO(mx25l25635e, 0xc22019, 0, 64 * 1024, 512, 0),
+ INFO(mx25l25655e, 0xc22619, 0, 64 * 1024, 512, 0),
+ INFO(mx66l51235l, 0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ),
+ INFO(mx66l1g55g, 0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ),
/* Micron */
- INFO("n25q064", 0x20ba17, 0, 64 * 1024, 128, 0),
- INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, 0),
- INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, 0),
- INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K),
- INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K),
- INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, USE_FSR),
- INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, USE_FSR),
+ INFO(n25q064, 0x20ba17, 0, 64 * 1024, 128, 0),
+ INFO(n25q128a11, 0x20bb18, 0, 64 * 1024, 256, 0),
+ INFO(n25q128a13, 0x20ba18, 0, 64 * 1024, 256, 0),
+ INFO(n25q256a, 0x20ba19, 0, 64 * 1024, 512, SECT_4K),
+ INFO(n25q512a, 0x20bb20, 0, 64 * 1024, 1024, SECT_4K),
+ INFO(n25q512ax3, 0x20ba20, 0, 64 * 1024, 1024, USE_FSR),
+ INFO(n25q00, 0x20ba21, 0, 64 * 1024, 2048, USE_FSR),
/* PMC */
- INFO("pm25lv512", 0, 0, 32 * 1024, 2, SECT_4K_PMC),
- INFO("pm25lv010", 0, 0, 32 * 1024, 4, SECT_4K_PMC),
- INFO("pm25lq032", 0x7f9d46, 0, 64 * 1024, 64, SECT_4K),
+ INFO(pm25lv512, 0, 0, 32 * 1024, 2, SECT_4K_PMC),
+ INFO(pm25lv010, 0, 0, 32 * 1024, 4, SECT_4K_PMC),
+ INFO(pm25lq032, 0x7f9d46, 0, 64 * 1024, 64, SECT_4K),
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- INFO("s25sl032p", 0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
- INFO("s25sl064p", 0x010216, 0x4d00, 64 * 1024, 128, 0),
- INFO("s25fl256s0", 0x010219, 0x4d00, 256 * 1024, 128, 0),
- INFO("s25fl256s1", 0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
- INFO("s25fl512s", 0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
- INFO("s70fl01gs", 0x010221, 0x4d00, 256 * 1024, 256, 0),
- INFO("s25sl12800", 0x012018, 0x0300, 256 * 1024, 64, 0),
- INFO("s25sl12801", 0x012018, 0x0301, 64 * 1024, 256, 0),
- INFO("s25fl129p0", 0x012018, 0x4d00, 256 * 1024, 64, 0),
- INFO("s25fl129p1", 0x012018, 0x4d01, 64 * 1024, 256, 0),
- INFO("s25sl004a", 0x010212, 0, 64 * 1024, 8, 0),
- INFO("s25sl008a", 0x010213, 0, 64 * 1024, 16, 0),
- INFO("s25sl016a", 0x010214, 0, 64 * 1024, 32, 0),
- INFO("s25sl032a", 0x010215, 0, 64 * 1024, 64, 0),
- INFO("s25sl064a", 0x010216, 0, 64 * 1024, 128, 0),
- INFO("s25fl008k", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
- INFO("s25fl016k", 0xef4015, 0, 64 * 1024, 32, SECT_4K),
- INFO("s25fl064k", 0xef4017, 0, 64 * 1024, 128, SECT_4K),
-
- /* SST -- large erase sizes are "overlays", "sectors" are 4K */
- INFO("sst25vf040b", 0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
- INFO("sst25vf080b", 0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE),
- INFO("sst25vf016b", 0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE),
- INFO("sst25vf032b", 0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE),
- INFO("sst25vf064c", 0xbf254b, 0, 64 * 1024, 128, SECT_4K),
- INFO("sst25wf512", 0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE),
- INFO("sst25wf010", 0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE),
- INFO("sst25wf020", 0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE),
- INFO("sst25wf040", 0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
+ INFO(s25sl032p, 0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO(s25sl064p, 0x010216, 0x4d00, 64 * 1024, 128, 0),
+ INFO(s25fl256s0, 0x010219, 0x4d00, 256 * 1024, 128, 0),
+ INFO(s25fl256s1, 0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO(s25fl512s, 0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO(s70fl01gs, 0x010221, 0x4d00, 256 * 1024, 256, 0),
+ INFO(s25sl12800, 0x012018, 0x0300, 256 * 1024, 64, 0),
+ INFO(s25sl12801, 0x012018, 0x0301, 64 * 1024, 256, 0),
+ INFO(s25fl129p0, 0x012018, 0x4d00, 256 * 1024, 64, 0),
+ INFO(s25fl129p1, 0x012018, 0x4d01, 64 * 1024, 256, 0),
+ INFO(s25sl004a, 0x010212, 0, 64 * 1024, 8, 0),
+ INFO(s25sl008a, 0x010213, 0, 64 * 1024, 16, 0),
+ INFO(s25sl016a, 0x010214, 0, 64 * 1024, 32, 0),
+ INFO(s25sl032a, 0x010215, 0, 64 * 1024, 64, 0),
+ INFO(s25sl064a, 0x010216, 0, 64 * 1024, 128, 0),
+ INFO(s25fl008k, 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(s25fl016k, 0xef4015, 0, 64 * 1024, 32, SECT_4K),
+ INFO(s25fl064k, 0xef4017, 0, 64 * 1024, 128, SECT_4K),
+
+ /* SST -- large erase sizes are overlays, sectors are 4K */
+ INFO(sst25vf040b, 0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
+ INFO(sst25vf080b, 0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE),
+ INFO(sst25vf016b, 0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE),
+ INFO(sst25vf032b, 0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE),
+ INFO(sst25vf064c, 0xbf254b, 0, 64 * 1024, 128, SECT_4K),
+ INFO(sst25wf512, 0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE),
+ INFO(sst25wf010, 0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE),
+ INFO(sst25wf020, 0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE),
+ INFO(sst25wf040, 0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
/* ST Microelectronics -- newer production may have feature updates */
- INFO("m25p05", 0x202010, 0, 32 * 1024, 2, 0),
- INFO("m25p10", 0x202011, 0, 32 * 1024, 4, 0),
- INFO("m25p20", 0x202012, 0, 64 * 1024, 4, 0),
- INFO("m25p40", 0x202013, 0, 64 * 1024, 8, 0),
- INFO("m25p80", 0x202014, 0, 64 * 1024, 16, 0),
- INFO("m25p16", 0x202015, 0, 64 * 1024, 32, 0),
- INFO("m25p32", 0x202016, 0, 64 * 1024, 64, 0),
- INFO("m25p64", 0x202017, 0, 64 * 1024, 128, 0),
- INFO("m25p128", 0x202018, 0, 256 * 1024, 64, 0),
- INFO("n25q032", 0x20ba16, 0, 64 * 1024, 64, 0),
-
- INFO("m25p05-nonjedec", 0, 0, 32 * 1024, 2, 0),
- INFO("m25p10-nonjedec", 0, 0, 32 * 1024, 4, 0),
- INFO("m25p20-nonjedec", 0, 0, 64 * 1024, 4, 0),
- INFO("m25p40-nonjedec", 0, 0, 64 * 1024, 8, 0),
- INFO("m25p80-nonjedec", 0, 0, 64 * 1024, 16, 0),
- INFO("m25p16-nonjedec", 0, 0, 64 * 1024, 32, 0),
- INFO("m25p32-nonjedec", 0, 0, 64 * 1024, 64, 0),
- INFO("m25p64-nonjedec", 0, 0, 64 * 1024, 128, 0),
- INFO("m25p128-nonjedec", 0, 0, 256 * 1024, 64, 0),
-
- INFO("m45pe10", 0x204011, 0, 64 * 1024, 2, 0),
- INFO("m45pe80", 0x204014, 0, 64 * 1024, 16, 0),
- INFO("m45pe16", 0x204015, 0, 64 * 1024, 32, 0),
-
- INFO("m25pe20", 0x208012, 0, 64 * 1024, 4, 0),
- INFO("m25pe80", 0x208014, 0, 64 * 1024, 16, 0),
- INFO("m25pe16", 0x208015, 0, 64 * 1024, 32, SECT_4K),
-
- INFO("m25px16", 0x207115, 0, 64 * 1024, 32, SECT_4K),
- INFO("m25px32", 0x207116, 0, 64 * 1024, 64, SECT_4K),
- INFO("m25px32-s0", 0x207316, 0, 64 * 1024, 64, SECT_4K),
- INFO("m25px32-s1", 0x206316, 0, 64 * 1024, 64, SECT_4K),
- INFO("m25px64", 0x207117, 0, 64 * 1024, 128, 0),
-
- /* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
- INFO("w25x10", 0xef3011, 0, 64 * 1024, 2, SECT_4K),
- INFO("w25x20", 0xef3012, 0, 64 * 1024, 4, SECT_4K),
- INFO("w25x40", 0xef3013, 0, 64 * 1024, 8, SECT_4K),
- INFO("w25x80", 0xef3014, 0, 64 * 1024, 16, SECT_4K),
- INFO("w25x16", 0xef3015, 0, 64 * 1024, 32, SECT_4K),
- INFO("w25x32", 0xef3016, 0, 64 * 1024, 64, SECT_4K),
- INFO("w25q32", 0xef4016, 0, 64 * 1024, 64, SECT_4K),
- INFO("w25q32dw", 0xef6016, 0, 64 * 1024, 64, SECT_4K),
- INFO("w25x64", 0xef3017, 0, 64 * 1024, 128, SECT_4K),
- INFO("w25q64", 0xef4017, 0, 64 * 1024, 128, SECT_4K),
- INFO("w25q80", 0xef5014, 0, 64 * 1024, 16, SECT_4K),
- INFO("w25q80bl", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
- INFO("w25q128", 0xef4018, 0, 64 * 1024, 256, SECT_4K),
- INFO("w25q256", 0xef4019, 0, 64 * 1024, 512, SECT_4K),
+ INFO(m25p05, 0x202010, 0, 32 * 1024, 2, 0),
+ INFO(m25p10, 0x202011, 0, 32 * 1024, 4, 0),
+ INFO(m25p20, 0x202012, 0, 64 * 1024, 4, 0),
+ INFO(m25p40, 0x202013, 0, 64 * 1024, 8, 0),
+ INFO(m25p80, 0x202014, 0, 64 * 1024, 16, 0),
+ INFO(m25p16, 0x202015, 0, 64 * 1024, 32, 0),
+ INFO(m25p32, 0x202016, 0, 64 * 1024, 64, 0),
+ INFO(m25p64, 0x202017, 0, 64 * 1024, 128, 0),
+ INFO(m25p128, 0x202018, 0, 256 * 1024, 64, 0),
+ INFO(n25q032, 0x20ba16, 0, 64 * 1024, 64, 0),
+
+ INFO(m25p05_nonjedec, 0, 0, 32 * 1024, 2, 0),
+ INFO(m25p10_nonjedec, 0, 0, 32 * 1024, 4, 0),
+ INFO(m25p20_nonjedec, 0, 0, 64 * 1024, 4, 0),
+ INFO(m25p40_nonjedec, 0, 0, 64 * 1024, 8, 0),
+ INFO(m25p80_nonjedec, 0, 0, 64 * 1024, 16, 0),
+ INFO(m25p16_nonjedec, 0, 0, 64 * 1024, 32, 0),
+ INFO(m25p32_nonjedec, 0, 0, 64 * 1024, 64, 0),
+ INFO(m25p64_nonjedec, 0, 0, 64 * 1024, 128, 0),
+ INFO(m25p128_nonjedec, 0, 0, 256 * 1024, 64, 0),
+
+ INFO(m45pe10, 0x204011, 0, 64 * 1024, 2, 0),
+ INFO(m45pe80, 0x204014, 0, 64 * 1024, 16, 0),
+ INFO(m45pe16, 0x204015, 0, 64 * 1024, 32, 0),
+
+ INFO(m25pe20, 0x208012, 0, 64 * 1024, 4, 0),
+ INFO(m25pe80, 0x208014, 0, 64 * 1024, 16, 0),
+ INFO(m25pe16, 0x208015, 0, 64 * 1024, 32, SECT_4K),
+
+ INFO(m25px16, 0x207115, 0, 64 * 1024, 32, SECT_4K),
+ INFO(m25px32, 0x207116, 0, 64 * 1024, 64, SECT_4K),
+ INFO(m25px32_s0, 0x207316, 0, 64 * 1024, 64, SECT_4K),
+ INFO(m25px32_s1, 0x206316, 0, 64 * 1024, 64, SECT_4K),
+ INFO(m25px64, 0x207117, 0, 64 * 1024, 128, 0),
+
+ /* Winbond -- w25x blocks are 64K, sectors are 4KiB */
+ INFO(w25x10, 0xef3011, 0, 64 * 1024, 2, SECT_4K),
+ INFO(w25x20, 0xef3012, 0, 64 * 1024, 4, SECT_4K),
+ INFO(w25x40, 0xef3013, 0, 64 * 1024, 8, SECT_4K),
+ INFO(w25x80, 0xef3014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(w25x16, 0xef3015, 0, 64 * 1024, 32, SECT_4K),
+ INFO(w25x32, 0xef3016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(w25q32, 0xef4016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(w25q32dw, 0xef6016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(w25x64, 0xef3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(w25q64, 0xef4017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(w25q80, 0xef5014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(w25q80bl, 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(w25q128, 0xef4018, 0, 64 * 1024, 256, SECT_4K),
+ INFO(w25q256, 0xef4019, 0, 64 * 1024, 512, SECT_4K),
/* Catalyst / On Semiconductor -- non-JEDEC */
- CAT25_INFO("cat25c11", 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25c03", 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25c09", 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25c17", 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25128", 2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- { },
+ CAT25_INFO(cat25c11, 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25c03, 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25c09, 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25c17, 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25128, 2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+
+ /* Fill in name fields */
+#define SPI_NOR_ENUM_TYPE(s, c) [CHIP_TYPE_ ## c].name = s,
+ SPI_NOR_ENUM_TYPES()
+#undef SPI_NOR_ENUM_TYPE
+
+ [CHIP_TYPE_COUNT] = { },
};
static const struct flash_info *spi_nor_info_by_name(const char *name)
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 6f92b4b..03b7959 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -198,4 +198,76 @@ struct spi_nor {
*/
int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
+#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
+ c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
+ c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
+ c_id(at26df081a) c_id(at26df161a) c_id(at26df321) \
+ c_id(at45db081d) \
+ c_id(en25f32) c_id(en25p32) c_id(en25q32b) \
+ c_id(en25p64) c_id(en25q64) c_id(en25qh128) \
+ c_id(en25qh256) \
+ c_id(f25l32pa) \
+ c_id(mr25h256) c_id(mr25h10) \
+ c_id(gd25q32) c_id(gd25q64) \
+ c_id(160s33b) c_id(320s33b) c_id(640s33b) \
+ c_id(mx25l2005a) c_id(mx25l4005a) c_id(mx25l8005) \
+ c_id(mx25l1606e) c_id(mx25l3205d) c_id(mx25l3255e) \
+ c_id(mx25l6405d) c_id(mx25l12805d) c_id(mx25l12855e) \
+ c_id(mx25l25635e) c_id(mx25l25655e) c_id(mx66l51235l) \
+ c_id(mx66l1g55g) \
+ c_id(n25q064) c_id(n25q128a11) c_id(n25q128a13) \
+ c_id(n25q256a) c_id(n25q512a) c_id(n25q512ax3) \
+ c_id(n25q00) \
+ c_id(pm25lv512) c_id(pm25lv010) c_id(pm25lq032) \
+ c_id(s25sl032p) c_id(s25sl064p) c_id(s25fl256s0) \
+ c_id(s25fl256s1) c_id(s25fl512s) c_id(s70fl01gs) \
+ c_id(s25sl12800) c_id(s25sl12801) c_id(s25fl129p0) \
+ c_id(s25fl129p1) c_id(s25sl004a) c_id(s25sl008a) \
+ c_id(s25sl016a) c_id(s25sl032a) c_id(s25sl064a) \
+ c_id(s25fl008k) c_id(s25fl016k) c_id(s25fl064k) \
+ c_id(sst25vf040b) c_id(sst25vf080b) c_id(sst25vf016b) \
+ c_id(sst25vf032b) c_id(sst25vf064c) c_id(sst25wf512) \
+ c_id(sst25wf010) c_id(sst25wf020) c_id(sst25wf040) \
+ c_id(m25p05) c_id(m25p10) c_id(m25p20) \
+ c_id(m25p40) c_id(m25p80) c_id(m25p16) \
+ c_id(m25p32) c_id(m25p64) c_id(m25p128) \
+ c_id(n25q032) \
+ str_and_c_id("m25p05-nonjedec", m25p05_nonjedec) \
+ str_and_c_id("m25p10-nonjedec", m25p10_nonjedec) \
+ str_and_c_id("m25p20-nonjedec", m25p20_nonjedec) \
+ str_and_c_id("m25p40-nonjedec", m25p40_nonjedec) \
+ str_and_c_id("m25p80-nonjedec", m25p80_nonjedec) \
+ str_and_c_id("m25p16-nonjedec", m25p16_nonjedec) \
+ str_and_c_id("m25p32-nonjedec", m25p32_nonjedec) \
+ str_and_c_id("m25p64-nonjedec", m25p64_nonjedec) \
+ str_and_c_id("m25p128-nonjedec", m25p128_nonjedec) \
+ c_id(m45pe10) c_id(m45pe80) c_id(m45pe16) \
+ c_id(m25pe20) c_id(m25pe80) c_id(m25pe16) \
+ c_id(m25px16) c_id(m25px32) \
+ str_and_c_id("m25px32-s0", m25px32_s0) \
+ str_and_c_id("m25px32-s1", m25px32_s1) \
+ c_id(m25px64) \
+ c_id(w25x10) c_id(w25x20) c_id(w25x40) \
+ c_id(w25x80) c_id(w25x16) c_id(w25x32) \
+ c_id(w25q32) c_id(w25q32dw) c_id(w25x64) \
+ c_id(w25q64) c_id(w25q80) c_id(w25q80bl) \
+ c_id(w25q128) c_id(w25q256) \
+ c_id(cat25c11) c_id(cat25c03) c_id(cat25c09) \
+ c_id(cat25c17) c_id(cat25128)
+#define __SPI_NOR_ENUM_TYPE_C_ID(id) SPI_NOR_ENUM_TYPE(#id, id)
+
+/**
+ * SPI_NOR_ENUM_TYPES - invoke SPI_NOR_ENUM_TYPE() for each SPI NOR chip type
+ *
+ * This will expand to SPI_NOR_ENUM_TYPE(string, c_id) for each chip
+ * type recognised by the spi-nor library. The first argument is the
+ * string literal version of the chip type name. The second argument
+ * is a version of the name suitable for including in a C identifier,
+ * though it may begin with a digit.
+ *
+ * The caller must define SPI_NOR_ENUM_TYPE before invoking this macro.
+ */
+#define SPI_NOR_ENUM_TYPES() \
+ __SPI_NOR_ENUM_TYPES(__SPI_NOR_ENUM_TYPE_C_ID, SPI_NOR_ENUM_TYPE)
+
#endif
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again
@ 2014-09-14 17:11 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Geert Uytterhoeven, Huang Shijie, linux-arm-kernel,
debian-kernel
[-- Attachment #1: Type: text/plain, Size: 25018 bytes --]
Move the list of chip type names to spi-nor.h. To avoid putting all
the chip type information there, we define this list as a macro
SPI_NOR_ENUM_TYPES() that invokes another macro SPI_NOR_ENUM_TYPE()
that must be defined to expand each name to whatever form it's needed.
In spi-nor.c, use it to define enumerators, then use the enumerators
as indices when defining spi_nor_info so that we cannot accidentally
use a name that's not on the list.
This is somewhat complicated by the fact that some names include
hyphens. SPI_NOR_ENUM_TYPE() therefore takes separate string and C
identifier parameters.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/mtd/devices/m25p80.c | 47 +------
drivers/mtd/spi-nor/spi-nor.c | 287 ++++++++++++++++++++++--------------------
include/linux/mtd/spi-nor.h | 72 +++++++++++
3 files changed, 227 insertions(+), 179 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 271d83f..368eb9a 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -245,51 +245,10 @@ static int m25p_remove(struct spi_device *spi)
}
-/*
- * XXX This needs to be kept in sync with spi_nor_info. We can't share
- * it with spi-nor, because if this is built as a module then modpost
- * won't be able to read it and add appropriate aliases.
- */
static const struct spi_device_id m25p_ids[] = {
- {"at25fs010"}, {"at25fs040"}, {"at25df041a"}, {"at25df321a"},
- {"at25df641"}, {"at26f004"}, {"at26df081a"}, {"at26df161a"},
- {"at26df321"}, {"at45db081d"},
- {"en25f32"}, {"en25p32"}, {"en25q32b"}, {"en25p64"},
- {"en25q64"}, {"en25qh128"}, {"en25qh256"},
- {"f25l32pa"},
- {"mr25h256"}, {"mr25h10"},
- {"gd25q32"}, {"gd25q64"},
- {"160s33b"}, {"320s33b"}, {"640s33b"},
- {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"}, {"mx25l1606e"},
- {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
- {"mx25l12855e"},{"mx25l25635e"},{"mx25l25655e"},{"mx66l51235l"},
- {"mx66l1g55g"},
- {"n25q064"}, {"n25q128a11"}, {"n25q128a13"}, {"n25q256a"},
- {"n25q512a"}, {"n25q512ax3"}, {"n25q00"},
- {"pm25lv512"}, {"pm25lv010"}, {"pm25lq032"},
- {"s25sl032p"}, {"s25sl064p"}, {"s25fl256s0"}, {"s25fl256s1"},
- {"s25fl512s"}, {"s70fl01gs"}, {"s25sl12800"}, {"s25sl12801"},
- {"s25fl129p0"}, {"s25fl129p1"}, {"s25sl004a"}, {"s25sl008a"},
- {"s25sl016a"}, {"s25sl032a"}, {"s25sl064a"}, {"s25fl008k"},
- {"s25fl016k"}, {"s25fl064k"},
- {"sst25vf040b"},{"sst25vf080b"},{"sst25vf016b"},{"sst25vf032b"},
- {"sst25vf064c"},{"sst25wf512"}, {"sst25wf010"}, {"sst25wf020"},
- {"sst25wf040"},
- {"m25p05"}, {"m25p10"}, {"m25p20"}, {"m25p40"},
- {"m25p80"}, {"m25p16"}, {"m25p32"}, {"m25p64"},
- {"m25p128"}, {"n25q032"},
- {"m25p05-nonjedec"}, {"m25p10-nonjedec"}, {"m25p20-nonjedec"},
- {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
- {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
- {"m45pe10"}, {"m45pe80"}, {"m45pe16"},
- {"m25pe20"}, {"m25pe80"}, {"m25pe16"},
- {"m25px16"}, {"m25px32"}, {"m25px32-s0"}, {"m25px32-s1"},
- {"m25px64"},
- {"w25x10"}, {"w25x20"}, {"w25x40"}, {"w25x80"},
- {"w25x16"}, {"w25x32"}, {"w25q32"}, {"w25q32dw"},
- {"w25x64"}, {"w25q64"}, {"w25q128"}, {"w25q80"},
- {"w25q80bl"}, {"w25q128"}, {"w25q256"}, {"cat25c11"},
- {"cat25c03"}, {"cat25c09"}, {"cat25c17"}, {"cat25128"},
+#define SPI_NOR_ENUM_TYPE(s, c) { s },
+ SPI_NOR_ENUM_TYPES()
+#undef SPI_NOR_ENUM_TYPE
{ },
};
MODULE_DEVICE_TABLE(spi, m25p_ids);
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 3b88c6b..68fedce 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -452,9 +452,16 @@ struct flash_info {
#define USE_FSR 0x80 /* use flag status register */
};
+enum {
+#define SPI_NOR_ENUM_TYPE(s, c) CHIP_TYPE_ ## c,
+ SPI_NOR_ENUM_TYPES()
+#undef SPI_NOR_ENUM_TYPE
+ CHIP_TYPE_COUNT
+};
+
#define INFO(_name, _jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ [CHIP_TYPE_ ## _name] = \
{ \
- .name = (_name), \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
@@ -465,8 +472,8 @@ struct flash_info {
#define CAT25_INFO(_name, _sector_size, _n_sectors, _page_size, \
_addr_width, _flags) \
+ [CHIP_TYPE_ ## _name] = \
{ \
- .name = (_name), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = (_page_size), \
@@ -477,169 +484,179 @@ struct flash_info {
/* 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 chip type names must be added to __SPI_NOR_ENUM_TYPES in
+ * spi-nor.h before they can be used here (enforced by using the
+ * names to index this array).
*/
static const struct flash_info spi_nor_info[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
- INFO("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
- INFO("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
+ INFO(at25fs010, 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
+ INFO(at25fs040, 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
- INFO("at25df041a", 0x1f4401, 0, 64 * 1024, 8, SECT_4K),
- INFO("at25df321a", 0x1f4701, 0, 64 * 1024, 64, SECT_4K),
- INFO("at25df641", 0x1f4800, 0, 64 * 1024, 128, SECT_4K),
+ INFO(at25df041a, 0x1f4401, 0, 64 * 1024, 8, SECT_4K),
+ INFO(at25df321a, 0x1f4701, 0, 64 * 1024, 64, SECT_4K),
+ INFO(at25df641, 0x1f4800, 0, 64 * 1024, 128, SECT_4K),
- INFO("at26f004", 0x1f0400, 0, 64 * 1024, 8, SECT_4K),
- INFO("at26df081a", 0x1f4501, 0, 64 * 1024, 16, SECT_4K),
- INFO("at26df161a", 0x1f4601, 0, 64 * 1024, 32, SECT_4K),
- INFO("at26df321", 0x1f4700, 0, 64 * 1024, 64, SECT_4K),
+ INFO(at26f004, 0x1f0400, 0, 64 * 1024, 8, SECT_4K),
+ INFO(at26df081a, 0x1f4501, 0, 64 * 1024, 16, SECT_4K),
+ INFO(at26df161a, 0x1f4601, 0, 64 * 1024, 32, SECT_4K),
+ INFO(at26df321, 0x1f4700, 0, 64 * 1024, 64, SECT_4K),
- INFO("at45db081d", 0x1f2500, 0, 64 * 1024, 16, SECT_4K),
+ INFO(at45db081d, 0x1f2500, 0, 64 * 1024, 16, SECT_4K),
/* EON -- en25xxx */
- INFO("en25f32", 0x1c3116, 0, 64 * 1024, 64, SECT_4K),
- INFO("en25p32", 0x1c2016, 0, 64 * 1024, 64, 0),
- INFO("en25q32b", 0x1c3016, 0, 64 * 1024, 64, 0),
- INFO("en25p64", 0x1c2017, 0, 64 * 1024, 128, 0),
- INFO("en25q64", 0x1c3017, 0, 64 * 1024, 128, SECT_4K),
- INFO("en25qh128", 0x1c7018, 0, 64 * 1024, 256, 0),
- INFO("en25qh256", 0x1c7019, 0, 64 * 1024, 512, 0),
+ INFO(en25f32, 0x1c3116, 0, 64 * 1024, 64, SECT_4K),
+ INFO(en25p32, 0x1c2016, 0, 64 * 1024, 64, 0),
+ INFO(en25q32b, 0x1c3016, 0, 64 * 1024, 64, 0),
+ INFO(en25p64, 0x1c2017, 0, 64 * 1024, 128, 0),
+ INFO(en25q64, 0x1c3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(en25qh128, 0x1c7018, 0, 64 * 1024, 256, 0),
+ INFO(en25qh256, 0x1c7019, 0, 64 * 1024, 512, 0),
/* ESMT */
- INFO("f25l32pa", 0x8c2016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(f25l32pa, 0x8c2016, 0, 64 * 1024, 64, SECT_4K),
/* Everspin */
- CAT25_INFO("mr25h256", 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("mr25h10", 128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(mr25h256, 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(mr25h10, 128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
/* GigaDevice */
- INFO("gd25q32", 0xc84016, 0, 64 * 1024, 64, SECT_4K),
- INFO("gd25q64", 0xc84017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(gd25q32, 0xc84016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(gd25q64, 0xc84017, 0, 64 * 1024, 128, SECT_4K),
/* Intel/Numonyx -- xxxs33b */
- INFO("160s33b", 0x898911, 0, 64 * 1024, 32, 0),
- INFO("320s33b", 0x898912, 0, 64 * 1024, 64, 0),
- INFO("640s33b", 0x898913, 0, 64 * 1024, 128, 0),
+ INFO(160s33b, 0x898911, 0, 64 * 1024, 32, 0),
+ INFO(320s33b, 0x898912, 0, 64 * 1024, 64, 0),
+ INFO(640s33b, 0x898913, 0, 64 * 1024, 128, 0),
/* Macronix */
- INFO("mx25l2005a", 0xc22012, 0, 64 * 1024, 4, SECT_4K),
- INFO("mx25l4005a", 0xc22013, 0, 64 * 1024, 8, SECT_4K),
- INFO("mx25l8005", 0xc22014, 0, 64 * 1024, 16, 0),
- INFO("mx25l1606e", 0xc22015, 0, 64 * 1024, 32, SECT_4K),
- INFO("mx25l3205d", 0xc22016, 0, 64 * 1024, 64, 0),
- INFO("mx25l3255e", 0xc29e16, 0, 64 * 1024, 64, SECT_4K),
- INFO("mx25l6405d", 0xc22017, 0, 64 * 1024, 128, 0),
- INFO("mx25l12805d", 0xc22018, 0, 64 * 1024, 256, 0),
- INFO("mx25l12855e", 0xc22618, 0, 64 * 1024, 256, 0),
- INFO("mx25l25635e", 0xc22019, 0, 64 * 1024, 512, 0),
- INFO("mx25l25655e", 0xc22619, 0, 64 * 1024, 512, 0),
- INFO("mx66l51235l", 0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ),
- INFO("mx66l1g55g", 0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ),
+ INFO(mx25l2005a, 0xc22012, 0, 64 * 1024, 4, SECT_4K),
+ INFO(mx25l4005a, 0xc22013, 0, 64 * 1024, 8, SECT_4K),
+ INFO(mx25l8005, 0xc22014, 0, 64 * 1024, 16, 0),
+ INFO(mx25l1606e, 0xc22015, 0, 64 * 1024, 32, SECT_4K),
+ INFO(mx25l3205d, 0xc22016, 0, 64 * 1024, 64, 0),
+ INFO(mx25l3255e, 0xc29e16, 0, 64 * 1024, 64, SECT_4K),
+ INFO(mx25l6405d, 0xc22017, 0, 64 * 1024, 128, 0),
+ INFO(mx25l12805d, 0xc22018, 0, 64 * 1024, 256, 0),
+ INFO(mx25l12855e, 0xc22618, 0, 64 * 1024, 256, 0),
+ INFO(mx25l25635e, 0xc22019, 0, 64 * 1024, 512, 0),
+ INFO(mx25l25655e, 0xc22619, 0, 64 * 1024, 512, 0),
+ INFO(mx66l51235l, 0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ),
+ INFO(mx66l1g55g, 0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ),
/* Micron */
- INFO("n25q064", 0x20ba17, 0, 64 * 1024, 128, 0),
- INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, 0),
- INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, 0),
- INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K),
- INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K),
- INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, USE_FSR),
- INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, USE_FSR),
+ INFO(n25q064, 0x20ba17, 0, 64 * 1024, 128, 0),
+ INFO(n25q128a11, 0x20bb18, 0, 64 * 1024, 256, 0),
+ INFO(n25q128a13, 0x20ba18, 0, 64 * 1024, 256, 0),
+ INFO(n25q256a, 0x20ba19, 0, 64 * 1024, 512, SECT_4K),
+ INFO(n25q512a, 0x20bb20, 0, 64 * 1024, 1024, SECT_4K),
+ INFO(n25q512ax3, 0x20ba20, 0, 64 * 1024, 1024, USE_FSR),
+ INFO(n25q00, 0x20ba21, 0, 64 * 1024, 2048, USE_FSR),
/* PMC */
- INFO("pm25lv512", 0, 0, 32 * 1024, 2, SECT_4K_PMC),
- INFO("pm25lv010", 0, 0, 32 * 1024, 4, SECT_4K_PMC),
- INFO("pm25lq032", 0x7f9d46, 0, 64 * 1024, 64, SECT_4K),
+ INFO(pm25lv512, 0, 0, 32 * 1024, 2, SECT_4K_PMC),
+ INFO(pm25lv010, 0, 0, 32 * 1024, 4, SECT_4K_PMC),
+ INFO(pm25lq032, 0x7f9d46, 0, 64 * 1024, 64, SECT_4K),
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- INFO("s25sl032p", 0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
- INFO("s25sl064p", 0x010216, 0x4d00, 64 * 1024, 128, 0),
- INFO("s25fl256s0", 0x010219, 0x4d00, 256 * 1024, 128, 0),
- INFO("s25fl256s1", 0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
- INFO("s25fl512s", 0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
- INFO("s70fl01gs", 0x010221, 0x4d00, 256 * 1024, 256, 0),
- INFO("s25sl12800", 0x012018, 0x0300, 256 * 1024, 64, 0),
- INFO("s25sl12801", 0x012018, 0x0301, 64 * 1024, 256, 0),
- INFO("s25fl129p0", 0x012018, 0x4d00, 256 * 1024, 64, 0),
- INFO("s25fl129p1", 0x012018, 0x4d01, 64 * 1024, 256, 0),
- INFO("s25sl004a", 0x010212, 0, 64 * 1024, 8, 0),
- INFO("s25sl008a", 0x010213, 0, 64 * 1024, 16, 0),
- INFO("s25sl016a", 0x010214, 0, 64 * 1024, 32, 0),
- INFO("s25sl032a", 0x010215, 0, 64 * 1024, 64, 0),
- INFO("s25sl064a", 0x010216, 0, 64 * 1024, 128, 0),
- INFO("s25fl008k", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
- INFO("s25fl016k", 0xef4015, 0, 64 * 1024, 32, SECT_4K),
- INFO("s25fl064k", 0xef4017, 0, 64 * 1024, 128, SECT_4K),
-
- /* SST -- large erase sizes are "overlays", "sectors" are 4K */
- INFO("sst25vf040b", 0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
- INFO("sst25vf080b", 0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE),
- INFO("sst25vf016b", 0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE),
- INFO("sst25vf032b", 0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE),
- INFO("sst25vf064c", 0xbf254b, 0, 64 * 1024, 128, SECT_4K),
- INFO("sst25wf512", 0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE),
- INFO("sst25wf010", 0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE),
- INFO("sst25wf020", 0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE),
- INFO("sst25wf040", 0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
+ INFO(s25sl032p, 0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO(s25sl064p, 0x010216, 0x4d00, 64 * 1024, 128, 0),
+ INFO(s25fl256s0, 0x010219, 0x4d00, 256 * 1024, 128, 0),
+ INFO(s25fl256s1, 0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO(s25fl512s, 0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO(s70fl01gs, 0x010221, 0x4d00, 256 * 1024, 256, 0),
+ INFO(s25sl12800, 0x012018, 0x0300, 256 * 1024, 64, 0),
+ INFO(s25sl12801, 0x012018, 0x0301, 64 * 1024, 256, 0),
+ INFO(s25fl129p0, 0x012018, 0x4d00, 256 * 1024, 64, 0),
+ INFO(s25fl129p1, 0x012018, 0x4d01, 64 * 1024, 256, 0),
+ INFO(s25sl004a, 0x010212, 0, 64 * 1024, 8, 0),
+ INFO(s25sl008a, 0x010213, 0, 64 * 1024, 16, 0),
+ INFO(s25sl016a, 0x010214, 0, 64 * 1024, 32, 0),
+ INFO(s25sl032a, 0x010215, 0, 64 * 1024, 64, 0),
+ INFO(s25sl064a, 0x010216, 0, 64 * 1024, 128, 0),
+ INFO(s25fl008k, 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(s25fl016k, 0xef4015, 0, 64 * 1024, 32, SECT_4K),
+ INFO(s25fl064k, 0xef4017, 0, 64 * 1024, 128, SECT_4K),
+
+ /* SST -- large erase sizes are overlays, sectors are 4K */
+ INFO(sst25vf040b, 0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
+ INFO(sst25vf080b, 0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE),
+ INFO(sst25vf016b, 0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE),
+ INFO(sst25vf032b, 0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE),
+ INFO(sst25vf064c, 0xbf254b, 0, 64 * 1024, 128, SECT_4K),
+ INFO(sst25wf512, 0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE),
+ INFO(sst25wf010, 0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE),
+ INFO(sst25wf020, 0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE),
+ INFO(sst25wf040, 0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
/* ST Microelectronics -- newer production may have feature updates */
- INFO("m25p05", 0x202010, 0, 32 * 1024, 2, 0),
- INFO("m25p10", 0x202011, 0, 32 * 1024, 4, 0),
- INFO("m25p20", 0x202012, 0, 64 * 1024, 4, 0),
- INFO("m25p40", 0x202013, 0, 64 * 1024, 8, 0),
- INFO("m25p80", 0x202014, 0, 64 * 1024, 16, 0),
- INFO("m25p16", 0x202015, 0, 64 * 1024, 32, 0),
- INFO("m25p32", 0x202016, 0, 64 * 1024, 64, 0),
- INFO("m25p64", 0x202017, 0, 64 * 1024, 128, 0),
- INFO("m25p128", 0x202018, 0, 256 * 1024, 64, 0),
- INFO("n25q032", 0x20ba16, 0, 64 * 1024, 64, 0),
-
- INFO("m25p05-nonjedec", 0, 0, 32 * 1024, 2, 0),
- INFO("m25p10-nonjedec", 0, 0, 32 * 1024, 4, 0),
- INFO("m25p20-nonjedec", 0, 0, 64 * 1024, 4, 0),
- INFO("m25p40-nonjedec", 0, 0, 64 * 1024, 8, 0),
- INFO("m25p80-nonjedec", 0, 0, 64 * 1024, 16, 0),
- INFO("m25p16-nonjedec", 0, 0, 64 * 1024, 32, 0),
- INFO("m25p32-nonjedec", 0, 0, 64 * 1024, 64, 0),
- INFO("m25p64-nonjedec", 0, 0, 64 * 1024, 128, 0),
- INFO("m25p128-nonjedec", 0, 0, 256 * 1024, 64, 0),
-
- INFO("m45pe10", 0x204011, 0, 64 * 1024, 2, 0),
- INFO("m45pe80", 0x204014, 0, 64 * 1024, 16, 0),
- INFO("m45pe16", 0x204015, 0, 64 * 1024, 32, 0),
-
- INFO("m25pe20", 0x208012, 0, 64 * 1024, 4, 0),
- INFO("m25pe80", 0x208014, 0, 64 * 1024, 16, 0),
- INFO("m25pe16", 0x208015, 0, 64 * 1024, 32, SECT_4K),
-
- INFO("m25px16", 0x207115, 0, 64 * 1024, 32, SECT_4K),
- INFO("m25px32", 0x207116, 0, 64 * 1024, 64, SECT_4K),
- INFO("m25px32-s0", 0x207316, 0, 64 * 1024, 64, SECT_4K),
- INFO("m25px32-s1", 0x206316, 0, 64 * 1024, 64, SECT_4K),
- INFO("m25px64", 0x207117, 0, 64 * 1024, 128, 0),
-
- /* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
- INFO("w25x10", 0xef3011, 0, 64 * 1024, 2, SECT_4K),
- INFO("w25x20", 0xef3012, 0, 64 * 1024, 4, SECT_4K),
- INFO("w25x40", 0xef3013, 0, 64 * 1024, 8, SECT_4K),
- INFO("w25x80", 0xef3014, 0, 64 * 1024, 16, SECT_4K),
- INFO("w25x16", 0xef3015, 0, 64 * 1024, 32, SECT_4K),
- INFO("w25x32", 0xef3016, 0, 64 * 1024, 64, SECT_4K),
- INFO("w25q32", 0xef4016, 0, 64 * 1024, 64, SECT_4K),
- INFO("w25q32dw", 0xef6016, 0, 64 * 1024, 64, SECT_4K),
- INFO("w25x64", 0xef3017, 0, 64 * 1024, 128, SECT_4K),
- INFO("w25q64", 0xef4017, 0, 64 * 1024, 128, SECT_4K),
- INFO("w25q80", 0xef5014, 0, 64 * 1024, 16, SECT_4K),
- INFO("w25q80bl", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
- INFO("w25q128", 0xef4018, 0, 64 * 1024, 256, SECT_4K),
- INFO("w25q256", 0xef4019, 0, 64 * 1024, 512, SECT_4K),
+ INFO(m25p05, 0x202010, 0, 32 * 1024, 2, 0),
+ INFO(m25p10, 0x202011, 0, 32 * 1024, 4, 0),
+ INFO(m25p20, 0x202012, 0, 64 * 1024, 4, 0),
+ INFO(m25p40, 0x202013, 0, 64 * 1024, 8, 0),
+ INFO(m25p80, 0x202014, 0, 64 * 1024, 16, 0),
+ INFO(m25p16, 0x202015, 0, 64 * 1024, 32, 0),
+ INFO(m25p32, 0x202016, 0, 64 * 1024, 64, 0),
+ INFO(m25p64, 0x202017, 0, 64 * 1024, 128, 0),
+ INFO(m25p128, 0x202018, 0, 256 * 1024, 64, 0),
+ INFO(n25q032, 0x20ba16, 0, 64 * 1024, 64, 0),
+
+ INFO(m25p05_nonjedec, 0, 0, 32 * 1024, 2, 0),
+ INFO(m25p10_nonjedec, 0, 0, 32 * 1024, 4, 0),
+ INFO(m25p20_nonjedec, 0, 0, 64 * 1024, 4, 0),
+ INFO(m25p40_nonjedec, 0, 0, 64 * 1024, 8, 0),
+ INFO(m25p80_nonjedec, 0, 0, 64 * 1024, 16, 0),
+ INFO(m25p16_nonjedec, 0, 0, 64 * 1024, 32, 0),
+ INFO(m25p32_nonjedec, 0, 0, 64 * 1024, 64, 0),
+ INFO(m25p64_nonjedec, 0, 0, 64 * 1024, 128, 0),
+ INFO(m25p128_nonjedec, 0, 0, 256 * 1024, 64, 0),
+
+ INFO(m45pe10, 0x204011, 0, 64 * 1024, 2, 0),
+ INFO(m45pe80, 0x204014, 0, 64 * 1024, 16, 0),
+ INFO(m45pe16, 0x204015, 0, 64 * 1024, 32, 0),
+
+ INFO(m25pe20, 0x208012, 0, 64 * 1024, 4, 0),
+ INFO(m25pe80, 0x208014, 0, 64 * 1024, 16, 0),
+ INFO(m25pe16, 0x208015, 0, 64 * 1024, 32, SECT_4K),
+
+ INFO(m25px16, 0x207115, 0, 64 * 1024, 32, SECT_4K),
+ INFO(m25px32, 0x207116, 0, 64 * 1024, 64, SECT_4K),
+ INFO(m25px32_s0, 0x207316, 0, 64 * 1024, 64, SECT_4K),
+ INFO(m25px32_s1, 0x206316, 0, 64 * 1024, 64, SECT_4K),
+ INFO(m25px64, 0x207117, 0, 64 * 1024, 128, 0),
+
+ /* Winbond -- w25x blocks are 64K, sectors are 4KiB */
+ INFO(w25x10, 0xef3011, 0, 64 * 1024, 2, SECT_4K),
+ INFO(w25x20, 0xef3012, 0, 64 * 1024, 4, SECT_4K),
+ INFO(w25x40, 0xef3013, 0, 64 * 1024, 8, SECT_4K),
+ INFO(w25x80, 0xef3014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(w25x16, 0xef3015, 0, 64 * 1024, 32, SECT_4K),
+ INFO(w25x32, 0xef3016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(w25q32, 0xef4016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(w25q32dw, 0xef6016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(w25x64, 0xef3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(w25q64, 0xef4017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(w25q80, 0xef5014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(w25q80bl, 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(w25q128, 0xef4018, 0, 64 * 1024, 256, SECT_4K),
+ INFO(w25q256, 0xef4019, 0, 64 * 1024, 512, SECT_4K),
/* Catalyst / On Semiconductor -- non-JEDEC */
- CAT25_INFO("cat25c11", 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25c03", 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25c09", 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25c17", 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25128", 2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- { },
+ CAT25_INFO(cat25c11, 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25c03, 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25c09, 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25c17, 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25128, 2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+
+ /* Fill in name fields */
+#define SPI_NOR_ENUM_TYPE(s, c) [CHIP_TYPE_ ## c].name = s,
+ SPI_NOR_ENUM_TYPES()
+#undef SPI_NOR_ENUM_TYPE
+
+ [CHIP_TYPE_COUNT] = { },
};
static const struct flash_info *spi_nor_info_by_name(const char *name)
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 6f92b4b..03b7959 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -198,4 +198,76 @@ struct spi_nor {
*/
int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
+#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
+ c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
+ c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
+ c_id(at26df081a) c_id(at26df161a) c_id(at26df321) \
+ c_id(at45db081d) \
+ c_id(en25f32) c_id(en25p32) c_id(en25q32b) \
+ c_id(en25p64) c_id(en25q64) c_id(en25qh128) \
+ c_id(en25qh256) \
+ c_id(f25l32pa) \
+ c_id(mr25h256) c_id(mr25h10) \
+ c_id(gd25q32) c_id(gd25q64) \
+ c_id(160s33b) c_id(320s33b) c_id(640s33b) \
+ c_id(mx25l2005a) c_id(mx25l4005a) c_id(mx25l8005) \
+ c_id(mx25l1606e) c_id(mx25l3205d) c_id(mx25l3255e) \
+ c_id(mx25l6405d) c_id(mx25l12805d) c_id(mx25l12855e) \
+ c_id(mx25l25635e) c_id(mx25l25655e) c_id(mx66l51235l) \
+ c_id(mx66l1g55g) \
+ c_id(n25q064) c_id(n25q128a11) c_id(n25q128a13) \
+ c_id(n25q256a) c_id(n25q512a) c_id(n25q512ax3) \
+ c_id(n25q00) \
+ c_id(pm25lv512) c_id(pm25lv010) c_id(pm25lq032) \
+ c_id(s25sl032p) c_id(s25sl064p) c_id(s25fl256s0) \
+ c_id(s25fl256s1) c_id(s25fl512s) c_id(s70fl01gs) \
+ c_id(s25sl12800) c_id(s25sl12801) c_id(s25fl129p0) \
+ c_id(s25fl129p1) c_id(s25sl004a) c_id(s25sl008a) \
+ c_id(s25sl016a) c_id(s25sl032a) c_id(s25sl064a) \
+ c_id(s25fl008k) c_id(s25fl016k) c_id(s25fl064k) \
+ c_id(sst25vf040b) c_id(sst25vf080b) c_id(sst25vf016b) \
+ c_id(sst25vf032b) c_id(sst25vf064c) c_id(sst25wf512) \
+ c_id(sst25wf010) c_id(sst25wf020) c_id(sst25wf040) \
+ c_id(m25p05) c_id(m25p10) c_id(m25p20) \
+ c_id(m25p40) c_id(m25p80) c_id(m25p16) \
+ c_id(m25p32) c_id(m25p64) c_id(m25p128) \
+ c_id(n25q032) \
+ str_and_c_id("m25p05-nonjedec", m25p05_nonjedec) \
+ str_and_c_id("m25p10-nonjedec", m25p10_nonjedec) \
+ str_and_c_id("m25p20-nonjedec", m25p20_nonjedec) \
+ str_and_c_id("m25p40-nonjedec", m25p40_nonjedec) \
+ str_and_c_id("m25p80-nonjedec", m25p80_nonjedec) \
+ str_and_c_id("m25p16-nonjedec", m25p16_nonjedec) \
+ str_and_c_id("m25p32-nonjedec", m25p32_nonjedec) \
+ str_and_c_id("m25p64-nonjedec", m25p64_nonjedec) \
+ str_and_c_id("m25p128-nonjedec", m25p128_nonjedec) \
+ c_id(m45pe10) c_id(m45pe80) c_id(m45pe16) \
+ c_id(m25pe20) c_id(m25pe80) c_id(m25pe16) \
+ c_id(m25px16) c_id(m25px32) \
+ str_and_c_id("m25px32-s0", m25px32_s0) \
+ str_and_c_id("m25px32-s1", m25px32_s1) \
+ c_id(m25px64) \
+ c_id(w25x10) c_id(w25x20) c_id(w25x40) \
+ c_id(w25x80) c_id(w25x16) c_id(w25x32) \
+ c_id(w25q32) c_id(w25q32dw) c_id(w25x64) \
+ c_id(w25q64) c_id(w25q80) c_id(w25q80bl) \
+ c_id(w25q128) c_id(w25q256) \
+ c_id(cat25c11) c_id(cat25c03) c_id(cat25c09) \
+ c_id(cat25c17) c_id(cat25128)
+#define __SPI_NOR_ENUM_TYPE_C_ID(id) SPI_NOR_ENUM_TYPE(#id, id)
+
+/**
+ * SPI_NOR_ENUM_TYPES - invoke SPI_NOR_ENUM_TYPE() for each SPI NOR chip type
+ *
+ * This will expand to SPI_NOR_ENUM_TYPE(string, c_id) for each chip
+ * type recognised by the spi-nor library. The first argument is the
+ * string literal version of the chip type name. The second argument
+ * is a version of the name suitable for including in a C identifier,
+ * though it may begin with a digit.
+ *
+ * The caller must define SPI_NOR_ENUM_TYPE before invoking this macro.
+ */
+#define SPI_NOR_ENUM_TYPES() \
+ __SPI_NOR_ENUM_TYPES(__SPI_NOR_ENUM_TYPE_C_ID, SPI_NOR_ENUM_TYPE)
+
#endif
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again
@ 2014-09-14 17:11 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:11 UTC (permalink / raw)
To: linux-arm-kernel
Move the list of chip type names to spi-nor.h. To avoid putting all
the chip type information there, we define this list as a macro
SPI_NOR_ENUM_TYPES() that invokes another macro SPI_NOR_ENUM_TYPE()
that must be defined to expand each name to whatever form it's needed.
In spi-nor.c, use it to define enumerators, then use the enumerators
as indices when defining spi_nor_info so that we cannot accidentally
use a name that's not on the list.
This is somewhat complicated by the fact that some names include
hyphens. SPI_NOR_ENUM_TYPE() therefore takes separate string and C
identifier parameters.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/mtd/devices/m25p80.c | 47 +------
drivers/mtd/spi-nor/spi-nor.c | 287 ++++++++++++++++++++++--------------------
include/linux/mtd/spi-nor.h | 72 +++++++++++
3 files changed, 227 insertions(+), 179 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 271d83f..368eb9a 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -245,51 +245,10 @@ static int m25p_remove(struct spi_device *spi)
}
-/*
- * XXX This needs to be kept in sync with spi_nor_info. We can't share
- * it with spi-nor, because if this is built as a module then modpost
- * won't be able to read it and add appropriate aliases.
- */
static const struct spi_device_id m25p_ids[] = {
- {"at25fs010"}, {"at25fs040"}, {"at25df041a"}, {"at25df321a"},
- {"at25df641"}, {"at26f004"}, {"at26df081a"}, {"at26df161a"},
- {"at26df321"}, {"at45db081d"},
- {"en25f32"}, {"en25p32"}, {"en25q32b"}, {"en25p64"},
- {"en25q64"}, {"en25qh128"}, {"en25qh256"},
- {"f25l32pa"},
- {"mr25h256"}, {"mr25h10"},
- {"gd25q32"}, {"gd25q64"},
- {"160s33b"}, {"320s33b"}, {"640s33b"},
- {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"}, {"mx25l1606e"},
- {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
- {"mx25l12855e"},{"mx25l25635e"},{"mx25l25655e"},{"mx66l51235l"},
- {"mx66l1g55g"},
- {"n25q064"}, {"n25q128a11"}, {"n25q128a13"}, {"n25q256a"},
- {"n25q512a"}, {"n25q512ax3"}, {"n25q00"},
- {"pm25lv512"}, {"pm25lv010"}, {"pm25lq032"},
- {"s25sl032p"}, {"s25sl064p"}, {"s25fl256s0"}, {"s25fl256s1"},
- {"s25fl512s"}, {"s70fl01gs"}, {"s25sl12800"}, {"s25sl12801"},
- {"s25fl129p0"}, {"s25fl129p1"}, {"s25sl004a"}, {"s25sl008a"},
- {"s25sl016a"}, {"s25sl032a"}, {"s25sl064a"}, {"s25fl008k"},
- {"s25fl016k"}, {"s25fl064k"},
- {"sst25vf040b"},{"sst25vf080b"},{"sst25vf016b"},{"sst25vf032b"},
- {"sst25vf064c"},{"sst25wf512"}, {"sst25wf010"}, {"sst25wf020"},
- {"sst25wf040"},
- {"m25p05"}, {"m25p10"}, {"m25p20"}, {"m25p40"},
- {"m25p80"}, {"m25p16"}, {"m25p32"}, {"m25p64"},
- {"m25p128"}, {"n25q032"},
- {"m25p05-nonjedec"}, {"m25p10-nonjedec"}, {"m25p20-nonjedec"},
- {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
- {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
- {"m45pe10"}, {"m45pe80"}, {"m45pe16"},
- {"m25pe20"}, {"m25pe80"}, {"m25pe16"},
- {"m25px16"}, {"m25px32"}, {"m25px32-s0"}, {"m25px32-s1"},
- {"m25px64"},
- {"w25x10"}, {"w25x20"}, {"w25x40"}, {"w25x80"},
- {"w25x16"}, {"w25x32"}, {"w25q32"}, {"w25q32dw"},
- {"w25x64"}, {"w25q64"}, {"w25q128"}, {"w25q80"},
- {"w25q80bl"}, {"w25q128"}, {"w25q256"}, {"cat25c11"},
- {"cat25c03"}, {"cat25c09"}, {"cat25c17"}, {"cat25128"},
+#define SPI_NOR_ENUM_TYPE(s, c) { s },
+ SPI_NOR_ENUM_TYPES()
+#undef SPI_NOR_ENUM_TYPE
{ },
};
MODULE_DEVICE_TABLE(spi, m25p_ids);
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 3b88c6b..68fedce 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -452,9 +452,16 @@ struct flash_info {
#define USE_FSR 0x80 /* use flag status register */
};
+enum {
+#define SPI_NOR_ENUM_TYPE(s, c) CHIP_TYPE_ ## c,
+ SPI_NOR_ENUM_TYPES()
+#undef SPI_NOR_ENUM_TYPE
+ CHIP_TYPE_COUNT
+};
+
#define INFO(_name, _jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ [CHIP_TYPE_ ## _name] = \
{ \
- .name = (_name), \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
@@ -465,8 +472,8 @@ struct flash_info {
#define CAT25_INFO(_name, _sector_size, _n_sectors, _page_size, \
_addr_width, _flags) \
+ [CHIP_TYPE_ ## _name] = \
{ \
- .name = (_name), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = (_page_size), \
@@ -477,169 +484,179 @@ struct flash_info {
/* 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 chip type names must be added to __SPI_NOR_ENUM_TYPES in
+ * spi-nor.h before they can be used here (enforced by using the
+ * names to index this array).
*/
static const struct flash_info spi_nor_info[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
- INFO("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
- INFO("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
+ INFO(at25fs010, 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
+ INFO(at25fs040, 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
- INFO("at25df041a", 0x1f4401, 0, 64 * 1024, 8, SECT_4K),
- INFO("at25df321a", 0x1f4701, 0, 64 * 1024, 64, SECT_4K),
- INFO("at25df641", 0x1f4800, 0, 64 * 1024, 128, SECT_4K),
+ INFO(at25df041a, 0x1f4401, 0, 64 * 1024, 8, SECT_4K),
+ INFO(at25df321a, 0x1f4701, 0, 64 * 1024, 64, SECT_4K),
+ INFO(at25df641, 0x1f4800, 0, 64 * 1024, 128, SECT_4K),
- INFO("at26f004", 0x1f0400, 0, 64 * 1024, 8, SECT_4K),
- INFO("at26df081a", 0x1f4501, 0, 64 * 1024, 16, SECT_4K),
- INFO("at26df161a", 0x1f4601, 0, 64 * 1024, 32, SECT_4K),
- INFO("at26df321", 0x1f4700, 0, 64 * 1024, 64, SECT_4K),
+ INFO(at26f004, 0x1f0400, 0, 64 * 1024, 8, SECT_4K),
+ INFO(at26df081a, 0x1f4501, 0, 64 * 1024, 16, SECT_4K),
+ INFO(at26df161a, 0x1f4601, 0, 64 * 1024, 32, SECT_4K),
+ INFO(at26df321, 0x1f4700, 0, 64 * 1024, 64, SECT_4K),
- INFO("at45db081d", 0x1f2500, 0, 64 * 1024, 16, SECT_4K),
+ INFO(at45db081d, 0x1f2500, 0, 64 * 1024, 16, SECT_4K),
/* EON -- en25xxx */
- INFO("en25f32", 0x1c3116, 0, 64 * 1024, 64, SECT_4K),
- INFO("en25p32", 0x1c2016, 0, 64 * 1024, 64, 0),
- INFO("en25q32b", 0x1c3016, 0, 64 * 1024, 64, 0),
- INFO("en25p64", 0x1c2017, 0, 64 * 1024, 128, 0),
- INFO("en25q64", 0x1c3017, 0, 64 * 1024, 128, SECT_4K),
- INFO("en25qh128", 0x1c7018, 0, 64 * 1024, 256, 0),
- INFO("en25qh256", 0x1c7019, 0, 64 * 1024, 512, 0),
+ INFO(en25f32, 0x1c3116, 0, 64 * 1024, 64, SECT_4K),
+ INFO(en25p32, 0x1c2016, 0, 64 * 1024, 64, 0),
+ INFO(en25q32b, 0x1c3016, 0, 64 * 1024, 64, 0),
+ INFO(en25p64, 0x1c2017, 0, 64 * 1024, 128, 0),
+ INFO(en25q64, 0x1c3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(en25qh128, 0x1c7018, 0, 64 * 1024, 256, 0),
+ INFO(en25qh256, 0x1c7019, 0, 64 * 1024, 512, 0),
/* ESMT */
- INFO("f25l32pa", 0x8c2016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(f25l32pa, 0x8c2016, 0, 64 * 1024, 64, SECT_4K),
/* Everspin */
- CAT25_INFO("mr25h256", 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("mr25h10", 128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(mr25h256, 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(mr25h10, 128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
/* GigaDevice */
- INFO("gd25q32", 0xc84016, 0, 64 * 1024, 64, SECT_4K),
- INFO("gd25q64", 0xc84017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(gd25q32, 0xc84016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(gd25q64, 0xc84017, 0, 64 * 1024, 128, SECT_4K),
/* Intel/Numonyx -- xxxs33b */
- INFO("160s33b", 0x898911, 0, 64 * 1024, 32, 0),
- INFO("320s33b", 0x898912, 0, 64 * 1024, 64, 0),
- INFO("640s33b", 0x898913, 0, 64 * 1024, 128, 0),
+ INFO(160s33b, 0x898911, 0, 64 * 1024, 32, 0),
+ INFO(320s33b, 0x898912, 0, 64 * 1024, 64, 0),
+ INFO(640s33b, 0x898913, 0, 64 * 1024, 128, 0),
/* Macronix */
- INFO("mx25l2005a", 0xc22012, 0, 64 * 1024, 4, SECT_4K),
- INFO("mx25l4005a", 0xc22013, 0, 64 * 1024, 8, SECT_4K),
- INFO("mx25l8005", 0xc22014, 0, 64 * 1024, 16, 0),
- INFO("mx25l1606e", 0xc22015, 0, 64 * 1024, 32, SECT_4K),
- INFO("mx25l3205d", 0xc22016, 0, 64 * 1024, 64, 0),
- INFO("mx25l3255e", 0xc29e16, 0, 64 * 1024, 64, SECT_4K),
- INFO("mx25l6405d", 0xc22017, 0, 64 * 1024, 128, 0),
- INFO("mx25l12805d", 0xc22018, 0, 64 * 1024, 256, 0),
- INFO("mx25l12855e", 0xc22618, 0, 64 * 1024, 256, 0),
- INFO("mx25l25635e", 0xc22019, 0, 64 * 1024, 512, 0),
- INFO("mx25l25655e", 0xc22619, 0, 64 * 1024, 512, 0),
- INFO("mx66l51235l", 0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ),
- INFO("mx66l1g55g", 0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ),
+ INFO(mx25l2005a, 0xc22012, 0, 64 * 1024, 4, SECT_4K),
+ INFO(mx25l4005a, 0xc22013, 0, 64 * 1024, 8, SECT_4K),
+ INFO(mx25l8005, 0xc22014, 0, 64 * 1024, 16, 0),
+ INFO(mx25l1606e, 0xc22015, 0, 64 * 1024, 32, SECT_4K),
+ INFO(mx25l3205d, 0xc22016, 0, 64 * 1024, 64, 0),
+ INFO(mx25l3255e, 0xc29e16, 0, 64 * 1024, 64, SECT_4K),
+ INFO(mx25l6405d, 0xc22017, 0, 64 * 1024, 128, 0),
+ INFO(mx25l12805d, 0xc22018, 0, 64 * 1024, 256, 0),
+ INFO(mx25l12855e, 0xc22618, 0, 64 * 1024, 256, 0),
+ INFO(mx25l25635e, 0xc22019, 0, 64 * 1024, 512, 0),
+ INFO(mx25l25655e, 0xc22619, 0, 64 * 1024, 512, 0),
+ INFO(mx66l51235l, 0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ),
+ INFO(mx66l1g55g, 0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ),
/* Micron */
- INFO("n25q064", 0x20ba17, 0, 64 * 1024, 128, 0),
- INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, 0),
- INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, 0),
- INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K),
- INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K),
- INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, USE_FSR),
- INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, USE_FSR),
+ INFO(n25q064, 0x20ba17, 0, 64 * 1024, 128, 0),
+ INFO(n25q128a11, 0x20bb18, 0, 64 * 1024, 256, 0),
+ INFO(n25q128a13, 0x20ba18, 0, 64 * 1024, 256, 0),
+ INFO(n25q256a, 0x20ba19, 0, 64 * 1024, 512, SECT_4K),
+ INFO(n25q512a, 0x20bb20, 0, 64 * 1024, 1024, SECT_4K),
+ INFO(n25q512ax3, 0x20ba20, 0, 64 * 1024, 1024, USE_FSR),
+ INFO(n25q00, 0x20ba21, 0, 64 * 1024, 2048, USE_FSR),
/* PMC */
- INFO("pm25lv512", 0, 0, 32 * 1024, 2, SECT_4K_PMC),
- INFO("pm25lv010", 0, 0, 32 * 1024, 4, SECT_4K_PMC),
- INFO("pm25lq032", 0x7f9d46, 0, 64 * 1024, 64, SECT_4K),
+ INFO(pm25lv512, 0, 0, 32 * 1024, 2, SECT_4K_PMC),
+ INFO(pm25lv010, 0, 0, 32 * 1024, 4, SECT_4K_PMC),
+ INFO(pm25lq032, 0x7f9d46, 0, 64 * 1024, 64, SECT_4K),
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- INFO("s25sl032p", 0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
- INFO("s25sl064p", 0x010216, 0x4d00, 64 * 1024, 128, 0),
- INFO("s25fl256s0", 0x010219, 0x4d00, 256 * 1024, 128, 0),
- INFO("s25fl256s1", 0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
- INFO("s25fl512s", 0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
- INFO("s70fl01gs", 0x010221, 0x4d00, 256 * 1024, 256, 0),
- INFO("s25sl12800", 0x012018, 0x0300, 256 * 1024, 64, 0),
- INFO("s25sl12801", 0x012018, 0x0301, 64 * 1024, 256, 0),
- INFO("s25fl129p0", 0x012018, 0x4d00, 256 * 1024, 64, 0),
- INFO("s25fl129p1", 0x012018, 0x4d01, 64 * 1024, 256, 0),
- INFO("s25sl004a", 0x010212, 0, 64 * 1024, 8, 0),
- INFO("s25sl008a", 0x010213, 0, 64 * 1024, 16, 0),
- INFO("s25sl016a", 0x010214, 0, 64 * 1024, 32, 0),
- INFO("s25sl032a", 0x010215, 0, 64 * 1024, 64, 0),
- INFO("s25sl064a", 0x010216, 0, 64 * 1024, 128, 0),
- INFO("s25fl008k", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
- INFO("s25fl016k", 0xef4015, 0, 64 * 1024, 32, SECT_4K),
- INFO("s25fl064k", 0xef4017, 0, 64 * 1024, 128, SECT_4K),
-
- /* SST -- large erase sizes are "overlays", "sectors" are 4K */
- INFO("sst25vf040b", 0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
- INFO("sst25vf080b", 0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE),
- INFO("sst25vf016b", 0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE),
- INFO("sst25vf032b", 0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE),
- INFO("sst25vf064c", 0xbf254b, 0, 64 * 1024, 128, SECT_4K),
- INFO("sst25wf512", 0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE),
- INFO("sst25wf010", 0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE),
- INFO("sst25wf020", 0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE),
- INFO("sst25wf040", 0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
+ INFO(s25sl032p, 0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO(s25sl064p, 0x010216, 0x4d00, 64 * 1024, 128, 0),
+ INFO(s25fl256s0, 0x010219, 0x4d00, 256 * 1024, 128, 0),
+ INFO(s25fl256s1, 0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO(s25fl512s, 0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ),
+ INFO(s70fl01gs, 0x010221, 0x4d00, 256 * 1024, 256, 0),
+ INFO(s25sl12800, 0x012018, 0x0300, 256 * 1024, 64, 0),
+ INFO(s25sl12801, 0x012018, 0x0301, 64 * 1024, 256, 0),
+ INFO(s25fl129p0, 0x012018, 0x4d00, 256 * 1024, 64, 0),
+ INFO(s25fl129p1, 0x012018, 0x4d01, 64 * 1024, 256, 0),
+ INFO(s25sl004a, 0x010212, 0, 64 * 1024, 8, 0),
+ INFO(s25sl008a, 0x010213, 0, 64 * 1024, 16, 0),
+ INFO(s25sl016a, 0x010214, 0, 64 * 1024, 32, 0),
+ INFO(s25sl032a, 0x010215, 0, 64 * 1024, 64, 0),
+ INFO(s25sl064a, 0x010216, 0, 64 * 1024, 128, 0),
+ INFO(s25fl008k, 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(s25fl016k, 0xef4015, 0, 64 * 1024, 32, SECT_4K),
+ INFO(s25fl064k, 0xef4017, 0, 64 * 1024, 128, SECT_4K),
+
+ /* SST -- large erase sizes are overlays, sectors are 4K */
+ INFO(sst25vf040b, 0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
+ INFO(sst25vf080b, 0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE),
+ INFO(sst25vf016b, 0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE),
+ INFO(sst25vf032b, 0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE),
+ INFO(sst25vf064c, 0xbf254b, 0, 64 * 1024, 128, SECT_4K),
+ INFO(sst25wf512, 0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE),
+ INFO(sst25wf010, 0xbf2502, 0, 64 * 1024, 2, SECT_4K | SST_WRITE),
+ INFO(sst25wf020, 0xbf2503, 0, 64 * 1024, 4, SECT_4K | SST_WRITE),
+ INFO(sst25wf040, 0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE),
/* ST Microelectronics -- newer production may have feature updates */
- INFO("m25p05", 0x202010, 0, 32 * 1024, 2, 0),
- INFO("m25p10", 0x202011, 0, 32 * 1024, 4, 0),
- INFO("m25p20", 0x202012, 0, 64 * 1024, 4, 0),
- INFO("m25p40", 0x202013, 0, 64 * 1024, 8, 0),
- INFO("m25p80", 0x202014, 0, 64 * 1024, 16, 0),
- INFO("m25p16", 0x202015, 0, 64 * 1024, 32, 0),
- INFO("m25p32", 0x202016, 0, 64 * 1024, 64, 0),
- INFO("m25p64", 0x202017, 0, 64 * 1024, 128, 0),
- INFO("m25p128", 0x202018, 0, 256 * 1024, 64, 0),
- INFO("n25q032", 0x20ba16, 0, 64 * 1024, 64, 0),
-
- INFO("m25p05-nonjedec", 0, 0, 32 * 1024, 2, 0),
- INFO("m25p10-nonjedec", 0, 0, 32 * 1024, 4, 0),
- INFO("m25p20-nonjedec", 0, 0, 64 * 1024, 4, 0),
- INFO("m25p40-nonjedec", 0, 0, 64 * 1024, 8, 0),
- INFO("m25p80-nonjedec", 0, 0, 64 * 1024, 16, 0),
- INFO("m25p16-nonjedec", 0, 0, 64 * 1024, 32, 0),
- INFO("m25p32-nonjedec", 0, 0, 64 * 1024, 64, 0),
- INFO("m25p64-nonjedec", 0, 0, 64 * 1024, 128, 0),
- INFO("m25p128-nonjedec", 0, 0, 256 * 1024, 64, 0),
-
- INFO("m45pe10", 0x204011, 0, 64 * 1024, 2, 0),
- INFO("m45pe80", 0x204014, 0, 64 * 1024, 16, 0),
- INFO("m45pe16", 0x204015, 0, 64 * 1024, 32, 0),
-
- INFO("m25pe20", 0x208012, 0, 64 * 1024, 4, 0),
- INFO("m25pe80", 0x208014, 0, 64 * 1024, 16, 0),
- INFO("m25pe16", 0x208015, 0, 64 * 1024, 32, SECT_4K),
-
- INFO("m25px16", 0x207115, 0, 64 * 1024, 32, SECT_4K),
- INFO("m25px32", 0x207116, 0, 64 * 1024, 64, SECT_4K),
- INFO("m25px32-s0", 0x207316, 0, 64 * 1024, 64, SECT_4K),
- INFO("m25px32-s1", 0x206316, 0, 64 * 1024, 64, SECT_4K),
- INFO("m25px64", 0x207117, 0, 64 * 1024, 128, 0),
-
- /* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
- INFO("w25x10", 0xef3011, 0, 64 * 1024, 2, SECT_4K),
- INFO("w25x20", 0xef3012, 0, 64 * 1024, 4, SECT_4K),
- INFO("w25x40", 0xef3013, 0, 64 * 1024, 8, SECT_4K),
- INFO("w25x80", 0xef3014, 0, 64 * 1024, 16, SECT_4K),
- INFO("w25x16", 0xef3015, 0, 64 * 1024, 32, SECT_4K),
- INFO("w25x32", 0xef3016, 0, 64 * 1024, 64, SECT_4K),
- INFO("w25q32", 0xef4016, 0, 64 * 1024, 64, SECT_4K),
- INFO("w25q32dw", 0xef6016, 0, 64 * 1024, 64, SECT_4K),
- INFO("w25x64", 0xef3017, 0, 64 * 1024, 128, SECT_4K),
- INFO("w25q64", 0xef4017, 0, 64 * 1024, 128, SECT_4K),
- INFO("w25q80", 0xef5014, 0, 64 * 1024, 16, SECT_4K),
- INFO("w25q80bl", 0xef4014, 0, 64 * 1024, 16, SECT_4K),
- INFO("w25q128", 0xef4018, 0, 64 * 1024, 256, SECT_4K),
- INFO("w25q256", 0xef4019, 0, 64 * 1024, 512, SECT_4K),
+ INFO(m25p05, 0x202010, 0, 32 * 1024, 2, 0),
+ INFO(m25p10, 0x202011, 0, 32 * 1024, 4, 0),
+ INFO(m25p20, 0x202012, 0, 64 * 1024, 4, 0),
+ INFO(m25p40, 0x202013, 0, 64 * 1024, 8, 0),
+ INFO(m25p80, 0x202014, 0, 64 * 1024, 16, 0),
+ INFO(m25p16, 0x202015, 0, 64 * 1024, 32, 0),
+ INFO(m25p32, 0x202016, 0, 64 * 1024, 64, 0),
+ INFO(m25p64, 0x202017, 0, 64 * 1024, 128, 0),
+ INFO(m25p128, 0x202018, 0, 256 * 1024, 64, 0),
+ INFO(n25q032, 0x20ba16, 0, 64 * 1024, 64, 0),
+
+ INFO(m25p05_nonjedec, 0, 0, 32 * 1024, 2, 0),
+ INFO(m25p10_nonjedec, 0, 0, 32 * 1024, 4, 0),
+ INFO(m25p20_nonjedec, 0, 0, 64 * 1024, 4, 0),
+ INFO(m25p40_nonjedec, 0, 0, 64 * 1024, 8, 0),
+ INFO(m25p80_nonjedec, 0, 0, 64 * 1024, 16, 0),
+ INFO(m25p16_nonjedec, 0, 0, 64 * 1024, 32, 0),
+ INFO(m25p32_nonjedec, 0, 0, 64 * 1024, 64, 0),
+ INFO(m25p64_nonjedec, 0, 0, 64 * 1024, 128, 0),
+ INFO(m25p128_nonjedec, 0, 0, 256 * 1024, 64, 0),
+
+ INFO(m45pe10, 0x204011, 0, 64 * 1024, 2, 0),
+ INFO(m45pe80, 0x204014, 0, 64 * 1024, 16, 0),
+ INFO(m45pe16, 0x204015, 0, 64 * 1024, 32, 0),
+
+ INFO(m25pe20, 0x208012, 0, 64 * 1024, 4, 0),
+ INFO(m25pe80, 0x208014, 0, 64 * 1024, 16, 0),
+ INFO(m25pe16, 0x208015, 0, 64 * 1024, 32, SECT_4K),
+
+ INFO(m25px16, 0x207115, 0, 64 * 1024, 32, SECT_4K),
+ INFO(m25px32, 0x207116, 0, 64 * 1024, 64, SECT_4K),
+ INFO(m25px32_s0, 0x207316, 0, 64 * 1024, 64, SECT_4K),
+ INFO(m25px32_s1, 0x206316, 0, 64 * 1024, 64, SECT_4K),
+ INFO(m25px64, 0x207117, 0, 64 * 1024, 128, 0),
+
+ /* Winbond -- w25x blocks are 64K, sectors are 4KiB */
+ INFO(w25x10, 0xef3011, 0, 64 * 1024, 2, SECT_4K),
+ INFO(w25x20, 0xef3012, 0, 64 * 1024, 4, SECT_4K),
+ INFO(w25x40, 0xef3013, 0, 64 * 1024, 8, SECT_4K),
+ INFO(w25x80, 0xef3014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(w25x16, 0xef3015, 0, 64 * 1024, 32, SECT_4K),
+ INFO(w25x32, 0xef3016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(w25q32, 0xef4016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(w25q32dw, 0xef6016, 0, 64 * 1024, 64, SECT_4K),
+ INFO(w25x64, 0xef3017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(w25q64, 0xef4017, 0, 64 * 1024, 128, SECT_4K),
+ INFO(w25q80, 0xef5014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(w25q80bl, 0xef4014, 0, 64 * 1024, 16, SECT_4K),
+ INFO(w25q128, 0xef4018, 0, 64 * 1024, 256, SECT_4K),
+ INFO(w25q256, 0xef4019, 0, 64 * 1024, 512, SECT_4K),
/* Catalyst / On Semiconductor -- non-JEDEC */
- CAT25_INFO("cat25c11", 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25c03", 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25c09", 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25c17", 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- CAT25_INFO("cat25128", 2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
- { },
+ CAT25_INFO(cat25c11, 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25c03, 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25c09, 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25c17, 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+ CAT25_INFO(cat25128, 2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR),
+
+ /* Fill in name fields */
+#define SPI_NOR_ENUM_TYPE(s, c) [CHIP_TYPE_ ## c].name = s,
+ SPI_NOR_ENUM_TYPES()
+#undef SPI_NOR_ENUM_TYPE
+
+ [CHIP_TYPE_COUNT] = { },
};
static const struct flash_info *spi_nor_info_by_name(const char *name)
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 6f92b4b..03b7959 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -198,4 +198,76 @@ struct spi_nor {
*/
int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
+#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
+ c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
+ c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
+ c_id(at26df081a) c_id(at26df161a) c_id(at26df321) \
+ c_id(at45db081d) \
+ c_id(en25f32) c_id(en25p32) c_id(en25q32b) \
+ c_id(en25p64) c_id(en25q64) c_id(en25qh128) \
+ c_id(en25qh256) \
+ c_id(f25l32pa) \
+ c_id(mr25h256) c_id(mr25h10) \
+ c_id(gd25q32) c_id(gd25q64) \
+ c_id(160s33b) c_id(320s33b) c_id(640s33b) \
+ c_id(mx25l2005a) c_id(mx25l4005a) c_id(mx25l8005) \
+ c_id(mx25l1606e) c_id(mx25l3205d) c_id(mx25l3255e) \
+ c_id(mx25l6405d) c_id(mx25l12805d) c_id(mx25l12855e) \
+ c_id(mx25l25635e) c_id(mx25l25655e) c_id(mx66l51235l) \
+ c_id(mx66l1g55g) \
+ c_id(n25q064) c_id(n25q128a11) c_id(n25q128a13) \
+ c_id(n25q256a) c_id(n25q512a) c_id(n25q512ax3) \
+ c_id(n25q00) \
+ c_id(pm25lv512) c_id(pm25lv010) c_id(pm25lq032) \
+ c_id(s25sl032p) c_id(s25sl064p) c_id(s25fl256s0) \
+ c_id(s25fl256s1) c_id(s25fl512s) c_id(s70fl01gs) \
+ c_id(s25sl12800) c_id(s25sl12801) c_id(s25fl129p0) \
+ c_id(s25fl129p1) c_id(s25sl004a) c_id(s25sl008a) \
+ c_id(s25sl016a) c_id(s25sl032a) c_id(s25sl064a) \
+ c_id(s25fl008k) c_id(s25fl016k) c_id(s25fl064k) \
+ c_id(sst25vf040b) c_id(sst25vf080b) c_id(sst25vf016b) \
+ c_id(sst25vf032b) c_id(sst25vf064c) c_id(sst25wf512) \
+ c_id(sst25wf010) c_id(sst25wf020) c_id(sst25wf040) \
+ c_id(m25p05) c_id(m25p10) c_id(m25p20) \
+ c_id(m25p40) c_id(m25p80) c_id(m25p16) \
+ c_id(m25p32) c_id(m25p64) c_id(m25p128) \
+ c_id(n25q032) \
+ str_and_c_id("m25p05-nonjedec", m25p05_nonjedec) \
+ str_and_c_id("m25p10-nonjedec", m25p10_nonjedec) \
+ str_and_c_id("m25p20-nonjedec", m25p20_nonjedec) \
+ str_and_c_id("m25p40-nonjedec", m25p40_nonjedec) \
+ str_and_c_id("m25p80-nonjedec", m25p80_nonjedec) \
+ str_and_c_id("m25p16-nonjedec", m25p16_nonjedec) \
+ str_and_c_id("m25p32-nonjedec", m25p32_nonjedec) \
+ str_and_c_id("m25p64-nonjedec", m25p64_nonjedec) \
+ str_and_c_id("m25p128-nonjedec", m25p128_nonjedec) \
+ c_id(m45pe10) c_id(m45pe80) c_id(m45pe16) \
+ c_id(m25pe20) c_id(m25pe80) c_id(m25pe16) \
+ c_id(m25px16) c_id(m25px32) \
+ str_and_c_id("m25px32-s0", m25px32_s0) \
+ str_and_c_id("m25px32-s1", m25px32_s1) \
+ c_id(m25px64) \
+ c_id(w25x10) c_id(w25x20) c_id(w25x40) \
+ c_id(w25x80) c_id(w25x16) c_id(w25x32) \
+ c_id(w25q32) c_id(w25q32dw) c_id(w25x64) \
+ c_id(w25q64) c_id(w25q80) c_id(w25q80bl) \
+ c_id(w25q128) c_id(w25q256) \
+ c_id(cat25c11) c_id(cat25c03) c_id(cat25c09) \
+ c_id(cat25c17) c_id(cat25128)
+#define __SPI_NOR_ENUM_TYPE_C_ID(id) SPI_NOR_ENUM_TYPE(#id, id)
+
+/**
+ * SPI_NOR_ENUM_TYPES - invoke SPI_NOR_ENUM_TYPE() for each SPI NOR chip type
+ *
+ * This will expand to SPI_NOR_ENUM_TYPE(string, c_id) for each chip
+ * type recognised by the spi-nor library. The first argument is the
+ * string literal version of the chip type name. The second argument
+ * is a version of the name suitable for including in a C identifier,
+ * though it may begin with a digit.
+ *
+ * The caller must define SPI_NOR_ENUM_TYPE before invoking this macro.
+ */
+#define SPI_NOR_ENUM_TYPES() \
+ __SPI_NOR_ENUM_TYPES(__SPI_NOR_ENUM_TYPE_C_ID, SPI_NOR_ENUM_TYPE)
+
#endif
--
Ben Hutchings
The world is coming to an end. Please log off.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140914/b5b0969d/attachment.sig>
^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
2014-09-14 17:10 ` Ben Hutchings
(?)
@ 2014-09-14 17:13 ` Ben Hutchings
-1 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:13 UTC (permalink / raw)
To: Brian Norris
Cc: Geert Uytterhoeven, Andrew Lunn, Jason Cooper, linux-spi,
Huang Shijie, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 813 bytes --]
On Sun, 2014-09-14 at 18:10 +0100, Ben Hutchings wrote:
> The first patch in the series restores the module aliases to m25p80, but
> it does so by duplicating the list of names. This should be suitable
> for stable, but it isn't viable in the longer term.
>
> The following patches change the spi-nor interface so that this
> duplication is no longer necessary. This includes removing
> spi_nor::read_id, but it could be re-added after this with a different
> interface, e.g. returning a flash_info structure (which would need to be
> defined in spi_nor.h).
Note that these patch are:
- Based on your 'testing' branch
- Untested by me, aside from compiling and checking that m25p80 has the
expected module aliases
Ben.
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-09-14 17:13 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:13 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Geert Uytterhoeven, Huang Shijie, linux-arm-kernel,
debian-kernel
[-- Attachment #1: Type: text/plain, Size: 813 bytes --]
On Sun, 2014-09-14 at 18:10 +0100, Ben Hutchings wrote:
> The first patch in the series restores the module aliases to m25p80, but
> it does so by duplicating the list of names. This should be suitable
> for stable, but it isn't viable in the longer term.
>
> The following patches change the spi-nor interface so that this
> duplication is no longer necessary. This includes removing
> spi_nor::read_id, but it could be re-added after this with a different
> interface, e.g. returning a flash_info structure (which would need to be
> defined in spi_nor.h).
Note that these patch are:
- Based on your 'testing' branch
- Untested by me, aside from compiling and checking that m25p80 has the
expected module aliases
Ben.
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-09-14 17:13 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-14 17:13 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, 2014-09-14 at 18:10 +0100, Ben Hutchings wrote:
> The first patch in the series restores the module aliases to m25p80, but
> it does so by duplicating the list of names. This should be suitable
> for stable, but it isn't viable in the longer term.
>
> The following patches change the spi-nor interface so that this
> duplication is no longer necessary. This includes removing
> spi_nor::read_id, but it could be re-added after this with a different
> interface, e.g. returning a flash_info structure (which would need to be
> defined in spi_nor.h).
Note that these patch are:
- Based on your 'testing' branch
- Untested by me, aside from compiling and checking that m25p80 has the
expected module aliases
Ben.
--
Ben Hutchings
The world is coming to an end. Please log off.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140914/5e97912a/attachment-0001.sig>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again
2014-09-14 17:11 ` Ben Hutchings
(?)
@ 2014-09-15 7:55 ` Geert Uytterhoeven
-1 siblings, 0 replies; 75+ messages in thread
From: Geert Uytterhoeven @ 2014-09-15 7:55 UTC (permalink / raw)
To: Ben Hutchings
Cc: Brian Norris, Andrew Lunn, Jason Cooper, linux-spi, Huang Shijie,
MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Ben,
On Sun, Sep 14, 2014 at 7:11 PM, Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org> wrote:
> Move the list of chip type names to spi-nor.h. To avoid putting all
> the chip type information there, we define this list as a macro
> SPI_NOR_ENUM_TYPES() that invokes another macro SPI_NOR_ENUM_TYPE()
> that must be defined to expand each name to whatever form it's needed.
>
> In spi-nor.c, use it to define enumerators, then use the enumerators
> as indices when defining spi_nor_info so that we cannot accidentally
> use a name that's not on the list.
>
> This is somewhat complicated by the fact that some names include
> hyphens. SPI_NOR_ENUM_TYPE() therefore takes separate string and C
> identifier parameters.
Thanks for doing this!
However, the table generation still looks overly complicated to me, with
too much duplication which needs to be kept in sync.
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -245,51 +245,10 @@ static int m25p_remove(struct spi_device *spi)
> }
>
>
> -/*
> - * XXX This needs to be kept in sync with spi_nor_info. We can't share
> - * it with spi-nor, because if this is built as a module then modpost
> - * won't be able to read it and add appropriate aliases.
> - */
> static const struct spi_device_id m25p_ids[] = {
[...]
> +#define SPI_NOR_ENUM_TYPE(s, c) { s },
> + SPI_NOR_ENUM_TYPES()
> +#undef SPI_NOR_ENUM_TYPE
> { },
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> /* 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 chip type names must be added to __SPI_NOR_ENUM_TYPES in
Oops... These will get out of sync.
> + * spi-nor.h before they can be used here (enforced by using the
> + * names to index this array).
> */
> static const struct flash_info spi_nor_info[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> - INFO("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
> - INFO("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
> + INFO(at25fs010, 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
> + INFO(at25fs040, 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
[...]
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -198,4 +198,76 @@ struct spi_nor {
> */
> int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
>
> +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
> + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
> + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
Can't you just have the IDs in a header file only, and let the header file
generate either a struct flash_info or a struct spi_device_id table, using
a macro defined by the file that includes it?
Cfr. include/uapi/asm-generic/unistd.h and its use of __SYSCALL()?
Or am I missing something (e.g. this is impossible due to the hyphens in the
names?).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 5/5] m25p80, spi-nor: Share the list of supported chip type names again
@ 2014-09-15 7:55 ` Geert Uytterhoeven
0 siblings, 0 replies; 75+ messages in thread
From: Geert Uytterhoeven @ 2014-09-15 7:55 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Brian Norris, Huang Shijie, linux-arm-kernel,
debian-kernel
Hi Ben,
On Sun, Sep 14, 2014 at 7:11 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> Move the list of chip type names to spi-nor.h. To avoid putting all
> the chip type information there, we define this list as a macro
> SPI_NOR_ENUM_TYPES() that invokes another macro SPI_NOR_ENUM_TYPE()
> that must be defined to expand each name to whatever form it's needed.
>
> In spi-nor.c, use it to define enumerators, then use the enumerators
> as indices when defining spi_nor_info so that we cannot accidentally
> use a name that's not on the list.
>
> This is somewhat complicated by the fact that some names include
> hyphens. SPI_NOR_ENUM_TYPE() therefore takes separate string and C
> identifier parameters.
Thanks for doing this!
However, the table generation still looks overly complicated to me, with
too much duplication which needs to be kept in sync.
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -245,51 +245,10 @@ static int m25p_remove(struct spi_device *spi)
> }
>
>
> -/*
> - * XXX This needs to be kept in sync with spi_nor_info. We can't share
> - * it with spi-nor, because if this is built as a module then modpost
> - * won't be able to read it and add appropriate aliases.
> - */
> static const struct spi_device_id m25p_ids[] = {
[...]
> +#define SPI_NOR_ENUM_TYPE(s, c) { s },
> + SPI_NOR_ENUM_TYPES()
> +#undef SPI_NOR_ENUM_TYPE
> { },
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> /* 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 chip type names must be added to __SPI_NOR_ENUM_TYPES in
Oops... These will get out of sync.
> + * spi-nor.h before they can be used here (enforced by using the
> + * names to index this array).
> */
> static const struct flash_info spi_nor_info[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> - INFO("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
> - INFO("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
> + INFO(at25fs010, 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
> + INFO(at25fs040, 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
[...]
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -198,4 +198,76 @@ struct spi_nor {
> */
> int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
>
> +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
> + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
> + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
Can't you just have the IDs in a header file only, and let the header file
generate either a struct flash_info or a struct spi_device_id table, using
a macro defined by the file that includes it?
Cfr. include/uapi/asm-generic/unistd.h and its use of __SYSCALL()?
Or am I missing something (e.g. this is impossible due to the hyphens in the
names?).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 5/5] m25p80, spi-nor: Share the list of supported chip type names again
@ 2014-09-15 7:55 ` Geert Uytterhoeven
0 siblings, 0 replies; 75+ messages in thread
From: Geert Uytterhoeven @ 2014-09-15 7:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ben,
On Sun, Sep 14, 2014 at 7:11 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> Move the list of chip type names to spi-nor.h. To avoid putting all
> the chip type information there, we define this list as a macro
> SPI_NOR_ENUM_TYPES() that invokes another macro SPI_NOR_ENUM_TYPE()
> that must be defined to expand each name to whatever form it's needed.
>
> In spi-nor.c, use it to define enumerators, then use the enumerators
> as indices when defining spi_nor_info so that we cannot accidentally
> use a name that's not on the list.
>
> This is somewhat complicated by the fact that some names include
> hyphens. SPI_NOR_ENUM_TYPE() therefore takes separate string and C
> identifier parameters.
Thanks for doing this!
However, the table generation still looks overly complicated to me, with
too much duplication which needs to be kept in sync.
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -245,51 +245,10 @@ static int m25p_remove(struct spi_device *spi)
> }
>
>
> -/*
> - * XXX This needs to be kept in sync with spi_nor_info. We can't share
> - * it with spi-nor, because if this is built as a module then modpost
> - * won't be able to read it and add appropriate aliases.
> - */
> static const struct spi_device_id m25p_ids[] = {
[...]
> +#define SPI_NOR_ENUM_TYPE(s, c) { s },
> + SPI_NOR_ENUM_TYPES()
> +#undef SPI_NOR_ENUM_TYPE
> { },
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> /* 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 chip type names must be added to __SPI_NOR_ENUM_TYPES in
Oops... These will get out of sync.
> + * spi-nor.h before they can be used here (enforced by using the
> + * names to index this array).
> */
> static const struct flash_info spi_nor_info[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> - INFO("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
> - INFO("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
> + INFO(at25fs010, 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
> + INFO(at25fs040, 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
[...]
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -198,4 +198,76 @@ struct spi_nor {
> */
> int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
>
> +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
> + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
> + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
Can't you just have the IDs in a header file only, and let the header file
generate either a struct flash_info or a struct spi_device_id table, using
a macro defined by the file that includes it?
Cfr. include/uapi/asm-generic/unistd.h and its use of __SYSCALL()?
Or am I missing something (e.g. this is impossible due to the hyphens in the
names?).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 2/5] spi-nor: Remove spi_nor::read_id operation
2014-09-14 17:11 ` Ben Hutchings
(?)
@ 2014-09-15 14:55 ` Huang Shijie
-1 siblings, 0 replies; 75+ messages in thread
From: Huang Shijie @ 2014-09-15 14:55 UTC (permalink / raw)
To: Ben Hutchings
Cc: Brian Norris, Geert Uytterhoeven, Andrew Lunn, Jason Cooper,
linux-spi, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Sun, Sep 14, 2014 at 06:11:16PM +0100, Ben Hutchings wrote:
> There is currently no useful way to override the default
> implementation of this operation. The returned struct spi_device_id
> must have a pointer to struct flash_info in its private data, but this
> structure is defined inside spi-nor.
>
> Signed-off-by: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
> ---
> drivers/mtd/spi-nor/spi-nor.c | 4 +---
> include/linux/mtd/spi-nor.h | 3 ---
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 6b1bda2..6f699c5 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -902,8 +902,6 @@ static int spi_nor_check(struct spi_nor *nor)
> return -EINVAL;
> }
>
> - if (!nor->read_id)
> - nor->read_id = spi_nor_read_id;
> if (!nor->wait_till_ready)
> nor->wait_till_ready = spi_nor_wait_till_ready;
>
> @@ -952,7 +950,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> if (info->jedec_id) {
> const struct spi_device_id *jid;
>
> - jid = nor->read_id(nor);
> + jid = spi_nor_read_id(nor);
> if (IS_ERR(jid)) {
> return PTR_ERR(jid);
> } else if (jid != id) {
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 5ec84cc..66af67a 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -139,8 +139,6 @@ enum spi_nor_ops {
> * @write_xfer: [OPTIONAL] the writefundamental primitive
> * @read_reg: [DRIVER-SPECIFIC] read out the register
> * @write_reg: [DRIVER-SPECIFIC] write data to the register
> - * @read_id: [REPLACEABLE] read out the ID data, and find
> - * the proper spi_device_id
If we remove this hook, i guess we will add it back in the later.
Other new drivers will use this hook.
so i suggest to keep it as it is.
thanks
Huang Shijie
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 2/5] spi-nor: Remove spi_nor::read_id operation
@ 2014-09-15 14:55 ` Huang Shijie
0 siblings, 0 replies; 75+ messages in thread
From: Huang Shijie @ 2014-09-15 14:55 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Lunn, Jason Cooper, linux-spi, Geert Uytterhoeven,
Ian Campbell, MTD Maling List, Brian Norris, linux-arm-kernel,
debian-kernel
On Sun, Sep 14, 2014 at 06:11:16PM +0100, Ben Hutchings wrote:
> There is currently no useful way to override the default
> implementation of this operation. The returned struct spi_device_id
> must have a pointer to struct flash_info in its private data, but this
> structure is defined inside spi-nor.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> drivers/mtd/spi-nor/spi-nor.c | 4 +---
> include/linux/mtd/spi-nor.h | 3 ---
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 6b1bda2..6f699c5 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -902,8 +902,6 @@ static int spi_nor_check(struct spi_nor *nor)
> return -EINVAL;
> }
>
> - if (!nor->read_id)
> - nor->read_id = spi_nor_read_id;
> if (!nor->wait_till_ready)
> nor->wait_till_ready = spi_nor_wait_till_ready;
>
> @@ -952,7 +950,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> if (info->jedec_id) {
> const struct spi_device_id *jid;
>
> - jid = nor->read_id(nor);
> + jid = spi_nor_read_id(nor);
> if (IS_ERR(jid)) {
> return PTR_ERR(jid);
> } else if (jid != id) {
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 5ec84cc..66af67a 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -139,8 +139,6 @@ enum spi_nor_ops {
> * @write_xfer: [OPTIONAL] the writefundamental primitive
> * @read_reg: [DRIVER-SPECIFIC] read out the register
> * @write_reg: [DRIVER-SPECIFIC] write data to the register
> - * @read_id: [REPLACEABLE] read out the ID data, and find
> - * the proper spi_device_id
If we remove this hook, i guess we will add it back in the later.
Other new drivers will use this hook.
so i suggest to keep it as it is.
thanks
Huang Shijie
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 2/5] spi-nor: Remove spi_nor::read_id operation
@ 2014-09-15 14:55 ` Huang Shijie
0 siblings, 0 replies; 75+ messages in thread
From: Huang Shijie @ 2014-09-15 14:55 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Sep 14, 2014 at 06:11:16PM +0100, Ben Hutchings wrote:
> There is currently no useful way to override the default
> implementation of this operation. The returned struct spi_device_id
> must have a pointer to struct flash_info in its private data, but this
> structure is defined inside spi-nor.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> drivers/mtd/spi-nor/spi-nor.c | 4 +---
> include/linux/mtd/spi-nor.h | 3 ---
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 6b1bda2..6f699c5 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -902,8 +902,6 @@ static int spi_nor_check(struct spi_nor *nor)
> return -EINVAL;
> }
>
> - if (!nor->read_id)
> - nor->read_id = spi_nor_read_id;
> if (!nor->wait_till_ready)
> nor->wait_till_ready = spi_nor_wait_till_ready;
>
> @@ -952,7 +950,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> if (info->jedec_id) {
> const struct spi_device_id *jid;
>
> - jid = nor->read_id(nor);
> + jid = spi_nor_read_id(nor);
> if (IS_ERR(jid)) {
> return PTR_ERR(jid);
> } else if (jid != id) {
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 5ec84cc..66af67a 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -139,8 +139,6 @@ enum spi_nor_ops {
> * @write_xfer: [OPTIONAL] the writefundamental primitive
> * @read_reg: [DRIVER-SPECIFIC] read out the register
> * @write_reg: [DRIVER-SPECIFIC] write data to the register
> - * @read_id: [REPLACEABLE] read out the ID data, and find
> - * the proper spi_device_id
If we remove this hook, i guess we will add it back in the later.
Other new drivers will use this hook.
so i suggest to keep it as it is.
thanks
Huang Shijie
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again
2014-09-15 7:55 ` Geert Uytterhoeven
(?)
@ 2014-09-15 15:07 ` Ben Hutchings
-1 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-15 15:07 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Brian Norris, Andrew Lunn, Jason Cooper, linux-spi, Huang Shijie,
MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]
On Mon, 2014-09-15 at 09:55 +0200, Geert Uytterhoeven wrote:
> Hi Ben,
>
> On Sun, Sep 14, 2014 at 7:11 PM, Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org> wrote:
> > Move the list of chip type names to spi-nor.h. To avoid putting all
> > the chip type information there, we define this list as a macro
> > SPI_NOR_ENUM_TYPES() that invokes another macro SPI_NOR_ENUM_TYPE()
> > that must be defined to expand each name to whatever form it's needed.
> >
> > In spi-nor.c, use it to define enumerators, then use the enumerators
> > as indices when defining spi_nor_info so that we cannot accidentally
> > use a name that's not on the list.
> >
> > This is somewhat complicated by the fact that some names include
> > hyphens. SPI_NOR_ENUM_TYPE() therefore takes separate string and C
> > identifier parameters.
>
> Thanks for doing this!
>
> However, the table generation still looks overly complicated to me, with
> too much duplication which needs to be kept in sync.
It does need to be kept in sync, but the compiler will check that.
[...]
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -198,4 +198,76 @@ struct spi_nor {
> > */
> > int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
> >
> > +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
> > + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
> > + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
>
> Can't you just have the IDs in a header file only, and let the header file
> generate either a struct flash_info or a struct spi_device_id table, using
> a macro defined by the file that includes it?
How would we match up the rest of the struct flash_info to the name?
> Cfr. include/uapi/asm-generic/unistd.h and its use of __SYSCALL()?
>
> Or am I missing something (e.g. this is impossible due to the hyphens in the
> names?).
Well the hyphens are only a problem because we want C identifiers. But
we only need C identifiers so we can enforce that each struct flash_info
matches a name on the list. If you can find a way to match them up
without having to define enumerators, that would of course be
preferable.
Ben.
--
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again
@ 2014-09-15 15:07 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-15 15:07 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Brian Norris, Huang Shijie, linux-arm-kernel,
debian-kernel
[-- Attachment #1: Type: text/plain, Size: 2376 bytes --]
On Mon, 2014-09-15 at 09:55 +0200, Geert Uytterhoeven wrote:
> Hi Ben,
>
> On Sun, Sep 14, 2014 at 7:11 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> > Move the list of chip type names to spi-nor.h. To avoid putting all
> > the chip type information there, we define this list as a macro
> > SPI_NOR_ENUM_TYPES() that invokes another macro SPI_NOR_ENUM_TYPE()
> > that must be defined to expand each name to whatever form it's needed.
> >
> > In spi-nor.c, use it to define enumerators, then use the enumerators
> > as indices when defining spi_nor_info so that we cannot accidentally
> > use a name that's not on the list.
> >
> > This is somewhat complicated by the fact that some names include
> > hyphens. SPI_NOR_ENUM_TYPE() therefore takes separate string and C
> > identifier parameters.
>
> Thanks for doing this!
>
> However, the table generation still looks overly complicated to me, with
> too much duplication which needs to be kept in sync.
It does need to be kept in sync, but the compiler will check that.
[...]
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -198,4 +198,76 @@ struct spi_nor {
> > */
> > int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
> >
> > +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
> > + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
> > + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
>
> Can't you just have the IDs in a header file only, and let the header file
> generate either a struct flash_info or a struct spi_device_id table, using
> a macro defined by the file that includes it?
How would we match up the rest of the struct flash_info to the name?
> Cfr. include/uapi/asm-generic/unistd.h and its use of __SYSCALL()?
>
> Or am I missing something (e.g. this is impossible due to the hyphens in the
> names?).
Well the hyphens are only a problem because we want C identifiers. But
we only need C identifiers so we can enforce that each struct flash_info
matches a name on the list. If you can find a way to match them up
without having to define enumerators, that would of course be
preferable.
Ben.
--
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again
@ 2014-09-15 15:07 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-15 15:07 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2014-09-15 at 09:55 +0200, Geert Uytterhoeven wrote:
> Hi Ben,
>
> On Sun, Sep 14, 2014 at 7:11 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> > Move the list of chip type names to spi-nor.h. To avoid putting all
> > the chip type information there, we define this list as a macro
> > SPI_NOR_ENUM_TYPES() that invokes another macro SPI_NOR_ENUM_TYPE()
> > that must be defined to expand each name to whatever form it's needed.
> >
> > In spi-nor.c, use it to define enumerators, then use the enumerators
> > as indices when defining spi_nor_info so that we cannot accidentally
> > use a name that's not on the list.
> >
> > This is somewhat complicated by the fact that some names include
> > hyphens. SPI_NOR_ENUM_TYPE() therefore takes separate string and C
> > identifier parameters.
>
> Thanks for doing this!
>
> However, the table generation still looks overly complicated to me, with
> too much duplication which needs to be kept in sync.
It does need to be kept in sync, but the compiler will check that.
[...]
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -198,4 +198,76 @@ struct spi_nor {
> > */
> > int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode);
> >
> > +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
> > + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
> > + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
>
> Can't you just have the IDs in a header file only, and let the header file
> generate either a struct flash_info or a struct spi_device_id table, using
> a macro defined by the file that includes it?
How would we match up the rest of the struct flash_info to the name?
> Cfr. include/uapi/asm-generic/unistd.h and its use of __SYSCALL()?
>
> Or am I missing something (e.g. this is impossible due to the hyphens in the
> names?).
Well the hyphens are only a problem because we want C identifiers. But
we only need C identifiers so we can enforce that each struct flash_info
matches a name on the list. If you can find a way to match them up
without having to define enumerators, that would of course be
preferable.
Ben.
--
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140915/90366ebe/attachment.sig>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 2/5] spi-nor: Remove spi_nor::read_id operation
2014-09-15 14:55 ` Huang Shijie
(?)
@ 2014-09-15 15:08 ` Ben Hutchings
-1 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-15 15:08 UTC (permalink / raw)
To: Huang Shijie
Cc: Brian Norris, Geert Uytterhoeven, Andrew Lunn, Jason Cooper,
linux-spi, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]
On Mon, 2014-09-15 at 22:55 +0800, Huang Shijie wrote:
> On Sun, Sep 14, 2014 at 06:11:16PM +0100, Ben Hutchings wrote:
> > There is currently no useful way to override the default
> > implementation of this operation. The returned struct spi_device_id
> > must have a pointer to struct flash_info in its private data, but this
> > structure is defined inside spi-nor.
> >
> > Signed-off-by: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 4 +---
> > include/linux/mtd/spi-nor.h | 3 ---
> > 2 files changed, 1 insertion(+), 6 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index 6b1bda2..6f699c5 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -902,8 +902,6 @@ static int spi_nor_check(struct spi_nor *nor)
> > return -EINVAL;
> > }
> >
> > - if (!nor->read_id)
> > - nor->read_id = spi_nor_read_id;
> > if (!nor->wait_till_ready)
> > nor->wait_till_ready = spi_nor_wait_till_ready;
> >
> > @@ -952,7 +950,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> > if (info->jedec_id) {
> > const struct spi_device_id *jid;
> >
> > - jid = nor->read_id(nor);
> > + jid = spi_nor_read_id(nor);
> > if (IS_ERR(jid)) {
> > return PTR_ERR(jid);
> > } else if (jid != id) {
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index 5ec84cc..66af67a 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -139,8 +139,6 @@ enum spi_nor_ops {
> > * @write_xfer: [OPTIONAL] the writefundamental primitive
> > * @read_reg: [DRIVER-SPECIFIC] read out the register
> > * @write_reg: [DRIVER-SPECIFIC] write data to the register
> > - * @read_id: [REPLACEABLE] read out the ID data, and find
> > - * the proper spi_device_id
> If we remove this hook, i guess we will add it back in the later.
> Other new drivers will use this hook.
>
> so i suggest to keep it as it is.
It may well be needed, but it can't be implemented in its current form.
Ben.
--
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 2/5] spi-nor: Remove spi_nor::read_id operation
@ 2014-09-15 15:08 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-15 15:08 UTC (permalink / raw)
To: Huang Shijie
Cc: Andrew Lunn, Jason Cooper, linux-spi, Geert Uytterhoeven,
Ian Campbell, MTD Maling List, Brian Norris, linux-arm-kernel,
debian-kernel
[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]
On Mon, 2014-09-15 at 22:55 +0800, Huang Shijie wrote:
> On Sun, Sep 14, 2014 at 06:11:16PM +0100, Ben Hutchings wrote:
> > There is currently no useful way to override the default
> > implementation of this operation. The returned struct spi_device_id
> > must have a pointer to struct flash_info in its private data, but this
> > structure is defined inside spi-nor.
> >
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 4 +---
> > include/linux/mtd/spi-nor.h | 3 ---
> > 2 files changed, 1 insertion(+), 6 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index 6b1bda2..6f699c5 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -902,8 +902,6 @@ static int spi_nor_check(struct spi_nor *nor)
> > return -EINVAL;
> > }
> >
> > - if (!nor->read_id)
> > - nor->read_id = spi_nor_read_id;
> > if (!nor->wait_till_ready)
> > nor->wait_till_ready = spi_nor_wait_till_ready;
> >
> > @@ -952,7 +950,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> > if (info->jedec_id) {
> > const struct spi_device_id *jid;
> >
> > - jid = nor->read_id(nor);
> > + jid = spi_nor_read_id(nor);
> > if (IS_ERR(jid)) {
> > return PTR_ERR(jid);
> > } else if (jid != id) {
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index 5ec84cc..66af67a 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -139,8 +139,6 @@ enum spi_nor_ops {
> > * @write_xfer: [OPTIONAL] the writefundamental primitive
> > * @read_reg: [DRIVER-SPECIFIC] read out the register
> > * @write_reg: [DRIVER-SPECIFIC] write data to the register
> > - * @read_id: [REPLACEABLE] read out the ID data, and find
> > - * the proper spi_device_id
> If we remove this hook, i guess we will add it back in the later.
> Other new drivers will use this hook.
>
> so i suggest to keep it as it is.
It may well be needed, but it can't be implemented in its current form.
Ben.
--
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 2/5] spi-nor: Remove spi_nor::read_id operation
@ 2014-09-15 15:08 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-15 15:08 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2014-09-15 at 22:55 +0800, Huang Shijie wrote:
> On Sun, Sep 14, 2014 at 06:11:16PM +0100, Ben Hutchings wrote:
> > There is currently no useful way to override the default
> > implementation of this operation. The returned struct spi_device_id
> > must have a pointer to struct flash_info in its private data, but this
> > structure is defined inside spi-nor.
> >
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 4 +---
> > include/linux/mtd/spi-nor.h | 3 ---
> > 2 files changed, 1 insertion(+), 6 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index 6b1bda2..6f699c5 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -902,8 +902,6 @@ static int spi_nor_check(struct spi_nor *nor)
> > return -EINVAL;
> > }
> >
> > - if (!nor->read_id)
> > - nor->read_id = spi_nor_read_id;
> > if (!nor->wait_till_ready)
> > nor->wait_till_ready = spi_nor_wait_till_ready;
> >
> > @@ -952,7 +950,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> > if (info->jedec_id) {
> > const struct spi_device_id *jid;
> >
> > - jid = nor->read_id(nor);
> > + jid = spi_nor_read_id(nor);
> > if (IS_ERR(jid)) {
> > return PTR_ERR(jid);
> > } else if (jid != id) {
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index 5ec84cc..66af67a 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -139,8 +139,6 @@ enum spi_nor_ops {
> > * @write_xfer: [OPTIONAL] the writefundamental primitive
> > * @read_reg: [DRIVER-SPECIFIC] read out the register
> > * @write_reg: [DRIVER-SPECIFIC] write data to the register
> > - * @read_id: [REPLACEABLE] read out the ID data, and find
> > - * the proper spi_device_id
> If we remove this hook, i guess we will add it back in the later.
> Other new drivers will use this hook.
>
> so i suggest to keep it as it is.
It may well be needed, but it can't be implemented in its current form.
Ben.
--
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140915/950cc586/attachment.sig>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again
2014-09-15 15:07 ` Ben Hutchings
(?)
@ 2014-09-17 8:23 ` Geert Uytterhoeven
-1 siblings, 0 replies; 75+ messages in thread
From: Geert Uytterhoeven @ 2014-09-17 8:23 UTC (permalink / raw)
To: Ben Hutchings
Cc: Brian Norris, Andrew Lunn, Jason Cooper, linux-spi, Huang Shijie,
MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Ben,
On Mon, Sep 15, 2014 at 5:07 PM, Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org> wrote:
>> >
>> > +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
>> > + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
>> > + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
>>
>> Can't you just have the IDs in a header file only, and let the header file
>> generate either a struct flash_info or a struct spi_device_id table, using
>> a macro defined by the file that includes it?
>
> How would we match up the rest of the struct flash_info to the name?
Ah, you use the enums to match the names to the rest of the flash_info.
But you can do it in one-shot, can't you?
spi-nor-data.h:
FLASH_ENTRY("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
FLASH_ENTRY("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
...
m25p80.c:
#define FLASH_ENTRY(_name, _jedec_id, _ext_id, _sector_size,
_n_sectors, _flags) \
{ .name = _name },
static const struct spi_device_id m25p_ids[] = {
#include "spi-nor-data.h"
};
spi-nor.c:
#define FLASH_ENTRY(_name, _jedec_id, _ext_id, _sector_size,
_n_sectors, _flags) \
{ \
.name = _name, \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = 256, \
.flags = (_flags), \
}
static const struct flash_info spi_nor_info[] = {
#include "spi-nor-data.h"
};
Then the whole table data in contained in one place (spi-nor-data.h).
Am I still missing something?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 5/5] m25p80, spi-nor: Share the list of supported chip type names again
@ 2014-09-17 8:23 ` Geert Uytterhoeven
0 siblings, 0 replies; 75+ messages in thread
From: Geert Uytterhoeven @ 2014-09-17 8:23 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Brian Norris, Huang Shijie, linux-arm-kernel,
debian-kernel
Hi Ben,
On Mon, Sep 15, 2014 at 5:07 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
>> >
>> > +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
>> > + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
>> > + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
>>
>> Can't you just have the IDs in a header file only, and let the header file
>> generate either a struct flash_info or a struct spi_device_id table, using
>> a macro defined by the file that includes it?
>
> How would we match up the rest of the struct flash_info to the name?
Ah, you use the enums to match the names to the rest of the flash_info.
But you can do it in one-shot, can't you?
spi-nor-data.h:
FLASH_ENTRY("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
FLASH_ENTRY("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
...
m25p80.c:
#define FLASH_ENTRY(_name, _jedec_id, _ext_id, _sector_size,
_n_sectors, _flags) \
{ .name = _name },
static const struct spi_device_id m25p_ids[] = {
#include "spi-nor-data.h"
};
spi-nor.c:
#define FLASH_ENTRY(_name, _jedec_id, _ext_id, _sector_size,
_n_sectors, _flags) \
{ \
.name = _name, \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = 256, \
.flags = (_flags), \
}
static const struct flash_info spi_nor_info[] = {
#include "spi-nor-data.h"
};
Then the whole table data in contained in one place (spi-nor-data.h).
Am I still missing something?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 5/5] m25p80, spi-nor: Share the list of supported chip type names again
@ 2014-09-17 8:23 ` Geert Uytterhoeven
0 siblings, 0 replies; 75+ messages in thread
From: Geert Uytterhoeven @ 2014-09-17 8:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ben,
On Mon, Sep 15, 2014 at 5:07 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
>> >
>> > +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
>> > + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
>> > + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
>>
>> Can't you just have the IDs in a header file only, and let the header file
>> generate either a struct flash_info or a struct spi_device_id table, using
>> a macro defined by the file that includes it?
>
> How would we match up the rest of the struct flash_info to the name?
Ah, you use the enums to match the names to the rest of the flash_info.
But you can do it in one-shot, can't you?
spi-nor-data.h:
FLASH_ENTRY("at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K),
FLASH_ENTRY("at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K),
...
m25p80.c:
#define FLASH_ENTRY(_name, _jedec_id, _ext_id, _sector_size,
_n_sectors, _flags) \
{ .name = _name },
static const struct spi_device_id m25p_ids[] = {
#include "spi-nor-data.h"
};
spi-nor.c:
#define FLASH_ENTRY(_name, _jedec_id, _ext_id, _sector_size,
_n_sectors, _flags) \
{ \
.name = _name, \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = 256, \
.flags = (_flags), \
}
static const struct flash_info spi_nor_info[] = {
#include "spi-nor-data.h"
};
Then the whole table data in contained in one place (spi-nor-data.h).
Am I still missing something?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
2014-09-14 17:10 ` Ben Hutchings
(?)
@ 2014-09-28 11:35 ` Mark Brown
-1 siblings, 0 replies; 75+ messages in thread
From: Mark Brown @ 2014-09-28 11:35 UTC (permalink / raw)
To: Ben Hutchings
Cc: Brian Norris, Geert Uytterhoeven, Andrew Lunn, Jason Cooper,
linux-spi, Huang Shijie, MTD Maling List, Ian Campbell,
debian-kernel, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
On Sun, Sep 14, 2014 at 06:10:24PM +0100, Ben Hutchings wrote:
> The first patch in the series restores the module aliases to m25p80, but
> it does so by duplicating the list of names. This should be suitable
> for stable, but it isn't viable in the longer term.
Please don't CC patches not for the SPI subsystem to linux-spi, they
just clog up patchwork for no benefit.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-09-28 11:35 ` Mark Brown
0 siblings, 0 replies; 75+ messages in thread
From: Mark Brown @ 2014-09-28 11:35 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Lunn, Jason Cooper, linux-spi, Geert Uytterhoeven,
Ian Campbell, MTD Maling List, Brian Norris, Huang Shijie,
linux-arm-kernel, debian-kernel
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
On Sun, Sep 14, 2014 at 06:10:24PM +0100, Ben Hutchings wrote:
> The first patch in the series restores the module aliases to m25p80, but
> it does so by duplicating the list of names. This should be suitable
> for stable, but it isn't viable in the longer term.
Please don't CC patches not for the SPI subsystem to linux-spi, they
just clog up patchwork for no benefit.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-09-28 11:35 ` Mark Brown
0 siblings, 0 replies; 75+ messages in thread
From: Mark Brown @ 2014-09-28 11:35 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Sep 14, 2014 at 06:10:24PM +0100, Ben Hutchings wrote:
> The first patch in the series restores the module aliases to m25p80, but
> it does so by duplicating the list of names. This should be suitable
> for stable, but it isn't viable in the longer term.
Please don't CC patches not for the SPI subsystem to linux-spi, they
just clog up patchwork for no benefit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140928/d3329005/attachment-0001.sig>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
2014-09-14 17:13 ` Ben Hutchings
(?)
@ 2014-09-28 22:03 ` Brian Norris
-1 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-09-28 22:03 UTC (permalink / raw)
To: Ben Hutchings
Cc: Geert Uytterhoeven, Andrew Lunn, Jason Cooper, linux-spi,
Huang Shijie, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Sun, Sep 14, 2014 at 06:13:15PM +0100, Ben Hutchings wrote:
> On Sun, 2014-09-14 at 18:10 +0100, Ben Hutchings wrote:
> > The first patch in the series restores the module aliases to m25p80, but
> > it does so by duplicating the list of names. This should be suitable
> > for stable, but it isn't viable in the longer term.
> >
> > The following patches change the spi-nor interface so that this
> > duplication is no longer necessary. This includes removing
> > spi_nor::read_id, but it could be re-added after this with a different
> > interface, e.g. returning a flash_info structure (which would need to be
> > defined in spi_nor.h).
>
> Note that these patch are:
> - Based on your 'testing' branch
Which testing branch? These two are the only official
repos for MTD:
git git://git.infradead.org/linux-mtd.git
git git://git.infradead.org/l2-mtd.git
> - Untested by me, aside from compiling and checking that m25p80 has the
> expected module aliases
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-09-28 22:03 ` Brian Norris
0 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-09-28 22:03 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Geert Uytterhoeven, Huang Shijie, linux-arm-kernel,
debian-kernel
On Sun, Sep 14, 2014 at 06:13:15PM +0100, Ben Hutchings wrote:
> On Sun, 2014-09-14 at 18:10 +0100, Ben Hutchings wrote:
> > The first patch in the series restores the module aliases to m25p80, but
> > it does so by duplicating the list of names. This should be suitable
> > for stable, but it isn't viable in the longer term.
> >
> > The following patches change the spi-nor interface so that this
> > duplication is no longer necessary. This includes removing
> > spi_nor::read_id, but it could be re-added after this with a different
> > interface, e.g. returning a flash_info structure (which would need to be
> > defined in spi_nor.h).
>
> Note that these patch are:
> - Based on your 'testing' branch
Which testing branch? These two are the only official
repos for MTD:
git git://git.infradead.org/linux-mtd.git
git git://git.infradead.org/l2-mtd.git
> - Untested by me, aside from compiling and checking that m25p80 has the
> expected module aliases
Brian
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-09-28 22:03 ` Brian Norris
0 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-09-28 22:03 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Sep 14, 2014 at 06:13:15PM +0100, Ben Hutchings wrote:
> On Sun, 2014-09-14 at 18:10 +0100, Ben Hutchings wrote:
> > The first patch in the series restores the module aliases to m25p80, but
> > it does so by duplicating the list of names. This should be suitable
> > for stable, but it isn't viable in the longer term.
> >
> > The following patches change the spi-nor interface so that this
> > duplication is no longer necessary. This includes removing
> > spi_nor::read_id, but it could be re-added after this with a different
> > interface, e.g. returning a flash_info structure (which would need to be
> > defined in spi_nor.h).
>
> Note that these patch are:
> - Based on your 'testing' branch
Which testing branch? These two are the only official
repos for MTD:
git git://git.infradead.org/linux-mtd.git
git git://git.infradead.org/l2-mtd.git
> - Untested by me, aside from compiling and checking that m25p80 has the
> expected module aliases
Brian
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
2014-09-14 17:11 ` Ben Hutchings
(?)
@ 2014-09-28 22:21 ` Brian Norris
-1 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-09-28 22:21 UTC (permalink / raw)
To: Ben Hutchings
Cc: Geert Uytterhoeven, Andrew Lunn, Jason Cooper, linux-spi,
Huang Shijie, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Rafał Miłecki
+ Rafal
Rafal has been looking at the same area of code. I'd really like to get
this patch into 3.18 if possible, so the more eyes the better.
On Sun, Sep 14, 2014 at 06:11:10PM +0100, Ben Hutchings wrote:
> m25p80's device ID table is now spi_nor_ids, defined in spi-nor. The
> MODULE_DEVICE_TABLE() macro doesn't work with extern definitions, but
> its use was also removed at the same time. Now if m25p80 is built as
> a module it doesn't get the necessary aliases to be loaded
> automatically.
>
> A clean solution to this will involve defining the list of device
> IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> API, but this is quite a large change.
>
> As a quick fix suitable for stable, copy the device IDs back into
> m25p80.
>
> Fixes: 03e296f613af ("mtd: m25p80: use the SPI nor framework")
> Cc: stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # 3.16
> Signed-off-by: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
> ---
> drivers/mtd/devices/m25p80.c | 58 +++++++++++++++++++++++++++++++++++++++++--
> drivers/mtd/spi-nor/spi-nor.c | 5 ++--
> include/linux/mtd/spi-nor.h | 3 +--
> 3 files changed, 59 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index ed7e0a1b..3f0fe86 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -196,6 +196,7 @@ static int m25p_probe(struct spi_device *spi)
> struct m25p *flash;
> struct spi_nor *nor;
> enum read_mode mode = SPI_NOR_NORMAL;
> + const struct spi_device_id *id;
> int ret;
>
> flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
> @@ -223,7 +224,10 @@ static int m25p_probe(struct spi_device *spi)
> mode = SPI_NOR_QUAD;
> else if (spi->mode & SPI_RX_DUAL)
> mode = SPI_NOR_DUAL;
> - ret = spi_nor_scan(nor, spi_get_device_id(spi), mode);
> + id = spi_nor_match_id(spi_get_device_id(spi)->name);
> + if (WARN_ON(!id))
> + return -ENODEV;
I'm not confident this logic is sound. And even if it is sound,
does it belong in a patch for stable? You might take a look at Rafal's
patch here:
http://lists.infradead.org/pipermail/linux-mtd/2014-September/055596.html
some of the matching logic is actually done via platform data, and I
don't think this check for spi_nor_match_id() will catch it.
(Honestly, some of this name-matching / ID-matching stuff confuses me;
there is at least one too many ways to choose a flash device for this
driver.)
> + ret = spi_nor_scan(nor, id, mode);
> if (ret)
> return ret;
>
> @@ -245,12 +249,62 @@ static int m25p_remove(struct spi_device *spi)
> }
>
>
> +/*
> + * XXX This needs to be kept in sync with spi_nor_ids. We can't share
> + * it with spi-nor, because if this is built as a module then modpost
> + * won't be able to read it and add appropriate aliases.
> + */
> +static const struct spi_device_id m25p_ids[] = {
> + {"at25fs010"}, {"at25fs040"}, {"at25df041a"}, {"at25df321a"},
> + {"at25df641"}, {"at26f004"}, {"at26df081a"}, {"at26df161a"},
> + {"at26df321"}, {"at45db081d"},
> + {"en25f32"}, {"en25p32"}, {"en25q32b"}, {"en25p64"},
> + {"en25q64"}, {"en25qh128"}, {"en25qh256"},
> + {"f25l32pa"},
> + {"mr25h256"}, {"mr25h10"},
> + {"gd25q32"}, {"gd25q64"},
> + {"160s33b"}, {"320s33b"}, {"640s33b"},
> + {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"}, {"mx25l1606e"},
> + {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
> + {"mx25l12855e"},{"mx25l25635e"},{"mx25l25655e"},{"mx66l51235l"},
> + {"mx66l1g55g"},
> + {"n25q064"}, {"n25q128a11"}, {"n25q128a13"}, {"n25q256a"},
> + {"n25q512a"}, {"n25q512ax3"}, {"n25q00"},
> + {"pm25lv512"}, {"pm25lv010"}, {"pm25lq032"},
> + {"s25sl032p"}, {"s25sl064p"}, {"s25fl256s0"}, {"s25fl256s1"},
> + {"s25fl512s"}, {"s70fl01gs"}, {"s25sl12800"}, {"s25sl12801"},
> + {"s25fl129p0"}, {"s25fl129p1"}, {"s25sl004a"}, {"s25sl008a"},
> + {"s25sl016a"}, {"s25sl032a"}, {"s25sl064a"}, {"s25fl008k"},
> + {"s25fl016k"}, {"s25fl064k"},
> + {"sst25vf040b"},{"sst25vf080b"},{"sst25vf016b"},{"sst25vf032b"},
> + {"sst25vf064c"},{"sst25wf512"}, {"sst25wf010"}, {"sst25wf020"},
> + {"sst25wf040"},
> + {"m25p05"}, {"m25p10"}, {"m25p20"}, {"m25p40"},
> + {"m25p80"}, {"m25p16"}, {"m25p32"}, {"m25p64"},
> + {"m25p128"}, {"n25q032"},
> + {"m25p05-nonjedec"}, {"m25p10-nonjedec"}, {"m25p20-nonjedec"},
> + {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
> + {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
> + {"m45pe10"}, {"m45pe80"}, {"m45pe16"},
> + {"m25pe20"}, {"m25pe80"}, {"m25pe16"},
> + {"m25px16"}, {"m25px32"}, {"m25px32-s0"}, {"m25px32-s1"},
> + {"m25px64"},
> + {"w25x10"}, {"w25x20"}, {"w25x40"}, {"w25x80"},
> + {"w25x16"}, {"w25x32"}, {"w25q32"}, {"w25q32dw"},
> + {"w25x64"}, {"w25q64"}, {"w25q128"}, {"w25q80"},
> + {"w25q80bl"}, {"w25q128"}, {"w25q256"}, {"cat25c11"},
> + {"cat25c03"}, {"cat25c09"}, {"cat25c17"}, {"cat25128"},
> + { },
> +};
> +MODULE_DEVICE_TABLE(spi, m25p_ids);
> +
> +
> static struct spi_driver m25p80_driver = {
> .driver = {
> .name = "m25p80",
> .owner = THIS_MODULE,
> },
> - .id_table = spi_nor_ids,
> + .id_table = m25p_ids,
> .probe = m25p_probe,
> .remove = m25p_remove,
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 03e0ab8..6b1bda2 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -473,7 +473,7 @@ struct flash_info {
> * more nor chips. This current list focusses on newer chips, which
> * have been converging on command sets which including JEDEC ID.
> */
> -const struct spi_device_id spi_nor_ids[] = {
> +static const struct spi_device_id spi_nor_ids[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
> { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
> @@ -637,7 +637,6 @@ const struct spi_device_id spi_nor_ids[] = {
> { "cat25128", CAT25_INFO(2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
> { },
> };
> -EXPORT_SYMBOL_GPL(spi_nor_ids);
>
> static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
> {
> @@ -1136,7 +1135,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> }
> EXPORT_SYMBOL_GPL(spi_nor_scan);
>
> -const struct spi_device_id *spi_nor_match_id(char *name)
> +const struct spi_device_id *spi_nor_match_id(const char *name)
> {
> const struct spi_device_id *id = spi_nor_ids;
>
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 9e6294f..5ec84cc 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -201,7 +201,6 @@ struct spi_nor {
> */
> int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> enum read_mode mode);
> -extern const struct spi_device_id spi_nor_ids[];
>
> /**
> * spi_nor_match_id() - find the spi_device_id by the name
> @@ -213,6 +212,6 @@ extern const struct spi_device_id spi_nor_ids[];
> * Return: returns the right spi_device_id pointer on success,
> * and returns NULL on failure.
> */
> -const struct spi_device_id *spi_nor_match_id(char *name);
> +const struct spi_device_id *spi_nor_match_id(const char *name);
>
> #endif
>
>
But aside from that, I think this patch is OK.
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-28 22:21 ` Brian Norris
0 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-09-28 22:21 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Lunn, Jason Cooper, Rafał Miłecki, linux-spi,
MTD Maling List, Ian Campbell, Geert Uytterhoeven, Huang Shijie,
linux-arm-kernel, debian-kernel
+ Rafal
Rafal has been looking at the same area of code. I'd really like to get
this patch into 3.18 if possible, so the more eyes the better.
On Sun, Sep 14, 2014 at 06:11:10PM +0100, Ben Hutchings wrote:
> m25p80's device ID table is now spi_nor_ids, defined in spi-nor. The
> MODULE_DEVICE_TABLE() macro doesn't work with extern definitions, but
> its use was also removed at the same time. Now if m25p80 is built as
> a module it doesn't get the necessary aliases to be loaded
> automatically.
>
> A clean solution to this will involve defining the list of device
> IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> API, but this is quite a large change.
>
> As a quick fix suitable for stable, copy the device IDs back into
> m25p80.
>
> Fixes: 03e296f613af ("mtd: m25p80: use the SPI nor framework")
> Cc: stable <stable@vger.kernel.org> # 3.16
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> drivers/mtd/devices/m25p80.c | 58 +++++++++++++++++++++++++++++++++++++++++--
> drivers/mtd/spi-nor/spi-nor.c | 5 ++--
> include/linux/mtd/spi-nor.h | 3 +--
> 3 files changed, 59 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index ed7e0a1b..3f0fe86 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -196,6 +196,7 @@ static int m25p_probe(struct spi_device *spi)
> struct m25p *flash;
> struct spi_nor *nor;
> enum read_mode mode = SPI_NOR_NORMAL;
> + const struct spi_device_id *id;
> int ret;
>
> flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
> @@ -223,7 +224,10 @@ static int m25p_probe(struct spi_device *spi)
> mode = SPI_NOR_QUAD;
> else if (spi->mode & SPI_RX_DUAL)
> mode = SPI_NOR_DUAL;
> - ret = spi_nor_scan(nor, spi_get_device_id(spi), mode);
> + id = spi_nor_match_id(spi_get_device_id(spi)->name);
> + if (WARN_ON(!id))
> + return -ENODEV;
I'm not confident this logic is sound. And even if it is sound,
does it belong in a patch for stable? You might take a look at Rafal's
patch here:
http://lists.infradead.org/pipermail/linux-mtd/2014-September/055596.html
some of the matching logic is actually done via platform data, and I
don't think this check for spi_nor_match_id() will catch it.
(Honestly, some of this name-matching / ID-matching stuff confuses me;
there is at least one too many ways to choose a flash device for this
driver.)
> + ret = spi_nor_scan(nor, id, mode);
> if (ret)
> return ret;
>
> @@ -245,12 +249,62 @@ static int m25p_remove(struct spi_device *spi)
> }
>
>
> +/*
> + * XXX This needs to be kept in sync with spi_nor_ids. We can't share
> + * it with spi-nor, because if this is built as a module then modpost
> + * won't be able to read it and add appropriate aliases.
> + */
> +static const struct spi_device_id m25p_ids[] = {
> + {"at25fs010"}, {"at25fs040"}, {"at25df041a"}, {"at25df321a"},
> + {"at25df641"}, {"at26f004"}, {"at26df081a"}, {"at26df161a"},
> + {"at26df321"}, {"at45db081d"},
> + {"en25f32"}, {"en25p32"}, {"en25q32b"}, {"en25p64"},
> + {"en25q64"}, {"en25qh128"}, {"en25qh256"},
> + {"f25l32pa"},
> + {"mr25h256"}, {"mr25h10"},
> + {"gd25q32"}, {"gd25q64"},
> + {"160s33b"}, {"320s33b"}, {"640s33b"},
> + {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"}, {"mx25l1606e"},
> + {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
> + {"mx25l12855e"},{"mx25l25635e"},{"mx25l25655e"},{"mx66l51235l"},
> + {"mx66l1g55g"},
> + {"n25q064"}, {"n25q128a11"}, {"n25q128a13"}, {"n25q256a"},
> + {"n25q512a"}, {"n25q512ax3"}, {"n25q00"},
> + {"pm25lv512"}, {"pm25lv010"}, {"pm25lq032"},
> + {"s25sl032p"}, {"s25sl064p"}, {"s25fl256s0"}, {"s25fl256s1"},
> + {"s25fl512s"}, {"s70fl01gs"}, {"s25sl12800"}, {"s25sl12801"},
> + {"s25fl129p0"}, {"s25fl129p1"}, {"s25sl004a"}, {"s25sl008a"},
> + {"s25sl016a"}, {"s25sl032a"}, {"s25sl064a"}, {"s25fl008k"},
> + {"s25fl016k"}, {"s25fl064k"},
> + {"sst25vf040b"},{"sst25vf080b"},{"sst25vf016b"},{"sst25vf032b"},
> + {"sst25vf064c"},{"sst25wf512"}, {"sst25wf010"}, {"sst25wf020"},
> + {"sst25wf040"},
> + {"m25p05"}, {"m25p10"}, {"m25p20"}, {"m25p40"},
> + {"m25p80"}, {"m25p16"}, {"m25p32"}, {"m25p64"},
> + {"m25p128"}, {"n25q032"},
> + {"m25p05-nonjedec"}, {"m25p10-nonjedec"}, {"m25p20-nonjedec"},
> + {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
> + {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
> + {"m45pe10"}, {"m45pe80"}, {"m45pe16"},
> + {"m25pe20"}, {"m25pe80"}, {"m25pe16"},
> + {"m25px16"}, {"m25px32"}, {"m25px32-s0"}, {"m25px32-s1"},
> + {"m25px64"},
> + {"w25x10"}, {"w25x20"}, {"w25x40"}, {"w25x80"},
> + {"w25x16"}, {"w25x32"}, {"w25q32"}, {"w25q32dw"},
> + {"w25x64"}, {"w25q64"}, {"w25q128"}, {"w25q80"},
> + {"w25q80bl"}, {"w25q128"}, {"w25q256"}, {"cat25c11"},
> + {"cat25c03"}, {"cat25c09"}, {"cat25c17"}, {"cat25128"},
> + { },
> +};
> +MODULE_DEVICE_TABLE(spi, m25p_ids);
> +
> +
> static struct spi_driver m25p80_driver = {
> .driver = {
> .name = "m25p80",
> .owner = THIS_MODULE,
> },
> - .id_table = spi_nor_ids,
> + .id_table = m25p_ids,
> .probe = m25p_probe,
> .remove = m25p_remove,
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 03e0ab8..6b1bda2 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -473,7 +473,7 @@ struct flash_info {
> * more nor chips. This current list focusses on newer chips, which
> * have been converging on command sets which including JEDEC ID.
> */
> -const struct spi_device_id spi_nor_ids[] = {
> +static const struct spi_device_id spi_nor_ids[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
> { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
> @@ -637,7 +637,6 @@ const struct spi_device_id spi_nor_ids[] = {
> { "cat25128", CAT25_INFO(2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
> { },
> };
> -EXPORT_SYMBOL_GPL(spi_nor_ids);
>
> static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
> {
> @@ -1136,7 +1135,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> }
> EXPORT_SYMBOL_GPL(spi_nor_scan);
>
> -const struct spi_device_id *spi_nor_match_id(char *name)
> +const struct spi_device_id *spi_nor_match_id(const char *name)
> {
> const struct spi_device_id *id = spi_nor_ids;
>
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 9e6294f..5ec84cc 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -201,7 +201,6 @@ struct spi_nor {
> */
> int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> enum read_mode mode);
> -extern const struct spi_device_id spi_nor_ids[];
>
> /**
> * spi_nor_match_id() - find the spi_device_id by the name
> @@ -213,6 +212,6 @@ extern const struct spi_device_id spi_nor_ids[];
> * Return: returns the right spi_device_id pointer on success,
> * and returns NULL on failure.
> */
> -const struct spi_device_id *spi_nor_match_id(char *name);
> +const struct spi_device_id *spi_nor_match_id(const char *name);
>
> #endif
>
>
But aside from that, I think this patch is OK.
Brian
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-28 22:21 ` Brian Norris
0 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-09-28 22:21 UTC (permalink / raw)
To: linux-arm-kernel
+ Rafal
Rafal has been looking at the same area of code. I'd really like to get
this patch into 3.18 if possible, so the more eyes the better.
On Sun, Sep 14, 2014 at 06:11:10PM +0100, Ben Hutchings wrote:
> m25p80's device ID table is now spi_nor_ids, defined in spi-nor. The
> MODULE_DEVICE_TABLE() macro doesn't work with extern definitions, but
> its use was also removed at the same time. Now if m25p80 is built as
> a module it doesn't get the necessary aliases to be loaded
> automatically.
>
> A clean solution to this will involve defining the list of device
> IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> API, but this is quite a large change.
>
> As a quick fix suitable for stable, copy the device IDs back into
> m25p80.
>
> Fixes: 03e296f613af ("mtd: m25p80: use the SPI nor framework")
> Cc: stable <stable@vger.kernel.org> # 3.16
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> drivers/mtd/devices/m25p80.c | 58 +++++++++++++++++++++++++++++++++++++++++--
> drivers/mtd/spi-nor/spi-nor.c | 5 ++--
> include/linux/mtd/spi-nor.h | 3 +--
> 3 files changed, 59 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index ed7e0a1b..3f0fe86 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -196,6 +196,7 @@ static int m25p_probe(struct spi_device *spi)
> struct m25p *flash;
> struct spi_nor *nor;
> enum read_mode mode = SPI_NOR_NORMAL;
> + const struct spi_device_id *id;
> int ret;
>
> flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL);
> @@ -223,7 +224,10 @@ static int m25p_probe(struct spi_device *spi)
> mode = SPI_NOR_QUAD;
> else if (spi->mode & SPI_RX_DUAL)
> mode = SPI_NOR_DUAL;
> - ret = spi_nor_scan(nor, spi_get_device_id(spi), mode);
> + id = spi_nor_match_id(spi_get_device_id(spi)->name);
> + if (WARN_ON(!id))
> + return -ENODEV;
I'm not confident this logic is sound. And even if it is sound,
does it belong in a patch for stable? You might take a look at Rafal's
patch here:
http://lists.infradead.org/pipermail/linux-mtd/2014-September/055596.html
some of the matching logic is actually done via platform data, and I
don't think this check for spi_nor_match_id() will catch it.
(Honestly, some of this name-matching / ID-matching stuff confuses me;
there is at least one too many ways to choose a flash device for this
driver.)
> + ret = spi_nor_scan(nor, id, mode);
> if (ret)
> return ret;
>
> @@ -245,12 +249,62 @@ static int m25p_remove(struct spi_device *spi)
> }
>
>
> +/*
> + * XXX This needs to be kept in sync with spi_nor_ids. We can't share
> + * it with spi-nor, because if this is built as a module then modpost
> + * won't be able to read it and add appropriate aliases.
> + */
> +static const struct spi_device_id m25p_ids[] = {
> + {"at25fs010"}, {"at25fs040"}, {"at25df041a"}, {"at25df321a"},
> + {"at25df641"}, {"at26f004"}, {"at26df081a"}, {"at26df161a"},
> + {"at26df321"}, {"at45db081d"},
> + {"en25f32"}, {"en25p32"}, {"en25q32b"}, {"en25p64"},
> + {"en25q64"}, {"en25qh128"}, {"en25qh256"},
> + {"f25l32pa"},
> + {"mr25h256"}, {"mr25h10"},
> + {"gd25q32"}, {"gd25q64"},
> + {"160s33b"}, {"320s33b"}, {"640s33b"},
> + {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"}, {"mx25l1606e"},
> + {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
> + {"mx25l12855e"},{"mx25l25635e"},{"mx25l25655e"},{"mx66l51235l"},
> + {"mx66l1g55g"},
> + {"n25q064"}, {"n25q128a11"}, {"n25q128a13"}, {"n25q256a"},
> + {"n25q512a"}, {"n25q512ax3"}, {"n25q00"},
> + {"pm25lv512"}, {"pm25lv010"}, {"pm25lq032"},
> + {"s25sl032p"}, {"s25sl064p"}, {"s25fl256s0"}, {"s25fl256s1"},
> + {"s25fl512s"}, {"s70fl01gs"}, {"s25sl12800"}, {"s25sl12801"},
> + {"s25fl129p0"}, {"s25fl129p1"}, {"s25sl004a"}, {"s25sl008a"},
> + {"s25sl016a"}, {"s25sl032a"}, {"s25sl064a"}, {"s25fl008k"},
> + {"s25fl016k"}, {"s25fl064k"},
> + {"sst25vf040b"},{"sst25vf080b"},{"sst25vf016b"},{"sst25vf032b"},
> + {"sst25vf064c"},{"sst25wf512"}, {"sst25wf010"}, {"sst25wf020"},
> + {"sst25wf040"},
> + {"m25p05"}, {"m25p10"}, {"m25p20"}, {"m25p40"},
> + {"m25p80"}, {"m25p16"}, {"m25p32"}, {"m25p64"},
> + {"m25p128"}, {"n25q032"},
> + {"m25p05-nonjedec"}, {"m25p10-nonjedec"}, {"m25p20-nonjedec"},
> + {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
> + {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
> + {"m45pe10"}, {"m45pe80"}, {"m45pe16"},
> + {"m25pe20"}, {"m25pe80"}, {"m25pe16"},
> + {"m25px16"}, {"m25px32"}, {"m25px32-s0"}, {"m25px32-s1"},
> + {"m25px64"},
> + {"w25x10"}, {"w25x20"}, {"w25x40"}, {"w25x80"},
> + {"w25x16"}, {"w25x32"}, {"w25q32"}, {"w25q32dw"},
> + {"w25x64"}, {"w25q64"}, {"w25q128"}, {"w25q80"},
> + {"w25q80bl"}, {"w25q128"}, {"w25q256"}, {"cat25c11"},
> + {"cat25c03"}, {"cat25c09"}, {"cat25c17"}, {"cat25128"},
> + { },
> +};
> +MODULE_DEVICE_TABLE(spi, m25p_ids);
> +
> +
> static struct spi_driver m25p80_driver = {
> .driver = {
> .name = "m25p80",
> .owner = THIS_MODULE,
> },
> - .id_table = spi_nor_ids,
> + .id_table = m25p_ids,
> .probe = m25p_probe,
> .remove = m25p_remove,
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 03e0ab8..6b1bda2 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -473,7 +473,7 @@ struct flash_info {
> * more nor chips. This current list focusses on newer chips, which
> * have been converging on command sets which including JEDEC ID.
> */
> -const struct spi_device_id spi_nor_ids[] = {
> +static const struct spi_device_id spi_nor_ids[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
> { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
> @@ -637,7 +637,6 @@ const struct spi_device_id spi_nor_ids[] = {
> { "cat25128", CAT25_INFO(2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
> { },
> };
> -EXPORT_SYMBOL_GPL(spi_nor_ids);
>
> static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
> {
> @@ -1136,7 +1135,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> }
> EXPORT_SYMBOL_GPL(spi_nor_scan);
>
> -const struct spi_device_id *spi_nor_match_id(char *name)
> +const struct spi_device_id *spi_nor_match_id(const char *name)
> {
> const struct spi_device_id *id = spi_nor_ids;
>
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 9e6294f..5ec84cc 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -201,7 +201,6 @@ struct spi_nor {
> */
> int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
> enum read_mode mode);
> -extern const struct spi_device_id spi_nor_ids[];
>
> /**
> * spi_nor_match_id() - find the spi_device_id by the name
> @@ -213,6 +212,6 @@ extern const struct spi_device_id spi_nor_ids[];
> * Return: returns the right spi_device_id pointer on success,
> * and returns NULL on failure.
> */
> -const struct spi_device_id *spi_nor_match_id(char *name);
> +const struct spi_device_id *spi_nor_match_id(const char *name);
>
> #endif
>
>
But aside from that, I think this patch is OK.
Brian
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
2014-09-28 22:21 ` Brian Norris
(?)
@ 2014-09-29 6:36 ` Rafał Miłecki
-1 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 6:36 UTC (permalink / raw)
To: Brian Norris
Cc: Ben Hutchings, Geert Uytterhoeven, Andrew Lunn, Jason Cooper,
linux-spi, Huang Shijie, MTD Maling List, Ian Campbell,
debian-kernel, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 29 September 2014 00:21, Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> + Rafal
>
> Rafal has been looking at the same area of code. I'd really like to get
> this patch into 3.18 if possible, so the more eyes the better.
Thanks Brian.
I took me a while to follow this issue, too bad I wasn't subscribed to
the ML earlier. Let me try to sum it up.
1) The main urgent issue: broken auto-loading
Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
Problem: m25p80.c references spi_nor_ids (from external file)
Short-term solution: duplicate IDs in the m25p80.c
Ben: just like Brian, I think the patch like this one (
[PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
) is the way to go. However few comments:
a) I don't see why you modify m25p_probe in it.
b) I don't think the described clean solution (you described it in the
commit message):
> A clean solution to this will involve defining the list of device
> IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> API, but this is quite a large change.
is the correct one. I think there should be a single string to trigger
m25p80 load and the rest should be handled using JEDEC, with some
workarounds for incompatible devices only.
One thing I wonder about is sense of pushing this patch to the Linus's
tree. Do you think we could prepare a real fix for Linus and leave
this patch for stable@ only? I'm far from being an expert on such
things, just asking.
2) On going cleanups
It seems there are at least 2 ppl (me, Ben) working on some cleanups
independently.
a) There is (l2-mtd pushed) patch moving flash_platform_data into m25p80:
https://patchwork.ozlabs.org/patch/394219/
b) Removing spi_nor::read_id
https://patchwork.ozlabs.org/patch/389073/
Ben: I think this one has a NACK from me, because I'm going to use
custom read_id in the bcm53xxspiflash driver.
See following thread for bcm53xxspiflash description:
http://comments.gmane.org/gmane.linux.drivers.mtd/54578
Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
c) Obsoleting spi_device_id
It seems we both were working on the same thing, me slightly slower however ;)
https://patchwork.ozlabs.org/patch/377917/
https://patchwork.ozlabs.org/patch/389074/
https://patchwork.ozlabs.org/patch/389075/
I still have to review calmly your changes, but they need to be rebased anyway.
d) Cleaning m25p80
https://patchwork.ozlabs.org/patch/389076/
Ben: As said before, I think we should do smarter in the m25p80. We
should get rid of all that duplicated strings.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-29 6:36 ` Rafał Miłecki
0 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 6:36 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, Huang Shijie, linux-spi,
Geert Uytterhoeven, Ian Campbell, MTD Maling List, Ben Hutchings,
linux-arm-kernel, debian-kernel
On 29 September 2014 00:21, Brian Norris <computersforpeace@gmail.com> wrote:
> + Rafal
>
> Rafal has been looking at the same area of code. I'd really like to get
> this patch into 3.18 if possible, so the more eyes the better.
Thanks Brian.
I took me a while to follow this issue, too bad I wasn't subscribed to
the ML earlier. Let me try to sum it up.
1) The main urgent issue: broken auto-loading
Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
Problem: m25p80.c references spi_nor_ids (from external file)
Short-term solution: duplicate IDs in the m25p80.c
Ben: just like Brian, I think the patch like this one (
[PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
) is the way to go. However few comments:
a) I don't see why you modify m25p_probe in it.
b) I don't think the described clean solution (you described it in the
commit message):
> A clean solution to this will involve defining the list of device
> IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> API, but this is quite a large change.
is the correct one. I think there should be a single string to trigger
m25p80 load and the rest should be handled using JEDEC, with some
workarounds for incompatible devices only.
One thing I wonder about is sense of pushing this patch to the Linus's
tree. Do you think we could prepare a real fix for Linus and leave
this patch for stable@ only? I'm far from being an expert on such
things, just asking.
2) On going cleanups
It seems there are at least 2 ppl (me, Ben) working on some cleanups
independently.
a) There is (l2-mtd pushed) patch moving flash_platform_data into m25p80:
https://patchwork.ozlabs.org/patch/394219/
b) Removing spi_nor::read_id
https://patchwork.ozlabs.org/patch/389073/
Ben: I think this one has a NACK from me, because I'm going to use
custom read_id in the bcm53xxspiflash driver.
See following thread for bcm53xxspiflash description:
http://comments.gmane.org/gmane.linux.drivers.mtd/54578
Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
c) Obsoleting spi_device_id
It seems we both were working on the same thing, me slightly slower however ;)
https://patchwork.ozlabs.org/patch/377917/
https://patchwork.ozlabs.org/patch/389074/
https://patchwork.ozlabs.org/patch/389075/
I still have to review calmly your changes, but they need to be rebased anyway.
d) Cleaning m25p80
https://patchwork.ozlabs.org/patch/389076/
Ben: As said before, I think we should do smarter in the m25p80. We
should get rid of all that duplicated strings.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-29 6:36 ` Rafał Miłecki
0 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 6:36 UTC (permalink / raw)
To: linux-arm-kernel
On 29 September 2014 00:21, Brian Norris <computersforpeace@gmail.com> wrote:
> + Rafal
>
> Rafal has been looking at the same area of code. I'd really like to get
> this patch into 3.18 if possible, so the more eyes the better.
Thanks Brian.
I took me a while to follow this issue, too bad I wasn't subscribed to
the ML earlier. Let me try to sum it up.
1) The main urgent issue: broken auto-loading
Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
Problem: m25p80.c references spi_nor_ids (from external file)
Short-term solution: duplicate IDs in the m25p80.c
Ben: just like Brian, I think the patch like this one (
[PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
) is the way to go. However few comments:
a) I don't see why you modify m25p_probe in it.
b) I don't think the described clean solution (you described it in the
commit message):
> A clean solution to this will involve defining the list of device
> IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> API, but this is quite a large change.
is the correct one. I think there should be a single string to trigger
m25p80 load and the rest should be handled using JEDEC, with some
workarounds for incompatible devices only.
One thing I wonder about is sense of pushing this patch to the Linus's
tree. Do you think we could prepare a real fix for Linus and leave
this patch for stable@ only? I'm far from being an expert on such
things, just asking.
2) On going cleanups
It seems there are at least 2 ppl (me, Ben) working on some cleanups
independently.
a) There is (l2-mtd pushed) patch moving flash_platform_data into m25p80:
https://patchwork.ozlabs.org/patch/394219/
b) Removing spi_nor::read_id
https://patchwork.ozlabs.org/patch/389073/
Ben: I think this one has a NACK from me, because I'm going to use
custom read_id in the bcm53xxspiflash driver.
See following thread for bcm53xxspiflash description:
http://comments.gmane.org/gmane.linux.drivers.mtd/54578
Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
c) Obsoleting spi_device_id
It seems we both were working on the same thing, me slightly slower however ;)
https://patchwork.ozlabs.org/patch/377917/
https://patchwork.ozlabs.org/patch/389074/
https://patchwork.ozlabs.org/patch/389075/
I still have to review calmly your changes, but they need to be rebased anyway.
d) Cleaning m25p80
https://patchwork.ozlabs.org/patch/389076/
Ben: As said before, I think we should do smarter in the m25p80. We
should get rid of all that duplicated strings.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
2014-09-28 22:21 ` Brian Norris
(?)
@ 2014-09-29 8:37 ` Rafał Miłecki
-1 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 8:37 UTC (permalink / raw)
To: Brian Norris
Cc: Ben Hutchings, Geert Uytterhoeven, Andrew Lunn, Jason Cooper,
linux-spi, Huang Shijie, MTD Maling List, Ian Campbell,
debian-kernel, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 29 September 2014 00:21, Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> (Honestly, some of this name-matching / ID-matching stuff confuses me;
> there is at least one too many ways to choose a flash device for this
> driver.)
It's not that complex once you track it. It's just ugly to tracks
because of different structs, function calls and code locations.
1) All m25p80 users (arch code, SPI drivers, etc.) register
struct spi_board_info
that contains "modalias". It it used to match a driver to load.
In most (?) cases modalias is set to "m25p80"
2) Some m25p80 users decided to put a flash device name (e.g.
"at25fs010", "mx25l2005a", "m25p05", "w25x10") as modalias of the
struct spi_board_info. I think they are affected by the recent m25p80
change to use spi-not framework.
3) Other m25p80 users provide flash device name (e.g. "at25fs010",
"mx25l2005a", "m25p05", "w25x10") using platform_data in the struct
spi_board_info. It points to the struct flash_platform_data with
"name" and "type" properties. It seems to me that "name" is never
used.
My idea for fixing this:
1) Always use "m25p80" modalias (for m25p80 compatible hw).
This will make m25p80 driver work without this huge id_table
2) Do not use "name" nor "type" in the struct flash_platform_data if
the flash supports JEDEC
3) If the flash is m25p80 compatible, but doesn't support JEDEC, let's
use "type" to let m25p80 work.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-29 8:37 ` Rafał Miłecki
0 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 8:37 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, Huang Shijie, linux-spi,
Geert Uytterhoeven, Ian Campbell, MTD Maling List, Ben Hutchings,
linux-arm-kernel, debian-kernel
On 29 September 2014 00:21, Brian Norris <computersforpeace@gmail.com> wrote:
> (Honestly, some of this name-matching / ID-matching stuff confuses me;
> there is at least one too many ways to choose a flash device for this
> driver.)
It's not that complex once you track it. It's just ugly to tracks
because of different structs, function calls and code locations.
1) All m25p80 users (arch code, SPI drivers, etc.) register
struct spi_board_info
that contains "modalias". It it used to match a driver to load.
In most (?) cases modalias is set to "m25p80"
2) Some m25p80 users decided to put a flash device name (e.g.
"at25fs010", "mx25l2005a", "m25p05", "w25x10") as modalias of the
struct spi_board_info. I think they are affected by the recent m25p80
change to use spi-not framework.
3) Other m25p80 users provide flash device name (e.g. "at25fs010",
"mx25l2005a", "m25p05", "w25x10") using platform_data in the struct
spi_board_info. It points to the struct flash_platform_data with
"name" and "type" properties. It seems to me that "name" is never
used.
My idea for fixing this:
1) Always use "m25p80" modalias (for m25p80 compatible hw).
This will make m25p80 driver work without this huge id_table
2) Do not use "name" nor "type" in the struct flash_platform_data if
the flash supports JEDEC
3) If the flash is m25p80 compatible, but doesn't support JEDEC, let's
use "type" to let m25p80 work.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-29 8:37 ` Rafał Miłecki
0 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 8:37 UTC (permalink / raw)
To: linux-arm-kernel
On 29 September 2014 00:21, Brian Norris <computersforpeace@gmail.com> wrote:
> (Honestly, some of this name-matching / ID-matching stuff confuses me;
> there is at least one too many ways to choose a flash device for this
> driver.)
It's not that complex once you track it. It's just ugly to tracks
because of different structs, function calls and code locations.
1) All m25p80 users (arch code, SPI drivers, etc.) register
struct spi_board_info
that contains "modalias". It it used to match a driver to load.
In most (?) cases modalias is set to "m25p80"
2) Some m25p80 users decided to put a flash device name (e.g.
"at25fs010", "mx25l2005a", "m25p05", "w25x10") as modalias of the
struct spi_board_info. I think they are affected by the recent m25p80
change to use spi-not framework.
3) Other m25p80 users provide flash device name (e.g. "at25fs010",
"mx25l2005a", "m25p05", "w25x10") using platform_data in the struct
spi_board_info. It points to the struct flash_platform_data with
"name" and "type" properties. It seems to me that "name" is never
used.
My idea for fixing this:
1) Always use "m25p80" modalias (for m25p80 compatible hw).
This will make m25p80 driver work without this huge id_table
2) Do not use "name" nor "type" in the struct flash_platform_data if
the flash supports JEDEC
3) If the flash is m25p80 compatible, but doesn't support JEDEC, let's
use "type" to let m25p80 work.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
2014-09-29 6:36 ` Rafał Miłecki
(?)
@ 2014-09-29 9:53 ` Rafał Miłecki
-1 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 9:53 UTC (permalink / raw)
To: Brian Norris
Cc: Ben Hutchings, Geert Uytterhoeven, Andrew Lunn, Jason Cooper,
linux-spi, Huang Shijie, MTD Maling List, Ian Campbell,
debian-kernel, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 29 September 2014 08:36, Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 1) The main urgent issue: broken auto-loading
> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
> Problem: m25p80.c references spi_nor_ids (from external file)
> Short-term solution: duplicate IDs in the m25p80.c
>
> Ben: just like Brian, I think the patch like this one (
> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
> ) is the way to go. However few comments:
I started wondering... would this be possible to fix all m25p80 users
instead? Make them always specify modalias as "m25p80" and then
provide platform_data if needed?
Has anyone checked in how many places we use "wrong" (or should I say
"weird") modaliases? I guess some would need to grep kernel for all
possible names.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-29 9:53 ` Rafał Miłecki
0 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 9:53 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, Huang Shijie, linux-spi,
Geert Uytterhoeven, Ian Campbell, MTD Maling List, Ben Hutchings,
linux-arm-kernel, debian-kernel
On 29 September 2014 08:36, Rafał Miłecki <zajec5@gmail.com> wrote:
> 1) The main urgent issue: broken auto-loading
> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
> Problem: m25p80.c references spi_nor_ids (from external file)
> Short-term solution: duplicate IDs in the m25p80.c
>
> Ben: just like Brian, I think the patch like this one (
> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
> ) is the way to go. However few comments:
I started wondering... would this be possible to fix all m25p80 users
instead? Make them always specify modalias as "m25p80" and then
provide platform_data if needed?
Has anyone checked in how many places we use "wrong" (or should I say
"weird") modaliases? I guess some would need to grep kernel for all
possible names.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-29 9:53 ` Rafał Miłecki
0 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 9:53 UTC (permalink / raw)
To: linux-arm-kernel
On 29 September 2014 08:36, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> 1) The main urgent issue: broken auto-loading
> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
> Problem: m25p80.c references spi_nor_ids (from external file)
> Short-term solution: duplicate IDs in the m25p80.c
>
> Ben: just like Brian, I think the patch like this one (
> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
> ) is the way to go. However few comments:
I started wondering... would this be possible to fix all m25p80 users
instead? Make them always specify modalias as "m25p80" and then
provide platform_data if needed?
Has anyone checked in how many places we use "wrong" (or should I say
"weird") modaliases? I guess some would need to grep kernel for all
possible names.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
2014-09-29 9:53 ` Rafał Miłecki
(?)
@ 2014-09-29 10:25 ` Rafał Miłecki
-1 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 10:25 UTC (permalink / raw)
To: Brian Norris
Cc: Ben Hutchings, Geert Uytterhoeven, Andrew Lunn, Jason Cooper,
linux-spi, Huang Shijie, MTD Maling List, Ian Campbell,
debian-kernel, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 29 September 2014 11:53, Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 29 September 2014 08:36, Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> 1) The main urgent issue: broken auto-loading
>> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
>> Problem: m25p80.c references spi_nor_ids (from external file)
>> Short-term solution: duplicate IDs in the m25p80.c
>>
>> Ben: just like Brian, I think the patch like this one (
>> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
>> ) is the way to go. However few comments:
>
> I started wondering... would this be possible to fix all m25p80 users
> instead? Make them always specify modalias as "m25p80" and then
> provide platform_data if needed?
>
> Has anyone checked in how many places we use "wrong" (or should I say
> "weird") modaliases? I guess some would need to grep kernel for all
> possible names.
I did some (e)grepping, it seems we have:
1) Only 6 references (modalias) in arch/mips/ath79/
2) About 57 references (compatible) in arch/arm/boot/dts/
3) About 32 references (compatible) in arch/powerpc/boot/dts/
However it seems there is no way to provide platform_data in Device
Tree files. So we have to support compatible (modalias) for now I
guess.
The list (if someone would like to check) of used names in archs:
m25p128 m25p16 m25p32 m25p40 m25p64
mx25l12805d mx25l1606e mx25l25635e mx25l4005a mx25l6405d mx66l51235l
n25q128a11 n25q128a13 n25q512a
s25fl008k s25fl256s1 s25fl512s s25sl064a s25sl12801
sst25vf016b sst25vf032b sst25vf040b sst25wf040
w25q128 w25q256 w25q32 w25q32dw w25q80bl w25x80
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-29 10:25 ` Rafał Miłecki
0 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 10:25 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, Huang Shijie, linux-spi,
Geert Uytterhoeven, Ian Campbell, MTD Maling List, Ben Hutchings,
linux-arm-kernel, debian-kernel
On 29 September 2014 11:53, Rafał Miłecki <zajec5@gmail.com> wrote:
> On 29 September 2014 08:36, Rafał Miłecki <zajec5@gmail.com> wrote:
>> 1) The main urgent issue: broken auto-loading
>> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
>> Problem: m25p80.c references spi_nor_ids (from external file)
>> Short-term solution: duplicate IDs in the m25p80.c
>>
>> Ben: just like Brian, I think the patch like this one (
>> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
>> ) is the way to go. However few comments:
>
> I started wondering... would this be possible to fix all m25p80 users
> instead? Make them always specify modalias as "m25p80" and then
> provide platform_data if needed?
>
> Has anyone checked in how many places we use "wrong" (or should I say
> "weird") modaliases? I guess some would need to grep kernel for all
> possible names.
I did some (e)grepping, it seems we have:
1) Only 6 references (modalias) in arch/mips/ath79/
2) About 57 references (compatible) in arch/arm/boot/dts/
3) About 32 references (compatible) in arch/powerpc/boot/dts/
However it seems there is no way to provide platform_data in Device
Tree files. So we have to support compatible (modalias) for now I
guess.
The list (if someone would like to check) of used names in archs:
m25p128 m25p16 m25p32 m25p40 m25p64
mx25l12805d mx25l1606e mx25l25635e mx25l4005a mx25l6405d mx66l51235l
n25q128a11 n25q128a13 n25q512a
s25fl008k s25fl256s1 s25fl512s s25sl064a s25sl12801
sst25vf016b sst25vf032b sst25vf040b sst25wf040
w25q128 w25q256 w25q32 w25q32dw w25q80bl w25x80
--
Rafał
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-29 10:25 ` Rafał Miłecki
0 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-29 10:25 UTC (permalink / raw)
To: linux-arm-kernel
On 29 September 2014 11:53, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> On 29 September 2014 08:36, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>> 1) The main urgent issue: broken auto-loading
>> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
>> Problem: m25p80.c references spi_nor_ids (from external file)
>> Short-term solution: duplicate IDs in the m25p80.c
>>
>> Ben: just like Brian, I think the patch like this one (
>> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
>> ) is the way to go. However few comments:
>
> I started wondering... would this be possible to fix all m25p80 users
> instead? Make them always specify modalias as "m25p80" and then
> provide platform_data if needed?
>
> Has anyone checked in how many places we use "wrong" (or should I say
> "weird") modaliases? I guess some would need to grep kernel for all
> possible names.
I did some (e)grepping, it seems we have:
1) Only 6 references (modalias) in arch/mips/ath79/
2) About 57 references (compatible) in arch/arm/boot/dts/
3) About 32 references (compatible) in arch/powerpc/boot/dts/
However it seems there is no way to provide platform_data in Device
Tree files. So we have to support compatible (modalias) for now I
guess.
The list (if someone would like to check) of used names in archs:
m25p128 m25p16 m25p32 m25p40 m25p64
mx25l12805d mx25l1606e mx25l25635e mx25l4005a mx25l6405d mx66l51235l
n25q128a11 n25q128a13 n25q512a
s25fl008k s25fl256s1 s25fl512s s25sl064a s25sl12801
sst25vf016b sst25vf032b sst25vf040b sst25wf040
w25q128 w25q256 w25q32 w25q32dw w25q80bl w25x80
--
Rafa?
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
2014-09-28 22:03 ` Brian Norris
(?)
@ 2014-09-30 1:47 ` Ben Hutchings
-1 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-30 1:47 UTC (permalink / raw)
To: Brian Norris
Cc: Geert Uytterhoeven, Andrew Lunn, Jason Cooper, linux-spi,
Huang Shijie, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]
On Sun, 2014-09-28 at 15:03 -0700, Brian Norris wrote:
> On Sun, Sep 14, 2014 at 06:13:15PM +0100, Ben Hutchings wrote:
> > On Sun, 2014-09-14 at 18:10 +0100, Ben Hutchings wrote:
> > > The first patch in the series restores the module aliases to m25p80, but
> > > it does so by duplicating the list of names. This should be suitable
> > > for stable, but it isn't viable in the longer term.
> > >
> > > The following patches change the spi-nor interface so that this
> > > duplication is no longer necessary. This includes removing
> > > spi_nor::read_id, but it could be re-added after this with a different
> > > interface, e.g. returning a flash_info structure (which would need to be
> > > defined in spi_nor.h).
> >
> > Note that these patch are:
> > - Based on your 'testing' branch
>
> Which testing branch? These two are the only official
> repos for MTD:
>
> git git://git.infradead.org/linux-mtd.git
> git git://git.infradead.org/l2-mtd.git
You had a testing branch in
git://git.infradead.org/users/norris/linux-mtd.git, and that included
commit af249c3a0ca8 ('mtd: spi-nor: remove duplicated w25q128 entry')
which this patch series depended on.
Ben.
> > - Untested by me, aside from compiling and checking that m25p80 has the
> > expected module aliases
>
> Brian
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-09-30 1:47 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-30 1:47 UTC (permalink / raw)
To: Brian Norris
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Geert Uytterhoeven, Huang Shijie, linux-arm-kernel,
debian-kernel
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]
On Sun, 2014-09-28 at 15:03 -0700, Brian Norris wrote:
> On Sun, Sep 14, 2014 at 06:13:15PM +0100, Ben Hutchings wrote:
> > On Sun, 2014-09-14 at 18:10 +0100, Ben Hutchings wrote:
> > > The first patch in the series restores the module aliases to m25p80, but
> > > it does so by duplicating the list of names. This should be suitable
> > > for stable, but it isn't viable in the longer term.
> > >
> > > The following patches change the spi-nor interface so that this
> > > duplication is no longer necessary. This includes removing
> > > spi_nor::read_id, but it could be re-added after this with a different
> > > interface, e.g. returning a flash_info structure (which would need to be
> > > defined in spi_nor.h).
> >
> > Note that these patch are:
> > - Based on your 'testing' branch
>
> Which testing branch? These two are the only official
> repos for MTD:
>
> git git://git.infradead.org/linux-mtd.git
> git git://git.infradead.org/l2-mtd.git
You had a testing branch in
git://git.infradead.org/users/norris/linux-mtd.git, and that included
commit af249c3a0ca8 ('mtd: spi-nor: remove duplicated w25q128 entry')
which this patch series depended on.
Ben.
> > - Untested by me, aside from compiling and checking that m25p80 has the
> > expected module aliases
>
> Brian
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-09-30 1:47 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-30 1:47 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, 2014-09-28 at 15:03 -0700, Brian Norris wrote:
> On Sun, Sep 14, 2014 at 06:13:15PM +0100, Ben Hutchings wrote:
> > On Sun, 2014-09-14 at 18:10 +0100, Ben Hutchings wrote:
> > > The first patch in the series restores the module aliases to m25p80, but
> > > it does so by duplicating the list of names. This should be suitable
> > > for stable, but it isn't viable in the longer term.
> > >
> > > The following patches change the spi-nor interface so that this
> > > duplication is no longer necessary. This includes removing
> > > spi_nor::read_id, but it could be re-added after this with a different
> > > interface, e.g. returning a flash_info structure (which would need to be
> > > defined in spi_nor.h).
> >
> > Note that these patch are:
> > - Based on your 'testing' branch
>
> Which testing branch? These two are the only official
> repos for MTD:
>
> git git://git.infradead.org/linux-mtd.git
> git git://git.infradead.org/l2-mtd.git
You had a testing branch in
git://git.infradead.org/users/norris/linux-mtd.git, and that included
commit af249c3a0ca8 ('mtd: spi-nor: remove duplicated w25q128 entry')
which this patch series depended on.
Ben.
> > - Untested by me, aside from compiling and checking that m25p80 has the
> > expected module aliases
>
> Brian
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/d7e348b5/attachment.sig>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again
2014-09-17 8:23 ` Geert Uytterhoeven
(?)
@ 2014-09-30 1:50 ` Ben Hutchings
-1 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-30 1:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Brian Norris, Andrew Lunn, Jason Cooper, linux-spi, Huang Shijie,
MTD Maling List, Ian Campbell, debian-kernel, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
On Wed, 2014-09-17 at 10:23 +0200, Geert Uytterhoeven wrote:
> Hi Ben,
>
> On Mon, Sep 15, 2014 at 5:07 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> >> >
> >> > +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
> >> > + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
> >> > + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
> >>
> >> Can't you just have the IDs in a header file only, and let the header file
> >> generate either a struct flash_info or a struct spi_device_id table, using
> >> a macro defined by the file that includes it?
> >
> > How would we match up the rest of the struct flash_info to the name?
>
> Ah, you use the enums to match the names to the rest of the flash_info.
> But you can do it in one-shot, can't you?
[...]
I know, but I didn't want to expose the data in a header file. As other
people consider that a lesser evil than this rather complex approach,
I'll do it the simple way.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again
@ 2014-09-30 1:50 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-30 1:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Brian Norris, Huang Shijie, linux-arm-kernel,
debian-kernel
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
On Wed, 2014-09-17 at 10:23 +0200, Geert Uytterhoeven wrote:
> Hi Ben,
>
> On Mon, Sep 15, 2014 at 5:07 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> >> >
> >> > +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
> >> > + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
> >> > + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
> >>
> >> Can't you just have the IDs in a header file only, and let the header file
> >> generate either a struct flash_info or a struct spi_device_id table, using
> >> a macro defined by the file that includes it?
> >
> > How would we match up the rest of the struct flash_info to the name?
>
> Ah, you use the enums to match the names to the rest of the flash_info.
> But you can do it in one-shot, can't you?
[...]
I know, but I didn't want to expose the data in a header file. As other
people consider that a lesser evil than this rather complex approach,
I'll do it the simple way.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again
@ 2014-09-30 1:50 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-30 1:50 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 2014-09-17 at 10:23 +0200, Geert Uytterhoeven wrote:
> Hi Ben,
>
> On Mon, Sep 15, 2014 at 5:07 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> >> >
> >> > +#define __SPI_NOR_ENUM_TYPES(c_id, str_and_c_id) \
> >> > + c_id(at25fs010) c_id(at25fs040) c_id(at25df041a) \
> >> > + c_id(at25df321a) c_id(at25df641) c_id(at26f004) \
> >>
> >> Can't you just have the IDs in a header file only, and let the header file
> >> generate either a struct flash_info or a struct spi_device_id table, using
> >> a macro defined by the file that includes it?
> >
> > How would we match up the rest of the struct flash_info to the name?
>
> Ah, you use the enums to match the names to the rest of the flash_info.
> But you can do it in one-shot, can't you?
[...]
I know, but I didn't want to expose the data in a header file. As other
people consider that a lesser evil than this rather complex approach,
I'll do it the simple way.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/2e442ad3/attachment.sig>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
2014-09-29 6:36 ` Rafał Miłecki
(?)
@ 2014-09-30 2:07 ` Ben Hutchings
-1 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-30 2:07 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Brian Norris, Geert Uytterhoeven, Andrew Lunn, Jason Cooper,
linux-spi, Huang Shijie, MTD Maling List, Ian Campbell,
debian-kernel, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]
On Mon, 2014-09-29 at 08:36 +0200, Rafał Miłecki wrote:
> On 29 September 2014 00:21, Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > + Rafal
> >
> > Rafal has been looking at the same area of code. I'd really like to get
> > this patch into 3.18 if possible, so the more eyes the better.
>
> Thanks Brian.
>
> I took me a while to follow this issue, too bad I wasn't subscribed to
> the ML earlier. Let me try to sum it up.
>
>
>
> 1) The main urgent issue: broken auto-loading
> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
> Problem: m25p80.c references spi_nor_ids (from external file)
> Short-term solution: duplicate IDs in the m25p80.c
>
> Ben: just like Brian, I think the patch like this one (
> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
> ) is the way to go. However few comments:
>
> a) I don't see why you modify m25p_probe in it.
Because spi_nor_scan() requires a struct spi_device_id with the
driver_data field pointing to a struct flash_info.
> b) I don't think the described clean solution (you described it in the
> commit message):
> > A clean solution to this will involve defining the list of device
> > IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> > API, but this is quite a large change.
> is the correct one. I think there should be a single string to trigger
> m25p80 load and the rest should be handled using JEDEC, with some
> workarounds for incompatible devices only.
That certainly makes sense for Linux-specific platform data, but I don't
think it works for Device Tree "compatible" strings (see
<http://mid.gmane.org/1410660009.3040.29.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>).
[...]
> b) Removing spi_nor::read_id
> https://patchwork.ozlabs.org/patch/389073/
> Ben: I think this one has a NACK from me, because I'm going to use
> custom read_id in the bcm53xxspiflash driver.
> See following thread for bcm53xxspiflash description:
> http://comments.gmane.org/gmane.linux.drivers.mtd/54578
> Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
[...]
But it has to use spi_nor_match_id() because of the driver_data
requirement. This just illustrates that the read_id operation doesn't
make sense as currently defined.
I accept that there will be a need for a read_id operation, but I think
it should fill in a struct flash_info rather than requiring every chip
to be described and named in spi-nor.c.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-30 2:07 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-30 2:07 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Andrew Lunn, Jason Cooper, linux-spi, Geert Uytterhoeven,
Ian Campbell, MTD Maling List, Brian Norris, Huang Shijie,
linux-arm-kernel, debian-kernel
[-- Attachment #1: Type: text/plain, Size: 2594 bytes --]
On Mon, 2014-09-29 at 08:36 +0200, Rafał Miłecki wrote:
> On 29 September 2014 00:21, Brian Norris <computersforpeace@gmail.com> wrote:
> > + Rafal
> >
> > Rafal has been looking at the same area of code. I'd really like to get
> > this patch into 3.18 if possible, so the more eyes the better.
>
> Thanks Brian.
>
> I took me a while to follow this issue, too bad I wasn't subscribed to
> the ML earlier. Let me try to sum it up.
>
>
>
> 1) The main urgent issue: broken auto-loading
> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
> Problem: m25p80.c references spi_nor_ids (from external file)
> Short-term solution: duplicate IDs in the m25p80.c
>
> Ben: just like Brian, I think the patch like this one (
> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
> ) is the way to go. However few comments:
>
> a) I don't see why you modify m25p_probe in it.
Because spi_nor_scan() requires a struct spi_device_id with the
driver_data field pointing to a struct flash_info.
> b) I don't think the described clean solution (you described it in the
> commit message):
> > A clean solution to this will involve defining the list of device
> > IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> > API, but this is quite a large change.
> is the correct one. I think there should be a single string to trigger
> m25p80 load and the rest should be handled using JEDEC, with some
> workarounds for incompatible devices only.
That certainly makes sense for Linux-specific platform data, but I don't
think it works for Device Tree "compatible" strings (see
<http://mid.gmane.org/1410660009.3040.29.camel@decadent.org.uk>).
[...]
> b) Removing spi_nor::read_id
> https://patchwork.ozlabs.org/patch/389073/
> Ben: I think this one has a NACK from me, because I'm going to use
> custom read_id in the bcm53xxspiflash driver.
> See following thread for bcm53xxspiflash description:
> http://comments.gmane.org/gmane.linux.drivers.mtd/54578
> Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
[...]
But it has to use spi_nor_match_id() because of the driver_data
requirement. This just illustrates that the read_id operation doesn't
make sense as currently defined.
I accept that there will be a need for a read_id operation, but I think
it should fill in a struct flash_info rather than requiring every chip
to be described and named in spi-nor.c.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-30 2:07 ` Ben Hutchings
0 siblings, 0 replies; 75+ messages in thread
From: Ben Hutchings @ 2014-09-30 2:07 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2014-09-29 at 08:36 +0200, Rafa? Mi?ecki wrote:
> On 29 September 2014 00:21, Brian Norris <computersforpeace@gmail.com> wrote:
> > + Rafal
> >
> > Rafal has been looking at the same area of code. I'd really like to get
> > this patch into 3.18 if possible, so the more eyes the better.
>
> Thanks Brian.
>
> I took me a while to follow this issue, too bad I wasn't subscribed to
> the ML earlier. Let me try to sum it up.
>
>
>
> 1) The main urgent issue: broken auto-loading
> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
> Problem: m25p80.c references spi_nor_ids (from external file)
> Short-term solution: duplicate IDs in the m25p80.c
>
> Ben: just like Brian, I think the patch like this one (
> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
> ) is the way to go. However few comments:
>
> a) I don't see why you modify m25p_probe in it.
Because spi_nor_scan() requires a struct spi_device_id with the
driver_data field pointing to a struct flash_info.
> b) I don't think the described clean solution (you described it in the
> commit message):
> > A clean solution to this will involve defining the list of device
> > IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> > API, but this is quite a large change.
> is the correct one. I think there should be a single string to trigger
> m25p80 load and the rest should be handled using JEDEC, with some
> workarounds for incompatible devices only.
That certainly makes sense for Linux-specific platform data, but I don't
think it works for Device Tree "compatible" strings (see
<http://mid.gmane.org/1410660009.3040.29.camel@decadent.org.uk>).
[...]
> b) Removing spi_nor::read_id
> https://patchwork.ozlabs.org/patch/389073/
> Ben: I think this one has a NACK from me, because I'm going to use
> custom read_id in the bcm53xxspiflash driver.
> See following thread for bcm53xxspiflash description:
> http://comments.gmane.org/gmane.linux.drivers.mtd/54578
> Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
[...]
But it has to use spi_nor_match_id() because of the driver_data
requirement. This just illustrates that the read_id operation doesn't
make sense as currently defined.
I accept that there will be a need for a read_id operation, but I think
it should fill in a struct flash_info rather than requiring every chip
to be described and named in spi-nor.c.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/da598f26/attachment.sig>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
2014-09-30 2:07 ` Ben Hutchings
(?)
@ 2014-09-30 3:55 ` Brian Norris
-1 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-09-30 3:55 UTC (permalink / raw)
To: Ben Hutchings
Cc: Rafał Miłecki, Geert Uytterhoeven, Andrew Lunn,
Jason Cooper, linux-spi, Huang Shijie, MTD Maling List,
Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Tue, Sep 30, 2014 at 03:07:38AM +0100, Ben Hutchings wrote:
> On Mon, 2014-09-29 at 08:36 +0200, Rafał Miłecki wrote:
> > b) I don't think the described clean solution (you described it in the
> > commit message):
> > > A clean solution to this will involve defining the list of device
> > > IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> > > API, but this is quite a large change.
> > is the correct one. I think there should be a single string to trigger
> > m25p80 load and the rest should be handled using JEDEC, with some
> > workarounds for incompatible devices only.
>
> That certainly makes sense for Linux-specific platform data, but I don't
> think it works for Device Tree "compatible" strings (see
> <http://mid.gmane.org/1410660009.3040.29.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>).
I think it might work.
Your quote from that thread:
"I think that a DT node is always supposed to include a compatible
string for the specific device. It could also include a generic
compatible string for SPI NOR chips, but the *only* thing a driver can
do with that is to use the JEDEC ID command. It can't even
generically read a single byte, since addresses may be either 3 or 4
bytes long! So I think that if a generic compatible string is
defined, the DT binding must also define the properties that spi-nor
currently reads out of its static table."
For every current entry (except the "*-nonjedec" entries; I don't think
we should be supporting any more entries like this, and I'd like to kill
the existing ones if possible), we can do just that; read out the JEDEC
ID and go from there. (Rafal is also looking at non-JEDEC RDID commands,
but that would just require a different type of binding.)
In fact, for most of these entries, we'll read out the ID and override
the match provided by the driver anyway. See:
int spi_nor_scan(...)
{
...
[Note: almost all 'info' entries provide a non-zero jedec_id field]
if (info->jedec_id) {
const struct spi_device_id *jid;
jid = nor->read_id(nor);
if (IS_ERR(jid)) {
return PTR_ERR(jid);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
* can't trust partitions any longer, but we'll let
* mtd apply them anyway, since some partitions may be
* marked read-only, and we don't want to lose that
* information, even if it's not 100% accurate.
*/
dev_warn(dev, "found %s, expected %s\n",
jid->name, id->name);
id = jid;
info = (void *)jid->driver_data;
}
}
...
}
I think this chunk might be reworked (or at least, modify the comments)
to note how we primarily expect to override the input ID. We might even
drop the dev_warn() eventually, and make it more informative instead.
> [...]
> > b) Removing spi_nor::read_id
> > https://patchwork.ozlabs.org/patch/389073/
> > Ben: I think this one has a NACK from me, because I'm going to use
> > custom read_id in the bcm53xxspiflash driver.
> > See following thread for bcm53xxspiflash description:
> > http://comments.gmane.org/gmane.linux.drivers.mtd/54578
> > Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
> [...]
>
> But it has to use spi_nor_match_id() because of the driver_data
> requirement. This just illustrates that the read_id operation doesn't
> make sense as currently defined.
Right. I think it may turn out better to drop it and force a redesign
for the next user.
> I accept that there will be a need for a read_id operation, but I think
> it should fill in a struct flash_info rather than requiring every chip
> to be described and named in spi-nor.c.
Maybe struct flash_info, but this still leaks more spi-nor.c internal
info into drivers. Perhaps Rafal's use case could be served by a
select-able 'READ ID' opcode, with his flash_info structs still stored
in spi_nor_ids[] -- or possibly as a separate ID table within spi-nor.c.
But either way, I agree the current read_id() hook is not satisfactory.
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-30 3:55 ` Brian Norris
0 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-09-30 3:55 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Lunn, Jason Cooper, Rafał Miłecki, linux-spi,
Geert Uytterhoeven, Ian Campbell, MTD Maling List, Huang Shijie,
linux-arm-kernel, debian-kernel
On Tue, Sep 30, 2014 at 03:07:38AM +0100, Ben Hutchings wrote:
> On Mon, 2014-09-29 at 08:36 +0200, Rafał Miłecki wrote:
> > b) I don't think the described clean solution (you described it in the
> > commit message):
> > > A clean solution to this will involve defining the list of device
> > > IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> > > API, but this is quite a large change.
> > is the correct one. I think there should be a single string to trigger
> > m25p80 load and the rest should be handled using JEDEC, with some
> > workarounds for incompatible devices only.
>
> That certainly makes sense for Linux-specific platform data, but I don't
> think it works for Device Tree "compatible" strings (see
> <http://mid.gmane.org/1410660009.3040.29.camel@decadent.org.uk>).
I think it might work.
Your quote from that thread:
"I think that a DT node is always supposed to include a compatible
string for the specific device. It could also include a generic
compatible string for SPI NOR chips, but the *only* thing a driver can
do with that is to use the JEDEC ID command. It can't even
generically read a single byte, since addresses may be either 3 or 4
bytes long! So I think that if a generic compatible string is
defined, the DT binding must also define the properties that spi-nor
currently reads out of its static table."
For every current entry (except the "*-nonjedec" entries; I don't think
we should be supporting any more entries like this, and I'd like to kill
the existing ones if possible), we can do just that; read out the JEDEC
ID and go from there. (Rafal is also looking at non-JEDEC RDID commands,
but that would just require a different type of binding.)
In fact, for most of these entries, we'll read out the ID and override
the match provided by the driver anyway. See:
int spi_nor_scan(...)
{
...
[Note: almost all 'info' entries provide a non-zero jedec_id field]
if (info->jedec_id) {
const struct spi_device_id *jid;
jid = nor->read_id(nor);
if (IS_ERR(jid)) {
return PTR_ERR(jid);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
* can't trust partitions any longer, but we'll let
* mtd apply them anyway, since some partitions may be
* marked read-only, and we don't want to lose that
* information, even if it's not 100% accurate.
*/
dev_warn(dev, "found %s, expected %s\n",
jid->name, id->name);
id = jid;
info = (void *)jid->driver_data;
}
}
...
}
I think this chunk might be reworked (or at least, modify the comments)
to note how we primarily expect to override the input ID. We might even
drop the dev_warn() eventually, and make it more informative instead.
> [...]
> > b) Removing spi_nor::read_id
> > https://patchwork.ozlabs.org/patch/389073/
> > Ben: I think this one has a NACK from me, because I'm going to use
> > custom read_id in the bcm53xxspiflash driver.
> > See following thread for bcm53xxspiflash description:
> > http://comments.gmane.org/gmane.linux.drivers.mtd/54578
> > Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
> [...]
>
> But it has to use spi_nor_match_id() because of the driver_data
> requirement. This just illustrates that the read_id operation doesn't
> make sense as currently defined.
Right. I think it may turn out better to drop it and force a redesign
for the next user.
> I accept that there will be a need for a read_id operation, but I think
> it should fill in a struct flash_info rather than requiring every chip
> to be described and named in spi-nor.c.
Maybe struct flash_info, but this still leaks more spi-nor.c internal
info into drivers. Perhaps Rafal's use case could be served by a
select-able 'READ ID' opcode, with his flash_info structs still stored
in spi_nor_ids[] -- or possibly as a separate ID table within spi-nor.c.
But either way, I agree the current read_id() hook is not satisfactory.
Brian
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-30 3:55 ` Brian Norris
0 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-09-30 3:55 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 30, 2014 at 03:07:38AM +0100, Ben Hutchings wrote:
> On Mon, 2014-09-29 at 08:36 +0200, Rafa? Mi?ecki wrote:
> > b) I don't think the described clean solution (you described it in the
> > commit message):
> > > A clean solution to this will involve defining the list of device
> > > IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
> > > API, but this is quite a large change.
> > is the correct one. I think there should be a single string to trigger
> > m25p80 load and the rest should be handled using JEDEC, with some
> > workarounds for incompatible devices only.
>
> That certainly makes sense for Linux-specific platform data, but I don't
> think it works for Device Tree "compatible" strings (see
> <http://mid.gmane.org/1410660009.3040.29.camel@decadent.org.uk>).
I think it might work.
Your quote from that thread:
"I think that a DT node is always supposed to include a compatible
string for the specific device. It could also include a generic
compatible string for SPI NOR chips, but the *only* thing a driver can
do with that is to use the JEDEC ID command. It can't even
generically read a single byte, since addresses may be either 3 or 4
bytes long! So I think that if a generic compatible string is
defined, the DT binding must also define the properties that spi-nor
currently reads out of its static table."
For every current entry (except the "*-nonjedec" entries; I don't think
we should be supporting any more entries like this, and I'd like to kill
the existing ones if possible), we can do just that; read out the JEDEC
ID and go from there. (Rafal is also looking at non-JEDEC RDID commands,
but that would just require a different type of binding.)
In fact, for most of these entries, we'll read out the ID and override
the match provided by the driver anyway. See:
int spi_nor_scan(...)
{
...
[Note: almost all 'info' entries provide a non-zero jedec_id field]
if (info->jedec_id) {
const struct spi_device_id *jid;
jid = nor->read_id(nor);
if (IS_ERR(jid)) {
return PTR_ERR(jid);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
* can't trust partitions any longer, but we'll let
* mtd apply them anyway, since some partitions may be
* marked read-only, and we don't want to lose that
* information, even if it's not 100% accurate.
*/
dev_warn(dev, "found %s, expected %s\n",
jid->name, id->name);
id = jid;
info = (void *)jid->driver_data;
}
}
...
}
I think this chunk might be reworked (or at least, modify the comments)
to note how we primarily expect to override the input ID. We might even
drop the dev_warn() eventually, and make it more informative instead.
> [...]
> > b) Removing spi_nor::read_id
> > https://patchwork.ozlabs.org/patch/389073/
> > Ben: I think this one has a NACK from me, because I'm going to use
> > custom read_id in the bcm53xxspiflash driver.
> > See following thread for bcm53xxspiflash description:
> > http://comments.gmane.org/gmane.linux.drivers.mtd/54578
> > Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
> [...]
>
> But it has to use spi_nor_match_id() because of the driver_data
> requirement. This just illustrates that the read_id operation doesn't
> make sense as currently defined.
Right. I think it may turn out better to drop it and force a redesign
for the next user.
> I accept that there will be a need for a read_id operation, but I think
> it should fill in a struct flash_info rather than requiring every chip
> to be described and named in spi-nor.c.
Maybe struct flash_info, but this still leaks more spi-nor.c internal
info into drivers. Perhaps Rafal's use case could be served by a
select-able 'READ ID' opcode, with his flash_info structs still stored
in spi_nor_ids[] -- or possibly as a separate ID table within spi-nor.c.
But either way, I agree the current read_id() hook is not satisfactory.
Brian
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
2014-09-30 2:07 ` Ben Hutchings
(?)
@ 2014-09-30 5:09 ` Rafał Miłecki
-1 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-30 5:09 UTC (permalink / raw)
To: Ben Hutchings
Cc: Brian Norris, Geert Uytterhoeven, Andrew Lunn, Jason Cooper,
linux-spi, Huang Shijie, MTD Maling List, Ian Campbell,
debian-kernel, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 30 September 2014 04:07, Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org> wrote:
> On Mon, 2014-09-29 at 08:36 +0200, Rafał Miłecki wrote:
>> On 29 September 2014 00:21, Brian Norris <computersforpeace-Re5JQEeQqe8@public.gmane.orgm> wrote:
>> > + Rafal
>> >
>> > Rafal has been looking at the same area of code. I'd really like to get
>> > this patch into 3.18 if possible, so the more eyes the better.
>>
>> Thanks Brian.
>>
>> I took me a while to follow this issue, too bad I wasn't subscribed to
>> the ML earlier. Let me try to sum it up.
>>
>>
>>
>> 1) The main urgent issue: broken auto-loading
>> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
>> Problem: m25p80.c references spi_nor_ids (from external file)
>> Short-term solution: duplicate IDs in the m25p80.c
>>
>> Ben: just like Brian, I think the patch like this one (
>> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
>> ) is the way to go. However few comments:
>>
>> a) I don't see why you modify m25p_probe in it.
>
> Because spi_nor_scan() requires a struct spi_device_id with the
> driver_data field pointing to a struct flash_info.
More friendly explanation: because spi_get_device_id uses driver's
id_table (that was now changes to pure strings).
I see the point.
>> b) I don't think the described clean solution (you described it in the
>> commit message):
>> > A clean solution to this will involve defining the list of device
>> > IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
>> > API, but this is quite a large change.
>> is the correct one. I think there should be a single string to trigger
>> m25p80 load and the rest should be handled using JEDEC, with some
>> workarounds for incompatible devices only.
>
> That certainly makes sense for Linux-specific platform data, but I don't
> think it works for Device Tree "compatible" strings (see
> <http://mid.gmane.org/1410660009.3040.29.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>).
We could simply follow the way Linux-specific platform data works. We
could always use
compatible = "m25p80";
and then for some rare cases (where JEDEC fails) add something like
model = "at25df321a";
>> b) Removing spi_nor::read_id
>> https://patchwork.ozlabs.org/patch/389073/
>> Ben: I think this one has a NACK from me, because I'm going to use
>> custom read_id in the bcm53xxspiflash driver.
>> See following thread for bcm53xxspiflash description:
>> http://comments.gmane.org/gmane.linux.drivers.mtd/54578
>> Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
> [...]
>
> But it has to use spi_nor_match_id() because of the driver_data
> requirement. This just illustrates that the read_id operation doesn't
> make sense as currently defined.
I agree, however there is already a patch in progress handling that:
https://patchwork.ozlabs.org/patch/377917/
> I accept that there will be a need for a read_id operation, but I think
> it should fill in a struct flash_info rather than requiring every chip
> to be described and named in spi-nor.c.
Flashes not supporting JEDEC are usually some weird versions of normal
flashes with JEDEC support. So I think we could still have them in the
spi-nor database and let users provide the name instead of filling the
whole struct flash_info.
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-30 5:09 ` Rafał Miłecki
0 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-30 5:09 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Lunn, Jason Cooper, linux-spi, Geert Uytterhoeven,
Ian Campbell, MTD Maling List, Brian Norris, Huang Shijie,
linux-arm-kernel, debian-kernel
On 30 September 2014 04:07, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Mon, 2014-09-29 at 08:36 +0200, Rafał Miłecki wrote:
>> On 29 September 2014 00:21, Brian Norris <computersforpeace@gmail.com> wrote:
>> > + Rafal
>> >
>> > Rafal has been looking at the same area of code. I'd really like to get
>> > this patch into 3.18 if possible, so the more eyes the better.
>>
>> Thanks Brian.
>>
>> I took me a while to follow this issue, too bad I wasn't subscribed to
>> the ML earlier. Let me try to sum it up.
>>
>>
>>
>> 1) The main urgent issue: broken auto-loading
>> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
>> Problem: m25p80.c references spi_nor_ids (from external file)
>> Short-term solution: duplicate IDs in the m25p80.c
>>
>> Ben: just like Brian, I think the patch like this one (
>> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
>> ) is the way to go. However few comments:
>>
>> a) I don't see why you modify m25p_probe in it.
>
> Because spi_nor_scan() requires a struct spi_device_id with the
> driver_data field pointing to a struct flash_info.
More friendly explanation: because spi_get_device_id uses driver's
id_table (that was now changes to pure strings).
I see the point.
>> b) I don't think the described clean solution (you described it in the
>> commit message):
>> > A clean solution to this will involve defining the list of device
>> > IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
>> > API, but this is quite a large change.
>> is the correct one. I think there should be a single string to trigger
>> m25p80 load and the rest should be handled using JEDEC, with some
>> workarounds for incompatible devices only.
>
> That certainly makes sense for Linux-specific platform data, but I don't
> think it works for Device Tree "compatible" strings (see
> <http://mid.gmane.org/1410660009.3040.29.camel@decadent.org.uk>).
We could simply follow the way Linux-specific platform data works. We
could always use
compatible = "m25p80";
and then for some rare cases (where JEDEC fails) add something like
model = "at25df321a";
>> b) Removing spi_nor::read_id
>> https://patchwork.ozlabs.org/patch/389073/
>> Ben: I think this one has a NACK from me, because I'm going to use
>> custom read_id in the bcm53xxspiflash driver.
>> See following thread for bcm53xxspiflash description:
>> http://comments.gmane.org/gmane.linux.drivers.mtd/54578
>> Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
> [...]
>
> But it has to use spi_nor_match_id() because of the driver_data
> requirement. This just illustrates that the read_id operation doesn't
> make sense as currently defined.
I agree, however there is already a patch in progress handling that:
https://patchwork.ozlabs.org/patch/377917/
> I accept that there will be a need for a read_id operation, but I think
> it should fill in a struct flash_info rather than requiring every chip
> to be described and named in spi-nor.c.
Flashes not supporting JEDEC are usually some weird versions of normal
flashes with JEDEC support. So I think we could still have them in the
spi-nor database and let users provide the name instead of filling the
whole struct flash_info.
--
Rafał
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
@ 2014-09-30 5:09 ` Rafał Miłecki
0 siblings, 0 replies; 75+ messages in thread
From: Rafał Miłecki @ 2014-09-30 5:09 UTC (permalink / raw)
To: linux-arm-kernel
On 30 September 2014 04:07, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Mon, 2014-09-29 at 08:36 +0200, Rafa? Mi?ecki wrote:
>> On 29 September 2014 00:21, Brian Norris <computersforpeace@gmail.com> wrote:
>> > + Rafal
>> >
>> > Rafal has been looking at the same area of code. I'd really like to get
>> > this patch into 3.18 if possible, so the more eyes the better.
>>
>> Thanks Brian.
>>
>> I took me a while to follow this issue, too bad I wasn't subscribed to
>> the ML earlier. Let me try to sum it up.
>>
>>
>>
>> 1) The main urgent issue: broken auto-loading
>> Tracked in the thread: http://www.spinics.net/lists/linux-spi/msg01726.html
>> Problem: m25p80.c references spi_nor_ids (from external file)
>> Short-term solution: duplicate IDs in the m25p80.c
>>
>> Ben: just like Brian, I think the patch like this one (
>> [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80
>> ) is the way to go. However few comments:
>>
>> a) I don't see why you modify m25p_probe in it.
>
> Because spi_nor_scan() requires a struct spi_device_id with the
> driver_data field pointing to a struct flash_info.
More friendly explanation: because spi_get_device_id uses driver's
id_table (that was now changes to pure strings).
I see the point.
>> b) I don't think the described clean solution (you described it in the
>> commit message):
>> > A clean solution to this will involve defining the list of device
>> > IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
>> > API, but this is quite a large change.
>> is the correct one. I think there should be a single string to trigger
>> m25p80 load and the rest should be handled using JEDEC, with some
>> workarounds for incompatible devices only.
>
> That certainly makes sense for Linux-specific platform data, but I don't
> think it works for Device Tree "compatible" strings (see
> <http://mid.gmane.org/1410660009.3040.29.camel@decadent.org.uk>).
We could simply follow the way Linux-specific platform data works. We
could always use
compatible = "m25p80";
and then for some rare cases (where JEDEC fails) add something like
model = "at25df321a";
>> b) Removing spi_nor::read_id
>> https://patchwork.ozlabs.org/patch/389073/
>> Ben: I think this one has a NACK from me, because I'm going to use
>> custom read_id in the bcm53xxspiflash driver.
>> See following thread for bcm53xxspiflash description:
>> http://comments.gmane.org/gmane.linux.drivers.mtd/54578
>> Initial commit (it uses read_id): https://patchwork.ozlabs.org/patch/381902/
> [...]
>
> But it has to use spi_nor_match_id() because of the driver_data
> requirement. This just illustrates that the read_id operation doesn't
> make sense as currently defined.
I agree, however there is already a patch in progress handling that:
https://patchwork.ozlabs.org/patch/377917/
> I accept that there will be a need for a read_id operation, but I think
> it should fill in a struct flash_info rather than requiring every chip
> to be described and named in spi-nor.c.
Flashes not supporting JEDEC are usually some weird versions of normal
flashes with JEDEC support. So I think we could still have them in the
spi-nor database and let users provide the name instead of filling the
whole struct flash_info.
--
Rafa?
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
2014-09-30 1:47 ` Ben Hutchings
(?)
@ 2014-10-10 4:52 ` Brian Norris
-1 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-10-10 4:52 UTC (permalink / raw)
To: Ben Hutchings
Cc: Geert Uytterhoeven, Andrew Lunn, Jason Cooper, linux-spi,
Huang Shijie, MTD Maling List, Ian Campbell, debian-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Tue, Sep 30, 2014 at 02:47:53AM +0100, Ben Hutchings wrote:
> On Sun, 2014-09-28 at 15:03 -0700, Brian Norris wrote:
> > On Sun, Sep 14, 2014 at 06:13:15PM +0100, Ben Hutchings wrote:
> > > Note that these patch are:
> > > - Based on your 'testing' branch
> >
> > Which testing branch? These two are the only official
> > repos for MTD:
> >
> > git git://git.infradead.org/linux-mtd.git
> > git git://git.infradead.org/l2-mtd.git
>
> You had a testing branch in
> git://git.infradead.org/users/norris/linux-mtd.git, and that included
> commit af249c3a0ca8 ('mtd: spi-nor: remove duplicated w25q128 entry')
> which this patch series depended on.
That repository is very much unofficial. I have a MAINTAINERS patch
queued up to add git://git.infradead.org/l2-mtd.git (our -next repo) to
reduce future confusion.
Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-10-10 4:52 ` Brian Norris
0 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-10-10 4:52 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Lunn, Jason Cooper, linux-spi, MTD Maling List,
Ian Campbell, Geert Uytterhoeven, Huang Shijie, linux-arm-kernel,
debian-kernel
On Tue, Sep 30, 2014 at 02:47:53AM +0100, Ben Hutchings wrote:
> On Sun, 2014-09-28 at 15:03 -0700, Brian Norris wrote:
> > On Sun, Sep 14, 2014 at 06:13:15PM +0100, Ben Hutchings wrote:
> > > Note that these patch are:
> > > - Based on your 'testing' branch
> >
> > Which testing branch? These two are the only official
> > repos for MTD:
> >
> > git git://git.infradead.org/linux-mtd.git
> > git git://git.infradead.org/l2-mtd.git
>
> You had a testing branch in
> git://git.infradead.org/users/norris/linux-mtd.git, and that included
> commit af249c3a0ca8 ('mtd: spi-nor: remove duplicated w25q128 entry')
> which this patch series depended on.
That repository is very much unofficial. I have a MAINTAINERS patch
queued up to add git://git.infradead.org/l2-mtd.git (our -next repo) to
reduce future confusion.
Regards,
Brian
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification
@ 2014-10-10 4:52 ` Brian Norris
0 siblings, 0 replies; 75+ messages in thread
From: Brian Norris @ 2014-10-10 4:52 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 30, 2014 at 02:47:53AM +0100, Ben Hutchings wrote:
> On Sun, 2014-09-28 at 15:03 -0700, Brian Norris wrote:
> > On Sun, Sep 14, 2014 at 06:13:15PM +0100, Ben Hutchings wrote:
> > > Note that these patch are:
> > > - Based on your 'testing' branch
> >
> > Which testing branch? These two are the only official
> > repos for MTD:
> >
> > git git://git.infradead.org/linux-mtd.git
> > git git://git.infradead.org/l2-mtd.git
>
> You had a testing branch in
> git://git.infradead.org/users/norris/linux-mtd.git, and that included
> commit af249c3a0ca8 ('mtd: spi-nor: remove duplicated w25q128 entry')
> which this patch series depended on.
That repository is very much unofficial. I have a MAINTAINERS patch
queued up to add git://git.infradead.org/l2-mtd.git (our -next repo) to
reduce future confusion.
Regards,
Brian
^ permalink raw reply [flat|nested] 75+ messages in thread
end of thread, other threads:[~2014-10-10 4:52 UTC | newest]
Thread overview: 75+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-14 17:10 [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification Ben Hutchings
2014-09-14 17:10 ` Ben Hutchings
2014-09-14 17:10 ` Ben Hutchings
[not found] ` <1410714624.3040.38.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
2014-09-14 17:11 ` [PATCH 1/5] m25p80,spi-nor: Fix module aliases for m25p80 Ben Hutchings
2014-09-14 17:11 ` Ben Hutchings
2014-09-14 17:11 ` Ben Hutchings
[not found] ` <1410714670.3040.39.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
2014-09-28 22:21 ` Brian Norris
2014-09-28 22:21 ` Brian Norris
2014-09-28 22:21 ` Brian Norris
2014-09-29 6:36 ` Rafał Miłecki
2014-09-29 6:36 ` Rafał Miłecki
2014-09-29 6:36 ` Rafał Miłecki
[not found] ` <CACna6rx=GyZ-4JpDix==WKszABseQXK6qCCkfiKCm9-WzBmM3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-29 9:53 ` Rafał Miłecki
2014-09-29 9:53 ` Rafał Miłecki
2014-09-29 9:53 ` Rafał Miłecki
[not found] ` <CACna6ry91b3wcHsG4C-td+STPuiaH7oaAcQuKiKdhud+jctUeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-29 10:25 ` Rafał Miłecki
2014-09-29 10:25 ` Rafał Miłecki
2014-09-29 10:25 ` Rafał Miłecki
2014-09-30 2:07 ` Ben Hutchings
2014-09-30 2:07 ` Ben Hutchings
2014-09-30 2:07 ` Ben Hutchings
[not found] ` <1412042858.9388.79.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
2014-09-30 3:55 ` Brian Norris
2014-09-30 3:55 ` Brian Norris
2014-09-30 3:55 ` Brian Norris
2014-09-30 5:09 ` Rafał Miłecki
2014-09-30 5:09 ` Rafał Miłecki
2014-09-30 5:09 ` Rafał Miłecki
2014-09-29 8:37 ` Rafał Miłecki
2014-09-29 8:37 ` Rafał Miłecki
2014-09-29 8:37 ` Rafał Miłecki
2014-09-14 17:11 ` [PATCH 2/5] spi-nor: Remove spi_nor::read_id operation Ben Hutchings
2014-09-14 17:11 ` Ben Hutchings
2014-09-14 17:11 ` Ben Hutchings
[not found] ` <1410714676.3040.40.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
2014-09-15 14:55 ` Huang Shijie
2014-09-15 14:55 ` Huang Shijie
2014-09-15 14:55 ` Huang Shijie
[not found] ` <20140915145523.GA1963-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2014-09-15 15:08 ` Ben Hutchings
2014-09-15 15:08 ` Ben Hutchings
2014-09-15 15:08 ` Ben Hutchings
2014-09-14 17:11 ` [PATCH 3/5] spi-nor: Make spi_nor_scan() take a chip type name, not an spi_device_id Ben Hutchings
2014-09-14 17:11 ` Ben Hutchings
2014-09-14 17:11 ` Ben Hutchings
2014-09-14 17:11 ` [PATCH 4/5] spi-nor: Replace struct spi_device_id with struct flash_info Ben Hutchings
2014-09-14 17:11 ` Ben Hutchings
2014-09-14 17:11 ` Ben Hutchings
2014-09-14 17:11 ` [PATCH 5/5] m25p80,spi-nor: Share the list of supported chip type names again Ben Hutchings
2014-09-14 17:11 ` Ben Hutchings
2014-09-14 17:11 ` Ben Hutchings
[not found] ` <1410714708.3040.43.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
2014-09-15 7:55 ` Geert Uytterhoeven
2014-09-15 7:55 ` [PATCH 5/5] m25p80, spi-nor: " Geert Uytterhoeven
2014-09-15 7:55 ` Geert Uytterhoeven
[not found] ` <CAMuHMdUs+7uidcD6tivnq6+TbD4_piixLVqwuSa0Z1u3sF7EoA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-15 15:07 ` [PATCH 5/5] m25p80,spi-nor: " Ben Hutchings
2014-09-15 15:07 ` Ben Hutchings
2014-09-15 15:07 ` Ben Hutchings
[not found] ` <1410793627.3040.61.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
2014-09-17 8:23 ` Geert Uytterhoeven
2014-09-17 8:23 ` [PATCH 5/5] m25p80, spi-nor: " Geert Uytterhoeven
2014-09-17 8:23 ` Geert Uytterhoeven
2014-09-30 1:50 ` [PATCH 5/5] m25p80,spi-nor: " Ben Hutchings
2014-09-30 1:50 ` Ben Hutchings
2014-09-30 1:50 ` Ben Hutchings
2014-09-14 17:13 ` [PATCH 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification Ben Hutchings
2014-09-14 17:13 ` Ben Hutchings
2014-09-14 17:13 ` Ben Hutchings
[not found] ` <1410714795.3040.45.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
2014-09-28 22:03 ` Brian Norris
2014-09-28 22:03 ` Brian Norris
2014-09-28 22:03 ` Brian Norris
2014-09-30 1:47 ` Ben Hutchings
2014-09-30 1:47 ` Ben Hutchings
2014-09-30 1:47 ` Ben Hutchings
[not found] ` <1412041673.9388.75.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
2014-10-10 4:52 ` Brian Norris
2014-10-10 4:52 ` Brian Norris
2014-10-10 4:52 ` Brian Norris
2014-09-28 11:35 ` Mark Brown
2014-09-28 11:35 ` Mark Brown
2014-09-28 11:35 ` Mark Brown
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.