linux-kernel - Re: [PATCH v2 2/2] firmware: arm_scmi: round rate bisecting in discrete rates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z1bKlOeHJFHpe9ZU@bogus>
Date: Mon, 9 Dec 2024 10:46:44 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Etienne Carriere <etienne.carriere@...s.st.com>
Cc: <linux-kernel@...r.kernel.org>, Sudeep Holla <sudeep.holla@....com>,
	Cristian Marussi <cristian.marussi@....com>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>, <arm-scmi@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-clk@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] firmware: arm_scmi: round rate bisecting in
 discrete rates

On Tue, Dec 03, 2024 at 06:39:08PM +0100, Etienne Carriere wrote:
> Implement clock round_rate operation for SCMI clocks that describe a
> discrete rates list. Bisect into the supported rates when using SCMI
> message CLOCK_DESCRIBE_RATES to optimize SCMI communication transfers.

Let me stop here and try to understand the requirement here. So you do
communicate with the firmware to arrive at this round_rate ? Does the
list of discreet clock rates changes at the run-time that enables the
need for it. Or will the initial list just include max and min ?

> Parse the rate list array when the target rate fit in the bounds
> of the command response for simplicity.
>

I don't understand what you mean by this.

> If so some reason the sequence fails or if the SCMI driver has no
> round_rate SCMI clock handler, then fallback to the legacy strategy that
> returned the target rate value.
>

Hmm, so we perform some extra dance but we are okay to fallback to default.
I am more confused.

> Operation handle scmi_clk_determine_rate() is change to get the effective
> supported rounded rate when there is no clock re-parenting operation
> supported. Otherwise, preserve the implementation that assumed any
> clock rate could be obtained.
>

OK, no I think I am getting some idea. Is this case where the parent has
changed and the describe rates can give a different result at run-time.

I need to re-read the part of the spec, but we may need some clarity so
that this implementation is not vendor specific. I am yet to understand this
fully. I just need to make sure spec covers this aspect and anything we
add here is generic solution.

I would like to avoid this extra query if not required which you seem to
have made an attempt but I just want to be thorough and make sure that's
what we need w.r.t the specification.

-- 
Regards,
Sudeep