sf: Update flash params for supported read commands and sector size

Update SST25VF064C read command to RD_EXTN per datasheet. Also change flash sector size to 4KiB to match SECT_4K.

Signed-off-by Bin Meng <[email protected]>

---

 drivers/mtd/spi/sf_params.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

drivers/mtd/spi/sf_params.c +10 -11

index 30875b3..5482700 100644
@@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
        {"N25Q1024A",      0x20bb21, 0x0,       64 * 1024,  2048, RD_FULL, WR_QPP | E_FSR | SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_SST            /* SST */
-       {"SST25VF040B",    0xbf258d, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF080B",    0xbf258e, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF016B",    0xbf2541, 0x0,       64 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF032B",    0xbf254a, 0x0,       64 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF064C",    0xbf254b, 0x0,       64 * 1024,   128, RD_NORM,                   SECT_4K},
-       {"SST25WF512",     0xbf2501, 0x0,       64 * 1024,     1, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF010",     0xbf2502, 0x0,       64 * 1024,     2, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF020",     0xbf2503, 0x0,       64 * 1024,     4, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF040",     0xbf2504, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF040B",    0xbf258d, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF080B",    0xbf258e, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF016B",    0xbf2541, 0x0,        4 * 1024,   512, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF032B",    0xbf254a, 0x0,        4 * 1024,  1024, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF064C",    0xbf254b, 0x0,        4 * 1024,  2048, RD_EXTN,                   SECT_4K},
+       {"SST25WF512",     0xbf2501, 0x0,        4 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25WF010",     0xbf2502, 0x0,        4 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25WF020",     0xbf2503, 0x0,        4 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25WF040",     0xbf2504, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25WF080",     0xbf2505, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
 #endif
 #ifdef CONFIG_SPI_FLASH_WINBOND                /* WINBOND */
        {"W25P80",         0xef2014, 0x0,       64 * 1024,    16, RD_NORM,                         0},
--

1.8.2.1

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

SST_WRITE) },

Please check it.

Quoted 33 lines

Update SST25VF064C read command to RD_EXTN per datasheet. Also change flash sector size to 4KiB to match SECT_4K.

Signed-off-by Bin Meng <[email protected]>

---

 drivers/mtd/spi/sf_params.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

drivers/mtd/spi/sf_params.c +6 -10

index 30875b3..5482700 100644
@@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
        {"N25Q1024A",      0x20bb21, 0x0,       64 * 1024,  2048, RD_FULL, WR_QPP | E_FSR | SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_SST            /* SST */
-       {"SST25VF040B",    0xbf258d, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF080B",    0xbf258e, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF016B",    0xbf2541, 0x0,       64 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF032B",    0xbf254a, 0x0,       64 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF064C",    0xbf254b, 0x0,       64 * 1024,   128, RD_NORM,                   SECT_4K},
-       {"SST25WF512",     0xbf2501, 0x0,       64 * 1024,     1, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF010",     0xbf2502, 0x0,       64 * 1024,     2, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF020",     0xbf2503, 0x0,       64 * 1024,     4, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF040",     0xbf2504, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF040B",    0xbf258d, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF080B",    0xbf258e, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF016B",    0xbf2541, 0x0,        4 * 1024,   512, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF032B",    0xbf254a, 0x0,        4 * 1024,  1024, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF064C",    0xbf254b, 0x0,        4 * 1024,  2048, RD_EXTN,                   SECT_4K},
+       {"SST25WF512",     0xbf2501, 0x0,        4 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},

drivers/mtd/spi/sf_params.c const struct spi_flash_params spi_flash_params_table[] = {

Quoted 8 lines

drivers/mtd/spi/sf_params.c +4 -1

+       {"SST25WF010",     0xbf2502, 0x0,        4 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25WF020",     0xbf2503, 0x0,        4 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25WF040",     0xbf2504, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25WF080",     0xbf2505, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
 #endif
 #ifdef CONFIG_SPI_FLASH_WINBOND                /* WINBOND */
        {"W25P80",         0xef2014, 0x0,       64 * 1024,    16, RD_NORM,                         0},
--

Hi Jagan,

Quoted 20 lines · Jagan Teki

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

Quoted 3 lines

SST_WRITE) },

Please check it.

Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.

Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.

Quoted 35 lines · Bin Meng

Quoted 33 lines

Update SST25VF064C read command to RD_EXTN per datasheet. Also change flash sector size to 4KiB to match SECT_4K.

Signed-off-by Bin Meng <[email protected]>

---

 drivers/mtd/spi/sf_params.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

drivers/mtd/spi/sf_params.c +6 -10

index 30875b3..5482700 100644
@@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
        {"N25Q1024A",      0x20bb21, 0x0,       64 * 1024,  2048, RD_FULL, WR_QPP | E_FSR | SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_SST            /* SST */
-       {"SST25VF040B",    0xbf258d, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF080B",    0xbf258e, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF016B",    0xbf2541, 0x0,       64 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF032B",    0xbf254a, 0x0,       64 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25VF064C",    0xbf254b, 0x0,       64 * 1024,   128, RD_NORM,                   SECT_4K},
-       {"SST25WF512",     0xbf2501, 0x0,       64 * 1024,     1, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF010",     0xbf2502, 0x0,       64 * 1024,     2, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF020",     0xbf2503, 0x0,       64 * 1024,     4, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF040",     0xbf2504, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
-       {"SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF040B",    0xbf258d, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF080B",    0xbf258e, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF016B",    0xbf2541, 0x0,        4 * 1024,   512, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF032B",    0xbf254a, 0x0,        4 * 1024,  1024, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25VF064C",    0xbf254b, 0x0,        4 * 1024,  2048, RD_EXTN,                   SECT_4K},
+       {"SST25WF512",     0xbf2501, 0x0,        4 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},

Quoted 8 lines

drivers/mtd/spi/sf_params.c const struct spi_flash_params spi_flash_params_table[] = {

Quoted 8 lines

drivers/mtd/spi/sf_params.c +4 -1

+       {"SST25WF010",     0xbf2502, 0x0,        4 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25WF020",     0xbf2503, 0x0,        4 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25WF040",     0xbf2504, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
+       {"SST25WF080",     0xbf2505, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
 #endif
 #ifdef CONFIG_SPI_FLASH_WINBOND                /* WINBOND */
        {"W25P80",         0xef2014, 0x0,       64 * 1024,    16, RD_NORM,                         0},
--

Hi Bin,

Quoted 31 lines · Bin Meng

Hi Jagan,

Quoted 20 lines · Jagan Teki

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

Quoted 3 lines

SST_WRITE) },

Please check it.

Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.

Quoted 3 lines

Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.

It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.

        /* Compute erase sector and command */
        if (params->flags & SECT_4K) {
                flash->erase_cmd = CMD_ERASE_4K;
                flash->erase_size = 4096 << flash->shift;
        } else if (params->flags & SECT_32K) {
                flash->erase_cmd = CMD_ERASE_32K;
                flash->erase_size = 32768 << flash->shift;
        } else {
                flash->erase_cmd = CMD_ERASE_64K;
                flash->erase_size = flash->sector_size;
        }

And to be honest, these flashes were tested with lowest ie 4KB so even if they do support 64KB, we mentioned on 4KB on 'params->flags' as we tested well with that
and it works consistently.

Quoted 1 line

Hi Jagan,

Quoted 34 lines · Jagan Teki

Hi Bin,

Quoted 31 lines · Bin Meng

Hi Jagan,

Quoted 20 lines · Jagan Teki

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

Quoted 3 lines

SST_WRITE) },

Please check it.

Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.

Quoted 6 lines

Quoted 3 lines

Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.

It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.

No, it is related. See cmd_sf.c:

static int sf_parse_len_arg(char *arg, ulong *len)

{
    char *ep;
    char round_up_len; /* indicates if the "+length" form used */
    ulong len_arg;

    round_up_len = 0;
    if (*arg == '+') {
        round_up_len = 1;
        ++arg;
    }

    len_arg = simple_strtoul(arg, &ep, 16);
    if (ep == arg || *ep != '\0')
        return -1;

    if (round_up_len && flash->sector_size > 0)
        *len = ROUND(len_arg, flash->sector_size);
    else
        *len = len_arg;

    return 1;
}

So even you are passing 4KB in the flash params, the 'sf erase' command WILL erase 64KB.

Quoted 16 lines

        /* Compute erase sector and command */
        if (params->flags & SECT_4K) {
                flash->erase_cmd = CMD_ERASE_4K;
                flash->erase_size = 4096 << flash->shift;
        } else if (params->flags & SECT_32K) {
                flash->erase_cmd = CMD_ERASE_32K;
                flash->erase_size = 32768 << flash->shift;
        } else {
                flash->erase_cmd = CMD_ERASE_64K;
                flash->erase_size = flash->sector_size;
        }

And to be honest, these flashes were tested with lowest ie 4KB so even if they do support 64KB, we mentioned on 4KB on 'params->flags' as we tested well with that
and it works consistently.

Hi Bin,

Quoted 41 lines · Bin Meng

Hi Jagan,

Quoted 38 lines · Jagan Teki

Hi Bin,

Quoted 34 lines · Bin Meng

Hi Jagan,

Quoted 20 lines · Jagan Teki

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

Quoted 3 lines

SST_WRITE) },

Please check it.

Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.

Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.

Quoted 4 lines

Quoted 2 lines

It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.

No, it is related. See cmd_sf.c:

I'm not getting your point- how could it erase use 64K sector size instead of 4K.

Suppose the sector size is 4K

flash->sector_size = 0x1000
1. erase 4K len flash (it's total erase length)

# sf erase 0x0 0x1000

len_arg = simple_strtoul(arg, &ep, 16);
gives - 0x1000

   *len becomes 0x1000

2. erase 4K+1 len flash

# sf erase 0x0 +0x1001

len_arg = simple_strtoul(arg, &ep, 16);
gives - 0x1001

*len becomes 0x2000

All the way when it goes to sf_ops.c erase will take by means of erase_size which is assigned in sf_probe.c based on flags like 4K 32K or 64K.

Hi Jagan,

Quoted 47 lines · Jagan Teki

Hi Bin,

Quoted 44 lines · Bin Meng

Hi Jagan,

Quoted 40 lines · Jagan Teki

Hi Bin,

Quoted 28 lines · Bin Meng

Hi Jagan,

Quoted 20 lines · Jagan Teki

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

Quoted 3 lines

SST_WRITE) },

Please check it.

Quoted 6 lines

Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.

Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.

It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.

Quoted 4 lines

Quoted 1 line

No, it is related. See cmd_sf.c:

I'm not getting your point- how could it erase use 64K sector size instead of 4K.

It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().

Quoted 17 lines

Suppose the sector size is 4K

flash->sector_size = 0x1000
1. erase 4K len flash (it's total erase length)

# sf erase 0x0 0x1000

len_arg = simple_strtoul(arg, &ep, 16);
gives - 0x1000

   *len becomes 0x1000

2. erase 4K+1 len flash

# sf erase 0x0 +0x1001

Quoted 8 lines

len_arg = simple_strtoul(arg, &ep, 16);
gives - 0x1001

*len becomes 0x2000

All the way when it goes to sf_ops.c erase will take by means of erase_size which is assigned in sf_probe.c based on flags like 4K 32K or 64K.

Hi Bin,

Quoted 52 lines · Bin Meng

Hi Jagan,

Quoted 49 lines · Jagan Teki

Hi Bin,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 34 lines · Jagan Teki

Hi Bin,

Quoted 31 lines · Bin Meng

Hi Jagan,

Quoted 20 lines · Jagan Teki

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

Quoted 3 lines

SST_WRITE) },

Please check it.

Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.

Quoted 6 lines

Quoted 3 lines

Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.

It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.

No, it is related. See cmd_sf.c:

Quoted 5 lines

Quoted 2 lines

I'm not getting your point- how could it erase use 64K sector size instead of 4K.

It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().

We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.

       /* Compute erase sector and command */
        if (params->flags & SECT_4K) {
                flash->erase_cmd = CMD_ERASE_4K;
                flash->erase_size = 4096;
        } else if (params->flags & SECT_32K) {
                flash->erase_cmd = CMD_ERASE_32K;
                flash->erase_size = 32768;
        } else {
                flash->erase_cmd = CMD_ERASE_64K;
                flash->erase_size = flash->sector_size;
        }

Quoted 20 lines

Quoted 20 lines

Suppose the sector size is 4K

flash->sector_size = 0x1000
1. erase 4K len flash (it's total erase length)

# sf erase 0x0 0x1000

len_arg = simple_strtoul(arg, &ep, 16);
gives - 0x1000

   *len becomes 0x1000

2. erase 4K+1 len flash

# sf erase 0x0 +0x1001

len_arg = simple_strtoul(arg, &ep, 16);
gives - 0x1001

Quoted 5 lines

Quoted 5 lines

*len becomes 0x2000

All the way when it goes to sf_ops.c erase will take by means of erase_size which is assigned in sf_probe.c based on flags like 4K 32K or 64K.

thanks!
--

Hi Jagan,

Quoted 55 lines · Jagan Teki

Hi Bin,

Quoted 52 lines · Bin Meng

Hi Jagan,

Quoted 49 lines · Jagan Teki

Hi Bin,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 34 lines · Jagan Teki

Hi Bin,

Quoted 31 lines · Bin Meng

Hi Jagan,

Quoted 20 lines · Jagan Teki

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

Quoted 3 lines

SST_WRITE) },

Please check it.

Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.

Quoted 6 lines

Quoted 3 lines

Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.

It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.

No, it is related. See cmd_sf.c:

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

I'm not getting your point- how could it erase use 64K sector size instead of 4K.

It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().

We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.

You previous email already said: the 'sf erase' command depends on *flash->sector_size*

Quoted 11 lines

       /* Compute erase sector and command */
        if (params->flags & SECT_4K) {
                flash->erase_cmd = CMD_ERASE_4K;
                flash->erase_size = 4096;
        } else if (params->flags & SECT_32K) {
                flash->erase_cmd = CMD_ERASE_32K;
                flash->erase_size = 32768;
        } else {
                flash->erase_cmd = CMD_ERASE_64K;
                flash->erase_size = flash->sector_size;
        }

Here the codes says: *flash->erase_size*

So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Suppose the sector size is 4K

flash->sector_size = 0x1000
1. erase 4K len flash (it's total erase length)

# sf erase 0x0 0x1000

len_arg = simple_strtoul(arg, &ep, 16);
gives - 0x1000

   *len becomes 0x1000

2. erase 4K+1 len flash

# sf erase 0x0 +0x1001

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

len_arg = simple_strtoul(arg, &ep, 16);
gives - 0x1001

*len becomes 0x2000

All the way when it goes to sf_ops.c erase will take by means of erase_size which is assigned in sf_probe.c based on flags like 4K 32K or 64K.

Hi Bin,

Quoted 82 lines · Bin Meng

Hi Jagan,

Quoted 55 lines · Jagan Teki

Hi Bin,

Quoted 52 lines · Bin Meng

Hi Jagan,

Quoted 49 lines · Jagan Teki

Hi Bin,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 34 lines · Jagan Teki

Hi Bin,

Quoted 31 lines · Bin Meng

Hi Jagan,

Quoted 20 lines · Jagan Teki

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

Quoted 3 lines

SST_WRITE) },

Please check it.

Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.

Quoted 6 lines

Quoted 3 lines

Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.

It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.

No, it is related. See cmd_sf.c:

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

I'm not getting your point- how could it erase use 64K sector size instead of 4K.

It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().

We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.

You previous email already said: the 'sf erase' command depends on *flash->sector_size*

Quoted 11 lines

       /* Compute erase sector and command */
        if (params->flags & SECT_4K) {
                flash->erase_cmd = CMD_ERASE_4K;
                flash->erase_size = 4096;
        } else if (params->flags & SECT_32K) {
                flash->erase_cmd = CMD_ERASE_32K;
                flash->erase_size = 32768;
        } else {
                flash->erase_cmd = CMD_ERASE_64K;
                flash->erase_size = flash->sector_size;
        }

Quoted 3 lines

Here the codes says: *flash->erase_size*

So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.

Example:
"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM,

    SECT_4K | SST_WR},

sf probe gives
sector_size = 64 * 1024 and erase_size = 4096

sf erase 0 100
sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"

Example:
"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM,

    SST_WR},

sf probe gives
sector_size = 64 * 1024 and erase_size = 64 * 1024

sf erase 0 100
sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"

Still have any concerns, please come to IRC for more discussion

Hi Jagan,

Quoted 96 lines · Jagan Teki

Hi Bin,

Quoted 82 lines · Bin Meng

Hi Jagan,

Quoted 55 lines · Jagan Teki

Hi Bin,

Quoted 52 lines · Bin Meng

Hi Jagan,

Quoted 49 lines · Jagan Teki

Hi Bin,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 34 lines · Jagan Teki

Hi Bin,

Quoted 31 lines · Bin Meng

Hi Jagan,

Quoted 20 lines · Jagan Teki

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

Quoted 3 lines

SST_WRITE) },

Please check it.

Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.

Quoted 6 lines

Quoted 3 lines

Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.

It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.

No, it is related. See cmd_sf.c:

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

I'm not getting your point- how could it erase use 64K sector size instead of 4K.

It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().

We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.

You previous email already said: the 'sf erase' command depends on *flash->sector_size*

Quoted 11 lines

       /* Compute erase sector and command */
        if (params->flags & SECT_4K) {
                flash->erase_cmd = CMD_ERASE_4K;
                flash->erase_size = 4096;
        } else if (params->flags & SECT_32K) {
                flash->erase_cmd = CMD_ERASE_32K;
                flash->erase_size = 32768;
        } else {
                flash->erase_cmd = CMD_ERASE_64K;
                flash->erase_size = flash->sector_size;
        }

Quoted 3 lines

Here the codes says: *flash->erase_size*

So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.

Example:
"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM,

    SECT_4K | SST_WR},

sf probe gives
sector_size = 64 * 1024 and erase_size = 4096

Quoted 3 lines

sf erase 0 100
sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"

sf erase 0 +100. Sorry for the typo. But looks like you are not really reading the codes.

=> sf probe
SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB, mapped at ffe00000

=> sf erase 0 +100
SF: 65536 bytes @ 0x0 Erased: OK

Tested on two boards, and both shows 64K was erased.

Quoted 12 lines

Example:
"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM,

    SST_WR},

sf probe gives
sector_size = 64 * 1024 and erase_size = 64 * 1024

sf erase 0 100
sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"

Still have any concerns, please come to IRC for more discussion

Hi Bin,

Quoted 103 lines · Bin Meng

Hi Jagan,

Quoted 99 lines · Jagan Teki

Hi Bin,

Quoted 82 lines · Bin Meng

Hi Jagan,

Quoted 55 lines · Jagan Teki

Hi Bin,

Quoted 52 lines · Bin Meng

Hi Jagan,

Quoted 49 lines · Jagan Teki

Hi Bin,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 34 lines · Jagan Teki

Hi Bin,

Quoted 31 lines · Bin Meng

Hi Jagan,

Quoted 20 lines · Jagan Teki

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

Quoted 3 lines

SST_WRITE) },

Please check it.

Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.

Quoted 6 lines

Quoted 3 lines

Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.

It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.

No, it is related. See cmd_sf.c:

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

I'm not getting your point- how could it erase use 64K sector size instead of 4K.

It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().

We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.

You previous email already said: the 'sf erase' command depends on *flash->sector_size*

Quoted 11 lines

       /* Compute erase sector and command */
        if (params->flags & SECT_4K) {
                flash->erase_cmd = CMD_ERASE_4K;
                flash->erase_size = 4096;
        } else if (params->flags & SECT_32K) {
                flash->erase_cmd = CMD_ERASE_32K;
                flash->erase_size = 32768;
        } else {
                flash->erase_cmd = CMD_ERASE_64K;
                flash->erase_size = flash->sector_size;
        }

Quoted 3 lines

Here the codes says: *flash->erase_size*

So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.

Example:
"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM,

    SECT_4K | SST_WR},

sf probe gives
sector_size = 64 * 1024 and erase_size = 4096

sf erase 0 100
sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"

Quoted 3 lines

sf erase 0 +100. Sorry for the typo. But looks like you are not really reading the codes.

Worked on too-many overclocked issue, sorry for that.

So, something fixed in sf_probe.c will fix this I guess.

Quoted 13 lines

=> sf probe
SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB, mapped at ffe00000

=> sf erase 0 +100
SF: 65536 bytes @ 0x0 Erased: OK

Tested on two boards, and both shows 64K was erased.

Quoted 4 lines

Example:
"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM,

    SST_WR},

Quoted 8 lines

Quoted 8 lines

sf probe gives
sector_size = 64 * 1024 and erase_size = 64 * 1024

sf erase 0 100
sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"

Still have any concerns, please come to IRC for more discussion

Hi Jagan,

Quoted 110 lines · Jagan Teki

Hi Bin,

Quoted 106 lines · Bin Meng

Hi Jagan,

Quoted 91 lines · Jagan Teki

Hi Bin,

Quoted 82 lines · Bin Meng

Hi Jagan,

Quoted 55 lines · Jagan Teki

Hi Bin,

Quoted 52 lines · Bin Meng

Hi Jagan,

Quoted 49 lines · Jagan Teki

Hi Bin,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 34 lines · Jagan Teki

Hi Bin,

Quoted 31 lines · Bin Meng

Hi Jagan,

Quoted 20 lines · Jagan Teki

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a "sector" by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.

Linux does follow the same-

        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |

Quoted 3 lines

SST_WRITE) },

Please check it.

Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.

Quoted 6 lines

Quoted 3 lines

Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.

It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.

No, it is related. See cmd_sf.c:

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

I'm not getting your point- how could it erase use 64K sector size instead of 4K.

It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().

We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.

You previous email already said: the 'sf erase' command depends on *flash->sector_size*

Quoted 11 lines

       /* Compute erase sector and command */
        if (params->flags & SECT_4K) {
                flash->erase_cmd = CMD_ERASE_4K;
                flash->erase_size = 4096;
        } else if (params->flags & SECT_32K) {
                flash->erase_cmd = CMD_ERASE_32K;
                flash->erase_size = 32768;
        } else {
                flash->erase_cmd = CMD_ERASE_64K;
                flash->erase_size = flash->sector_size;
        }

Quoted 3 lines

Here the codes says: *flash->erase_size*

So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.

Example:
"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM,

Quoted 8 lines

    SECT_4K | SST_WR},

sf probe gives
sector_size = 64 * 1024 and erase_size = 4096

sf erase 0 100
sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"

sf erase 0 +100. Sorry for the typo. But looks like you are not really reading the codes.

Quoted 3 lines

Worked on too-many overclocked issue, sorry for that.

So, something fixed in sf_probe.c will fix this I guess.

Good, you finally got it! So you prefer fixing this inconsistency in sf_probe.c? I guess by overriding flash->sector_size and flash->nr_sectors if SECT_4K?

Quoted 14 lines

Quoted 14 lines

=> sf probe
SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB, mapped at ffe00000

=> sf erase 0 +100
SF: 65536 bytes @ 0x0 Erased: OK

Tested on two boards, and both shows 64K was erased.

Quoted 4 lines

Example:
"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM,

    SST_WR},

Quoted 9 lines

Quoted 8 lines

Quoted 8 lines

sf probe gives
sector_size = 64 * 1024 and erase_size = 64 * 1024

sf erase 0 100
sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"

Still have any concerns, please come to IRC for more discussion

As you see I have rebased this patch once for v2/v3 and lots of effort were spent on this series. I remember you said this patch series needs some testing on your side, but this comment shows that you may want to do it in another way. I really hope such comments could be sent months ago. Today I can't even remember all of the details in this series. Luckily I don't lose interest to get this upstream so I kept asking for an update.

Update flash sector size to 4KiB as long as flash supports sector erase (20h) command. Correct AT25DF321 JEDEC ID and bulk erase command to 50h instead of D8h. Also add AT25DF321A params per datasheet.

Signed-off-by Bin Meng <[email protected]>

---

  drivers/mtd/spi/sf_internal.h |  5 +++++
  drivers/mtd/spi/sf_params.c   | 17 +++++++++--------
  drivers/mtd/spi/sf_probe.c    |  4 ++++
  3 files changed, 18 insertions(+), 8 deletions(-)

drivers/mtd/spi/sf_internal.h +5 -0

index 785f7a9..8010fc5 100644
@@ -106,6 +106,11 @@ enum {
  #define SPI_FLASH_PAGE_ERASE_TIMEOUT		(5 * CONFIG_SYS_HZ)
  #define SPI_FLASH_SECTOR_ERASE_TIMEOUT	(10 * CONFIG_SYS_HZ)
 
+/* Atmel specific */
+#ifdef CONFIG_SPI_FLASH_ATMEL
+# define CMD_ATMEL_BLK_ERASE	0x50
+#endif
+
  /* SST specific */
  #ifdef CONFIG_SPI_FLASH_SST
  # define CMD_SST_BP		0x02    /* Byte Program */

drivers/mtd/spi/sf_params.c +0 -4

index 5482700..cc4cd60 100644
@@ -15,14 +15,15 @@
  /* SPI/QSPI flash device params structure */
  const struct spi_flash_params spi_flash_params_table[] = {
  #ifdef CONFIG_SPI_FLASH_ATMEL		/* ATMEL */
-	{"AT45DB011D",	   0x1f2200, 0x0,	64 * 1024,     4, RD_NORM,		    SECT_4K},
-	{"AT45DB021D",	   0x1f2300, 0x0,	64 * 1024,     8, RD_NORM,		    SECT_4K},
-	{"AT45DB041D",	   0x1f2400, 0x0,	64 * 1024,     8, RD_NORM,		    SECT_4K},
-	{"AT45DB081D",	   0x1f2500, 0x0,	64 * 1024,    16, RD_NORM,		    SECT_4K},

drivers/mtd/spi/sf_params.c +3 -0

+	{"AT45DB641D",	   0x1f2800, 0x0,	 2 * 1024,  4096, RD_NORM,		          0},
+	{"AT25DF321",      0x1f4700, 0x0,	 4 * 1024,  1024, RD_NORM,		    SECT_4K},
+	{"AT25DF321A",     0x1f4701, 0x0,	 4 * 1024,  1024, RD_NORM,		    SECT_4K},
  #endif
  #ifdef CONFIG_SPI_FLASH_EON		/* EON */
  	{"EN25Q32B",	   0x1c3016, 0x0,	64 * 1024,    64, RD_NORM,			  0},

drivers/mtd/spi/sf_probe.c +0 -0

index ce9987f..13fda44 100644
@@ -179,7 +179,11 @@ static int spi_flash_validate_params(struct spi_slave *spi, u8 *idcode,
  		flash->erase_cmd = CMD_ERASE_32K;

Hi Meng,

Quoted 58 lines · Bin Meng

Update flash sector size to 4KiB as long as flash supports sector erase (20h) command. Correct AT25DF321 JEDEC ID and bulk erase command to 50h instead of D8h. Also add AT25DF321A params per datasheet.

Signed-off-by Bin Meng <[email protected]>

---

  drivers/mtd/spi/sf_internal.h |  5 +++++
  drivers/mtd/spi/sf_params.c   | 17 +++++++++--------
  drivers/mtd/spi/sf_probe.c    |  4 ++++
  3 files changed, 18 insertions(+), 8 deletions(-)

drivers/mtd/spi/sf_internal.h +5 -0

index 785f7a9..8010fc5 100644
@@ -106,6 +106,11 @@ enum {
  #define SPI_FLASH_PAGE_ERASE_TIMEOUT          (5 * CONFIG_SYS_HZ)
  #define SPI_FLASH_SECTOR_ERASE_TIMEOUT        (10 * CONFIG_SYS_HZ)
 
+/* Atmel specific */
+#ifdef CONFIG_SPI_FLASH_ATMEL
+# define CMD_ATMEL_BLK_ERASE   0x50
+#endif
+
  /* SST specific */
  #ifdef CONFIG_SPI_FLASH_SST
  # define CMD_SST_BP           0x02    /* Byte Program */

drivers/mtd/spi/sf_params.c +0 -6

index 5482700..cc4cd60 100644
@@ -15,14 +15,15 @@
  /* SPI/QSPI flash device params structure */
  const struct spi_flash_params spi_flash_params_table[] = {
  #ifdef CONFIG_SPI_FLASH_ATMEL         /* ATMEL */
-       {"AT45DB011D",     0x1f2200, 0x0,       64 * 1024,     4, RD_NORM,
 SECT_4K},
-       {"AT45DB021D",     0x1f2300, 0x0,       64 * 1024,     8, RD_NORM,
 SECT_4K},
-       {"AT45DB041D",     0x1f2400, 0x0,       64 * 1024,     8, RD_NORM,
 SECT_4K},
-       {"AT45DB081D",     0x1f2500, 0x0,       64 * 1024,    16, RD_NORM,
 SECT_4K},
-       {"AT45DB161D",     0x1f2600, 0x0,       64 * 1024,    32, RD_NORM,
 SECT_4K},
-       {"AT45DB321D",     0x1f2700, 0x0,       64 * 1024,    64, RD_NORM,

SECT_4K},
- {"AT45DB641D", 0x1f2800, 0x0, 64 * 1024, 128, RD_NORM,
SECT_4K},
- {"AT25DF321", 0x1f4701, 0x0, 64 * 1024, 64, RD_NORM,
SECT_4K},
+ {"AT45DB011D", 0x1f2200, 0x0, 2 * 1024, 64, RD_NORM,
0},
+ {"AT45DB021D", 0x1f2300, 0x0, 2 * 1024, 128, RD_NORM,
0},

Quoted 8 lines

+ {"AT45DB041D", 0x1f2400, 0x0, 2 * 1024, 256, RD_NORM,
0},
+ {"AT45DB081D", 0x1f2500, 0x0, 2 * 1024, 512, RD_NORM,
0},
+ {"AT45DB161D", 0x1f2600, 0x0, 4 * 1024, 512, RD_NORM,
0},
+ {"AT45DB321D", 0x1f2700, 0x0, 4 * 1024, 1024, RD_NORM,
0},

In datasheet, the id is 0x1f2701. Doc number is: 3597Q-DFLASH-6/11. I can not find any new datasheet.

And I test on at91sam9m10g45ek board, it also read as this ID (0x1f2701).

So, if you plan to send new version, can you help add this ID? If not, maybe follow up patch will be better.

Update supported read commands for EON flash parts to RD_EXTN and QUAD_IO_FAST per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.

Signed-off-by Bin Meng <[email protected]>

---

 drivers/mtd/spi/sf_params.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/mtd/spi/sf_params.c +0 -0

index cc4cd60..3e5c6e0 100644
@@ -26,10 +26,10 @@ const struct spi_flash_params spi_flash_params_table[] = {
        {"AT25DF321A",     0x1f4701, 0x0,        4 * 1024,  1024, RD_NORM,                  SECT_4K},

drivers/mtd/spi/sf_params.c +0 -1

 #endif
 #ifdef CONFIG_SPI_FLASH_GIGADEVICE     /* GIGADEVICE */
        {"GD25Q64B",       0xc84017, 0x0,       64 * 1024,   128, RD_NORM,                  SECT_4K},
--

1.8.2.1

Hi Bin,

Quoted 20 lines · Bin Meng

Update supported read commands for EON flash parts to RD_EXTN and QUAD_IO_FAST per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.

Signed-off-by Bin Meng <[email protected]>

---

 drivers/mtd/spi/sf_params.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/mtd/spi/sf_params.c +0 -2

index cc4cd60..3e5c6e0 100644
@@ -26,10 +26,10 @@ const struct spi_flash_params spi_flash_params_table[] = {
        {"AT25DF321A",     0x1f4701, 0x0,        4 * 1024,  1024, RD_NORM,                  SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_EON            /* EON */
-       {"EN25Q32B",       0x1c3016, 0x0,       64 * 1024,    64, RD_NORM,                        0},
-       {"EN25Q64",        0x1c3017, 0x0,       64 * 1024,   128, RD_NORM,                  SECT_4K},

drivers/mtd/spi/sf_params.c const struct spi_flash_params spi_flash_params_table[] = { · line 32

Quoted 6 lines

drivers/mtd/spi/sf_params.c +4 -2

-       {"EN25Q128B",      0x1c3018, 0x0,       64 * 1024,   256, RD_NORM,                        0},
-       {"EN25S64",        0x1c3817, 0x0,       64 * 1024,   128, RD_NORM,                        0},
+       {"EN25Q32B",       0x1c3016, 0x0,        4 * 1024,  1024, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
+       {"EN25Q64",        0x1c3017, 0x0,        4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
+       {"EN25Q128B",      0x1c3018, 0x0,        4 * 1024,  4096, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
+       {"EN25S64",        0x1c3817, 0x0,        4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,   SECT_4K},

Did you test this QUAD_IO_FAST ?

Update supported read commands for Spansion flash parts per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.

Signed-off-by Bin Meng <[email protected]>

---

 drivers/mtd/spi/sf_params.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

drivers/mtd/spi/sf_params.c +0 -1

index 77aa95b..5a3a434 100644
@@ -52,14 +52,14 @@ const struct spi_flash_params spi_flash_params_table[] = {
        {"S25FL016A",      0x010214, 0x0,       64 * 1024,    32, RD_NORM,                        0},
        {"S25FL032A",      0x010215, 0x0,       64 * 1024,    64, RD_NORM,                        0},
        {"S25FL064A",      0x010216, 0x0,       64 * 1024,   128, RD_NORM,                        0},
-       {"S25FL128P_256K", 0x012018, 0x0300,   256 * 1024,    64, RD_FULL,                   WR_QPP},

drivers/mtd/spi/sf_params.c +1 -2

        {"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,                   WR_QPP},
-       {"S25FL256S_64K",  0x010219, 0x4d01,    64 * 1024,   512, RD_FULL,                   WR_QPP},
+       {"S25FL256S_64K",  0x010219, 0x4d01,     4 * 1024,  8192, RD_FULL,         WR_QPP | SECT_4K},
        {"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256, RD_FULL,                   WR_QPP},
        {"S25FL512S_64K",  0x010220, 0x4d01,    64 * 1024,  1024, RD_FULL,                   WR_QPP},
        {"S25FL512S_512K", 0x010220, 0x4f00,   256 * 1024,   256, RD_FULL,                   WR_QPP},
--

1.8.2.1

Hi Bin,

Quoted 25 lines · Bin Meng

Update supported read commands for Spansion flash parts per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.

Signed-off-by Bin Meng <[email protected]>

---

 drivers/mtd/spi/sf_params.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

drivers/mtd/spi/sf_params.c +3 -4

index 77aa95b..5a3a434 100644
@@ -52,14 +52,14 @@ const struct spi_flash_params spi_flash_params_table[] = {
        {"S25FL016A",      0x010214, 0x0,       64 * 1024,    32, RD_NORM,                        0},
        {"S25FL032A",      0x010215, 0x0,       64 * 1024,    64, RD_NORM,                        0},
        {"S25FL064A",      0x010216, 0x0,       64 * 1024,   128, RD_NORM,                        0},
-       {"S25FL128P_256K", 0x012018, 0x0300,   256 * 1024,    64, RD_FULL,                   WR_QPP},
-       {"S25FL128P_64K",  0x012018, 0x0301,    64 * 1024,   256, RD_FULL,                   WR_QPP},
-       {"S25FL032P",      0x010215, 0x4d00,    64 * 1024,    64, RD_FULL,                   WR_QPP},
-       {"S25FL064P",      0x010216, 0x4d00,    64 * 1024,   128, RD_FULL,                   WR_QPP},
+       {"S25FL128P_256K", 0x012018, 0x0300,   256 * 1024,    64, RD_NORM,                        0},
+       {"S25FL128P_64K",  0x012018, 0x0301,    64 * 1024,   256, RD_NORM,                        0},
+       {"S25FL032P",      0x010215, 0x4d00,     4 * 1024,  1024, RD_FULL,         WR_QPP | SECT_4K},

drivers/mtd/spi/sf_params.c const struct spi_flash_params spi_flash_params_table[] = { · line 60

Quoted 4 lines

drivers/mtd/spi/sf_params.c +2 -1

+       {"S25FL064P",      0x010216, 0x4d00,     4 * 1024,  2048, RD_FULL,         WR_QPP | SECT_4K},
        {"S25FL128S_256K", 0x012018, 0x4d00,   256 * 1024,    64, RD_FULL,                   WR_QPP},
-       {"S25FL128S_64K",  0x012018, 0x4d01,    64 * 1024,   256, RD_FULL,                   WR_QPP},
+       {"S25FL128S_64K",  0x012018, 0x4d01,     4 * 1024,  4096, RD_FULL,         WR_QPP | SECT_4K},

This is incorrect - 64 is the sector size and it should be 64 * 1024 and 4 * 1024 is not working
on my latest test - please verify the same.

Quoted 10 lines

drivers/mtd/spi/sf_params.c +1 -2

        {"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,                   WR_QPP},
-       {"S25FL256S_64K",  0x010219, 0x4d01,    64 * 1024,   512, RD_FULL,                   WR_QPP},
+       {"S25FL256S_64K",  0x010219, 0x4d01,     4 * 1024,  8192, RD_FULL,         WR_QPP | SECT_4K},
        {"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256, RD_FULL,                   WR_QPP},
        {"S25FL512S_64K",  0x010220, 0x4d01,    64 * 1024,  1024, RD_FULL,                   WR_QPP},
        {"S25FL512S_512K", 0x010220, 0x4f00,   256 * 1024,   256, RD_FULL,                   WR_QPP},
--

1.8.2.1

thanks!
--
Jagan.

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

 drivers/mtd/spi/sf_internal.h |   5 ++
 drivers/mtd/spi/sf_params.c   | 185 ++++++++++++++++++++++--------------------
 drivers/mtd/spi/sf_probe.c    |   4 +
 3 files changed, 104 insertions(+), 90 deletions(-)

--
1.8.2.1

Hi Bin,

Quoted 10 lines · Bin Meng

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Quoted 10 lines

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Thanks for the updates - have you verified these changes?

Quoted 6 lines

 drivers/mtd/spi/sf_internal.h |   5 ++
 drivers/mtd/spi/sf_params.c   | 185 ++++++++++++++++++++++--------------------
 drivers/mtd/spi/sf_probe.c    |   4 +
 3 files changed, 104 insertions(+), 90 deletions(-)

Quoted 3 lines

--
1.8.2.1

thanks!
--
Jagan.

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

Quoted 20 lines · Bin Meng

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Quoted 6 lines

Quoted 6 lines

 drivers/mtd/spi/sf_internal.h |   5 ++
 drivers/mtd/spi/sf_params.c   | 185 ++++++++++++++++++++++--------------------
 drivers/mtd/spi/sf_probe.c    |   4 +
 3 files changed, 104 insertions(+), 90 deletions(-)

Hi Bin,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

Quoted 20 lines · Bin Meng

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 8 lines

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Let me know your inputs?

Hi Jagan,

Quoted 42 lines · Jagan Teki

Hi Bin,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

Quoted 20 lines · Bin Meng

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 8 lines

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Quoted 1 line

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Hi Jagan,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 42 lines · Jagan Teki

Hi Bin,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

Quoted 20 lines · Bin Meng

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 8 lines

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Quoted 8 lines

Quoted 1 line

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

Quoted 57 lines · Bin Meng

Hi Jagan,

Quoted 53 lines · Bin Meng

Hi Jagan,

Quoted 39 lines · Jagan Teki

Hi Bin,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

Quoted 20 lines · Bin Meng

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 8 lines

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Quoted 4 lines

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Quoted 3 lines

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

Hi Jagan,

Quoted 62 lines · Jagan Teki

Quoted 60 lines · Bin Meng

Hi Jagan,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 42 lines · Jagan Teki

Hi Bin,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

Quoted 20 lines · Bin Meng

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 8 lines

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Quoted 8 lines

Quoted 1 line

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

Quoted 3 lines

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Quoted 69 lines · Bin Meng

Hi Jagan,

Quoted 65 lines · Jagan Teki

Quoted 57 lines · Bin Meng

Hi Jagan,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 42 lines · Jagan Teki

Hi Bin,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

Quoted 20 lines · Bin Meng

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 8 lines

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Quoted 8 lines

Quoted 1 line

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Quoted 3 lines

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

Quoted 3 lines

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Yes - about testing.

Hi Jagan,

Quoted 70 lines · Jagan Teki

Quoted 69 lines · Bin Meng

Hi Jagan,

Quoted 65 lines · Jagan Teki

Quoted 57 lines · Bin Meng

Hi Jagan,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 42 lines · Jagan Teki

Hi Bin,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

Quoted 20 lines · Bin Meng

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 8 lines

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Quoted 8 lines

Quoted 1 line

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Quoted 3 lines

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

Quoted 6 lines

Quoted 3 lines

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Yes - about testing.

Ping? What about your test results about this patch series?

Quoted 80 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 65 lines · Bin Meng

Hi Jagan,

Quoted 62 lines · Jagan Teki

Quoted 60 lines · Bin Meng

Hi Jagan,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 42 lines · Jagan Teki

Hi Bin,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

Quoted 20 lines · Bin Meng

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 8 lines

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Quoted 8 lines

Quoted 1 line

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

Quoted 7 lines

Quoted 3 lines

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Yes - about testing.

Quoted 1 line

Ping? What about your test results about this patch series?

Some were pending - Will comment, pls- wait.

thanks!
--

Hi Jagan,

Quoted 83 lines · Jagan Teki

Quoted 81 lines · Bin Meng

Hi Jagan,

Quoted 70 lines · Jagan Teki

Quoted 69 lines · Bin Meng

Hi Jagan,

Quoted 65 lines · Jagan Teki

Quoted 57 lines · Bin Meng

Hi Jagan,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 42 lines · Jagan Teki

Hi Bin,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

Quoted 20 lines · Bin Meng

This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 8 lines

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Quoted 8 lines

Quoted 1 line

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Quoted 3 lines

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

Quoted 6 lines

Quoted 3 lines

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Yes - about testing.

Ping? What about your test results about this patch series?

Quoted 4 lines

Some were pending - Will comment, pls- wait.

thanks!
--

I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?

Hi Jagan,

Quoted 91 lines · Bin Meng

Hi Jagan,

Quoted 87 lines · Jagan Teki

Quoted 73 lines · Bin Meng

Hi Jagan,

Quoted 70 lines · Jagan Teki

Quoted 69 lines · Bin Meng

Hi Jagan,

Quoted 65 lines · Jagan Teki

Quoted 57 lines · Bin Meng

Hi Jagan,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 42 lines · Jagan Teki

Hi Bin,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

Quoted 20 lines · Bin Meng

This series update SPI flash supported read commands per datasheet
in the flash params table, and change flash sector size to 4KiB as
long as flash supports sector erase (20h) command, to ensure
'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 8 lines

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Quoted 8 lines

Quoted 1 line

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Quoted 3 lines

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Yes - about testing.

Ping? What about your test results about this patch series?

Some were pending - Will comment, pls- wait.

thanks!
--

Quoted 4 lines

I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?

Could you respond this? I wonder if this series could be merged in before MW is closed.

+Tom

Hi Jagan,

Quoted 99 lines · Bin Meng

Hi Jagan,

Quoted 95 lines · Bin Meng

Hi Jagan,

Quoted 81 lines · Jagan Teki

Quoted 80 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 65 lines · Bin Meng

Hi Jagan,

Quoted 62 lines · Jagan Teki

Quoted 60 lines · Bin Meng

Hi Jagan,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 42 lines · Jagan Teki

Hi Bin,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 24 lines · Jagan Teki

Hi Bin,

On 10 December 2014 at 18:21, Bin Meng <[email protected]> wrote:
This series update SPI flash supported read commands per datasheet
in the flash params table, and change flash sector size to 4KiB as
long as flash supports sector erase (20h) command, to ensure
'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Quoted 8 lines

Quoted 1 line

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Quoted 8 lines

Quoted 1 line

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

Quoted 7 lines

Quoted 3 lines

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Yes - about testing.

Quoted 6 lines

Quoted 1 line

Ping? What about your test results about this patch series?

Some were pending - Will comment, pls- wait.

thanks!
--

I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?

Quoted 3 lines

Could you respond this? I wonder if this series could be merged in before MW is closed.

I feel that you did not work on this. Can you please respond with any comments?

Quoted 108 lines · Bin Meng

+Tom

Hi Jagan,

Quoted 102 lines · Bin Meng

Hi Jagan,

Quoted 86 lines · Bin Meng

Hi Jagan,

Quoted 83 lines · Jagan Teki

Quoted 81 lines · Bin Meng

Hi Jagan,

Quoted 70 lines · Jagan Teki

Quoted 69 lines · Bin Meng

Hi Jagan,

Quoted 65 lines · Jagan Teki

Quoted 57 lines · Bin Meng

Hi Jagan,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 42 lines · Jagan Teki

Hi Bin,

Quoted 35 lines · Bin Meng

Hi Jagan,

On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <[email protected]> wrote:
Hi Bin,

On 10 December 2014 at 18:21, Bin Meng <[email protected]> wrote:
This series update SPI flash supported read commands per datasheet
in the flash params table, and change flash sector size to 4KiB as
long as flash supports sector erase (20h) command, to ensure
'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based
on flash datasheet, so if something is broken, eg before this series
the flash advertises only READ_NORM and after my series it is changed
to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
likely that the SPI controller driver has some bugs when supporting
QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.

Quoted 8 lines

Quoted 1 line

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Quoted 3 lines

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

Quoted 6 lines

Quoted 3 lines

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Yes - about testing.

Ping? What about your test results about this patch series?

Quoted 9 lines

Quoted 4 lines

Some were pending - Will comment, pls- wait.

thanks!
--

I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?

Could you respond this? I wonder if this series could be merged in before MW is closed.

Quoted 1 line

I feel that you did not work on this. Can you please respond with any comments?

Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks!

--

Hi Tom,

Quoted 109 lines · Tom Rini

Quoted 108 lines · Bin Meng

+Tom

Hi Jagan,

Quoted 102 lines · Bin Meng

Hi Jagan,

Quoted 86 lines · Bin Meng

Hi Jagan,

Quoted 83 lines · Jagan Teki

Quoted 81 lines · Bin Meng

Hi Jagan,

Quoted 70 lines · Jagan Teki

Quoted 69 lines · Bin Meng

Hi Jagan,

Quoted 65 lines · Jagan Teki

Quoted 57 lines · Bin Meng

Hi Jagan,

Quoted 45 lines · Bin Meng

Hi Jagan,

Quoted 42 lines · Jagan Teki

Hi Bin,

On 11 December 2014 at 08:34, Bin Meng <[email protected]> wrote:
Hi Jagan,

On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <[email protected]> wrote:
Hi Bin,

On 10 December 2014 at 18:21, Bin Meng <[email protected]> wrote:
This series update SPI flash supported read commands per datasheet
in the flash params table, and change flash sector size to 4KiB as
long as flash supports sector erase (20h) command, to ensure
'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based
on flash datasheet, so if something is broken, eg before this series
the flash advertises only READ_NORM and after my series it is changed
to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
likely that the SPI controller driver has some bugs when supporting
QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR.
Will test all the rest (except these) and send the PR soon.

Quoted 8 lines

Quoted 1 line

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.

Quoted 3 lines

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

Quoted 6 lines

Quoted 3 lines

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Yes - about testing.

Ping? What about your test results about this patch series?

Quoted 9 lines

Quoted 4 lines

Some were pending - Will comment, pls- wait.

thanks!
--

I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?

Could you respond this? I wonder if this series could be merged in before MW is closed.

Quoted 6 lines

Quoted 1 line

I feel that you did not work on this. Can you please respond with any comments?

Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks!

--

Thanks for checking. Here you are:

http://patchwork.ozlabs.org/patch/419633/
http://patchwork.ozlabs.org/patch/419634/
http://patchwork.ozlabs.org/patch/419635/
http://patchwork.ozlabs.org/patch/419636/
http://patchwork.ozlabs.org/patch/419637/
http://patchwork.ozlabs.org/patch/419638/
http://patchwork.ozlabs.org/patch/419639/
http://patchwork.ozlabs.org/patch/419640/
http://patchwork.ozlabs.org/patch/419641/

They might not be applied cleanly now due to the significant delay since it was originally posted to the mailing list. So far Jagan pointed out only one issue and he said he would continue looking into the patches but I did not receive any feedback for months.

Quoted 131 lines · Bin Meng

Hi Tom,

Quoted 109 lines · Tom Rini

Quoted 108 lines · Bin Meng

+Tom

Hi Jagan,

Quoted 102 lines · Bin Meng

Hi Jagan,

Quoted 86 lines · Bin Meng

Hi Jagan,

Quoted 83 lines · Jagan Teki

Quoted 81 lines · Bin Meng

Hi Jagan,

Quoted 70 lines · Jagan Teki

Quoted 69 lines · Bin Meng

Hi Jagan,

Quoted 65 lines · Jagan Teki

Quoted 57 lines · Bin Meng

Hi Jagan,

Quoted 53 lines · Bin Meng

Hi Jagan,

On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <[email protected]> wrote:
Hi Bin,

On 11 December 2014 at 08:34, Bin Meng <[email protected]> wrote:
Hi Jagan,

On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <[email protected]> wrote:
Hi Bin,

On 10 December 2014 at 18:21, Bin Meng <[email protected]> wrote:
This series update SPI flash supported read commands per datasheet
in the flash params table, and change flash sector size to 4KiB as
long as flash supports sector erase (20h) command, to ensure
'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based
on flash datasheet, so if something is broken, eg before this series
the flash advertises only READ_NORM and after my series it is changed
to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
likely that the SPI controller driver has some bugs when supporting
QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR.
Will test all the rest (except these) and send the PR soon.

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which
modify the same sf_params.c to introduce more flash support. We can
test these updates and if everything looks fine, apply these first and
ask other commits to rebase on this series to introduce more flash
support.

Quoted 3 lines

Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

Quoted 6 lines

Quoted 3 lines

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Yes - about testing.

Ping? What about your test results about this patch series?

Quoted 9 lines

Quoted 4 lines

Some were pending - Will comment, pls- wait.

thanks!
--

I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?

Could you respond this? I wonder if this series could be merged in before MW is closed.

Quoted 6 lines

Quoted 1 line

I feel that you did not work on this. Can you please respond with any comments?

Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks!

--

Thanks for checking. Here you are:

http://patchwork.ozlabs.org/patch/419633/
http://patchwork.ozlabs.org/patch/419634/
http://patchwork.ozlabs.org/patch/419635/
http://patchwork.ozlabs.org/patch/419636/
http://patchwork.ozlabs.org/patch/419637/
http://patchwork.ozlabs.org/patch/419638/
http://patchwork.ozlabs.org/patch/419639/
http://patchwork.ozlabs.org/patch/419640/
http://patchwork.ozlabs.org/patch/419641/

Quoted 4 lines

They might not be applied cleanly now due to the significant delay since it was originally posted to the mailing list. So far Jagan pointed out only one issue and he said he would continue looking into the patches but I did not receive any feedback for months.

Sorry that I'm in long vacations which is less possible in mailing. As these changes are very crucial, I keep waiting the same.

I will be back on March, end - if still need an urgent sync-up on these changes Tom or Simon please look at the same.

Hi Jagan,

Quoted 137 lines · Jagan Teki

Quoted 135 lines · Bin Meng

Hi Tom,

Quoted 109 lines · Tom Rini

Quoted 108 lines · Bin Meng

+Tom

Hi Jagan,

Quoted 102 lines · Bin Meng

Hi Jagan,

Quoted 86 lines · Bin Meng

Hi Jagan,

Quoted 83 lines · Jagan Teki

Quoted 81 lines · Bin Meng

Hi Jagan,

Quoted 70 lines · Jagan Teki

Quoted 69 lines · Bin Meng

Hi Jagan,

Quoted 65 lines · Jagan Teki

Quoted 60 lines · Bin Meng

Hi Jagan,

On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <[email protected]> wrote:
Hi Jagan,

On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <[email protected]> wrote:
Hi Bin,

On 11 December 2014 at 08:34, Bin Meng <[email protected]> wrote:
Hi Jagan,

On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <[email protected]> wrote:
Hi Bin,

On 10 December 2014 at 18:21, Bin Meng <[email protected]> wrote:
This series update SPI flash supported read commands per datasheet
in the flash params table, and change flash sector size to 4KiB as
long as flash supports sector erase (20h) command, to ensure
'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based
on flash datasheet, so if something is broken, eg before this series
the flash advertises only READ_NORM and after my series it is changed
to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
likely that the SPI controller driver has some bugs when supporting
QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR.
Will test all the rest (except these) and send the PR soon.

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which
modify the same sf_params.c to introduce more flash support. We can
test these updates and if everything looks fine, apply these first and
ask other commits to rebase on this series to introduce more flash
support.

Do you have any additional comments about this patch series besides
the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
the v4.

I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.

Quoted 6 lines

Quoted 3 lines

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Yes - about testing.

Ping? What about your test results about this patch series?

Quoted 9 lines

Quoted 4 lines

Some were pending - Will comment, pls- wait.

thanks!
--

I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?

Could you respond this? I wonder if this series could be merged in before MW is closed.

Quoted 6 lines

Quoted 1 line

I feel that you did not work on this. Can you please respond with any comments?

Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks!

--

Thanks for checking. Here you are:

http://patchwork.ozlabs.org/patch/419633/
http://patchwork.ozlabs.org/patch/419634/
http://patchwork.ozlabs.org/patch/419635/
http://patchwork.ozlabs.org/patch/419636/
http://patchwork.ozlabs.org/patch/419637/
http://patchwork.ozlabs.org/patch/419638/
http://patchwork.ozlabs.org/patch/419639/
http://patchwork.ozlabs.org/patch/419640/
http://patchwork.ozlabs.org/patch/419641/

They might not be applied cleanly now due to the significant delay since it was originally posted to the mailing list. So far Jagan pointed out only one issue and he said he would continue looking into the patches but I did not receive any feedback for months.

Quoted 2 lines

Sorry that I'm in long vacations which is less possible in mailing. As these changes are very crucial, I keep waiting the same.

What are you waiting for? Do you mean you have some sort of testing out there in the background and you don't have complete test result yet?

Quoted 4 lines

I will be back on March, end - if still need an urgent sync-up on these changes Tom or Simon please look at the same.

OK, so this series will for sure miss the v2015.04 release (it already missed the v2015.01 release before)

Quoted 140 lines · Bin Meng

Hi Jagan,

Quoted 137 lines · Jagan Teki

Quoted 135 lines · Bin Meng

Hi Tom,

Quoted 109 lines · Tom Rini

Quoted 108 lines · Bin Meng

+Tom

Hi Jagan,

Quoted 102 lines · Bin Meng

Hi Jagan,

Quoted 86 lines · Bin Meng

Hi Jagan,

Quoted 83 lines · Jagan Teki

Quoted 81 lines · Bin Meng

Hi Jagan,

Quoted 70 lines · Jagan Teki

Quoted 69 lines · Bin Meng

Hi Jagan,

Quoted 65 lines · Jagan Teki

On 15 December 2014 at 19:21, Bin Meng <[email protected]> wrote:
Hi Jagan,

On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <[email protected]> wrote:
Hi Jagan,

On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <[email protected]> wrote:
Hi Bin,

On 11 December 2014 at 08:34, Bin Meng <[email protected]> wrote:
Hi Jagan,

On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <[email protected]> wrote:
Hi Bin,

On 10 December 2014 at 18:21, Bin Meng <[email protected]> wrote:
This series update SPI flash supported read commands per datasheet
in the flash params table, and change flash sector size to 4KiB as
long as flash supports sector erase (20h) command, to ensure
'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/

Bin Meng (9):
sf: Update SST flash params
sf: Update Atmel flash params
sf: Update EON flash params
sf: Update GigaDevice flash params
sf: Update Macronix flash params
sf: Update Spansion flash params
sf: Update Micron flash params
sf: Update Winbond flash params
sf: Give proper spacing between flash table params

Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based
on flash datasheet, so if something is broken, eg before this series
the flash advertises only READ_NORM and after my series it is changed
to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
likely that the SPI controller driver has some bugs when supporting
QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR.
Will test all the rest (except these) and send the PR soon.

Let me know your inputs?

I am fine, as long as this PR will not contains other commits which
modify the same sf_params.c to introduce more flash support. We can
test these updates and if everything looks fine, apply these first and
ask other commits to rebase on this series to introduce more flash
support.

Do you have any additional comments about this patch series besides
the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
the v4.

I'm thinking about the other flashes too, since these params were taken from
previous working and Linux mtd.

Quoted 6 lines

Quoted 3 lines

You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.

Yes - about testing.

Ping? What about your test results about this patch series?

Quoted 9 lines

Quoted 4 lines

Some were pending - Will comment, pls- wait.

thanks!
--

I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?

Could you respond this? I wonder if this series could be merged in before MW is closed.

Quoted 6 lines

Quoted 1 line

I feel that you did not work on this. Can you please respond with any comments?

Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks!

--

Thanks for checking. Here you are:

http://patchwork.ozlabs.org/patch/419633/
http://patchwork.ozlabs.org/patch/419634/
http://patchwork.ozlabs.org/patch/419635/
http://patchwork.ozlabs.org/patch/419636/
http://patchwork.ozlabs.org/patch/419637/
http://patchwork.ozlabs.org/patch/419638/
http://patchwork.ozlabs.org/patch/419639/
http://patchwork.ozlabs.org/patch/419640/
http://patchwork.ozlabs.org/patch/419641/

They might not be applied cleanly now due to the significant delay since it was originally posted to the mailing list. So far Jagan pointed out only one issue and he said he would continue looking into the patches but I did not receive any feedback for months.

Quoted 6 lines

Quoted 2 lines

Sorry that I'm in long vacations which is less possible in mailing. As these changes are very crucial, I keep waiting the same.

What are you waiting for? Do you mean you have some sort of testing out there in the background and you don't have complete test result yet?

I mean I did some testing, and moved my wedding vacations(currently IN) I will look at it after 25 March, if still you feel these are urgent.

Please test it all possible flashes (atleast once) then may be Tom/Simon will look those (if possible I will comment on testings).

I do have some flashes on my hand to verify but currently I'm busy with my vacations,
once I switch back to work may be will look at and finalize the same.

Quoted 7 lines

Quoted 4 lines

I will be back on March, end - if still need an urgent sync-up on these changes Tom or Simon please look at the same.

OK, so this series will for sure miss the v2015.04 release (it already missed the v2015.01 release before)