Re: [PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Daniel Lezcano]

On 11/03/2015 11:02 AM, Arnd Bergmann wrote:
> On Tuesday 03 November 2015 09:40:02 Daniel Lezcano wrote:
> > On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote:
> > > On 03.11.2015 09:30, Krzysztof Kozlowski wrote:
> > > > On 02.11.2015 21:56, Daniel Lezcano wrote:
> > > > > Let the platform's Kconfig to select the clock instead of having a reverse
> > > > > dependency from the driver to the platform options.
> > > >
> > > > Selecting user-visible symbols is rather discouraged so why not
> > > > something like this:
> > > >
> > > > -       def_bool y if ARCH_EXYNOS
> > > > -       depends on !ARM64
> > > > +       bool "Exynos multi core timer driver"
> > > > +       depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)
> > >
> > > Nope, that was wrong as we loose auto-select on Exynos. Instead:
> > > -       def_bool y if ARCH_EXYNOS
> > > -       depends on !ARM64
> > > +       bool "Exynos multi core timer driver" if ARM
> > > +       depends on ARCH_EXYNOS || COMPILE_TEST
> > > +       default y if ARCH_EXYNOS
> > >
> > > This way we avoid select (which is a reverse dependency for the driver),
> > > have it auto-selectable and compile tested on arm.
> >
> > I think you misunderstood the patch I sent.
> >
> > It does two things:
> >
> > 1. Follow the thumb of rule of the current Kconfig format
> >
> >      - The timer driver is selected by the platform (exynos in this case)
> >      - User can't select the driver in the menuconfig
> >      - There is no dependency on the platform except for compilation test
> >
> > 2. Add the COMPILE_TEST
> >
> >      - User can select the driver for compilation testing. This is for
> > allyesconfig when doing compilation test coverage (exynos timer could be
> > compiled on other platform). As the delay code is not portable, we have
> > to restrict the compilation on the ARM platform, this is why there is
> > the dependency on ARM.
> >
> > I am currently looking at splitting the delay code in order to prevent
> > this restriction on this driver and some others drivers.
>
> I suspect this will come up again in the future. The problem is
> really that drivers/clocksource has different rules from almost
> everything else, by requiring the platform to 'select' the driver.
>
> The second version that Krzysztof posted is how we handle this in
> other driver subsystems, and I would generally prefer it to do this
> consistently for everything, but John Stultz has in the past argued
> strongly for using 'select' in all clocksource drivers. The reason
> is that for each platform we know in advance which driver we want,
> and there is never a need for the user to have to select the right
> one.

Yes, and I second John in this.



--
 <http://www.linaro.org/> Linaro.org â Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/