* [PATCH 1/1 RFC] mtd: spi-nor: Fix ID for Spansion s70fl01gs
@ 2014-09-29 9:43 Alexander Stein
2014-10-14 6:30 ` Alexander Stein
2014-11-05 21:13 ` Brian Norris
0 siblings, 2 replies; 5+ messages in thread
From: Alexander Stein @ 2014-09-29 9:43 UTC (permalink / raw
To: David Woodhouse, Brian Norris; +Cc: linux-mtd, Alexander Stein
The Device ID is the same as with s25fl512s as stated in datasheet:
6. Identification (RDID)
The Read Identification (RDID) command outputs the one-byte manufacturer
identification, followed by the two-byte device identification and the
bytes for the Common Flash Interface (CFI) tables. Each die of the FL01GS
dual die stack will have identical identification data as the FL512S die,
with the exception of the CFI data at byte 27h, as shown in Table 6.1.
If DT is configured with 's70fl01gs' I get the following warnings (on a 3.12
kernel, but that shouldn't matter):
m25p80 spi32766.0: found s25fl512s, expected s70fl01gs
m25p80 spi32766.1: found s25fl512s, expected s70fl01gs
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
I am aware that there is now an ID conflict. But this is due that the
s70fl01gs simply uses two separate chips. How to handle that?
drivers/mtd/spi-nor/spi-nor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..0c34968 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -551,7 +551,7 @@ const struct spi_device_id spi_nor_ids[] = {
{ "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
{ "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "s70fl01gs", INFO(0x010221, 0x4d00, 256 * 1024, 256, 0) },
+ { "s70fl01gs", INFO(0x010220, 0x4d00, 256 * 1024, 256, 0) },
{ "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
{ "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
{ "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024, 64, 0) },
--
1.8.5.5
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 1/1 RFC] mtd: spi-nor: Fix ID for Spansion s70fl01gs
2014-09-29 9:43 [PATCH 1/1 RFC] mtd: spi-nor: Fix ID for Spansion s70fl01gs Alexander Stein
@ 2014-10-14 6:30 ` Alexander Stein
2014-11-05 21:13 ` Brian Norris
1 sibling, 0 replies; 5+ messages in thread
From: Alexander Stein @ 2014-10-14 6:30 UTC (permalink / raw
To: David Woodhouse; +Cc: Brian Norris, linux-mtd
Ping?
On Monday 29 September 2014 11:43:15, Alexander Stein wrote:
> The Device ID is the same as with s25fl512s as stated in datasheet:
> 6. Identification (RDID)
> The Read Identification (RDID) command outputs the one-byte manufacturer
> identification, followed by the two-byte device identification and the
> bytes for the Common Flash Interface (CFI) tables. Each die of the FL01GS
> dual die stack will have identical identification data as the FL512S die,
> with the exception of the CFI data at byte 27h, as shown in Table 6.1.
>
> If DT is configured with 's70fl01gs' I get the following warnings (on a 3.12
> kernel, but that shouldn't matter):
> m25p80 spi32766.0: found s25fl512s, expected s70fl01gs
> m25p80 spi32766.1: found s25fl512s, expected s70fl01gs
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
> I am aware that there is now an ID conflict. But this is due that the
> s70fl01gs simply uses two separate chips. How to handle that?
>
> drivers/mtd/spi-nor/spi-nor.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index b5ad6be..0c34968 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -551,7 +551,7 @@ const struct spi_device_id spi_nor_ids[] = {
> { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> - { "s70fl01gs", INFO(0x010221, 0x4d00, 256 * 1024, 256, 0) },
> + { "s70fl01gs", INFO(0x010220, 0x4d00, 256 * 1024, 256, 0) },
> { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
> { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
> { "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024, 64, 0) },
>
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
Am Windrad 2
08468 Heinsdorfergrund
Tel.: 03765 38600-1156
Fax: 03765 38600-4100
Email: alexander.stein@systec-electronic.com
Website: www.systec-electronic.com
Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Chemnitz, HRB 28082
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/1 RFC] mtd: spi-nor: Fix ID for Spansion s70fl01gs
2014-09-29 9:43 [PATCH 1/1 RFC] mtd: spi-nor: Fix ID for Spansion s70fl01gs Alexander Stein
2014-10-14 6:30 ` Alexander Stein
@ 2014-11-05 21:13 ` Brian Norris
2014-11-06 7:01 ` Alexander Stein
2014-11-06 7:02 ` Alexander Stein
1 sibling, 2 replies; 5+ messages in thread
From: Brian Norris @ 2014-11-05 21:13 UTC (permalink / raw
To: Alexander Stein; +Cc: Marek Vasut, linux-mtd, Kevin Cernekee, David Woodhouse
On Mon, Sep 29, 2014 at 11:43:15AM +0200, Alexander Stein wrote:
> The Device ID is the same as with s25fl512s as stated in datasheet:
> 6. Identification (RDID)
> The Read Identification (RDID) command outputs the one-byte manufacturer
> identification, followed by the two-byte device identification and the
> bytes for the Common Flash Interface (CFI) tables. Each die of the FL01GS
> dual die stack will have identical identification data as the FL512S die,
> with the exception of the CFI data at byte 27h, as shown in Table 6.1.
>
> If DT is configured with 's70fl01gs' I get the following warnings (on a 3.12
> kernel, but that shouldn't matter):
> m25p80 spi32766.0: found s25fl512s, expected s70fl01gs
> m25p80 spi32766.1: found s25fl512s, expected s70fl01gs
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
> I am aware that there is now an ID conflict. But this is due that the
> s70fl01gs simply uses two separate chips. How to handle that?
Maybe you should just be specifying s25fl512s in your DT instead?
Are we sure there are no s70fl01gs devices which use the current ID? I
know some manufacturers are prone to doing the stupidest things you can
think of (like arbitrarily-changing IDs).
>
> drivers/mtd/spi-nor/spi-nor.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index b5ad6be..0c34968 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -551,7 +551,7 @@ const struct spi_device_id spi_nor_ids[] = {
> { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> - { "s70fl01gs", INFO(0x010221, 0x4d00, 256 * 1024, 256, 0) },
> + { "s70fl01gs", INFO(0x010220, 0x4d00, 256 * 1024, 256, 0) },
> { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
> { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
> { "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024, 64, 0) },
Brian
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/1 RFC] mtd: spi-nor: Fix ID for Spansion s70fl01gs
2014-11-05 21:13 ` Brian Norris
@ 2014-11-06 7:01 ` Alexander Stein
2014-11-06 7:02 ` Alexander Stein
1 sibling, 0 replies; 5+ messages in thread
From: Alexander Stein @ 2014-11-06 7:01 UTC (permalink / raw
To: Brian Norris; +Cc: Marek Vasut, linux-mtd, Kevin Cernekee, David Woodhouse
Hello Brian,
thanks for replying.
On Wednesday 05 November 2014 13:13:34, Brian Norris wrote:
> On Mon, Sep 29, 2014 at 11:43:15AM +0200, Alexander Stein wrote:
> > The Device ID is the same as with s25fl512s as stated in datasheet:
> > 6. Identification (RDID)
> > The Read Identification (RDID) command outputs the one-byte manufacturer
> > identification, followed by the two-byte device identification and the
> > bytes for the Common Flash Interface (CFI) tables. Each die of the FL01GS
> > dual die stack will have identical identification data as the FL512S die,
> > with the exception of the CFI data at byte 27h, as shown in Table 6.1.
> >
> > If DT is configured with 's70fl01gs' I get the following warnings (on a 3.12
> > kernel, but that shouldn't matter):
> > m25p80 spi32766.0: found s25fl512s, expected s70fl01gs
> > m25p80 spi32766.1: found s25fl512s, expected s70fl01gs
> >
> > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> > ---
> > I am aware that there is now an ID conflict. But this is due that the
> > s70fl01gs simply uses two separate chips. How to handle that?
>
> Maybe you should just be specifying s25fl512s in your DT instead?
This is what I'm doing now. It seems to me that this is currently the only valid solution.
> Are we sure there are no s70fl01gs devices which use the current ID? I
> know some manufacturers are prone to doing the stupidest things you can
> think of (like arbitrarily-changing IDs).
To quote from http://www.spansion.com/Support/Datasheets/S70FL01GS.pdf:
6. Read Identification (RDID)
The Read Identification (RDID) command outputs the one-byte manufacturer identification, followed by the
two-byte device identification and the bytes for the Common Flash Interface (CFI) tables. Each die of the
FL01GS dual die stack will have identical identification data as the FL512S die, with the exception of the CFI
data at byte 27h, as shown in Table 6.1.
So, AFAICS you can only distinguish two FL512S from a FL01GS by reading this CFI byte which isn't done in linux.
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
Am Windrad 2
08468 Heinsdorfergrund
Tel.: 03765 38600-1156
Fax: 03765 38600-4100
Email: alexander.stein@systec-electronic.com
Website: www.systec-electronic.com
Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Chemnitz, HRB 28082
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/1 RFC] mtd: spi-nor: Fix ID for Spansion s70fl01gs
2014-11-05 21:13 ` Brian Norris
2014-11-06 7:01 ` Alexander Stein
@ 2014-11-06 7:02 ` Alexander Stein
1 sibling, 0 replies; 5+ messages in thread
From: Alexander Stein @ 2014-11-06 7:02 UTC (permalink / raw
To: Brian Norris; +Cc: Marek Vasut, linux-mtd, Kevin Cernekee, David Woodhouse
Hello Brian,
thanks for replying.
On Wednesday 05 November 2014 13:13:34, Brian Norris wrote:
> On Mon, Sep 29, 2014 at 11:43:15AM +0200, Alexander Stein wrote:
> > The Device ID is the same as with s25fl512s as stated in datasheet:
> > 6. Identification (RDID)
> > The Read Identification (RDID) command outputs the one-byte manufacturer
> > identification, followed by the two-byte device identification and the
> > bytes for the Common Flash Interface (CFI) tables. Each die of the FL01GS
> > dual die stack will have identical identification data as the FL512S die,
> > with the exception of the CFI data at byte 27h, as shown in Table 6.1.
> >
> > If DT is configured with 's70fl01gs' I get the following warnings (on a 3.12
> > kernel, but that shouldn't matter):
> > m25p80 spi32766.0: found s25fl512s, expected s70fl01gs
> > m25p80 spi32766.1: found s25fl512s, expected s70fl01gs
> >
> > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> > ---
> > I am aware that there is now an ID conflict. But this is due that the
> > s70fl01gs simply uses two separate chips. How to handle that?
>
> Maybe you should just be specifying s25fl512s in your DT instead?
This is what I'm doing now. It seems to me that this is currently the only valid solution.
> Are we sure there are no s70fl01gs devices which use the current ID? I
> know some manufacturers are prone to doing the stupidest things you can
> think of (like arbitrarily-changing IDs).
To quote from http://www.spansion.com/Support/Datasheets/S70FL01GS.pdf:
6. Read Identification (RDID)
The Read Identification (RDID) command outputs the one-byte manufacturer identification, followed by the
two-byte device identification and the bytes for the Common Flash Interface (CFI) tables. Each die of the
FL01GS dual die stack will have identical identification data as the FL512S die, with the exception of the CFI
data at byte 27h, as shown in Table 6.1.
So, AFAICS you can only distinguish two FL512S from a FL01GS by reading this CFI byte which isn't done in linux.
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
Am Windrad 2
08468 Heinsdorfergrund
Tel.: 03765 38600-1156
Fax: 03765 38600-4100
Email: alexander.stein@systec-electronic.com
Website: www.systec-electronic.com
Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Chemnitz, HRB 28082
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-11-06 7:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-29 9:43 [PATCH 1/1 RFC] mtd: spi-nor: Fix ID for Spansion s70fl01gs Alexander Stein
2014-10-14 6:30 ` Alexander Stein
2014-11-05 21:13 ` Brian Norris
2014-11-06 7:01 ` Alexander Stein
2014-11-06 7:02 ` Alexander Stein
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.