linux-kernel - Re: [PATCH 1/1] firmware: arm_scmi: Increase MAX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251211-wandering-magnificent-yak-5fb19e@sudeepholla>
Date: Thu, 11 Dec 2025 14:07:07 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: "Alexey Klimov" <alexey.klimov@...aro.org>,
	"Vivek Aknurwar" <vivek.aknurwar@....qualcomm.com>
Cc: <cristian.marussi@....com>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-arm-msm@...r.kernel.org>, <mike.tipton@....qualcomm.com>
Subject: Re: [PATCH 1/1] firmware: arm_scmi: Increase MAX_OPPS to 64

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