Hi, On 25/09/2012, Felipe Balbi <balbi@xxxxxx> wrote: >> > > Not a mention of CONFIG_SOC_OMAP2430 and CONFIG_SOC_OMAP3430 did not >> > > get set (while it is not a 3430 but a 3630 I am using). Maybe >> > > CONFIG_ARCH_OMAP3 would have been a better choice then? >> > >> > that's quite f**ked up. Tony, why doesn't SOC_OMAP3430 get set for all >> > OMAP3 boards ? And another question: why don't we have a matching >> > SOC_OMAP3530, SOC_OMAP3630 and so on ? >> >> ARCH_OMAP3 will probably eventually just disappear and >> be replaced with ARCH_OMAP2PLUS + SOC_XXXX. But there's >> no need to do it right now as most of that should be >> internal to arch/arm/mach-omap2 anyways. I would just >> set the driver to depend on ARCH_OMAP2PLUS, and rely on >> the platform_data and DT to do something if specified. >> That means that on 2420 musb should not probe unless >> tusb6010 in specified. >> >> It seems that things like fifo_mode and generic_interrupt >> can all be set during the probe based on the platform_data >> or DT passed information? > > Then maybe it's best to just remove the ifdefs and always provide > generic_interrupt() ? > > Anyone against it ? Well it seems there are only two drivers that use it omap2430 and ux500. Maybe we somehow link it to the drivers that need it? (I might have missed other drivers but it looks like it is just those two) Regards, Philippe -- 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
