[PATCH] mtd: nand_ids: Add device parameters for Toshiba's TC58NVG1S3ETAI0 NAND EEPROM

[Gupta, Pekon]

Hi Brian,

>From: Brian Norris [mailto:computersforpeace at gmail.com]
>>On Tue, Jan 07, 2014 at 11:04:43AM +0100, Stefan Roese wrote:
>> Toshiba's TC58NVG1S3ETAI0 is a single 3.3V 2 Gbit (2,214,592,512 bits) NAND
>> Electrically Erasable and Programmable Read-Only Memory (NAND E2PROM)
>> organized as (2048 + 64) bytes x 64 pages x 2048 blocks.
>>
>> Signed-off-by: Stefan Roese <sr at denx.de>
[...]
>> @@ -31,6 +31,9 @@ struct nand_flash_dev nand_flash_ids[] = {
>>  	 * listed by full ID. We list them first so that we can easily identify
>>  	 * the most specific match.
>>  	 */
>> +	{"TC58NVG1S3ETAI0 2G 3.3V 8-bit",
>> +		{ .id = {0x98, 0xda, 0x90, 0x15, 0x76, 0x00, 0x00, 0x00} },
>> +		  SZ_2K, SZ_256, SZ_128K, 0, 5, 64, NAND_ECC_INFO(1, SZ_512) },
>
>I have to NAK this in its current form, for two reasons:
>
>1) This is not a specific enough ID string. It conflicts with another
>NAND which was recently supported.
>
>2) This patch may not really be needed at all. The "full ID" listing is
>only for NAND which can't be detected via other means (e.g., ONFI, or
>traditional extended ID parsing). Is this NAND mis-detected in Linus'
>current tree? As I read the code, it should correctly identify this
>NAND's device size, page size, OOB size, etc.
>
>See this commit for reference:
>
>commit 60c6738245612df9499b340c15edf48b8f3e7981
>Author: Brian Norris <computersforpeace at gmail.com>
>Date:   Tue Jun 25 13:17:59 2013 -0700
>
>    mtd: nand: detect OOB size for Toshiba 24nm raw SLC
>
>   https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=60c6738245612df9499b340c15edf48b8f3e7981
>
>It adds support for a class of Toshiba 24nm NAND, including this one:
>
>    24nm SLC 2Gbit TC58NVG1S3HTA00
>    ID: 0x98 0xda 0x90 0x15 0x76 0x16 0x08 0x00
>
>Please reconcile your patch with the comments found there.
>

Yes, I think this is a different technology part..
because though the page-size = 2048B is same, but OOB-size = 64B.
However, with your OOB-size is detected as 128B.

Best part is the datasheet of this part does not mention anything about the 6th byte :-).
So, I think we can first  read 6th-byte (using READID command), and figure out difference
between your part and this one, then based on it append the OOB-calculation to you patch. Ok ?

ID byte 5, bit[7]: 
	1 -> BENAND 
	0 -> raw SLC   <<----- SLC NAND

ID byte 6, bits[2:0]:   <<----- 6th byte has no mention in datasheet
	100b -> 43nm 
	 101b -> 32nm
	 110b -> 24nm
	 111b -> Reserved

But sincerely, why is Toshiba doing all this ?
It would hit them only, as their devices will lack support on mainline kernels and u-boots.
(Or their customers would have to carry custom patches all along).
I tried convincing Toshiba to get their parts ONFI compliant, but they were too reluctant.


with regards, pekon