[U-Boot] [PATCH] MTD: atmel_nand: support for software BCH ECC

[Scott Wood <scottwood@freescale.com>]

On Wed, 2013-09-04 at 17:15 +0200, Andreas Bie?mann wrote:
> Hi Bo,
> 
> On 09/04/2013 02:46 PM, Bo Shen wrote:
> > On 9/4/2013 8:30 PM, Andreas Bie?mann wrote:
> >>> >Yes, we need libbch.
> >>> >
> >>> >If we really want to enable software BCH support. It also need add
> >>> >following two options in board configuration file.
> >>> >---8>---
> >>> >#define CONFIG_NAND_ECC_BCH
> >>> >#define CONFIG_BCH
> >>> >---<8---
> >>> >
> >>> >So, this patch give us option to enable software BCH.
> >> got it. So the NAND_ECC_BCH is the adoption for the SW BCH correction in
> >> mtd layer. I understand that this would be helpful for at91 SoC without
> >> PMECC HW. But there is no user currently, so I hesitate to apply this.
> > 
> > Frankly, there is no EK boards from Atmel use software BCH now, however,
> > a lot of customers use NAND with 224 bytes OOB, can not use software
> > ECC, they need use software BCH.
> 
> I understand this. But it will be a piece of dead code until a user of
> it would be submitted.
> 
> > So, I think it is better to apply this patch. If it will break the rule
> > of u-boot, then I think we can wait real user in u-boot need this and
> > then apply this patch.
> 
> I'd like to hear Scott's comment on that.

Is this for the benefit of out-of-tree boards, or for boards which will
be submitted but haven't yet?

In the latter case, it could be submitted at the same time.  In the
former case, of course we encourage the boards to be submitted, and we
don't generally add code solely for the benefit of out-of-tree boards.  

In any case, this is minor enough that I don't care all that much.  If
we ever get kconfig, then hopefully the "dead code" rules will relax to
code which could be enabled through some legal config, rather than code
which is enabled in some default config for a board.  Things like
allyesconfig and randconfig could help with build test coverage.

-Scott