Messages in this thread | | | Date | Wed, 13 Mar 2013 21:48:42 -0700 | Subject | Re: [PATCH v5 0/3] mtd: use the full-id as the keyword for some nand chips | From | Brian Norris <> |
| |
On Wed, Mar 13, 2013 at 7:59 PM, Huang Shijie <b32955@freescale.com> 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. > So it is time to add some new fields to the nand_flash_dev{}, > and update the detection mechanisms. > > v4 --> v4: > [1] remove the id_len field. > [2] based on Artem "mtd: nand: use more reasonable integer types" > [3] add more comments.
Sorry for not posting this earlier, but why don't we want an id_len field? NAND chips often only have a 5-byte or 6-byte ID "defined" in their datasheet, and so the next few bytes aren't guaranteed to be any particular value. Wouldn't we want to accommodate for any potential variation in the "undefined" bytes? (These bytes do typically have a pattern, and in fact, we currently rely on that fact.) Also, I can easily foresee a situation in which someone might want to support NAND based solely on the datasheet, not waiting till they get a sample of that chip in their hands. In that case, they cannot specify a full 8 bytes in the table; they can (and should) only specify the few substring found in their datasheet.
Really, the only argument I see for dropping id_len is to save space. I think this is a bad choice.
... <snip> ...
Brian
| |