Re: [PATCH 3/7] MIPS: csrc-r4k: Replace CONFIG_GENERIC_GETTIMEOFDAY ifdeffery with IS_ENABLED()

["Arnd Bergmann" <arnd@arndb.de>]

On Wed, Jul 15, 2026, at 10:43, Thomas Weißschuh wrote:
> On Wed, Jul 15, 2026 at 10:25:19AM +0200, Thomas Gleixner wrote:

>> -#ifdef CONFIG_GENERIC_GETTIMEOFDAY
>>  #include <asm/vdso/clocksource.h>
>> -#endif /* CONFIG_GENERIC_GETTIMEOFDAY */
>>  enum vdso_clock_mode {
>>  	VDSO_CLOCKMODE_NONE,
>> -#ifdef CONFIG_GENERIC_GETTIMEOFDAY
>> +#ifdef VDSO_ARCH_CLOCKMODES
>>  	VDSO_ARCH_CLOCKMODES,
>>  #endif
>>  	VDSO_CLOCKMODE_MAX,
>> 
>> and then you can just unconditionally set clocksource::vdso_clock_mode
>> in all drivers.
>> 
>> No?
>
> It will weaken the sanity check in __clocksouce_register_scale() if
> CONFIG_GENERIC_GETTIMEOFDAY=n. I am not sure what that sanity check
> is supposed to protect against, so I left it as is.

Is there still a reason to even allow CONFIG_GENERIC_GETTIMEOFDAY=n
when  generic VDSO is enabled? I see that loongarch32 and
riscv32 are still missing the vdso time support, but that may
be more a sign that nobody cares enough about performance
on those targets.

In particular, riscv64 doesn't even build the vdso32 code for
compat tasks, which indicates that userspace doesn't actually
need vdso. On loongarch32, the commit adding the vdso said
GENERIC_GETTIMEOFDAY 'will be supported in future'.

On everything else, GENERIC_GETTIMEOFDAY and HAVE_GENERIC_VDSO
are already synonyms.

    Arnd