Devicetree
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@kernel.org>
To: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Cc: Lukasz Luba <lukasz.luba@arm.com>,
	linux-arm-msm@vger.kernel.org,
	Sudeep Holla <sudeep.holla@kernel.org>,
	andersson@kernel.org, konradybcio@kernel.org,
	myungjoo.ham@samsung.com, kyungmin.park@samsung.com,
	cw00.choi@samsung.com, cristian.marussi@arm.com,
	dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, arm-scmi@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org,
	dmitry.baryshkov@oss.qualcomm.com, jonathanh@nvidia.com,
	thierry.reding@kernel.org, digetx@gmail.com, conor+dt@kernel.org,
	krzk+dt@kernel.org, robh@kernel.org
Subject: Re: [RFC V6 0/8] arm_scmi: vendors: Qualcomm Generic Vendor Extensions
Date: Thu, 14 May 2026 13:40:40 +0100	[thread overview]
Message-ID: <20260514-towering-heavenly-earwig-b18feb@sudeepholla> (raw)
In-Reply-To: <5494a379-1e49-4551-a5f0-50d0bd7cd7d0@oss.qualcomm.com>

On Thu, May 14, 2026 at 05:11:41PM +0530, Sibi Sankar wrote:
> 
> On 5/13/2026 10:30 PM, Lukasz Luba wrote:
> > 
> > 

[...]

> 
> > Based on this description I have a few questions:
> > 1. Why we don't use SCMI notifications for this purpose?
> 
> 
> This is an attempt to retrofit firmware, that is already out in the wild
> running on X1E laptops and Glymur which continues to use the same firmware, into
> generic linux frameworks, so that it provides some useful information to
> user rather than it being a complete black box.

We cannot accept changes that rely on firmware interfaces that are not well
defined. This is not a comment on any specific interface, but if an interface
is not specified with the same level of rigor as a standard specification, it
should not be expected to receive mainline support.

> We already have a ton of firmware changes suggested by Sudeep/Cristian that
> will be taken into account for the next generation of SoCs, will make sure
> this is accounted for as well :)

It is helpful to know this but also unfortunate as we have only just begun
reviewing the interface and refining its shape. Please do not rely solely on
the review completed so far, as the interface may still evolve. Until it is
merged, it should not be considered accepted. This is why I am insisting that
the interface document be reviewed and accepted before any driver changes are
made.

-- 
Regards,
Sudeep

      reply	other threads:[~2026-05-14 12:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-07  6:22 [RFC V6 0/8] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Sibi Sankar
2026-05-07  6:22 ` [RFC V6 1/8] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation Sibi Sankar
2026-05-07 12:36   ` Sudeep Holla
2026-05-07  6:22 ` [RFC V6 2/8] firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions Sibi Sankar
2026-05-07  6:22 ` [RFC V6 3/8] PM / devfreq: Add new target_freq attribute flag for governors Sibi Sankar
2026-05-07  6:22 ` [RFC V6 4/8] PM / devfreq: Add new track_remote " Sibi Sankar
2026-05-07  6:22 ` [RFC V6 5/8] PM / devfreq: Add a governor for tracking remote device frequencies Sibi Sankar
2026-05-07  6:22 ` [RFC V6 6/8] PM / devfreq: Introduce the QCOM SCMI Memlat devfreq device Sibi Sankar
2026-05-07  6:22 ` [RFC V6 7/8] arm64: dts: qcom: glymur: Enable LLCC/DDR/DDR_QOS dvfs Sibi Sankar
2026-05-07  6:22 ` [RFC V6 8/8] arm64: dts: qcom: hamoa: " Sibi Sankar
2026-05-07  9:10 ` [RFC V6 0/8] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Dmitry Baryshkov
2026-05-07  9:58   ` Sibi Sankar
2026-05-07 11:10     ` Dmitry Baryshkov
2026-05-13 17:00 ` Lukasz Luba
2026-05-14 11:41   ` Sibi Sankar
2026-05-14 12:40     ` Sudeep Holla [this message]

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=20260514-towering-heavenly-earwig-b18feb@sudeepholla \
    --to=sudeep.holla@kernel.org \
    --cc=andersson@kernel.org \
    --cc=arm-scmi@vger.kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=cristian.marussi@arm.com \
    --cc=cw00.choi@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=digetx@gmail.com \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jonathanh@nvidia.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=robh@kernel.org \
    --cc=sibi.sankar@oss.qualcomm.com \
    --cc=thierry.reding@kernel.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