lkml.org 
[lkml]   [2020]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: [PATCH v3 7/7] clocksource/drivers/arm_arch_timer: validate arch_timer_rate
From
Date
Hi Ionela, Valentin

On 2/11/20 6:45 PM, Ionela Voinescu wrote:
> From: Valentin Schneider <valentin.schneider@arm.com>
>
> Using an arch timer with a frequency of less than 1MHz can result in an
> incorrect functionality of the system which assumes a reasonable rate.
>
> One example is the use of activity monitors for frequency invariance
> which uses the rate of the arch timer as the known rate of the constant
> cycle counter in computing its ratio compared to the maximum frequency
> of a CPU. For arch timer frequencies less than 1MHz this ratio could
> end up being 0 which is an invalid value for its use.
>
> Therefore, warn if the arch timer rate is below 1MHz which contravenes
> the recommended architecture interval of 1 to 50MHz.
>
> Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 9a5464c625b4..4faa930eabf8 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -885,6 +885,17 @@ static int arch_timer_starting_cpu(unsigned int cpu)
> return 0;
> }
>
> +static int validate_timer_rate(void)
> +{
> + if (!arch_timer_rate)
> + return -EINVAL;
> +
> + /* Arch timer frequency < 1MHz can cause trouble */
> + WARN_ON(arch_timer_rate < 1000000);

I don't see a big value of having a patch just to add one extra warning,
in a situation which we handle in our code with in 6/7 with:

+ if (!ratio) {
+ pr_err("System timer frequency too low.\n");
+ return -EINVAL;
+ }

Furthermore, the value '100000' here is because of our code and
calculation in there, so it does not belong to arch timer. Someone
might ask why it's not 200000 or a define in our header...
Or questions asking why do you warn when that arch timer and cpu is not
AMU capable...

> +
> + return 0;
> +}
> +
> /*
> * For historical reasons, when probing with DT we use whichever (non-zero)
> * rate was probed first, and don't verify that others match. If the first node
> @@ -900,7 +911,7 @@ static void arch_timer_of_configure_rate(u32 rate, struct device_node *np)
> arch_timer_rate = rate;
>
> /* Check the timer frequency. */
> - if (arch_timer_rate == 0)
> + if (validate_timer_rate())
> pr_warn("frequency not available\n");
> }
>
> @@ -1594,9 +1605,10 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *table)
> * CNTFRQ value. This *must* be correct.
> */
> arch_timer_rate = arch_timer_get_cntfrq();
> - if (!arch_timer_rate) {
> + ret = validate_timer_rate();
> + if (ret) {
> pr_err(FW_BUG "frequency not available.\n");
> - return -EINVAL;
> + return ret;
> }
>
> arch_timer_uses_ppi = arch_timer_select_ppi();
>

Lastly, this is arch timer.
To increase chances of getting merge soon, I would recommend to drop
the patch from this series.

Regards,
Lukasz

\
 
 \ /
  Last update: 2020-02-12 11:02    [W:0.195 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site