[PATCH 1/1] firmware: arm_scmi: Increase MAX_OPPS to 64

[Sudeep Holla]

On Thu, Dec 11, 2025 at 01:54:01PM +0000, Alexey Klimov wrote:
> On Thu Dec 11, 2025 at 1:48 PM GMT, Sudeep Holla wrote:
> > On Thu, Dec 11, 2025 at 01:14:06PM +0000, Alexey Klimov wrote:
> >> > On 10/14/2025 12:34 AM, Vivek Aknurwar wrote:
> >> >> Some upcoming SoCs define more than 32 operating performance points (OPPs),
> >> >> exceeding the current SCMI protocol limit. Increase MAX_OPPS to 64
> >> >> (next power of 2) to support these configurations.
> >> 
> >> Didn't touch for a while. The way it is stated confuses me a bit.
> >> Should the value defined by protocol be updated out of the blue?
> >> Should the protocol (defined by spec) be changed first?
> >> 
> >
> > Ah good point on confusing commit message. I just assumed it is limitation
> > of the implementation. I can update the log when applying. It is not spec
> > or protocol limitation for sure.
> >
> > How about this ?
> >
> >   | firmware: arm_scmi: Increase performance MAX_OPPS limit to 64
> >   |
> >   | Some platforms expose more than 32 operating performance points (OPPs)
> >   | per performance domain via the SCMI performance protocol, but the
> >   | driver currently limits the number of OPPs it can handle to 32 via
> >   | MAX_OPPS.
> >   |
> >   | Bump MAX_OPPS to 64 so that these platforms can register all their
> >   | performance levels. This is an internal limit in the driver only and
> >   | does not affect the SCMI protocol ABI.
> >   |
> >   | 64 is chosen as the next power of two above the existing limit.
> 
> Yeah, that sounds better :)
> 

Thanks!

> I also thought that this was a driver limitation, not the protocol/spec one
> as stated in the original patch.
> 
> I don't mind updating the commit message like this (but I am not the author
> of the original patch).
> 

Vivek, are you happy with the above edited commit message ?

-- 
Regards,
Sudeep