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

[Thomas Weißschuh]

On Wed, Jul 15, 2026 at 12:13:06PM +0200, Arnd Bergmann wrote:
> 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.

See [0], where HAVE_GENERIC_VDSO is now VDSO_DATASTORE.
The naming "generic vDSO" does not make much sense anymore.
There are different pieces which are used in various combinations.

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

It doesn't build the time bits. But it has the hwprobe bits,
which do need the datastore (which is effectively HAVE_GENERIC_VDSO).

> On loongarch32, the commit adding the vdso said
> GENERIC_GETTIMEOFDAY 'will be supported in future'.

I have no idea if this port is even functional right now.
So far I was unable to run it in QEMU.

> On everything else, GENERIC_GETTIMEOFDAY and HAVE_GENERIC_VDSO
> are already synonyms.

[0] https://lore.kernel.org/lkml/20260709-vdso-have_generic_vdso-v1-0-d2e1061f268b@linutronix.de/