From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?QW5kcmVhcyBCaWXDn21hbm4=?= Date: Thu, 05 Sep 2013 08:28:06 +0200 Subject: [U-Boot] [PATCH] MTD: atmel_nand: support for software BCH ECC In-Reply-To: <1378323841.12204.40.camel@snotra.buserror.net> References: <1377701666-9632-1-git-send-email-voice.shen@gmail.com> <52270A1A.2080205@gmail.com> <5227238B.8020205@gmail.com> <522727DC.5020209@gmail.com> <52272BB7.8050900@gmail.com> <52274E82.6030300@gmail.com> <1378323841.12204.40.camel@snotra.buserror.net> Message-ID: <52282476.9060501@googlemail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Scott Wood, On 04.09.13 21:44, Scott Wood wrote: > On Wed, 2013-09-04 at 17:15 +0200, Andreas Bie?mann wrote: >> 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. I think this is a 'yes we take it'. Scott, would you pull it in or should I do? Is it even that minor to pull it into 2013.10? It was posted weeks after merge window closed. Best regards Andreas Bie?mann