linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
	linux-mtd@lists.infradead.org,
	David Woodhouse <dwmw2@infradead.org>
Subject: [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code
Date: Wed, 19 Aug 2009 01:46:22 +0400	[thread overview]
Message-ID: <20090818214622.GA22651@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20090818214449.GA12848@oksana.dev.rtsoft.ru>

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

  reply	other threads:[~2009-08-18 21:46 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-31  0:39 [PATCH v2 0/6] Device table matching for SPI subsystem Anton Vorontsov
2009-07-31  0:40 ` [PATCH 1/6] spi: Add support for device table matching Anton Vorontsov
2009-07-31  0:41 ` [PATCH 2/6] mtd: m25p80: Convert to " Anton Vorontsov
2009-08-04  2:54   ` David Brownell
2009-08-18 21:44     ` Anton Vorontsov
2009-08-18 21:46       ` Anton Vorontsov [this message]
2010-06-12  6:27         ` [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code Barry Song
2010-06-18 13:32           ` Anton Vorontsov
2010-06-21  2:42             ` [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code Song, Barry
2010-06-21  3:27               ` Barry Song
2010-06-21  7:15                 ` Anton Vorontsov
2010-06-21  7:22                   ` Barry Song
2010-06-21  7:39                     ` Anton Vorontsov
2010-06-21 10:31                       ` Barry Song
2010-06-21 11:20                         ` Anton Vorontsov
2010-06-21 16:34                           ` Mike Frysinger
2010-06-21 16:47                             ` Anton Vorontsov
2010-06-21 16:54                               ` Mike Frysinger
2010-06-22  6:37                           ` Barry Song
2010-06-22 16:55                             ` Anton Vorontsov
2010-06-22 16:57                               ` [PATCH 1/2] mtd: m25p80: Fix false-positive probing Anton Vorontsov
2010-06-22 17:56                                 ` Mike Frysinger
2010-07-08  5:57                                 ` Artem Bityutskiy
2010-06-22 16:57                               ` [PATCH 2/2] mtd: m25p80: Make jedec_probe() return proper errno values Anton Vorontsov
2009-08-18 21:46       ` [PATCH 2/2] mtd: m25p80: Add support for CAT25xxx serial EEPROMs Anton Vorontsov
2009-09-22 23:25         ` Andrew Morton
2009-09-22 23:40           ` Anton Vorontsov
2009-09-22 21:17     ` [PATCH 2/6] mtd: m25p80: Convert to device table matching Andrew Morton
2009-09-22 23:01       ` Anton Vorontsov
2009-09-22 23:43         ` David Woodhouse
2009-09-22 23:52           ` Andrew Morton
2009-09-22 23:55           ` Anton Vorontsov
2009-09-23  0:02             ` Andrew Morton
2009-08-12 20:45   ` Michael Barkowski
2009-08-12 20:58     ` Anton Vorontsov
2009-08-12 20:58       ` Michael Barkowski
2009-07-31  0:41 ` [PATCH 3/6] of: Remove "stm,m25p40" alias Anton Vorontsov
2009-07-31  0:41 ` [PATCH 4/6] hwmon: adxx: Convert to device table matching Anton Vorontsov
2009-07-31  0:41 ` [PATCH 5/6] hwmon: lm70: " Anton Vorontsov
2009-07-31  0:41 ` [PATCH 6/6] spi: Prefix modalias with "spi:" Anton Vorontsov
2009-08-10  7:35 ` [PATCH v2 0/6] Device table matching for SPI subsystem Artem Bityutskiy
2009-08-18 21:44   ` Anton Vorontsov
2009-08-25 14:14     ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090818214622.GA22651@oksana.dev.rtsoft.ru \
    --to=avorontsov@ru.mvista.com \
    --cc=akpm@linux-foundation.org \
    --cc=dbrownell@users.sourceforge.net \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).