ARM defconfig files
in [Kernel]
|
Prev: menuconfig: fix to center checklist correctly in a corner case
Next: [PATCH -next] classmate-laptop: fix for RFKILL=m, CMPC=y
From: david on 6 Jun 2010 00:00 On Thu, 3 Jun 2010, Russell King wrote: > On Thu, Jun 03, 2010 at 11:20:30AM -0700, Daniel Walker wrote: >> I don't see how we can do without defconfigs altogether tho. I mean , if >> you want to run a Beagle board or a Nexus one we can't just give the >> users a slim ARM config and let them troll through 1000's of drivers >> trying to find just those ones that work on their given board. > > Well, Linus does have a point - I can't start a new with Kconfig and > generate a working defconfig first time mainly because of the > thounds of options there. > > What I can do is get the ARM side of the configuration right, since > for the majority of cases the only thing that needs doing is selecting > the platform class and the board itself. > > The problem comes with driver configuration, where you have to go > through lots of menus to find all the drivers for the platform/SoC. > That's the tedious bit, and more often than not it takes several > attempts to get everything that's necessary. Would the resulting kconfig files that Linus is proposing (or whatever else goes in) be stable enough across different kernel versions that the hardware vendors could create them when the hardware is created and make them available? I'm not just thinking the ARM embedded space here, I'm also thinking things like laptops/notebooks which tend to have some unusual hardware as well. having a 'this is enough to see everything on the system' config would be a wonderful starting place to have. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Catalin Marinas on 8 Jun 2010 11:40 Daniel Walker <dwalker(a)codeaurora.org> wrote: > Have you noticed this .. > > http://ktrap.org/mailarchive/linux-kernel/2010/5/17/4571130 > > I'm not sure of the goals, but it sounds like it might be relevant. In some cases you don't want to automatically enable features but rather fix the Kconfig file. For example, with the select dependencies patch (http://lkml.org/lkml/2009/9/16/413) on ARMv7 RealView I get the following: warning: (CPU_V7 && !ARCH_OMAP2 || CPU_MMP2 && ARCH_MMP) selects CPU_32v6K which has unmet direct dependencies (CPU_V6) Unless I misunderstand this, a solver may try to select CPU_V6 which I don't want to. The solution is to fix Kconfig as below: Author: Catalin Marinas <catalin.marinas(a)arm.com> Date: Wed Aug 12 13:50:05 2009 +0100 Mark CPU_32v6K as depended on CPU_V7 Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 9f10a9b..a4909db 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -398,7 +398,7 @@ config CPU_V6 # ARMv6k config CPU_32v6K bool "Support ARM V6K processor extensions" if !SMP - depends on CPU_V6 + depends on CPU_V6 || CPU_V7 default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) help Say Y here if your ARMv6 processor supports the 'K' extension. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Walker on 8 Jun 2010 12:40
On Tue, 2010-06-08 at 16:30 +0100, Catalin Marinas wrote: > Daniel Walker <dwalker(a)codeaurora.org> wrote: > > Have you noticed this .. > > > > http://ktrap.org/mailarchive/linux-kernel/2010/5/17/4571130 > > > > I'm not sure of the goals, but it sounds like it might be relevant. > > In some cases you don't want to automatically enable features but rather > fix the Kconfig file. For example, with the select dependencies patch > (http://lkml.org/lkml/2009/9/16/413) on ARMv7 RealView I get the > following: > > warning: (CPU_V7 && !ARCH_OMAP2 || CPU_MMP2 && ARCH_MMP) selects > CPU_32v6K which has unmet direct dependencies (CPU_V6) > > Unless I misunderstand this, a solver may try to select CPU_V6 which I > don't want to. The solution is to fix Kconfig as below: It seems like those are something the solver would likely find, or have problems with. Since we technically don't have a solver yet it's hard to say what the end result would be. None the less it's sucks we have things getting selected without their depends be met or correct.. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |