* [PATCH V3 0/3] mtd: use the full-id as the keyword
@ 2013-01-28 4:57 Huang Shijie
2013-01-28 4:57 ` [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} Huang Shijie
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Huang Shijie @ 2013-01-28 4:57 UTC (permalink / raw)
To: dwmw2; +Cc: dedekind1, computersforpeace, linux-mtd, linux-kernel
From: Huang Shijie <b32955@freescale.com>
I ever submitted a patch to use the full-id as the keyword for
some unparsable nand chips. This is the second tries.
As time goes on, we begin to meet the situation that we can not
get enough information from some nand chips's id data.
Take some Toshiba's nand chips for example.
I have 4 Toshiba's nand chips in my hand:
TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2
When we read these chips' datasheets, we will get the geometry of these chips:
TC58NVG2S0F : 4096 + 224
TC58NVG3S0F : 4096 + 232
TC58NVG5D2 : 8192 + 640
TC58NVG6D2 : 8192 + 640
But we can not parse out the correct oob size for these chips from the id data.
So it is time to add some new fields to the nand_flash_dev{},
and update the detection mechanisms.
v2 --> v3:
[1] remove the duplicated header.
[2] remove the field "ecc_len" in nand_flash_dev{}.
[3] fix some coding style warnings.
[4] add more comments
Huang Shijie (3):
mtd: add new fields to nand_flash_dev{}
mtd: add a new table for the unparsable nand chips
mtd: add the new detection method for the unparsable nand chips
drivers/mtd/devices/doc2000.c | 2 +-
drivers/mtd/devices/doc2001.c | 2 +-
drivers/mtd/devices/doc2001plus.c | 2 +-
drivers/mtd/nand/nand_base.c | 35 ++++++-
drivers/mtd/nand/nand_ids.c | 217 +++++++++++++++++++++----------------
drivers/mtd/nand/nandsim.c | 2 +-
drivers/mtd/nand/pxa3xx_nand.c | 2 +-
drivers/mtd/nand/sm_common.c | 61 +++++------
include/linux/mtd/nand.h | 9 ++-
9 files changed, 201 insertions(+), 131 deletions(-)
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-01-28 4:57 [PATCH V3 0/3] mtd: use the full-id as the keyword Huang Shijie @ 2013-01-28 4:57 ` Huang Shijie 2013-02-12 15:47 ` Artem Bityutskiy 2013-03-02 14:19 ` Artem Bityutskiy 2013-01-28 4:57 ` [PATCH V3 2/3] mtd: add a new table for the unparsable nand chips Huang Shijie 2013-01-28 4:57 ` [PATCH V3 3/3] mtd: add the new detection method " Huang Shijie 2 siblings, 2 replies; 21+ messages in thread From: Huang Shijie @ 2013-01-28 4:57 UTC (permalink / raw) To: dwmw2; +Cc: dedekind1, computersforpeace, linux-mtd, linux-kernel, Huang Shijie As time goes on, we begin to meet the situation that we can not get enough information from some nand chips's id data. Take some Toshiba's nand chips for example. I have 4 Toshiba's nand chips in my hand: TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2 When we read these chips' datasheets, we will get the geometry of these chips: TC58NVG2S0F : 4096 + 224 TC58NVG3S0F : 4096 + 232 TC58NVG5D2 : 8192 + 640 TC58NVG6D2 : 8192 + 640 But we can not parse out the correct oob size for these chips from the id data. So it is time to add some new fields to the nand_flash_dev{}, and update the detection mechanisms. This patch just adds some new fields to the nand_flash_dev{}: @id[8] : the 8 bytes id data. @id_len: the valid length of the id data. @oobsize: the oob size. Signed-off-by: Huang Shijie <b32955@freescale.com> --- drivers/mtd/devices/doc2000.c | 2 +- drivers/mtd/devices/doc2001.c | 2 +- drivers/mtd/devices/doc2001plus.c | 2 +- drivers/mtd/nand/nand_base.c | 2 +- drivers/mtd/nand/nand_ids.c | 196 ++++++++++++++++++++----------------- drivers/mtd/nand/nandsim.c | 2 +- drivers/mtd/nand/pxa3xx_nand.c | 2 +- drivers/mtd/nand/sm_common.c | 61 ++++++------ include/linux/mtd/nand.h | 8 +- 9 files changed, 147 insertions(+), 130 deletions(-) diff --git a/drivers/mtd/devices/doc2000.c b/drivers/mtd/devices/doc2000.c index a4eb8b5..93f037f 100644 --- a/drivers/mtd/devices/doc2000.c +++ b/drivers/mtd/devices/doc2000.c @@ -379,7 +379,7 @@ static int DoC_IdentChip(struct DiskOnChip *doc, int floor, int chip) /* Print and store the manufacturer and ID codes. */ for (i = 0; nand_flash_ids[i].name != NULL; i++) { - if (id == nand_flash_ids[i].id) { + if (id == nand_flash_ids[i].id[1]) { /* Try to identify manufacturer */ for (j = 0; nand_manuf_ids[j].id != 0x0; j++) { if (nand_manuf_ids[j].id == mfr) diff --git a/drivers/mtd/devices/doc2001.c b/drivers/mtd/devices/doc2001.c index f692795..15dd177 100644 --- a/drivers/mtd/devices/doc2001.c +++ b/drivers/mtd/devices/doc2001.c @@ -206,7 +206,7 @@ static int DoC_IdentChip(struct DiskOnChip *doc, int floor, int chip) /* FIXME: to deal with multi-flash on multi-Millennium case more carefully */ for (i = 0; nand_flash_ids[i].name != NULL; i++) { - if ( id == nand_flash_ids[i].id) { + if (id == nand_flash_ids[i].id[1]) { /* Try to identify manufacturer */ for (j = 0; nand_manuf_ids[j].id != 0x0; j++) { if (nand_manuf_ids[j].id == mfr) diff --git a/drivers/mtd/devices/doc2001plus.c b/drivers/mtd/devices/doc2001plus.c index 4f2220a..80aef1b 100644 --- a/drivers/mtd/devices/doc2001plus.c +++ b/drivers/mtd/devices/doc2001plus.c @@ -314,7 +314,7 @@ static int DoC_IdentChip(struct DiskOnChip *doc, int floor, int chip) return 0; for (i = 0; nand_flash_ids[i].name != NULL; i++) { - if (id == nand_flash_ids[i].id) { + if (id == nand_flash_ids[i].id[1]) { /* Try to identify manufacturer */ for (j = 0; nand_manuf_ids[j].id != 0x0; j++) { if (nand_manuf_ids[j].id == mfr) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index a8c1fb4..0e80ec4 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3204,7 +3204,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd, type = nand_flash_ids; for (; type->name != NULL; type++) - if (*dev_id == type->id) + if (*dev_id == type->id[1]) break; chip->onfi_version = 0; diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c index e3aa274..99949f6 100644 --- a/drivers/mtd/nand/nand_ids.c +++ b/drivers/mtd/nand/nand_ids.c @@ -10,6 +10,8 @@ */ #include <linux/module.h> #include <linux/mtd/nand.h> +#include <linux/sizes.h> + /* * Chip ID list * @@ -24,47 +26,59 @@ struct nand_flash_dev nand_flash_ids[] = { #ifdef CONFIG_MTD_NAND_MUSEUM_IDS - {"NAND 1MiB 5V 8-bit", 0x6e, 256, 1, 0x1000, 0}, - {"NAND 2MiB 5V 8-bit", 0x64, 256, 2, 0x1000, 0}, - {"NAND 4MiB 5V 8-bit", 0x6b, 512, 4, 0x2000, 0}, - {"NAND 1MiB 3,3V 8-bit", 0xe8, 256, 1, 0x1000, 0}, - {"NAND 1MiB 3,3V 8-bit", 0xec, 256, 1, 0x1000, 0}, - {"NAND 2MiB 3,3V 8-bit", 0xea, 256, 2, 0x1000, 0}, - {"NAND 4MiB 3,3V 8-bit", 0xd5, 512, 4, 0x2000, 0}, - {"NAND 4MiB 3,3V 8-bit", 0xe3, 512, 4, 0x2000, 0}, - {"NAND 4MiB 3,3V 8-bit", 0xe5, 512, 4, 0x2000, 0}, - {"NAND 8MiB 3,3V 8-bit", 0xd6, 512, 8, 0x2000, 0}, - - {"NAND 8MiB 1,8V 8-bit", 0x39, 512, 8, 0x2000, 0}, - {"NAND 8MiB 3,3V 8-bit", 0xe6, 512, 8, 0x2000, 0}, - {"NAND 8MiB 1,8V 16-bit", 0x49, 512, 8, 0x2000, NAND_BUSWIDTH_16}, - {"NAND 8MiB 3,3V 16-bit", 0x59, 512, 8, 0x2000, NAND_BUSWIDTH_16}, + {"NAND 1MiB 5V 8-bit", {0, 0x6e}, 256, 1, 0x1000, 0}, + {"NAND 2MiB 5V 8-bit", {0, 0x64}, 256, 2, 0x1000, 0}, + {"NAND 4MiB 5V 8-bit", {0, 0x6b}, 512, 4, 0x2000, 0}, + {"NAND 1MiB 3,3V 8-bit", {0, 0xe8}, 256, 1, 0x1000, 0}, + {"NAND 1MiB 3,3V 8-bit", {0, 0xec}, 256, 1, 0x1000, 0}, + {"NAND 2MiB 3,3V 8-bit", {0, 0xea}, 256, 2, 0x1000, 0}, + {"NAND 4MiB 3,3V 8-bit", {0, 0xd5}, 512, 4, 0x2000, 0}, + {"NAND 4MiB 3,3V 8-bit", {0, 0xe3}, 512, 4, 0x2000, 0}, + {"NAND 4MiB 3,3V 8-bit", {0, 0xe5}, 512, 4, 0x2000, 0}, + {"NAND 8MiB 3,3V 8-bit", {0, 0xd6}, 512, 8, 0x2000, 0}, + + {"NAND 8MiB 1,8V 8-bit", {0, 0x39}, 512, 8, 0x2000, 0}, + {"NAND 8MiB 3,3V 8-bit", {0, 0xe6}, 512, 8, 0x2000, 0}, + {"NAND 8MiB 1,8V 16-bit", {0, 0x49}, 512, 8, 0x2000, + NAND_BUSWIDTH_16}, + {"NAND 8MiB 3,3V 16-bit", {0, 0x59}, 512, 8, 0x2000, + NAND_BUSWIDTH_16}, #endif - {"NAND 16MiB 1,8V 8-bit", 0x33, 512, 16, 0x4000, 0}, - {"NAND 16MiB 3,3V 8-bit", 0x73, 512, 16, 0x4000, 0}, - {"NAND 16MiB 1,8V 16-bit", 0x43, 512, 16, 0x4000, NAND_BUSWIDTH_16}, - {"NAND 16MiB 3,3V 16-bit", 0x53, 512, 16, 0x4000, NAND_BUSWIDTH_16}, - - {"NAND 32MiB 1,8V 8-bit", 0x35, 512, 32, 0x4000, 0}, - {"NAND 32MiB 3,3V 8-bit", 0x75, 512, 32, 0x4000, 0}, - {"NAND 32MiB 1,8V 16-bit", 0x45, 512, 32, 0x4000, NAND_BUSWIDTH_16}, - {"NAND 32MiB 3,3V 16-bit", 0x55, 512, 32, 0x4000, NAND_BUSWIDTH_16}, - - {"NAND 64MiB 1,8V 8-bit", 0x36, 512, 64, 0x4000, 0}, - {"NAND 64MiB 3,3V 8-bit", 0x76, 512, 64, 0x4000, 0}, - {"NAND 64MiB 1,8V 16-bit", 0x46, 512, 64, 0x4000, NAND_BUSWIDTH_16}, - {"NAND 64MiB 3,3V 16-bit", 0x56, 512, 64, 0x4000, NAND_BUSWIDTH_16}, - - {"NAND 128MiB 1,8V 8-bit", 0x78, 512, 128, 0x4000, 0}, - {"NAND 128MiB 1,8V 8-bit", 0x39, 512, 128, 0x4000, 0}, - {"NAND 128MiB 3,3V 8-bit", 0x79, 512, 128, 0x4000, 0}, - {"NAND 128MiB 1,8V 16-bit", 0x72, 512, 128, 0x4000, NAND_BUSWIDTH_16}, - {"NAND 128MiB 1,8V 16-bit", 0x49, 512, 128, 0x4000, NAND_BUSWIDTH_16}, - {"NAND 128MiB 3,3V 16-bit", 0x74, 512, 128, 0x4000, NAND_BUSWIDTH_16}, - {"NAND 128MiB 3,3V 16-bit", 0x59, 512, 128, 0x4000, NAND_BUSWIDTH_16}, - - {"NAND 256MiB 3,3V 8-bit", 0x71, 512, 256, 0x4000, 0}, + {"NAND 16MiB 1,8V 8-bit", {0, 0x33}, 512, 16, 0x4000, 0}, + {"NAND 16MiB 3,3V 8-bit", {0, 0x73}, 512, 16, 0x4000, 0}, + {"NAND 16MiB 1,8V 16-bit", {0, 0x43}, 512, 16, 0x4000, + NAND_BUSWIDTH_16}, + {"NAND 16MiB 3,3V 16-bit", {0, 0x53}, 512, 16, 0x4000, + NAND_BUSWIDTH_16}, + + {"NAND 32MiB 1,8V 8-bit", {0, 0x35}, 512, 32, 0x4000, 0}, + {"NAND 32MiB 3,3V 8-bit", {0, 0x75}, 512, 32, 0x4000, 0}, + {"NAND 32MiB 1,8V 16-bit", {0, 0x45}, 512, 32, 0x4000, + NAND_BUSWIDTH_16}, + {"NAND 32MiB 3,3V 16-bit", {0, 0x55}, 512, 32, 0x4000, + NAND_BUSWIDTH_16}, + + {"NAND 64MiB 1,8V 8-bit", {0, 0x36}, 512, 64, 0x4000, 0}, + {"NAND 64MiB 3,3V 8-bit", {0, 0x76}, 512, 64, 0x4000, 0}, + {"NAND 64MiB 1,8V 16-bit", {0, 0x46}, 512, 64, 0x4000, + NAND_BUSWIDTH_16}, + {"NAND 64MiB 3,3V 16-bit", {0, 0x56}, 512, 64, 0x4000, + NAND_BUSWIDTH_16}, + + {"NAND 128MiB 1,8V 8-bit", {0, 0x78}, 512, 128, 0x4000, 0}, + {"NAND 128MiB 1,8V 8-bit", {0, 0x39}, 512, 128, 0x4000, 0}, + {"NAND 128MiB 3,3V 8-bit", {0, 0x79}, 512, 128, 0x4000, 0}, + {"NAND 128MiB 1,8V 16-bit", {0, 0x72}, 512, 128, 0x4000, + NAND_BUSWIDTH_16}, + {"NAND 128MiB 1,8V 16-bit", {0, 0x49}, 512, 128, 0x4000, + NAND_BUSWIDTH_16}, + {"NAND 128MiB 3,3V 16-bit", {0, 0x74}, 512, 128, 0x4000, + NAND_BUSWIDTH_16}, + {"NAND 128MiB 3,3V 16-bit", {0, 0x59}, 512, 128, 0x4000, + NAND_BUSWIDTH_16}, + + {"NAND 256MiB 3,3V 8-bit", {0, 0x71}, 512, 256, 0x4000, 0}, /* * These are the new chips with large page size. The pagesize and the @@ -74,77 +88,77 @@ struct nand_flash_dev nand_flash_ids[] = { #define LP_OPTIONS16 (LP_OPTIONS | NAND_BUSWIDTH_16) /* 512 Megabit */ - {"NAND 64MiB 1,8V 8-bit", 0xA2, 0, 64, 0, LP_OPTIONS}, - {"NAND 64MiB 1,8V 8-bit", 0xA0, 0, 64, 0, LP_OPTIONS}, - {"NAND 64MiB 3,3V 8-bit", 0xF2, 0, 64, 0, LP_OPTIONS}, - {"NAND 64MiB 3,3V 8-bit", 0xD0, 0, 64, 0, LP_OPTIONS}, - {"NAND 64MiB 3,3V 8-bit", 0xF0, 0, 64, 0, LP_OPTIONS}, - {"NAND 64MiB 1,8V 16-bit", 0xB2, 0, 64, 0, LP_OPTIONS16}, - {"NAND 64MiB 1,8V 16-bit", 0xB0, 0, 64, 0, LP_OPTIONS16}, - {"NAND 64MiB 3,3V 16-bit", 0xC2, 0, 64, 0, LP_OPTIONS16}, - {"NAND 64MiB 3,3V 16-bit", 0xC0, 0, 64, 0, LP_OPTIONS16}, + {"NAND 64MiB 1,8V 8-bit", {0, 0xA2}, 0, 64, 0, LP_OPTIONS}, + {"NAND 64MiB 1,8V 8-bit", {0, 0xA0}, 0, 64, 0, LP_OPTIONS}, + {"NAND 64MiB 3,3V 8-bit", {0, 0xF2}, 0, 64, 0, LP_OPTIONS}, + {"NAND 64MiB 3,3V 8-bit", {0, 0xD0}, 0, 64, 0, LP_OPTIONS}, + {"NAND 64MiB 3,3V 8-bit", {0, 0xF0}, 0, 64, 0, LP_OPTIONS}, + {"NAND 64MiB 1,8V 16-bit", {0, 0xB2}, 0, 64, 0, LP_OPTIONS16}, + {"NAND 64MiB 1,8V 16-bit", {0, 0xB0}, 0, 64, 0, LP_OPTIONS16}, + {"NAND 64MiB 3,3V 16-bit", {0, 0xC2}, 0, 64, 0, LP_OPTIONS16}, + {"NAND 64MiB 3,3V 16-bit", {0, 0xC0}, 0, 64, 0, LP_OPTIONS16}, /* 1 Gigabit */ - {"NAND 128MiB 1,8V 8-bit", 0xA1, 0, 128, 0, LP_OPTIONS}, - {"NAND 128MiB 3,3V 8-bit", 0xF1, 0, 128, 0, LP_OPTIONS}, - {"NAND 128MiB 3,3V 8-bit", 0xD1, 0, 128, 0, LP_OPTIONS}, - {"NAND 128MiB 1,8V 16-bit", 0xB1, 0, 128, 0, LP_OPTIONS16}, - {"NAND 128MiB 3,3V 16-bit", 0xC1, 0, 128, 0, LP_OPTIONS16}, - {"NAND 128MiB 1,8V 16-bit", 0xAD, 0, 128, 0, LP_OPTIONS16}, + {"NAND 128MiB 1,8V 8-bit", {0, 0xA1}, 0, 128, 0, LP_OPTIONS}, + {"NAND 128MiB 3,3V 8-bit", {0, 0xF1}, 0, 128, 0, LP_OPTIONS}, + {"NAND 128MiB 3,3V 8-bit", {0, 0xD1}, 0, 128, 0, LP_OPTIONS}, + {"NAND 128MiB 1,8V 16-bit", {0, 0xB1}, 0, 128, 0, LP_OPTIONS16}, + {"NAND 128MiB 3,3V 16-bit", {0, 0xC1}, 0, 128, 0, LP_OPTIONS16}, + {"NAND 128MiB 1,8V 16-bit", {0, 0xAD}, 0, 128, 0, LP_OPTIONS16}, /* 2 Gigabit */ - {"NAND 256MiB 1,8V 8-bit", 0xAA, 0, 256, 0, LP_OPTIONS}, - {"NAND 256MiB 3,3V 8-bit", 0xDA, 0, 256, 0, LP_OPTIONS}, - {"NAND 256MiB 1,8V 16-bit", 0xBA, 0, 256, 0, LP_OPTIONS16}, - {"NAND 256MiB 3,3V 16-bit", 0xCA, 0, 256, 0, LP_OPTIONS16}, + {"NAND 256MiB 1,8V 8-bit", {0, 0xAA}, 0, 256, 0, LP_OPTIONS}, + {"NAND 256MiB 3,3V 8-bit", {0, 0xDA}, 0, 256, 0, LP_OPTIONS}, + {"NAND 256MiB 1,8V 16-bit", {0, 0xBA}, 0, 256, 0, LP_OPTIONS16}, + {"NAND 256MiB 3,3V 16-bit", {0, 0xCA}, 0, 256, 0, LP_OPTIONS16}, /* 4 Gigabit */ - {"NAND 512MiB 1,8V 8-bit", 0xAC, 0, 512, 0, LP_OPTIONS}, - {"NAND 512MiB 3,3V 8-bit", 0xDC, 0, 512, 0, LP_OPTIONS}, - {"NAND 512MiB 1,8V 16-bit", 0xBC, 0, 512, 0, LP_OPTIONS16}, - {"NAND 512MiB 3,3V 16-bit", 0xCC, 0, 512, 0, LP_OPTIONS16}, + {"NAND 512MiB 1,8V 8-bit", {0, 0xAC}, 0, 512, 0, LP_OPTIONS}, + {"NAND 512MiB 3,3V 8-bit", {0, 0xDC}, 0, 512, 0, LP_OPTIONS}, + {"NAND 512MiB 1,8V 16-bit", {0, 0xBC}, 0, 512, 0, LP_OPTIONS16}, + {"NAND 512MiB 3,3V 16-bit", {0, 0xCC}, 0, 512, 0, LP_OPTIONS16}, /* 8 Gigabit */ - {"NAND 1GiB 1,8V 8-bit", 0xA3, 0, 1024, 0, LP_OPTIONS}, - {"NAND 1GiB 3,3V 8-bit", 0xD3, 0, 1024, 0, LP_OPTIONS}, - {"NAND 1GiB 1,8V 16-bit", 0xB3, 0, 1024, 0, LP_OPTIONS16}, - {"NAND 1GiB 3,3V 16-bit", 0xC3, 0, 1024, 0, LP_OPTIONS16}, + {"NAND 1GiB 1,8V 8-bit", {0, 0xA3}, 0, 1024, 0, LP_OPTIONS}, + {"NAND 1GiB 3,3V 8-bit", {0, 0xD3}, 0, 1024, 0, LP_OPTIONS}, + {"NAND 1GiB 1,8V 16-bit", {0, 0xB3}, 0, 1024, 0, LP_OPTIONS16}, + {"NAND 1GiB 3,3V 16-bit", {0, 0xC3}, 0, 1024, 0, LP_OPTIONS16}, /* 16 Gigabit */ - {"NAND 2GiB 1,8V 8-bit", 0xA5, 0, 2048, 0, LP_OPTIONS}, - {"NAND 2GiB 3,3V 8-bit", 0xD5, 0, 2048, 0, LP_OPTIONS}, - {"NAND 2GiB 1,8V 16-bit", 0xB5, 0, 2048, 0, LP_OPTIONS16}, - {"NAND 2GiB 3,3V 16-bit", 0xC5, 0, 2048, 0, LP_OPTIONS16}, + {"NAND 2GiB 1,8V 8-bit", {0, 0xA5}, 0, 2048, 0, LP_OPTIONS}, + {"NAND 2GiB 3,3V 8-bit", {0, 0xD5}, 0, 2048, 0, LP_OPTIONS}, + {"NAND 2GiB 1,8V 16-bit", {0, 0xB5}, 0, 2048, 0, LP_OPTIONS16}, + {"NAND 2GiB 3,3V 16-bit", {0, 0xC5}, 0, 2048, 0, LP_OPTIONS16}, /* 32 Gigabit */ - {"NAND 4GiB 1,8V 8-bit", 0xA7, 0, 4096, 0, LP_OPTIONS}, - {"NAND 4GiB 3,3V 8-bit", 0xD7, 0, 4096, 0, LP_OPTIONS}, - {"NAND 4GiB 1,8V 16-bit", 0xB7, 0, 4096, 0, LP_OPTIONS16}, - {"NAND 4GiB 3,3V 16-bit", 0xC7, 0, 4096, 0, LP_OPTIONS16}, + {"NAND 4GiB 1,8V 8-bit", {0, 0xA7}, 0, 4096, 0, LP_OPTIONS}, + {"NAND 4GiB 3,3V 8-bit", {0, 0xD7}, 0, 4096, 0, LP_OPTIONS}, + {"NAND 4GiB 1,8V 16-bit", {0, 0xB7}, 0, 4096, 0, LP_OPTIONS16}, + {"NAND 4GiB 3,3V 16-bit", {0, 0xC7}, 0, 4096, 0, LP_OPTIONS16}, /* 64 Gigabit */ - {"NAND 8GiB 1,8V 8-bit", 0xAE, 0, 8192, 0, LP_OPTIONS}, - {"NAND 8GiB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS}, - {"NAND 8GiB 1,8V 16-bit", 0xBE, 0, 8192, 0, LP_OPTIONS16}, - {"NAND 8GiB 3,3V 16-bit", 0xCE, 0, 8192, 0, LP_OPTIONS16}, + {"NAND 8GiB 1,8V 8-bit", {0, 0xAE}, 0, 8192, 0, LP_OPTIONS}, + {"NAND 8GiB 3,3V 8-bit", {0, 0xDE}, 0, 8192, 0, LP_OPTIONS}, + {"NAND 8GiB 1,8V 16-bit", {0, 0xBE}, 0, 8192, 0, LP_OPTIONS16}, + {"NAND 8GiB 3,3V 16-bit", {0, 0xCE}, 0, 8192, 0, LP_OPTIONS16}, /* 128 Gigabit */ - {"NAND 16GiB 1,8V 8-bit", 0x1A, 0, 16384, 0, LP_OPTIONS}, - {"NAND 16GiB 3,3V 8-bit", 0x3A, 0, 16384, 0, LP_OPTIONS}, - {"NAND 16GiB 1,8V 16-bit", 0x2A, 0, 16384, 0, LP_OPTIONS16}, - {"NAND 16GiB 3,3V 16-bit", 0x4A, 0, 16384, 0, LP_OPTIONS16}, + {"NAND 16GiB 1,8V 8-bit", {0, 0x1A}, 0, 16384, 0, LP_OPTIONS}, + {"NAND 16GiB 3,3V 8-bit", {0, 0x3A}, 0, 16384, 0, LP_OPTIONS}, + {"NAND 16GiB 1,8V 16-bit", {0, 0x2A}, 0, 16384, 0, LP_OPTIONS16}, + {"NAND 16GiB 3,3V 16-bit", {0, 0x4A}, 0, 16384, 0, LP_OPTIONS16}, /* 256 Gigabit */ - {"NAND 32GiB 1,8V 8-bit", 0x1C, 0, 32768, 0, LP_OPTIONS}, - {"NAND 32GiB 3,3V 8-bit", 0x3C, 0, 32768, 0, LP_OPTIONS}, - {"NAND 32GiB 1,8V 16-bit", 0x2C, 0, 32768, 0, LP_OPTIONS16}, - {"NAND 32GiB 3,3V 16-bit", 0x4C, 0, 32768, 0, LP_OPTIONS16}, + {"NAND 32GiB 1,8V 8-bit", {0, 0x1C}, 0, 32768, 0, LP_OPTIONS}, + {"NAND 32GiB 3,3V 8-bit", {0, 0x3C}, 0, 32768, 0, LP_OPTIONS}, + {"NAND 32GiB 1,8V 16-bit", {0, 0x2C}, 0, 32768, 0, LP_OPTIONS16}, + {"NAND 32GiB 3,3V 16-bit", {0, 0x4C}, 0, 32768, 0, LP_OPTIONS16}, /* 512 Gigabit */ - {"NAND 64GiB 1,8V 8-bit", 0x1E, 0, 65536, 0, LP_OPTIONS}, - {"NAND 64GiB 3,3V 8-bit", 0x3E, 0, 65536, 0, LP_OPTIONS}, - {"NAND 64GiB 1,8V 16-bit", 0x2E, 0, 65536, 0, LP_OPTIONS16}, - {"NAND 64GiB 3,3V 16-bit", 0x4E, 0, 65536, 0, LP_OPTIONS16}, + {"NAND 64GiB 1,8V 8-bit", {0, 0x1E}, 0, 65536, 0, LP_OPTIONS}, + {"NAND 64GiB 3,3V 8-bit", {0, 0x3E}, 0, 65536, 0, LP_OPTIONS}, + {"NAND 64GiB 1,8V 16-bit", {0, 0x2E}, 0, 65536, 0, LP_OPTIONS16}, + {"NAND 64GiB 3,3V 16-bit", {0, 0x4E}, 0, 65536, 0, LP_OPTIONS16}, /* * Renesas AND 1 Gigabit. Those chips do not support extended id and @@ -156,7 +170,7 @@ struct nand_flash_dev nand_flash_ids[] = { * erased in one go There are more speed improvements for reads and * writes possible, but not implemented now */ - {"AND 128MiB 3,3V 8-bit", 0x01, 2048, 128, 0x4000, + {"AND 128MiB 3,3V 8-bit", {0, 0x01}, 2048, 128, 0x4000, NAND_IS_AND | NAND_4PAGE_ARRAY | BBT_AUTO_REFRESH}, {NULL,} diff --git a/drivers/mtd/nand/nandsim.c b/drivers/mtd/nand/nandsim.c index 4c31798..8742dc1 100644 --- a/drivers/mtd/nand/nandsim.c +++ b/drivers/mtd/nand/nandsim.c @@ -770,7 +770,7 @@ static int init_nandsim(struct mtd_info *mtd) /* Detect how many ID bytes the NAND chip outputs */ for (i = 0; nand_flash_ids[i].name != NULL; i++) { - if (second_id_byte != nand_flash_ids[i].id) + if (second_id_byte != nand_flash_ids[i].id[1]) continue; } diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c index 37ee75c..78a8fd1 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c +++ b/drivers/mtd/nand/pxa3xx_nand.c @@ -989,7 +989,7 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd) } pxa3xx_flash_ids[0].name = f->name; - pxa3xx_flash_ids[0].id = (f->chip_id >> 8) & 0xffff; + pxa3xx_flash_ids[0].id[1] = (f->chip_id >> 8) & 0xffff; pxa3xx_flash_ids[0].pagesize = f->page_size; chipsize = (uint64_t)f->num_blocks * f->page_per_block * f->page_size; pxa3xx_flash_ids[0].chipsize = chipsize >> 20; diff --git a/drivers/mtd/nand/sm_common.c b/drivers/mtd/nand/sm_common.c index 082bcdc..bd5cc43 100644 --- a/drivers/mtd/nand/sm_common.c +++ b/drivers/mtd/nand/sm_common.c @@ -69,41 +69,40 @@ static int sm_block_markbad(struct mtd_info *mtd, loff_t ofs) static struct nand_flash_dev nand_smartmedia_flash_ids[] = { - {"SmartMedia 1MiB 5V", 0x6e, 256, 1, 0x1000, 0}, - {"SmartMedia 1MiB 3,3V", 0xe8, 256, 1, 0x1000, 0}, - {"SmartMedia 1MiB 3,3V", 0xec, 256, 1, 0x1000, 0}, - {"SmartMedia 2MiB 3,3V", 0xea, 256, 2, 0x1000, 0}, - {"SmartMedia 2MiB 5V", 0x64, 256, 2, 0x1000, 0}, - {"SmartMedia 2MiB 3,3V ROM", 0x5d, 512, 2, 0x2000, NAND_ROM}, - {"SmartMedia 4MiB 3,3V", 0xe3, 512, 4, 0x2000, 0}, - {"SmartMedia 4MiB 3,3/5V", 0xe5, 512, 4, 0x2000, 0}, - {"SmartMedia 4MiB 5V", 0x6b, 512, 4, 0x2000, 0}, - {"SmartMedia 4MiB 3,3V ROM", 0xd5, 512, 4, 0x2000, NAND_ROM}, - {"SmartMedia 8MiB 3,3V", 0xe6, 512, 8, 0x2000, 0}, - {"SmartMedia 8MiB 3,3V ROM", 0xd6, 512, 8, 0x2000, NAND_ROM}, - {"SmartMedia 16MiB 3,3V", 0x73, 512, 16, 0x4000, 0}, - {"SmartMedia 16MiB 3,3V ROM", 0x57, 512, 16, 0x4000, NAND_ROM}, - {"SmartMedia 32MiB 3,3V", 0x75, 512, 32, 0x4000, 0}, - {"SmartMedia 32MiB 3,3V ROM", 0x58, 512, 32, 0x4000, NAND_ROM}, - {"SmartMedia 64MiB 3,3V", 0x76, 512, 64, 0x4000, 0}, - {"SmartMedia 64MiB 3,3V ROM", 0xd9, 512, 64, 0x4000, NAND_ROM}, - {"SmartMedia 128MiB 3,3V", 0x79, 512, 128, 0x4000, 0}, - {"SmartMedia 128MiB 3,3V ROM", 0xda, 512, 128, 0x4000, NAND_ROM}, - {"SmartMedia 256MiB 3,3V", 0x71, 512, 256, 0x4000 }, - {"SmartMedia 256MiB 3,3V ROM", 0x5b, 512, 256, 0x4000, NAND_ROM}, + {"SmartMedia 1MiB 5V", {0, 0x6e}, 256, 1, 0x1000, 0}, + {"SmartMedia 1MiB 3,3V", {0, 0xe8}, 256, 1, 0x1000, 0}, + {"SmartMedia 1MiB 3,3V", {0, 0xec}, 256, 1, 0x1000, 0}, + {"SmartMedia 2MiB 3,3V", {0, 0xea}, 256, 2, 0x1000, 0}, + {"SmartMedia 2MiB 5V", {0, 0x64}, 256, 2, 0x1000, 0}, + {"SmartMedia 2MiB 3,3V ROM", {0, 0x5d}, 512, 2, 0x2000, NAND_ROM}, + {"SmartMedia 4MiB 3,3V", {0, 0xe3}, 512, 4, 0x2000, 0}, + {"SmartMedia 4MiB 3,3/5V", {0, 0xe5}, 512, 4, 0x2000, 0}, + {"SmartMedia 4MiB 5V", {0, 0x6b}, 512, 4, 0x2000, 0}, + {"SmartMedia 4MiB 3,3V ROM", {0, 0xd5}, 512, 4, 0x2000, NAND_ROM}, + {"SmartMedia 8MiB 3,3V", {0, 0xe6}, 512, 8, 0x2000, 0}, + {"SmartMedia 8MiB 3,3V ROM", {0, 0xd6}, 512, 8, 0x2000, NAND_ROM}, + {"SmartMedia 16MiB 3,3V", {0, 0x73}, 512, 16, 0x4000, 0}, + {"SmartMedia 16MiB 3,3V ROM", {0, 0x57}, 512, 16, 0x4000, NAND_ROM}, + {"SmartMedia 32MiB 3,3V", {0, 0x75}, 512, 32, 0x4000, 0}, + {"SmartMedia 32MiB 3,3V ROM", {0, 0x58}, 512, 32, 0x4000, NAND_ROM}, + {"SmartMedia 64MiB 3,3V", {0, 0x76}, 512, 64, 0x4000, 0}, + {"SmartMedia 64MiB 3,3V ROM", {0, 0xd9}, 512, 64, 0x4000, NAND_ROM}, + {"SmartMedia 128MiB 3,3V", {0, 0x79}, 512, 128, 0x4000, 0}, + {"SmartMedia 128MiB 3,3V ROM", {0, 0xda}, 512, 128, 0x4000, NAND_ROM}, + {"SmartMedia 256MiB 3,3V", {0, 0x71}, 512, 256, 0x4000 }, + {"SmartMedia 256MiB 3,3V ROM", {0, 0x5b}, 512, 256, 0x4000, NAND_ROM}, {NULL,} }; static struct nand_flash_dev nand_xd_flash_ids[] = { - - {"xD 16MiB 3,3V", 0x73, 512, 16, 0x4000, 0}, - {"xD 32MiB 3,3V", 0x75, 512, 32, 0x4000, 0}, - {"xD 64MiB 3,3V", 0x76, 512, 64, 0x4000, 0}, - {"xD 128MiB 3,3V", 0x79, 512, 128, 0x4000, 0}, - {"xD 256MiB 3,3V", 0x71, 512, 256, 0x4000, NAND_BROKEN_XD}, - {"xD 512MiB 3,3V", 0xdc, 512, 512, 0x4000, NAND_BROKEN_XD}, - {"xD 1GiB 3,3V", 0xd3, 512, 1024, 0x4000, NAND_BROKEN_XD}, - {"xD 2GiB 3,3V", 0xd5, 512, 2048, 0x4000, NAND_BROKEN_XD}, + {"xD 16MiB 3,3V", {0, 0x73}, 512, 16, 0x4000, 0}, + {"xD 32MiB 3,3V", {0, 0x75}, 512, 32, 0x4000, 0}, + {"xD 64MiB 3,3V", {0, 0x76}, 512, 64, 0x4000, 0}, + {"xD 128MiB 3,3V", {0, 0x79}, 512, 128, 0x4000, 0}, + {"xD 256MiB 3,3V", {0, 0x71}, 512, 256, 0x4000, NAND_BROKEN_XD}, + {"xD 512MiB 3,3V", {0, 0xdc}, 512, 512, 0x4000, NAND_BROKEN_XD}, + {"xD 1GiB 3,3V", {0, 0xd3}, 512, 1024, 0x4000, NAND_BROKEN_XD}, + {"xD 2GiB 3,3V", {0, 0xd5}, 512, 2048, 0x4000, NAND_BROKEN_XD}, {NULL,} }; diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 7ccb3c5..d8fd638 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -585,7 +585,7 @@ struct nand_chip { /** * struct nand_flash_dev - NAND Flash Device ID Structure * @name: Identify the device type - * @id: device ID code + * @id: ID data * @pagesize: Pagesize in bytes. Either 256 or 512 or 0 * If the pagesize is 0, then the real pagesize * and the eraseize are determined from the @@ -593,14 +593,18 @@ struct nand_chip { * @erasesize: Size of an erase block in the flash device. * @chipsize: Total chipsize in Mega Bytes * @options: Bitfield to store chip relevant options + * @id_len: The valid length of the id data. + * @oobsize: OOB size */ struct nand_flash_dev { char *name; - int id; + u8 id[8]; unsigned long pagesize; unsigned long chipsize; unsigned long erasesize; unsigned long options; + unsigned int id_len; + unsigned long oobsize; }; /** -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-01-28 4:57 ` [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} Huang Shijie @ 2013-02-12 15:47 ` Artem Bityutskiy 2013-02-16 3:56 ` Huang Shijie 2013-02-28 8:25 ` Huang Shijie 2013-03-02 14:19 ` Artem Bityutskiy 1 sibling, 2 replies; 21+ messages in thread From: Artem Bityutskiy @ 2013-02-12 15:47 UTC (permalink / raw) To: Huang Shijie; +Cc: dwmw2, computersforpeace, linux-mtd, linux-kernel On Mon, 2013-01-28 at 12:57 +0800, Huang Shijie wrote: > + {"SmartMedia 256MiB 3,3V", {0, 0x71}, 512, 256, 0x4000 }, > + {"SmartMedia 256MiB 3,3V ROM", {0, 0x5b}, 512, 256, 0x4000, > NAND_ROM}, Sorry for a possibly stupid question, but what does it buy you adding another "0" to all the entries? I see you add another table, which you look up if the "traditional" table does not work. Why you need to add these zeroes? -- Best Regards, Artem Bityutskiy ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-02-12 15:47 ` Artem Bityutskiy @ 2013-02-16 3:56 ` Huang Shijie 2013-03-02 14:21 ` Artem Bityutskiy 2013-02-28 8:25 ` Huang Shijie 1 sibling, 1 reply; 21+ messages in thread From: Huang Shijie @ 2013-02-16 3:56 UTC (permalink / raw) To: dedekind1; +Cc: Huang Shijie, dwmw2, computersforpeace, linux-mtd, linux-kernel On Tue, Feb 12, 2013 at 11:47 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote: > On Mon, 2013-01-28 at 12:57 +0800, Huang Shijie wrote: >> + {"SmartMedia 256MiB 3,3V", {0, 0x71}, 512, 256, 0x4000 }, >> + {"SmartMedia 256MiB 3,3V ROM", {0, 0x5b}, 512, 256, 0x4000, >> NAND_ROM}, > > Sorry for a possibly stupid question, but what does it buy you adding > another "0" to all the entries? I see you add another table, which you > look up if the "traditional" table does not work. Why you need to add > these zeroes? The zeros are for the maf_id. The dev_id is the second byte of the 8-byte id data. thanks Huang Shijie > > -- > Best Regards, > Artem Bityutskiy > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-02-16 3:56 ` Huang Shijie @ 2013-03-02 14:21 ` Artem Bityutskiy 2013-03-04 5:57 ` Huang Shijie 0 siblings, 1 reply; 21+ messages in thread From: Artem Bityutskiy @ 2013-03-02 14:21 UTC (permalink / raw) To: Huang Shijie Cc: Huang Shijie, dwmw2, computersforpeace, linux-mtd, linux-kernel On Sat, 2013-02-16 at 11:56 +0800, Huang Shijie wrote: > On Tue, Feb 12, 2013 at 11:47 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote: > > On Mon, 2013-01-28 at 12:57 +0800, Huang Shijie wrote: > >> + {"SmartMedia 256MiB 3,3V", {0, 0x71}, 512, 256, 0x4000 }, > >> + {"SmartMedia 256MiB 3,3V ROM", {0, 0x5b}, 512, 256, 0x4000, > >> NAND_ROM}, > > > > Sorry for a possibly stupid question, but what does it buy you adding > > another "0" to all the entries? I see you add another table, which you > > look up if the "traditional" table does not work. Why you need to add > > these zeroes? > > The zeros are for the maf_id. > > The dev_id is the second byte of the 8-byte id data. It does not really make me understand why we add these zeroes, they still look useless to me... Would you please be a little more verbose about your solution? -- Best Regards, Artem Bityutskiy ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-02 14:21 ` Artem Bityutskiy @ 2013-03-04 5:57 ` Huang Shijie 2013-03-04 7:50 ` Artem Bityutskiy 0 siblings, 1 reply; 21+ messages in thread From: Huang Shijie @ 2013-03-04 5:57 UTC (permalink / raw) To: dedekind1; +Cc: Huang Shijie, dwmw2, computersforpeace, linux-mtd, linux-kernel 于 2013年03月02日 22:21, Artem Bityutskiy 写道: > On Sat, 2013-02-16 at 11:56 +0800, Huang Shijie wrote: >> On Tue, Feb 12, 2013 at 11:47 PM, Artem Bityutskiy<dedekind1@gmail.com> wrote: >>> On Mon, 2013-01-28 at 12:57 +0800, Huang Shijie wrote: >>>> + {"SmartMedia 256MiB 3,3V", {0, 0x71}, 512, 256, 0x4000 }, >>>> + {"SmartMedia 256MiB 3,3V ROM", {0, 0x5b}, 512, 256, 0x4000, >>>> NAND_ROM}, >>> Sorry for a possibly stupid question, but what does it buy you adding >>> another "0" to all the entries? I see you add another table, which you >>> look up if the "traditional" table does not work. Why you need to add >>> these zeroes? >> The zeros are for the maf_id. >> >> The dev_id is the second byte of the 8-byte id data. > It does not really make me understand why we add these zeroes, they > still look useless to me... Would you please be a little more verbose > about your solution? > the 8bytes id data read out by the READ ID command is in the following order: byte 0(Maker id): such as 0x98 stands for Toshiba, 0xec stands for Samsung. byte 1(device id): byte 2(used to store the chip number,cell type information): byte 3(used to store the page size, block size information) byte 4(used to store the Plane information). ........................ The current code uses the @id to store the device id(byte 1). But if we use the 8 bytes id data as the keyword, and expand the @id field to 8byte array, the device id is the second byte now. All the added zeros are for the Maker id. For example, {"SmartMedia 256MiB 3,3V", {0, 0x71}, 512, 256, 0x4000 }, We really do not use the zeros. All the zeros are added for avoiding the misunderstanding. If we do not add the zero, it will looks like: {"SmartMedia 256MiB 3,3V", {0x71}, 512, 256, 0x4000 }, The device id (0x71) becomes the first byte of 8byte id array, people will treat the 0x71 as the Maker code. thanks Huang Shijie ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-04 5:57 ` Huang Shijie @ 2013-03-04 7:50 ` Artem Bityutskiy 2013-03-04 8:08 ` Huang Shijie 0 siblings, 1 reply; 21+ messages in thread From: Artem Bityutskiy @ 2013-03-04 7:50 UTC (permalink / raw) To: Huang Shijie Cc: Huang Shijie, dwmw2, computersforpeace, linux-mtd, linux-kernel On Mon, 2013-03-04 at 13:57 +0800, Huang Shijie wrote: > The current code uses the @id to store the device id(byte 1). > But if we use the 8 bytes id data as the keyword, and expand the @id > field to 8byte array, > the device id is the second byte now. All the added zeros are for the I do not think you need to store the full array of ID's. Device ID's for all the 4 of above chips are different, which is enough to distinguish between them. The only thing you need to add is the OOB size field to 'struct nand_flash_dev'. -- Best Regards, Artem Bityutskiy ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-04 7:50 ` Artem Bityutskiy @ 2013-03-04 8:08 ` Huang Shijie 2013-03-04 8:24 ` Artem Bityutskiy 2013-03-04 8:37 ` Artem Bityutskiy 0 siblings, 2 replies; 21+ messages in thread From: Huang Shijie @ 2013-03-04 8:08 UTC (permalink / raw) To: dedekind1; +Cc: Huang Shijie, dwmw2, computersforpeace, linux-mtd, linux-kernel 于 2013年03月04日 15:50, Artem Bityutskiy 写道: > On Mon, 2013-03-04 at 13:57 +0800, Huang Shijie wrote: >> The current code uses the @id to store the device id(byte 1). >> But if we use the 8 bytes id data as the keyword, and expand the @id >> field to 8byte array, >> the device id is the second byte now. All the added zeros are for the > I do not think you need to store the full array of ID's. Device ID's for > all the 4 of above chips are different, which is enough to distinguish > between them. > > The only thing you need to add is the OOB size field to 'struct > nand_flash_dev'. > If i only add the oob size field. There will be two items with the same Device ID in nand_flash_ids table, one has oob_size, one does not have. such as: {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS}, {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS, 640}, //OOB size is 640. How can i distinguish them? In which case, i choose the item with the oob_size, and in which case, i choose the item without the oobsize? thanks Huang Shijie ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-04 8:08 ` Huang Shijie @ 2013-03-04 8:24 ` Artem Bityutskiy 2013-03-04 8:40 ` Huang Shijie 2013-03-04 8:37 ` Artem Bityutskiy 1 sibling, 1 reply; 21+ messages in thread From: Artem Bityutskiy @ 2013-03-04 8:24 UTC (permalink / raw) To: Huang Shijie Cc: Huang Shijie, dwmw2, computersforpeace, linux-mtd, linux-kernel On Mon, 2013-03-04 at 16:08 +0800, Huang Shijie wrote: > 于 2013年03月04日 15:50, Artem Bityutskiy 写道: > > On Mon, 2013-03-04 at 13:57 +0800, Huang Shijie wrote: > >> The current code uses the @id to store the device id(byte 1). > >> But if we use the 8 bytes id data as the keyword, and expand the @id > >> field to 8byte array, > >> the device id is the second byte now. All the added zeros are for the > > I do not think you need to store the full array of ID's. Device ID's for > > all the 4 of above chips are different, which is enough to distinguish > > between them. > > > > The only thing you need to add is the OOB size field to 'struct > > nand_flash_dev'. > > > If i only add the oob size field. There will be two items with the same > Device ID in nand_flash_ids table, > one has oob_size, one does not have. such as: > > {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS}, Do you know what is this chip? > {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS, 640}, //OOB > size is 640 So there are really 2 different chips with the same device id and different OOB size? If you had 2 datasheets for me demonstrating this, I'd be grateful. -- Best Regards, Artem Bityutskiy ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-04 8:24 ` Artem Bityutskiy @ 2013-03-04 8:40 ` Huang Shijie 2013-03-04 8:46 ` Artem Bityutskiy 0 siblings, 1 reply; 21+ messages in thread From: Huang Shijie @ 2013-03-04 8:40 UTC (permalink / raw) To: dedekind1; +Cc: Huang Shijie, dwmw2, computersforpeace, linux-mtd, linux-kernel 于 2013年03月04日 16:24, Artem Bityutskiy 写道: > On Mon, 2013-03-04 at 16:08 +0800, Huang Shijie wrote: >> 于 2013年03月04日 15:50, Artem Bityutskiy 写道: >>> On Mon, 2013-03-04 at 13:57 +0800, Huang Shijie wrote: >>>> The current code uses the @id to store the device id(byte 1). >>>> But if we use the 8 bytes id data as the keyword, and expand the @id >>>> field to 8byte array, >>>> the device id is the second byte now. All the added zeros are for the >>> I do not think you need to store the full array of ID's. Device ID's for >>> all the 4 of above chips are different, which is enough to distinguish >>> between them. >>> >>> The only thing you need to add is the OOB size field to 'struct >>> nand_flash_dev'. >>> >> If i only add the oob size field. There will be two items with the same >> Device ID in nand_flash_ids table, >> one has oob_size, one does not have. such as: >> >> {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS}, > Do you know what is this chip? this maybe not just a nand chip, it may stands for a class of nand chips. Toshiba may uses this device id, Micron may also uses it. In other word, this item may stands for many nand chips. >> {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS, 640}, //OOB >> size is 640 > So there are really 2 different chips with the same device id and > different OOB size? If you had 2 datasheets for me demonstrating this, > I'd be grateful. Please see the http://www.linux-mtd.infradead.org/nand-data/nanddata.html The ST's NAND08GW3B2C and Numonyx's NAND08GW3F2B share the same device id but with the different oob size. thanks Huang Shijie ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-04 8:40 ` Huang Shijie @ 2013-03-04 8:46 ` Artem Bityutskiy 2013-03-04 8:59 ` Huang Shijie 0 siblings, 1 reply; 21+ messages in thread From: Artem Bityutskiy @ 2013-03-04 8:46 UTC (permalink / raw) To: Huang Shijie Cc: Huang Shijie, dwmw2, computersforpeace, linux-mtd, linux-kernel On Mon, 2013-03-04 at 16:40 +0800, Huang Shijie wrote: > 于 2013年03月04日 16:24, Artem Bityutskiy 写道: > > On Mon, 2013-03-04 at 16:08 +0800, Huang Shijie wrote: > >> 于 2013年03月04日 15:50, Artem Bityutskiy 写道: > >>> On Mon, 2013-03-04 at 13:57 +0800, Huang Shijie wrote: > >>>> The current code uses the @id to store the device id(byte 1). > >>>> But if we use the 8 bytes id data as the keyword, and expand the @id > >>>> field to 8byte array, > >>>> the device id is the second byte now. All the added zeros are for the > >>> I do not think you need to store the full array of ID's. Device ID's for > >>> all the 4 of above chips are different, which is enough to distinguish > >>> between them. > >>> > >>> The only thing you need to add is the OOB size field to 'struct > >>> nand_flash_dev'. > >>> > >> If i only add the oob size field. There will be two items with the same > >> Device ID in nand_flash_ids table, > >> one has oob_size, one does not have. such as: > >> > >> {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS}, > > Do you know what is this chip? > this maybe not just a nand chip, it may stands for a class of nand chips. > Toshiba may uses this device id, Micron may also uses it. > > In other word, this item may stands for many nand chips. > >> {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS, 640}, //OOB > >> size is 640 > > So there are really 2 different chips with the same device id and > > different OOB size? If you had 2 datasheets for me demonstrating this, > > I'd be grateful. > Please see the http://www.linux-mtd.infradead.org/nand-data/nanddata.html > The ST's NAND08GW3B2C and Numonyx's NAND08GW3F2B share the same device Thanks, I forgot we have this great table. BTW, please, do not forget to update it with information about these 4 chip you are adding, irrespective of the solution we end up with. -- Best Regards, Artem Bityutskiy ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-04 8:46 ` Artem Bityutskiy @ 2013-03-04 8:59 ` Huang Shijie 2013-03-04 19:27 ` Brian Norris 2013-08-08 18:38 ` Brian Norris 0 siblings, 2 replies; 21+ messages in thread From: Huang Shijie @ 2013-03-04 8:59 UTC (permalink / raw) To: dedekind1; +Cc: Huang Shijie, dwmw2, computersforpeace, linux-mtd, linux-kernel 于 2013年03月04日 16:46, Artem Bityutskiy 写道: > Thanks, I forgot we have this great table. BTW, please, do not forget to > update it with information about these 4 chip you are adding, > irrespective of the solution we end up with. I also want to update the table, but i do not know how to do it. thanks Huang Shijie ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-04 8:59 ` Huang Shijie @ 2013-03-04 19:27 ` Brian Norris 2013-08-08 18:38 ` Brian Norris 1 sibling, 0 replies; 21+ messages in thread From: Brian Norris @ 2013-03-04 19:27 UTC (permalink / raw) To: Huang Shijie; +Cc: dedekind1, Huang Shijie, dwmw2, linux-mtd, linux-kernel On Mon, Mar 4, 2013 at 12:59 AM, Huang Shijie <b32955@freescale.com> wrote: > 于 2013年03月04日 16:46, Artem Bityutskiy 写道: > >> Thanks, I forgot we have this great table. BTW, please, do not forget to >> update it with information about these 4 chip you are adding, >> irrespective of the solution we end up with. > > I also want to update the table, but i do not know how to do it. You can send patches against the mtd-www.git repo. It's just a CSV text-file, so you'd add a few rows. I'll try to review / ack any patches. Brian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-04 8:59 ` Huang Shijie 2013-03-04 19:27 ` Brian Norris @ 2013-08-08 18:38 ` Brian Norris 1 sibling, 0 replies; 21+ messages in thread From: Brian Norris @ 2013-08-08 18:38 UTC (permalink / raw) To: Huang Shijie; +Cc: dedekind1, Huang Shijie, dwmw2, linux-mtd, linux-kernel Hi Huang, For some reason, I just noticed your question here. But I think it's important to answer. On 03/04/2013 12:59 AM, Huang Shijie wrote: > 于 2013年03月04日 16:46, Artem Bityutskiy 写道: >> Thanks, I forgot we have this great table. BTW, please, do not forget to >> update it with information about these 4 chip you are adding, >> irrespective of the solution we end up with. > I also want to update the table, but i do not know how to do it. You can submit a patch against mtd-www.git. See: http://www.linux-mtd.infradead.org/faq/general.html#L_mtdwww You just need to edit the CSV table under nand-data/nanddata.csv. Brian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-04 8:08 ` Huang Shijie 2013-03-04 8:24 ` Artem Bityutskiy @ 2013-03-04 8:37 ` Artem Bityutskiy 2013-03-04 8:57 ` Huang Shijie 1 sibling, 1 reply; 21+ messages in thread From: Artem Bityutskiy @ 2013-03-04 8:37 UTC (permalink / raw) To: Huang Shijie Cc: Huang Shijie, dwmw2, computersforpeace, linux-mtd, linux-kernel On Mon, 2013-03-04 at 16:08 +0800, Huang Shijie wrote: > 于 2013年03月04日 15:50, Artem Bityutskiy 写道: > > On Mon, 2013-03-04 at 13:57 +0800, Huang Shijie wrote: > >> The current code uses the @id to store the device id(byte 1). > >> But if we use the 8 bytes id data as the keyword, and expand the @id > >> field to 8byte array, > >> the device id is the second byte now. All the added zeros are for the > > I do not think you need to store the full array of ID's. Device ID's for > > all the 4 of above chips are different, which is enough to distinguish > > between them. > > > > The only thing you need to add is the OOB size field to 'struct > > nand_flash_dev'. > > > If i only add the oob size field. There will be two items with the same > Device ID in nand_flash_ids table, > one has oob_size, one does not have. such as: > > {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS}, OK, I guess for this one: {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS, 0}, nand_decode_ext_id() will calculate the OOB size. > {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS, 640}, //OOB > size is 640. And for this one 'nand_decode_ext_id()' will calculate it too, but _afterwards_ we change OOB size to 640. Does this sound sane? -- Best Regards, Artem Bityutskiy ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-04 8:37 ` Artem Bityutskiy @ 2013-03-04 8:57 ` Huang Shijie 0 siblings, 0 replies; 21+ messages in thread From: Huang Shijie @ 2013-03-04 8:57 UTC (permalink / raw) To: dedekind1; +Cc: Huang Shijie, dwmw2, computersforpeace, linux-mtd, linux-kernel 于 2013年03月04日 16:37, Artem Bityutskiy 写道: > On Mon, 2013-03-04 at 16:08 +0800, Huang Shijie wrote: >> 于 2013年03月04日 15:50, Artem Bityutskiy 写道: >>> On Mon, 2013-03-04 at 13:57 +0800, Huang Shijie wrote: >>>> The current code uses the @id to store the device id(byte 1). >>>> But if we use the 8 bytes id data as the keyword, and expand the @id >>>> field to 8byte array, >>>> the device id is the second byte now. All the added zeros are for the >>> I do not think you need to store the full array of ID's. Device ID's for >>> all the 4 of above chips are different, which is enough to distinguish >>> between them. >>> >>> The only thing you need to add is the OOB size field to 'struct >>> nand_flash_dev'. >>> >> If i only add the oob size field. There will be two items with the same >> Device ID in nand_flash_ids table, >> one has oob_size, one does not have. such as: >> >> {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS}, > OK, I guess for this one: > > {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS, 0}, > > nand_decode_ext_id() will calculate the OOB size. > >> {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS, 640}, //OOB >> size is 640. > And for this one 'nand_decode_ext_id()' will calculate it too, but > _afterwards_ we change OOB size to 640. > > Does this sound sane? > I think not. The problem is : we can not know which nand_flash_dev item we should use when the same Device ID occurs. When we meet a nand whose Device ID is 0xDE, the current code will select the first one: {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS, 0} Could you tell me how can we choose the seconde one? The second same device-id item is {"NAND 8GIB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS, 640} thanks Huang Shijie ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-02-12 15:47 ` Artem Bityutskiy 2013-02-16 3:56 ` Huang Shijie @ 2013-02-28 8:25 ` Huang Shijie 1 sibling, 0 replies; 21+ messages in thread From: Huang Shijie @ 2013-02-28 8:25 UTC (permalink / raw) To: dedekind1; +Cc: dwmw2, computersforpeace, linux-mtd, linux-kernel 于 2013年02月12日 23:47, Artem Bityutskiy 写道: > On Mon, 2013-01-28 at 12:57 +0800, Huang Shijie wrote: >> + {"SmartMedia 256MiB 3,3V", {0, 0x71}, 512, 256, 0x4000 }, >> + {"SmartMedia 256MiB 3,3V ROM", {0, 0x5b}, 512, 256, 0x4000, >> NAND_ROM}, > Sorry for a possibly stupid question, but what does it buy you adding > another "0" to all the entries? I see you add another table, which you > look up if the "traditional" table does not work. Why you need to add > these zeroes? > just a ping. are we missing the merge window again? thanks Huang Shijie ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-01-28 4:57 ` [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} Huang Shijie 2013-02-12 15:47 ` Artem Bityutskiy @ 2013-03-02 14:19 ` Artem Bityutskiy 2013-03-04 3:06 ` Huang Shijie 1 sibling, 1 reply; 21+ messages in thread From: Artem Bityutskiy @ 2013-03-02 14:19 UTC (permalink / raw) To: Huang Shijie; +Cc: dwmw2, computersforpeace, linux-mtd, linux-kernel On Mon, 2013-01-28 at 12:57 +0800, Huang Shijie wrote: > As time goes on, we begin to meet the situation that we can not get enough > information from some nand chips's id data. Take some Toshiba's nand chips > for example. I have 4 Toshiba's nand chips in my hand: > TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2 > > When we read these chips' datasheets, we will get the geometry of these chips: > TC58NVG2S0F : 4096 + 224 > TC58NVG3S0F : 4096 + 232 > TC58NVG5D2 : 8192 + 640 > TC58NVG6D2 : 8192 + 640 > > But we can not parse out the correct oob size for these chips from the id data. Very good start of the commit message - you clearly defined the problem. > So it is time to add some new fields to the nand_flash_dev{}, and update the > detection mechanisms. But continued with very poor description of how you address the problem. Please, provide a better description. > This patch just adds some new fields to the nand_flash_dev{}: > @id[8] : the 8 bytes id data. id[8] = 8 bytes id data, just like password[5] = 5 bytes of password data. Please, provide a better commentary. > @id_len: the valid length of the id data. What does "valid" mean? Are "invalid" parts? > @oobsize: the oob size. Try to invent a better comment. Huang, it is not that I am trying to be difficult, but I truly do not understand how you are solving the issue. -- Best Regards, Artem Bityutskiy ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} 2013-03-02 14:19 ` Artem Bityutskiy @ 2013-03-04 3:06 ` Huang Shijie 0 siblings, 0 replies; 21+ messages in thread From: Huang Shijie @ 2013-03-04 3:06 UTC (permalink / raw) To: dedekind1; +Cc: dwmw2, computersforpeace, linux-mtd, linux-kernel 于 2013年03月02日 22:19, Artem Bityutskiy 写道: > On Mon, 2013-01-28 at 12:57 +0800, Huang Shijie wrote: >> As time goes on, we begin to meet the situation that we can not get enough >> information from some nand chips's id data. Take some Toshiba's nand chips >> for example. I have 4 Toshiba's nand chips in my hand: >> TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2 >> >> When we read these chips' datasheets, we will get the geometry of these chips: >> TC58NVG2S0F : 4096 + 224 >> TC58NVG3S0F : 4096 + 232 >> TC58NVG5D2 : 8192 + 640 >> TC58NVG6D2 : 8192 + 640 >> >> But we can not parse out the correct oob size for these chips from the id data. > Very good start of the commit message - you clearly defined the problem. > >> So it is time to add some new fields to the nand_flash_dev{}, and update the >> detection mechanisms. > But continued with very poor description of how you address the problem. > Please, provide a better description. sorry. It's my fault. I will add more description in the next version. >> This patch just adds some new fields to the nand_flash_dev{}: >> @id[8] : the 8 bytes id data. > id[8] = 8 bytes id data, just like password[5] = 5 bytes of password > data. Please, provide a better commentary. > okay. >> @id_len: the valid length of the id data. > What does "valid" mean? Are "invalid" parts? yes. some nand chips may only have 5 valid bytes in the 8 bytes id data which is read out by the READ ID(0x90) command. for example, the 8 bytes id data may like this: A1, A2, A3, A4, A5, A1, A2, A3 The last three bytes are just the repeat of the first three bytes. Of course, we can remove this field, in other word, treat the last three bytes as the valid bytes too. >> @oobsize: the oob size. > Try to invent a better comment. > > Huang, it is not that I am trying to be difficult, but I truly do not not at all, it's my fault. > understand how you are solving the issue. > My method is: Use the 8 bytes id data (which is read out by READ ID command) as the keyword. The 8bytes id data is unique for each nand chip. Do we meet two different nand chips have the same 8 bytes id data? I afraid not. Since we can not parse out the oob size for these Toshiba nand chips, we can add a new field oob_size to store the right oob size for the nand chips. that's why i add the @oobsize field. Are you clear now? thanks Huang Shijie ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH V3 2/3] mtd: add a new table for the unparsable nand chips 2013-01-28 4:57 [PATCH V3 0/3] mtd: use the full-id as the keyword Huang Shijie 2013-01-28 4:57 ` [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} Huang Shijie @ 2013-01-28 4:57 ` Huang Shijie 2013-01-28 4:57 ` [PATCH V3 3/3] mtd: add the new detection method " Huang Shijie 2 siblings, 0 replies; 21+ messages in thread From: Huang Shijie @ 2013-01-28 4:57 UTC (permalink / raw) To: dwmw2; +Cc: dedekind1, computersforpeace, linux-mtd, linux-kernel, Huang Shijie We have 4 Toshiba nand chips which can not be parsed out by the id data. Add a new table for the unparsable nand chips. It makes mess if we add these entries to the nand_flash_ids table. The entries in the nand_flash_ids stands for a class of nand chips. But the unparsable nand chips are just some singular chips. Signed-off-by: Huang Shijie <b32955@freescale.com> --- drivers/mtd/nand/nand_ids.c | 21 +++++++++++++++++++++ include/linux/mtd/nand.h | 1 + 2 files changed, 22 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c index 99949f6..4147c78 100644 --- a/drivers/mtd/nand/nand_ids.c +++ b/drivers/mtd/nand/nand_ids.c @@ -12,6 +12,27 @@ #include <linux/mtd/nand.h> #include <linux/sizes.h> +/* This table uses the full ID data as the keyword. */ +struct nand_flash_dev nand_flash_full_ids[] = { + /* TOSHIBA */ + {"TC58NVG2S0F 4G 3.3V 8-bit ", + {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08}, + SZ_4K, SZ_512, SZ_256K, 0, 8, 224}, + {"TC58NVG3S0F 8G 3.3V 8-bit ", + {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08}, + SZ_4K, SZ_1K, SZ_256K, 0, 8, 232}, + {"TC58NVG5D2 32G 3.3V 8-bit ", + {0x98, 0xd7, 0x94, 0x32, 0x76, 0x56, 0x09, 0x00}, + SZ_8K, SZ_4K, SZ_1M, 0, 8, 640}, + {"TC58NVG6D2 64G 3.3V 8-bit ", + {0x98, 0xde, 0x94, 0x82, 0x76, 0x56, 0x04, 0x20}, + SZ_8K, SZ_8K, SZ_2M, 0, 8, 640}, + + /* end here */ + {NULL,} +}; + + /* * Chip ID list * diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index d8fd638..119c8e0 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -618,6 +618,7 @@ struct nand_manufacturers { }; extern struct nand_flash_dev nand_flash_ids[]; +extern struct nand_flash_dev nand_flash_full_ids[]; extern struct nand_manufacturers nand_manuf_ids[]; extern int nand_scan_bbt(struct mtd_info *mtd, struct nand_bbt_descr *bd); -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH V3 3/3] mtd: add the new detection method for the unparsable nand chips 2013-01-28 4:57 [PATCH V3 0/3] mtd: use the full-id as the keyword Huang Shijie 2013-01-28 4:57 ` [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} Huang Shijie 2013-01-28 4:57 ` [PATCH V3 2/3] mtd: add a new table for the unparsable nand chips Huang Shijie @ 2013-01-28 4:57 ` Huang Shijie 2 siblings, 0 replies; 21+ messages in thread From: Huang Shijie @ 2013-01-28 4:57 UTC (permalink / raw) To: dwmw2; +Cc: dedekind1, computersforpeace, linux-mtd, linux-kernel, Huang Shijie Add the new detection method find_nand_type_by_fullid() for the unparsable nand chips. The new detection method is called firstly before all the other detection methods. Signed-off-by: Huang Shijie <b32955@freescale.com> --- drivers/mtd/nand/nand_base.c | 33 ++++++++++++++++++++++++++++++++- 1 files changed, 32 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 0e80ec4..7f0431d 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3152,6 +3152,29 @@ static void nand_decode_bbm_options(struct mtd_info *mtd, chip->bbt_options |= NAND_BBT_SCAN2NDPAGE; } +static struct nand_flash_dev *find_nand_type_by_fullid(struct mtd_info *mtd, + struct nand_chip *chip, u8 *id_data, int *busw) +{ + struct nand_flash_dev *type = nand_flash_full_ids; + + for (; type->name != NULL; type++) { + if (!strncmp(type->id, id_data, type->id_len)) { + mtd->writesize = type->pagesize; + mtd->erasesize = type->erasesize; + mtd->oobsize = type->oobsize; + + chip->cellinfo = id_data[2]; + chip->chipsize = (uint64_t)type->chipsize << 20; + chip->options |= type->options; + + *busw = type->options & NAND_BUSWIDTH_16; + + break; + } + } + return type; +} + /* * Get the flash and manufacturer id and lookup if the type is supported. */ @@ -3200,8 +3223,16 @@ static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd, return ERR_PTR(-ENODEV); } - if (!type) + if (!type) { + /* + * Some nand chips's information can not be paresed out + * from the id data. So, try your luck in the full-id table. + */ + type = find_nand_type_by_fullid(mtd, chip, id_data, &busw); + if (type->name != NULL) + goto ident_done; type = nand_flash_ids; + } for (; type->name != NULL; type++) if (*dev_id == type->id[1]) -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 21+ messages in thread
end of thread, other threads:[~2013-08-08 18:38 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-28 4:57 [PATCH V3 0/3] mtd: use the full-id as the keyword Huang Shijie
2013-01-28 4:57 ` [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{} Huang Shijie
2013-02-12 15:47 ` Artem Bityutskiy
2013-02-16 3:56 ` Huang Shijie
2013-03-02 14:21 ` Artem Bityutskiy
2013-03-04 5:57 ` Huang Shijie
2013-03-04 7:50 ` Artem Bityutskiy
2013-03-04 8:08 ` Huang Shijie
2013-03-04 8:24 ` Artem Bityutskiy
2013-03-04 8:40 ` Huang Shijie
2013-03-04 8:46 ` Artem Bityutskiy
2013-03-04 8:59 ` Huang Shijie
2013-03-04 19:27 ` Brian Norris
2013-08-08 18:38 ` Brian Norris
2013-03-04 8:37 ` Artem Bityutskiy
2013-03-04 8:57 ` Huang Shijie
2013-02-28 8:25 ` Huang Shijie
2013-03-02 14:19 ` Artem Bityutskiy
2013-03-04 3:06 ` Huang Shijie
2013-01-28 4:57 ` [PATCH V3 2/3] mtd: add a new table for the unparsable nand chips Huang Shijie
2013-01-28 4:57 ` [PATCH V3 3/3] mtd: add the new detection method " Huang Shijie
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).