From: Cristian Marussi <cristian.marussi@arm.com>
To: Dhruva Gole <d-gole@ti.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org,
linux-pm@vger.kernel.org, sudeep.holla@arm.com,
james.quinlan@broadcom.com, f.fainelli@gmail.com,
vincent.guittot@linaro.org, quic_sibis@quicinc.com,
dan.carpenter@linaro.org, johan+linaro@kernel.org,
rafael@kernel.org, viresh.kumar@linaro.org,
quic_mdtipton@quicinc.com,
Florian Fainelli <florian.fainelli@broadcom.com>
Subject: Re: [PATCH 2/2] [NOT_FOR_UPSTREAM] cpufreq: scmi: Add quirk to disable checks in scmi_dev_used_by_cpus()
Date: Mon, 18 Aug 2025 14:21:14 +0100 [thread overview]
Message-ID: <aKMoyp5xw9xSj2v1@pluto> (raw)
In-Reply-To: <20250818062044.zawqkalphvxjwt2w@lcpd911>
On Mon, Aug 18, 2025 at 11:50:44AM +0530, Dhruva Gole wrote:
> On Aug 15, 2025 at 11:27:36 +0100, Cristian Marussi wrote:
> > From: Florian Fainelli <florian.fainelli@broadcom.com>
> >
> > Broadcom STB platforms were early adopters of the SCMI framework and as
> > a result, not all deployed systems have a Device Tree entry where SCMI
> > protocol 0x13 (PERFORMANCE) is declared as a clock provider, nor are the
> > CPU Device Tree node(s) referencing protocol 0x13 as their clock
> > provider.
> >
> > Leverage the quirks framework recently introduce to match on the
> > Broadcom SCMI vendor and in that case, disable the Device Tree
> > properties checks being done by scmi_dev_used_by_cpus().
> >
> > Suggested-by: Cristian Marussi <cristian.marussi@arm.com>
> > Fixes: 6c9bb8692272 ("cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs")
> > Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> > [Cristian: Moved quirk directly into scmi_dev_used_by_cpus]
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> >
> > ----
> > @Florian: I reworked this minimally to avoid the global as I was mentioning.
> > No change around the version match either...so the NOT_FOR_UPSTREAM tag.
> > (also the if (true) i smaybe a bit idiotic...)
> > Please check if it is fine and modify as you see fit.
> > ---
> > drivers/cpufreq/scmi-cpufreq.c | 9 +++++++++
> > drivers/firmware/arm_scmi/quirks.c | 2 ++
> > include/linux/scmi_quirks.h | 1 +
> > 3 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> > index ef078426bfd5..9b7cbc4e87d9 100644
> > --- a/drivers/cpufreq/scmi-cpufreq.c
> > +++ b/drivers/cpufreq/scmi-cpufreq.c
> > @@ -19,6 +19,7 @@
> > #include <linux/pm_qos.h>
> > #include <linux/slab.h>
> > #include <linux/scmi_protocol.h>
> > +#include <linux/scmi_quirks.h>
> > #include <linux/types.h>
> > #include <linux/units.h>
> >
> > @@ -393,6 +394,12 @@ static struct cpufreq_driver scmi_cpufreq_driver = {
> > .set_boost = cpufreq_boost_set_sw,
> > };
> >
> > +#define QUIRK_SCMI_CPUFREQ_CHECK_DT_PROPS \
> > + ({ \
> > + if (true) \
> > + return true; \
> > + })
> > +
>
> Probably another checkpatch warning to fix:
> 8<--------------------------------------------------------------------
> WARNING: Macros with flow control statements should be avoided
> #50: FILE: drivers/cpufreq/scmi-cpufreq.c:397:
Yes I saw this too....but seemed harmless and anyway Quirks are really
very peculiar piece of code...
Thanks
Cristian
next prev parent reply other threads:[~2025-08-18 13:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 10:27 [PATCH 1/2] firmware: arm_scmi: Rework quirks framework header Cristian Marussi
2025-08-15 10:27 ` [PATCH 2/2] [NOT_FOR_UPSTREAM] cpufreq: scmi: Add quirk to disable checks in scmi_dev_used_by_cpus() Cristian Marussi
2025-08-18 6:20 ` Dhruva Gole
2025-08-18 13:21 ` Cristian Marussi [this message]
2025-08-18 5:35 ` [PATCH 1/2] firmware: arm_scmi: Rework quirks framework header Dhruva Gole
2025-08-18 13:19 ` Cristian Marussi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aKMoyp5xw9xSj2v1@pluto \
--to=cristian.marussi@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=d-gole@ti.com \
--cc=dan.carpenter@linaro.org \
--cc=f.fainelli@gmail.com \
--cc=florian.fainelli@broadcom.com \
--cc=james.quinlan@broadcom.com \
--cc=johan+linaro@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=quic_mdtipton@quicinc.com \
--cc=quic_sibis@quicinc.com \
--cc=rafael@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.