All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ben Dooks <ben@fluff.org>, David Woodhouse <dwmw2@infradead.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Jean Delvare <khali@linux-fr.org>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	lm-sensors@lm-sensors.org, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
Date: Mon, 3 Aug 2009 19:54:50 -0700	[thread overview]
Message-ID: <200908031954.50955.david-b@pacbell.net> (raw)
In-Reply-To: <20090731004100.GB8371@oksana.dev.rtsoft.ru>

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;



WARNING: multiple messages have this Message-ID (diff)
From: David Brownell <david-b@pacbell.net>
To: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Ben Dooks <ben@fluff.org>,
	linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org,
	linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
	Jean Delvare <khali@linux-fr.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
Date: Mon, 3 Aug 2009 19:54:50 -0700	[thread overview]
Message-ID: <200908031954.50955.david-b@pacbell.net> (raw)
In-Reply-To: <20090731004100.GB8371@oksana.dev.rtsoft.ru>

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;

WARNING: multiple messages have this Message-ID (diff)
From: David Brownell <david-b@pacbell.net>
To: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Ben Dooks <ben@fluff.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org,
	Grant Likely <grant.likely@secretlab.ca>,
	linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
	Jean Delvare <khali@linux-fr.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
Date: Mon, 3 Aug 2009 19:54:50 -0700	[thread overview]
Message-ID: <200908031954.50955.david-b@pacbell.net> (raw)
In-Reply-To: <20090731004100.GB8371@oksana.dev.rtsoft.ru>

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;

WARNING: multiple messages have this Message-ID (diff)
From: David Brownell <david-b@pacbell.net>
To: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ben Dooks <ben@fluff.org>, David Woodhouse <dwmw2@infradead.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Jean Delvare <khali@linux-fr.org>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	lm-sensors@lm-sensors.org, linuxppc-dev@ozlabs.org
Subject: Re: [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table
Date: Tue, 04 Aug 2009 02:54:50 +0000	[thread overview]
Message-ID: <200908031954.50955.david-b@pacbell.net> (raw)
In-Reply-To: <20090731004100.GB8371@oksana.dev.rtsoft.ru>

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

  reply	other threads:[~2009-08-05  0:28 UTC|newest]

Thread overview: 131+ 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:39 ` [lm-sensors] " Anton Vorontsov
2009-07-31  0:39 ` Anton Vorontsov
2009-07-31  0:39 ` Anton Vorontsov
2009-07-31  0:40 ` [PATCH 1/6] spi: Add support for device table matching Anton Vorontsov
2009-07-31  0:40   ` [lm-sensors] " Anton Vorontsov
2009-07-31  0:40   ` Anton Vorontsov
2009-07-31  0:40   ` Anton Vorontsov
2009-07-31  0:41 ` [PATCH 2/6] mtd: m25p80: Convert to " Anton Vorontsov
2009-07-31  0:41   ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table Anton Vorontsov
2009-07-31  0:41   ` [PATCH 2/6] mtd: m25p80: Convert to device table matching Anton Vorontsov
2009-07-31  0:41   ` Anton Vorontsov
2009-08-04  2:54   ` David Brownell [this message]
2009-08-04  2:54     ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table David Brownell
2009-08-04  2:54     ` [PATCH 2/6] mtd: m25p80: Convert to device table matching David Brownell
2009-08-04  2:54     ` David Brownell
2009-08-18 21:44     ` Anton Vorontsov
2009-08-18 21:44       ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table Anton Vorontsov
2009-08-18 21:44       ` [PATCH 2/6] mtd: m25p80: Convert to device table matching Anton Vorontsov
2009-08-18 21:44       ` Anton Vorontsov
2009-08-18 21:46       ` [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code Anton Vorontsov
2009-08-18 21:46         ` Anton Vorontsov
2010-06-12  6:27         ` Barry Song
2010-06-12  6:27           ` Barry Song
2010-06-12  6:27           ` Barry Song
2010-06-18 13:32           ` Anton Vorontsov
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  2:42               ` Song, Barry
2010-06-21  2:42               ` Song, Barry
2010-06-21  3:27               ` Barry Song
2010-06-21  3:27                 ` Barry Song
2010-06-21  3:27                 ` Barry Song
2010-06-21  7:15                 ` Anton Vorontsov
2010-06-21  7:15                   ` Anton Vorontsov
2010-06-21  7:22                   ` Barry Song
2010-06-21  7:22                     ` Barry Song
2010-06-21  7:22                     ` Barry Song
2010-06-21  7:39                     ` Anton Vorontsov
2010-06-21  7:39                       ` Anton Vorontsov
2010-06-21 10:31                       ` Barry Song
2010-06-21 10:31                         ` Barry Song
2010-06-21 10:31                         ` Barry Song
2010-06-21 11:20                         ` Anton Vorontsov
2010-06-21 11:20                           ` Anton Vorontsov
2010-06-21 16:34                           ` Mike Frysinger
2010-06-21 16:34                             ` Mike Frysinger
2010-06-21 16:34                             ` Mike Frysinger
2010-06-21 16:47                             ` Anton Vorontsov
2010-06-21 16:47                               ` Anton Vorontsov
2010-06-21 16:54                               ` Mike Frysinger
2010-06-21 16:54                                 ` Mike Frysinger
2010-06-21 16:54                                 ` Mike Frysinger
2010-06-22  6:37                           ` Barry Song
2010-06-22  6:37                             ` Barry Song
2010-06-22  6:37                             ` Barry Song
2010-06-22 16:55                             ` Anton Vorontsov
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 16:57                                 ` Anton Vorontsov
2010-06-22 17:56                                 ` Mike Frysinger
2010-06-22 17:56                                   ` Mike Frysinger
2010-07-08  5:57                                 ` Artem Bityutskiy
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
2010-06-22 16:57                                 ` Anton Vorontsov
2009-08-18 21:46       ` [PATCH 2/2] mtd: m25p80: Add support for CAT25xxx serial EEPROMs Anton Vorontsov
2009-08-18 21:46         ` Anton Vorontsov
2009-09-22 23:25         ` Andrew Morton
2009-09-22 23:25           ` Andrew Morton
2009-09-22 23:40           ` Anton Vorontsov
2009-09-22 23:40             ` Anton Vorontsov
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 21:17       ` Andrew Morton
2009-09-22 21:17       ` Andrew Morton
2009-09-22 23:01       ` Anton Vorontsov
2009-09-22 23:01         ` Anton Vorontsov
2009-09-22 23:01         ` Anton Vorontsov
2009-09-22 23:43         ` David Woodhouse
2009-09-22 23:43           ` David Woodhouse
2009-09-22 23:43           ` David Woodhouse
2009-09-22 23:52           ` Andrew Morton
2009-09-22 23:52             ` Andrew Morton
2009-09-22 23:52             ` Andrew Morton
2009-09-22 23:55           ` Anton Vorontsov
2009-09-22 23:55             ` Anton Vorontsov
2009-09-22 23:55             ` Anton Vorontsov
2009-09-23  0:02             ` Andrew Morton
2009-09-23  0:02               ` Andrew Morton
2009-09-23  0:02               ` Andrew Morton
2009-08-12 20:45   ` Michael Barkowski
2009-08-12 20:45     ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table Michael Barkowski
2009-08-12 20:45     ` [PATCH 2/6] mtd: m25p80: Convert to device table matching Michael Barkowski
2009-08-12 20:45     ` Michael Barkowski
2009-08-12 20:58     ` Anton Vorontsov
2009-08-12 20:58       ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table Anton Vorontsov
2009-08-12 20:58       ` [PATCH 2/6] mtd: m25p80: Convert to device table matching Anton Vorontsov
2009-08-12 20:58       ` Anton Vorontsov
2009-08-12 20:58       ` Michael Barkowski
2009-08-12 20:58         ` [lm-sensors] [PATCH 2/6] mtd: m25p80: Convert to device table Michael Barkowski
2009-08-12 20:58         ` [PATCH 2/6] mtd: m25p80: Convert to device table matching Michael Barkowski
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   ` [lm-sensors] " Anton Vorontsov
2009-07-31  0:41   ` Anton Vorontsov
2009-07-31  0:41   ` Anton Vorontsov
2009-07-31  0:41 ` [PATCH 4/6] hwmon: adxx: Convert to device table matching Anton Vorontsov
2009-07-31  0:41   ` [lm-sensors] [PATCH 4/6] hwmon: adxx: Convert to device table Anton Vorontsov
2009-07-31  0:41   ` [PATCH 4/6] hwmon: adxx: Convert to device table matching Anton Vorontsov
2009-07-31  0:41   ` Anton Vorontsov
2009-07-31  0:41 ` [PATCH 5/6] hwmon: lm70: " Anton Vorontsov
2009-07-31  0:41   ` [lm-sensors] [PATCH 5/6] hwmon: lm70: Convert to device table Anton Vorontsov
2009-07-31  0:41   ` [PATCH 5/6] hwmon: lm70: Convert to device table matching Anton Vorontsov
2009-07-31  0:41   ` Anton Vorontsov
2009-07-31  0:41 ` [PATCH 6/6] spi: Prefix modalias with "spi:" Anton Vorontsov
2009-07-31  0:41   ` [lm-sensors] " Anton Vorontsov
2009-07-31  0:41   ` Anton Vorontsov
2009-07-31  0:41   ` Anton Vorontsov
2009-08-10  7:35 ` [PATCH v2 0/6] Device table matching for SPI subsystem Artem Bityutskiy
2009-08-10  7:35   ` [lm-sensors] [PATCH v2 0/6] Device table matching for SPI Artem Bityutskiy
2009-08-10  7:35   ` [PATCH v2 0/6] Device table matching for SPI subsystem Artem Bityutskiy
2009-08-10  7:35   ` Artem Bityutskiy
2009-08-18 21:44   ` Anton Vorontsov
2009-08-18 21:44     ` [lm-sensors] [PATCH v2 0/6] Device table matching for SPI Anton Vorontsov
2009-08-18 21:44     ` [PATCH v2 0/6] Device table matching for SPI subsystem Anton Vorontsov
2009-08-18 21:44     ` Anton Vorontsov
2009-08-25 14:14     ` Artem Bityutskiy
2009-08-25 14:14       ` [lm-sensors] [PATCH v2 0/6] Device table matching for SPI Artem Bityutskiy
2009-08-25 14:14       ` [PATCH v2 0/6] Device table matching for SPI subsystem Artem Bityutskiy
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=200908031954.50955.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@linux-foundation.org \
    --cc=avorontsov@ru.mvista.com \
    --cc=ben@fluff.org \
    --cc=benh@kernel.crashing.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.