Re: [PATCH] mtd: docg3 fix in-middle of blocks reads

[Robert Jarzmik <robert.jarzmik@free.fr>]

David Woodhouse <dwmw2@infradead.org> writes:

> On Mon, 2012-04-09 at 13:19 +0200, Robert Jarzmik wrote:
>> 
>> 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. 
>
> Um, this seems complex. Wouldn't it be easier just to say "Don't Do That
> Then" — always read a multiple of two bytes, even if the caller doesn't
> care about the last byte?

Hi David,

I don't get the "Don't Do That Then".

The caller here, UBIFS, wants to read 12 bytes at offset 111 => [
byte111..byte122]. Note that the number of wanted bytes is even, and it's the
offset which is _odd_.

The problem for the driver is to read the 111 first bytes and forget them, and
then store the next 12 bytes. I don't see an alternative here, apart from having
a bounce buffer to read the bytes [byte110..byte122], and then copy into the
destination buffer. And I really don't want the bounce buffer.

Do you see any other alternative ?

Cheers.

-- 
Robert