* [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-07-31 0:41 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-07-31 0:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Ben Dooks, David Brownell, David Woodhouse, Grant Likely,
Benjamin Herrenschmidt, Jean Delvare, linux-mtd, linux-kernel,
lm-sensors, linuxppc-dev
This patch converts the m25p80 driver so that now it uses .id_table
for device matching, making it properly detect devices on OpenFirmware
platforms (prior to this patch the driver misdetected non-JEDEC chips,
seeing all chips as "m25p80").
Also, now jedec_probe() only does jedec probing, nothing else. If it
is not able to detect a chip, NULL is returned and the driver fall
backs to the information specified by the platform (platform_data, or
exact ID).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mtd/devices/m25p80.c | 146 +++++++++++++++++++++++-------------------
1 files changed, 80 insertions(+), 66 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 10ed195..0d74b38 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -21,6 +21,7 @@
#include <linux/interrupt.h>
#include <linux/mutex.h>
#include <linux/math64.h>
+#include <linux/mod_devicetable.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -462,8 +463,6 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
*/
struct flash_info {
- char *name;
-
/* 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.
@@ -481,74 +480,83 @@ struct flash_info {
#define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
};
+#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ ((kernel_ulong_t)&(struct flash_info) { \
+ .jedec_id = (_jedec_id), \
+ .ext_id = (_ext_id), \
+ .sector_size = (_sector_size), \
+ .n_sectors = (_n_sectors), \
+ .flags = (_flags), \
+ })
/* NOTE: double check command sets and memory organization when you add
* more flash chips. This current list focusses on newer chips, which
* have been converging on command sets which including JEDEC ID.
*/
-static struct flash_info __devinitdata m25p_data [] = {
-
+static const struct spi_device_id m25p_ids[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
- { "at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
- { "at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
+ { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
+ { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
- { "at25df041a", 0x1f4401, 0, 64 * 1024, 8, SECT_4K, },
- { "at25df641", 0x1f4800, 0, 64 * 1024, 128, SECT_4K, },
+ { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
+ { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
- { "at26f004", 0x1f0400, 0, 64 * 1024, 8, SECT_4K, },
- { "at26df081a", 0x1f4501, 0, 64 * 1024, 16, SECT_4K, },
- { "at26df161a", 0x1f4601, 0, 64 * 1024, 32, SECT_4K, },
- { "at26df321", 0x1f4701, 0, 64 * 1024, 64, 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(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
/* Macronix */
- { "mx25l12805d", 0xc22018, 0, 64 * 1024, 256, },
+ { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- { "s25sl004a", 0x010212, 0, 64 * 1024, 8, },
- { "s25sl008a", 0x010213, 0, 64 * 1024, 16, },
- { "s25sl016a", 0x010214, 0, 64 * 1024, 32, },
- { "s25sl032a", 0x010215, 0, 64 * 1024, 64, },
- { "s25sl064a", 0x010216, 0, 64 * 1024, 128, },
- { "s25sl12800", 0x012018, 0x0300, 256 * 1024, 64, },
- { "s25sl12801", 0x012018, 0x0301, 64 * 1024, 256, },
+ { "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) },
+ { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
+ { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
/* SST -- large erase sizes are "overlays", "sectors" are 4K */
- { "sst25vf040b", 0xbf258d, 0, 64 * 1024, 8, SECT_4K, },
- { "sst25vf080b", 0xbf258e, 0, 64 * 1024, 16, SECT_4K, },
- { "sst25vf016b", 0xbf2541, 0, 64 * 1024, 32, SECT_4K, },
- { "sst25vf032b", 0xbf254a, 0, 64 * 1024, 64, SECT_4K, },
+ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K) },
+ { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K) },
+ { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K) },
+ { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K) },
/* ST Microelectronics -- newer production may have feature updates */
- { "m25p05", 0x202010, 0, 32 * 1024, 2, },
- { "m25p10", 0x202011, 0, 32 * 1024, 4, },
- { "m25p20", 0x202012, 0, 64 * 1024, 4, },
- { "m25p40", 0x202013, 0, 64 * 1024, 8, },
- { "m25p80", 0, 0, 64 * 1024, 16, },
- { "m25p16", 0x202015, 0, 64 * 1024, 32, },
- { "m25p32", 0x202016, 0, 64 * 1024, 64, },
- { "m25p64", 0x202017, 0, 64 * 1024, 128, },
- { "m25p128", 0x202018, 0, 256 * 1024, 64, },
-
- { "m45pe10", 0x204011, 0, 64 * 1024, 2, },
- { "m45pe80", 0x204014, 0, 64 * 1024, 16, },
- { "m45pe16", 0x204015, 0, 64 * 1024, 32, },
-
- { "m25pe80", 0x208014, 0, 64 * 1024, 16, },
- { "m25pe16", 0x208015, 0, 64 * 1024, 32, SECT_4K, },
+ { "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) },
+
+ { "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 0) },
+ { "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 0) },
+ { "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 0) },
+
+ { "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 0) },
+ { "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, SECT_4K) },
/* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
- { "w25x10", 0xef3011, 0, 64 * 1024, 2, SECT_4K, },
- { "w25x20", 0xef3012, 0, 64 * 1024, 4, SECT_4K, },
- { "w25x40", 0xef3013, 0, 64 * 1024, 8, SECT_4K, },
- { "w25x80", 0xef3014, 0, 64 * 1024, 16, SECT_4K, },
- { "w25x16", 0xef3015, 0, 64 * 1024, 32, SECT_4K, },
- { "w25x32", 0xef3016, 0, 64 * 1024, 64, SECT_4K, },
- { "w25x64", 0xef3017, 0, 64 * 1024, 128, SECT_4K, },
+ { "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) },
+ { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
+ { },
};
+MODULE_DEVICE_TABLE(spi, m25p_ids);
-static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
+static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
{
int tmp;
u8 code = OPCODE_RDID;
@@ -575,16 +583,14 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
ext_jedec = id[3] << 8 | id[4];
- for (tmp = 0, info = m25p_data;
- tmp < ARRAY_SIZE(m25p_data);
- tmp++, info++) {
+ for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
+ info = (void *)m25p_ids[tmp].driver_data;
if (info->jedec_id == jedec) {
if (info->ext_id != 0 && info->ext_id != ext_jedec)
continue;
- return info;
+ return &m25p_ids[tmp];
}
}
- dev_err(&spi->dev, "unrecognized JEDEC id %06x\n", jedec);
return NULL;
}
@@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
*/
static int __devinit m25p_probe(struct spi_device *spi)
{
+ const struct spi_device_id *id;
struct flash_platform_data *data;
struct m25p *flash;
struct flash_info *info;
@@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
*/
data = spi->dev.platform_data;
if (data && data->type) {
- for (i = 0, info = m25p_data;
- i < ARRAY_SIZE(m25p_data);
- i++, info++) {
- if (strcmp(data->type, info->name) == 0)
- break;
+ for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
+ id = &m25p_ids[i];
+ info = (void *)m25p_ids[i].driver_data;
+ if (strcmp(data->type, id->name))
+ continue;
+ break;
}
/* unrecognized chip? */
- if (i == ARRAY_SIZE(m25p_data)) {
+ if (i == ARRAY_SIZE(m25p_ids) - 1) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
dev_name(&spi->dev), data->type);
info = NULL;
/* recognized; is that chip really what's there? */
} else if (info->jedec_id) {
- struct flash_info *chip = jedec_probe(spi);
+ id = jedec_probe(spi);
- if (!chip || chip != info) {
+ if (id != &m25p_ids[i]) {
dev_warn(&spi->dev, "found %s, expected %s\n",
- chip ? chip->name : "UNKNOWN",
- info->name);
+ id ? id->name : "UNKNOWN",
+ m25p_ids[i].name);
info = NULL;
}
}
- } else
- info = jedec_probe(spi);
+ } else {
+ id = jedec_probe(spi);
+ if (!id)
+ id = spi_get_device_id(spi);
+
+ info = (void *)id->driver_data;
+ }
if (!info)
return -ENODEV;
@@ -680,7 +693,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
flash->mtd.dev.parent = &spi->dev;
- dev_info(&spi->dev, "%s (%lld Kbytes)\n", info->name,
+ dev_info(&spi->dev, "%s (%lld Kbytes)\n", id->name,
(long long)flash->mtd.size >> 10);
DEBUG(MTD_DEBUG_LEVEL2,
@@ -766,6 +779,7 @@ static struct spi_driver m25p80_driver = {
.bus = &spi_bus_type,
.owner = THIS_MODULE,
},
+ .id_table = m25p_ids,
.probe = m25p_probe,
.remove = __devexit_p(m25p_remove),
--
1.6.3.3
^ permalink raw reply related [flat|nested] 131+ messages in thread* [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-07-31 0:41 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-07-31 0:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, David Woodhouse
This patch converts the m25p80 driver so that now it uses .id_table
for device matching, making it properly detect devices on OpenFirmware
platforms (prior to this patch the driver misdetected non-JEDEC chips,
seeing all chips as "m25p80").
Also, now jedec_probe() only does jedec probing, nothing else. If it
is not able to detect a chip, NULL is returned and the driver fall
backs to the information specified by the platform (platform_data, or
exact ID).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mtd/devices/m25p80.c | 146 +++++++++++++++++++++++-------------------
1 files changed, 80 insertions(+), 66 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 10ed195..0d74b38 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -21,6 +21,7 @@
#include <linux/interrupt.h>
#include <linux/mutex.h>
#include <linux/math64.h>
+#include <linux/mod_devicetable.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -462,8 +463,6 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
*/
struct flash_info {
- char *name;
-
/* 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.
@@ -481,74 +480,83 @@ struct flash_info {
#define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
};
+#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ ((kernel_ulong_t)&(struct flash_info) { \
+ .jedec_id = (_jedec_id), \
+ .ext_id = (_ext_id), \
+ .sector_size = (_sector_size), \
+ .n_sectors = (_n_sectors), \
+ .flags = (_flags), \
+ })
/* NOTE: double check command sets and memory organization when you add
* more flash chips. This current list focusses on newer chips, which
* have been converging on command sets which including JEDEC ID.
*/
-static struct flash_info __devinitdata m25p_data [] = {
-
+static const struct spi_device_id m25p_ids[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
- { "at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
- { "at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
+ { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
+ { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
- { "at25df041a", 0x1f4401, 0, 64 * 1024, 8, SECT_4K, },
- { "at25df641", 0x1f4800, 0, 64 * 1024, 128, SECT_4K, },
+ { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
+ { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
- { "at26f004", 0x1f0400, 0, 64 * 1024, 8, SECT_4K, },
- { "at26df081a", 0x1f4501, 0, 64 * 1024, 16, SECT_4K, },
- { "at26df161a", 0x1f4601, 0, 64 * 1024, 32, SECT_4K, },
- { "at26df321", 0x1f4701, 0, 64 * 1024, 64, 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(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
/* Macronix */
- { "mx25l12805d", 0xc22018, 0, 64 * 1024, 256, },
+ { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- { "s25sl004a", 0x010212, 0, 64 * 1024, 8, },
- { "s25sl008a", 0x010213, 0, 64 * 1024, 16, },
- { "s25sl016a", 0x010214, 0, 64 * 1024, 32, },
- { "s25sl032a", 0x010215, 0, 64 * 1024, 64, },
- { "s25sl064a", 0x010216, 0, 64 * 1024, 128, },
- { "s25sl12800", 0x012018, 0x0300, 256 * 1024, 64, },
- { "s25sl12801", 0x012018, 0x0301, 64 * 1024, 256, },
+ { "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) },
+ { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
+ { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
/* SST -- large erase sizes are "overlays", "sectors" are 4K */
- { "sst25vf040b", 0xbf258d, 0, 64 * 1024, 8, SECT_4K, },
- { "sst25vf080b", 0xbf258e, 0, 64 * 1024, 16, SECT_4K, },
- { "sst25vf016b", 0xbf2541, 0, 64 * 1024, 32, SECT_4K, },
- { "sst25vf032b", 0xbf254a, 0, 64 * 1024, 64, SECT_4K, },
+ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K) },
+ { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K) },
+ { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K) },
+ { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K) },
/* ST Microelectronics -- newer production may have feature updates */
- { "m25p05", 0x202010, 0, 32 * 1024, 2, },
- { "m25p10", 0x202011, 0, 32 * 1024, 4, },
- { "m25p20", 0x202012, 0, 64 * 1024, 4, },
- { "m25p40", 0x202013, 0, 64 * 1024, 8, },
- { "m25p80", 0, 0, 64 * 1024, 16, },
- { "m25p16", 0x202015, 0, 64 * 1024, 32, },
- { "m25p32", 0x202016, 0, 64 * 1024, 64, },
- { "m25p64", 0x202017, 0, 64 * 1024, 128, },
- { "m25p128", 0x202018, 0, 256 * 1024, 64, },
-
- { "m45pe10", 0x204011, 0, 64 * 1024, 2, },
- { "m45pe80", 0x204014, 0, 64 * 1024, 16, },
- { "m45pe16", 0x204015, 0, 64 * 1024, 32, },
-
- { "m25pe80", 0x208014, 0, 64 * 1024, 16, },
- { "m25pe16", 0x208015, 0, 64 * 1024, 32, SECT_4K, },
+ { "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) },
+
+ { "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 0) },
+ { "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 0) },
+ { "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 0) },
+
+ { "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 0) },
+ { "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, SECT_4K) },
/* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
- { "w25x10", 0xef3011, 0, 64 * 1024, 2, SECT_4K, },
- { "w25x20", 0xef3012, 0, 64 * 1024, 4, SECT_4K, },
- { "w25x40", 0xef3013, 0, 64 * 1024, 8, SECT_4K, },
- { "w25x80", 0xef3014, 0, 64 * 1024, 16, SECT_4K, },
- { "w25x16", 0xef3015, 0, 64 * 1024, 32, SECT_4K, },
- { "w25x32", 0xef3016, 0, 64 * 1024, 64, SECT_4K, },
- { "w25x64", 0xef3017, 0, 64 * 1024, 128, SECT_4K, },
+ { "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) },
+ { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
+ { },
};
+MODULE_DEVICE_TABLE(spi, m25p_ids);
-static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
+static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
{
int tmp;
u8 code = OPCODE_RDID;
@@ -575,16 +583,14 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
ext_jedec = id[3] << 8 | id[4];
- for (tmp = 0, info = m25p_data;
- tmp < ARRAY_SIZE(m25p_data);
- tmp++, info++) {
+ for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
+ info = (void *)m25p_ids[tmp].driver_data;
if (info->jedec_id == jedec) {
if (info->ext_id != 0 && info->ext_id != ext_jedec)
continue;
- return info;
+ return &m25p_ids[tmp];
}
}
- dev_err(&spi->dev, "unrecognized JEDEC id %06x\n", jedec);
return NULL;
}
@@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
*/
static int __devinit m25p_probe(struct spi_device *spi)
{
+ const struct spi_device_id *id;
struct flash_platform_data *data;
struct m25p *flash;
struct flash_info *info;
@@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
*/
data = spi->dev.platform_data;
if (data && data->type) {
- for (i = 0, info = m25p_data;
- i < ARRAY_SIZE(m25p_data);
- i++, info++) {
- if (strcmp(data->type, info->name) == 0)
- break;
+ for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
+ id = &m25p_ids[i];
+ info = (void *)m25p_ids[i].driver_data;
+ if (strcmp(data->type, id->name))
+ continue;
+ break;
}
/* unrecognized chip? */
- if (i == ARRAY_SIZE(m25p_data)) {
+ if (i == ARRAY_SIZE(m25p_ids) - 1) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
dev_name(&spi->dev), data->type);
info = NULL;
/* recognized; is that chip really what's there? */
} else if (info->jedec_id) {
- struct flash_info *chip = jedec_probe(spi);
+ id = jedec_probe(spi);
- if (!chip || chip != info) {
+ if (id != &m25p_ids[i]) {
dev_warn(&spi->dev, "found %s, expected %s\n",
- chip ? chip->name : "UNKNOWN",
- info->name);
+ id ? id->name : "UNKNOWN",
+ m25p_ids[i].name);
info = NULL;
}
}
- } else
- info = jedec_probe(spi);
+ } else {
+ id = jedec_probe(spi);
+ if (!id)
+ id = spi_get_device_id(spi);
+
+ info = (void *)id->driver_data;
+ }
if (!info)
return -ENODEV;
@@ -680,7 +693,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
flash->mtd.dev.parent = &spi->dev;
- dev_info(&spi->dev, "%s (%lld Kbytes)\n", info->name,
+ dev_info(&spi->dev, "%s (%lld Kbytes)\n", id->name,
(long long)flash->mtd.size >> 10);
DEBUG(MTD_DEBUG_LEVEL2,
@@ -766,6 +779,7 @@ static struct spi_driver m25p80_driver = {
.bus = &spi_bus_type,
.owner = THIS_MODULE,
},
+ .id_table = m25p_ids,
.probe = m25p_probe,
.remove = __devexit_p(m25p_remove),
--
1.6.3.3
^ permalink raw reply related [flat|nested] 131+ messages in thread* [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table
@ 2009-07-31 0:41 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-07-31 0:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Ben Dooks, David Brownell, David Woodhouse, Grant Likely,
Benjamin Herrenschmidt, Jean Delvare, linux-mtd, linux-kernel,
lm-sensors, linuxppc-dev
This patch converts the m25p80 driver so that now it uses .id_table
for device matching, making it properly detect devices on OpenFirmware
platforms (prior to this patch the driver misdetected non-JEDEC chips,
seeing all chips as "m25p80").
Also, now jedec_probe() only does jedec probing, nothing else. If it
is not able to detect a chip, NULL is returned and the driver fall
backs to the information specified by the platform (platform_data, or
exact ID).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mtd/devices/m25p80.c | 146 +++++++++++++++++++++++-------------------
1 files changed, 80 insertions(+), 66 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 10ed195..0d74b38 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -21,6 +21,7 @@
#include <linux/interrupt.h>
#include <linux/mutex.h>
#include <linux/math64.h>
+#include <linux/mod_devicetable.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -462,8 +463,6 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
*/
struct flash_info {
- char *name;
-
/* 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.
@@ -481,74 +480,83 @@ struct flash_info {
#define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
};
+#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ ((kernel_ulong_t)&(struct flash_info) { \
+ .jedec_id = (_jedec_id), \
+ .ext_id = (_ext_id), \
+ .sector_size = (_sector_size), \
+ .n_sectors = (_n_sectors), \
+ .flags = (_flags), \
+ })
/* NOTE: double check command sets and memory organization when you add
* more flash chips. This current list focusses on newer chips, which
* have been converging on command sets which including JEDEC ID.
*/
-static struct flash_info __devinitdata m25p_data [] = {
-
+static const struct spi_device_id m25p_ids[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
- { "at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
- { "at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
+ { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
+ { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
- { "at25df041a", 0x1f4401, 0, 64 * 1024, 8, SECT_4K, },
- { "at25df641", 0x1f4800, 0, 64 * 1024, 128, SECT_4K, },
+ { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
+ { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
- { "at26f004", 0x1f0400, 0, 64 * 1024, 8, SECT_4K, },
- { "at26df081a", 0x1f4501, 0, 64 * 1024, 16, SECT_4K, },
- { "at26df161a", 0x1f4601, 0, 64 * 1024, 32, SECT_4K, },
- { "at26df321", 0x1f4701, 0, 64 * 1024, 64, 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(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
/* Macronix */
- { "mx25l12805d", 0xc22018, 0, 64 * 1024, 256, },
+ { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- { "s25sl004a", 0x010212, 0, 64 * 1024, 8, },
- { "s25sl008a", 0x010213, 0, 64 * 1024, 16, },
- { "s25sl016a", 0x010214, 0, 64 * 1024, 32, },
- { "s25sl032a", 0x010215, 0, 64 * 1024, 64, },
- { "s25sl064a", 0x010216, 0, 64 * 1024, 128, },
- { "s25sl12800", 0x012018, 0x0300, 256 * 1024, 64, },
- { "s25sl12801", 0x012018, 0x0301, 64 * 1024, 256, },
+ { "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) },
+ { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
+ { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
/* SST -- large erase sizes are "overlays", "sectors" are 4K */
- { "sst25vf040b", 0xbf258d, 0, 64 * 1024, 8, SECT_4K, },
- { "sst25vf080b", 0xbf258e, 0, 64 * 1024, 16, SECT_4K, },
- { "sst25vf016b", 0xbf2541, 0, 64 * 1024, 32, SECT_4K, },
- { "sst25vf032b", 0xbf254a, 0, 64 * 1024, 64, SECT_4K, },
+ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K) },
+ { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K) },
+ { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K) },
+ { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K) },
/* ST Microelectronics -- newer production may have feature updates */
- { "m25p05", 0x202010, 0, 32 * 1024, 2, },
- { "m25p10", 0x202011, 0, 32 * 1024, 4, },
- { "m25p20", 0x202012, 0, 64 * 1024, 4, },
- { "m25p40", 0x202013, 0, 64 * 1024, 8, },
- { "m25p80", 0, 0, 64 * 1024, 16, },
- { "m25p16", 0x202015, 0, 64 * 1024, 32, },
- { "m25p32", 0x202016, 0, 64 * 1024, 64, },
- { "m25p64", 0x202017, 0, 64 * 1024, 128, },
- { "m25p128", 0x202018, 0, 256 * 1024, 64, },
-
- { "m45pe10", 0x204011, 0, 64 * 1024, 2, },
- { "m45pe80", 0x204014, 0, 64 * 1024, 16, },
- { "m45pe16", 0x204015, 0, 64 * 1024, 32, },
-
- { "m25pe80", 0x208014, 0, 64 * 1024, 16, },
- { "m25pe16", 0x208015, 0, 64 * 1024, 32, SECT_4K, },
+ { "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) },
+
+ { "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 0) },
+ { "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 0) },
+ { "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 0) },
+
+ { "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 0) },
+ { "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, SECT_4K) },
/* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
- { "w25x10", 0xef3011, 0, 64 * 1024, 2, SECT_4K, },
- { "w25x20", 0xef3012, 0, 64 * 1024, 4, SECT_4K, },
- { "w25x40", 0xef3013, 0, 64 * 1024, 8, SECT_4K, },
- { "w25x80", 0xef3014, 0, 64 * 1024, 16, SECT_4K, },
- { "w25x16", 0xef3015, 0, 64 * 1024, 32, SECT_4K, },
- { "w25x32", 0xef3016, 0, 64 * 1024, 64, SECT_4K, },
- { "w25x64", 0xef3017, 0, 64 * 1024, 128, SECT_4K, },
+ { "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) },
+ { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
+ { },
};
+MODULE_DEVICE_TABLE(spi, m25p_ids);
-static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
+static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
{
int tmp;
u8 code = OPCODE_RDID;
@@ -575,16 +583,14 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
ext_jedec = id[3] << 8 | id[4];
- for (tmp = 0, info = m25p_data;
- tmp < ARRAY_SIZE(m25p_data);
- tmp++, info++) {
+ for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
+ info = (void *)m25p_ids[tmp].driver_data;
if (info->jedec_id = jedec) {
if (info->ext_id != 0 && info->ext_id != ext_jedec)
continue;
- return info;
+ return &m25p_ids[tmp];
}
}
- dev_err(&spi->dev, "unrecognized JEDEC id %06x\n", jedec);
return NULL;
}
@@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
*/
static int __devinit m25p_probe(struct spi_device *spi)
{
+ const struct spi_device_id *id;
struct flash_platform_data *data;
struct m25p *flash;
struct flash_info *info;
@@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
*/
data = spi->dev.platform_data;
if (data && data->type) {
- for (i = 0, info = m25p_data;
- i < ARRAY_SIZE(m25p_data);
- i++, info++) {
- if (strcmp(data->type, info->name) = 0)
- break;
+ for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
+ id = &m25p_ids[i];
+ info = (void *)m25p_ids[i].driver_data;
+ if (strcmp(data->type, id->name))
+ continue;
+ break;
}
/* unrecognized chip? */
- if (i = ARRAY_SIZE(m25p_data)) {
+ if (i = ARRAY_SIZE(m25p_ids) - 1) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
dev_name(&spi->dev), data->type);
info = NULL;
/* recognized; is that chip really what's there? */
} else if (info->jedec_id) {
- struct flash_info *chip = jedec_probe(spi);
+ id = jedec_probe(spi);
- if (!chip || chip != info) {
+ if (id != &m25p_ids[i]) {
dev_warn(&spi->dev, "found %s, expected %s\n",
- chip ? chip->name : "UNKNOWN",
- info->name);
+ id ? id->name : "UNKNOWN",
+ m25p_ids[i].name);
info = NULL;
}
}
- } else
- info = jedec_probe(spi);
+ } else {
+ id = jedec_probe(spi);
+ if (!id)
+ id = spi_get_device_id(spi);
+
+ info = (void *)id->driver_data;
+ }
if (!info)
return -ENODEV;
@@ -680,7 +693,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
flash->mtd.dev.parent = &spi->dev;
- dev_info(&spi->dev, "%s (%lld Kbytes)\n", info->name,
+ dev_info(&spi->dev, "%s (%lld Kbytes)\n", id->name,
(long long)flash->mtd.size >> 10);
DEBUG(MTD_DEBUG_LEVEL2,
@@ -766,6 +779,7 @@ static struct spi_driver m25p80_driver = {
.bus = &spi_bus_type,
.owner = THIS_MODULE,
},
+ .id_table = m25p_ids,
.probe = m25p_probe,
.remove = __devexit_p(m25p_remove),
--
1.6.3.3
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply related [flat|nested] 131+ messages in thread* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
2009-07-31 0:41 ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table Anton Vorontsov
(?)
(?)
@ 2009-08-04 2:54 ` David Brownell
-1 siblings, 0 replies; 131+ messages in thread
From: David Brownell @ 2009-08-04 2:54 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ben Dooks, Benjamin Herrenschmidt, linux-kernel, lm-sensors,
Grant Likely, linuxppc-dev, linux-mtd, Jean Delvare,
Andrew Morton, David Woodhouse
On Thursday 30 July 2009, Anton Vorontsov wrote:
> This patch converts the m25p80 driver so that now it uses .id_table
> for device matching, making it properly detect devices on OpenFirmware
> platforms (prior to this patch the driver misdetected non-JEDEC chips,
> seeing all chips as "m25p80").
I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
All others got explicit declarations ... so if there's misbehavior for
other chips, it's because those declarations were poorly handled. Maybe
they were not properly flagged as non-JDEC
> Also, now jedec_probe() only does jedec probing, nothing else. If it
> is not able to detect a chip, NULL is returned and the driver fall
> backs to the information specified by the platform (platform_data, or
> exact ID).
I'd rather keep the warning, so there's a clue about what's really
going on: JEDEC chip found, but its ID is not handled.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/mtd/devices/m25p80.c | 146 +++++++++++++++++++++++-------------------
> 1 files changed, 80 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 10ed195..0d74b38 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> ... deletia ...
> @@ -481,74 +480,83 @@ struct flash_info {
> #define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
> };
>
> +#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
> + ((kernel_ulong_t)&(struct flash_info) { \
> + .jedec_id = (_jedec_id), \
> + .ext_id = (_ext_id), \
> + .sector_size = (_sector_size), \
> + .n_sectors = (_n_sectors), \
> + .flags = (_flags), \
> + })
Anonymous inlined structures ... kind of ugly, but I can
understand why you might not want to declare and name a
few dozen single-use structures.
>
> /* NOTE: double check command sets and memory organization when you add
> * more flash chips. This current list focusses on newer chips, which
> * have been converging on command sets which including JEDEC ID.
> */
> -static struct flash_info __devinitdata m25p_data [] = {
> -
> +static const struct spi_device_id m25p_ids[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> - { "at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
> - { "at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
> + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
> + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
>
> ... deletia ...
>
> @@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
> */
> static int __devinit m25p_probe(struct spi_device *spi)
> {
> + const struct spi_device_id *id;
> struct flash_platform_data *data;
> struct m25p *flash;
> struct flash_info *info;
> @@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
> */
> data = spi->dev.platform_data;
> if (data && data->type) {
At this point I wonder why you're not changing the probe sequence
more. Get "id" and then "id" here. If it's for "m25p80" assume
it's an old-style board init and do the current logic. Else just
verify "info".
There's a new error case of course: new-style but data->type
doesn't match id->name.
> - for (i = 0, info = m25p_data;
> - i < ARRAY_SIZE(m25p_data);
> - i++, info++) {
> - if (strcmp(data->type, info->name) == 0)
> - break;
> + for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
> + id = &m25p_ids[i];
> + info = (void *)m25p_ids[i].driver_data;
> + if (strcmp(data->type, id->name))
> + continue;
> + break;
> }
>
> /* unrecognized chip? */
> - if (i == ARRAY_SIZE(m25p_data)) {
> + if (i == ARRAY_SIZE(m25p_ids) - 1) {
Better: "if (info == NULL) ..." You've got all the pointers
in hand; don't use indices.
> DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
> dev_name(&spi->dev), data->type);
> info = NULL;
>
> /* recognized; is that chip really what's there? */
> } else if (info->jedec_id) {
> - struct flash_info *chip = jedec_probe(spi);
> + id = jedec_probe(spi);
>
> - if (!chip || chip != info) {
> + if (id != &m25p_ids[i]) {
Again, don't use indices except during the lookup.
> dev_warn(&spi->dev, "found %s, expected %s\n",
> - chip ? chip->name : "UNKNOWN",
> - info->name);
> + id ? id->name : "UNKNOWN",
> + m25p_ids[i].name);
> info = NULL;
> }
> }
> - } else
> - info = jedec_probe(spi);
> + } else {
> + id = jedec_probe(spi);
> + if (!id)
> + id = spi_get_device_id(spi);
> +
> + info = (void *)id->driver_data;
> + }
>
> if (!info)
> return -ENODEV;
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-08-04 2:54 ` David Brownell
0 siblings, 0 replies; 131+ messages in thread
From: David Brownell @ 2009-08-04 2:54 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Andrew Morton, Ben Dooks, David Woodhouse, Grant Likely,
Benjamin Herrenschmidt, Jean Delvare, linux-mtd, linux-kernel,
lm-sensors, linuxppc-dev
On Thursday 30 July 2009, Anton Vorontsov wrote:
> This patch converts the m25p80 driver so that now it uses .id_table
> for device matching, making it properly detect devices on OpenFirmware
> platforms (prior to this patch the driver misdetected non-JEDEC chips,
> seeing all chips as "m25p80").
I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
All others got explicit declarations ... so if there's misbehavior for
other chips, it's because those declarations were poorly handled. Maybe
they were not properly flagged as non-JDEC
> Also, now jedec_probe() only does jedec probing, nothing else. If it
> is not able to detect a chip, NULL is returned and the driver fall
> backs to the information specified by the platform (platform_data, or
> exact ID).
I'd rather keep the warning, so there's a clue about what's really
going on: JEDEC chip found, but its ID is not handled.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/mtd/devices/m25p80.c | 146 +++++++++++++++++++++++-------------------
> 1 files changed, 80 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 10ed195..0d74b38 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> ... deletia ...
> @@ -481,74 +480,83 @@ struct flash_info {
> #define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
> };
>
> +#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
> + ((kernel_ulong_t)&(struct flash_info) { \
> + .jedec_id = (_jedec_id), \
> + .ext_id = (_ext_id), \
> + .sector_size = (_sector_size), \
> + .n_sectors = (_n_sectors), \
> + .flags = (_flags), \
> + })
Anonymous inlined structures ... kind of ugly, but I can
understand why you might not want to declare and name a
few dozen single-use structures.
>
> /* NOTE: double check command sets and memory organization when you add
> * more flash chips. This current list focusses on newer chips, which
> * have been converging on command sets which including JEDEC ID.
> */
> -static struct flash_info __devinitdata m25p_data [] = {
> -
> +static const struct spi_device_id m25p_ids[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> - { "at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
> - { "at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
> + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
> + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
>
> ... deletia ...
>
> @@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
> */
> static int __devinit m25p_probe(struct spi_device *spi)
> {
> + const struct spi_device_id *id;
> struct flash_platform_data *data;
> struct m25p *flash;
> struct flash_info *info;
> @@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
> */
> data = spi->dev.platform_data;
> if (data && data->type) {
At this point I wonder why you're not changing the probe sequence
more. Get "id" and then "id" here. If it's for "m25p80" assume
it's an old-style board init and do the current logic. Else just
verify "info".
There's a new error case of course: new-style but data->type
doesn't match id->name.
> - for (i = 0, info = m25p_data;
> - i < ARRAY_SIZE(m25p_data);
> - i++, info++) {
> - if (strcmp(data->type, info->name) == 0)
> - break;
> + for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
> + id = &m25p_ids[i];
> + info = (void *)m25p_ids[i].driver_data;
> + if (strcmp(data->type, id->name))
> + continue;
> + break;
> }
>
> /* unrecognized chip? */
> - if (i == ARRAY_SIZE(m25p_data)) {
> + if (i == ARRAY_SIZE(m25p_ids) - 1) {
Better: "if (info == NULL) ..." You've got all the pointers
in hand; don't use indices.
> DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
> dev_name(&spi->dev), data->type);
> info = NULL;
>
> /* recognized; is that chip really what's there? */
> } else if (info->jedec_id) {
> - struct flash_info *chip = jedec_probe(spi);
> + id = jedec_probe(spi);
>
> - if (!chip || chip != info) {
> + if (id != &m25p_ids[i]) {
Again, don't use indices except during the lookup.
> dev_warn(&spi->dev, "found %s, expected %s\n",
> - chip ? chip->name : "UNKNOWN",
> - info->name);
> + id ? id->name : "UNKNOWN",
> + m25p_ids[i].name);
> info = NULL;
> }
> }
> - } else
> - info = jedec_probe(spi);
> + } else {
> + id = jedec_probe(spi);
> + if (!id)
> + id = spi_get_device_id(spi);
> +
> + info = (void *)id->driver_data;
> + }
>
> if (!info)
> return -ENODEV;
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-08-04 2:54 ` David Brownell
0 siblings, 0 replies; 131+ messages in thread
From: David Brownell @ 2009-08-04 2:54 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ben Dooks, linux-kernel, lm-sensors, linuxppc-dev, linux-mtd,
Jean Delvare, Andrew Morton, David Woodhouse
On Thursday 30 July 2009, Anton Vorontsov wrote:
> This patch converts the m25p80 driver so that now it uses .id_table
> for device matching, making it properly detect devices on OpenFirmware
> platforms (prior to this patch the driver misdetected non-JEDEC chips,
> seeing all chips as "m25p80").
I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
All others got explicit declarations ... so if there's misbehavior for
other chips, it's because those declarations were poorly handled. Maybe
they were not properly flagged as non-JDEC
> Also, now jedec_probe() only does jedec probing, nothing else. If it
> is not able to detect a chip, NULL is returned and the driver fall
> backs to the information specified by the platform (platform_data, or
> exact ID).
I'd rather keep the warning, so there's a clue about what's really
going on: JEDEC chip found, but its ID is not handled.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/mtd/devices/m25p80.c | 146 +++++++++++++++++++++++-------------------
> 1 files changed, 80 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 10ed195..0d74b38 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> ... deletia ...
> @@ -481,74 +480,83 @@ struct flash_info {
> #define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
> };
>
> +#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
> + ((kernel_ulong_t)&(struct flash_info) { \
> + .jedec_id = (_jedec_id), \
> + .ext_id = (_ext_id), \
> + .sector_size = (_sector_size), \
> + .n_sectors = (_n_sectors), \
> + .flags = (_flags), \
> + })
Anonymous inlined structures ... kind of ugly, but I can
understand why you might not want to declare and name a
few dozen single-use structures.
>
> /* NOTE: double check command sets and memory organization when you add
> * more flash chips. This current list focusses on newer chips, which
> * have been converging on command sets which including JEDEC ID.
> */
> -static struct flash_info __devinitdata m25p_data [] = {
> -
> +static const struct spi_device_id m25p_ids[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> - { "at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
> - { "at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
> + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
> + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
>
> ... deletia ...
>
> @@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
> */
> static int __devinit m25p_probe(struct spi_device *spi)
> {
> + const struct spi_device_id *id;
> struct flash_platform_data *data;
> struct m25p *flash;
> struct flash_info *info;
> @@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
> */
> data = spi->dev.platform_data;
> if (data && data->type) {
At this point I wonder why you're not changing the probe sequence
more. Get "id" and then "id" here. If it's for "m25p80" assume
it's an old-style board init and do the current logic. Else just
verify "info".
There's a new error case of course: new-style but data->type
doesn't match id->name.
> - for (i = 0, info = m25p_data;
> - i < ARRAY_SIZE(m25p_data);
> - i++, info++) {
> - if (strcmp(data->type, info->name) == 0)
> - break;
> + for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
> + id = &m25p_ids[i];
> + info = (void *)m25p_ids[i].driver_data;
> + if (strcmp(data->type, id->name))
> + continue;
> + break;
> }
>
> /* unrecognized chip? */
> - if (i == ARRAY_SIZE(m25p_data)) {
> + if (i == ARRAY_SIZE(m25p_ids) - 1) {
Better: "if (info == NULL) ..." You've got all the pointers
in hand; don't use indices.
> DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
> dev_name(&spi->dev), data->type);
> info = NULL;
>
> /* recognized; is that chip really what's there? */
> } else if (info->jedec_id) {
> - struct flash_info *chip = jedec_probe(spi);
> + id = jedec_probe(spi);
>
> - if (!chip || chip != info) {
> + if (id != &m25p_ids[i]) {
Again, don't use indices except during the lookup.
> dev_warn(&spi->dev, "found %s, expected %s\n",
> - chip ? chip->name : "UNKNOWN",
> - info->name);
> + id ? id->name : "UNKNOWN",
> + m25p_ids[i].name);
> info = NULL;
> }
> }
> - } else
> - info = jedec_probe(spi);
> + } else {
> + id = jedec_probe(spi);
> + if (!id)
> + id = spi_get_device_id(spi);
> +
> + info = (void *)id->driver_data;
> + }
>
> if (!info)
> return -ENODEV;
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table
@ 2009-08-04 2:54 ` David Brownell
0 siblings, 0 replies; 131+ messages in thread
From: David Brownell @ 2009-08-04 2:54 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Andrew Morton, Ben Dooks, David Woodhouse, Grant Likely,
Benjamin Herrenschmidt, Jean Delvare, linux-mtd, linux-kernel,
lm-sensors, linuxppc-dev
On Thursday 30 July 2009, Anton Vorontsov wrote:
> This patch converts the m25p80 driver so that now it uses .id_table
> for device matching, making it properly detect devices on OpenFirmware
> platforms (prior to this patch the driver misdetected non-JEDEC chips,
> seeing all chips as "m25p80").
I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
All others got explicit declarations ... so if there's misbehavior for
other chips, it's because those declarations were poorly handled. Maybe
they were not properly flagged as non-JDEC
> Also, now jedec_probe() only does jedec probing, nothing else. If it
> is not able to detect a chip, NULL is returned and the driver fall
> backs to the information specified by the platform (platform_data, or
> exact ID).
I'd rather keep the warning, so there's a clue about what's really
going on: JEDEC chip found, but its ID is not handled.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/mtd/devices/m25p80.c | 146 +++++++++++++++++++++++-------------------
> 1 files changed, 80 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 10ed195..0d74b38 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> ... deletia ...
> @@ -481,74 +480,83 @@ struct flash_info {
> #define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
> };
>
> +#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
> + ((kernel_ulong_t)&(struct flash_info) { \
> + .jedec_id = (_jedec_id), \
> + .ext_id = (_ext_id), \
> + .sector_size = (_sector_size), \
> + .n_sectors = (_n_sectors), \
> + .flags = (_flags), \
> + })
Anonymous inlined structures ... kind of ugly, but I can
understand why you might not want to declare and name a
few dozen single-use structures.
>
> /* NOTE: double check command sets and memory organization when you add
> * more flash chips. This current list focusses on newer chips, which
> * have been converging on command sets which including JEDEC ID.
> */
> -static struct flash_info __devinitdata m25p_data [] = {
> -
> +static const struct spi_device_id m25p_ids[] = {
> /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> - { "at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
> - { "at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
> + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
> + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
>
> ... deletia ...
>
> @@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
> */
> static int __devinit m25p_probe(struct spi_device *spi)
> {
> + const struct spi_device_id *id;
> struct flash_platform_data *data;
> struct m25p *flash;
> struct flash_info *info;
> @@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
> */
> data = spi->dev.platform_data;
> if (data && data->type) {
At this point I wonder why you're not changing the probe sequence
more. Get "id" and then "id" here. If it's for "m25p80" assume
it's an old-style board init and do the current logic. Else just
verify "info".
There's a new error case of course: new-style but data->type
doesn't match id->name.
> - for (i = 0, info = m25p_data;
> - i < ARRAY_SIZE(m25p_data);
> - i++, info++) {
> - if (strcmp(data->type, info->name) = 0)
> - break;
> + for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
> + id = &m25p_ids[i];
> + info = (void *)m25p_ids[i].driver_data;
> + if (strcmp(data->type, id->name))
> + continue;
> + break;
> }
>
> /* unrecognized chip? */
> - if (i = ARRAY_SIZE(m25p_data)) {
> + if (i = ARRAY_SIZE(m25p_ids) - 1) {
Better: "if (info = NULL) ..." You've got all the pointers
in hand; don't use indices.
> DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
> dev_name(&spi->dev), data->type);
> info = NULL;
>
> /* recognized; is that chip really what's there? */
> } else if (info->jedec_id) {
> - struct flash_info *chip = jedec_probe(spi);
> + id = jedec_probe(spi);
>
> - if (!chip || chip != info) {
> + if (id != &m25p_ids[i]) {
Again, don't use indices except during the lookup.
> dev_warn(&spi->dev, "found %s, expected %s\n",
> - chip ? chip->name : "UNKNOWN",
> - info->name);
> + id ? id->name : "UNKNOWN",
> + m25p_ids[i].name);
> info = NULL;
> }
> }
> - } else
> - info = jedec_probe(spi);
> + } else {
> + id = jedec_probe(spi);
> + if (!id)
> + id = spi_get_device_id(spi);
> +
> + info = (void *)id->driver_data;
> + }
>
> if (!info)
> return -ENODEV;
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
2009-08-04 2:54 ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table David Brownell
(?)
(?)
@ 2009-08-18 21:44 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-18 21:44 UTC (permalink / raw)
To: David Brownell
Cc: Ben Dooks, Benjamin Herrenschmidt, linux-kernel, lm-sensors,
Grant Likely, linuxppc-dev, linux-mtd, Jean Delvare,
Andrew Morton, David Woodhouse
Hi David,
Thanks for the review, and sorry for the delayed response.
On Mon, Aug 03, 2009 at 07:54:50PM -0700, David Brownell wrote:
> On Thursday 30 July 2009, Anton Vorontsov wrote:
> > This patch converts the m25p80 driver so that now it uses .id_table
> > for device matching, making it properly detect devices on OpenFirmware
> > platforms (prior to this patch the driver misdetected non-JEDEC chips,
> > seeing all chips as "m25p80").
>
> I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
Currently the driver always tries JEDEC probing, and it wrongly "assumed"
that all non-JEDEC chips are m25p80, because an entry for m25p80 chips
had "0" in jedec id field, which isn't correct ID, but 0 is returned by
most non-JEDEC chips. Having 0 in the m25p80 entry was a hack.
> All others got explicit declarations ... so if there's misbehavior for
> other chips, it's because those declarations were poorly handled. Maybe
> they were not properly flagged as non-JDEC
> > Also, now jedec_probe() only does jedec probing, nothing else. If it
> > is not able to detect a chip, NULL is returned and the driver fall
> > backs to the information specified by the platform (platform_data, or
> > exact ID).
>
> I'd rather keep the warning, so there's a clue about what's really
> going on: JEDEC chip found, but its ID is not handled.
We can't tell if the chip was actually found.
M25Px0 chips can be JEDEC and non-JEDEC, e.g. Nymonyx manufacturing
"M25P80" chips in two variants: "The RDID instruction is available only
for parts made with Technology T9HX (0.11μm), ..."
Most (but not all) non-JEDEC EEPROMs will return "0" for RDID opcode
though (in that case warning is misleading). And for the chips that
don't return 0, we shouldn't probe them with jedec at all.
[...]
> > @@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
> > */
> > data = spi->dev.platform_data;
> > if (data && data->type) {
>
> At this point I wonder why you're not changing the probe sequence
> more.
Yep, I was going to do it anyway, but for another reason: to support
CAT25 chips.
> There's a new error case of course: new-style but data->type
> doesn't match id->name.
[...]
> > + if (i == ARRAY_SIZE(m25p_ids) - 1) {
>
> Better: "if (info == NULL) ..." You've got all the pointers
> in hand; don't use indices.
[...]
> > + if (id != &m25p_ids[i]) {
>
> Again, don't use indices except during the lookup.
Yep, good ideas. Though, the code will vanish anyway.
Patches on the way...
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-08-18 21:44 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-18 21:44 UTC (permalink / raw)
To: David Brownell
Cc: Andrew Morton, Ben Dooks, David Woodhouse, Grant Likely,
Benjamin Herrenschmidt, Jean Delvare, linux-mtd, linux-kernel,
lm-sensors, linuxppc-dev
Hi David,
Thanks for the review, and sorry for the delayed response.
On Mon, Aug 03, 2009 at 07:54:50PM -0700, David Brownell wrote:
> On Thursday 30 July 2009, Anton Vorontsov wrote:
> > This patch converts the m25p80 driver so that now it uses .id_table
> > for device matching, making it properly detect devices on OpenFirmware
> > platforms (prior to this patch the driver misdetected non-JEDEC chips,
> > seeing all chips as "m25p80").
>
> I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
Currently the driver always tries JEDEC probing, and it wrongly "assumed"
that all non-JEDEC chips are m25p80, because an entry for m25p80 chips
had "0" in jedec id field, which isn't correct ID, but 0 is returned by
most non-JEDEC chips. Having 0 in the m25p80 entry was a hack.
> All others got explicit declarations ... so if there's misbehavior for
> other chips, it's because those declarations were poorly handled. Maybe
> they were not properly flagged as non-JDEC
> > Also, now jedec_probe() only does jedec probing, nothing else. If it
> > is not able to detect a chip, NULL is returned and the driver fall
> > backs to the information specified by the platform (platform_data, or
> > exact ID).
>
> I'd rather keep the warning, so there's a clue about what's really
> going on: JEDEC chip found, but its ID is not handled.
We can't tell if the chip was actually found.
M25Px0 chips can be JEDEC and non-JEDEC, e.g. Nymonyx manufacturing
"M25P80" chips in two variants: "The RDID instruction is available only
for parts made with Technology T9HX (0.11μm), ..."
Most (but not all) non-JEDEC EEPROMs will return "0" for RDID opcode
though (in that case warning is misleading). And for the chips that
don't return 0, we shouldn't probe them with jedec at all.
[...]
> > @@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
> > */
> > data = spi->dev.platform_data;
> > if (data && data->type) {
>
> At this point I wonder why you're not changing the probe sequence
> more.
Yep, I was going to do it anyway, but for another reason: to support
CAT25 chips.
> There's a new error case of course: new-style but data->type
> doesn't match id->name.
[...]
> > + if (i == ARRAY_SIZE(m25p_ids) - 1) {
>
> Better: "if (info == NULL) ..." You've got all the pointers
> in hand; don't use indices.
[...]
> > + if (id != &m25p_ids[i]) {
>
> Again, don't use indices except during the lookup.
Yep, good ideas. Though, the code will vanish anyway.
Patches on the way...
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-08-18 21:44 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-18 21:44 UTC (permalink / raw)
To: David Brownell
Cc: Ben Dooks, linux-kernel, lm-sensors, linuxppc-dev, linux-mtd,
Jean Delvare, Andrew Morton, David Woodhouse
Hi David,
Thanks for the review, and sorry for the delayed response.
On Mon, Aug 03, 2009 at 07:54:50PM -0700, David Brownell wrote:
> On Thursday 30 July 2009, Anton Vorontsov wrote:
> > This patch converts the m25p80 driver so that now it uses .id_table
> > for device matching, making it properly detect devices on OpenFirmware
> > platforms (prior to this patch the driver misdetected non-JEDEC chips,
> > seeing all chips as "m25p80").
>
> I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
Currently the driver always tries JEDEC probing, and it wrongly "assumed"
that all non-JEDEC chips are m25p80, because an entry for m25p80 chips
had "0" in jedec id field, which isn't correct ID, but 0 is returned by
most non-JEDEC chips. Having 0 in the m25p80 entry was a hack.
> All others got explicit declarations ... so if there's misbehavior for
> other chips, it's because those declarations were poorly handled. Maybe
> they were not properly flagged as non-JDEC
> > Also, now jedec_probe() only does jedec probing, nothing else. If it
> > is not able to detect a chip, NULL is returned and the driver fall
> > backs to the information specified by the platform (platform_data, or
> > exact ID).
>
> I'd rather keep the warning, so there's a clue about what's really
> going on: JEDEC chip found, but its ID is not handled.
We can't tell if the chip was actually found.
M25Px0 chips can be JEDEC and non-JEDEC, e.g. Nymonyx manufacturing
"M25P80" chips in two variants: "The RDID instruction is available only
for parts made with Technology T9HX (0.11μm), ..."
Most (but not all) non-JEDEC EEPROMs will return "0" for RDID opcode
though (in that case warning is misleading). And for the chips that
don't return 0, we shouldn't probe them with jedec at all.
[...]
> > @@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
> > */
> > data = spi->dev.platform_data;
> > if (data && data->type) {
>
> At this point I wonder why you're not changing the probe sequence
> more.
Yep, I was going to do it anyway, but for another reason: to support
CAT25 chips.
> There's a new error case of course: new-style but data->type
> doesn't match id->name.
[...]
> > + if (i == ARRAY_SIZE(m25p_ids) - 1) {
>
> Better: "if (info == NULL) ..." You've got all the pointers
> in hand; don't use indices.
[...]
> > + if (id != &m25p_ids[i]) {
>
> Again, don't use indices except during the lookup.
Yep, good ideas. Though, the code will vanish anyway.
Patches on the way...
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table
@ 2009-08-18 21:44 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-18 21:44 UTC (permalink / raw)
To: David Brownell
Cc: Andrew Morton, Ben Dooks, David Woodhouse, Grant Likely,
Benjamin Herrenschmidt, Jean Delvare, linux-mtd, linux-kernel,
lm-sensors, linuxppc-dev
Hi David,
Thanks for the review, and sorry for the delayed response.
On Mon, Aug 03, 2009 at 07:54:50PM -0700, David Brownell wrote:
> On Thursday 30 July 2009, Anton Vorontsov wrote:
> > This patch converts the m25p80 driver so that now it uses .id_table
> > for device matching, making it properly detect devices on OpenFirmware
> > platforms (prior to this patch the driver misdetected non-JEDEC chips,
> > seeing all chips as "m25p80").
>
> I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
Currently the driver always tries JEDEC probing, and it wrongly "assumed"
that all non-JEDEC chips are m25p80, because an entry for m25p80 chips
had "0" in jedec id field, which isn't correct ID, but 0 is returned by
most non-JEDEC chips. Having 0 in the m25p80 entry was a hack.
> All others got explicit declarations ... so if there's misbehavior for
> other chips, it's because those declarations were poorly handled. Maybe
> they were not properly flagged as non-JDEC
> > Also, now jedec_probe() only does jedec probing, nothing else. If it
> > is not able to detect a chip, NULL is returned and the driver fall
> > backs to the information specified by the platform (platform_data, or
> > exact ID).
>
> I'd rather keep the warning, so there's a clue about what's really
> going on: JEDEC chip found, but its ID is not handled.
We can't tell if the chip was actually found.
M25Px0 chips can be JEDEC and non-JEDEC, e.g. Nymonyx manufacturing
"M25P80" chips in two variants: "The RDID instruction is available only
for parts made with Technology T9HX (0.11μm), ..."
Most (but not all) non-JEDEC EEPROMs will return "0" for RDID opcode
though (in that case warning is misleading). And for the chips that
don't return 0, we shouldn't probe them with jedec at all.
[...]
> > @@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
> > */
> > data = spi->dev.platform_data;
> > if (data && data->type) {
>
> At this point I wonder why you're not changing the probe sequence
> more.
Yep, I was going to do it anyway, but for another reason: to support
CAT25 chips.
> There's a new error case of course: new-style but data->type
> doesn't match id->name.
[...]
> > + if (i = ARRAY_SIZE(m25p_ids) - 1) {
>
> Better: "if (info = NULL) ..." You've got all the pointers
> in hand; don't use indices.
[...]
> > + if (id != &m25p_ids[i]) {
>
> Again, don't use indices except during the lookup.
Yep, good ideas. Though, the code will vanish anyway.
Patches on the way...
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 131+ messages in thread* [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code
2009-08-18 21:44 ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table Anton Vorontsov
@ 2009-08-18 21:46 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-18 21:46 UTC (permalink / raw)
To: Andrew Morton
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, David Woodhouse
Previosly the driver always tried JEDEC probing, assuming that non-JEDEC
chips will return '0'. But truly non-JEDEC chips (like CAT25) won't do
that, their behaviour on RDID command is undefined, so the driver should
not call jedec_probe() for these chips.
Also, be less strict on error conditions, don't fail to probe if JEDEC
found a chip that is different from what platform code told, instead
just print some warnings and use an information obtained via JEDEC. In
that case we should not trust partitions any longer, but they might be
still useful (i.e. they could protect some parts of the chip).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mtd/devices/m25p80.c | 69 ++++++++++++++++++++++++-----------------
1 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 0d74b38..b75e319 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -581,6 +581,14 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
jedec = jedec << 8;
jedec |= id[2];
+ /*
+ * Some chips (like Numonyx M25P80) have JEDEC and non-JEDEC variants,
+ * which depend on technology process. Officially RDID command doesn't
+ * exist for non-JEDEC chips, but for compatibility they return ID 0.
+ */
+ if (jedec == 0)
+ return NULL;
+
ext_jedec = id[3] << 8 | id[4];
for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
@@ -602,7 +610,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
*/
static int __devinit m25p_probe(struct spi_device *spi)
{
- const struct spi_device_id *id;
+ const struct spi_device_id *id = spi_get_device_id(spi);
struct flash_platform_data *data;
struct m25p *flash;
struct flash_info *info;
@@ -615,41 +623,44 @@ static int __devinit m25p_probe(struct spi_device *spi)
*/
data = spi->dev.platform_data;
if (data && data->type) {
+ const struct spi_device_id *plat_id;
+
for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
- id = &m25p_ids[i];
- info = (void *)m25p_ids[i].driver_data;
- if (strcmp(data->type, id->name))
+ plat_id = &m25p_ids[i];
+ if (strcmp(data->type, plat_id->name))
continue;
break;
}
- /* unrecognized chip? */
- if (i == ARRAY_SIZE(m25p_ids) - 1) {
- DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
- dev_name(&spi->dev), data->type);
- info = NULL;
-
- /* recognized; is that chip really what's there? */
- } else if (info->jedec_id) {
- id = jedec_probe(spi);
-
- if (id != &m25p_ids[i]) {
- dev_warn(&spi->dev, "found %s, expected %s\n",
- id ? id->name : "UNKNOWN",
- m25p_ids[i].name);
- info = NULL;
- }
- }
- } else {
- id = jedec_probe(spi);
- if (!id)
- id = spi_get_device_id(spi);
-
- info = (void *)id->driver_data;
+ if (plat_id)
+ id = plat_id;
+ else
+ dev_warn(&spi->dev, "unrecognized id %s\n", data->type);
}
- if (!info)
- return -ENODEV;
+ info = (void *)id->driver_data;
+
+ if (info->jedec_id) {
+ const struct spi_device_id *jid;
+
+ jid = jedec_probe(spi);
+ if (!jid) {
+ dev_info(&spi->dev, "non-JEDEC variant of %s\n",
+ id->name);
+ } 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(&spi->dev, "found %s, expected %s\n",
+ jid->name, id->name);
+ id = jid;
+ info = (void *)jid->driver_data;
+ }
+ }
flash = kzalloc(sizeof *flash, GFP_KERNEL);
if (!flash)
--
1.6.3.3
^ permalink raw reply related [flat|nested] 131+ messages in thread* [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code
@ 2009-08-18 21:46 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-18 21:46 UTC (permalink / raw)
To: Andrew Morton
Cc: David Brownell, David Woodhouse, Artem Bityutskiy, linux-mtd,
linux-kernel, linuxppc-dev
Previosly the driver always tried JEDEC probing, assuming that non-JEDEC
chips will return '0'. But truly non-JEDEC chips (like CAT25) won't do
that, their behaviour on RDID command is undefined, so the driver should
not call jedec_probe() for these chips.
Also, be less strict on error conditions, don't fail to probe if JEDEC
found a chip that is different from what platform code told, instead
just print some warnings and use an information obtained via JEDEC. In
that case we should not trust partitions any longer, but they might be
still useful (i.e. they could protect some parts of the chip).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mtd/devices/m25p80.c | 69 ++++++++++++++++++++++++-----------------
1 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 0d74b38..b75e319 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -581,6 +581,14 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
jedec = jedec << 8;
jedec |= id[2];
+ /*
+ * Some chips (like Numonyx M25P80) have JEDEC and non-JEDEC variants,
+ * which depend on technology process. Officially RDID command doesn't
+ * exist for non-JEDEC chips, but for compatibility they return ID 0.
+ */
+ if (jedec == 0)
+ return NULL;
+
ext_jedec = id[3] << 8 | id[4];
for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
@@ -602,7 +610,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
*/
static int __devinit m25p_probe(struct spi_device *spi)
{
- const struct spi_device_id *id;
+ const struct spi_device_id *id = spi_get_device_id(spi);
struct flash_platform_data *data;
struct m25p *flash;
struct flash_info *info;
@@ -615,41 +623,44 @@ static int __devinit m25p_probe(struct spi_device *spi)
*/
data = spi->dev.platform_data;
if (data && data->type) {
+ const struct spi_device_id *plat_id;
+
for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
- id = &m25p_ids[i];
- info = (void *)m25p_ids[i].driver_data;
- if (strcmp(data->type, id->name))
+ plat_id = &m25p_ids[i];
+ if (strcmp(data->type, plat_id->name))
continue;
break;
}
- /* unrecognized chip? */
- if (i == ARRAY_SIZE(m25p_ids) - 1) {
- DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
- dev_name(&spi->dev), data->type);
- info = NULL;
-
- /* recognized; is that chip really what's there? */
- } else if (info->jedec_id) {
- id = jedec_probe(spi);
-
- if (id != &m25p_ids[i]) {
- dev_warn(&spi->dev, "found %s, expected %s\n",
- id ? id->name : "UNKNOWN",
- m25p_ids[i].name);
- info = NULL;
- }
- }
- } else {
- id = jedec_probe(spi);
- if (!id)
- id = spi_get_device_id(spi);
-
- info = (void *)id->driver_data;
+ if (plat_id)
+ id = plat_id;
+ else
+ dev_warn(&spi->dev, "unrecognized id %s\n", data->type);
}
- if (!info)
- return -ENODEV;
+ info = (void *)id->driver_data;
+
+ if (info->jedec_id) {
+ const struct spi_device_id *jid;
+
+ jid = jedec_probe(spi);
+ if (!jid) {
+ dev_info(&spi->dev, "non-JEDEC variant of %s\n",
+ id->name);
+ } 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(&spi->dev, "found %s, expected %s\n",
+ jid->name, id->name);
+ id = jid;
+ info = (void *)jid->driver_data;
+ }
+ }
flash = kzalloc(sizeof *flash, GFP_KERNEL);
if (!flash)
--
1.6.3.3
^ permalink raw reply related [flat|nested] 131+ messages in thread* Re: [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code
2009-08-18 21:46 ` Anton Vorontsov
(?)
@ 2010-06-12 6:27 ` Barry Song
-1 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-12 6:27 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, Andrew Morton, David Woodhouse
On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
>
> Previosly the driver always tried JEDEC probing, assuming that non-JEDEC
> chips will return '0'. But truly non-JEDEC chips (like CAT25) won't do
> that, their behaviour on RDID command is undefined, so the driver should
> not call jedec_probe() for these chips.
>
> Also, be less strict on error conditions, don't fail to probe if JEDEC
> found a chip that is different from what platform code told, instead
> just print some warnings and use an information obtained via JEDEC. In
This patch caused a problem:
even though the external flash doesn't exist, it will still pass the
probe() and be registerred into kernel and given the partition table.
You may refer to this bug report:
http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975&start=0
> that case we should not trust partitions any longer, but they might be
> still useful (i.e. they could protect some parts of the chip).
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/mtd/devices/m25p80.c | 69 ++++++++++++++++++++++++-----------------
> 1 files changed, 40 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 0d74b38..b75e319 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -581,6 +581,14 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
> jedec = jedec << 8;
> jedec |= id[2];
>
> + /*
> + * Some chips (like Numonyx M25P80) have JEDEC and non-JEDEC variants,
> + * which depend on technology process. Officially RDID command doesn't
> + * exist for non-JEDEC chips, but for compatibility they return ID 0.
> + */
> + if (jedec == 0)
> + return NULL;
> +
> ext_jedec = id[3] << 8 | id[4];
>
> for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
> @@ -602,7 +610,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
> */
> static int __devinit m25p_probe(struct spi_device *spi)
> {
> - const struct spi_device_id *id;
> + const struct spi_device_id *id = spi_get_device_id(spi);
> struct flash_platform_data *data;
> struct m25p *flash;
> struct flash_info *info;
> @@ -615,41 +623,44 @@ static int __devinit m25p_probe(struct spi_device *spi)
> */
> data = spi->dev.platform_data;
> if (data && data->type) {
> + const struct spi_device_id *plat_id;
> +
> for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
> - id = &m25p_ids[i];
> - info = (void *)m25p_ids[i].driver_data;
> - if (strcmp(data->type, id->name))
> + plat_id = &m25p_ids[i];
> + if (strcmp(data->type, plat_id->name))
> continue;
> break;
> }
>
> - /* unrecognized chip? */
> - if (i == ARRAY_SIZE(m25p_ids) - 1) {
> - DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
> - dev_name(&spi->dev), data->type);
> - info = NULL;
> -
> - /* recognized; is that chip really what's there? */
> - } else if (info->jedec_id) {
> - id = jedec_probe(spi);
> -
> - if (id != &m25p_ids[i]) {
> - dev_warn(&spi->dev, "found %s, expected %s\n",
> - id ? id->name : "UNKNOWN",
> - m25p_ids[i].name);
> - info = NULL;
> - }
> - }
> - } else {
> - id = jedec_probe(spi);
> - if (!id)
> - id = spi_get_device_id(spi);
> -
> - info = (void *)id->driver_data;
> + if (plat_id)
> + id = plat_id;
> + else
> + dev_warn(&spi->dev, "unrecognized id %s\n", data->type);
> }
>
> - if (!info)
> - return -ENODEV;
> + info = (void *)id->driver_data;
> +
> + if (info->jedec_id) {
> + const struct spi_device_id *jid;
> +
> + jid = jedec_probe(spi);
> + if (!jid) {
> + dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> + id->name);
> + } 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(&spi->dev, "found %s, expected %s\n",
> + jid->name, id->name);
> + id = jid;
> + info = (void *)jid->driver_data;
> + }
> + }
>
> flash = kzalloc(sizeof *flash, GFP_KERNEL);
> if (!flash)
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code
@ 2010-06-12 6:27 ` Barry Song
0 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-12 6:27 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Andrew Morton, David Brownell, David Woodhouse, Artem Bityutskiy,
linux-mtd, linux-kernel, linuxppc-dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 6542 bytes --]
On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov<avorontsov@ru.mvista.com> wrote:>> Previosly the driver always tried JEDEC probing, assuming that non-JEDEC> chips will return '0'. But truly non-JEDEC chips (like CAT25) won't do> that, their behaviour on RDID command is undefined, so the driver should> not call jedec_probe() for these chips.>> Also, be less strict on error conditions, don't fail to probe if JEDEC> found a chip that is different from what platform code told, instead> just print some warnings and use an information obtained via JEDEC. InThis patch caused a problem:even though the external flash doesn't exist, it will still pass theprobe() and be registerred into kernel and given the partition table.You may refer to this bug report:http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975&start=0
> that case we should not trust partitions any longer, but they might be> still useful (i.e. they could protect some parts of the chip).>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>> --->  drivers/mtd/devices/m25p80.c |  69 ++++++++++++++++++++++++----------------->  1 files changed, 40 insertions(+), 29 deletions(-)>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c> index 0d74b38..b75e319 100644> --- a/drivers/mtd/devices/m25p80.c> +++ b/drivers/mtd/devices/m25p80.c> @@ -581,6 +581,14 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)>     jedec = jedec << 8;>     jedec |= id[2];>> +    /*> +     * Some chips (like Numonyx M25P80) have JEDEC and non-JEDEC variants,> +     * which depend on technology process. Officially RDID command doesn't> +     * exist for non-JEDEC chips, but for compatibility they return ID 0.> +     */> +    if (jedec == 0)> +        return NULL;> +>     ext_jedec = id[3] << 8 | id[4];>>     for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {> @@ -602,7 +610,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)>  */>  static int __devinit m25p_probe(struct spi_device *spi)>  {> -    const struct spi_device_id    *id;> +    const struct spi_device_id    *id = spi_get_device_id(spi);>     struct flash_platform_data    *data;>     struct m25p           *flash;>     struct flash_info        *info;> @@ -615,41 +623,44 @@ static int __devinit m25p_probe(struct spi_device *spi)>     */>     data = spi->dev.platform_data;>     if (data && data->type) {> +        const struct spi_device_id *plat_id;> +>         for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {> -            id = &m25p_ids[i];> -            info = (void *)m25p_ids[i].driver_data;> -            if (strcmp(data->type, id->name))> +            plat_id = &m25p_ids[i];> +            if (strcmp(data->type, plat_id->name))>                 continue;>             break;>         }>> -        /* unrecognized chip? */> -        if (i == ARRAY_SIZE(m25p_ids) - 1) {> -            DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",> -                    dev_name(&spi->dev), data->type);> -            info = NULL;> -> -        /* recognized; is that chip really what's there? */> -        } else if (info->jedec_id) {> -            id = jedec_probe(spi);> -> -            if (id != &m25p_ids[i]) {> -                dev_warn(&spi->dev, "found %s, expected %s\n",> -                        id ? id->name : "UNKNOWN",> -                        m25p_ids[i].name);> -                info = NULL;> -            }> -        }> -    } else {> -        id = jedec_probe(spi);> -        if (!id)> -            id = spi_get_device_id(spi);> -> -        info = (void *)id->driver_data;> +        if (plat_id)> +            id = plat_id;> +        else> +            dev_warn(&spi->dev, "unrecognized id %s\n", data->type);>     }>> -    if (!info)> -        return -ENODEV;> +    info = (void *)id->driver_data;> +> +    if (info->jedec_id) {> +        const struct spi_device_id *jid;> +> +        jid = jedec_probe(spi);> +        if (!jid) {> +            dev_info(&spi->dev, "non-JEDEC variant of %s\n",> +                 id->name);> +        } 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(&spi->dev, "found %s, expected %s\n",> +                 jid->name, id->name);> +            id = jid;> +            info = (void *)jid->driver_data;> +        }> +    }>>     flash = kzalloc(sizeof *flash, GFP_KERNEL);>     if (!flash)> --> 1.6.3.3>> --> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in> the body of a message to majordomo@vger.kernel.org> More majordomo info at  http://vger.kernel.org/majordomo-info.html> Please read the FAQ at  http://www.tux.org/lkml/ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code
@ 2010-06-12 6:27 ` Barry Song
0 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-12 6:27 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, Andrew Morton, David Woodhouse
T24gV2VkLCBBdWcgMTksIDIwMDkgYXQgNTo0NiBBTSwgQW50b24gVm9yb250c292Cjxhdm9yb250
c292QHJ1Lm12aXN0YS5jb20+IHdyb3RlOgo+Cj4gUHJldmlvc2x5IHRoZSBkcml2ZXIgYWx3YXlz
IHRyaWVkIEpFREVDIHByb2JpbmcsIGFzc3VtaW5nIHRoYXQgbm9uLUpFREVDCj4gY2hpcHMgd2ls
bCByZXR1cm4gJzAnLiBCdXQgdHJ1bHkgbm9uLUpFREVDIGNoaXBzIChsaWtlIENBVDI1KSB3b24n
dCBkbwo+IHRoYXQsIHRoZWlyIGJlaGF2aW91ciBvbiBSRElEIGNvbW1hbmQgaXMgdW5kZWZpbmVk
LCBzbyB0aGUgZHJpdmVyIHNob3VsZAo+IG5vdCBjYWxsIGplZGVjX3Byb2JlKCkgZm9yIHRoZXNl
IGNoaXBzLgo+Cj4gQWxzbywgYmUgbGVzcyBzdHJpY3Qgb24gZXJyb3IgY29uZGl0aW9ucywgZG9u
J3QgZmFpbCB0byBwcm9iZSBpZiBKRURFQwo+IGZvdW5kIGEgY2hpcCB0aGF0IGlzIGRpZmZlcmVu
dCBmcm9tIHdoYXQgcGxhdGZvcm0gY29kZSB0b2xkLCBpbnN0ZWFkCj4ganVzdCBwcmludCBzb21l
IHdhcm5pbmdzIGFuZCB1c2UgYW4gaW5mb3JtYXRpb24gb2J0YWluZWQgdmlhIEpFREVDLiBJbgpU
aGlzIHBhdGNoIGNhdXNlZCBhIHByb2JsZW06CmV2ZW4gdGhvdWdoIHRoZSBleHRlcm5hbCBmbGFz
aCBkb2Vzbid0IGV4aXN0LCBpdCB3aWxsIHN0aWxsIHBhc3MgdGhlCnByb2JlKCkgYW5kIGJlIHJl
Z2lzdGVycmVkIGludG8ga2VybmVsIGFuZCBnaXZlbiB0aGUgcGFydGl0aW9uIHRhYmxlLgpZb3Ug
bWF5IHJlZmVyIHRvIHRoaXMgYnVnIHJlcG9ydDoKaHR0cDovL2JsYWNrZmluLnVjbGludXgub3Jn
L2dmL3Byb2plY3QvdWNsaW51eC1kaXN0L3RyYWNrZXIvP2FjdGlvbj1UcmFja2VySXRlbUVkaXQm
dHJhY2tlcl9pdGVtX2lkPTU5NzUmc3RhcnQ9MAoKPiB0aGF0IGNhc2Ugd2Ugc2hvdWxkIG5vdCB0
cnVzdCBwYXJ0aXRpb25zIGFueSBsb25nZXIsIGJ1dCB0aGV5IG1pZ2h0IGJlCj4gc3RpbGwgdXNl
ZnVsIChpLmUuIHRoZXkgY291bGQgcHJvdGVjdCBzb21lIHBhcnRzIG9mIHRoZSBjaGlwKS4KPgo+
IFNpZ25lZC1vZmYtYnk6IEFudG9uIFZvcm9udHNvdiA8YXZvcm9udHNvdkBydS5tdmlzdGEuY29t
Pgo+IC0tLQo+IMKgZHJpdmVycy9tdGQvZGV2aWNlcy9tMjVwODAuYyB8IMKgIDY5ICsrKysrKysr
KysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tCj4gwqAxIGZpbGVzIGNoYW5nZWQsIDQw
IGluc2VydGlvbnMoKyksIDI5IGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMv
bXRkL2RldmljZXMvbTI1cDgwLmMgYi9kcml2ZXJzL210ZC9kZXZpY2VzL20yNXA4MC5jCj4gaW5k
ZXggMGQ3NGIzOC4uYjc1ZTMxOSAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL210ZC9kZXZpY2VzL20y
NXA4MC5jCj4gKysrIGIvZHJpdmVycy9tdGQvZGV2aWNlcy9tMjVwODAuYwo+IEBAIC01ODEsNiAr
NTgxLDE0IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3Qgc3BpX2RldmljZV9pZCAqX19kZXZpbml0IGpl
ZGVjX3Byb2JlKHN0cnVjdCBzcGlfZGV2aWNlICpzcGkpCj4gwqAgwqAgwqAgwqBqZWRlYyA9IGpl
ZGVjIDw8IDg7Cj4gwqAgwqAgwqAgwqBqZWRlYyB8PSBpZFsyXTsKPgo+ICsgwqAgwqAgwqAgLyoK
PiArIMKgIMKgIMKgIMKgKiBTb21lIGNoaXBzIChsaWtlIE51bW9ueXggTTI1UDgwKSBoYXZlIEpF
REVDIGFuZCBub24tSkVERUMgdmFyaWFudHMsCj4gKyDCoCDCoCDCoCDCoCogd2hpY2ggZGVwZW5k
IG9uIHRlY2hub2xvZ3kgcHJvY2Vzcy4gT2ZmaWNpYWxseSBSRElEIGNvbW1hbmQgZG9lc24ndAo+
ICsgwqAgwqAgwqAgwqAqIGV4aXN0IGZvciBub24tSkVERUMgY2hpcHMsIGJ1dCBmb3IgY29tcGF0
aWJpbGl0eSB0aGV5IHJldHVybiBJRCAwLgo+ICsgwqAgwqAgwqAgwqAqLwo+ICsgwqAgwqAgwqAg
aWYgKGplZGVjID09IDApCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXR1cm4gTlVMTDsKPiAr
Cj4gwqAgwqAgwqAgwqBleHRfamVkZWMgPSBpZFszXSA8PCA4IHwgaWRbNF07Cj4KPiDCoCDCoCDC
oCDCoGZvciAodG1wID0gMDsgdG1wIDwgQVJSQVlfU0laRShtMjVwX2lkcykgLSAxOyB0bXArKykg
ewo+IEBAIC02MDIsNyArNjEwLDcgQEAgc3RhdGljIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lk
ICpfX2RldmluaXQgamVkZWNfcHJvYmUoc3RydWN0IHNwaV9kZXZpY2UgKnNwaSkKPiDCoCovCj4g
wqBzdGF0aWMgaW50IF9fZGV2aW5pdCBtMjVwX3Byb2JlKHN0cnVjdCBzcGlfZGV2aWNlICpzcGkp
Cj4gwqB7Cj4gLSDCoCDCoCDCoCBjb25zdCBzdHJ1Y3Qgc3BpX2RldmljZV9pZCDCoCDCoCDCoCpp
ZDsKPiArIMKgIMKgIMKgIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lkIMKgIMKgIMKgKmlkID0g
c3BpX2dldF9kZXZpY2VfaWQoc3BpKTsKPiDCoCDCoCDCoCDCoHN0cnVjdCBmbGFzaF9wbGF0Zm9y
bV9kYXRhIMKgIMKgIMKgKmRhdGE7Cj4gwqAgwqAgwqAgwqBzdHJ1Y3QgbTI1cCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCAqZmxhc2g7Cj4gwqAgwqAgwqAgwqBzdHJ1Y3QgZmxhc2hfaW5m
byDCoCDCoCDCoCDCoCDCoCDCoCDCoCAqaW5mbzsKPiBAQCAtNjE1LDQxICs2MjMsNDQgQEAgc3Rh
dGljIGludCBfX2RldmluaXQgbTI1cF9wcm9iZShzdHJ1Y3Qgc3BpX2RldmljZSAqc3BpKQo+IMKg
IMKgIMKgIMKgICovCj4gwqAgwqAgwqAgwqBkYXRhID0gc3BpLT5kZXYucGxhdGZvcm1fZGF0YTsK
PiDCoCDCoCDCoCDCoGlmIChkYXRhICYmIGRhdGEtPnR5cGUpIHsKPiArIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lkICpwbGF0X2lkOwo+ICsKPiDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoGZvciAoaSA9IDA7IGkgPCBBUlJBWV9TSVpFKG0yNXBfaWRzKSAtIDE7
IGkrKykgewo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWQgPSAmbTI1cF9p
ZHNbaV07Cj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbmZvID0gKHZvaWQg
KiltMjVwX2lkc1tpXS5kcml2ZXJfZGF0YTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIGlmIChzdHJjbXAoZGF0YS0+dHlwZSwgaWQtPm5hbWUpKQo+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgcGxhdF9pZCA9ICZtMjVwX2lkc1tpXTsKPiArIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChzdHJjbXAoZGF0YS0+dHlwZSwgcGxhdF9pZC0+
bmFtZSkpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBj
b250aW51ZTsKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJyZWFrOwo+IMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgfQo+Cj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCAvKiB1bnJl
Y29nbml6ZWQgY2hpcD8gKi8KPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChpID09IEFSUkFZ
X1NJWkUobTI1cF9pZHMpIC0gMSkgewo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgREVCVUcoTVREX0RFQlVHX0xFVkVMMCwgIiVzOiB1bnJlY29nbml6ZWQgaWQgJXNcbiIsCj4g
LSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCBkZXZfbmFtZSgmc3BpLT5kZXYpLCBkYXRhLT50eXBlKTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIGluZm8gPSBOVUxMOwo+IC0KPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IC8qIHJlY29nbml6ZWQ7IGlzIHRoYXQgY2hpcCByZWFsbHkgd2hhdCdzIHRoZXJlPyAqLwo+IC0g
wqAgwqAgwqAgwqAgwqAgwqAgwqAgfSBlbHNlIGlmIChpbmZvLT5qZWRlY19pZCkgewo+IC0gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWQgPSBqZWRlY19wcm9iZShzcGkpOwo+IC0K
PiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChpZCAhPSAmbTI1cF9pZHNb
aV0pIHsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRl
dl93YXJuKCZzcGktPmRldiwgImZvdW5kICVzLCBleHBlY3RlZCAlc1xuIiwKPiAtIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGlkID8gaWQtPm5hbWUgOiAiVU5LTk9XTiIsCj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtMjVwX2lkc1tp
XS5uYW1lKTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IGluZm8gPSBOVUxMOwo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfQo+IC0g
wqAgwqAgwqAgwqAgwqAgwqAgwqAgfQo+IC0gwqAgwqAgwqAgfSBlbHNlIHsKPiAtIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIGlkID0gamVkZWNfcHJvYmUoc3BpKTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGlmICghaWQpCj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZCA9IHNw
aV9nZXRfZGV2aWNlX2lkKHNwaSk7Cj4gLQo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5mbyA9
ICh2b2lkICopaWQtPmRyaXZlcl9kYXRhOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWYgKHBs
YXRfaWQpCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZCA9IHBsYXRfaWQ7
Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlbHNlCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCBkZXZfd2Fybigmc3BpLT5kZXYsICJ1bnJlY29nbml6ZWQgaWQgJXNcbiIsIGRh
dGEtPnR5cGUpOwo+IMKgIMKgIMKgIMKgfQo+Cj4gLSDCoCDCoCDCoCBpZiAoIWluZm8pCj4gLSDC
oCDCoCDCoCDCoCDCoCDCoCDCoCByZXR1cm4gLUVOT0RFVjsKPiArIMKgIMKgIMKgIGluZm8gPSAo
dm9pZCAqKWlkLT5kcml2ZXJfZGF0YTsKPiArCj4gKyDCoCDCoCDCoCBpZiAoaW5mby0+amVkZWNf
aWQpIHsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lk
ICpqaWQ7Cj4gKwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgamlkID0gamVkZWNfcHJvYmUoc3Bp
KTsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmICghamlkKSB7Cj4gKyDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCBkZXZfaW5mbygmc3BpLT5kZXYsICJub24tSkVERUMgdmFyaWFu
dCBvZiAlc1xuIiwKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgaWQtPm5hbWUpOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfSBlbHNlIGlmIChqaWQg
IT0gaWQpIHsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC8qCj4gKyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogSkVERUMga25vd3MgYmV0dGVyLCBzbyBv
dmVyd3JpdGUgcGxhdGZvcm0gSUQuIFdlCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCogY2FuJ3QgdHJ1c3QgcGFydGl0aW9ucyBhbnkgbG9uZ2VyLCBidXQgd2UnbGwgbGV0
Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogbXRkIGFwcGx5IHRoZW0g
YW55d2F5LCBzaW5jZSBzb21lIHBhcnRpdGlvbnMgbWF5IGJlCj4gKyDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCogbWFya2VkIHJlYWQtb25seSwgYW5kIHdlIGRvbid0IHdhbnQg
dG8gbG9zZSB0aGF0Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogaW5m
b3JtYXRpb24sIGV2ZW4gaWYgaXQncyBub3QgMTAwJSBhY2N1cmF0ZS4KPiArIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKi8KPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIGRldl93YXJuKCZzcGktPmRldiwgImZvdW5kICVzLCBleHBlY3RlZCAlc1xuIiwKPiAr
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgamlkLT5uYW1l
LCBpZC0+bmFtZSk7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZCA9IGpp
ZDsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluZm8gPSAodm9pZCAqKWpp
ZC0+ZHJpdmVyX2RhdGE7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCB9Cj4gKyDCoCDCoCDCoCB9
Cj4KPiDCoCDCoCDCoCDCoGZsYXNoID0ga3phbGxvYyhzaXplb2YgKmZsYXNoLCBHRlBfS0VSTkVM
KTsKPiDCoCDCoCDCoCDCoGlmICghZmxhc2gpCj4gLS0KPiAxLjYuMy4zCj4KPiAtLQo+IFRvIHVu
c3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51
eC1rZXJuZWwiIGluCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtl
cm5lbC5vcmcKPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0IMKgaHR0cDovL3ZnZXIua2VybmVsLm9y
Zy9tYWpvcmRvbW8taW5mby5odG1sCj4gUGxlYXNlIHJlYWQgdGhlIEZBUSBhdCDCoGh0dHA6Ly93
d3cudHV4Lm9yZy9sa21sLwo=
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code
2010-06-12 6:27 ` Barry Song
@ 2010-06-18 13:32 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-18 13:32 UTC (permalink / raw)
To: Barry Song
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, uclinux-dist-devel, Andrew Morton, David Woodhouse
On Sat, Jun 12, 2010 at 02:27:12PM +0800, Barry Song wrote:
> On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov
> <avorontsov@ru.mvista.com> wrote:
> >
> > Previosly the driver always tried JEDEC probing, assuming that non-JEDEC
> > chips will return '0'. But truly non-JEDEC chips (like CAT25) won't do
> > that, their behaviour on RDID command is undefined, so the driver should
> > not call jedec_probe() for these chips.
> >
> > Also, be less strict on error conditions, don't fail to probe if JEDEC
> > found a chip that is different from what platform code told, instead
> > just print some warnings and use an information obtained via JEDEC. In
> This patch caused a problem:
> even though the external flash doesn't exist, it will still pass the
> probe() and be registerred into kernel and given the partition table.
> You may refer to this bug report:
> http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975&start=0
Thanks for the report.
There's little we can do about it. Platform code asked us
to register the device, and JEDEC probing of M25Pxx chips isn't
reliable (thanks to various vendors that make these JEDEC and
non-JEDEC variants), so the best thing we can do is to register
the chip anyway.
OTOH, if the board pulls MISO line up, then the following patch
should help.
If this won't work, we'll have to add some flag to the platform
data, i.e. to force JEDEC probing, and not trust platform data.
Not-yet-Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..a307929 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -16,6 +16,7 @@
*/
#include <linux/init.h>
+#include <linux/errno.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/interrupt.h>
@@ -723,7 +724,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
if (tmp < 0) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading JEDEC ID\n",
dev_name(&spi->dev), tmp);
- return NULL;
+ return ERR_PTR(tmp);
}
jedec = id[0];
jedec = jedec << 8;
@@ -737,7 +738,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
* exist for non-JEDEC chips, but for compatibility they return ID 0.
*/
if (jedec == 0)
- return NULL;
+ return ERR_PTR(-EEXIST);
ext_jedec = id[3] << 8 | id[4];
@@ -749,7 +750,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
return &m25p_ids[tmp];
}
}
- return NULL;
+ return ERR_PTR(-ENODEV);
}
@@ -794,9 +795,11 @@ static int __devinit m25p_probe(struct spi_device *spi)
const struct spi_device_id *jid;
jid = jedec_probe(spi);
- if (!jid) {
+ if (IS_ERR(jid) && PTR_ERR(jid) == -EEXIST) {
dev_info(&spi->dev, "non-JEDEC variant of %s\n",
id->name);
+ } else if (IS_ERR(jid)) {
+ return PTR_ERR(jid);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
^ permalink raw reply related [flat|nested] 131+ messages in thread* Re: [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code
@ 2010-06-18 13:32 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-18 13:32 UTC (permalink / raw)
To: Barry Song
Cc: Andrew Morton, David Brownell, David Woodhouse, Artem Bityutskiy,
linux-mtd, linux-kernel, linuxppc-dev, uclinux-dist-devel
On Sat, Jun 12, 2010 at 02:27:12PM +0800, Barry Song wrote:
> On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov
> <avorontsov@ru.mvista.com> wrote:
> >
> > Previosly the driver always tried JEDEC probing, assuming that non-JEDEC
> > chips will return '0'. But truly non-JEDEC chips (like CAT25) won't do
> > that, their behaviour on RDID command is undefined, so the driver should
> > not call jedec_probe() for these chips.
> >
> > Also, be less strict on error conditions, don't fail to probe if JEDEC
> > found a chip that is different from what platform code told, instead
> > just print some warnings and use an information obtained via JEDEC. In
> This patch caused a problem:
> even though the external flash doesn't exist, it will still pass the
> probe() and be registerred into kernel and given the partition table.
> You may refer to this bug report:
> http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975&start=0
Thanks for the report.
There's little we can do about it. Platform code asked us
to register the device, and JEDEC probing of M25Pxx chips isn't
reliable (thanks to various vendors that make these JEDEC and
non-JEDEC variants), so the best thing we can do is to register
the chip anyway.
OTOH, if the board pulls MISO line up, then the following patch
should help.
If this won't work, we'll have to add some flag to the platform
data, i.e. to force JEDEC probing, and not trust platform data.
Not-yet-Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..a307929 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -16,6 +16,7 @@
*/
#include <linux/init.h>
+#include <linux/errno.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/interrupt.h>
@@ -723,7 +724,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
if (tmp < 0) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading JEDEC ID\n",
dev_name(&spi->dev), tmp);
- return NULL;
+ return ERR_PTR(tmp);
}
jedec = id[0];
jedec = jedec << 8;
@@ -737,7 +738,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
* exist for non-JEDEC chips, but for compatibility they return ID 0.
*/
if (jedec == 0)
- return NULL;
+ return ERR_PTR(-EEXIST);
ext_jedec = id[3] << 8 | id[4];
@@ -749,7 +750,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
return &m25p_ids[tmp];
}
}
- return NULL;
+ return ERR_PTR(-ENODEV);
}
@@ -794,9 +795,11 @@ static int __devinit m25p_probe(struct spi_device *spi)
const struct spi_device_id *jid;
jid = jedec_probe(spi);
- if (!jid) {
+ if (IS_ERR(jid) && PTR_ERR(jid) == -EEXIST) {
dev_info(&spi->dev, "non-JEDEC variant of %s\n",
id->name);
+ } else if (IS_ERR(jid)) {
+ return PTR_ERR(jid);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
^ permalink raw reply related [flat|nested] 131+ messages in thread* RE: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-18 13:32 ` Anton Vorontsov
(?)
@ 2010-06-21 2:42 ` Song, Barry
-1 siblings, 0 replies; 131+ messages in thread
From: Song, Barry @ 2010-06-21 2:42 UTC (permalink / raw)
To: Anton Vorontsov, Barry Song
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, uclinux-dist-devel, Andrew Morton
>-----Original Message-----
>From: uclinux-dist-devel-bounces@blackfin.uclinux.org
>[mailto:uclinux-dist-devel-bounces@blackfin.uclinux.org] On
>Behalf Of Anton Vorontsov
>Sent: Friday, June 18, 2010 9:32 PM
>To: Barry Song
>Cc: David Brownell; Artem Bityutskiy;
>linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org;
>linux-mtd@lists.infradead.org;
>uclinux-dist-devel@blackfin.uclinux.org; Andrew Morton
>Subject: Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80:
>Reworkprobing/JEDEC code
>
>On Sat, Jun 12, 2010 at 02:27:12PM +0800, Barry Song wrote:
>> On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov
>> <avorontsov@ru.mvista.com> wrote:
>> >
>> > Previosly the driver always tried JEDEC probing, assuming
>that non-JEDEC
>> > chips will return '0'. But truly non-JEDEC chips (like
>CAT25) won't do
>> > that, their behaviour on RDID command is undefined, so the
>driver should
>> > not call jedec_probe() for these chips.
>> >
>> > Also, be less strict on error conditions, don't fail to
>probe if JEDEC
>> > found a chip that is different from what platform code
>told, instead
>> > just print some warnings and use an information obtained
>via JEDEC. In
>> This patch caused a problem:
>> even though the external flash doesn't exist, it will still pass the
>> probe() and be registerred into kernel and given the partition table.
>> You may refer to this bug report:
>>
>http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?ac
>tion=TrackerItemEdit&tracker_item_id=5975&start=0
>
>Thanks for the report.
>
>There's little we can do about it. Platform code asked us
>to register the device, and JEDEC probing of M25Pxx chips isn't
>reliable (thanks to various vendors that make these JEDEC and
>non-JEDEC variants), so the best thing we can do is to register
>the chip anyway.
>
>OTOH, if the board pulls MISO line up, then the following patch
>should help.
Make sense with pullup to keep the value high while external device
doesn't exist.
>
>If this won't work, we'll have to add some flag to the platform
>data, i.e. to force JEDEC probing, and not trust platform data.
How about we add a non_jedec flag in platform_data, if the flag is 1, we
let the detection pass even though the ID is 0? Otherwise, we need a
valid ID?
>
>Not-yet-Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
>---
>
>diff --git a/drivers/mtd/devices/m25p80.c
>b/drivers/mtd/devices/m25p80.c
>index 81e49a9..a307929 100644
>--- a/drivers/mtd/devices/m25p80.c
>+++ b/drivers/mtd/devices/m25p80.c
>@@ -16,6 +16,7 @@
> */
>
> #include <linux/init.h>
>+#include <linux/errno.h>
> #include <linux/module.h>
> #include <linux/device.h>
> #include <linux/interrupt.h>
>@@ -723,7 +724,7 @@ static const struct spi_device_id
>*__devinit jedec_probe(struct spi_device *spi)
> if (tmp < 0) {
> DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading
>JEDEC ID\n",
> dev_name(&spi->dev), tmp);
>- return NULL;
>+ return ERR_PTR(tmp);
> }
> jedec = id[0];
> jedec = jedec << 8;
>@@ -737,7 +738,7 @@ static const struct spi_device_id
>*__devinit jedec_probe(struct spi_device *spi)
> * exist for non-JEDEC chips, but for compatibility
>they return ID 0.
> */
> if (jedec == 0)
>- return NULL;
>+ return ERR_PTR(-EEXIST);
>
> ext_jedec = id[3] << 8 | id[4];
>
>@@ -749,7 +750,7 @@ static const struct spi_device_id
>*__devinit jedec_probe(struct spi_device *spi)
> return &m25p_ids[tmp];
> }
> }
>- return NULL;
>+ return ERR_PTR(-ENODEV);
> }
>
>
>@@ -794,9 +795,11 @@ static int __devinit m25p_probe(struct
>spi_device *spi)
> const struct spi_device_id *jid;
>
> jid = jedec_probe(spi);
>- if (!jid) {
>+ if (IS_ERR(jid) && PTR_ERR(jid) == -EEXIST) {
> dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> id->name);
>+ } else if (IS_ERR(jid)) {
>+ return PTR_ERR(jid);
> } else if (jid != id) {
> /*
> * JEDEC knows better, so overwrite
>platform ID. We
>_______________________________________________
>Uclinux-dist-devel mailing list
>Uclinux-dist-devel@blackfin.uclinux.org
>https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
>
^ permalink raw reply [flat|nested] 131+ messages in thread* RE: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 2:42 ` Song, Barry
0 siblings, 0 replies; 131+ messages in thread
From: Song, Barry @ 2010-06-21 2:42 UTC (permalink / raw)
To: Anton Vorontsov, Barry Song
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, uclinux-dist-devel, Andrew Morton
>-----Original Message-----
>From: uclinux-dist-devel-bounces@blackfin.uclinux.org
>[mailto:uclinux-dist-devel-bounces@blackfin.uclinux.org] On
>Behalf Of Anton Vorontsov
>Sent: Friday, June 18, 2010 9:32 PM
>To: Barry Song
>Cc: David Brownell; Artem Bityutskiy;
>linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org;
>linux-mtd@lists.infradead.org;
>uclinux-dist-devel@blackfin.uclinux.org; Andrew Morton
>Subject: Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80:
>Reworkprobing/JEDEC code
>
>On Sat, Jun 12, 2010 at 02:27:12PM +0800, Barry Song wrote:
>> On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov
>> <avorontsov@ru.mvista.com> wrote:
>> >
>> > Previosly the driver always tried JEDEC probing, assuming
>that non-JEDEC
>> > chips will return '0'. But truly non-JEDEC chips (like
>CAT25) won't do
>> > that, their behaviour on RDID command is undefined, so the
>driver should
>> > not call jedec_probe() for these chips.
>> >
>> > Also, be less strict on error conditions, don't fail to
>probe if JEDEC
>> > found a chip that is different from what platform code
>told, instead
>> > just print some warnings and use an information obtained
>via JEDEC. In
>> This patch caused a problem:
>> even though the external flash doesn't exist, it will still pass the
>> probe() and be registerred into kernel and given the partition table.
>> You may refer to this bug report:
>>
>http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?ac
>tion=TrackerItemEdit&tracker_item_id=5975&start=0
>
>Thanks for the report.
>
>There's little we can do about it. Platform code asked us
>to register the device, and JEDEC probing of M25Pxx chips isn't
>reliable (thanks to various vendors that make these JEDEC and
>non-JEDEC variants), so the best thing we can do is to register
>the chip anyway.
>
>OTOH, if the board pulls MISO line up, then the following patch
>should help.
Make sense with pullup to keep the value high while external device
doesn't exist.
>
>If this won't work, we'll have to add some flag to the platform
>data, i.e. to force JEDEC probing, and not trust platform data.
How about we add a non_jedec flag in platform_data, if the flag is 1, we
let the detection pass even though the ID is 0? Otherwise, we need a
valid ID?
>
>Not-yet-Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
>---
>
>diff --git a/drivers/mtd/devices/m25p80.c
>b/drivers/mtd/devices/m25p80.c
>index 81e49a9..a307929 100644
>--- a/drivers/mtd/devices/m25p80.c
>+++ b/drivers/mtd/devices/m25p80.c
>@@ -16,6 +16,7 @@
> */
>
> #include <linux/init.h>
>+#include <linux/errno.h>
> #include <linux/module.h>
> #include <linux/device.h>
> #include <linux/interrupt.h>
>@@ -723,7 +724,7 @@ static const struct spi_device_id
>*__devinit jedec_probe(struct spi_device *spi)
> if (tmp < 0) {
> DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading
>JEDEC ID\n",
> dev_name(&spi->dev), tmp);
>- return NULL;
>+ return ERR_PTR(tmp);
> }
> jedec = id[0];
> jedec = jedec << 8;
>@@ -737,7 +738,7 @@ static const struct spi_device_id
>*__devinit jedec_probe(struct spi_device *spi)
> * exist for non-JEDEC chips, but for compatibility
>they return ID 0.
> */
> if (jedec == 0)
>- return NULL;
>+ return ERR_PTR(-EEXIST);
>
> ext_jedec = id[3] << 8 | id[4];
>
>@@ -749,7 +750,7 @@ static const struct spi_device_id
>*__devinit jedec_probe(struct spi_device *spi)
> return &m25p_ids[tmp];
> }
> }
>- return NULL;
>+ return ERR_PTR(-ENODEV);
> }
>
>
>@@ -794,9 +795,11 @@ static int __devinit m25p_probe(struct
>spi_device *spi)
> const struct spi_device_id *jid;
>
> jid = jedec_probe(spi);
>- if (!jid) {
>+ if (IS_ERR(jid) && PTR_ERR(jid) == -EEXIST) {
> dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> id->name);
>+ } else if (IS_ERR(jid)) {
>+ return PTR_ERR(jid);
> } else if (jid != id) {
> /*
> * JEDEC knows better, so overwrite
>platform ID. We
>_______________________________________________
>Uclinux-dist-devel mailing list
>Uclinux-dist-devel@blackfin.uclinux.org
>https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
>
^ permalink raw reply [flat|nested] 131+ messages in thread* RE: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 2:42 ` Song, Barry
0 siblings, 0 replies; 131+ messages in thread
From: Song, Barry @ 2010-06-21 2:42 UTC (permalink / raw)
To: Anton Vorontsov, Barry Song
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, uclinux-dist-devel, Andrew Morton
=20
>-----Original Message-----
>From: uclinux-dist-devel-bounces@blackfin.uclinux.org=20
>[mailto:uclinux-dist-devel-bounces@blackfin.uclinux.org] On=20
>Behalf Of Anton Vorontsov
>Sent: Friday, June 18, 2010 9:32 PM
>To: Barry Song
>Cc: David Brownell; Artem Bityutskiy;=20
>linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org;=20
>linux-mtd@lists.infradead.org;=20
>uclinux-dist-devel@blackfin.uclinux.org; Andrew Morton
>Subject: Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80:=20
>Reworkprobing/JEDEC code
>
>On Sat, Jun 12, 2010 at 02:27:12PM +0800, Barry Song wrote:
>> On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov
>> <avorontsov@ru.mvista.com> wrote:
>> >
>> > Previosly the driver always tried JEDEC probing, assuming=20
>that non-JEDEC
>> > chips will return '0'. But truly non-JEDEC chips (like=20
>CAT25) won't do
>> > that, their behaviour on RDID command is undefined, so the=20
>driver should
>> > not call jedec_probe() for these chips.
>> >
>> > Also, be less strict on error conditions, don't fail to=20
>probe if JEDEC
>> > found a chip that is different from what platform code=20
>told, instead
>> > just print some warnings and use an information obtained=20
>via JEDEC. In
>> This patch caused a problem:
>> even though the external flash doesn't exist, it will still pass the
>> probe() and be registerred into kernel and given the partition table.
>> You may refer to this bug report:
>>=20
>http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?ac
>tion=3DTrackerItemEdit&tracker_item_id=3D5975&start=3D0
>
>Thanks for the report.
>
>There's little we can do about it. Platform code asked us
>to register the device, and JEDEC probing of M25Pxx chips isn't
>reliable (thanks to various vendors that make these JEDEC and
>non-JEDEC variants), so the best thing we can do is to register
>the chip anyway.
>
>OTOH, if the board pulls MISO line up, then the following patch
>should help.
Make sense with pullup to keep the value high while external device
doesn't exist.
>
>If this won't work, we'll have to add some flag to the platform
>data, i.e. to force JEDEC probing, and not trust platform data.
How about we add a non_jedec flag in platform_data, if the flag is 1, we
let the detection pass even though the ID is 0? Otherwise, we need a
valid ID?
>
>Not-yet-Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
>---
>
>diff --git a/drivers/mtd/devices/m25p80.c=20
>b/drivers/mtd/devices/m25p80.c
>index 81e49a9..a307929 100644
>--- a/drivers/mtd/devices/m25p80.c
>+++ b/drivers/mtd/devices/m25p80.c
>@@ -16,6 +16,7 @@
> */
>=20
> #include <linux/init.h>
>+#include <linux/errno.h>
> #include <linux/module.h>
> #include <linux/device.h>
> #include <linux/interrupt.h>
>@@ -723,7 +724,7 @@ static const struct spi_device_id=20
>*__devinit jedec_probe(struct spi_device *spi)
> if (tmp < 0) {
> DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading=20
>JEDEC ID\n",
> dev_name(&spi->dev), tmp);
>- return NULL;
>+ return ERR_PTR(tmp);
> }
> jedec =3D id[0];
> jedec =3D jedec << 8;
>@@ -737,7 +738,7 @@ static const struct spi_device_id=20
>*__devinit jedec_probe(struct spi_device *spi)
> * exist for non-JEDEC chips, but for compatibility=20
>they return ID 0.
> */
> if (jedec =3D=3D 0)
>- return NULL;
>+ return ERR_PTR(-EEXIST);
>=20
> ext_jedec =3D id[3] << 8 | id[4];
>=20
>@@ -749,7 +750,7 @@ static const struct spi_device_id=20
>*__devinit jedec_probe(struct spi_device *spi)
> return &m25p_ids[tmp];
> }
> }
>- return NULL;
>+ return ERR_PTR(-ENODEV);
> }
>=20
>=20
>@@ -794,9 +795,11 @@ static int __devinit m25p_probe(struct=20
>spi_device *spi)
> const struct spi_device_id *jid;
>=20
> jid =3D jedec_probe(spi);
>- if (!jid) {
>+ if (IS_ERR(jid) && PTR_ERR(jid) =3D=3D -EEXIST) {
> dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> id->name);
>+ } else if (IS_ERR(jid)) {
>+ return PTR_ERR(jid);
> } else if (jid !=3D id) {
> /*
> * JEDEC knows better, so overwrite=20
>platform ID. We
>_______________________________________________
>Uclinux-dist-devel mailing list
>Uclinux-dist-devel@blackfin.uclinux.org
>https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-21 2:42 ` Song, Barry
(?)
@ 2010-06-21 3:27 ` Barry Song
-1 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-21 3:27 UTC (permalink / raw)
To: Song, Barry
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, Anton Vorontsov, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 10:42 AM, Song, Barry <Barry.Song@analog.com> wrote:
>
>
>>-----Original Message-----
>>From: uclinux-dist-devel-bounces@blackfin.uclinux.org
>>[mailto:uclinux-dist-devel-bounces@blackfin.uclinux.org] On
>>Behalf Of Anton Vorontsov
>>Sent: Friday, June 18, 2010 9:32 PM
>>To: Barry Song
>>Cc: David Brownell; Artem Bityutskiy;
>>linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org;
>>linux-mtd@lists.infradead.org;
>>uclinux-dist-devel@blackfin.uclinux.org; Andrew Morton
>>Subject: Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80:
>>Reworkprobing/JEDEC code
>>
>>On Sat, Jun 12, 2010 at 02:27:12PM +0800, Barry Song wrote:
>>> On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov
>>> <avorontsov@ru.mvista.com> wrote:
>>> >
>>> > Previosly the driver always tried JEDEC probing, assuming
>>that non-JEDEC
>>> > chips will return '0'. But truly non-JEDEC chips (like
>>CAT25) won't do
>>> > that, their behaviour on RDID command is undefined, so the
>>driver should
>>> > not call jedec_probe() for these chips.
>>> >
>>> > Also, be less strict on error conditions, don't fail to
>>probe if JEDEC
>>> > found a chip that is different from what platform code
>>told, instead
>>> > just print some warnings and use an information obtained
>>via JEDEC. In
>>> This patch caused a problem:
>>> even though the external flash doesn't exist, it will still pass the
>>> probe() and be registerred into kernel and given the partition table.
>>> You may refer to this bug report:
>>>
>>http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?ac
>>tion=TrackerItemEdit&tracker_item_id=5975&start=0
>>
>>Thanks for the report.
>>
>>There's little we can do about it. Platform code asked us
>>to register the device, and JEDEC probing of M25Pxx chips isn't
>>reliable (thanks to various vendors that make these JEDEC and
>>non-JEDEC variants), so the best thing we can do is to register
>>the chip anyway.
>>
>>OTOH, if the board pulls MISO line up, then the following patch
>>should help.
> Make sense with pullup to keep the value high while external device
> doesn't exist.
>>
>>If this won't work, we'll have to add some flag to the platform
>>data, i.e. to force JEDEC probing, and not trust platform data.
>
> How about we add a non_jedec flag in platform_data, if the flag is 1, we
> let the detection pass even though the ID is 0? Otherwise, we need a
> valid ID?
Here i mean:
Index: drivers/mtd/devices/m25p80.c
===================================================================
--- drivers/mtd/devices/m25p80.c (revision 8927)
+++ drivers/mtd/devices/m25p80.c (revision 8929)
@@ -795,8 +795,13 @@
jid = jedec_probe(spi);
if (!jid) {
- dev_info(&spi->dev, "non-JEDEC variant of %s\n",
- id->name);
+ if (!data->non_jedec) {
+ dev_err(&spi->dev, "fail to detect%s\n",
+ id->name);
+ return -ENODEV;
+ } else
+ dev_info(&spi->dev, "non-JEDEC variant of %s\n",
+ id->name);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
Index: include/linux/spi/flash.h
===================================================================
--- include/linux/spi/flash.h (revision 8927)
+++ include/linux/spi/flash.h (revision 8929)
@@ -25,6 +25,11 @@
char *type;
+ /*
+ * For non-JEDEC, id will be 0. In this case, we can't be sure
+ * whether the flash exists with runtime probing.
+ */
+ int non_jedec;
/* we'll likely add more ... use JEDEC IDs, etc */
};
>
>>
>>Not-yet-Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
>>---
>>
>>diff --git a/drivers/mtd/devices/m25p80.c
>>b/drivers/mtd/devices/m25p80.c
>>index 81e49a9..a307929 100644
>>--- a/drivers/mtd/devices/m25p80.c
>>+++ b/drivers/mtd/devices/m25p80.c
>>@@ -16,6 +16,7 @@
>> */
>>
>> #include <linux/init.h>
>>+#include <linux/errno.h>
>> #include <linux/module.h>
>> #include <linux/device.h>
>> #include <linux/interrupt.h>
>>@@ -723,7 +724,7 @@ static const struct spi_device_id
>>*__devinit jedec_probe(struct spi_device *spi)
>> if (tmp < 0) {
>> DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading
>>JEDEC ID\n",
>> dev_name(&spi->dev), tmp);
>>- return NULL;
>>+ return ERR_PTR(tmp);
>> }
>> jedec = id[0];
>> jedec = jedec << 8;
>>@@ -737,7 +738,7 @@ static const struct spi_device_id
>>*__devinit jedec_probe(struct spi_device *spi)
>> * exist for non-JEDEC chips, but for compatibility
>>they return ID 0.
>> */
>> if (jedec == 0)
>>- return NULL;
>>+ return ERR_PTR(-EEXIST);
>>
>> ext_jedec = id[3] << 8 | id[4];
>>
>>@@ -749,7 +750,7 @@ static const struct spi_device_id
>>*__devinit jedec_probe(struct spi_device *spi)
>> return &m25p_ids[tmp];
>> }
>> }
>>- return NULL;
>>+ return ERR_PTR(-ENODEV);
>> }
>>
>>
>>@@ -794,9 +795,11 @@ static int __devinit m25p_probe(struct
>>spi_device *spi)
>> const struct spi_device_id *jid;
>>
>> jid = jedec_probe(spi);
>>- if (!jid) {
>>+ if (IS_ERR(jid) && PTR_ERR(jid) == -EEXIST) {
>> dev_info(&spi->dev, "non-JEDEC variant of %s\n",
>> id->name);
>>+ } else if (IS_ERR(jid)) {
>>+ return PTR_ERR(jid);
>> } else if (jid != id) {
>> /*
>> * JEDEC knows better, so overwrite
>>platform ID. We
>>_______________________________________________
>>Uclinux-dist-devel mailing list
>>Uclinux-dist-devel@blackfin.uclinux.org
>>https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
>>
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 3:27 ` Barry Song
0 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-21 3:27 UTC (permalink / raw)
To: Song, Barry
Cc: Anton Vorontsov, David Brownell, Artem Bityutskiy, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 10:42 AM, Song, Barry <Barry.Song@analog.com> wrote:
>
>
>>-----Original Message-----
>>From: uclinux-dist-devel-bounces@blackfin.uclinux.org
>>[mailto:uclinux-dist-devel-bounces@blackfin.uclinux.org] On
>>Behalf Of Anton Vorontsov
>>Sent: Friday, June 18, 2010 9:32 PM
>>To: Barry Song
>>Cc: David Brownell; Artem Bityutskiy;
>>linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org;
>>linux-mtd@lists.infradead.org;
>>uclinux-dist-devel@blackfin.uclinux.org; Andrew Morton
>>Subject: Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80:
>>Reworkprobing/JEDEC code
>>
>>On Sat, Jun 12, 2010 at 02:27:12PM +0800, Barry Song wrote:
>>> On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov
>>> <avorontsov@ru.mvista.com> wrote:
>>> >
>>> > Previosly the driver always tried JEDEC probing, assuming
>>that non-JEDEC
>>> > chips will return '0'. But truly non-JEDEC chips (like
>>CAT25) won't do
>>> > that, their behaviour on RDID command is undefined, so the
>>driver should
>>> > not call jedec_probe() for these chips.
>>> >
>>> > Also, be less strict on error conditions, don't fail to
>>probe if JEDEC
>>> > found a chip that is different from what platform code
>>told, instead
>>> > just print some warnings and use an information obtained
>>via JEDEC. In
>>> This patch caused a problem:
>>> even though the external flash doesn't exist, it will still pass the
>>> probe() and be registerred into kernel and given the partition table.
>>> You may refer to this bug report:
>>>
>>http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?ac
>>tion=TrackerItemEdit&tracker_item_id=5975&start=0
>>
>>Thanks for the report.
>>
>>There's little we can do about it. Platform code asked us
>>to register the device, and JEDEC probing of M25Pxx chips isn't
>>reliable (thanks to various vendors that make these JEDEC and
>>non-JEDEC variants), so the best thing we can do is to register
>>the chip anyway.
>>
>>OTOH, if the board pulls MISO line up, then the following patch
>>should help.
> Make sense with pullup to keep the value high while external device
> doesn't exist.
>>
>>If this won't work, we'll have to add some flag to the platform
>>data, i.e. to force JEDEC probing, and not trust platform data.
>
> How about we add a non_jedec flag in platform_data, if the flag is 1, we
> let the detection pass even though the ID is 0? Otherwise, we need a
> valid ID?
Here i mean:
Index: drivers/mtd/devices/m25p80.c
===================================================================
--- drivers/mtd/devices/m25p80.c (revision 8927)
+++ drivers/mtd/devices/m25p80.c (revision 8929)
@@ -795,8 +795,13 @@
jid = jedec_probe(spi);
if (!jid) {
- dev_info(&spi->dev, "non-JEDEC variant of %s\n",
- id->name);
+ if (!data->non_jedec) {
+ dev_err(&spi->dev, "fail to detect%s\n",
+ id->name);
+ return -ENODEV;
+ } else
+ dev_info(&spi->dev, "non-JEDEC variant of %s\n",
+ id->name);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
Index: include/linux/spi/flash.h
===================================================================
--- include/linux/spi/flash.h (revision 8927)
+++ include/linux/spi/flash.h (revision 8929)
@@ -25,6 +25,11 @@
char *type;
+ /*
+ * For non-JEDEC, id will be 0. In this case, we can't be sure
+ * whether the flash exists with runtime probing.
+ */
+ int non_jedec;
/* we'll likely add more ... use JEDEC IDs, etc */
};
>
>>
>>Not-yet-Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
>>---
>>
>>diff --git a/drivers/mtd/devices/m25p80.c
>>b/drivers/mtd/devices/m25p80.c
>>index 81e49a9..a307929 100644
>>--- a/drivers/mtd/devices/m25p80.c
>>+++ b/drivers/mtd/devices/m25p80.c
>>@@ -16,6 +16,7 @@
>> */
>>
>> #include <linux/init.h>
>>+#include <linux/errno.h>
>> #include <linux/module.h>
>> #include <linux/device.h>
>> #include <linux/interrupt.h>
>>@@ -723,7 +724,7 @@ static const struct spi_device_id
>>*__devinit jedec_probe(struct spi_device *spi)
>> if (tmp < 0) {
>> DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading
>>JEDEC ID\n",
>> dev_name(&spi->dev), tmp);
>>- return NULL;
>>+ return ERR_PTR(tmp);
>> }
>> jedec = id[0];
>> jedec = jedec << 8;
>>@@ -737,7 +738,7 @@ static const struct spi_device_id
>>*__devinit jedec_probe(struct spi_device *spi)
>> * exist for non-JEDEC chips, but for compatibility
>>they return ID 0.
>> */
>> if (jedec == 0)
>>- return NULL;
>>+ return ERR_PTR(-EEXIST);
>>
>> ext_jedec = id[3] << 8 | id[4];
>>
>>@@ -749,7 +750,7 @@ static const struct spi_device_id
>>*__devinit jedec_probe(struct spi_device *spi)
>> return &m25p_ids[tmp];
>> }
>> }
>>- return NULL;
>>+ return ERR_PTR(-ENODEV);
>> }
>>
>>
>>@@ -794,9 +795,11 @@ static int __devinit m25p_probe(struct
>>spi_device *spi)
>> const struct spi_device_id *jid;
>>
>> jid = jedec_probe(spi);
>>- if (!jid) {
>>+ if (IS_ERR(jid) && PTR_ERR(jid) == -EEXIST) {
>> dev_info(&spi->dev, "non-JEDEC variant of %s\n",
>> id->name);
>>+ } else if (IS_ERR(jid)) {
>>+ return PTR_ERR(jid);
>> } else if (jid != id) {
>> /*
>> * JEDEC knows better, so overwrite
>>platform ID. We
>>_______________________________________________
>>Uclinux-dist-devel mailing list
>>Uclinux-dist-devel@blackfin.uclinux.org
>>https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
>>
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 3:27 ` Barry Song
0 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-21 3:27 UTC (permalink / raw)
To: Song, Barry
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 10:42 AM, Song, Barry <Barry.Song@analog.com> wrote=
:
>
>
>>-----Original Message-----
>>From: uclinux-dist-devel-bounces@blackfin.uclinux.org
>>[mailto:uclinux-dist-devel-bounces@blackfin.uclinux.org] On
>>Behalf Of Anton Vorontsov
>>Sent: Friday, June 18, 2010 9:32 PM
>>To: Barry Song
>>Cc: David Brownell; Artem Bityutskiy;
>>linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org;
>>linux-mtd@lists.infradead.org;
>>uclinux-dist-devel@blackfin.uclinux.org; Andrew Morton
>>Subject: Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80:
>>Reworkprobing/JEDEC code
>>
>>On Sat, Jun 12, 2010 at 02:27:12PM +0800, Barry Song wrote:
>>> On Wed, Aug 19, 2009 at 5:46 AM, Anton Vorontsov
>>> <avorontsov@ru.mvista.com> wrote:
>>> >
>>> > Previosly the driver always tried JEDEC probing, assuming
>>that non-JEDEC
>>> > chips will return '0'. But truly non-JEDEC chips (like
>>CAT25) won't do
>>> > that, their behaviour on RDID command is undefined, so the
>>driver should
>>> > not call jedec_probe() for these chips.
>>> >
>>> > Also, be less strict on error conditions, don't fail to
>>probe if JEDEC
>>> > found a chip that is different from what platform code
>>told, instead
>>> > just print some warnings and use an information obtained
>>via JEDEC. In
>>> This patch caused a problem:
>>> even though the external flash doesn't exist, it will still pass the
>>> probe() and be registerred into kernel and given the partition table.
>>> You may refer to this bug report:
>>>
>>http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?ac
>>tion=3DTrackerItemEdit&tracker_item_id=3D5975&start=3D0
>>
>>Thanks for the report.
>>
>>There's little we can do about it. Platform code asked us
>>to register the device, and JEDEC probing of M25Pxx chips isn't
>>reliable (thanks to various vendors that make these JEDEC and
>>non-JEDEC variants), so the best thing we can do is to register
>>the chip anyway.
>>
>>OTOH, if the board pulls MISO line up, then the following patch
>>should help.
> Make sense with pullup to keep the value high while external device
> doesn't exist.
>>
>>If this won't work, we'll have to add some flag to the platform
>>data, i.e. to force JEDEC probing, and not trust platform data.
>
> How about we add a non_jedec flag in platform_data, if the flag is 1, we
> let the detection pass even though the ID is 0? Otherwise, we need a
> valid ID?
Here i mean:
Index: drivers/mtd/devices/m25p80.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- drivers/mtd/devices/m25p80.c (revision 8927)
+++ drivers/mtd/devices/m25p80.c (revision 8929)
@@ -795,8 +795,13 @@
jid =3D jedec_probe(spi);
if (!jid) {
- dev_info(&spi->dev, "non-JEDEC variant of %s\n",
- id->name);
+ if (!data->non_jedec) {
+ dev_err(&spi->dev, "fail to detect%s\n",
+ id->name);
+ return -ENODEV;
+ } else
+ dev_info(&spi->dev, "non-JEDEC variant of %s\n",
+ id->name);
} else if (jid !=3D id) {
/*
* JEDEC knows better, so overwrite platform ID. We
Index: include/linux/spi/flash.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- include/linux/spi/flash.h (revision 8927)
+++ include/linux/spi/flash.h (revision 8929)
@@ -25,6 +25,11 @@
char *type;
+ /*
+ * For non-JEDEC, id will be 0. In this case, we can't be sure
+ * whether the flash exists with runtime probing.
+ */
+ int non_jedec;
/* we'll likely add more ... use JEDEC IDs, etc */
};
>
>>
>>Not-yet-Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
>>---
>>
>>diff --git a/drivers/mtd/devices/m25p80.c
>>b/drivers/mtd/devices/m25p80.c
>>index 81e49a9..a307929 100644
>>--- a/drivers/mtd/devices/m25p80.c
>>+++ b/drivers/mtd/devices/m25p80.c
>>@@ -16,6 +16,7 @@
>> =C2=A0*/
>>
>> #include <linux/init.h>
>>+#include <linux/errno.h>
>> #include <linux/module.h>
>> #include <linux/device.h>
>> #include <linux/interrupt.h>
>>@@ -723,7 +724,7 @@ static const struct spi_device_id
>>*__devinit jedec_probe(struct spi_device *spi)
>> =C2=A0 =C2=A0 =C2=A0 if (tmp < 0) {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DEBUG(MTD_DEBUG_LEVEL0,=
"%s: error %d reading
>>JEDEC ID\n",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 dev_name(&spi->dev), tmp);
>>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return NULL;
>>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return ERR_PTR(tmp);
>> =C2=A0 =C2=A0 =C2=A0 }
>> =C2=A0 =C2=A0 =C2=A0 jedec =3D id[0];
>> =C2=A0 =C2=A0 =C2=A0 jedec =3D jedec << 8;
>>@@ -737,7 +738,7 @@ static const struct spi_device_id
>>*__devinit jedec_probe(struct spi_device *spi)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0* exist for non-JEDEC chips, but for compatib=
ility
>>they return ID 0.
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
>> =C2=A0 =C2=A0 =C2=A0 if (jedec =3D=3D 0)
>>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return NULL;
>>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return ERR_PTR(-EEXIST)=
;
>>
>> =C2=A0 =C2=A0 =C2=A0 ext_jedec =3D id[3] << 8 | id[4];
>>
>>@@ -749,7 +750,7 @@ static const struct spi_device_id
>>*__devinit jedec_probe(struct spi_device *spi)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return &m25p_ids[tmp];
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>> =C2=A0 =C2=A0 =C2=A0 }
>>- =C2=A0 =C2=A0 =C2=A0return NULL;
>>+ =C2=A0 =C2=A0 =C2=A0return ERR_PTR(-ENODEV);
>> }
>>
>>
>>@@ -794,9 +795,11 @@ static int __devinit m25p_probe(struct
>>spi_device *spi)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 const struct spi_device=
_id *jid;
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 jid =3D jedec_probe(spi=
);
>>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!jid) {
>>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (IS_ERR(jid) && PTR_=
ERR(jid) =3D=3D -EEXIST) {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 dev_info(&spi->dev, "non-JEDEC variant of %s\n",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0id->name);
>>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else if (IS_ERR(jid))=
{
>>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0return PTR_ERR(jid);
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } else if (jid !=3D id)=
{
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 /*
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0* JEDEC knows better, so overwrite
>>platform ID. We
>>_______________________________________________
>>Uclinux-dist-devel mailing list
>>Uclinux-dist-devel@blackfin.uclinux.org
>>https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
>>
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-21 3:27 ` Barry Song
@ 2010-06-21 7:15 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-21 7:15 UTC (permalink / raw)
To: Barry Song
Cc: David Brownell, Artem Bityutskiy, linux-kernel, Song, Barry,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
[...]
> > How about we add a non_jedec flag in platform_data, if the flag is 1, we
> > let the detection pass even though the ID is 0? Otherwise, we need a
> > valid ID?
> Here i mean:
This will break at least OF-enabled platforms (e.g. PowerPC),
they assume that the driver will success for non-JEDEC flashes.
OF platforms don't pass platform data, and even if they did,
device tree doesn't specify if the flash is JEDEC or non-JEDEC.
Which is why I think that, by default, the driver should
successfully register the flash even if JEDEC probe fails. So,
instead of checking for "!non_jedec", I would recommend
"force_jedec" check.
> Index: drivers/mtd/devices/m25p80.c
> ===================================================================
> --- drivers/mtd/devices/m25p80.c (revision 8927)
> +++ drivers/mtd/devices/m25p80.c (revision 8929)
> @@ -795,8 +795,13 @@
>
> jid = jedec_probe(spi);
> if (!jid) {
> - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> - id->name);
> + if (!data->non_jedec) {
> + dev_err(&spi->dev, "fail to detect%s\n",
> + id->name);
> + return -ENODEV;
> + } else
> + dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> + id->name);
> } else if (jid != id) {
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 7:15 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-21 7:15 UTC (permalink / raw)
To: Barry Song
Cc: Song, Barry, David Brownell, Artem Bityutskiy, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
[...]
> > How about we add a non_jedec flag in platform_data, if the flag is 1, we
> > let the detection pass even though the ID is 0? Otherwise, we need a
> > valid ID?
> Here i mean:
This will break at least OF-enabled platforms (e.g. PowerPC),
they assume that the driver will success for non-JEDEC flashes.
OF platforms don't pass platform data, and even if they did,
device tree doesn't specify if the flash is JEDEC or non-JEDEC.
Which is why I think that, by default, the driver should
successfully register the flash even if JEDEC probe fails. So,
instead of checking for "!non_jedec", I would recommend
"force_jedec" check.
> Index: drivers/mtd/devices/m25p80.c
> ===================================================================
> --- drivers/mtd/devices/m25p80.c (revision 8927)
> +++ drivers/mtd/devices/m25p80.c (revision 8929)
> @@ -795,8 +795,13 @@
>
> jid = jedec_probe(spi);
> if (!jid) {
> - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> - id->name);
> + if (!data->non_jedec) {
> + dev_err(&spi->dev, "fail to detect%s\n",
> + id->name);
> + return -ENODEV;
> + } else
> + dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> + id->name);
> } else if (jid != id) {
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-21 7:15 ` Anton Vorontsov
(?)
@ 2010-06-21 7:22 ` Barry Song
-1 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-21 7:22 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, linux-kernel, Song, Barry,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
> [...]
>> > How about we add a non_jedec flag in platform_data, if the flag is 1, we
>> > let the detection pass even though the ID is 0? Otherwise, we need a
>> > valid ID?
>> Here i mean:
>
> This will break at least OF-enabled platforms (e.g. PowerPC),
> they assume that the driver will success for non-JEDEC flashes.
> OF platforms don't pass platform data, and even if they did,
> device tree doesn't specify if the flash is JEDEC or non-JEDEC.
>
> Which is why I think that, by default, the driver should
> successfully register the flash even if JEDEC probe fails. So,
> instead of checking for "!non_jedec", I would recommend
> "force_jedec" check.
Mike Frysinger suggested to use non_jedec since most devices are
standard jedec devices. Only if non_jedec=1, we let the detection pass
if ID is 0.
>
>> Index: drivers/mtd/devices/m25p80.c
>> ===================================================================
>> --- drivers/mtd/devices/m25p80.c (revision 8927)
>> +++ drivers/mtd/devices/m25p80.c (revision 8929)
>> @@ -795,8 +795,13 @@
>>
>> jid = jedec_probe(spi);
>> if (!jid) {
>> - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
>> - id->name);
>> + if (!data->non_jedec) {
>> + dev_err(&spi->dev, "fail to detect%s\n",
>> + id->name);
>> + return -ENODEV;
>> + } else
>> + dev_info(&spi->dev, "non-JEDEC variant of %s\n",
>> + id->name);
>> } else if (jid != id) {
>
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 7:22 ` Barry Song
0 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-21 7:22 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Song, Barry, David Brownell, Artem Bityutskiy, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 2202 bytes --]
On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:> On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:> [...]>> > How about we add a non_jedec flag in platform_data, if the flag is 1, we>> > let the detection pass even though the ID is 0? Otherwise, we need a>> > valid ID?>> Here i mean:>> This will break at least OF-enabled platforms (e.g. PowerPC),> they assume that the driver will success for non-JEDEC flashes.> OF platforms don't pass platform data, and even if they did,> device tree doesn't specify if the flash is JEDEC or non-JEDEC.>> Which is why I think that, by default, the driver should> successfully register the flash even if JEDEC probe fails. So,> instead of checking for "!non_jedec", I would recommend> "force_jedec" check.
Mike Frysinger suggested to use non_jedec since most devices arestandard jedec devices. Only if non_jedec=1, we let the detection passif ID is 0.
>>> Index: drivers/mtd/devices/m25p80.c>> ===================================================================>> --- drivers/mtd/devices/m25p80.c    (revision 8927)>> +++ drivers/mtd/devices/m25p80.c    (revision 8929)>> @@ -795,8 +795,13 @@>>>>        jid = jedec_probe(spi);>>        if (!jid) {>> -           dev_info(&spi->dev, "non-JEDEC variant of %s\n",>> -                id->name);>> +           if (!data->non_jedec) {>> +               dev_err(&spi->dev, "fail to detect%s\n",>> +                       id->name);>> +               return -ENODEV;>> +           } else>> +               dev_info(&spi->dev, "non-JEDEC variant of %s\n",>> +                       id->name);>>        } else if (jid != id) {>> --> Anton Vorontsov> email: cbouatmailru@gmail.com> irc://irc.freenode.net/bd2>ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 7:22 ` Barry Song
0 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-21 7:22 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, linux-kernel, Song, Barry,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
T24gTW9uLCBKdW4gMjEsIDIwMTAgYXQgMzoxNSBQTSwgQW50b24gVm9yb250c292IDxjYm91YXRt
YWlscnVAZ21haWwuY29tPiB3cm90ZToKPiBPbiBNb24sIEp1biAyMSwgMjAxMCBhdCAxMToyNzoz
MUFNICswODAwLCBCYXJyeSBTb25nIHdyb3RlOgo+IFsuLi5dCj4+ID4gSG93IGFib3V0IHdlIGFk
ZCBhIG5vbl9qZWRlYyBmbGFnIGluIHBsYXRmb3JtX2RhdGEsIGlmIHRoZSBmbGFnIGlzIDEsIHdl
Cj4+ID4gbGV0IHRoZSBkZXRlY3Rpb24gcGFzcyBldmVuIHRob3VnaCB0aGUgSUQgaXMgMD8gT3Ro
ZXJ3aXNlLCB3ZSBuZWVkIGEKPj4gPiB2YWxpZCBJRD8KPj4gSGVyZSBpIG1lYW46Cj4KPiBUaGlz
IHdpbGwgYnJlYWsgYXQgbGVhc3QgT0YtZW5hYmxlZCBwbGF0Zm9ybXMgKGUuZy4gUG93ZXJQQyks
Cj4gdGhleSBhc3N1bWUgdGhhdCB0aGUgZHJpdmVyIHdpbGwgc3VjY2VzcyBmb3Igbm9uLUpFREVD
IGZsYXNoZXMuCj4gT0YgcGxhdGZvcm1zIGRvbid0IHBhc3MgcGxhdGZvcm0gZGF0YSwgYW5kIGV2
ZW4gaWYgdGhleSBkaWQsCj4gZGV2aWNlIHRyZWUgZG9lc24ndCBzcGVjaWZ5IGlmIHRoZSBmbGFz
aCBpcyBKRURFQyBvciBub24tSkVERUMuCj4KPiBXaGljaCBpcyB3aHkgSSB0aGluayB0aGF0LCBi
eSBkZWZhdWx0LCB0aGUgZHJpdmVyIHNob3VsZAo+IHN1Y2Nlc3NmdWxseSByZWdpc3RlciB0aGUg
Zmxhc2ggZXZlbiBpZiBKRURFQyBwcm9iZSBmYWlscy4gU28sCj4gaW5zdGVhZCBvZiBjaGVja2lu
ZyBmb3IgIiFub25famVkZWMiLCBJIHdvdWxkIHJlY29tbWVuZAo+ICJmb3JjZV9qZWRlYyIgY2hl
Y2suCgpNaWtlIEZyeXNpbmdlciBzdWdnZXN0ZWQgdG8gdXNlIG5vbl9qZWRlYyBzaW5jZSBtb3N0
IGRldmljZXMgYXJlCnN0YW5kYXJkIGplZGVjIGRldmljZXMuIE9ubHkgaWYgbm9uX2plZGVjPTEs
IHdlIGxldCB0aGUgZGV0ZWN0aW9uIHBhc3MKaWYgSUQgaXMgMC4KCj4KPj4gSW5kZXg6IGRyaXZl
cnMvbXRkL2RldmljZXMvbTI1cDgwLmMKPj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQo+PiAtLS0gZHJpdmVycy9tdGQv
ZGV2aWNlcy9tMjVwODAuYyDCoCDCoCDCoChyZXZpc2lvbiA4OTI3KQo+PiArKysgZHJpdmVycy9t
dGQvZGV2aWNlcy9tMjVwODAuYyDCoCDCoCDCoChyZXZpc2lvbiA4OTI5KQo+PiBAQCAtNzk1LDgg
Kzc5NSwxMyBAQAo+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBqaWQgPSBqZWRlY19wcm9iZShz
cGkpOwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZiAoIWppZCkgewo+PiAtIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIGRldl9pbmZvKCZzcGktPmRldiwgIm5vbi1KRURFQyB2YXJpYW50
IG9mICVzXG4iLAo+PiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgaWQtPm5hbWUpOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmICghZGF0
YS0+bm9uX2plZGVjKSB7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgZGV2X2Vycigmc3BpLT5kZXYsICJmYWlsIHRvIGRldGVjdCVzXG4iLAo+PiArIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGlkLT5uYW1lKTsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCByZXR1cm4gLUVOT0RFVjsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB9
IGVsc2UKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkZXZf
aW5mbygmc3BpLT5kZXYsICJub24tSkVERUMgdmFyaWFudCBvZiAlc1xuIiwKPj4gKyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCBpZC0+bmFtZSk7Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIH0gZWxzZSBpZiAoamlkICE9IGlk
KSB7Cj4KPiAtLQo+IEFudG9uIFZvcm9udHNvdgo+IGVtYWlsOiBjYm91YXRtYWlscnVAZ21haWwu
Y29tCj4gaXJjOi8vaXJjLmZyZWVub2RlLm5ldC9iZDIKPgo=
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-21 7:22 ` Barry Song
@ 2010-06-21 7:39 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-21 7:39 UTC (permalink / raw)
To: Barry Song
Cc: David Brownell, Artem Bityutskiy, linux-kernel, Song, Barry,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
> On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> > On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
> > [...]
> >> > How about we add a non_jedec flag in platform_data, if the flag is 1, we
> >> > let the detection pass even though the ID is 0? Otherwise, we need a
> >> > valid ID?
> >> Here i mean:
> >
> > This will break at least OF-enabled platforms (e.g. PowerPC),
> > they assume that the driver will success for non-JEDEC flashes.
> > OF platforms don't pass platform data, and even if they did,
> > device tree doesn't specify if the flash is JEDEC or non-JEDEC.
> >
> > Which is why I think that, by default, the driver should
> > successfully register the flash even if JEDEC probe fails. So,
> > instead of checking for "!non_jedec", I would recommend
> > "force_jedec" check.
>
> Mike Frysinger suggested to use non_jedec since most devices are
> standard jedec devices.
Well, on OF platforms most devices that I'm aware of are non-JEDEC.
> Only if non_jedec=1, we let the detection pass
> if ID is 0.
Then please #ifdef it with CONFIG_OF.
Thanks,
> >> Index: drivers/mtd/devices/m25p80.c
> >> ===================================================================
> >> --- drivers/mtd/devices/m25p80.c (revision 8927)
> >> +++ drivers/mtd/devices/m25p80.c (revision 8929)
> >> @@ -795,8 +795,13 @@
> >>
> >> jid = jedec_probe(spi);
> >> if (!jid) {
> >> - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> >> - id->name);
> >> + if (!data->non_jedec) {
> >> + dev_err(&spi->dev, "fail to detect%s\n",
> >> + id->name);
> >> + return -ENODEV;
> >> + } else
> >> + dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> >> + id->name);
> >> } else if (jid != id) {
> >
> > --
> > Anton Vorontsov
> > email: cbouatmailru@gmail.com
> > irc://irc.freenode.net/bd2
> >
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 7:39 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-21 7:39 UTC (permalink / raw)
To: Barry Song
Cc: Song, Barry, David Brownell, Artem Bityutskiy, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
> On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> > On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
> > [...]
> >> > How about we add a non_jedec flag in platform_data, if the flag is 1, we
> >> > let the detection pass even though the ID is 0? Otherwise, we need a
> >> > valid ID?
> >> Here i mean:
> >
> > This will break at least OF-enabled platforms (e.g. PowerPC),
> > they assume that the driver will success for non-JEDEC flashes.
> > OF platforms don't pass platform data, and even if they did,
> > device tree doesn't specify if the flash is JEDEC or non-JEDEC.
> >
> > Which is why I think that, by default, the driver should
> > successfully register the flash even if JEDEC probe fails. So,
> > instead of checking for "!non_jedec", I would recommend
> > "force_jedec" check.
>
> Mike Frysinger suggested to use non_jedec since most devices are
> standard jedec devices.
Well, on OF platforms most devices that I'm aware of are non-JEDEC.
> Only if non_jedec=1, we let the detection pass
> if ID is 0.
Then please #ifdef it with CONFIG_OF.
Thanks,
> >> Index: drivers/mtd/devices/m25p80.c
> >> ===================================================================
> >> --- drivers/mtd/devices/m25p80.c (revision 8927)
> >> +++ drivers/mtd/devices/m25p80.c (revision 8929)
> >> @@ -795,8 +795,13 @@
> >>
> >> jid = jedec_probe(spi);
> >> if (!jid) {
> >> - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> >> - id->name);
> >> + if (!data->non_jedec) {
> >> + dev_err(&spi->dev, "fail to detect%s\n",
> >> + id->name);
> >> + return -ENODEV;
> >> + } else
> >> + dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> >> + id->name);
> >> } else if (jid != id) {
> >
> > --
> > Anton Vorontsov
> > email: cbouatmailru@gmail.com
> > irc://irc.freenode.net/bd2
> >
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-21 7:39 ` Anton Vorontsov
(?)
@ 2010-06-21 10:31 ` Barry Song
-1 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-21 10:31 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, linux-kernel, Song, Barry,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 3:39 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
>> On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
>> > On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
>> > [...]
>> >> > How about we add a non_jedec flag in platform_data, if the flag is 1, we
>> >> > let the detection pass even though the ID is 0? Otherwise, we need a
>> >> > valid ID?
>> >> Here i mean:
>> >
>> > This will break at least OF-enabled platforms (e.g. PowerPC),
>> > they assume that the driver will success for non-JEDEC flashes.
>> > OF platforms don't pass platform data, and even if they did,
>> > device tree doesn't specify if the flash is JEDEC or non-JEDEC.
>> >
>> > Which is why I think that, by default, the driver should
>> > successfully register the flash even if JEDEC probe fails. So,
>> > instead of checking for "!non_jedec", I would recommend
>> > "force_jedec" check.
>>
>> Mike Frysinger suggested to use non_jedec since most devices are
>> standard jedec devices.
>
> Well, on OF platforms most devices that I'm aware of are non-JEDEC.
>
>> Only if non_jedec=1, we let the detection pass
>> if ID is 0.
>
> Then please #ifdef it with CONFIG_OF.
I think the patch has nothing to do with platform. Here SPI Flash is a
peripherals, doesn't depend on any platform. Adding a CONFIG_OF
doesn't make sense very much.
If you think most devices are non-JEDEC, we can change non_JEDEC to
force_JEDEC as you said. But anyway, is that real that most devices
are non_JEDEC? If not, I think we should change OF platform codes to
fit with this patch.
>
> Thanks,
>
>> >> Index: drivers/mtd/devices/m25p80.c
>> >> ===================================================================
>> >> --- drivers/mtd/devices/m25p80.c (revision 8927)
>> >> +++ drivers/mtd/devices/m25p80.c (revision 8929)
>> >> @@ -795,8 +795,13 @@
>> >>
>> >> jid = jedec_probe(spi);
>> >> if (!jid) {
>> >> - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
>> >> - id->name);
>> >> + if (!data->non_jedec) {
>> >> + dev_err(&spi->dev, "fail to detect%s\n",
>> >> + id->name);
>> >> + return -ENODEV;
>> >> + } else
>> >> + dev_info(&spi->dev, "non-JEDEC variant of %s\n",
>> >> + id->name);
>> >> } else if (jid != id) {
>> >
>> > --
>> > Anton Vorontsov
>> > email: cbouatmailru@gmail.com
>> > irc://irc.freenode.net/bd2
>> >
>
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 10:31 ` Barry Song
0 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-21 10:31 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Song, Barry, David Brownell, Artem Bityutskiy, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 3:39 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
>> On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
>> > On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
>> > [...]
>> >> > How about we add a non_jedec flag in platform_data, if the flag is 1, we
>> >> > let the detection pass even though the ID is 0? Otherwise, we need a
>> >> > valid ID?
>> >> Here i mean:
>> >
>> > This will break at least OF-enabled platforms (e.g. PowerPC),
>> > they assume that the driver will success for non-JEDEC flashes.
>> > OF platforms don't pass platform data, and even if they did,
>> > device tree doesn't specify if the flash is JEDEC or non-JEDEC.
>> >
>> > Which is why I think that, by default, the driver should
>> > successfully register the flash even if JEDEC probe fails. So,
>> > instead of checking for "!non_jedec", I would recommend
>> > "force_jedec" check.
>>
>> Mike Frysinger suggested to use non_jedec since most devices are
>> standard jedec devices.
>
> Well, on OF platforms most devices that I'm aware of are non-JEDEC.
>
>> Only if non_jedec=1, we let the detection pass
>> if ID is 0.
>
> Then please #ifdef it with CONFIG_OF.
I think the patch has nothing to do with platform. Here SPI Flash is a
peripherals, doesn't depend on any platform. Adding a CONFIG_OF
doesn't make sense very much.
If you think most devices are non-JEDEC, we can change non_JEDEC to
force_JEDEC as you said. But anyway, is that real that most devices
are non_JEDEC? If not, I think we should change OF platform codes to
fit with this patch.
>
> Thanks,
>
>> >> Index: drivers/mtd/devices/m25p80.c
>> >> ===================================================================
>> >> --- drivers/mtd/devices/m25p80.c (revision 8927)
>> >> +++ drivers/mtd/devices/m25p80.c (revision 8929)
>> >> @@ -795,8 +795,13 @@
>> >>
>> >> jid = jedec_probe(spi);
>> >> if (!jid) {
>> >> - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
>> >> - id->name);
>> >> + if (!data->non_jedec) {
>> >> + dev_err(&spi->dev, "fail to detect%s\n",
>> >> + id->name);
>> >> + return -ENODEV;
>> >> + } else
>> >> + dev_info(&spi->dev, "non-JEDEC variant of %s\n",
>> >> + id->name);
>> >> } else if (jid != id) {
>> >
>> > --
>> > Anton Vorontsov
>> > email: cbouatmailru@gmail.com
>> > irc://irc.freenode.net/bd2
>> >
>
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 10:31 ` Barry Song
0 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-21 10:31 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, linux-kernel, Song, Barry,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 3:39 PM, Anton Vorontsov <cbouatmailru@gmail.com> w=
rote:
> On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
>> On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.com=
> wrote:
>> > On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
>> > [...]
>> >> > How about we add a non_jedec flag in platform_data, if the flag is =
1, we
>> >> > let the detection pass even though the ID is 0? Otherwise, we need =
a
>> >> > valid ID?
>> >> Here i mean:
>> >
>> > This will break at least OF-enabled platforms (e.g. PowerPC),
>> > they assume that the driver will success for non-JEDEC flashes.
>> > OF platforms don't pass platform data, and even if they did,
>> > device tree doesn't specify if the flash is JEDEC or non-JEDEC.
>> >
>> > Which is why I think that, by default, the driver should
>> > successfully register the flash even if JEDEC probe fails. So,
>> > instead of checking for "!non_jedec", I would recommend
>> > "force_jedec" check.
>>
>> Mike Frysinger suggested to use non_jedec since most devices are
>> standard jedec devices.
>
> Well, on OF platforms most devices that I'm aware of are non-JEDEC.
>
>> Only if non_jedec=3D1, we let the detection pass
>> if ID is 0.
>
> Then please #ifdef it with CONFIG_OF.
I think the patch has nothing to do with platform. Here SPI Flash is a
peripherals, doesn't depend on any platform. Adding a CONFIG_OF
doesn't make sense very much.
If you think most devices are non-JEDEC, we can change non_JEDEC to
force_JEDEC as you said. But anyway, is that real that most devices
are non_JEDEC? If not, I think we should change OF platform codes to
fit with this patch.
>
> Thanks,
>
>> >> Index: drivers/mtd/devices/m25p80.c
>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> --- drivers/mtd/devices/m25p80.c =C2=A0 =C2=A0 =C2=A0(revision 8927)
>> >> +++ drivers/mtd/devices/m25p80.c =C2=A0 =C2=A0 =C2=A0(revision 8929)
>> >> @@ -795,8 +795,13 @@
>> >>
>> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 jid =3D jedec_probe(=
spi);
>> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!jid) {
>> >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 dev_info(&spi->dev, "non-JEDEC variant of %s\n",
>> >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0id->name);
>> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 if (!data->non_jedec) {
>> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dev_err(&spi->dev, "fail to detect%s\n",
>> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 id->name);
>> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -ENODEV;
>> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 } else
>> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dev_info(&spi->dev, "non-JEDEC variant of %=
s\n",
>> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 id->name);
>> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } else if (jid !=3D =
id) {
>> >
>> > --
>> > Anton Vorontsov
>> > email: cbouatmailru@gmail.com
>> > irc://irc.freenode.net/bd2
>> >
>
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-21 10:31 ` Barry Song
@ 2010-06-21 11:20 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-21 11:20 UTC (permalink / raw)
To: Barry Song
Cc: David Brownell, Artem Bityutskiy, linux-kernel, Song, Barry,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 06:31:44PM +0800, Barry Song wrote:
> On Mon, Jun 21, 2010 at 3:39 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> > On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
> >> On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> >> > On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
> >> > [...]
> >> >> > How about we add a non_jedec flag in platform_data, if the flag is 1, we
> >> >> > let the detection pass even though the ID is 0? Otherwise, we need a
> >> >> > valid ID?
> >> >> Here i mean:
> >> >
> >> > This will break at least OF-enabled platforms (e.g. PowerPC),
> >> > they assume that the driver will success for non-JEDEC flashes.
> >> > OF platforms don't pass platform data, and even if they did,
> >> > device tree doesn't specify if the flash is JEDEC or non-JEDEC.
> >> >
> >> > Which is why I think that, by default, the driver should
> >> > successfully register the flash even if JEDEC probe fails. So,
> >> > instead of checking for "!non_jedec", I would recommend
> >> > "force_jedec" check.
> >>
> >> Mike Frysinger suggested to use non_jedec since most devices are
> >> standard jedec devices.
> >
> > Well, on OF platforms most devices that I'm aware of are non-JEDEC.
> >
> >> Only if non_jedec=1, we let the detection pass
> >> if ID is 0.
> >
> > Then please #ifdef it with CONFIG_OF.
> I think the patch has nothing to do with platform. Here SPI Flash is a
> peripherals, doesn't depend on any platform. Adding a CONFIG_OF
> doesn't make sense very much.
With OF we don't place non-existent devices into the device
tree (or we mark them with status = "not-ok/disabled/absent"
property).
> If you think most devices are non-JEDEC, we can change non_JEDEC to
> force_JEDEC as you said.
> But anyway, is that real that most devices are non_JEDEC?
Why would this matter? We have to support both.
> If not, I think we should change OF platform codes to
> fit with this patch.
You can't easily change OF. It's like "let's change ACPI tables
or BIOS in these PCs". Doable, but involves things like reflashing.
And we usually have to support old BIOSes as well.
OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
mainline kernel only MPC8569 board has a correct m25p
node, and it is STMicro variant (it is JEDEC capable).
As we don't really have to support out of tree code, I'd
just go with this patch, assuming that we have to change
device tree for boards with non-JEDEC flashes. It's
effectively the same thing as platform data flag, except
that it works automatically for OF platforms.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..a610ca9 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
{ "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
{ "m25p128", INFO(0x202018, 0, 256 * 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) },
@@ -795,8 +805,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
jid = jedec_probe(spi);
if (!jid) {
- dev_info(&spi->dev, "non-JEDEC variant of %s\n",
- id->name);
+ return -ENODEV;
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
^ permalink raw reply related [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 11:20 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-21 11:20 UTC (permalink / raw)
To: Barry Song
Cc: Song, Barry, David Brownell, Artem Bityutskiy, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 06:31:44PM +0800, Barry Song wrote:
> On Mon, Jun 21, 2010 at 3:39 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> > On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
> >> On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> >> > On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
> >> > [...]
> >> >> > How about we add a non_jedec flag in platform_data, if the flag is 1, we
> >> >> > let the detection pass even though the ID is 0? Otherwise, we need a
> >> >> > valid ID?
> >> >> Here i mean:
> >> >
> >> > This will break at least OF-enabled platforms (e.g. PowerPC),
> >> > they assume that the driver will success for non-JEDEC flashes.
> >> > OF platforms don't pass platform data, and even if they did,
> >> > device tree doesn't specify if the flash is JEDEC or non-JEDEC.
> >> >
> >> > Which is why I think that, by default, the driver should
> >> > successfully register the flash even if JEDEC probe fails. So,
> >> > instead of checking for "!non_jedec", I would recommend
> >> > "force_jedec" check.
> >>
> >> Mike Frysinger suggested to use non_jedec since most devices are
> >> standard jedec devices.
> >
> > Well, on OF platforms most devices that I'm aware of are non-JEDEC.
> >
> >> Only if non_jedec=1, we let the detection pass
> >> if ID is 0.
> >
> > Then please #ifdef it with CONFIG_OF.
> I think the patch has nothing to do with platform. Here SPI Flash is a
> peripherals, doesn't depend on any platform. Adding a CONFIG_OF
> doesn't make sense very much.
With OF we don't place non-existent devices into the device
tree (or we mark them with status = "not-ok/disabled/absent"
property).
> If you think most devices are non-JEDEC, we can change non_JEDEC to
> force_JEDEC as you said.
> But anyway, is that real that most devices are non_JEDEC?
Why would this matter? We have to support both.
> If not, I think we should change OF platform codes to
> fit with this patch.
You can't easily change OF. It's like "let's change ACPI tables
or BIOS in these PCs". Doable, but involves things like reflashing.
And we usually have to support old BIOSes as well.
OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
mainline kernel only MPC8569 board has a correct m25p
node, and it is STMicro variant (it is JEDEC capable).
As we don't really have to support out of tree code, I'd
just go with this patch, assuming that we have to change
device tree for boards with non-JEDEC flashes. It's
effectively the same thing as platform data flag, except
that it works automatically for OF platforms.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..a610ca9 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
{ "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
{ "m25p128", INFO(0x202018, 0, 256 * 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) },
@@ -795,8 +805,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
jid = jedec_probe(spi);
if (!jid) {
- dev_info(&spi->dev, "non-JEDEC variant of %s\n",
- id->name);
+ return -ENODEV;
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
^ permalink raw reply related [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-21 11:20 ` Anton Vorontsov
(?)
@ 2010-06-21 16:34 ` Mike Frysinger
-1 siblings, 0 replies; 131+ messages in thread
From: Mike Frysinger @ 2010-06-21 16:34 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, Barry Song, linux-kernel,
Song, Barry, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
On Mon, Jun 21, 2010 at 07:20, Anton Vorontsov wrote:
> You can't easily change OF. It's like "let's change ACPI tables
> or BIOS in these PCs". Doable, but involves things like reflashing.
> And we usually have to support old BIOSes as well.
>
> OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
> mainline kernel only MPC8569 board has a correct m25p
> node, and it is STMicro variant (it is JEDEC capable).
>
> As we don't really have to support out of tree code, I'd
> just go with this patch, assuming that we have to change
> device tree for boards with non-JEDEC flashes. It's
> effectively the same thing as platform data flag, except
> that it works automatically for OF platforms.
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 81e49a9..a610ca9 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
> { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
> { "m25p128", INFO(0x202018, 0, 256 * 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) },
> +
are you picking the m25p because its flash geometry matches whatever
you're using, or because you have some weird variant of the m25p that
has JEDEC commands removed ?
-mike
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 16:34 ` Mike Frysinger
0 siblings, 0 replies; 131+ messages in thread
From: Mike Frysinger @ 2010-06-21 16:34 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Barry Song, Song, Barry, David Brownell, Artem Bityutskiy,
linux-kernel, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
On Mon, Jun 21, 2010 at 07:20, Anton Vorontsov wrote:
> You can't easily change OF. It's like "let's change ACPI tables
> or BIOS in these PCs". Doable, but involves things like reflashing.
> And we usually have to support old BIOSes as well.
>
> OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
> mainline kernel only MPC8569 board has a correct m25p
> node, and it is STMicro variant (it is JEDEC capable).
>
> As we don't really have to support out of tree code, I'd
> just go with this patch, assuming that we have to change
> device tree for boards with non-JEDEC flashes. It's
> effectively the same thing as platform data flag, except
> that it works automatically for OF platforms.
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 81e49a9..a610ca9 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
> { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
> { "m25p128", INFO(0x202018, 0, 256 * 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) },
> +
are you picking the m25p because its flash geometry matches whatever
you're using, or because you have some weird variant of the m25p that
has JEDEC commands removed ?
-mike
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 16:34 ` Mike Frysinger
0 siblings, 0 replies; 131+ messages in thread
From: Mike Frysinger @ 2010-06-21 16:34 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, Barry Song, linux-kernel,
Song, Barry, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
On Mon, Jun 21, 2010 at 07:20, Anton Vorontsov wrote:
> You can't easily change OF. It's like "let's change ACPI tables
> or BIOS in these PCs". Doable, but involves things like reflashing.
> And we usually have to support old BIOSes as well.
>
> OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
> mainline kernel only MPC8569 board has a correct m25p
> node, and it is STMicro variant (it is JEDEC capable).
>
> As we don't really have to support out of tree code, I'd
> just go with this patch, assuming that we have to change
> device tree for boards with non-JEDEC flashes. It's
> effectively the same thing as platform data flag, except
> that it works automatically for OF platforms.
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 81e49a9..a610ca9 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] =3D {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "m25p64", =C2=A0INFO(0x202017, =C2=A00, =C2=
=A064 * 1024, 128, 0) },
> =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "m25p128", INFO(0x202018, =C2=A00, 256 * 102=
4, =C2=A064, 0) },
>
> + =C2=A0 =C2=A0 =C2=A0 { "m25p05-nonjedec", =C2=A0INFO(0, 0, =C2=A032 * 1=
024, =C2=A0 2, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p10-nonjedec", =C2=A0INFO(0, 0, =C2=A032 * 1=
024, =C2=A0 4, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p20-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, =C2=A0 4, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p40-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, =C2=A0 8, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p80-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, =C2=A016, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p16-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, =C2=A032, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p32-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, =C2=A064, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p64-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, 128, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p128-nonjedec", INFO(0, 0, 256 * 1024, =C2=
=A064, 0) },
> +
are you picking the m25p because its flash geometry matches whatever
you're using, or because you have some weird variant of the m25p that
has JEDEC commands removed ?
-mike
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-21 16:34 ` Mike Frysinger
@ 2010-06-21 16:47 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-21 16:47 UTC (permalink / raw)
To: Mike Frysinger
Cc: David Brownell, Artem Bityutskiy, Barry Song, linux-kernel,
Song, Barry, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
On Mon, Jun 21, 2010 at 12:34:05PM -0400, Mike Frysinger wrote:
> On Mon, Jun 21, 2010 at 07:20, Anton Vorontsov wrote:
> > You can't easily change OF. It's like "let's change ACPI tables
> > or BIOS in these PCs". Doable, but involves things like reflashing.
> > And we usually have to support old BIOSes as well.
> >
> > OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
> > mainline kernel only MPC8569 board has a correct m25p
> > node, and it is STMicro variant (it is JEDEC capable).
> >
> > As we don't really have to support out of tree code, I'd
> > just go with this patch, assuming that we have to change
> > device tree for boards with non-JEDEC flashes. It's
> > effectively the same thing as platform data flag, except
> > that it works automatically for OF platforms.
> >
> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> > index 81e49a9..a610ca9 100644
> > --- a/drivers/mtd/devices/m25p80.c
> > +++ b/drivers/mtd/devices/m25p80.c
> > @@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
> > { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
> > { "m25p128", INFO(0x202018, 0, 256 * 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) },
> > +
>
> are you picking the m25p because its flash geometry matches whatever
> you're using, or because you have some weird variant of the m25p that
> has JEDEC commands removed ?
The latter. It's Numonyx M25Pxx flashes, see
http://www.numonyx.com/Documents/Datasheets/M25P80.pdf
The RDID instruction is available only for parts made with 110
nm Technology identified with Process letter '4'.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 16:47 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-21 16:47 UTC (permalink / raw)
To: Mike Frysinger
Cc: Barry Song, Song, Barry, David Brownell, Artem Bityutskiy,
linux-kernel, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
On Mon, Jun 21, 2010 at 12:34:05PM -0400, Mike Frysinger wrote:
> On Mon, Jun 21, 2010 at 07:20, Anton Vorontsov wrote:
> > You can't easily change OF. It's like "let's change ACPI tables
> > or BIOS in these PCs". Doable, but involves things like reflashing.
> > And we usually have to support old BIOSes as well.
> >
> > OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
> > mainline kernel only MPC8569 board has a correct m25p
> > node, and it is STMicro variant (it is JEDEC capable).
> >
> > As we don't really have to support out of tree code, I'd
> > just go with this patch, assuming that we have to change
> > device tree for boards with non-JEDEC flashes. It's
> > effectively the same thing as platform data flag, except
> > that it works automatically for OF platforms.
> >
> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> > index 81e49a9..a610ca9 100644
> > --- a/drivers/mtd/devices/m25p80.c
> > +++ b/drivers/mtd/devices/m25p80.c
> > @@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
> > { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
> > { "m25p128", INFO(0x202018, 0, 256 * 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) },
> > +
>
> are you picking the m25p because its flash geometry matches whatever
> you're using, or because you have some weird variant of the m25p that
> has JEDEC commands removed ?
The latter. It's Numonyx M25Pxx flashes, see
http://www.numonyx.com/Documents/Datasheets/M25P80.pdf
The RDID instruction is available only for parts made with 110
nm Technology identified with Process letter '4'.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-21 16:47 ` Anton Vorontsov
(?)
@ 2010-06-21 16:54 ` Mike Frysinger
-1 siblings, 0 replies; 131+ messages in thread
From: Mike Frysinger @ 2010-06-21 16:54 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, Barry Song, linux-kernel,
Song, Barry, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
On Mon, Jun 21, 2010 at 12:47, Anton Vorontsov wrote:
> On Mon, Jun 21, 2010 at 12:34:05PM -0400, Mike Frysinger wrote:
>> On Mon, Jun 21, 2010 at 07:20, Anton Vorontsov wrote:
>> > You can't easily change OF. It's like "let's change ACPI tables
>> > or BIOS in these PCs". Doable, but involves things like reflashing.
>> > And we usually have to support old BIOSes as well.
>> >
>> > OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
>> > mainline kernel only MPC8569 board has a correct m25p
>> > node, and it is STMicro variant (it is JEDEC capable).
>> >
>> > As we don't really have to support out of tree code, I'd
>> > just go with this patch, assuming that we have to change
>> > device tree for boards with non-JEDEC flashes. It's
>> > effectively the same thing as platform data flag, except
>> > that it works automatically for OF platforms.
>> >
>> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> > index 81e49a9..a610ca9 100644
>> > --- a/drivers/mtd/devices/m25p80.c
>> > +++ b/drivers/mtd/devices/m25p80.c
>> > @@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
>> > { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
>> > { "m25p128", INFO(0x202018, 0, 256 * 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) },
>> > +
>>
>> are you picking the m25p because its flash geometry matches whatever
>> you're using, or because you have some weird variant of the m25p that
>> has JEDEC commands removed ?
>
> The latter. It's Numonyx M25Pxx flashes, see
> http://www.numonyx.com/Documents/Datasheets/M25P80.pdf
>
> The RDID instruction is available only for parts made with 110
> nm Technology identified with Process letter '4'.
lovely. i guess this patch is the way to go to satisfy everyone's
requirements. i'm also of the mindset that a mtd should not be
created if the SPI flash isnt there simply because the resources say
it might be.
-mike
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 16:54 ` Mike Frysinger
0 siblings, 0 replies; 131+ messages in thread
From: Mike Frysinger @ 2010-06-21 16:54 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Barry Song, Song, Barry, David Brownell, Artem Bityutskiy,
linux-kernel, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
On Mon, Jun 21, 2010 at 12:47, Anton Vorontsov wrote:
> On Mon, Jun 21, 2010 at 12:34:05PM -0400, Mike Frysinger wrote:
>> On Mon, Jun 21, 2010 at 07:20, Anton Vorontsov wrote:
>> > You can't easily change OF. It's like "let's change ACPI tables
>> > or BIOS in these PCs". Doable, but involves things like reflashing.
>> > And we usually have to support old BIOSes as well.
>> >
>> > OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
>> > mainline kernel only MPC8569 board has a correct m25p
>> > node, and it is STMicro variant (it is JEDEC capable).
>> >
>> > As we don't really have to support out of tree code, I'd
>> > just go with this patch, assuming that we have to change
>> > device tree for boards with non-JEDEC flashes. It's
>> > effectively the same thing as platform data flag, except
>> > that it works automatically for OF platforms.
>> >
>> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> > index 81e49a9..a610ca9 100644
>> > --- a/drivers/mtd/devices/m25p80.c
>> > +++ b/drivers/mtd/devices/m25p80.c
>> > @@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
>> > { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
>> > { "m25p128", INFO(0x202018, 0, 256 * 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) },
>> > +
>>
>> are you picking the m25p because its flash geometry matches whatever
>> you're using, or because you have some weird variant of the m25p that
>> has JEDEC commands removed ?
>
> The latter. It's Numonyx M25Pxx flashes, see
> http://www.numonyx.com/Documents/Datasheets/M25P80.pdf
>
> The RDID instruction is available only for parts made with 110
> nm Technology identified with Process letter '4'.
lovely. i guess this patch is the way to go to satisfy everyone's
requirements. i'm also of the mindset that a mtd should not be
created if the SPI flash isnt there simply because the resources say
it might be.
-mike
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-21 16:54 ` Mike Frysinger
0 siblings, 0 replies; 131+ messages in thread
From: Mike Frysinger @ 2010-06-21 16:54 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, Barry Song, linux-kernel,
Song, Barry, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
On Mon, Jun 21, 2010 at 12:47, Anton Vorontsov wrote:
> On Mon, Jun 21, 2010 at 12:34:05PM -0400, Mike Frysinger wrote:
>> On Mon, Jun 21, 2010 at 07:20, Anton Vorontsov wrote:
>> > You can't easily change OF. It's like "let's change ACPI tables
>> > or BIOS in these PCs". Doable, but involves things like reflashing.
>> > And we usually have to support old BIOSes as well.
>> >
>> > OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
>> > mainline kernel only MPC8569 board has a correct m25p
>> > node, and it is STMicro variant (it is JEDEC capable).
>> >
>> > As we don't really have to support out of tree code, I'd
>> > just go with this patch, assuming that we have to change
>> > device tree for boards with non-JEDEC flashes. It's
>> > effectively the same thing as platform data flag, except
>> > that it works automatically for OF platforms.
>> >
>> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80=
.c
>> > index 81e49a9..a610ca9 100644
>> > --- a/drivers/mtd/devices/m25p80.c
>> > +++ b/drivers/mtd/devices/m25p80.c
>> > @@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] =3D =
{
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "m25p64", =C2=A0INFO(0x202017, =C2=A00, =
=C2=A064 * 1024, 128, 0) },
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "m25p128", INFO(0x202018, =C2=A00, 256 * =
1024, =C2=A064, 0) },
>> >
>> > + =C2=A0 =C2=A0 =C2=A0 { "m25p05-nonjedec", =C2=A0INFO(0, 0, =C2=A032 =
* 1024, =C2=A0 2, 0) },
>> > + =C2=A0 =C2=A0 =C2=A0 { "m25p10-nonjedec", =C2=A0INFO(0, 0, =C2=A032 =
* 1024, =C2=A0 4, 0) },
>> > + =C2=A0 =C2=A0 =C2=A0 { "m25p20-nonjedec", =C2=A0INFO(0, 0, =C2=A064 =
* 1024, =C2=A0 4, 0) },
>> > + =C2=A0 =C2=A0 =C2=A0 { "m25p40-nonjedec", =C2=A0INFO(0, 0, =C2=A064 =
* 1024, =C2=A0 8, 0) },
>> > + =C2=A0 =C2=A0 =C2=A0 { "m25p80-nonjedec", =C2=A0INFO(0, 0, =C2=A064 =
* 1024, =C2=A016, 0) },
>> > + =C2=A0 =C2=A0 =C2=A0 { "m25p16-nonjedec", =C2=A0INFO(0, 0, =C2=A064 =
* 1024, =C2=A032, 0) },
>> > + =C2=A0 =C2=A0 =C2=A0 { "m25p32-nonjedec", =C2=A0INFO(0, 0, =C2=A064 =
* 1024, =C2=A064, 0) },
>> > + =C2=A0 =C2=A0 =C2=A0 { "m25p64-nonjedec", =C2=A0INFO(0, 0, =C2=A064 =
* 1024, 128, 0) },
>> > + =C2=A0 =C2=A0 =C2=A0 { "m25p128-nonjedec", INFO(0, 0, 256 * 1024, =
=C2=A064, 0) },
>> > +
>>
>> are you picking the m25p because its flash geometry matches whatever
>> you're using, or because you have some weird variant of the m25p that
>> has JEDEC commands removed ?
>
> The latter. It's Numonyx M25Pxx flashes, see
> http://www.numonyx.com/Documents/Datasheets/M25P80.pdf
>
> =C2=A0 The RDID instruction is available only for parts made with 110
> =C2=A0 nm Technology identified with Process letter '4'.
lovely. i guess this patch is the way to go to satisfy everyone's
requirements. i'm also of the mindset that a mtd should not be
created if the SPI flash isnt there simply because the resources say
it might be.
-mike
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-21 11:20 ` Anton Vorontsov
(?)
@ 2010-06-22 6:37 ` Barry Song
-1 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-22 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, linux-kernel, Song, Barry,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 7:20 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Mon, Jun 21, 2010 at 06:31:44PM +0800, Barry Song wrote:
>> On Mon, Jun 21, 2010 at 3:39 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
>> > On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
>> >> On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
>> >> > On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
>> >> > [...]
>> >> >> > How about we add a non_jedec flag in platform_data, if the flag is 1, we
>> >> >> > let the detection pass even though the ID is 0? Otherwise, we need a
>> >> >> > valid ID?
>> >> >> Here i mean:
>> >> >
>> >> > This will break at least OF-enabled platforms (e.g. PowerPC),
>> >> > they assume that the driver will success for non-JEDEC flashes.
>> >> > OF platforms don't pass platform data, and even if they did,
>> >> > device tree doesn't specify if the flash is JEDEC or non-JEDEC.
>> >> >
>> >> > Which is why I think that, by default, the driver should
>> >> > successfully register the flash even if JEDEC probe fails. So,
>> >> > instead of checking for "!non_jedec", I would recommend
>> >> > "force_jedec" check.
>> >>
>> >> Mike Frysinger suggested to use non_jedec since most devices are
>> >> standard jedec devices.
>> >
>> > Well, on OF platforms most devices that I'm aware of are non-JEDEC.
>> >
>> >> Only if non_jedec=1, we let the detection pass
>> >> if ID is 0.
>> >
>> > Then please #ifdef it with CONFIG_OF.
>> I think the patch has nothing to do with platform. Here SPI Flash is a
>> peripherals, doesn't depend on any platform. Adding a CONFIG_OF
>> doesn't make sense very much.
>
> With OF we don't place non-existent devices into the device
> tree (or we mark them with status = "not-ok/disabled/absent"
> property).
>
>> If you think most devices are non-JEDEC, we can change non_JEDEC to
>> force_JEDEC as you said.
>> But anyway, is that real that most devices are non_JEDEC?
>
> Why would this matter? We have to support both.
>
>> If not, I think we should change OF platform codes to
>> fit with this patch.
>
> You can't easily change OF. It's like "let's change ACPI tables
> or BIOS in these PCs". Doable, but involves things like reflashing.
> And we usually have to support old BIOSes as well.
>
> OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
> mainline kernel only MPC8569 board has a correct m25p
> node, and it is STMicro variant (it is JEDEC capable).
>
> As we don't really have to support out of tree code, I'd
> just go with this patch, assuming that we have to change
> device tree for boards with non-JEDEC flashes. It's
> effectively the same thing as platform data flag, except
> that it works automatically for OF platforms.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 81e49a9..a610ca9 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
> { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
> { "m25p128", INFO(0x202018, 0, 256 * 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) },
> @@ -795,8 +805,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
>
> jid = jedec_probe(spi);
> if (!jid) {
> - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> - id->name);
> + return -ENODEV;
The patch looks good to me. Only problem is NULL is also returned by
spi_write_then_read() fail:
static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
{
int tmp;
u8 code = OPCODE_RDID;
u8 id[5];
u32 jedec;
u16 ext_jedec;
struct flash_info *info;
/* JEDEC also defines an optional "extended device information"
* string for after vendor-specific data, after the three bytes
* we use here. Supporting some chips might require using it.
*/
tmp = spi_write_then_read(spi, &code, 1, id, 5);
if (tmp < 0) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading JEDEC ID\n",
dev_name(&spi->dev), tmp);
return NULL;
}
...
}
Here much better for -EIO (return tmp)?
> } else if (jid != id) {
> /*
> * JEDEC knows better, so overwrite platform ID. We
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-22 6:37 ` Barry Song
0 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-22 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Song, Barry, David Brownell, Artem Bityutskiy, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 7:20 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Mon, Jun 21, 2010 at 06:31:44PM +0800, Barry Song wrote:
>> On Mon, Jun 21, 2010 at 3:39 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
>> > On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
>> >> On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
>> >> > On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
>> >> > [...]
>> >> >> > How about we add a non_jedec flag in platform_data, if the flag is 1, we
>> >> >> > let the detection pass even though the ID is 0? Otherwise, we need a
>> >> >> > valid ID?
>> >> >> Here i mean:
>> >> >
>> >> > This will break at least OF-enabled platforms (e.g. PowerPC),
>> >> > they assume that the driver will success for non-JEDEC flashes.
>> >> > OF platforms don't pass platform data, and even if they did,
>> >> > device tree doesn't specify if the flash is JEDEC or non-JEDEC.
>> >> >
>> >> > Which is why I think that, by default, the driver should
>> >> > successfully register the flash even if JEDEC probe fails. So,
>> >> > instead of checking for "!non_jedec", I would recommend
>> >> > "force_jedec" check.
>> >>
>> >> Mike Frysinger suggested to use non_jedec since most devices are
>> >> standard jedec devices.
>> >
>> > Well, on OF platforms most devices that I'm aware of are non-JEDEC.
>> >
>> >> Only if non_jedec=1, we let the detection pass
>> >> if ID is 0.
>> >
>> > Then please #ifdef it with CONFIG_OF.
>> I think the patch has nothing to do with platform. Here SPI Flash is a
>> peripherals, doesn't depend on any platform. Adding a CONFIG_OF
>> doesn't make sense very much.
>
> With OF we don't place non-existent devices into the device
> tree (or we mark them with status = "not-ok/disabled/absent"
> property).
>
>> If you think most devices are non-JEDEC, we can change non_JEDEC to
>> force_JEDEC as you said.
>> But anyway, is that real that most devices are non_JEDEC?
>
> Why would this matter? We have to support both.
>
>> If not, I think we should change OF platform codes to
>> fit with this patch.
>
> You can't easily change OF. It's like "let's change ACPI tables
> or BIOS in these PCs". Doable, but involves things like reflashing.
> And we usually have to support old BIOSes as well.
>
> OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
> mainline kernel only MPC8569 board has a correct m25p
> node, and it is STMicro variant (it is JEDEC capable).
>
> As we don't really have to support out of tree code, I'd
> just go with this patch, assuming that we have to change
> device tree for boards with non-JEDEC flashes. It's
> effectively the same thing as platform data flag, except
> that it works automatically for OF platforms.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 81e49a9..a610ca9 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
> { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
> { "m25p128", INFO(0x202018, 0, 256 * 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) },
> @@ -795,8 +805,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
>
> jid = jedec_probe(spi);
> if (!jid) {
> - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> - id->name);
> + return -ENODEV;
The patch looks good to me. Only problem is NULL is also returned by
spi_write_then_read() fail:
static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
{
int tmp;
u8 code = OPCODE_RDID;
u8 id[5];
u32 jedec;
u16 ext_jedec;
struct flash_info *info;
/* JEDEC also defines an optional "extended device information"
* string for after vendor-specific data, after the three bytes
* we use here. Supporting some chips might require using it.
*/
tmp = spi_write_then_read(spi, &code, 1, id, 5);
if (tmp < 0) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading JEDEC ID\n",
dev_name(&spi->dev), tmp);
return NULL;
}
...
}
Here much better for -EIO (return tmp)?
> } else if (jid != id) {
> /*
> * JEDEC knows better, so overwrite platform ID. We
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-22 6:37 ` Barry Song
0 siblings, 0 replies; 131+ messages in thread
From: Barry Song @ 2010-06-22 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, linux-kernel, Song, Barry,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton
On Mon, Jun 21, 2010 at 7:20 PM, Anton Vorontsov <cbouatmailru@gmail.com> w=
rote:
> On Mon, Jun 21, 2010 at 06:31:44PM +0800, Barry Song wrote:
>> On Mon, Jun 21, 2010 at 3:39 PM, Anton Vorontsov <cbouatmailru@gmail.com=
> wrote:
>> > On Mon, Jun 21, 2010 at 03:22:48PM +0800, Barry Song wrote:
>> >> On Mon, Jun 21, 2010 at 3:15 PM, Anton Vorontsov <cbouatmailru@gmail.=
com> wrote:
>> >> > On Mon, Jun 21, 2010 at 11:27:31AM +0800, Barry Song wrote:
>> >> > [...]
>> >> >> > How about we add a non_jedec flag in platform_data, if the flag =
is 1, we
>> >> >> > let the detection pass even though the ID is 0? Otherwise, we ne=
ed a
>> >> >> > valid ID?
>> >> >> Here i mean:
>> >> >
>> >> > This will break at least OF-enabled platforms (e.g. PowerPC),
>> >> > they assume that the driver will success for non-JEDEC flashes.
>> >> > OF platforms don't pass platform data, and even if they did,
>> >> > device tree doesn't specify if the flash is JEDEC or non-JEDEC.
>> >> >
>> >> > Which is why I think that, by default, the driver should
>> >> > successfully register the flash even if JEDEC probe fails. So,
>> >> > instead of checking for "!non_jedec", I would recommend
>> >> > "force_jedec" check.
>> >>
>> >> Mike Frysinger suggested to use non_jedec since most devices are
>> >> standard jedec devices.
>> >
>> > Well, on OF platforms most devices that I'm aware of are non-JEDEC.
>> >
>> >> Only if non_jedec=3D1, we let the detection pass
>> >> if ID is 0.
>> >
>> > Then please #ifdef it with CONFIG_OF.
>> I think the patch has nothing to do with platform. Here SPI Flash is a
>> peripherals, doesn't depend on any platform. Adding a CONFIG_OF
>> doesn't make sense very much.
>
> With OF we don't place non-existent devices into the device
> tree (or we mark them with status =3D "not-ok/disabled/absent"
> property).
>
>> If you think most devices are non-JEDEC, we can change non_JEDEC to
>> force_JEDEC as you said.
>> But anyway, is that real that most devices are non_JEDEC?
>
> Why would this matter? We have to support both.
>
>> If not, I think we should change OF platform codes to
>> fit with this patch.
>
> You can't easily change OF. It's like "let's change ACPI tables
> or BIOS in these PCs". Doable, but involves things like reflashing.
> And we usually have to support old BIOSes as well.
>
> OTOH, I see (git grep m25p arch/powerpc/boot/dts/) that in
> mainline kernel only MPC8569 board has a correct m25p
> node, and it is STMicro variant (it is JEDEC capable).
>
> As we don't really have to support out of tree code, I'd
> just go with this patch, assuming that we have to change
> device tree for boards with non-JEDEC flashes. It's
> effectively the same thing as platform data flag, except
> that it works automatically for OF platforms.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 81e49a9..a610ca9 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] =3D {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "m25p64", =C2=A0INFO(0x202017, =C2=A00, =C2=
=A064 * 1024, 128, 0) },
> =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "m25p128", INFO(0x202018, =C2=A00, 256 * 102=
4, =C2=A064, 0) },
>
> + =C2=A0 =C2=A0 =C2=A0 { "m25p05-nonjedec", =C2=A0INFO(0, 0, =C2=A032 * 1=
024, =C2=A0 2, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p10-nonjedec", =C2=A0INFO(0, 0, =C2=A032 * 1=
024, =C2=A0 4, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p20-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, =C2=A0 4, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p40-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, =C2=A0 8, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p80-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, =C2=A016, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p16-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, =C2=A032, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p32-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, =C2=A064, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p64-nonjedec", =C2=A0INFO(0, 0, =C2=A064 * 1=
024, 128, 0) },
> + =C2=A0 =C2=A0 =C2=A0 { "m25p128-nonjedec", INFO(0, 0, 256 * 1024, =C2=
=A064, 0) },
> +
> =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "m45pe10", INFO(0x204011, =C2=A00, 64 * 1024=
, =C2=A0 =C2=A02, 0) },
> =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "m45pe80", INFO(0x204014, =C2=A00, 64 * 1024=
, =C2=A0 16, 0) },
> =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "m45pe16", INFO(0x204015, =C2=A00, 64 * 1024=
, =C2=A0 32, 0) },
> @@ -795,8 +805,7 @@ static int __devinit m25p_probe(struct spi_device *sp=
i)
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0jid =3D jedec_prob=
e(spi);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!jid) {
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0id->name);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return -ENODEV;
The patch looks good to me. Only problem is NULL is also returned by
spi_write_then_read() fail:
static const struct spi_device_id *__devinit jedec_probe(struct spi_device =
*spi)
{
int tmp;
u8 code =3D OPCODE_RDID;
u8 id[5];
u32 jedec;
u16 ext_jedec;
struct flash_info *info;
/* JEDEC also defines an optional "extended device information"
* string for after vendor-specific data, after the three bytes
* we use here. Supporting some chips might require using it.
*/
tmp =3D spi_write_then_read(spi, &code, 1, id, 5);
if (tmp < 0) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading JEDEC ID\n",
dev_name(&spi->dev), tmp);
return NULL;
}
...
}
Here much better for -EIO (return tmp)?
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else if (jid !=
=3D id) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/*
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 * JEDEC knows better, so overwrite platform ID. We
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
2010-06-22 6:37 ` Barry Song
@ 2010-06-22 16:55 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-22 16:55 UTC (permalink / raw)
To: Barry Song
Cc: David Brownell, Artem Bityutskiy, linux-kernel, Song, Barry,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton,
David Woodhouse
On Tue, Jun 22, 2010 at 02:37:52PM +0800, Barry Song wrote:
[...]
> > jid = jedec_probe(spi);
> > if (!jid) {
> > - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> > - id->name);
> > + return -ENODEV;
> The patch looks good to me. Only problem is NULL is also returned by
> spi_write_then_read() fail:
[...]
> Here much better for -EIO (return tmp)?
Agreed. Though, this is not a regression, and I guess desires
its own patch.
Here are two patches, one for 2.6.35 (minimal changes to fix
the JEDEC problem), another for 2.6.36.
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
@ 2010-06-22 16:55 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-22 16:55 UTC (permalink / raw)
To: Barry Song
Cc: Song, Barry, David Brownell, Artem Bityutskiy, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton,
David Woodhouse
On Tue, Jun 22, 2010 at 02:37:52PM +0800, Barry Song wrote:
[...]
> > jid = jedec_probe(spi);
> > if (!jid) {
> > - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> > - id->name);
> > + return -ENODEV;
> The patch looks good to me. Only problem is NULL is also returned by
> spi_write_then_read() fail:
[...]
> Here much better for -EIO (return tmp)?
Agreed. Though, this is not a regression, and I guess desires
its own patch.
Here are two patches, one for 2.6.35 (minimal changes to fix
the JEDEC problem), another for 2.6.36.
^ permalink raw reply [flat|nested] 131+ messages in thread* [PATCH 1/2] mtd: m25p80: Fix false-positive probing
2010-06-22 16:55 ` Anton Vorontsov
@ 2010-06-22 16:57 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-22 16:57 UTC (permalink / raw)
To: David Woodhouse
Cc: David Brownell, Mike Frysinger, Artem Bityutskiy, Barry Song,
linux-kernel, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
Since commit 18c6182bae0acca220ed6611f741034d563cd19f ("Rework
probing/JEDEC code"), m25p80 driver successfully registers chips
even if JEDEC probing fails.
This was needed to support non-JEDEC flashes. Though, it appears
that some platforms (e.g. blackfin bf533 stamp[1]) used the old
behavior to detect if there's any flash connected, so the driver
have to fail on JEDEC probing errors.
This patch restores the old behavior for JEDEC flashes, and adds
"-nonjedec" SPI device IDs for M25Pxx flashes, so that the kernel
still supports non-JEDEC flashes.
[1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975
Reported-by: Mingquan Pan
Reported-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
This is for 2.6.35.
drivers/mtd/devices/m25p80.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..a610ca9 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
{ "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
{ "m25p128", INFO(0x202018, 0, 256 * 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) },
@@ -795,8 +805,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
jid = jedec_probe(spi);
if (!jid) {
- dev_info(&spi->dev, "non-JEDEC variant of %s\n",
- id->name);
+ return -ENODEV;
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
--
1.7.0.5
^ permalink raw reply related [flat|nested] 131+ messages in thread* [PATCH 1/2] mtd: m25p80: Fix false-positive probing
@ 2010-06-22 16:57 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-22 16:57 UTC (permalink / raw)
To: David Woodhouse
Cc: Barry Song, Andrew Morton, Mike Frysinger, David Brownell,
Artem Bityutskiy, linux-kernel, linuxppc-dev, linux-mtd,
uclinux-dist-devel
Since commit 18c6182bae0acca220ed6611f741034d563cd19f ("Rework
probing/JEDEC code"), m25p80 driver successfully registers chips
even if JEDEC probing fails.
This was needed to support non-JEDEC flashes. Though, it appears
that some platforms (e.g. blackfin bf533 stamp[1]) used the old
behavior to detect if there's any flash connected, so the driver
have to fail on JEDEC probing errors.
This patch restores the old behavior for JEDEC flashes, and adds
"-nonjedec" SPI device IDs for M25Pxx flashes, so that the kernel
still supports non-JEDEC flashes.
[1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975
Reported-by: Mingquan Pan
Reported-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
This is for 2.6.35.
drivers/mtd/devices/m25p80.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..a610ca9 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
{ "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
{ "m25p128", INFO(0x202018, 0, 256 * 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) },
@@ -795,8 +805,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
jid = jedec_probe(spi);
if (!jid) {
- dev_info(&spi->dev, "non-JEDEC variant of %s\n",
- id->name);
+ return -ENODEV;
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
--
1.7.0.5
^ permalink raw reply related [flat|nested] 131+ messages in thread* Re: [PATCH 1/2] mtd: m25p80: Fix false-positive probing
2010-06-22 16:57 ` Anton Vorontsov
@ 2010-06-22 17:56 ` Mike Frysinger
-1 siblings, 0 replies; 131+ messages in thread
From: Mike Frysinger @ 2010-06-22 17:56 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, Barry Song, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton,
David Woodhouse
On Tue, Jun 22, 2010 at 12:57, Anton Vorontsov wrote:
> Since commit 18c6182bae0acca220ed6611f741034d563cd19f ("Rework
> probing/JEDEC code"), m25p80 driver successfully registers chips
> even if JEDEC probing fails.
>
> This was needed to support non-JEDEC flashes. Though, it appears
> that some platforms (e.g. blackfin bf533 stamp[1]) used the old
> behavior to detect if there's any flash connected, so the driver
> have to fail on JEDEC probing errors.
>
> This patch restores the old behavior for JEDEC flashes, and adds
> "-nonjedec" SPI device IDs for M25Pxx flashes, so that the kernel
> still supports non-JEDEC flashes.
Acked-by: Mike Frysinger <vapier@gentoo.org>
> [1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975
http://blackfin.uclinux.org/gf/tracker/5975
> Reported-by: Mingquan Pan
<Grace.Pan@analog.com>
-mike
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 1/2] mtd: m25p80: Fix false-positive probing
@ 2010-06-22 17:56 ` Mike Frysinger
0 siblings, 0 replies; 131+ messages in thread
From: Mike Frysinger @ 2010-06-22 17:56 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Woodhouse, Barry Song, Andrew Morton, David Brownell,
Artem Bityutskiy, linux-kernel, linuxppc-dev, linux-mtd,
uclinux-dist-devel
On Tue, Jun 22, 2010 at 12:57, Anton Vorontsov wrote:
> Since commit 18c6182bae0acca220ed6611f741034d563cd19f ("Rework
> probing/JEDEC code"), m25p80 driver successfully registers chips
> even if JEDEC probing fails.
>
> This was needed to support non-JEDEC flashes. Though, it appears
> that some platforms (e.g. blackfin bf533 stamp[1]) used the old
> behavior to detect if there's any flash connected, so the driver
> have to fail on JEDEC probing errors.
>
> This patch restores the old behavior for JEDEC flashes, and adds
> "-nonjedec" SPI device IDs for M25Pxx flashes, so that the kernel
> still supports non-JEDEC flashes.
Acked-by: Mike Frysinger <vapier@gentoo.org>
> [1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975
http://blackfin.uclinux.org/gf/tracker/5975
> Reported-by: Mingquan Pan
<Grace.Pan@analog.com>
-mike
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 1/2] mtd: m25p80: Fix false-positive probing
2010-06-22 16:57 ` Anton Vorontsov
@ 2010-07-08 5:57 ` Artem Bityutskiy
-1 siblings, 0 replies; 131+ messages in thread
From: Artem Bityutskiy @ 2010-07-08 5:57 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Mike Frysinger, Barry Song, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton,
David Woodhouse
On Tue, 2010-06-22 at 20:57 +0400, Anton Vorontsov wrote:
> Since commit 18c6182bae0acca220ed6611f741034d563cd19f ("Rework
> probing/JEDEC code"), m25p80 driver successfully registers chips
> even if JEDEC probing fails.
>
> This was needed to support non-JEDEC flashes. Though, it appears
> that some platforms (e.g. blackfin bf533 stamp[1]) used the old
> behavior to detect if there's any flash connected, so the driver
> have to fail on JEDEC probing errors.
>
> This patch restores the old behavior for JEDEC flashes, and adds
> "-nonjedec" SPI device IDs for M25Pxx flashes, so that the kernel
> still supports non-JEDEC flashes.
>
> [1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975
>
> Reported-by: Mingquan Pan
> Reported-by: Barry Song <21cnbao@gmail.com>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
Pushed both patches to my l2-mtd-2.6.git / dunno, added Mike's ack.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 1/2] mtd: m25p80: Fix false-positive probing
@ 2010-07-08 5:57 ` Artem Bityutskiy
0 siblings, 0 replies; 131+ messages in thread
From: Artem Bityutskiy @ 2010-07-08 5:57 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Woodhouse, Barry Song, Andrew Morton, Mike Frysinger,
David Brownell, linux-kernel, linuxppc-dev, linux-mtd,
uclinux-dist-devel
On Tue, 2010-06-22 at 20:57 +0400, Anton Vorontsov wrote:
> Since commit 18c6182bae0acca220ed6611f741034d563cd19f ("Rework
> probing/JEDEC code"), m25p80 driver successfully registers chips
> even if JEDEC probing fails.
>
> This was needed to support non-JEDEC flashes. Though, it appears
> that some platforms (e.g. blackfin bf533 stamp[1]) used the old
> behavior to detect if there's any flash connected, so the driver
> have to fail on JEDEC probing errors.
>
> This patch restores the old behavior for JEDEC flashes, and adds
> "-nonjedec" SPI device IDs for M25Pxx flashes, so that the kernel
> still supports non-JEDEC flashes.
>
> [1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975
>
> Reported-by: Mingquan Pan
> Reported-by: Barry Song <21cnbao@gmail.com>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
Pushed both patches to my l2-mtd-2.6.git / dunno, added Mike's ack.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 131+ messages in thread
* [PATCH 2/2] mtd: m25p80: Make jedec_probe() return proper errno values
2010-06-22 16:55 ` Anton Vorontsov
@ 2010-06-22 16:57 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-22 16:57 UTC (permalink / raw)
To: David Woodhouse
Cc: David Brownell, Mike Frysinger, Artem Bityutskiy, Barry Song,
linux-kernel, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
spi_write_then_read() may return its own return codes (e.g. -EIO),
so let's propagate the value down to the probe().
Also, remove jedec == 0 check, it isn't needed as nowadays we use
dedicated SPI device IDs for non-JEDEC flashes.
Suggested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
This is for 2.6.36.
drivers/mtd/devices/m25p80.c | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index a610ca9..7bf5c45 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -16,6 +16,8 @@
*/
#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/errno.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/interrupt.h>
@@ -733,7 +735,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
if (tmp < 0) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading JEDEC ID\n",
dev_name(&spi->dev), tmp);
- return NULL;
+ return ERR_PTR(tmp);
}
jedec = id[0];
jedec = jedec << 8;
@@ -741,14 +743,6 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
jedec = jedec << 8;
jedec |= id[2];
- /*
- * Some chips (like Numonyx M25P80) have JEDEC and non-JEDEC variants,
- * which depend on technology process. Officially RDID command doesn't
- * exist for non-JEDEC chips, but for compatibility they return ID 0.
- */
- if (jedec == 0)
- return NULL;
-
ext_jedec = id[3] << 8 | id[4];
for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
@@ -759,7 +753,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
return &m25p_ids[tmp];
}
}
- return NULL;
+ return ERR_PTR(-ENODEV);
}
@@ -804,8 +798,8 @@ static int __devinit m25p_probe(struct spi_device *spi)
const struct spi_device_id *jid;
jid = jedec_probe(spi);
- if (!jid) {
- return -ENODEV;
+ if (IS_ERR(jid)) {
+ return PTR_ERR(jid);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
--
1.7.0.5
^ permalink raw reply related [flat|nested] 131+ messages in thread* [PATCH 2/2] mtd: m25p80: Make jedec_probe() return proper errno values
@ 2010-06-22 16:57 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2010-06-22 16:57 UTC (permalink / raw)
To: David Woodhouse
Cc: Barry Song, Andrew Morton, Mike Frysinger, David Brownell,
Artem Bityutskiy, linux-kernel, linuxppc-dev, linux-mtd,
uclinux-dist-devel
spi_write_then_read() may return its own return codes (e.g. -EIO),
so let's propagate the value down to the probe().
Also, remove jedec == 0 check, it isn't needed as nowadays we use
dedicated SPI device IDs for non-JEDEC flashes.
Suggested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
This is for 2.6.36.
drivers/mtd/devices/m25p80.c | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index a610ca9..7bf5c45 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -16,6 +16,8 @@
*/
#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/errno.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/interrupt.h>
@@ -733,7 +735,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
if (tmp < 0) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading JEDEC ID\n",
dev_name(&spi->dev), tmp);
- return NULL;
+ return ERR_PTR(tmp);
}
jedec = id[0];
jedec = jedec << 8;
@@ -741,14 +743,6 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
jedec = jedec << 8;
jedec |= id[2];
- /*
- * Some chips (like Numonyx M25P80) have JEDEC and non-JEDEC variants,
- * which depend on technology process. Officially RDID command doesn't
- * exist for non-JEDEC chips, but for compatibility they return ID 0.
- */
- if (jedec == 0)
- return NULL;
-
ext_jedec = id[3] << 8 | id[4];
for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
@@ -759,7 +753,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
return &m25p_ids[tmp];
}
}
- return NULL;
+ return ERR_PTR(-ENODEV);
}
@@ -804,8 +798,8 @@ static int __devinit m25p_probe(struct spi_device *spi)
const struct spi_device_id *jid;
jid = jedec_probe(spi);
- if (!jid) {
- return -ENODEV;
+ if (IS_ERR(jid)) {
+ return PTR_ERR(jid);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
--
1.7.0.5
^ permalink raw reply related [flat|nested] 131+ messages in thread
* [PATCH 2/2] mtd: m25p80: Add support for CAT25xxx serial EEPROMs
2009-08-18 21:44 ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table Anton Vorontsov
@ 2009-08-18 21:46 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-18 21:46 UTC (permalink / raw)
To: Andrew Morton
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, David Woodhouse
CAT25 chips (as manufactured by On Semiconductor, previously Catalyst
Semiconductor) are similar to the original M25Px0 chips, except:
- Address width can vary (1-2 bytes, in contrast to 3 bytes in M25P
chips). So, implement convenient m25p_addr2cmd() and m25p_cmdsz()
calls, and place address width information into flash_info struct;
- Page size can vary, therefore we shouldn't hardcode it, so get rid
of FLASH_PAGESIZE definition, and place the page size information
into flash_info struct;
- CAT25 EEPROMs don't need to be erased, so add NO_ERASE flag, and
propagate it to the mtd subsystem.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mtd/devices/m25p80.c | 172 ++++++++++++++++++++++++------------------
1 files changed, 97 insertions(+), 75 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index b75e319..8930266 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -29,9 +29,6 @@
#include <linux/spi/spi.h>
#include <linux/spi/flash.h>
-
-#define FLASH_PAGESIZE 256
-
/* Flash opcodes. */
#define OPCODE_WREN 0x06 /* Write enable */
#define OPCODE_RDSR 0x05 /* Read status register */
@@ -56,7 +53,7 @@
/* Define max times to check status register before we give up. */
#define MAX_READY_WAIT_JIFFIES (40 * HZ) /* M25P16 specs 40s max chip erase */
-#define CMD_SIZE 4
+#define MAX_CMD_SIZE 4
#ifdef CONFIG_M25PXX_USE_FAST_READ
#define OPCODE_READ OPCODE_FAST_READ
@@ -73,8 +70,10 @@ struct m25p {
struct mutex lock;
struct mtd_info mtd;
unsigned partitioned:1;
+ u16 page_size;
+ u16 addr_width;
u8 erase_opcode;
- u8 command[CMD_SIZE + FAST_READ_DUMMY_BYTE];
+ u8 command[MAX_CMD_SIZE + FAST_READ_DUMMY_BYTE];
};
static inline struct m25p *mtd_to_m25p(struct mtd_info *mtd)
@@ -184,6 +183,19 @@ static int erase_chip(struct m25p *flash)
return 0;
}
+static void m25p_addr2cmd(struct m25p *flash, unsigned int addr, u8 *cmd)
+{
+ /* opcode is in cmd[0] */
+ cmd[1] = addr >> (flash->addr_width * 8 - 8);
+ cmd[2] = addr >> (flash->addr_width * 8 - 16);
+ cmd[3] = addr >> (flash->addr_width * 8 - 24);
+}
+
+static int m25p_cmdsz(struct m25p *flash)
+{
+ return 1 + flash->addr_width;
+}
+
/*
* Erase one sector of flash memory at offset ``offset'' which is any
* address within the sector which should be erased.
@@ -205,11 +217,9 @@ static int erase_sector(struct m25p *flash, u32 offset)
/* Set up command buffer. */
flash->command[0] = flash->erase_opcode;
- flash->command[1] = offset >> 16;
- flash->command[2] = offset >> 8;
- flash->command[3] = offset;
+ m25p_addr2cmd(flash, offset, flash->command);
- spi_write(flash->spi, flash->command, CMD_SIZE);
+ spi_write(flash->spi, flash->command, m25p_cmdsz(flash));
return 0;
}
@@ -311,7 +321,7 @@ static int m25p80_read(struct mtd_info *mtd, loff_t from, size_t len,
* Should add 1 byte DUMMY_BYTE.
*/
t[0].tx_buf = flash->command;
- t[0].len = CMD_SIZE + FAST_READ_DUMMY_BYTE;
+ t[0].len = m25p_cmdsz(flash) + FAST_READ_DUMMY_BYTE;
spi_message_add_tail(&t[0], &m);
t[1].rx_buf = buf;
@@ -338,13 +348,11 @@ static int m25p80_read(struct mtd_info *mtd, loff_t from, size_t len,
/* Set up the write data buffer. */
flash->command[0] = OPCODE_READ;
- flash->command[1] = from >> 16;
- flash->command[2] = from >> 8;
- flash->command[3] = from;
+ m25p_addr2cmd(flash, from, flash->command);
spi_sync(flash->spi, &m);
- *retlen = m.actual_length - CMD_SIZE - FAST_READ_DUMMY_BYTE;
+ *retlen = m.actual_length - m25p_cmdsz(flash) - FAST_READ_DUMMY_BYTE;
mutex_unlock(&flash->lock);
@@ -382,7 +390,7 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
memset(t, 0, (sizeof t));
t[0].tx_buf = flash->command;
- t[0].len = CMD_SIZE;
+ t[0].len = m25p_cmdsz(flash);
spi_message_add_tail(&t[0], &m);
t[1].tx_buf = buf;
@@ -400,41 +408,36 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
/* Set up the opcode in the write buffer. */
flash->command[0] = OPCODE_PP;
- flash->command[1] = to >> 16;
- flash->command[2] = to >> 8;
- flash->command[3] = to;
+ m25p_addr2cmd(flash, to, flash->command);
- /* what page do we start with? */
- page_offset = to % FLASH_PAGESIZE;
+ page_offset = to & (flash->page_size - 1);
/* do all the bytes fit onto one page? */
- if (page_offset + len <= FLASH_PAGESIZE) {
+ if (page_offset + len <= flash->page_size) {
t[1].len = len;
spi_sync(flash->spi, &m);
- *retlen = m.actual_length - CMD_SIZE;
+ *retlen = m.actual_length - m25p_cmdsz(flash);
} else {
u32 i;
/* the size of data remaining on the first page */
- page_size = FLASH_PAGESIZE - page_offset;
+ page_size = flash->page_size - page_offset;
t[1].len = page_size;
spi_sync(flash->spi, &m);
- *retlen = m.actual_length - CMD_SIZE;
+ *retlen = m.actual_length - m25p_cmdsz(flash);
- /* write everything in PAGESIZE chunks */
+ /* write everything in flash->page_size chunks */
for (i = page_size; i < len; i += page_size) {
page_size = len - i;
- if (page_size > FLASH_PAGESIZE)
- page_size = FLASH_PAGESIZE;
+ if (page_size > flash->page_size)
+ page_size = flash->page_size;
/* write the next page to flash */
- flash->command[1] = (to + i) >> 16;
- flash->command[2] = (to + i) >> 8;
- flash->command[3] = (to + i);
+ m25p_addr2cmd(flash, to + i, flash->command);
t[1].tx_buf = buf + i;
t[1].len = page_size;
@@ -446,7 +449,7 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
spi_sync(flash->spi, &m);
if (retlen)
- *retlen += m.actual_length - CMD_SIZE;
+ *retlen += m.actual_length - m25p_cmdsz(flash);
}
}
@@ -476,16 +479,23 @@ struct flash_info {
unsigned sector_size;
u16 n_sectors;
+ u16 page_size;
+ u16 addr_width;
+
u16 flags;
#define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
+#define M25P_NO_ERASE 0x02 /* No erase command needed */
};
-#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _page_size, \
+ _addr_width, _flags) \
((kernel_ulong_t)&(struct flash_info) { \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
+ .page_size = (_page_size), \
+ .addr_width = (_addr_width), \
.flags = (_flags), \
})
@@ -495,63 +505,70 @@ struct flash_info {
*/
static const struct spi_device_id m25p_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) },
+ { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, 256, 3, SECT_4K) },
+ { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, 256, 3, SECT_4K) },
- { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
- { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
+ { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, 256, 3, SECT_4K) },
+ { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, 256, 3, 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(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
+ { "at26f004", INFO(0x1f0400, 0, 64 * 1024, 8, 256, 3, SECT_4K) },
+ { "at26df081a", INFO(0x1f4501, 0, 64 * 1024, 16, 256, 3, SECT_4K) },
+ { "at26df161a", INFO(0x1f4601, 0, 64 * 1024, 32, 256, 3, SECT_4K) },
+ { "at26df321", INFO(0x1f4701, 0, 64 * 1024, 64, 256, 3, SECT_4K) },
/* Macronix */
- { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
+ { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 256, 3, 0) },
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- { "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) },
- { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
- { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
+ { "s25sl004a", INFO(0x010212, 0, 64 * 1024, 8, 256, 3, 0) },
+ { "s25sl008a", INFO(0x010213, 0, 64 * 1024, 16, 256, 3, 0) },
+ { "s25sl016a", INFO(0x010214, 0, 64 * 1024, 32, 256, 3, 0) },
+ { "s25sl032a", INFO(0x010215, 0, 64 * 1024, 64, 256, 3, 0) },
+ { "s25sl064a", INFO(0x010216, 0, 64 * 1024, 128, 256, 3, 0) },
+ { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 256, 3, 0) },
+ { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 256, 3, 0) },
/* SST -- large erase sizes are "overlays", "sectors" are 4K */
- { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K) },
- { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K) },
- { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K) },
- { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K) },
+ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, 256, 3, SECT_4K) },
+ { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, 256, 3, SECT_4K) },
+ { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, 256, 3, SECT_4K) },
+ { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, 256, 3, SECT_4K) },
/* 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) },
-
- { "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 0) },
- { "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 0) },
- { "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 0) },
-
- { "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 0) },
- { "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, SECT_4K) },
+ { "m25p05", INFO(0x202010, 0, 32 * 1024, 2, 256, 3, 0) },
+ { "m25p10", INFO(0x202011, 0, 32 * 1024, 4, 256, 3, 0) },
+ { "m25p20", INFO(0x202012, 0, 64 * 1024, 4, 256, 3, 0) },
+ { "m25p40", INFO(0x202013, 0, 64 * 1024, 8, 256, 3, 0) },
+ { "m25p80", INFO(0x202014, 0, 64 * 1024, 16, 256, 3, 0) },
+ { "m25p16", INFO(0x202015, 0, 64 * 1024, 32, 256, 3, 0) },
+ { "m25p32", INFO(0x202016, 0, 64 * 1024, 64, 256, 3, 0) },
+ { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 256, 3, 0) },
+ { "m25p128", INFO(0x202018, 0, 256 * 1024, 64, 256, 3, 0) },
+
+ { "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 256, 3, 0) },
+ { "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 256, 3, 0) },
+ { "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 256, 3, 0) },
+
+ { "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 256, 3, 0) },
+ { "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, 256, 3, SECT_4K) },
/* 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) },
- { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
+ { "w25x10", INFO(0xef3011, 0, 64 * 1024, 2, 256, 3, SECT_4K) },
+ { "w25x20", INFO(0xef3012, 0, 64 * 1024, 4, 256, 3, SECT_4K) },
+ { "w25x40", INFO(0xef3013, 0, 64 * 1024, 8, 256, 3, SECT_4K) },
+ { "w25x80", INFO(0xef3014, 0, 64 * 1024, 16, 256, 3, SECT_4K) },
+ { "w25x16", INFO(0xef3015, 0, 64 * 1024, 32, 256, 3, SECT_4K) },
+ { "w25x32", INFO(0xef3016, 0, 64 * 1024, 64, 256, 3, SECT_4K) },
+ { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, 256, 3, SECT_4K) },
+
+ /* Catalyst / On Semiconductor -- non-JEDEC */
+ { "cat25c11", INFO(0x0, 0, 16, 8, 16, 1, M25P_NO_ERASE) },
+ { "cat25c03", INFO(0x0, 0, 32, 8, 16, 2, M25P_NO_ERASE) },
+ { "cat25c09", INFO(0x0, 0, 128, 8, 32, 2, M25P_NO_ERASE) },
+ { "cat25c17", INFO(0x0, 0, 256, 8, 32, 2, M25P_NO_ERASE) },
+ { "cat25128", INFO(0x0, 0, 2048, 8, 64, 2, M25P_NO_ERASE) },
{ },
};
MODULE_DEVICE_TABLE(spi, m25p_ids);
@@ -702,7 +719,12 @@ static int __devinit m25p_probe(struct spi_device *spi)
flash->mtd.erasesize = info->sector_size;
}
+ if (info->flags & M25P_NO_ERASE)
+ flash->mtd.flags |= MTD_NO_ERASE;
+
flash->mtd.dev.parent = &spi->dev;
+ flash->page_size = info->page_size;
+ flash->addr_width = info->addr_width;
dev_info(&spi->dev, "%s (%lld Kbytes)\n", id->name,
(long long)flash->mtd.size >> 10);
--
1.6.3.3
^ permalink raw reply related [flat|nested] 131+ messages in thread* [PATCH 2/2] mtd: m25p80: Add support for CAT25xxx serial EEPROMs
@ 2009-08-18 21:46 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-18 21:46 UTC (permalink / raw)
To: Andrew Morton
Cc: David Brownell, David Woodhouse, Artem Bityutskiy, linux-mtd,
linux-kernel, linuxppc-dev
CAT25 chips (as manufactured by On Semiconductor, previously Catalyst
Semiconductor) are similar to the original M25Px0 chips, except:
- Address width can vary (1-2 bytes, in contrast to 3 bytes in M25P
chips). So, implement convenient m25p_addr2cmd() and m25p_cmdsz()
calls, and place address width information into flash_info struct;
- Page size can vary, therefore we shouldn't hardcode it, so get rid
of FLASH_PAGESIZE definition, and place the page size information
into flash_info struct;
- CAT25 EEPROMs don't need to be erased, so add NO_ERASE flag, and
propagate it to the mtd subsystem.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mtd/devices/m25p80.c | 172 ++++++++++++++++++++++++------------------
1 files changed, 97 insertions(+), 75 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index b75e319..8930266 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -29,9 +29,6 @@
#include <linux/spi/spi.h>
#include <linux/spi/flash.h>
-
-#define FLASH_PAGESIZE 256
-
/* Flash opcodes. */
#define OPCODE_WREN 0x06 /* Write enable */
#define OPCODE_RDSR 0x05 /* Read status register */
@@ -56,7 +53,7 @@
/* Define max times to check status register before we give up. */
#define MAX_READY_WAIT_JIFFIES (40 * HZ) /* M25P16 specs 40s max chip erase */
-#define CMD_SIZE 4
+#define MAX_CMD_SIZE 4
#ifdef CONFIG_M25PXX_USE_FAST_READ
#define OPCODE_READ OPCODE_FAST_READ
@@ -73,8 +70,10 @@ struct m25p {
struct mutex lock;
struct mtd_info mtd;
unsigned partitioned:1;
+ u16 page_size;
+ u16 addr_width;
u8 erase_opcode;
- u8 command[CMD_SIZE + FAST_READ_DUMMY_BYTE];
+ u8 command[MAX_CMD_SIZE + FAST_READ_DUMMY_BYTE];
};
static inline struct m25p *mtd_to_m25p(struct mtd_info *mtd)
@@ -184,6 +183,19 @@ static int erase_chip(struct m25p *flash)
return 0;
}
+static void m25p_addr2cmd(struct m25p *flash, unsigned int addr, u8 *cmd)
+{
+ /* opcode is in cmd[0] */
+ cmd[1] = addr >> (flash->addr_width * 8 - 8);
+ cmd[2] = addr >> (flash->addr_width * 8 - 16);
+ cmd[3] = addr >> (flash->addr_width * 8 - 24);
+}
+
+static int m25p_cmdsz(struct m25p *flash)
+{
+ return 1 + flash->addr_width;
+}
+
/*
* Erase one sector of flash memory at offset ``offset'' which is any
* address within the sector which should be erased.
@@ -205,11 +217,9 @@ static int erase_sector(struct m25p *flash, u32 offset)
/* Set up command buffer. */
flash->command[0] = flash->erase_opcode;
- flash->command[1] = offset >> 16;
- flash->command[2] = offset >> 8;
- flash->command[3] = offset;
+ m25p_addr2cmd(flash, offset, flash->command);
- spi_write(flash->spi, flash->command, CMD_SIZE);
+ spi_write(flash->spi, flash->command, m25p_cmdsz(flash));
return 0;
}
@@ -311,7 +321,7 @@ static int m25p80_read(struct mtd_info *mtd, loff_t from, size_t len,
* Should add 1 byte DUMMY_BYTE.
*/
t[0].tx_buf = flash->command;
- t[0].len = CMD_SIZE + FAST_READ_DUMMY_BYTE;
+ t[0].len = m25p_cmdsz(flash) + FAST_READ_DUMMY_BYTE;
spi_message_add_tail(&t[0], &m);
t[1].rx_buf = buf;
@@ -338,13 +348,11 @@ static int m25p80_read(struct mtd_info *mtd, loff_t from, size_t len,
/* Set up the write data buffer. */
flash->command[0] = OPCODE_READ;
- flash->command[1] = from >> 16;
- flash->command[2] = from >> 8;
- flash->command[3] = from;
+ m25p_addr2cmd(flash, from, flash->command);
spi_sync(flash->spi, &m);
- *retlen = m.actual_length - CMD_SIZE - FAST_READ_DUMMY_BYTE;
+ *retlen = m.actual_length - m25p_cmdsz(flash) - FAST_READ_DUMMY_BYTE;
mutex_unlock(&flash->lock);
@@ -382,7 +390,7 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
memset(t, 0, (sizeof t));
t[0].tx_buf = flash->command;
- t[0].len = CMD_SIZE;
+ t[0].len = m25p_cmdsz(flash);
spi_message_add_tail(&t[0], &m);
t[1].tx_buf = buf;
@@ -400,41 +408,36 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
/* Set up the opcode in the write buffer. */
flash->command[0] = OPCODE_PP;
- flash->command[1] = to >> 16;
- flash->command[2] = to >> 8;
- flash->command[3] = to;
+ m25p_addr2cmd(flash, to, flash->command);
- /* what page do we start with? */
- page_offset = to % FLASH_PAGESIZE;
+ page_offset = to & (flash->page_size - 1);
/* do all the bytes fit onto one page? */
- if (page_offset + len <= FLASH_PAGESIZE) {
+ if (page_offset + len <= flash->page_size) {
t[1].len = len;
spi_sync(flash->spi, &m);
- *retlen = m.actual_length - CMD_SIZE;
+ *retlen = m.actual_length - m25p_cmdsz(flash);
} else {
u32 i;
/* the size of data remaining on the first page */
- page_size = FLASH_PAGESIZE - page_offset;
+ page_size = flash->page_size - page_offset;
t[1].len = page_size;
spi_sync(flash->spi, &m);
- *retlen = m.actual_length - CMD_SIZE;
+ *retlen = m.actual_length - m25p_cmdsz(flash);
- /* write everything in PAGESIZE chunks */
+ /* write everything in flash->page_size chunks */
for (i = page_size; i < len; i += page_size) {
page_size = len - i;
- if (page_size > FLASH_PAGESIZE)
- page_size = FLASH_PAGESIZE;
+ if (page_size > flash->page_size)
+ page_size = flash->page_size;
/* write the next page to flash */
- flash->command[1] = (to + i) >> 16;
- flash->command[2] = (to + i) >> 8;
- flash->command[3] = (to + i);
+ m25p_addr2cmd(flash, to + i, flash->command);
t[1].tx_buf = buf + i;
t[1].len = page_size;
@@ -446,7 +449,7 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
spi_sync(flash->spi, &m);
if (retlen)
- *retlen += m.actual_length - CMD_SIZE;
+ *retlen += m.actual_length - m25p_cmdsz(flash);
}
}
@@ -476,16 +479,23 @@ struct flash_info {
unsigned sector_size;
u16 n_sectors;
+ u16 page_size;
+ u16 addr_width;
+
u16 flags;
#define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
+#define M25P_NO_ERASE 0x02 /* No erase command needed */
};
-#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _page_size, \
+ _addr_width, _flags) \
((kernel_ulong_t)&(struct flash_info) { \
.jedec_id = (_jedec_id), \
.ext_id = (_ext_id), \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
+ .page_size = (_page_size), \
+ .addr_width = (_addr_width), \
.flags = (_flags), \
})
@@ -495,63 +505,70 @@ struct flash_info {
*/
static const struct spi_device_id m25p_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) },
+ { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, 256, 3, SECT_4K) },
+ { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, 256, 3, SECT_4K) },
- { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
- { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
+ { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, 256, 3, SECT_4K) },
+ { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, 256, 3, 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(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
+ { "at26f004", INFO(0x1f0400, 0, 64 * 1024, 8, 256, 3, SECT_4K) },
+ { "at26df081a", INFO(0x1f4501, 0, 64 * 1024, 16, 256, 3, SECT_4K) },
+ { "at26df161a", INFO(0x1f4601, 0, 64 * 1024, 32, 256, 3, SECT_4K) },
+ { "at26df321", INFO(0x1f4701, 0, 64 * 1024, 64, 256, 3, SECT_4K) },
/* Macronix */
- { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
+ { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 256, 3, 0) },
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- { "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) },
- { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
- { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
+ { "s25sl004a", INFO(0x010212, 0, 64 * 1024, 8, 256, 3, 0) },
+ { "s25sl008a", INFO(0x010213, 0, 64 * 1024, 16, 256, 3, 0) },
+ { "s25sl016a", INFO(0x010214, 0, 64 * 1024, 32, 256, 3, 0) },
+ { "s25sl032a", INFO(0x010215, 0, 64 * 1024, 64, 256, 3, 0) },
+ { "s25sl064a", INFO(0x010216, 0, 64 * 1024, 128, 256, 3, 0) },
+ { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 256, 3, 0) },
+ { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 256, 3, 0) },
/* SST -- large erase sizes are "overlays", "sectors" are 4K */
- { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K) },
- { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K) },
- { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K) },
- { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K) },
+ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, 256, 3, SECT_4K) },
+ { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, 256, 3, SECT_4K) },
+ { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, 256, 3, SECT_4K) },
+ { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, 256, 3, SECT_4K) },
/* 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) },
-
- { "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 0) },
- { "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 0) },
- { "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 0) },
-
- { "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 0) },
- { "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, SECT_4K) },
+ { "m25p05", INFO(0x202010, 0, 32 * 1024, 2, 256, 3, 0) },
+ { "m25p10", INFO(0x202011, 0, 32 * 1024, 4, 256, 3, 0) },
+ { "m25p20", INFO(0x202012, 0, 64 * 1024, 4, 256, 3, 0) },
+ { "m25p40", INFO(0x202013, 0, 64 * 1024, 8, 256, 3, 0) },
+ { "m25p80", INFO(0x202014, 0, 64 * 1024, 16, 256, 3, 0) },
+ { "m25p16", INFO(0x202015, 0, 64 * 1024, 32, 256, 3, 0) },
+ { "m25p32", INFO(0x202016, 0, 64 * 1024, 64, 256, 3, 0) },
+ { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 256, 3, 0) },
+ { "m25p128", INFO(0x202018, 0, 256 * 1024, 64, 256, 3, 0) },
+
+ { "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 256, 3, 0) },
+ { "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 256, 3, 0) },
+ { "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 256, 3, 0) },
+
+ { "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 256, 3, 0) },
+ { "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, 256, 3, SECT_4K) },
/* 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) },
- { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
+ { "w25x10", INFO(0xef3011, 0, 64 * 1024, 2, 256, 3, SECT_4K) },
+ { "w25x20", INFO(0xef3012, 0, 64 * 1024, 4, 256, 3, SECT_4K) },
+ { "w25x40", INFO(0xef3013, 0, 64 * 1024, 8, 256, 3, SECT_4K) },
+ { "w25x80", INFO(0xef3014, 0, 64 * 1024, 16, 256, 3, SECT_4K) },
+ { "w25x16", INFO(0xef3015, 0, 64 * 1024, 32, 256, 3, SECT_4K) },
+ { "w25x32", INFO(0xef3016, 0, 64 * 1024, 64, 256, 3, SECT_4K) },
+ { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, 256, 3, SECT_4K) },
+
+ /* Catalyst / On Semiconductor -- non-JEDEC */
+ { "cat25c11", INFO(0x0, 0, 16, 8, 16, 1, M25P_NO_ERASE) },
+ { "cat25c03", INFO(0x0, 0, 32, 8, 16, 2, M25P_NO_ERASE) },
+ { "cat25c09", INFO(0x0, 0, 128, 8, 32, 2, M25P_NO_ERASE) },
+ { "cat25c17", INFO(0x0, 0, 256, 8, 32, 2, M25P_NO_ERASE) },
+ { "cat25128", INFO(0x0, 0, 2048, 8, 64, 2, M25P_NO_ERASE) },
{ },
};
MODULE_DEVICE_TABLE(spi, m25p_ids);
@@ -702,7 +719,12 @@ static int __devinit m25p_probe(struct spi_device *spi)
flash->mtd.erasesize = info->sector_size;
}
+ if (info->flags & M25P_NO_ERASE)
+ flash->mtd.flags |= MTD_NO_ERASE;
+
flash->mtd.dev.parent = &spi->dev;
+ flash->page_size = info->page_size;
+ flash->addr_width = info->addr_width;
dev_info(&spi->dev, "%s (%lld Kbytes)\n", id->name,
(long long)flash->mtd.size >> 10);
--
1.6.3.3
^ permalink raw reply related [flat|nested] 131+ messages in thread* Re: [PATCH 2/2] mtd: m25p80: Add support for CAT25xxx serial EEPROMs
2009-08-18 21:46 ` Anton Vorontsov
@ 2009-09-22 23:25 ` Andrew Morton
-1 siblings, 0 replies; 131+ messages in thread
From: Andrew Morton @ 2009-09-22 23:25 UTC (permalink / raw)
To: Anton Vorontsov
Cc: dbrownell, dedekind1, linux-kernel, linuxppc-dev, linux-mtd,
dwmw2
On Wed, 19 Aug 2009 01:46:28 +0400
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> CAT25 chips (as manufactured by On Semiconductor, previously Catalyst
> Semiconductor) are similar to the original M25Px0 chips, except:
>
> - Address width can vary (1-2 bytes, in contrast to 3 bytes in M25P
> chips). So, implement convenient m25p_addr2cmd() and m25p_cmdsz()
> calls, and place address width information into flash_info struct;
>
> - Page size can vary, therefore we shouldn't hardcode it, so get rid
> of FLASH_PAGESIZE definition, and place the page size information
> into flash_info struct;
>
> - CAT25 EEPROMs don't need to be erased, so add NO_ERASE flag, and
> propagate it to the mtd subsystem.
This patch (still) doesn't know about the mx25l3205d, mx25l12805d and
mx25l12855e devices.
I randomly did this:
-> { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, 256, 3, 0) },
-> { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, 256, 3, 0) },
{ "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 256, 3, 0) },
-> { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 256, 3, 0) },
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/2] mtd: m25p80: Add support for CAT25xxx serial EEPROMs
@ 2009-09-22 23:25 ` Andrew Morton
0 siblings, 0 replies; 131+ messages in thread
From: Andrew Morton @ 2009-09-22 23:25 UTC (permalink / raw)
To: Anton Vorontsov
Cc: dbrownell, dwmw2, dedekind1, linux-mtd, linux-kernel,
linuxppc-dev
On Wed, 19 Aug 2009 01:46:28 +0400
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> CAT25 chips (as manufactured by On Semiconductor, previously Catalyst
> Semiconductor) are similar to the original M25Px0 chips, except:
>
> - Address width can vary (1-2 bytes, in contrast to 3 bytes in M25P
> chips). So, implement convenient m25p_addr2cmd() and m25p_cmdsz()
> calls, and place address width information into flash_info struct;
>
> - Page size can vary, therefore we shouldn't hardcode it, so get rid
> of FLASH_PAGESIZE definition, and place the page size information
> into flash_info struct;
>
> - CAT25 EEPROMs don't need to be erased, so add NO_ERASE flag, and
> propagate it to the mtd subsystem.
This patch (still) doesn't know about the mx25l3205d, mx25l12805d and
mx25l12855e devices.
I randomly did this:
-> { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, 256, 3, 0) },
-> { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, 256, 3, 0) },
{ "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 256, 3, 0) },
-> { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 256, 3, 0) },
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/2] mtd: m25p80: Add support for CAT25xxx serial EEPROMs
2009-09-22 23:25 ` Andrew Morton
(?)
@ 2009-09-22 23:40 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-09-22 23:40 UTC (permalink / raw)
To: Andrew Morton
Cc: dbrownell, dedekind1, linux-kernel, linuxppc-dev, linux-mtd,
Anton Vorontsov, dwmw2
On Tue, Sep 22, 2009 at 04:25:48PM -0700, Andrew Morton wrote:
> On Wed, 19 Aug 2009 01:46:28 +0400
> Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> > CAT25 chips (as manufactured by On Semiconductor, previously Catalyst
> > Semiconductor) are similar to the original M25Px0 chips, except:
> >
> > - Address width can vary (1-2 bytes, in contrast to 3 bytes in M25P
> > chips). So, implement convenient m25p_addr2cmd() and m25p_cmdsz()
> > calls, and place address width information into flash_info struct;
> >
> > - Page size can vary, therefore we shouldn't hardcode it, so get rid
> > of FLASH_PAGESIZE definition, and place the page size information
> > into flash_info struct;
> >
> > - CAT25 EEPROMs don't need to be erased, so add NO_ERASE flag, and
> > propagate it to the mtd subsystem.
>
> This patch (still) doesn't know about the mx25l3205d, mx25l12805d and
> mx25l12855e devices.
Yes, support for these chips commited on Fri, 4 Sep 2009 08:40:27
+0000 (09:40 +0100). And the patch dated 19 Aug.
> I randomly did this:
>
> -> { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, 256, 3, 0) },
> -> { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, 256, 3, 0) },
> { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 256, 3, 0) },
> -> { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 256, 3, 0) },
Looks correct, thanks a lot.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/2] mtd: m25p80: Add support for CAT25xxx serial EEPROMs
@ 2009-09-22 23:40 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-09-22 23:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Anton Vorontsov, dbrownell, dwmw2, dedekind1, linux-mtd,
linux-kernel, linuxppc-dev
On Tue, Sep 22, 2009 at 04:25:48PM -0700, Andrew Morton wrote:
> On Wed, 19 Aug 2009 01:46:28 +0400
> Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> > CAT25 chips (as manufactured by On Semiconductor, previously Catalyst
> > Semiconductor) are similar to the original M25Px0 chips, except:
> >
> > - Address width can vary (1-2 bytes, in contrast to 3 bytes in M25P
> > chips). So, implement convenient m25p_addr2cmd() and m25p_cmdsz()
> > calls, and place address width information into flash_info struct;
> >
> > - Page size can vary, therefore we shouldn't hardcode it, so get rid
> > of FLASH_PAGESIZE definition, and place the page size information
> > into flash_info struct;
> >
> > - CAT25 EEPROMs don't need to be erased, so add NO_ERASE flag, and
> > propagate it to the mtd subsystem.
>
> This patch (still) doesn't know about the mx25l3205d, mx25l12805d and
> mx25l12855e devices.
Yes, support for these chips commited on Fri, 4 Sep 2009 08:40:27
+0000 (09:40 +0100). And the patch dated 19 Aug.
> I randomly did this:
>
> -> { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, 256, 3, 0) },
> -> { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, 256, 3, 0) },
> { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 256, 3, 0) },
> -> { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 256, 3, 0) },
Looks correct, thanks a lot.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/2] mtd: m25p80: Add support for CAT25xxx serial EEPROMs
@ 2009-09-22 23:40 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-09-22 23:40 UTC (permalink / raw)
To: Andrew Morton
Cc: dbrownell, dedekind1, linux-kernel, linuxppc-dev, linux-mtd,
dwmw2
On Tue, Sep 22, 2009 at 04:25:48PM -0700, Andrew Morton wrote:
> On Wed, 19 Aug 2009 01:46:28 +0400
> Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> > CAT25 chips (as manufactured by On Semiconductor, previously Catalyst
> > Semiconductor) are similar to the original M25Px0 chips, except:
> >
> > - Address width can vary (1-2 bytes, in contrast to 3 bytes in M25P
> > chips). So, implement convenient m25p_addr2cmd() and m25p_cmdsz()
> > calls, and place address width information into flash_info struct;
> >
> > - Page size can vary, therefore we shouldn't hardcode it, so get rid
> > of FLASH_PAGESIZE definition, and place the page size information
> > into flash_info struct;
> >
> > - CAT25 EEPROMs don't need to be erased, so add NO_ERASE flag, and
> > propagate it to the mtd subsystem.
>
> This patch (still) doesn't know about the mx25l3205d, mx25l12805d and
> mx25l12855e devices.
Yes, support for these chips commited on Fri, 4 Sep 2009 08:40:27
+0000 (09:40 +0100). And the patch dated 19 Aug.
> I randomly did this:
>
> -> { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, 256, 3, 0) },
> -> { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, 256, 3, 0) },
> { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 256, 3, 0) },
> -> { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 256, 3, 0) },
Looks correct, thanks a lot.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
2009-08-04 2:54 ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table David Brownell
(?)
@ 2009-09-22 21:17 ` Andrew Morton
-1 siblings, 0 replies; 131+ messages in thread
From: Andrew Morton @ 2009-09-22 21:17 UTC (permalink / raw)
To: David Brownell
Cc: ben, benh, linux-kernel, lm-sensors, grant.likely, linuxppc-dev,
linux-mtd, khali, avorontsov, dwmw2
On Mon, 3 Aug 2009 19:54:50 -0700
David Brownell <david-b@pacbell.net> wrote:
> On Thursday 30 July 2009, Anton Vorontsov wrote:
> > This patch converts the m25p80 driver so that now it uses .id_table
> > for device matching, making it properly detect devices on OpenFirmware
> > platforms (prior to this patch the driver misdetected non-JEDEC chips,
> > seeing all chips as "m25p80").
>
> I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
> All others got explicit declarations ... so if there's misbehavior for
> other chips, it's because those declarations were poorly handled. Maybe
> they were not properly flagged as non-JDEC
>
>
> > Also, now jedec_probe() only does jedec probing, nothing else. If it
> > is not able to detect a chip, NULL is returned and the driver fall
> > backs to the information specified by the platform (platform_data, or
> > exact ID).
>
> I'd rather keep the warning, so there's a clue about what's really
> going on: JEDEC chip found, but its ID is not handled.
>
afaik there was no response to David's review comments, so this patch
is in the "stuck" state.
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> > drivers/mtd/devices/m25p80.c | 146 +++++++++++++++++++++++-------------------
> > 1 files changed, 80 insertions(+), 66 deletions(-)
> >
> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> > index 10ed195..0d74b38 100644
> > --- a/drivers/mtd/devices/m25p80.c
> > +++ b/drivers/mtd/devices/m25p80.c
> > ... deletia ...
>
> > @@ -481,74 +480,83 @@ struct flash_info {
> > #define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
> > };
> >
> > +#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
> > + ((kernel_ulong_t)&(struct flash_info) { \
> > + .jedec_id = (_jedec_id), \
> > + .ext_id = (_ext_id), \
> > + .sector_size = (_sector_size), \
> > + .n_sectors = (_n_sectors), \
> > + .flags = (_flags), \
> > + })
>
> Anonymous inlined structures ... kind of ugly, but I can
> understand why you might not want to declare and name a
> few dozen single-use structures.
>
>
> >
> > /* NOTE: double check command sets and memory organization when you add
> > * more flash chips. This current list focusses on newer chips, which
> > * have been converging on command sets which including JEDEC ID.
> > */
> > -static struct flash_info __devinitdata m25p_data [] = {
> > -
> > +static const struct spi_device_id m25p_ids[] = {
> > /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> > - { "at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
> > - { "at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
> > + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
> > + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
> >
> > ... deletia ...
> >
>
> > @@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
> > */
> > static int __devinit m25p_probe(struct spi_device *spi)
> > {
> > + const struct spi_device_id *id;
> > struct flash_platform_data *data;
> > struct m25p *flash;
> > struct flash_info *info;
> > @@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
> > */
> > data = spi->dev.platform_data;
> > if (data && data->type) {
>
> At this point I wonder why you're not changing the probe sequence
> more. Get "id" and then "id" here. If it's for "m25p80" assume
> it's an old-style board init and do the current logic. Else just
> verify "info".
>
> There's a new error case of course: new-style but data->type
> doesn't match id->name.
>
>
> > - for (i = 0, info = m25p_data;
> > - i < ARRAY_SIZE(m25p_data);
> > - i++, info++) {
> > - if (strcmp(data->type, info->name) == 0)
> > - break;
> > + for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
> > + id = &m25p_ids[i];
> > + info = (void *)m25p_ids[i].driver_data;
> > + if (strcmp(data->type, id->name))
> > + continue;
> > + break;
> > }
> >
> > /* unrecognized chip? */
> > - if (i == ARRAY_SIZE(m25p_data)) {
> > + if (i == ARRAY_SIZE(m25p_ids) - 1) {
>
> Better: "if (info == NULL) ..." You've got all the pointers
> in hand; don't use indices.
>
> > DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
> > dev_name(&spi->dev), data->type);
> > info = NULL;
> >
> > /* recognized; is that chip really what's there? */
> > } else if (info->jedec_id) {
> > - struct flash_info *chip = jedec_probe(spi);
> > + id = jedec_probe(spi);
> >
> > - if (!chip || chip != info) {
> > + if (id != &m25p_ids[i]) {
>
> Again, don't use indices except during the lookup.
>
> > dev_warn(&spi->dev, "found %s, expected %s\n",
> > - chip ? chip->name : "UNKNOWN",
> > - info->name);
> > + id ? id->name : "UNKNOWN",
> > + m25p_ids[i].name);
> > info = NULL;
> > }
> > }
> > - } else
> > - info = jedec_probe(spi);
> > + } else {
> > + id = jedec_probe(spi);
> > + if (!id)
> > + id = spi_get_device_id(spi);
> > +
> > + info = (void *)id->driver_data;
> > + }
> >
> > if (!info)
> > return -ENODEV;
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-22 21:17 ` Andrew Morton
0 siblings, 0 replies; 131+ messages in thread
From: Andrew Morton @ 2009-09-22 21:17 UTC (permalink / raw)
To: David Brownell
Cc: avorontsov, ben, dwmw2, grant.likely, benh, khali, linux-mtd,
linux-kernel, lm-sensors, linuxppc-dev
On Mon, 3 Aug 2009 19:54:50 -0700
David Brownell <david-b@pacbell.net> wrote:
> On Thursday 30 July 2009, Anton Vorontsov wrote:
> > This patch converts the m25p80 driver so that now it uses .id_table
> > for device matching, making it properly detect devices on OpenFirmware
> > platforms (prior to this patch the driver misdetected non-JEDEC chips,
> > seeing all chips as "m25p80").
>
> I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
> All others got explicit declarations ... so if there's misbehavior for
> other chips, it's because those declarations were poorly handled. Maybe
> they were not properly flagged as non-JDEC
>
>
> > Also, now jedec_probe() only does jedec probing, nothing else. If it
> > is not able to detect a chip, NULL is returned and the driver fall
> > backs to the information specified by the platform (platform_data, or
> > exact ID).
>
> I'd rather keep the warning, so there's a clue about what's really
> going on: JEDEC chip found, but its ID is not handled.
>
afaik there was no response to David's review comments, so this patch
is in the "stuck" state.
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> > drivers/mtd/devices/m25p80.c | 146 +++++++++++++++++++++++-------------------
> > 1 files changed, 80 insertions(+), 66 deletions(-)
> >
> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> > index 10ed195..0d74b38 100644
> > --- a/drivers/mtd/devices/m25p80.c
> > +++ b/drivers/mtd/devices/m25p80.c
> > ... deletia ...
>
> > @@ -481,74 +480,83 @@ struct flash_info {
> > #define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
> > };
> >
> > +#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
> > + ((kernel_ulong_t)&(struct flash_info) { \
> > + .jedec_id = (_jedec_id), \
> > + .ext_id = (_ext_id), \
> > + .sector_size = (_sector_size), \
> > + .n_sectors = (_n_sectors), \
> > + .flags = (_flags), \
> > + })
>
> Anonymous inlined structures ... kind of ugly, but I can
> understand why you might not want to declare and name a
> few dozen single-use structures.
>
>
> >
> > /* NOTE: double check command sets and memory organization when you add
> > * more flash chips. This current list focusses on newer chips, which
> > * have been converging on command sets which including JEDEC ID.
> > */
> > -static struct flash_info __devinitdata m25p_data [] = {
> > -
> > +static const struct spi_device_id m25p_ids[] = {
> > /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> > - { "at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
> > - { "at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
> > + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
> > + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
> >
> > ... deletia ...
> >
>
> > @@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
> > */
> > static int __devinit m25p_probe(struct spi_device *spi)
> > {
> > + const struct spi_device_id *id;
> > struct flash_platform_data *data;
> > struct m25p *flash;
> > struct flash_info *info;
> > @@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
> > */
> > data = spi->dev.platform_data;
> > if (data && data->type) {
>
> At this point I wonder why you're not changing the probe sequence
> more. Get "id" and then "id" here. If it's for "m25p80" assume
> it's an old-style board init and do the current logic. Else just
> verify "info".
>
> There's a new error case of course: new-style but data->type
> doesn't match id->name.
>
>
> > - for (i = 0, info = m25p_data;
> > - i < ARRAY_SIZE(m25p_data);
> > - i++, info++) {
> > - if (strcmp(data->type, info->name) == 0)
> > - break;
> > + for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
> > + id = &m25p_ids[i];
> > + info = (void *)m25p_ids[i].driver_data;
> > + if (strcmp(data->type, id->name))
> > + continue;
> > + break;
> > }
> >
> > /* unrecognized chip? */
> > - if (i == ARRAY_SIZE(m25p_data)) {
> > + if (i == ARRAY_SIZE(m25p_ids) - 1) {
>
> Better: "if (info == NULL) ..." You've got all the pointers
> in hand; don't use indices.
>
> > DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
> > dev_name(&spi->dev), data->type);
> > info = NULL;
> >
> > /* recognized; is that chip really what's there? */
> > } else if (info->jedec_id) {
> > - struct flash_info *chip = jedec_probe(spi);
> > + id = jedec_probe(spi);
> >
> > - if (!chip || chip != info) {
> > + if (id != &m25p_ids[i]) {
>
> Again, don't use indices except during the lookup.
>
> > dev_warn(&spi->dev, "found %s, expected %s\n",
> > - chip ? chip->name : "UNKNOWN",
> > - info->name);
> > + id ? id->name : "UNKNOWN",
> > + m25p_ids[i].name);
> > info = NULL;
> > }
> > }
> > - } else
> > - info = jedec_probe(spi);
> > + } else {
> > + id = jedec_probe(spi);
> > + if (!id)
> > + id = spi_get_device_id(spi);
> > +
> > + info = (void *)id->driver_data;
> > + }
> >
> > if (!info)
> > return -ENODEV;
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-22 21:17 ` Andrew Morton
0 siblings, 0 replies; 131+ messages in thread
From: Andrew Morton @ 2009-09-22 21:17 UTC (permalink / raw)
To: David Brownell
Cc: ben, linux-kernel, lm-sensors, linuxppc-dev, linux-mtd, khali,
dwmw2
On Mon, 3 Aug 2009 19:54:50 -0700
David Brownell <david-b@pacbell.net> wrote:
> On Thursday 30 July 2009, Anton Vorontsov wrote:
> > This patch converts the m25p80 driver so that now it uses .id_table
> > for device matching, making it properly detect devices on OpenFirmware
> > platforms (prior to this patch the driver misdetected non-JEDEC chips,
> > seeing all chips as "m25p80").
>
> I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
> All others got explicit declarations ... so if there's misbehavior for
> other chips, it's because those declarations were poorly handled. Maybe
> they were not properly flagged as non-JDEC
>
>
> > Also, now jedec_probe() only does jedec probing, nothing else. If it
> > is not able to detect a chip, NULL is returned and the driver fall
> > backs to the information specified by the platform (platform_data, or
> > exact ID).
>
> I'd rather keep the warning, so there's a clue about what's really
> going on: JEDEC chip found, but its ID is not handled.
>
afaik there was no response to David's review comments, so this patch
is in the "stuck" state.
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> > drivers/mtd/devices/m25p80.c | 146 +++++++++++++++++++++++-------------------
> > 1 files changed, 80 insertions(+), 66 deletions(-)
> >
> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> > index 10ed195..0d74b38 100644
> > --- a/drivers/mtd/devices/m25p80.c
> > +++ b/drivers/mtd/devices/m25p80.c
> > ... deletia ...
>
> > @@ -481,74 +480,83 @@ struct flash_info {
> > #define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
> > };
> >
> > +#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
> > + ((kernel_ulong_t)&(struct flash_info) { \
> > + .jedec_id = (_jedec_id), \
> > + .ext_id = (_ext_id), \
> > + .sector_size = (_sector_size), \
> > + .n_sectors = (_n_sectors), \
> > + .flags = (_flags), \
> > + })
>
> Anonymous inlined structures ... kind of ugly, but I can
> understand why you might not want to declare and name a
> few dozen single-use structures.
>
>
> >
> > /* NOTE: double check command sets and memory organization when you add
> > * more flash chips. This current list focusses on newer chips, which
> > * have been converging on command sets which including JEDEC ID.
> > */
> > -static struct flash_info __devinitdata m25p_data [] = {
> > -
> > +static const struct spi_device_id m25p_ids[] = {
> > /* Atmel -- some are (confusingly) marketed as "DataFlash" */
> > - { "at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
> > - { "at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
> > + { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
> > + { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
> >
> > ... deletia ...
> >
>
> > @@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
> > */
> > static int __devinit m25p_probe(struct spi_device *spi)
> > {
> > + const struct spi_device_id *id;
> > struct flash_platform_data *data;
> > struct m25p *flash;
> > struct flash_info *info;
> > @@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
> > */
> > data = spi->dev.platform_data;
> > if (data && data->type) {
>
> At this point I wonder why you're not changing the probe sequence
> more. Get "id" and then "id" here. If it's for "m25p80" assume
> it's an old-style board init and do the current logic. Else just
> verify "info".
>
> There's a new error case of course: new-style but data->type
> doesn't match id->name.
>
>
> > - for (i = 0, info = m25p_data;
> > - i < ARRAY_SIZE(m25p_data);
> > - i++, info++) {
> > - if (strcmp(data->type, info->name) == 0)
> > - break;
> > + for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
> > + id = &m25p_ids[i];
> > + info = (void *)m25p_ids[i].driver_data;
> > + if (strcmp(data->type, id->name))
> > + continue;
> > + break;
> > }
> >
> > /* unrecognized chip? */
> > - if (i == ARRAY_SIZE(m25p_data)) {
> > + if (i == ARRAY_SIZE(m25p_ids) - 1) {
>
> Better: "if (info == NULL) ..." You've got all the pointers
> in hand; don't use indices.
>
> > DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
> > dev_name(&spi->dev), data->type);
> > info = NULL;
> >
> > /* recognized; is that chip really what's there? */
> > } else if (info->jedec_id) {
> > - struct flash_info *chip = jedec_probe(spi);
> > + id = jedec_probe(spi);
> >
> > - if (!chip || chip != info) {
> > + if (id != &m25p_ids[i]) {
>
> Again, don't use indices except during the lookup.
>
> > dev_warn(&spi->dev, "found %s, expected %s\n",
> > - chip ? chip->name : "UNKNOWN",
> > - info->name);
> > + id ? id->name : "UNKNOWN",
> > + m25p_ids[i].name);
> > info = NULL;
> > }
> > }
> > - } else
> > - info = jedec_probe(spi);
> > + } else {
> > + id = jedec_probe(spi);
> > + if (!id)
> > + id = spi_get_device_id(spi);
> > +
> > + info = (void *)id->driver_data;
> > + }
> >
> > if (!info)
> > return -ENODEV;
>
^ permalink raw reply [flat|nested] 131+ messages in thread* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
2009-09-22 21:17 ` Andrew Morton
(?)
@ 2009-09-22 23:01 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-09-22 23:01 UTC (permalink / raw)
To: Andrew Morton
Cc: ben, benh, linux-kernel, grant.likely, lm-sensors, David Brownell,
linuxppc-dev, linux-mtd, khali, dwmw2
On Tue, Sep 22, 2009 at 02:17:05PM -0700, Andrew Morton wrote:
> On Mon, 3 Aug 2009 19:54:50 -0700
> David Brownell <david-b@pacbell.net> wrote:
>
> > On Thursday 30 July 2009, Anton Vorontsov wrote:
> > > This patch converts the m25p80 driver so that now it uses .id_table
> > > for device matching, making it properly detect devices on OpenFirmware
> > > platforms (prior to this patch the driver misdetected non-JEDEC chips,
> > > seeing all chips as "m25p80").
> >
> > I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
> > All others got explicit declarations ... so if there's misbehavior for
> > other chips, it's because those declarations were poorly handled. Maybe
> > they were not properly flagged as non-JDEC
> >
> >
> > > Also, now jedec_probe() only does jedec probing, nothing else. If it
> > > is not able to detect a chip, NULL is returned and the driver fall
> > > backs to the information specified by the platform (platform_data, or
> > > exact ID).
> >
> > I'd rather keep the warning, so there's a clue about what's really
> > going on: JEDEC chip found, but its ID is not handled.
> >
>
> afaik there was no response to David's review comments, so this patch
> is in the "stuck" state.
Hm? Response:
http://lkml.org/lkml/2009/8/18/363
And the two patches I sent on top:
http://lkml.org/lkml/2009/8/18/364
http://lkml.org/lkml/2009/8/18/366
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-22 23:01 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-09-22 23:01 UTC (permalink / raw)
To: Andrew Morton
Cc: David Brownell, ben, dwmw2, grant.likely, benh, khali, linux-mtd,
linux-kernel, lm-sensors, linuxppc-dev
On Tue, Sep 22, 2009 at 02:17:05PM -0700, Andrew Morton wrote:
> On Mon, 3 Aug 2009 19:54:50 -0700
> David Brownell <david-b@pacbell.net> wrote:
>
> > On Thursday 30 July 2009, Anton Vorontsov wrote:
> > > This patch converts the m25p80 driver so that now it uses .id_table
> > > for device matching, making it properly detect devices on OpenFirmware
> > > platforms (prior to this patch the driver misdetected non-JEDEC chips,
> > > seeing all chips as "m25p80").
> >
> > I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
> > All others got explicit declarations ... so if there's misbehavior for
> > other chips, it's because those declarations were poorly handled. Maybe
> > they were not properly flagged as non-JDEC
> >
> >
> > > Also, now jedec_probe() only does jedec probing, nothing else. If it
> > > is not able to detect a chip, NULL is returned and the driver fall
> > > backs to the information specified by the platform (platform_data, or
> > > exact ID).
> >
> > I'd rather keep the warning, so there's a clue about what's really
> > going on: JEDEC chip found, but its ID is not handled.
> >
>
> afaik there was no response to David's review comments, so this patch
> is in the "stuck" state.
Hm? Response:
http://lkml.org/lkml/2009/8/18/363
And the two patches I sent on top:
http://lkml.org/lkml/2009/8/18/364
http://lkml.org/lkml/2009/8/18/366
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-22 23:01 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-09-22 23:01 UTC (permalink / raw)
To: Andrew Morton
Cc: ben, linux-kernel, lm-sensors, David Brownell, linuxppc-dev,
linux-mtd, khali, dwmw2
On Tue, Sep 22, 2009 at 02:17:05PM -0700, Andrew Morton wrote:
> On Mon, 3 Aug 2009 19:54:50 -0700
> David Brownell <david-b@pacbell.net> wrote:
>
> > On Thursday 30 July 2009, Anton Vorontsov wrote:
> > > This patch converts the m25p80 driver so that now it uses .id_table
> > > for device matching, making it properly detect devices on OpenFirmware
> > > platforms (prior to this patch the driver misdetected non-JEDEC chips,
> > > seeing all chips as "m25p80").
> >
> > I suspect "detect" is a misnomer there. It only "detects" JEDEC chips.
> > All others got explicit declarations ... so if there's misbehavior for
> > other chips, it's because those declarations were poorly handled. Maybe
> > they were not properly flagged as non-JDEC
> >
> >
> > > Also, now jedec_probe() only does jedec probing, nothing else. If it
> > > is not able to detect a chip, NULL is returned and the driver fall
> > > backs to the information specified by the platform (platform_data, or
> > > exact ID).
> >
> > I'd rather keep the warning, so there's a clue about what's really
> > going on: JEDEC chip found, but its ID is not handled.
> >
>
> afaik there was no response to David's review comments, so this patch
> is in the "stuck" state.
Hm? Response:
http://lkml.org/lkml/2009/8/18/363
And the two patches I sent on top:
http://lkml.org/lkml/2009/8/18/364
http://lkml.org/lkml/2009/8/18/366
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
2009-09-22 23:01 ` Anton Vorontsov
(?)
@ 2009-09-22 23:43 ` David Woodhouse
-1 siblings, 0 replies; 131+ messages in thread
From: David Woodhouse @ 2009-09-22 23:43 UTC (permalink / raw)
To: avorontsov
Cc: ben, benh, linux-kernel, grant.likely, lm-sensors, David Brownell,
linuxppc-dev, linux-mtd, khali, Andrew Morton
On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
>
> And the two patches I sent on top:
>
> http://lkml.org/lkml/2009/8/18/364
> http://lkml.org/lkml/2009/8/18/366
Got versions of those which apply to the mtd-2.6.git tree (which I'm
about to ask Linus to pull)?
--
dwmw2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-22 23:43 ` David Woodhouse
0 siblings, 0 replies; 131+ messages in thread
From: David Woodhouse @ 2009-09-22 23:43 UTC (permalink / raw)
To: avorontsov
Cc: Andrew Morton, David Brownell, ben, grant.likely, benh, khali,
linux-mtd, linux-kernel, lm-sensors, linuxppc-dev
On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
>
> And the two patches I sent on top:
>
> http://lkml.org/lkml/2009/8/18/364
> http://lkml.org/lkml/2009/8/18/366
Got versions of those which apply to the mtd-2.6.git tree (which I'm
about to ask Linus to pull)?
--
dwmw2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-22 23:43 ` David Woodhouse
0 siblings, 0 replies; 131+ messages in thread
From: David Woodhouse @ 2009-09-22 23:43 UTC (permalink / raw)
To: avorontsov
Cc: ben, linux-kernel, lm-sensors, David Brownell, linuxppc-dev,
linux-mtd, khali, Andrew Morton
On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
>
> And the two patches I sent on top:
>
> http://lkml.org/lkml/2009/8/18/364
> http://lkml.org/lkml/2009/8/18/366
Got versions of those which apply to the mtd-2.6.git tree (which I'm
about to ask Linus to pull)?
--
dwmw2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
2009-09-22 23:43 ` David Woodhouse
(?)
@ 2009-09-22 23:52 ` Andrew Morton
-1 siblings, 0 replies; 131+ messages in thread
From: Andrew Morton @ 2009-09-22 23:52 UTC (permalink / raw)
To: David Woodhouse
Cc: ben, benh, linux-kernel, grant.likely, lm-sensors, david-b,
linuxppc-dev, linux-mtd, khali, avorontsov
On Tue, 22 Sep 2009 16:43:47 -0700
David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
> >
> > And the two patches I sent on top:
> >
> > http://lkml.org/lkml/2009/8/18/364
> > http://lkml.org/lkml/2009/8/18/366
>
> Got versions of those which apply to the mtd-2.6.git tree (which I'm
> about to ask Linus to pull)?
>
I'll send them in a sec.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-22 23:52 ` Andrew Morton
0 siblings, 0 replies; 131+ messages in thread
From: Andrew Morton @ 2009-09-22 23:52 UTC (permalink / raw)
To: David Woodhouse
Cc: avorontsov, david-b, ben, grant.likely, benh, khali, linux-mtd,
linux-kernel, lm-sensors, linuxppc-dev
On Tue, 22 Sep 2009 16:43:47 -0700
David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
> >
> > And the two patches I sent on top:
> >
> > http://lkml.org/lkml/2009/8/18/364
> > http://lkml.org/lkml/2009/8/18/366
>
> Got versions of those which apply to the mtd-2.6.git tree (which I'm
> about to ask Linus to pull)?
>
I'll send them in a sec.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-22 23:52 ` Andrew Morton
0 siblings, 0 replies; 131+ messages in thread
From: Andrew Morton @ 2009-09-22 23:52 UTC (permalink / raw)
To: David Woodhouse
Cc: ben, linux-kernel, lm-sensors, david-b, linuxppc-dev, linux-mtd,
khali
On Tue, 22 Sep 2009 16:43:47 -0700
David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
> >
> > And the two patches I sent on top:
> >
> > http://lkml.org/lkml/2009/8/18/364
> > http://lkml.org/lkml/2009/8/18/366
>
> Got versions of those which apply to the mtd-2.6.git tree (which I'm
> about to ask Linus to pull)?
>
I'll send them in a sec.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
2009-09-22 23:43 ` David Woodhouse
(?)
@ 2009-09-22 23:55 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-09-22 23:55 UTC (permalink / raw)
To: David Woodhouse
Cc: ben, benh, linux-kernel, grant.likely, lm-sensors, David Brownell,
linuxppc-dev, linux-mtd, khali, Andrew Morton, avorontsov
On Tue, Sep 22, 2009 at 04:43:47PM -0700, David Woodhouse wrote:
> On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
> >
> > And the two patches I sent on top:
> >
> > http://lkml.org/lkml/2009/8/18/364
> > http://lkml.org/lkml/2009/8/18/366
>
> Got versions of those which apply to the mtd-2.6.git tree (which I'm
> about to ask Linus to pull)?
I'd love to, but they depend on a bunch of SPI patches that are still
in -mm tree. As soon as SPI core changes hit Linus' tree, I think
Andrew will send all m25p80 patches to you anyway.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-22 23:55 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-09-22 23:55 UTC (permalink / raw)
To: David Woodhouse
Cc: avorontsov, Andrew Morton, David Brownell, ben, grant.likely,
benh, khali, linux-mtd, linux-kernel, lm-sensors, linuxppc-dev
On Tue, Sep 22, 2009 at 04:43:47PM -0700, David Woodhouse wrote:
> On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
> >
> > And the two patches I sent on top:
> >
> > http://lkml.org/lkml/2009/8/18/364
> > http://lkml.org/lkml/2009/8/18/366
>
> Got versions of those which apply to the mtd-2.6.git tree (which I'm
> about to ask Linus to pull)?
I'd love to, but they depend on a bunch of SPI patches that are still
in -mm tree. As soon as SPI core changes hit Linus' tree, I think
Andrew will send all m25p80 patches to you anyway.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-22 23:55 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-09-22 23:55 UTC (permalink / raw)
To: David Woodhouse
Cc: ben, linux-kernel, lm-sensors, David Brownell, linuxppc-dev,
linux-mtd, khali, Andrew Morton
On Tue, Sep 22, 2009 at 04:43:47PM -0700, David Woodhouse wrote:
> On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
> >
> > And the two patches I sent on top:
> >
> > http://lkml.org/lkml/2009/8/18/364
> > http://lkml.org/lkml/2009/8/18/366
>
> Got versions of those which apply to the mtd-2.6.git tree (which I'm
> about to ask Linus to pull)?
I'd love to, but they depend on a bunch of SPI patches that are still
in -mm tree. As soon as SPI core changes hit Linus' tree, I think
Andrew will send all m25p80 patches to you anyway.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
2009-09-22 23:55 ` Anton Vorontsov
(?)
@ 2009-09-23 0:02 ` Andrew Morton
-1 siblings, 0 replies; 131+ messages in thread
From: Andrew Morton @ 2009-09-23 0:02 UTC (permalink / raw)
To: avorontsov
Cc: ben, benh, linux-kernel, grant.likely, lm-sensors, david-b,
linuxppc-dev, linux-mtd, cbouatmailru, khali, dwmw2
On Wed, 23 Sep 2009 03:55:34 +0400
Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Tue, Sep 22, 2009 at 04:43:47PM -0700, David Woodhouse wrote:
> > On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
> > >
> > > And the two patches I sent on top:
> > >
> > > http://lkml.org/lkml/2009/8/18/364
> > > http://lkml.org/lkml/2009/8/18/366
> >
> > Got versions of those which apply to the mtd-2.6.git tree (which I'm
> > about to ask Linus to pull)?
>
> I'd love to, but they depend on a bunch of SPI patches that are still
> in -mm tree.
oh, is that why I queued them up where I did. Sigh.
> As soon as SPI core changes hit Linus' tree, I think
> Andrew will send all m25p80 patches to you anyway.
Or David can ack them and I'll send 'em up.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-23 0:02 ` Andrew Morton
0 siblings, 0 replies; 131+ messages in thread
From: Andrew Morton @ 2009-09-23 0:02 UTC (permalink / raw)
To: avorontsov
Cc: cbouatmailru, dwmw2, david-b, ben, grant.likely, benh, khali,
linux-mtd, linux-kernel, lm-sensors, linuxppc-dev
On Wed, 23 Sep 2009 03:55:34 +0400
Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Tue, Sep 22, 2009 at 04:43:47PM -0700, David Woodhouse wrote:
> > On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
> > >
> > > And the two patches I sent on top:
> > >
> > > http://lkml.org/lkml/2009/8/18/364
> > > http://lkml.org/lkml/2009/8/18/366
> >
> > Got versions of those which apply to the mtd-2.6.git tree (which I'm
> > about to ask Linus to pull)?
>
> I'd love to, but they depend on a bunch of SPI patches that are still
> in -mm tree.
oh, is that why I queued them up where I did. Sigh.
> As soon as SPI core changes hit Linus' tree, I think
> Andrew will send all m25p80 patches to you anyway.
Or David can ack them and I'll send 'em up.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-09-23 0:02 ` Andrew Morton
0 siblings, 0 replies; 131+ messages in thread
From: Andrew Morton @ 2009-09-23 0:02 UTC (permalink / raw)
To: avorontsov
Cc: ben, linux-kernel, lm-sensors, david-b, linuxppc-dev, linux-mtd,
khali, dwmw2
On Wed, 23 Sep 2009 03:55:34 +0400
Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Tue, Sep 22, 2009 at 04:43:47PM -0700, David Woodhouse wrote:
> > On Wed, 2009-09-23 at 03:01 +0400, Anton Vorontsov wrote:
> > >
> > > And the two patches I sent on top:
> > >
> > > http://lkml.org/lkml/2009/8/18/364
> > > http://lkml.org/lkml/2009/8/18/366
> >
> > Got versions of those which apply to the mtd-2.6.git tree (which I'm
> > about to ask Linus to pull)?
>
> I'd love to, but they depend on a bunch of SPI patches that are still
> in -mm tree.
oh, is that why I queued them up where I did. Sigh.
> As soon as SPI core changes hit Linus' tree, I think
> Andrew will send all m25p80 patches to you anyway.
Or David can ack them and I'll send 'em up.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
2009-07-31 0:41 ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table Anton Vorontsov
(?)
(?)
@ 2009-08-12 20:45 ` Michael Barkowski
-1 siblings, 0 replies; 131+ messages in thread
From: Michael Barkowski @ 2009-08-12 20:45 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ben Dooks, David Brownell, Benjamin Herrenschmidt, linux-kernel,
lm-sensors, Grant Likely, linuxppc-dev, linux-mtd, Jean Delvare,
Andrew Morton, David Woodhouse
Hello Anton,
Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
Then shouldn't you have the following change as well, near the end of
the function?
- } else if (data->nr_parts)
+ } else if (data && data->nr_parts)
dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
data->nr_parts, data->name);
Or am I misunderstanding something?
--
Michael Barkowski
RuggedCom
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-08-12 20:45 ` Michael Barkowski
0 siblings, 0 replies; 131+ messages in thread
From: Michael Barkowski @ 2009-08-12 20:45 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-mtd, lm-sensors, linuxppc-dev
Hello Anton,
Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
Then shouldn't you have the following change as well, near the end of
the function?
- } else if (data->nr_parts)
+ } else if (data && data->nr_parts)
dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
data->nr_parts, data->name);
Or am I misunderstanding something?
--
Michael Barkowski
RuggedCom
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-08-12 20:45 ` Michael Barkowski
0 siblings, 0 replies; 131+ messages in thread
From: Michael Barkowski @ 2009-08-12 20:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, linux-mtd, linux-kernel, lm-sensors
Hello Anton,
Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
Then shouldn't you have the following change as well, near the end of
the function?
- } else if (data->nr_parts)
+ } else if (data && data->nr_parts)
dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
data->nr_parts, data->name);
Or am I misunderstanding something?
--
Michael Barkowski
RuggedCom
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table
@ 2009-08-12 20:45 ` Michael Barkowski
0 siblings, 0 replies; 131+ messages in thread
From: Michael Barkowski @ 2009-08-12 20:45 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-mtd, lm-sensors, linuxppc-dev
Hello Anton,
Is m25p_probe now valid with dev.platform_data = NULL, for of platforms?
Then shouldn't you have the following change as well, near the end of
the function?
- } else if (data->nr_parts)
+ } else if (data && data->nr_parts)
dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
data->nr_parts, data->name);
Or am I misunderstanding something?
--
Michael Barkowski
RuggedCom
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
2009-08-12 20:45 ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table Michael Barkowski
(?)
(?)
@ 2009-08-12 20:58 ` Anton Vorontsov
-1 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-12 20:58 UTC (permalink / raw)
To: Michael Barkowski
Cc: Ben Dooks, David Brownell, Benjamin Herrenschmidt, linux-kernel,
lm-sensors, Grant Likely, linuxppc-dev, linux-mtd, Jean Delvare,
Andrew Morton, David Woodhouse
On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
> Hello Anton,
>
> Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
>
> Then shouldn't you have the following change as well, near the end of
> the function?
>
> - } else if (data->nr_parts)
> + } else if (data && data->nr_parts)
> dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
> data->nr_parts, data->name);
>
> Or am I misunderstanding something?
Yeah, you missed this patch:
http://patchwork.kernel.org/patch/38179/
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-08-12 20:58 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-12 20:58 UTC (permalink / raw)
To: Michael Barkowski
Cc: Andrew Morton, Ben Dooks, David Brownell, David Woodhouse,
Grant Likely, Benjamin Herrenschmidt, Jean Delvare, linux-mtd,
linux-kernel, lm-sensors, linuxppc-dev
On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
> Hello Anton,
>
> Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
>
> Then shouldn't you have the following change as well, near the end of
> the function?
>
> - } else if (data->nr_parts)
> + } else if (data && data->nr_parts)
> dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
> data->nr_parts, data->name);
>
> Or am I misunderstanding something?
Yeah, you missed this patch:
http://patchwork.kernel.org/patch/38179/
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-08-12 20:58 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-12 20:58 UTC (permalink / raw)
To: Michael Barkowski
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, Andrew Morton, David Woodhouse
On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
> Hello Anton,
>
> Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
>
> Then shouldn't you have the following change as well, near the end of
> the function?
>
> - } else if (data->nr_parts)
> + } else if (data && data->nr_parts)
> dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
> data->nr_parts, data->name);
>
> Or am I misunderstanding something?
Yeah, you missed this patch:
http://patchwork.kernel.org/patch/38179/
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table
@ 2009-08-12 20:58 ` Anton Vorontsov
0 siblings, 0 replies; 131+ messages in thread
From: Anton Vorontsov @ 2009-08-12 20:58 UTC (permalink / raw)
To: Michael Barkowski
Cc: Andrew Morton, Ben Dooks, David Brownell, David Woodhouse,
Grant Likely, Benjamin Herrenschmidt, Jean Delvare, linux-mtd,
linux-kernel, lm-sensors, linuxppc-dev
On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
> Hello Anton,
>
> Is m25p_probe now valid with dev.platform_data = NULL, for of platforms?
>
> Then shouldn't you have the following change as well, near the end of
> the function?
>
> - } else if (data->nr_parts)
> + } else if (data && data->nr_parts)
> dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
> data->nr_parts, data->name);
>
> Or am I misunderstanding something?
Yeah, you missed this patch:
http://patchwork.kernel.org/patch/38179/
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
2009-08-12 20:58 ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table Anton Vorontsov
(?)
(?)
@ 2009-08-12 20:58 ` Michael Barkowski
-1 siblings, 0 replies; 131+ messages in thread
From: Michael Barkowski @ 2009-08-12 20:58 UTC (permalink / raw)
To: avorontsov
Cc: Ben Dooks, David Brownell, Benjamin Herrenschmidt, linux-kernel,
lm-sensors, Grant Likely, linuxppc-dev, linux-mtd, Jean Delvare,
Andrew Morton, David Woodhouse
Anton Vorontsov wrote:
> On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
>> Hello Anton,
>>
>> Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
>>
>> Then shouldn't you have the following change as well, near the end of
>> the function?
>>
>> - } else if (data->nr_parts)
>> + } else if (data && data->nr_parts)
>> dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
>> data->nr_parts, data->name);
>>
>> Or am I misunderstanding something?
>
> Yeah, you missed this patch:
> http://patchwork.kernel.org/patch/38179/
>
>
> Thanks,
>
Beautiful - thanks - sorry to interrupt
--
Michael Barkowski
905-482-4577
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-08-12 20:58 ` Michael Barkowski
0 siblings, 0 replies; 131+ messages in thread
From: Michael Barkowski @ 2009-08-12 20:58 UTC (permalink / raw)
To: avorontsov
Cc: Andrew Morton, Ben Dooks, David Brownell, David Woodhouse,
Grant Likely, Benjamin Herrenschmidt, Jean Delvare, linux-mtd,
linux-kernel, lm-sensors, linuxppc-dev
Anton Vorontsov wrote:
> On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
>> Hello Anton,
>>
>> Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
>>
>> Then shouldn't you have the following change as well, near the end of
>> the function?
>>
>> - } else if (data->nr_parts)
>> + } else if (data && data->nr_parts)
>> dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
>> data->nr_parts, data->name);
>>
>> Or am I misunderstanding something?
>
> Yeah, you missed this patch:
> http://patchwork.kernel.org/patch/38179/
>
>
> Thanks,
>
Beautiful - thanks - sorry to interrupt
--
Michael Barkowski
905-482-4577
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
@ 2009-08-12 20:58 ` Michael Barkowski
0 siblings, 0 replies; 131+ messages in thread
From: Michael Barkowski @ 2009-08-12 20:58 UTC (permalink / raw)
To: avorontsov
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, Andrew Morton, David Woodhouse
Anton Vorontsov wrote:
> On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
>> Hello Anton,
>>
>> Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
>>
>> Then shouldn't you have the following change as well, near the end of
>> the function?
>>
>> - } else if (data->nr_parts)
>> + } else if (data && data->nr_parts)
>> dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
>> data->nr_parts, data->name);
>>
>> Or am I misunderstanding something?
>
> Yeah, you missed this patch:
> http://patchwork.kernel.org/patch/38179/
>
>
> Thanks,
>
Beautiful - thanks - sorry to interrupt
--
Michael Barkowski
905-482-4577
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table
@ 2009-08-12 20:58 ` Michael Barkowski
0 siblings, 0 replies; 131+ messages in thread
From: Michael Barkowski @ 2009-08-12 20:58 UTC (permalink / raw)
To: avorontsov
Cc: Andrew Morton, Ben Dooks, David Brownell, David Woodhouse,
Grant Likely, Benjamin Herrenschmidt, Jean Delvare, linux-mtd,
linux-kernel, lm-sensors, linuxppc-dev
Anton Vorontsov wrote:
> On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
>> Hello Anton,
>>
>> Is m25p_probe now valid with dev.platform_data = NULL, for of platforms?
>>
>> Then shouldn't you have the following change as well, near the end of
>> the function?
>>
>> - } else if (data->nr_parts)
>> + } else if (data && data->nr_parts)
>> dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
>> data->nr_parts, data->name);
>>
>> Or am I misunderstanding something?
>
> Yeah, you missed this patch:
> http://patchwork.kernel.org/patch/38179/
>
>
> Thanks,
>
Beautiful - thanks - sorry to interrupt
--
Michael Barkowski
905-482-4577
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 131+ messages in thread