| Message ID | 1366734653-488286-22-git-send-email-arnd@arndb.de |
|---|---|
| State | Accepted |
| Commit | 930d800bded771b26d9944c47810829130ff7c8c |
| Headers | show |
> * Arnd Bergmann <arnd@arndb.de> [130423 09:37]: > > The omap2 nand device driver calls into the the elm code, which can > > be a loadable module, and in that case it cannot be built-in itself. > > I can see no reason why the omap2 driver cannot also be a module, > > so let's make the option "tristate" in Kconfig to fix this allmodconfig > > build error: > > > > ERROR: "elm_config" [drivers/mtd/nand/omap2.ko] undefined! > > ERROR: "elm_decode_bch_error_page" [drivers/mtd/nand/omap2.ko] > undefined! > > [Pekon]: ELM module is required in for Hardware based ECC correction for NAND devices. And this driver has a very small foot-print. The only cases this drives would _not_ be used are: (a) Using S/W based ECC scheme, which have vey high CPU utilization (b) Using single bit ECC scheme, which are becoming obsolete due to increasing NAND densities. For most of the cases ELM module will be used with nand-driver. So there should be no harm in having this module as built-in, if not used in 10% of the use-cases. Thus I think it's better to keep this module tied to GPMC module, rather than independent control via KConfig. And user should just selects which ECC scheme he would like to use via DT, without worrying about KConfig options. I'm working in cleaning up omap2-nand driver to remove some redundancies. So would like to know your feedback on same.. with regards, pekon
On Wednesday 24 April 2013, Gupta, Pekon wrote: > [Pekon]: > ELM module is required in for Hardware based ECC correction for > NAND devices. And this driver has a very small foot-print. > > The only cases this drives would not be used are: > (a) Using S/W based ECC scheme, which have vey high CPU utilization > (b) Using single bit ECC scheme, which are becoming obsolete due to > increasing NAND densities. > For most of the cases ELM module will be used with nand-driver. So > there should be no harm in having this module as built-in, if not used > in 10% of the use-cases. > > Thus I think it's better to keep this module tied to GPMC module, > rather than independent control via KConfig. > And user should just selects which ECC scheme he would like to > use via DT, without worrying about KConfig options. Sorry, I'm lost here and have no idea what you are actually suggesting we do. Can you phrase that as a patch? Unless you come up with a better solution, I would still like to queue up my patch since it fixes an annoying bug and seems to have no downsides. > I'm working in cleaning up omap2-nand driver to remove some > redundancies. So would like to know your feedback on same.. Sure, just Cc me on your patches. Arnd
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 81bf5e5..106b55e 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -109,7 +109,7 @@ config MTD_NAND_OMAP2 config MTD_NAND_OMAP_BCH depends on MTD_NAND && MTD_NAND_OMAP2 && ARCH_OMAP3 - bool "Enable support for hardware BCH error correction" + tristate "Enable support for hardware BCH error correction" default n select BCH select BCH_CONST_PARAMS
The omap2 nand device driver calls into the the elm code, which can be a loadable module, and in that case it cannot be built-in itself. I can see no reason why the omap2 driver cannot also be a module, so let's make the option "tristate" in Kconfig to fix this allmodconfig build error: ERROR: "elm_config" [drivers/mtd/nand/omap2.ko] undefined! ERROR: "elm_decode_bch_error_page" [drivers/mtd/nand/omap2.ko] undefined! Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Afzal Mohammed <afzal@ti.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: linux-mtd@lists.infradead.org --- drivers/mtd/nand/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)