clarify calculation in nand_read_subpage and fix possible bug

Alexey Korolev akorolev at infradead.org
Fri Nov 7 06:01:09 EST 2008


Hi Werner,

Hah. You are right. But this case is so weird!
Please send patch in form of patch with your Signed-off line and add 
Acked-by: Alexey Korolev <akorolev at infradead.org>

Thank you very much for this patch!

Alexey

> 
> > But I did not understand the note about a bug.
> > What is the case when bug appears? (What is the distribution of ecc
> > positions)
> 
> That bug is just for a hypothetical layout. If we assume that the
> ECC layout can be completely arbitrary, then we could have a layout
> that looks like this:
> 
> position	0 1 2 3 4 5 6 7 8 9 10
> ECC block	- A A A B B B - C C C
> 
> Let's assume we want to read the ECC bytes AAA and BBB. Our bus
> width is 2 bytes. With the original algorithm, the unaligned
> position would be 1, the unaligned length 6. 
> 
> 	/* no alignment: pos = 1, length = 6 */
> 
> 	aligned_pos = eccpos[start_step * chip->ecc.bytes] & ~(busw - 1);
> 
> 	/* aligned_pos = 0, ok */
> 
> 	aligned_len = eccfrag_len;
> 
> 	/* aligned_len = 6 */
> 
> 	if (eccpos[start_step * chip->ecc.bytes] & (busw - 1))
> 		aligned_len++;
> 
> 	/* the original start was unaligned, so aligned_len = 7 */
> 
> 	if (eccpos[(start_step + num_steps) * chip->ecc.bytes] & (busw - 1))
> 		aligned_len++;
> 
> 	/* the next block is aligned, so aligned_len = 7 */
> 
> I don't know if this is something one could encounter in real life,
> but then, there are lot of people with crazy ideas out there ;-)
> 
> - Werner
> 



More information about the linux-mtd mailing list