All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Huang Shijie <b32955@freescale.com>
Cc: linux-mtd@lists.infradead.org, computersforpeace@gmail.com,
	dwmw2@infradead.org, angus.clark@st.com
Subject: Re: [PATCH] mtd: spi-nor: read 6 bytes for the ID
Date: Mon, 14 Apr 2014 13:53:07 +0200	[thread overview]
Message-ID: <201404141353.07427.marex@denx.de> (raw)
In-Reply-To: <1397470174-27856-1-git-send-email-b32955@freescale.com>

On Monday, April 14, 2014 at 12:09:34 PM, Huang Shijie wrote:

[...]

> @@ -505,6 +505,7 @@ const struct spi_device_id spi_nor_ids[] = {
>  	{ "s70fl01gs",  INFO(0x010221, 0x4d00, 256 * 1024, 256, 0) },
>  	{ "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024,  64, 0) },
>  	{ "s25sl12801", INFO(0x012018, 0x0301,  64 * 1024, 256, 0) },
> +	{ "s25fl128s",	INFO(0x012018, 0x4d0180, 64 * 1024, 256,
> SPI_NOR_QUAD_READ) }, { "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024, 
> 64, 0) },

Support for new hardware should go in separatelly.

>  	{ "s25fl129p1", INFO(0x012018, 0x4d01,  64 * 1024, 256, 0) },
>  	{ "s25sl004a",  INFO(0x010212,      0,  64 * 1024,   8, 0) },
> @@ -593,12 +594,13 @@ EXPORT_SYMBOL_GPL(spi_nor_ids);
>  static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
>  {
>  	int			tmp;
> -	u8			id[5];
> +	u8			id[6];
>  	u32			jedec;
> -	u16                     ext_jedec;
> +	u32                     ext_jedec;
>  	struct flash_info	*info;
> +	int			matched = -1;
> 
> -	tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, 5);
> +	tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, 6);
>  	if (tmp < 0) {
>  		dev_dbg(nor->dev, " error %d reading JEDEC ID\n", tmp);
>  		return ERR_PTR(tmp);
> @@ -614,8 +616,23 @@ static const struct spi_device_id
> *spi_nor_read_id(struct spi_nor *nor) for (tmp = 0; tmp <
> ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
>  		info = (void *)spi_nor_ids[tmp].driver_data;
>  		if (info->jedec_id == jedec) {
> -			if (info->ext_id == 0 || info->ext_id == ext_jedec)
> +			if (info->ext_id == 0)
>  				return &spi_nor_ids[tmp];
> +
> +			/* the legacy two bytes ext_id */
> +			if ((info->ext_id >> 16) == 0) {
> +				if (info->ext_id == ext_jedec)
> +					matched = tmp;
> +			} else {
> +				/* check the sixth byte now */
> +				ext_jedec = ext_jedec << 8 | id[5];
> +				if (info->ext_id == ext_jedec)
> +					return &spi_nor_ids[tmp];
> +			}
> +		} else {
> +			/* shortcut */
> +			if (matched != -1)
> +				return &spi_nor_ids[matched];

I wonder if the ID-bytes wraparound cannot cause us trouble here. For example if 
we try to detect a SPI NOR which has 5-byte ID code, but in the table, we'd also 
have a SPI NOR with has a 6-byte code where the last byte of ext-jedec matches 
the first byte of JEDEC ID , this would actually match on the later.

Shall we not add an ID code length field into the table instead ?

  reply	other threads:[~2014-04-14 11:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-14 10:09 [PATCH] mtd: spi-nor: read 6 bytes for the ID Huang Shijie
2014-04-14 11:53 ` Marek Vasut [this message]
2014-04-14 14:44   ` Huang Shijie
2014-04-14 18:23     ` Marek Vasut
2014-04-15  5:22       ` Huang Shijie
2014-04-15 13:35         ` Marek Vasut
2014-04-15 16:04           ` Huang Shijie
2014-04-15 18:48             ` Marek Vasut
2014-04-16  1:52               ` Huang Shijie
2014-04-16 10:18                 ` Marek Vasut
2014-04-16 13:56                   ` Huang Shijie
2014-04-16 23:23                     ` Marek Vasut
2014-04-17  4:55                       ` Huang Shijie
2014-04-22  8:19           ` Huang Shijie
2014-05-27  1:12 ` Huang Shijie
2014-05-27 15:57   ` Christophe KERELLO
2014-05-28  5:22     ` Huang Shijie
2014-05-28 16:27       ` Christophe KERELLO
2014-05-29 20:58       ` Marek Vasut
2014-05-30  0:49         ` Huang Shijie
2014-06-03 14:23           ` Marek Vasut
2014-08-04 23:24       ` Brian Norris
2014-08-05  0:52         ` Huang Shijie
2014-08-05  7:14           ` Marek Vasut
2014-08-06  0:23             ` Huang Shijie

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=201404141353.07427.marex@denx.de \
    --to=marex@denx.de \
    --cc=angus.clark@st.com \
    --cc=b32955@freescale.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.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.