linux-kernel - Re: [RFC V6 2/2] firmware: arm_scmi: Add quirk to bypass SCP fw bug

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Z9l1L1WICMYXSoIu@pluto>
Date: Tue, 18 Mar 2025 13:29:19 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: Johan Hovold <johan@...nel.org>
Cc: Cristian Marussi <cristian.marussi@....com>,
	Dan Carpenter <dan.carpenter@...aro.org>,
	Sibi Sankar <quic_sibis@...cinc.com>, sudeep.holla@....com,
	dmitry.baryshkov@...aro.org, maz@...nel.org,
	linux-kernel@...r.kernel.org, arm-scmi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
	konradybcio@...nel.org
Subject: Re: [RFC V6 2/2] firmware: arm_scmi: Add quirk to bypass SCP fw bug

On Tue, Mar 18, 2025 at 09:16:36AM +0100, Johan Hovold wrote:
> Hi Cristian,

Hi Johan,

> 
> On Mon, Mar 03, 2025 at 11:53:52AM +0100, Johan Hovold wrote:
> > On Thu, Feb 27, 2025 at 08:34:44AM +0000, Cristian Marussi wrote:
> > > On Wed, Feb 26, 2025 at 10:58:44AM +0100, Johan Hovold wrote:
> > 
> > > > Something like that, yes. :) I didn't try to implement it, but it seems
> > > > like it should be possible implement this is a way that keeps the quirk
> > > > handling isolated.
> > > 
> > > I hope next week to have a better look at this, in tne meantime just a
> > > few considerations....
> > > 
> > > Sooner or later we should have introduced some sort of quirk framework
> > > in SCMI to deal systematically with potentially out-of-spec FW, but as
> > > in the name, it should be some sort of framework where you have a table of
> > > quirks, related activation conditions and a few very well isolated points
> > > where the quirks are placed and take action if enabled...this does not
> > > seem the case here where instead an ad-hoc param is added to the function
> > > that needs to be quirked...this does not scale and will make the codebase
> > > a mess IMHO...
> > 
> > Sounds good. At least we have a good understanding now of how this
> > particular firmware is broken so it would be great if you could use
> > this as a test case for the implementation.
> > 
> > In summary, we need to force the use of a fast channel for
> > PERF_LEVEL_GET on these machines, or possibly fall back to the current
> > behaviour of only using the domain attribute to determine whether the
> > fast channels should be initialised.
> > 
> > The latter may allow for a less intrusive implementation even if we'd
> > still see:
> > 
> > 	arm-scmi arm-scmi.0.auto: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:0] - ret:-95. Using regular messaging.
> > 	arm-scmi arm-scmi.0.auto: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:1] - ret:-95. Using regular messaging.
> > 	arm-scmi arm-scmi.0.auto: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:2] - ret:-95. Using regular messaging.
> > 
> > when not supported for all messages (e.g. with the current firmware).
> 
> > > Anyway, after all of this babbling, I know, talk is cheap :D...so now I will shut
> > > up and see if I can prototype something generic to deal with quirks, possibly
> > > next week...
> 
> Have you made any progress on the quirk framework prototyping?
> 

I have not forgot, tried a few things, but nothing really to post as of
now...dont wnat to rush either .... I was hoping to push something out at
the end of this next merge window...

> Do you need any input from Sibi on the protocol versioning for that?
>

No I am fine, I am planning anyway for something generic enough to be
easy then to plug your own quirks separately...

> We'd really like to enable cpufreq on this platform and ideally in 6.15.
> I think that should be possible given that we now understand in what
> ways the firmware is broken and what is needed to handle it even if we
> still need to decide on how best to implement this.
> 

v6.15 seems hard/impossible even using the original Sibi patch 
given the usual upstreaming-timeline of the SCMI stack where everything has
to be usually reviewed and accepted by rc4/rc5.....so both Sibi initial
patch and my own babbling were alreaady sort of late.

Thanks,
Cristian