From: Will Deacon <will@kernel.org>
To: Yunhui Cui <cuiyunhui@bytedance.com>
Cc: akpm@linux-foundation.org, alex@ghiti.fr, anup@brainfault.org,
aou@eecs.berkeley.edu, atish.patra@linux.dev,
catalin.marinas@arm.com, dianders@chromium.org,
johannes@sipsolutions.net, lihuafei1@huawei.com,
mark.rutland@arm.com, masahiroy@kernel.org, maz@kernel.org,
mingo@kernel.org, nicolas.schier@linux.dev, palmer@dabbelt.com,
paul.walmsley@sifive.com, suzuki.poulose@arm.com,
thorsten.blum@linux.dev, wangjinchao600@gmail.com,
yangyicong@hisilicon.com, zhanjie9@hisilicon.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH v4 1/2] watchdog: move arm64 watchdog_hld into common code
Date: Mon, 3 Nov 2025 13:44:16 +0000 [thread overview]
Message-ID: <aQixsIQXTjYyhRVj@willie-the-truck> (raw)
In-Reply-To: <20251014031425.93284-2-cuiyunhui@bytedance.com>
On Tue, Oct 14, 2025 at 11:14:24AM +0800, Yunhui Cui wrote:
> @@ -306,3 +307,85 @@ void __init hardlockup_config_perf_event(const char *str)
> wd_hw_attr.type = PERF_TYPE_RAW;
> wd_hw_attr.config = config;
> }
> +
> +#ifdef CONFIG_WATCHDOG_PERF_ADJUST_PERIOD
> +/*
> + * Safe maximum CPU frequency in case a particular platform doesn't implement
> + * cpufreq driver. Although, architecture doesn't put any restrictions on
> + * maximum frequency but 5 GHz seems to be safe maximum given the available
> + * CPUs in the market which are clocked much less than 5 GHz. On the other
> + * hand, we can't make it much higher as it would lead to a large hard-lockup
> + * detection timeout on parts which are running slower (eg. 1GHz on
> + * Developerbox) and doesn't possess a cpufreq driver.
> + */
> +#define SAFE_MAX_CPU_FREQ 5000000000UL // 5 GHz
> +__weak u64 hw_nmi_get_sample_period(int watchdog_thresh)
> +{
> + unsigned int cpu = smp_processor_id();
> + unsigned long max_cpu_freq;
> +
> + max_cpu_freq = cpufreq_get_hw_max_freq(cpu) * 1000UL;
> + if (!max_cpu_freq)
> + max_cpu_freq = SAFE_MAX_CPU_FREQ;
> +
> + return (u64)max_cpu_freq * watchdog_thresh;
> +}
Why does this function become __weak? Neither arm64 nor riscv override
it afaict.
Will
next prev parent reply other threads:[~2025-11-03 13:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-14 3:14 [PATCH v4 0/2] Add HARDLOCKUP_DETECTOR_PERF support for RISC-V Yunhui Cui
2025-10-14 3:14 ` [PATCH v4 1/2] watchdog: move arm64 watchdog_hld into common code Yunhui Cui
2025-11-03 13:44 ` Will Deacon [this message]
2025-11-07 2:42 ` [External] " yunhui cui
2025-11-07 13:10 ` Will Deacon
2025-11-11 7:15 ` yunhui cui
2025-10-14 3:14 ` [PATCH v4 2/2] riscv: add HARDLOCKUP_DETECTOR_PERF support Yunhui Cui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aQixsIQXTjYyhRVj@willie-the-truck \
--to=will@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@linux.dev \
--cc=catalin.marinas@arm.com \
--cc=cuiyunhui@bytedance.com \
--cc=dianders@chromium.org \
--cc=johannes@sipsolutions.net \
--cc=lihuafei1@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=maz@kernel.org \
--cc=mingo@kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=suzuki.poulose@arm.com \
--cc=thorsten.blum@linux.dev \
--cc=wangjinchao600@gmail.com \
--cc=yangyicong@hisilicon.com \
--cc=zhanjie9@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox