Home
last modified time | relevance | path

Searched hist:"305 b93f1" (Results 1 – 1 of 1) sorted by relevance

/openbmc/linux/drivers/mtd/
H A Dmtdchar.c305b93f1 Tue Aug 23 19:17:32 CDT 2011 Brian Norris <computersforpeace@gmail.com> mtd: do not assume oobsize is power of 2

Previous generations of MTDs all used OOB sizes that were powers of 2,
(e.g., 64, 128). However, newer generations of flash, especially NAND,
use irregular OOB sizes that are not powers of 2 (e.g., 218, 224, 448).
This means we cannot use masks like "mtd->oobsize - 1" to assume that we
will get a proper bitmask for OOB operations.

These masks are really only intended to hide the "page" portion of the
offset, leaving any OOB offset intact, so a masking with the writesize
(which *is* always a power of 2) is valid and makes more sense.

This has been tested for read/write of NAND devices (nanddump/nandwrite)
using nandsim and actual NAND flash.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@intel.com>
305b93f1 Tue Aug 23 19:17:32 CDT 2011 Brian Norris <computersforpeace@gmail.com> mtd: do not assume oobsize is power of 2

Previous generations of MTDs all used OOB sizes that were powers of 2,
(e.g., 64, 128). However, newer generations of flash, especially NAND,
use irregular OOB sizes that are not powers of 2 (e.g., 218, 224, 448).
This means we cannot use masks like "mtd->oobsize - 1" to assume that we
will get a proper bitmask for OOB operations.

These masks are really only intended to hide the "page" portion of the
offset, leaving any OOB offset intact, so a masking with the writesize
(which *is* always a power of 2) is valid and makes more sense.

This has been tested for read/write of NAND devices (nanddump/nandwrite)
using nandsim and actual NAND flash.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@intel.com>