Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1441214iob; Fri, 29 Apr 2022 05:31:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCcCSXMVmYO2BvsHZV5zHy11HTWrI+KzM03q29Q3BZ4fHYJl8TTSgYR7MhI/QVzSe4Lzie X-Received: by 2002:a17:902:da81:b0:15d:37b9:70df with SMTP id j1-20020a170902da8100b0015d37b970dfmr18052360plx.34.1651235469592; Fri, 29 Apr 2022 05:31:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651235469; cv=none; d=google.com; s=arc-20160816; b=bfyJup0kGzBb1EF8stvve0LUltXyo8Y9QA9C7jHF8R2IYBTrprByHeqncFkVSv6W9L G/Y3w93puxCUh6j4lM3U60mwr712Uctm7YpSKnojrliFQTUBjVvmo2HMnUtl5w0bpTTq 0cB/yyA9zJWWhYx5mF8JoDdEm1+gYocLlxNeoLKCGk4NrFD7ClM26AID3DgyGIhNPGx7 woFjpCJQwxAPob4fttKbkB2M2j6+yJiv0oRupv9zRwDMKG3CCNwhxC7pxjtq5+6h/2DY 9LwV2s/zWBPzm+hoJQfg3OmYtTqlCZyeT1uCTOB1ZnlTxTiW5c33pCVVGGaim1oPvMDU 2mNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=AW2rjwLaOhOnsTJ6aftYwZNPiBX971pxUhK25CWVjAQ=; b=s178TjUYemw0ppTsh80/RWMJFPFh75NKBIHzV6VN2zuo+8xjmTzcnbhhZkp6PMZXec FyhT4sTo1B2dMqEvTm0jyiVSWE3jNovPJLJ3Kqj5XcnDC+fILl/rFnavw+CWjPBlzTwP 7g28ySgWpkRy0FUQJ2hxJ4qsoAyRDcSHNkWuK85gzry2tqROjkyxsq3BFU8VsEEwXA0W cFRQGffr8YjXZ/JOS0uKQXsISwvvrUoDPXyUcbC3IVdCSH+t4VESxXAVRL7G5W/ecvKK BeiTniU29E/7FSKHHpMFz+0aHSkiq6goekw0LWy1AbFqWv3+0iqcRAAGtZH6vU0vgFhS 7AUA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o18-20020a17090ac71200b001cbc357005asi10074801pjt.174.2022.04.29.05.30.54; Fri, 29 Apr 2022 05:31:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346290AbiD1Mck (ORCPT + 99 others); Thu, 28 Apr 2022 08:32:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45358 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346236AbiD1Mch (ORCPT ); Thu, 28 Apr 2022 08:32:37 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E4C1BAF1EA for ; Thu, 28 Apr 2022 05:29:20 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A8A691474; Thu, 28 Apr 2022 05:29:20 -0700 (PDT) Received: from usa.arm.com (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id F341C3F73B; Thu, 28 Apr 2022 05:29:19 -0700 (PDT) From: Sudeep Holla To: linux-kernel@vger.kernel.org Cc: Sudeep Holla , linux-arm-kernel@lists.infradead.org, Cristian Marussi Subject: [PATCH] firmware: arm_scmi: Set clock latency to U32_MAX if it is not supported Date: Thu, 28 Apr 2022 13:29:13 +0100 Message-Id: <20220428122913.1654821-1-sudeep.holla@arm.com> X-Mailer: git-send-email 2.36.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- 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 +#include #include #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