On Thursday, February 06, 2014 10:25:09 AM Olof Johansson wrote: > On Thu, Feb 6, 2014 at 7:02 AM, Bartlomiej Zolnierkiewicz > <[email protected]> wrote: > > > > Hi, > > > > On Thursday, February 06, 2014 03:10:39 PM Tomasz Figa wrote: > >> Hi Sachin, > >> > >> On 06.02.2014 12:59, Sachin Kamat wrote: > >> > Instead of repeating the Kconfig entries for every SoC, move them under > >> > ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under > >> > ARCH_EXYNOS. Also, since the individual SoCs do not have any specific > >> > machine/platform code, keep them as boolean symbols instead of user > > > > All soc_is_exynosxxxx() dependent code gets thrown away is specific SoC > > support is not selected. With this change this is not longer true. > > Moreover some drivers are doing explicit ifdef checks for specific SoC > > support, i.e. thermal driver. > > I'm guessing you're referring to exynos_tmu_data.c? That's not all
Yes. > that much data, and not all that substantial compared to things like > pinctrl and clocks. Removing those ifdefs per SoC is reasonable. I agree. I just wanted to point out that the current patch description is not entirely accurate. > I'm ok with one Kconfig per family (EXYNOS 4 and 5), but we should > avoid higher granularity than that. That's similar to how OMAP is > handled. i.MX is more granular but they aren't introducing as many > SoCs as Samsung so it's not as big a deal. OK. > >> > selectable and select them from Exynos4 and 5 config symbols. Individual > >> > SoC symbols can be removed eventually once the driver Kconfig > >> > dependencies > >> > on these symbols are removed. > >> > > >> > Signed-off-by: Sachin Kamat <[email protected]> > >> > --- > >> > arch/arm/Kconfig | 12 ++++++ > >> > arch/arm/mach-exynos/Kconfig | 97 > >> > ++++++++++-------------------------------- > >> > 2 files changed, 35 insertions(+), 74 deletions(-) > >> > >> I fully agree that there is no real need of having per-SoC Kconfig > >> entries, since the differences caused by them are quite insignificant. > > > > I think so but some numbers to back it up would be good.. > > > >> Moreover, this makes me wonder if there is even need to distinguish > >> between ARCH_EXYNOS4 and ARCH_EXYNOS5... > > > > Well, once again, seeing some numbers would be good. :) > > What numbers do you want? Size comparisons with all SoC options on vs only > one? Yes, size comparisions with all SoCs (for given family) turned on vs only one turned on (done on kernel without this patch applied). Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch applied). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
