linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: David Brownell <david-b@pacbell.net>
Cc: ben@fluff.org, benh@kernel.crashing.org,
	linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org,
	grant.likely@secretlab.ca, linuxppc-dev@ozlabs.org,
	linux-mtd@lists.infradead.org, khali@linux-fr.org,
	avorontsov@ru.mvista.com, dwmw2@infradead.org
Subject: Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
Date: Tue, 22 Sep 2009 14:17:05 -0700	[thread overview]
Message-ID: <20090922141705.b5d31e24.akpm@linux-foundation.org> (raw)
In-Reply-To: <200908031954.50955.david-b@pacbell.net>

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;
> 

  parent reply	other threads:[~2009-09-22 21:18 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       ` [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code Anton Vorontsov
2010-06-12  6:27         ` 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     ` Andrew Morton [this message]
2009-09-22 23:01       ` [PATCH 2/6] mtd: m25p80: Convert to device table matching 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=20090922141705.b5d31e24.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=avorontsov@ru.mvista.com \
    --cc=ben@fluff.org \
    --cc=benh@kernel.crashing.org \
    --cc=david-b@pacbell.net \
    --cc=dwmw2@infradead.org \
    --cc=grant.likely@secretlab.ca \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=lm-sensors@lm-sensors.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).