From: Yury Norov <yury.norov@gmail.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
"Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com>,
"Danilo Krummrich" <dakr@redhat.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
linux-pm@vger.kernel.org,
"Vincent Guittot" <vincent.guittot@linaro.org>,
"Stephen Boyd" <sboyd@kernel.org>, "Nishanth Menon" <nm@ti.com>,
rust-for-linux@vger.kernel.org,
"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>,
"Erik Schilling" <erik.schilling@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Joakim Bech" <joakim.bech@linaro.org>,
"Rob Herring" <robh@kernel.org>, "Burak Emir" <bqe@google.com>,
"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
"Russell King" <linux@armlinux.org.uk>,
linux-clk@vger.kernel.org,
"Michael Turquette" <mturquette@baylibre.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V9 08/17] cpufreq: Use enum for cpufreq flags that use BIT()
Date: Fri, 11 Apr 2025 12:07:40 -0400 [thread overview]
Message-ID: <Z_k-TFCkLWu9eiFt@yury> (raw)
In-Reply-To: <efbdd8212a90175c293313de961c34d13b9f4b43.1744366571.git.viresh.kumar@linaro.org>
On Fri, Apr 11, 2025 at 04:25:07PM +0530, Viresh Kumar wrote:
> The BIT() macro is too complex for Rust's bindgen to interpret as
The BIT() is as simple as '1 << nr'. How that it's so complex for that
tool to realize that '1 << 2' is the constant?
> integer constants. This results in many of the cpufreq macros being
> undefined in Rust auto-generated bindings. By replacing the "#define"
> macros with an "enum", we ensure that bindgen can properly evaluate
> these values, enabling their seamless use in Rust code.
>
> No intentional functional impact.
The code you're wiping is perfectly correct. And you clearly state
that one of your tools is broken. Please fix your tool or find any
other solution.
We don't touch correct code, sorry.
> Suggested-by: Alice Ryhl <aliceryhl@google.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> include/linux/cpufreq.h | 96 ++++++++++++++++++++++-------------------
> 1 file changed, 51 insertions(+), 45 deletions(-)
>
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 400fee6427a5..354ae35fe708 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -298,11 +298,12 @@ static inline void cpufreq_stats_record_transition(struct cpufreq_policy *policy
> * CPUFREQ DRIVER INTERFACE *
> *********************************************************************/
>
> -#define CPUFREQ_RELATION_L 0 /* lowest frequency at or above target */
> -#define CPUFREQ_RELATION_H 1 /* highest frequency below or at target */
> -#define CPUFREQ_RELATION_C 2 /* closest frequency to target */
> -/* relation flags */
> -#define CPUFREQ_RELATION_E BIT(2) /* Get if possible an efficient frequency */
> +enum {
> + CPUFREQ_RELATION_L = 0, /* lowest frequency at or above target */
> + CPUFREQ_RELATION_H = BIT(0), /* highest frequency below or at target */
> + CPUFREQ_RELATION_C = BIT(1), /* closest frequency to target */
> + CPUFREQ_RELATION_E = BIT(2), /* Get if possible an efficient frequency */
> +};
>
> #define CPUFREQ_RELATION_LE (CPUFREQ_RELATION_L | CPUFREQ_RELATION_E)
> #define CPUFREQ_RELATION_HE (CPUFREQ_RELATION_H | CPUFREQ_RELATION_E)
> @@ -424,52 +425,57 @@ struct cpufreq_driver {
>
> /* flags */
>
> -/*
> - * Set by drivers that need to update internal upper and lower boundaries along
> - * with the target frequency and so the core and governors should also invoke
> - * the diver if the target frequency does not change, but the policy min or max
> - * may have changed.
> - */
> -#define CPUFREQ_NEED_UPDATE_LIMITS BIT(0)
> +enum {
> + /*
> + * Set by drivers that need to update internal upper and lower
> + * boundaries along with the target frequency and so the core and
> + * governors should also invoke the diver if the target frequency does
> + * not change, but the policy min or max may have changed.
> + */
> + CPUFREQ_NEED_UPDATE_LIMITS = BIT(0),
>
> -/* loops_per_jiffy or other kernel "constants" aren't affected by frequency transitions */
> -#define CPUFREQ_CONST_LOOPS BIT(1)
> + /*
> + * loops_per_jiffy or other kernel "constants" aren't affected by
> + * frequency transitions.
> + */
> + CPUFREQ_CONST_LOOPS = BIT(1),
>
> -/*
> - * Set by drivers that want the core to automatically register the cpufreq
> - * driver as a thermal cooling device.
> - */
> -#define CPUFREQ_IS_COOLING_DEV BIT(2)
> + /*
> + * Set by drivers that want the core to automatically register the
> + * cpufreq driver as a thermal cooling device.
> + */
> + CPUFREQ_IS_COOLING_DEV = BIT(2),
>
> -/*
> - * This should be set by platforms having multiple clock-domains, i.e.
> - * supporting multiple policies. With this sysfs directories of governor would
> - * be created in cpu/cpu<num>/cpufreq/ directory and so they can use the same
> - * governor with different tunables for different clusters.
> - */
> -#define CPUFREQ_HAVE_GOVERNOR_PER_POLICY BIT(3)
> + /*
> + * This should be set by platforms having multiple clock-domains, i.e.
> + * supporting multiple policies. With this sysfs directories of governor
> + * would be created in cpu/cpu<num>/cpufreq/ directory and so they can
> + * use the same governor with different tunables for different clusters.
> + */
> + CPUFREQ_HAVE_GOVERNOR_PER_POLICY = BIT(3),
>
> -/*
> - * Driver will do POSTCHANGE notifications from outside of their ->target()
> - * routine and so must set cpufreq_driver->flags with this flag, so that core
> - * can handle them specially.
> - */
> -#define CPUFREQ_ASYNC_NOTIFICATION BIT(4)
> + /*
> + * Driver will do POSTCHANGE notifications from outside of their
> + * ->target() routine and so must set cpufreq_driver->flags with this
> + * flag, so that core can handle them specially.
> + */
> + CPUFREQ_ASYNC_NOTIFICATION = BIT(4),
>
> -/*
> - * Set by drivers which want cpufreq core to check if CPU is running at a
> - * frequency present in freq-table exposed by the driver. For these drivers if
> - * CPU is found running at an out of table freq, we will try to set it to a freq
> - * from the table. And if that fails, we will stop further boot process by
> - * issuing a BUG_ON().
> - */
> -#define CPUFREQ_NEED_INITIAL_FREQ_CHECK BIT(5)
> + /*
> + * Set by drivers which want cpufreq core to check if CPU is running at
> + * a frequency present in freq-table exposed by the driver. For these
> + * drivers if CPU is found running at an out of table freq, we will try
> + * to set it to a freq from the table. And if that fails, we will stop
> + * further boot process by issuing a BUG_ON().
> + */
> + CPUFREQ_NEED_INITIAL_FREQ_CHECK = BIT(5),
>
> -/*
> - * Set by drivers to disallow use of governors with "dynamic_switching" flag
> - * set.
> - */
> -#define CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING BIT(6)
> + /*
> + * Set by drivers to disallow use of governors with "dynamic_switching"
> + * flag set.
> + */
> + CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING = BIT(6),
> +};
>
> int cpufreq_register_driver(struct cpufreq_driver *driver_data);
> void cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
> --
> 2.31.1.272.g89b43f80a514
next prev parent reply other threads:[~2025-04-11 16:07 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-11 10:54 [PATCH V9 00/17] Rust abstractions for clk, cpumask, cpufreq, OPP Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 01/17] rust: cpumask: Use non-atomic helpers Viresh Kumar
2025-04-11 15:20 ` Yury Norov
2025-04-11 10:55 ` [PATCH V9 02/17] rust: cpumask: Add few more helpers Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 03/17] rust: cpumask: Add initial abstractions Viresh Kumar
2025-04-11 15:54 ` Yury Norov
2025-04-14 11:29 ` Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 04/17] MAINTAINERS: Add entry for Rust cpumask API Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 05/17] rust: clk: Add helpers for Rust code Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 06/17] rust: clk: Add initial abstractions Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 07/17] rust: macros: enable use of hyphens in module names Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 08/17] cpufreq: Use enum for cpufreq flags that use BIT() Viresh Kumar
2025-04-11 16:07 ` Yury Norov [this message]
2025-04-11 17:05 ` Miguel Ojeda
2025-04-11 10:55 ` [PATCH V9 09/17] rust: cpu: Add from_cpu() Viresh Kumar
2025-04-11 16:18 ` Yury Norov
2025-04-11 18:03 ` Danilo Krummrich
2025-04-11 10:55 ` [PATCH V9 10/17] rust: opp: Add initial abstractions for OPP framework Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 11/17] rust: opp: Add abstractions for the OPP table Viresh Kumar
2025-04-11 16:29 ` Yury Norov
2025-04-11 10:55 ` [PATCH V9 12/17] rust: opp: Add abstractions for the configuration options Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 13/17] rust: cpufreq: Add initial abstractions for cpufreq framework Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 14/17] rust: cpufreq: Extend abstractions for policy and driver ops Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 15/17] rust: cpufreq: Extend abstractions for driver registration Viresh Kumar
2025-04-11 11:58 ` Danilo Krummrich
2025-04-14 8:47 ` Viresh Kumar
2025-04-14 9:39 ` Danilo Krummrich
2025-04-14 10:52 ` Viresh Kumar
2025-04-14 11:51 ` Danilo Krummrich
2025-04-11 10:55 ` [PATCH V9 16/17] rust: opp: Extend OPP abstractions with cpufreq support Viresh Kumar
2025-04-11 10:55 ` [PATCH V9 17/17] cpufreq: Add Rust-based cpufreq-dt driver Viresh Kumar
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=Z_k-TFCkLWu9eiFt@yury \
--to=yury.norov@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=alex.bennee@linaro.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bqe@google.com \
--cc=dakr@kernel.org \
--cc=dakr@redhat.com \
--cc=erik.schilling@linaro.org \
--cc=gary@garyguo.net \
--cc=joakim.bech@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linux@rasmusvillemoes.dk \
--cc=manos.pitsidianakis@linaro.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mturquette@baylibre.com \
--cc=nm@ti.com \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=tmgross@umich.edu \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/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;
as well as URLs for NNTP newsgroup(s).