lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 8 Aug 2013 16:33:35 +0800
From:	Huang Shijie <b32955@...escale.com>
To:	Brian Norris <computersforpeace@...il.com>
CC:	<dwmw2@...radead.org>, <dedekind1@...il.com>,
	<linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	<vikram186@...il.com>
Subject: Re: [PATCH v6 00/10] mtd: add datasheet's ECC information to nand_chip{}

Hi Artem & Brian:
> Hi Huang and others,
>
> On Thu, May 16, 2013 at 8:17 PM, Huang Shijie<b32955@...escale.com>  wrote:
>> 1.) Why add the ECC information to the nand_chip{} ?
>>     Each nand chip has its requirement for the ECC correctability, such as
>>     "4bit ECC for each 512Byte" or "40bit ECC for each 1024Byte".
>>     This ECC info is very important to the nand controller, such as gpmi.
>>
>>     Take the Micron MT29F64G08CBABA for example, its geometry is
>>     8k page size, 744 bytes oob size and it requires 40bit ECC per 1K bytes.
>>     If we do not provide the ECC info to the gpmi nand driver, it has to
>>     calculate the ECC correctability itself. The gpmi driver will gets the 56bit
>>     ECC for per 1K bytes which is beyond its BCH's 40bit ecc capibility.
>>     The gpmi will quits in this case. But in actually, the gpmi can supports
>>     this nand chip if it can get the right ECC info.
>>
>> 2.) About the patch set:
>>     2.1) patch 1:
>>                The keynote patch.
>>
>>     2.2) patch 2 ~ patch 6:
>>                 These patches are for ONFI nand.
>>                 Parse out the ecc info from the parameter page if we can, else
>>                 parse out the ecc info from the extended parameter page.
>>
>>     2.2) patch 7 ~ patch 9:
>>                 Add the ECC info for full-id nand, and parse it out.
>>
>>     2.3) patch 10
>>                 The gpmi uses the ecc info to set the BCH module. and with this
>>                 patch set, the gpmi can supports the MT29F64G08CBABA now.
> What's the status on this patch set? Surely by v6 we have some
> reasonable stable state on things like naming. Does anyone have any
> other objections? Unfortunately, I've been awfully distracted, and on
> top of that, I'm running into some bugs with my NAND controller
> sending the ONFI parameter read/change column commands. But any time
> my controller actually outputs a correct parameter page + extended
> parameter page, this series has worked for me.
>
> I've put my 2 cents in on most of the issues I had, and I tested the
> whole series on my driver at around v5. The only issues I have with it
> are somewhat cosmetic and not worth bikeshedding. So for all the
> non-GPMI specific stuff I'll give my:
>
> Reviewed-by: Brian Norris<computersforpeace@...il.com>
> Tested-by: Brian Norris<computersforpeace@...il.com>
>
> Thanks for the work Huang.
>
> Brian
>
Could you please merge this patch set?


thanks

Huang Shijie


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ