* Hiremath, Vaibhav <hvaib...@ti.com> [120507 22:52]: > On Tue, May 08, 2012 at 01:05:01, Tony Lindgren wrote: > > * Tony Lindgren <t...@atomide.com> [120507 12:22]: > > > * Paul Walmsley <p...@pwsan.com> [120507 12:11]: > > > > Hi, > > > > > > > > On Fri, 4 May 2012, Tony Lindgren wrote: > > > > > > > > > How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? > > > > > Then this becomes just: > > > > > > > > > > #ifdef CONFIG_SOC_OMAP3PLUS > > > > > > > > We might want to consider having separate CONFIG_SOC_* values for each > > > > SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have > > > > CONFIG_SOC_OMAP3430, > > > > CONFIG_SOC_OMAP3630, etc. > > > > > > Hmm but this would be in addition to the SOC specific options. The goal > > > is to cut down the ifdeffery needed all over the place to add new SoCs, > > > see the experimental patch I posted: > > > > > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html > > > > Of course we could make this finer grained based on features > > like SOC_HAS_XYZ or SOC_HAS_OMAP3PLUS_PRMXYZBITS if you have some > > grouping like that in mind. > > > > This is much better approach than both ARCH_OMAPx and SOC_OMAPxxxx.
OK good, so now the question is just what groupings we need.. Got any suggestions? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
