[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a12789f5-002f-51b1-7051-8802ec81d8e0@linaro.org>
Date: Tue, 19 Sep 2017 00:02:55 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Arnd Bergmann <arnd@...db.de>, Thomas Gleixner <tglx@...utronix.de>
Cc: Randy Dunlap <rdunlap@...radead.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
linux-m68k@...ts.linux-m68k.org, linux-ia64@...r.kernel.org,
Tony Luck <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Linus Walleij <linus.walleij@...aro.org>,
Ding Tianhong <dingtianhong@...wei.com>,
Mark Rutland <mark.rutland@....com>,
Marc Zyngier <marc.zyngier@....com>,
Vineet Gupta <vgupta@...opsys.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency
On 05/09/2017 17:04, Arnd Bergmann wrote:
> We regularly run into build errors when a clocksource driver selects
> CONFIG_TIMER_OF while CONFIG_GENERIC_CLOCKEVENTS is disabled:
>
> In file included from drivers/clocksource/timer-of.c:25:0:
> drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete type
>
> At the moment, three drivers can show this behavior: ARMV7M_SYSTICK,
> CLKSRC_ST_LPC and CLKSRC_NPS. We could add further dependencies as we did
> many times, but I have looked a little bit more at what architectures
> are left that don't use GENERIC_CLOCKEVENTS, and this shows that there
> is a better solution.
>
> On arch/frv and arch/ia64, we never select CONFIG_GENERIC_CLOCKEVENTS
> and we also don't use ARCH_USES_GETTIMEOFFSET, which would
> block the clocksource Kconfig menu. On m68k, some platforms use
> CONFIG_GENERIC_CLOCKEVENTS, some use ARCH_USES_GETTIMEOFFSET, and some
> use neither of them. The good news is that there is no configuration that
> does not set CONFIG_GENERIC_CLOCKEVENTS but that wants to enable any of
> the Kconfig symbols in the menu, so we can simply replace the dependency
> with the stricter one. While in theory one could have a clocksource
> driver without the clockevent infrastructure, this seems unlikely
> to be relevant in the future any more.
>
> We can probably drop some of the other dependencies as well now,
> e.g. there should generally be no reason to depend on CONFIG_ARM
> unless the driver uses architecture specific assembly.
>
> Reported-by: Randy Dunlap <rdunlap@...radead.org>
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
Makes sense. Agree with this change.
--
<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
Powered by blists - more mailing lists