Commit 7ad6b6cc authored by Sudeep Holla's avatar Sudeep Holla
Browse files

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.

Link: https://lore.kernel.org/r/20220428122913.1654821-1-sudeep.holla@arm.com


Fixes: 18f295b7 ("firmware: arm_scmi: Add support for clock_enable_latency")
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
parent b260fcca

drivers/firmware/arm_scmi/clock.c

+4 −2
Original line number Diff line number Diff line
@@ -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 = 0;

		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);