2022-04-29 12:31:09

by Sudeep Holla

[permalink] [raw]
Subject: [PATCH] firmware: arm_scmi: Set clock latency to U32_MAX if it is not supported

As per the spec, the clock_enable_delay is the worst case latency
incurred by the platform to enable the clock. The value of 0 indicates
that the platform doesn't support the same and must be considered as
maximum latency for practical purposes.

Currently the value of 0 is assigned as is and is propogated to the clock
framework which can assume that the clock can support atomic enable operation.

Fixes: 18f295b758b2 ("firmware: arm_scmi: Add support for clock_enable_latency")
Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_scmi/clock.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index 7a031afff389..2460979eabd2 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -6,6 +6,7 @@
*/

#include <linux/module.h>
+#include <linux/limits.h>
#include <linux/sort.h>

#include "protocols.h"
@@ -128,12 +129,13 @@ static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,

ret = ph->xops->do_xfer(ph, t);
if (!ret) {
+ u32 latency;
attributes = le32_to_cpu(attr->attributes);
strlcpy(clk->name, attr->name, SCMI_MAX_STR_SIZE);
/* Is optional field clock_enable_latency provided ? */
if (t->rx.len == sizeof(*attr))
- clk->enable_latency =
- le32_to_cpu(attr->clock_enable_latency);
+ latency = le32_to_cpu(attr->clock_enable_latency);
+ clk->enable_latency = latency ? : U32_MAX;
}

ph->xops->xfer_put(ph, t);
--
2.36.0


2022-05-03 11:50:56

by Sudeep Holla

[permalink] [raw]
Subject: Re: [PATCH] firmware: arm_scmi: Set clock latency to U32_MAX if it is not supported

On Thu, 28 Apr 2022 13:29:13 +0100, Sudeep Holla wrote:
> As per the spec, the clock_enable_delay is the worst case latency
> incurred by the platform to enable the clock. The value of 0 indicates
> that the platform doesn't support the same and must be considered as
> maximum latency for practical purposes.
>
> Currently the value of 0 is assigned as is and is propogated to the clock
> framework which can assume that the clock can support atomic enable operation.
>
> [...]


Applied to sudeep.holla/linux (for-next/scmi), thanks!

[1/1] firmware: arm_scmi: Set clock latency to U32_MAX if it is not supported
https://git.kernel.org/sudeep.holla/c/7ad6b6ccba

--
Regards,
Sudeep