]> git.karo-electronics.de Git - karo-tx-linux.git/commit
mtd: docg3 fix in-middle of blocks reads
authorRobert Jarzmik <robert.jarzmik@free.fr>
Mon, 9 Apr 2012 11:19:08 +0000 (13:19 +0200)
committerArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
Fri, 27 Apr 2012 06:02:19 +0000 (09:02 +0300)
commit554260ce4dbca3ffd442147f1884ed4ae95dac37
treef22b5aabfb9eef2fe5ebcd4b8cbb822c32e32222
parentfa9d2c35d5a1f5f65f18df8352a0494e0e6fbb6d
mtd: docg3 fix in-middle of blocks reads

Corner case reads do not work, and return false data and
ECC. This case is typically seen in a ubifs usage, with a
read of type:
 - docg3 docg3: doc_read_oob(from=14882415, mode=1,
 data=(c30eca40:12), oob=(  (null):0))

This results in the following reads:
 - docg3 docg3: doc_read_data_area(buf=  (null), len=111)
 - docg3 docg3: doc_read_data_area(buf=c30eca40, len=12)
 - docg3 docg3: doc_read_data_area(buf=  (null), len=389)
 - docg3 docg3: doc_read_data_area(buf=  (null), len=0)
 - docg3 docg3: doc_read_data_area(buf=  (null), len=16)

If we suppose that the pages content is :
 - bytes 0 .. 111   : 0x0a
 - bytes 112 .. 255 : 0x0f
Then the returned bytes will be :
 - 111 times 0x0a (correct)
 - 0x0a 2 times and 0x0f 10 times (incorrect, should be
 0x0a,0x0f)
 - 0x0f 389 times (correct)
 - nothing
 - correct OOB

The reason seams that the first 111 bytes read ends between
the 2 docg3 planes, and that the first following read (in
the 12 bytes sequence, read of 16 bit word) returns the byte
of the rightmost plane duplicated in high and lower byte of
the word.

Fix this behaviour by ensuring that if the previous read
ended up in-between the 2 planes, there will be a first 1
byte read to get back to the beginning of leftmost plane.

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
drivers/mtd/devices/docg3.c