lkml.org 
[lkml]   [2017]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete type
On Tue, Sep 5, 2017 at 12:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Sep 4, 2017 at 7:01 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
>> On 09/02/17 23:28, kbuild test robot wrote:
>
>>
>> Summary:
>>
>> GENERIC_CLOCKEVENTS is not enabled. (ia64)
>> COMPILE_TEST=y
>>
>> #
>> # Clock Source drivers
>> #
>> CONFIG_TIMER_OF=y
>> CONFIG_CLKSRC_MMIO=y
>> # CONFIG_CLKSRC_PISTACHIO is not set
>> CONFIG_ARMV7M_SYSTICK=y
>> # CONFIG_ATMEL_PIT is not set
>> CONFIG_CLKSRC_ST_LPC=y
>>
>> Both ARMV7M_SYSTICK and CLKSRC_ST_LPC select TIMER_OF (if OF, which is enabled)
>> and select CLKSRC_MMIO. TIMER_OF depends on GENERIC_CLOCKEVENTS (=n), but
>> 'select' does not care about that "depends on".
>>
>> This build error only happens because COMPILE_TEST=y.
>>
>> Any driver that does 'select TIMER_OF' should also depend on GENERIC_CLOCKEVENTS.
>> The problem is that some drivers do 'select TIMER_OF if OF', so if OF is not
>> enabled, then we don't need to depend on GENERIC_CLOCKEVENTS.
>>
>>
>> "O, what a tangled web we weave when first we practise to deceive!" --Walter Scott
>>
>> Not that we are trying to deceive in this case -- it's just another Kconfig
>> tangled web.
>>
>> Arnd: any ideas?

> The only architectures that use neither GENERIC_CLOCKEVENTS
> nor ARCH_USES_GETTIMEOFFSET are frv, ia64 and some m68k
> configurations. If we can show that none of those configurations
> ever rely on clocksource drivers, we can simplify the
> drivers/clocksource/Kconfig file a lot by using a
> GENERIC_CLOCKEVENTS for the top-level option and removing
> all the other dependencies in there.

I had a closer look at this, and found a third one: CONFIG_CLKSRC_NPS
should show the same bug as CONFIG_ARMV7M_SYSTICK and
CLKSRC_ST_LPC on the two 32-bit architectures, it just did not trigger
on ia64 because of the '!PHYS_ADDR_T_64BIT' dependency.

None of those three drivers makes any sense on any of the three
architectures though, and all other drivers directly or indirectly
depend on GENERIC_CLOCKEVENTS already, so simply making
the whole directory depend on GENERIC_CLOCKEVENTS
should solve this problem for good. I'll send a patch.

Arnd

\
 
 \ /
  Last update: 2017-09-05 14:46    [W:0.644 / U:4.488 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site