Re: [PATCH RFC 01/10] firmware: arm_scmi: Add SCMI QCOM Generic Extension Protocol documentation

[Sudeep Holla <sudeep.holla@kernel.org>]

On Tue, Aug 04, 2026 at 02:07:28AM +0530, Sibi Sankar wrote:
> 
> On 7/24/2026 2:43 PM, Sudeep Holla wrote:
> > On Fri, Jul 24, 2026 at 12:48:06PM +0530, Pragnesh Papaniya wrote:
> > > Add System Control Management Interface (SCMI) Qualcomm Generic Extension
> > > Protocol documentation. It consists of a small set of generic SET/GET/
> > > START/STOP commands, which is used to turn on/off and configure Qualcomm
> > > SoC specific algorithms that run on the SCP.
> > > 
> > > It currently only supports MEMLAT (memory latency governor) algorithm.
> > > The immutable pairing of the MEMLAT algorithm string with the supported
> > > param_ids associated with it are documented here.
> > > 
> > > Co-developed-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> > > Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> > > Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com>
> > > ---
> > >   .../arm_scmi/vendors/qcom/qcom_generic.rst         | 954 +++++++++++++++++++++
> > >   1 file changed, 954 insertions(+)
> > > 
> > > diff --git a/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst
> > > new file mode 100644
> > > index 000000000000..42e327d53841
> > > --- /dev/null
> > > +++ b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst
> > > @@ -0,0 +1,954 @@
> > > +.. SPDX-License-Identifier: GPL-2.0
> > > +.. include:: <isonum.txt>
> > > +
> > > +==================================================================================
> > > +System Control and Management Interface (SCMI) Qualcomm Generic Extension Protocol
> > > +==================================================================================
> > > +
> > > +:Copyright: |copy| Qualcomm Technologies, Inc. and/or its subsidiaries.
> > > +
> > > +:Authors:
> > > +   - Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> > > +   - Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com>
> > > +
> > > +System Control and Management Interface Qualcomm Generic Extension Vendor Protocol
> > > +==================================================================================
> > > +
> > > +System Control Management Interface (SCMI) Qualcomm Generic Extension Protocol
> > > +consists of a small set of generic SET/GET/START/STOP commands, which is used to
> > > +turn on/off and configure Qualcomm SoC specific algorithms that run on the SCP.
> > > +Each algorithm is identified through an algorithm string and has an immutable list
> > > +of param_ids. All supported algorithms (currently just MEMLAT) have their own
> > > +dedicated section and are listed after the generic commands.
> > > +
> 
> Hey Sudeep,
> 
> Will set some context here, this version of the vendor protocol is currently
> running in the wild on 5 SoCs (Hamoa, Purwa, Glymur, Mahua, Kaanapali).

While noted, this does not impact the code quality or review process for an
entirely new feature. That context would be relevant for a localized fix or
system quirk, but it is not applicable here.

> The ABI/Specification that this vendor protocol uses can't be changed in
> any way since other Os'es like Windows/Android expect it to behave as
> described in this document and will break userspace.

The current rationale isn't entirely clear to me. Windows historically favors
ACPI over native SCMI, meaning that supporting a proprietary vendor protocol
would require non-native workarounds potentially hidden within interfaces like
PEP. I am skeptical of this architectural direction. Since Android leverages
the Linux kernel and already manages this through vendor modules, maintaining
those as modules seems like the optimal path until we agree on the interface
that can be merged.

> series is meant for the devfreq portion (since it introduces a new devfreq
> governor) and is not for the vendor protocol. We certainly can take design
> improvements for future revisions but making changes to this major/minor
> version of the firmware isn't possible.
>

Given that this patch series has been under discussion for nearly two years,
please provide a summary of the feedback that has already been incorporated
to address these concerns just for sake of argument and in your defence.

To clarify, the vendor protocol space is strictly intended for
platform-specific functionalities that cannot be standardized; it should not
be used to bypass standardization for convenience. It appears no evaluation
was done to determine if or why the standard performance protocol was
insufficient. Had that assessment occurred, I would expect the proposed
interface to align much more closely with the standard definitions as I
previously mentioned.

> Plenty of folks running linux on these SoCs would benefit a great deal from
> this series landing, so please have a bit of patience, take a look at the
> documentation/series as a whole. I still feel we should be able to land this
> series in a form that is acceptable to you. However, if you still feel you
> have
> to NAK this series regardless of its usefulness to the users, please do list
> the
> reasons and we'll try our best to convince you otherwise.
> 

The core issue here is that the proposed vendor protocol interface has been
presented as a finished product without open discussion or a willingness to
iterate based on upstream feedback. This approach bypasses standard
development processes.

IMO these vendor protocol interfaces must be debated on the mailing list prior
to finalization, similar to the 'code-first' prototyping model used for new
ACPI specifications or SCMI early prototyping. If an interface is developed
in isolation and then submitted with an expectation of immediate acceptance
without modification, we cannot approve it. I recommend we pivot to an open
review of the interface design itself.

> > This multiplexer 'N' random algorithn into one single custom SCMI protocol ID
> > (0x80) seems to go against the general SCMI design principle and this seems
> 
> Only the strings documented are allowed by the vendor protocol while the
> rest are filtered out, so we clearly don't have to worry about this. Also
> grouping a class of devfreq algorithms into a single vendor protocol should
> be treated as a SoC vendor design choice.
> 

This is precisely why I previously suggested defining MEMLAT as its own
distinct protocol. Doing so maintains architectural consistency and adheres to
core SCMI principles.

> > like a deliberated attempt to circumvent the standard SCMI protocol template.
> > Standard SCMI expects distinct features to occupy their own vendor protocol
> > IDs and utilize standard protocol discovery.
> > 

^^^ as mentioned above

-- 
Regards,
Sudeep