* Paul Mundt <lethal@xxxxxxxxxxxx> [101117 22:09]: > On Wed, Nov 17, 2010 at 02:28:11PM +0200, Tomi Valkeinen wrote: > > On Tue, 2010-11-16 at 21:10 +0100, ext Tony Lindgren wrote: > > > Sure a module would be even better. My point is that the selection of > > > all the features should be enabled by default and the board options come > > > from platform_data. > > > > Ok, let's build DSS & all panel drivers as modules by default. > > > > Somehow I've gotten the impression from linux ml that enabling features > > by default is bad. But perhaps it's more about intervening features than > > normal drivers. > > > The general rule is to avoid default enabling unless you really need it, > but it still remains optional (which is why it's not being selected, > instead). Some, like gpiolib, have come up with WANT/NEED options for the > platform code to select in order to work out the desired behaviour, and > you may benefit from a similar approach for your subsystem if it's really > that integral for some parts. > > The flip side of course is that if you expect your users to primarily be > using the defconfigs provided, you can simply leave it default disabled > in the Kconfig and set the options you want in the defconfigs. > > Unless you can say with certainty that all OMAP3 boards are going to want > DSS enabled or modular by default, it's almost always better to just > leave it up to the defconfigs. I wish we could just do "default m if ARCH_OMAP2PLUS_TYPICAL".. But meanwhile setting it as a module in omap2plus_defconfig does the trick though like you say. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
