linux-kernel - RE: [PATCH 21/21] mtd: omap2: allow bulding as a module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Apr 2013 05:34:21 +0000
From:	"Gupta, Pekon" <pekon@...com>
To:	Tony Lindgren <tony@...mide.com>, Arnd Bergmann <arnd@...db.de>
CC:	"Mohammed, Afzal" <afzal@...com>,
	Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	Russell King <rmk+kernel@....linux.org.uk>,
	David Woodhouse <dwmw2@...radead.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 21/21] mtd: omap2: allow bulding as a module

> * Arnd Bergmann <arnd@...db.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/