Re: [PATCH V15 10/24] LoongArch: Add other common headers

[Jason A. Donenfeld]

Hi Huacai,

On Fri, Jun 03, 2022 at 03:20:39PM +0800, Huacai Chen wrote:
> diff --git a/arch/loongarch/include/asm/timex.h b/arch/loongarch/include/asm/timex.h
> new file mode 100644
> index 000000000000..d3ed99a4fdbd
> --- /dev/null
> +++ b/arch/loongarch/include/asm/timex.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2022 Loongson Technology Corporation Limited
> + */
> +#ifndef _ASM_TIMEX_H
> +#define _ASM_TIMEX_H
> +
> +#ifdef __KERNEL__
> +
> +#include <linux/compiler.h>
> +
> +#include <asm/cpu.h>
> +#include <asm/cpu-features.h>
> +
> +/*
> + * Standard way to access the cycle counter.
> + * Currently only used on SMP for scheduling.
> + *
> + * We know that all SMP capable CPUs have cycle counters.
> + */
> +
> +typedef unsigned long cycles_t;
> +
> +#define get_cycles get_cycles
> +
> +static inline cycles_t get_cycles(void)
> +{
> +	return drdtime();
> +}
> +
> +#endif /* __KERNEL__ */
> +
> +#endif /*  _ASM_TIMEX_H */

"Currently only used on SMP for scheduling" isn't quite correct. It's
also used by random_get_entropy(). And anything else that uses
get_cycles() for, e.g., benchmarking, might use it too.

You wrote also, "we know that all SMP capable CPUs have cycle counters",
so if I gather from this statement that some !SMP CPUs don't have a
cycle counter, though some do. If that's a correct supposition, then
you may need to rewrite this file to be something like:

    static inline bool cpu_has_rdtime(void)
    {
        return IS_ENABLED(CONFIG_SMP) ? true : { ... some magic to determine on !SMP ... };
    }

    typedef unsigned long cycles_t;
    static inline cycles_t get_cycles(void)
    {
    	return cpu_has_rdtime() ? drdtime() : 0;
    }
    #define get_cycles get_cycles

    static inline unsigned long random_get_entropy(void)
    {
        return cpu_has_rdtime() ? drdtime() : random_get_entropy_fallback();
    }
    #define random_get_entropy random_get_entropy

Does that make sense? More importantly, is my presumption about !SMP
correct?

In any case, please do CC me on this patch for v+1.

Regards,
Jason