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: 18f295b758b2 ("firmware: arm_scmi: Add support for clock_enable_latency")
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
*/
#include <linux/module.h>
+#include <linux/limits.h>
#include <linux/sort.h>
#include "protocols.h"
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);