From: Brian Masney <bmasney@redhat.com>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org,
linux-clk@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
sudeep.holla@arm.com, philip.radford@arm.com,
james.quinlan@broadcom.com, f.fainelli@gmail.com,
vincent.guittot@linaro.org, etienne.carriere@foss.st.com,
peng.fan@oss.nxp.com, michal.simek@amd.com,
geert+renesas@glider.be, kuninori.morimoto.gx@renesas.com,
marek.vasut+renesas@gmail.com,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH v3 03/15] clk: scmi: Use new determine_rate clock operation
Date: Tue, 28 Apr 2026 16:33:38 -0400 [thread overview]
Message-ID: <afEZotnIZYXEtMiC@redhat.com> (raw)
In-Reply-To: <20260428201522.903875-4-cristian.marussi@arm.com>
Hi Cristian,
On Tue, Apr 28, 2026 at 09:15:10PM +0100, Cristian Marussi wrote:
> Use the Clock protocol layer determine_rate logic to calculate the closest
> rate that can be supported by a specific clock.
>
> No functional change.
>
> Cc: Brian Masney <bmasney@redhat.com>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> @brian: I'd modify further this clk-scmi driver, with a patch on top of
> this series, to properly use your new CLK_ROUNDING_NOOP flag once your
> series AND another (already reviewed) series on clk-scmi from Peng are in.
I don't know if Stephen is going to pick up my CLK_ROUNDING_NOOP series.
We talked about it in person at LPC in Tokyo, and he was the one that
suggested the flag rather than a new shared noop function. However he
didn't pick it up last development cycle.
I would recommend NOT basing on that series of mine to reduce
dependencies, and so that your stuff doesn't get held up by series.
Brian
next prev parent reply other threads:[~2026-04-28 20:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 20:15 [PATCH v3 00/15] SCMI Clock rates discovery rework Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 01/15] clk: scmi: Fix clock rate rounding Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 02/15] firmware: arm_scmi: Add clock determine_rate operation Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 03/15] clk: scmi: Use new determine_rate clock operation Cristian Marussi
2026-04-28 20:33 ` Brian Masney [this message]
2026-04-28 22:20 ` Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 04/15] firmware: arm_scmi: Simplify clock rates exposed interface Cristian Marussi
2026-05-05 12:17 ` Geert Uytterhoeven
2026-05-05 14:36 ` Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 05/15] clk: scmi: Use new simplified per-clock rate properties Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 06/15] firmware: arm_scmi: Drop unused clock rate interfaces Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 07/15] firmware: arm_scmi: Make clock rates allocation dynamic Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 08/15] firmware: arm_scmi: Harden clock parents discovery Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 09/15] firmware: arm_scmi: Refactor iterators internal allocation Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 10/15] firmware: arm_scmi: Add bound iterators support Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 11/15] firmware: arm_scmi: Fix bound iterators returning too many items Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 12/15] firmware: arm_scmi: Use proper iter_response_bound_cleanup() name Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 13/15] firmware: arm_scmi: Use bound iterators to minimize discovered rates Cristian Marussi
2026-05-05 9:59 ` Geert Uytterhoeven
2026-05-05 11:57 ` Geert Uytterhoeven
2026-04-28 20:15 ` [PATCH v3 14/15] firmware: arm_scmi: Fix OOB in scmi_clock_describe_rates_get_lazy() Cristian Marussi
2026-04-28 20:15 ` [PATCH v3 15/15] firmware: arm_scmi: Introduce all_rates_get clock operation Cristian Marussi
2026-04-29 15:39 ` [PATCH v3 00/15] SCMI Clock rates discovery rework Florian Fainelli
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=afEZotnIZYXEtMiC@redhat.com \
--to=bmasney@redhat.com \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=etienne.carriere@foss.st.com \
--cc=f.fainelli@gmail.com \
--cc=geert+renesas@glider.be \
--cc=james.quinlan@broadcom.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=marek.vasut+renesas@gmail.com \
--cc=michal.simek@amd.com \
--cc=mturquette@baylibre.com \
--cc=peng.fan@oss.nxp.com \
--cc=philip.radford@arm.com \
--cc=sboyd@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.