On Thursday, February 06, 2014 10:25:09 AM Olof Johansson wrote: > On Thu, Feb 6, 2014 at 7:02 AM, Bartlomiej Zolnierkiewicz > <b.zolnierkie@xxxxxxxxxxx> 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 <sachin.kamat@xxxxxxxxxx> > >> > --- > >> > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |