user/sven/linux.git/include/linux/mtd, branch v3.12.23

mtd: map: fixed bug in 64-bit systems

2013-12-04T19:05:25Z

commit a4d62babf988fe5dfde24437fa135ef147bc7aa0 upstream. Hardware: CPU: XLP832,the 64-bit OS NOR Flash:S29GL128S 128M Software: Kernel:2.6.32.41 Filesystem:JFFS2 When writing files, errors appear: Write len 182 but return retlen 180 Write of 182 bytes at 0x072c815c failed. returned -5, retlen 180 Write len 186 but return retlen 184 Write of 186 bytes at 0x072caff4 failed. returned -5, retlen 184 These errors exist only in 64-bit systems,not in 32-bit systems. After analysis, we found that the left shift operation is wrong in map_word_load_partial. For instance: unsigned char buf[3] ={0x9e,0x3a,0xea}; map_bankwidth(map) is 4; for (i=0; i < 3; i++) { int bitpos; bitpos = (map_bankwidth(map)-1-i)*8; orig.x[0] &= ~(0xff << bitpos); orig.x[0] |= buf[i] << bitpos; } The value of orig.x[0] is expected to be 0x9e3aeaff, but in this situation(64-bit System) we'll get the wrong value of 0xffffffff9e3aeaff due to the 64-bit sign extension: buf[i] is defined as "unsigned char" and the left-shift operation will convert it to the type of "signed int", so when left-shift buf[i] by 24 bits, the final result will get the wrong value: 0xffffffff9e3aeaff. If the left-shift bits are less than 24, then sign extension will not occur. Whereas the bankwidth of the nor flash we used is 4, therefore this BUG emerges. Signed-off-by: Pang Xunlei Signed-off-by: Zhang Yi Signed-off-by: Lu Zhongjun Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman

mtd: add a new ecc_step_size field to mtd_info{}

2013-08-30T20:37:01Z

In order to implement the NAND boot for some Freescale's chips, such as imx23/imx28/imx50/imx6, we use a tool (called kobs-ng) to burn the uboot and some metadata to nand chip. And the ROM code will use the metadata to configrate the BCH, and to find the uboot. The ECC information(ecc step size, ecc strength) which is used to configrure the BCH is part of the metadata. The kobs-ng can get the ecc strength from the sys node /sys/*/ecc_strength now. But it can not get the ecc step size. This patch adds a new field to store the ecc step size in mtd_info{}, and it makes preparation for the next patches. Signed-off-by: Huang Shijie Signed-off-by: Artem Bityutskiy Signed-off-by: Brian Norris Signed-off-by: David Woodhouse

mtd: add ECC info for nand_flash_dev{}

2013-08-30T20:34:45Z

Add an instance of an anonymous struct to store the ECC info for full id nand chips. @ecc.strength_ds: ECC correctability from the datasheet. @ecc.step_ds: ECC size required by the @ecc.strength_ds, These two fields are all from the datasheet. Also add the necessary macros to make the code simple and clean. Signed-off-by: Huang Shijie Signed-off-by: Brian Norris Signed-off-by: David Woodhouse

mtd: add a helper to get the supported features for ONFI nand

2013-08-30T20:34:41Z

add a helper to get the supported features for ONFI nand. Also add the neccessary macros. Signed-off-by: Huang Shijie Reviewed-and-tested-by: Brian Norris Signed-off-by: Brian Norris Signed-off-by: David Woodhouse

mtd: add data structures for Extended Parameter Page

2013-08-30T20:34:40Z

Since the ONFI 2.1, the onfi spec adds the Extended Parameter Page to store the ECC info. The onfi spec tells us that if the nand chip's recommended ECC codeword size is not 512 bytes, then the @ecc_bits is 0xff. The host _SHOULD_ then read the Extended ECC information that is part of the extended parameter page to retrieve the ECC requirements for this device. This patch adds [1] the neccessary fields for nand_onfi_params{}, [2] and adds the onfi_ext_ecc_info{} for Extended ECC information, [3] adds onfi_ext_section{} for extended sections, [4] and adds onfi_ext_param_page{} for the Extended Parameter Page. Acked-by: Pekon Gupta Signed-off-by: Huang Shijie Reviewed-and-tested-by: Brian Norris [Brian: amended for checkpatch.pl] Signed-off-by: Brian Norris Signed-off-by: David Woodhouse

mtd: add datasheet's ECC information to nand_chip{}

2013-08-30T20:34:37Z

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 8KiB page size, 744 bytes oob size and it requires 40bit ECC per 1KiB. 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 1KiB 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 new fields. The @ecc_strength_ds stands for the ecc bits needed within the @ecc_step_ds. The two fields should be set from the nand chip's datasheets. For example: "4bit ECC for each 512Byte" could be: @ecc_strength_ds = 4, @ecc_step_ds = 512. "40bit ECC for each 1024Byte" could be: @ecc_strength_ds = 40, @ecc_step_ds = 1024. 3.) Why do not re-use the @strength and @size in the nand_ecc_ctrl{}? The @strength and @size in nand_ecc_ctrl{} is used by the nand controller driver, while the @ecc_strength_ds and @ecc_step_ds are get from the datasheet. Signed-off-by: Huang Shijie Reviewed-and-tested-by: Brian Norris Signed-off-by: Brian Norris Signed-off-by: David Woodhouse

mtd: nand: remove NAND_BBT_SCANEMPTY

2013-08-30T15:48:37Z

NAND_BBT_SCANEMPTY is a strange, badly-supported option with omap as its single remaining user. NAND_BBT_SCANEMPTY was likely used by accident in omap2[1]. And anyway, omap2 doesn't scan the chip for bad blocks (courtesy of NAND_SKIP_BBTSCAN), and so its use of this option is irrelevant. This patch drops the NAND_BBT_SCANEMPTY option. [1] http://lists.infradead.org/pipermail/linux-mtd/2012-July/042902.html Signed-off-by: Brian Norris Cc: Ivan Djelic Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse

mtd: nand: hide in-memory BBT implementation details

2013-08-30T15:48:17Z

nand_base.c shouldn't have to know the implementation details of nand_bbt's in-memory BBT. Specifically, nand_base shouldn't perform the bit masking and shifting to isolate a BBT entry. Instead, just move some of the BBT code into a new nand_markbad_bbt() interface. This interface allows external users (i.e., nand_base) to mark a single block as bad in the BBT. Then nand_bbt will take care of modifying the in-memory BBT and updating the flash-based BBT (if applicable). Signed-off-by: Brian Norris Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse

mtd: nand_base: Only use GET/SET FEATURES command on chips that support them.

2013-08-05T19:49:04Z

Spansion's S34MLx chips support ONFI but not the GET/SET FEATURES calls. Signed-off-by: David Mosberger Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse

mtd: nand: fsmc: update of OF support

2013-08-05T19:48:49Z

Add nand bank selection and timings to the device tree bindings. Signed-off-by: Mian Yousaf Kaukab [Added some documentation] Signed-off-by: Linus Walleij Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse