From: Sudeep Holla <sudeep.holla@arm.com>
To: Mike Tipton <quic_mdtipton@quicinc.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
<arm-scmi@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Peng Fan <peng.fan@oss.nxp.com>, Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH v3] cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs
Date: Tue, 6 May 2025 11:12:07 +0100 [thread overview]
Message-ID: <20250506-stirring-competent-ladybug-9cadb5@sudeepholla> (raw)
In-Reply-To: <aBllHt7A2nP/9x3N@hu-mdtipton-lv.qualcomm.com>
On Mon, May 05, 2025 at 06:25:50PM -0700, Mike Tipton wrote:
> On Mon, Apr 28, 2025 at 07:47:28AM -0700, Mike Tipton wrote:
> > Currently, all SCMI devices with performance domains attempt to register
> > a cpufreq driver, even if their performance domains aren't used to
> > control the CPUs. The cpufreq framework only supports registering a
> > single driver, so only the first device will succeed. And if that device
> > isn't used for the CPUs, then cpufreq will scale the wrong domains.
> >
> > To avoid this, return early from scmi_cpufreq_probe() if the probing
> > SCMI device isn't referenced by the CPU device phandles.
> >
> > This keeps the existing assumption that all CPUs are controlled by a
> > single SCMI device.
> >
> > Signed-off-by: Mike Tipton <quic_mdtipton@quicinc.com>
> > Reviewed-by: Peng Fan <peng.fan@nxp.com>
> > ---
>
> Hi Sudeep / Viresh,
>
> Any thoughts on this?
>
I have actually queued and forgot to respond. Though I realise the change
is not dependent on any other changes now.
Viresh, hope you are OK with me taking this change or do you prefer to take
it via your tree ? I am fine with that as well.
--
Regards,
Sudeep
next prev parent reply other threads:[~2025-05-06 10:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-28 14:47 [PATCH v3] cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs Mike Tipton
2025-05-06 1:25 ` Mike Tipton
2025-05-06 10:12 ` Sudeep Holla [this message]
2025-05-07 11:59 ` Cristian Marussi
2025-05-07 13:12 ` Sudeep Holla
2025-05-15 3:47 ` Mike Tipton
2025-05-07 13:18 ` Dan Carpenter
2025-05-07 13:27 ` 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=20250506-stirring-competent-ladybug-9cadb5@sudeepholla \
--to=sudeep.holla@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=peng.fan@oss.nxp.com \
--cc=quic_mdtipton@quicinc.com \
--cc=rafael@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox