Message ID | 20231130204343.503076-1-sudeep.holla@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp673043vqy; Thu, 30 Nov 2023 12:44:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IFtcN7T+v4EBT0C94pHp8hu4QDlwCEKYfmtIxVA8G6iEP+HKF7micZpQvUH5rWxRcaWWCjZ X-Received: by 2002:a05:6a20:1455:b0:18c:a8fe:42f3 with SMTP id a21-20020a056a20145500b0018ca8fe42f3mr15108870pzi.19.1701377061111; Thu, 30 Nov 2023 12:44:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701377061; cv=none; d=google.com; s=arc-20160816; b=T/TDS8WziBRFGSjPMSXZ9ipRsqLP0f2Kip9dE7nZegWiVb+eMG/hjN2HNZBM2J2K0l R6Pqfar592GxRFevzMitLoDe+ZcO5C1wAFgxVFDN9KzH819G6UBJxiaPErbK90ETP7ax 64W5HoAYtMc885AHTtp4XdOpRkV76WHTOYrRmYl/Mz6UB676GxztC8t0SWhxBYdTKXw2 mG/kjQhFP/Svrn8y1LlTs6rkjuoekgnz4VhK2KGnoOjNEl/jg+RY9D7kMpTQ2VLZcyHI S3bHsYMHZs1bFknC3DIMASUlQ4qnzZoGa1OqfaTGFwAf6xBq9GgcslQwvRsoh7MoIb6B CODw== 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=/0jU5xqycc0INc7xfvu25TUCTmwcIVLu+lTI0MHpfJc=; fh=g3kSv4WvKlMaeFENGH9vsQAEMHCdLvlnRC6We8RThxY=; b=Xc7gnOL4JlFBhKc+Mc4yvHUGkfQygifdxiEvyLGFhPV2BJY9gJnmp9Rop7n6gRLTeE H/JTFZO1u6gmbdj6rA6SmzkVAgyB+gHRpqghrVA8ab4g+37vEzY/thKOVlgGAZ6I1QVt rFFRRc3xCjrEa/7IKcDfA0ArszY6GHMmLLbxZLQ2P293cu3yRD0f52Qz/K2HewsfaBVQ +ojSzE6jUbuH0luVqTCXUtusReq42dJtjiZFMV9H23CtAJHqyh5bORMGBBusqKL0rRgB cyy7IV2pxaveNh6g4Y9OMYquJWcfepB7ztJ9MD6BtjFG5BnWYa22dF9An9xp1YKYwWhE WDfg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id h18-20020a056a00231200b0069347c30c78si2032509pfh.230.2023.11.30.12.44.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Nov 2023 12:44:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id C4E21801C627; Thu, 30 Nov 2023 12:44:16 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235287AbjK3UoD (ORCPT <rfc822;ruipengqi7@gmail.com> + 99 others); Thu, 30 Nov 2023 15:44:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376770AbjK3Un7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 30 Nov 2023 15:43:59 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 15D711731; Thu, 30 Nov 2023 12:43:57 -0800 (PST) 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 5ED9F1042; Thu, 30 Nov 2023 12:44:43 -0800 (PST) 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 617BF3F73F; Thu, 30 Nov 2023 12:43:55 -0800 (PST) From: Sudeep Holla <sudeep.holla@arm.com> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Sudeep Holla <sudeep.holla@arm.com>, quic_mdtipton@quicinc.com, quic_asartor@quicinc.com, quic_lingutla@quicinc.com, Sibi Sankar <quic_sibis@quicinc.com>, linux-arm-msm@vger.kernel.org, Cristian Marussi <cristian.marussi@arm.com> Subject: [PATCH 1/2] firmware: arm_scmi: Fix frequency truncation by promoting multiplier to u64 Date: Thu, 30 Nov 2023 20:43:42 +0000 Message-ID: <20231130204343.503076-1-sudeep.holla@arm.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Thu, 30 Nov 2023 12:44:17 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784023153343900619 X-GMAIL-MSGID: 1784023153343900619 |
Series |
[1/2] firmware: arm_scmi: Fix frequency truncation by promoting multiplier to u64
|
|
Commit Message
Sudeep Holla
Nov. 30, 2023, 8:43 p.m. UTC
Fix the frequency truncation for all values equal to or greater 4GHz by
updating the multiplier 'mult_factor' to u64 type. It is also possible
that the multiplier itself can be greater than or equal to 2^32. So we need
to also fix the equation computing the value of the multiplier.
Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol")
Reported-by: Sibi Sankar <quic_sibis@quicinc.com>
Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/
Cc: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_scmi/perf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.43.0
Comments
On Thu, Nov 30, 2023 at 08:43:42PM +0000, Sudeep Holla wrote: > Fix the frequency truncation for all values equal to or greater 4GHz by > updating the multiplier 'mult_factor' to u64 type. It is also possible > that the multiplier itself can be greater than or equal to 2^32. So we need > to also fix the equation computing the value of the multiplier. > > Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol") > Reported-by: Sibi Sankar <quic_sibis@quicinc.com> > Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/ > Cc: Cristian Marussi <cristian.marussi@arm.com> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > drivers/firmware/arm_scmi/perf.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c > index 81dd5c5e5533..8ce449922e55 100644 > --- a/drivers/firmware/arm_scmi/perf.c > +++ b/drivers/firmware/arm_scmi/perf.c > @@ -152,7 +152,7 @@ struct perf_dom_info { > u32 opp_count; > u32 sustained_freq_khz; > u32 sustained_perf_level; > - u32 mult_factor; > + u64 mult_factor; I have now changed this to unsigned long instead of u64 to fix the 32-bit build failure[1].
On Fri, Dec 01, 2023 at 02:39:35PM +0000, Sudeep Holla wrote: > On Thu, Nov 30, 2023 at 08:43:42PM +0000, Sudeep Holla wrote: > > Fix the frequency truncation for all values equal to or greater 4GHz by > > updating the multiplier 'mult_factor' to u64 type. It is also possible > > that the multiplier itself can be greater than or equal to 2^32. So we need > > to also fix the equation computing the value of the multiplier. > > > > Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol") > > Reported-by: Sibi Sankar <quic_sibis@quicinc.com> > > Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/ > > Cc: Cristian Marussi <cristian.marussi@arm.com> > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > drivers/firmware/arm_scmi/perf.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c > > index 81dd5c5e5533..8ce449922e55 100644 > > --- a/drivers/firmware/arm_scmi/perf.c > > +++ b/drivers/firmware/arm_scmi/perf.c > > @@ -152,7 +152,7 @@ struct perf_dom_info { > > u32 opp_count; > > u32 sustained_freq_khz; > > u32 sustained_perf_level; > > - u32 mult_factor; > > + u64 mult_factor; > > I have now changed this to unsigned long instead of u64 to fix the 32-bit > build failure[1]. Right, I was caught a few times too by this kind of failures on v7 :D ... but this 32bit issue makes me wonder what to do in such a case... ...I mean, on 32bit if the calculated freq oveflows, there is just nothing we can do on v7 without overcomplicating the code...but I suppose it is unplausible to have such high freq on a v7... as a palliative I can only think of some sort of overflow check (only on v7) that could trigger a warning ... but it is hardly worth the effort probably.. Thanks, Cristian
On Fri, Dec 01, 2023 at 04:17:56PM +0000, Cristian Marussi wrote: > On Fri, Dec 01, 2023 at 02:39:35PM +0000, Sudeep Holla wrote: > > On Thu, Nov 30, 2023 at 08:43:42PM +0000, Sudeep Holla wrote: > > > Fix the frequency truncation for all values equal to or greater 4GHz by > > > updating the multiplier 'mult_factor' to u64 type. It is also possible > > > that the multiplier itself can be greater than or equal to 2^32. So we need > > > to also fix the equation computing the value of the multiplier. > > > > > > Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol") > > > Reported-by: Sibi Sankar <quic_sibis@quicinc.com> > > > Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/ > > > Cc: Cristian Marussi <cristian.marussi@arm.com> > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > --- > > > drivers/firmware/arm_scmi/perf.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c > > > index 81dd5c5e5533..8ce449922e55 100644 > > > --- a/drivers/firmware/arm_scmi/perf.c > > > +++ b/drivers/firmware/arm_scmi/perf.c > > > @@ -152,7 +152,7 @@ struct perf_dom_info { > > > u32 opp_count; > > > u32 sustained_freq_khz; > > > u32 sustained_perf_level; > > > - u32 mult_factor; > > > + u64 mult_factor; > > > > I have now changed this to unsigned long instead of u64 to fix the 32-bit > > build failure[1]. > > Right, I was caught a few times too by this kind of failures on v7 :D > 😄 > ... but this 32bit issue makes me wonder what to do in such a case... > Same here, but the frequency calculations are also unsigned long in higher layers, so I don't see any point in making it u64(also 32-bit doesn't support 32bit value to be divided by a 64bit value which adds unnecessary complications here). > ...I mean, on 32bit if the calculated freq oveflows, there is just > nothing we can do on v7 without overcomplicating the code...but I suppose > it is unplausible to have such high freq on a v7... Yes this is exactly the argument I made myself and got convinced to keep it unsigned long(KISS approach) unless we need it on v7. > as a palliative I can only think of some sort of overflow check (only on v7) > that could trigger a warning ... but it is hardly worth the effort > probably.. > Not sure myself. -- Regards, Sudeep
On Thu, 30 Nov 2023 20:43:42 +0000, Sudeep Holla wrote: > Fix the frequency truncation for all values equal to or greater 4GHz by > updating the multiplier 'mult_factor' to u64 type. It is also possible > that the multiplier itself can be greater than or equal to 2^32. So we need > to also fix the equation computing the value of the multiplier. > Applied to sudeep.holla/linux (for-next/scmi/fixes), thanks! [1/2] firmware: arm_scmi: Fix frequency truncation by promoting multiplier to u64 (Applied changing u64 to unsigned long to fix armv7 build) https://git.kernel.org/sudeep.holla/c/8e3c98d9187e [2/2] firmware: arm_scmi: Fix possible frequency truncation when using level indexing mode https://git.kernel.org/sudeep.holla/c/77f5032e94f2 -- Regards, Sudeep
diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c index 81dd5c5e5533..8ce449922e55 100644 --- a/drivers/firmware/arm_scmi/perf.c +++ b/drivers/firmware/arm_scmi/perf.c @@ -152,7 +152,7 @@ struct perf_dom_info { u32 opp_count; u32 sustained_freq_khz; u32 sustained_perf_level; - u32 mult_factor; + u64 mult_factor; struct scmi_perf_domain_info info; struct scmi_opp opp[MAX_OPPS]; struct scmi_fc_info *fc_info; @@ -273,8 +273,8 @@ scmi_perf_domain_attributes_get(const struct scmi_protocol_handle *ph, dom_info->mult_factor = 1000; else dom_info->mult_factor = - (dom_info->sustained_freq_khz * 1000) / - dom_info->sustained_perf_level; + (dom_info->sustained_freq_khz * 1000UL) + / dom_info->sustained_perf_level; strscpy(dom_info->info.name, attr->name, SCMI_SHORT_NAME_MAX_SIZE); }