Skip to content

Commit 9be1446

Browse files
committed
mtd: rawnand: fsmc: Fix use of SM ORDER
The introduction of the generic ECC engine API lead to a number of changes in various drivers which broke some of them. Here is a typical example: I expected the SM_ORDER option to be handled by the Hamming ECC engine internals. Problem: the fsmc driver does not instantiate (yet) a real ECC engine object so we had to use a 'bare' ECC helper instead of the shiny rawnand functions. However, when not intializing this engine properly and using the bare helpers, we do not get the SM ORDER feature handled automatically. It looks like this was lost in the process so let's ensure we use the right SM ORDER now. Fixes: ad9ffdc ("mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper") Cc: [email protected] Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
1 parent c2606dd commit 9be1446

File tree

1 file changed

+3
-1
lines changed

1 file changed

+3
-1
lines changed

drivers/mtd/nand/raw/fsmc_nand.c

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -438,8 +438,10 @@ static int fsmc_correct_ecc1(struct nand_chip *chip,
438438
unsigned char *read_ecc,
439439
unsigned char *calc_ecc)
440440
{
441+
bool sm_order = chip->ecc.options & NAND_ECC_SOFT_HAMMING_SM_ORDER;
442+
441443
return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc,
442-
chip->ecc.size, false);
444+
chip->ecc.size, sm_order);
443445
}
444446

445447
/* Count the number of 0's in buff upto a max of max_bits */

0 commit comments

Comments
 (0)