Re: [PATCH] clocksource: time-efm32: Select CLKSRC_MMIO

[Daniel Lezcano]

On 12/10/2013 02:24 PM, Uwe Kleine-KÃnig wrote:
> On Wed, Nov 20, 2013 at 10:15:11AM +0800, Axel Lin wrote:
> > The time-efm32 driver uses the clocksource MMIO functions.
> > Thus it needs to select CLKSRC_MMIO in Kconfig.
> >
> > Signed-off-by: Axel Lin <axel.lin@xxxxxxxxxx>
> > ---
> > This fixes build error when COMPILE_TEST=y.
> > drivers/built-in.o: In function `efm32_clocksource_init':
> > drivers/clocksource/time-efm32.c:162: undefined reference to `clocksource_mmio_init'
> > drivers/built-in.o: In function `efm32_timer_init':
> > drivers/clocksource/time-efm32.c:274: undefined reference to `clocksource_mmio_readl_up'
> > make: *** [vmlinux] Error 1
> >
> >   drivers/clocksource/Kconfig | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index bdb953e..99763eb 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -75,6 +75,7 @@ config CLKSRC_DBX500_PRCMU_SCHED_CLOCK
> >   config CLKSRC_EFM32
> >   	bool "Clocksource for Energy Micro's EFM32 SoCs" if !ARCH_EFM32
> >   	depends on OF && ARM && (ARCH_EFM32 || COMPILE_TEST)
> > +	select CLKSRC_MMIO
> >   	default ARCH_EFM32
> I'd like to send support for arch/arm/mach-efm32 for 3.14. Formerly I
> had ARCH_EFM32 select CLKSRC_MMIO, but having it here is obviously the
> correct thing to do. So my possibilities are:
>
>   a) I take this patch and apply mach-efm32 on top of it; or
>   b) you take it early enough for me into 3.13-rc to base mach-efm32 on
>      it; or

I sent the PR with this patch. If everything is ok, it should be in the 
next -rc.

>   c) I send mach-efm32 with ARCH_EFM32 selecting CLKSRC_MMIO and drop
>      this select later; or
>   d) we life with the build failure (i.e.
>      drivers/clocksource/time-efm32.c:274: undefined reference to
>      `clocksource_mmio_readl_up' and the same for clocksource_mmio_init
>      in a different line) until this patch and mine come together.
>
> I don't like d), but don't have a clear favorite between a), b) and c).
> What do you think? Probably a) is the easiest for all if there are no
> merge conflicts (I don't expect any). In this case I'd need Daniel's or
> Thomas' ack.
>
> Thanks
> Uwe


--
 <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/