linux-kernel - Re: [PATCH V7 0/2] qcom: x1e80100: Enable CPUFreq

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] [day] [month] [year] [list]

Message-ID: <Z4Dt8E7C6upVtEGV@hovoldconsulting.com>
Date: Fri, 10 Jan 2025 10:52:48 +0100
From: Johan Hovold <johan@...nel.org>
To: Sibi Sankar <quic_sibis@...cinc.com>
Cc: Marc Zyngier <maz@...nel.org>, sudeep.holla@....com,
	cristian.marussi@....com, andersson@...nel.org,
	konrad.dybcio@...aro.org, robh+dt@...nel.org,
	krzysztof.kozlowski+dt@...aro.org, dmitry.baryshkov@...aro.org,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	devicetree@...r.kernel.org, quic_rgottimu@...cinc.com,
	quic_kshivnan@...cinc.com, conor+dt@...nel.org,
	quic_nkela@...cinc.com, quic_psodagud@...cinc.com,
	abel.vesa@...aro.org
Subject: Re: [PATCH V7 0/2] qcom: x1e80100: Enable CPUFreq

On Mon, Jan 06, 2025 at 05:52:48PM +0530, Sibi Sankar wrote:
> On 12/5/24 21:16, Johan Hovold wrote:

> > As Marc said, it seems you need to come up with a way to detect and work
> > around the broken firmware.
> 
> The perf protocol version won't have any changes so detecting
> it isn't possible :(

But there could be other ways, see below.

> > We want to get the fast channel issue fixed, but when we merge that fix
> > it will trigger these crashes if we also merge cpufreq support for x1e.
> > 
> > Can you expand the on the PERF_LEVEL_GET issue? Is it possible to
> > implement some workaround for the buggy firmware? Like returning a dummy
> > value? How exactly are things working today? Can't that be used a basis
> > for a quirk?
> 
> The main problem is the X1E firmware supports fast channel level get
> but when queried it says it doesn't support it :|. The PERF_LEVEL_GET
> regular messaging which gets used as a fallback has a bug which causes
> the device to crash. So we either enable cpufreq only on platforms
> that has the fix in place or live with the warning that certain messages
> don't support fast channel which I don't think will fly. I've also been
> told the crash wouldn't show up if we have all sleep states disabled.

We certainly want cpufreq enabled also on the current/older firmware
which have these bugs.

Based on the above, it sounds like your fix:

	https://lore.kernel.org/lkml/20241030125512.2884761-2-quic_sibis@quicinc.com/

is correct even if it triggers the crash on machines with buggy firmware.

Why can't you add a quirk for x1e platforms that makes sure that the
driver always uses fastchannel level get?

You know it is supported (and as has to be used) even if the buggy
firmware says it's not. Just set the corresponding attribute bit
unconditionally based on the DT machine compatible (or fall back to the
current implementation which theoretically other broken fw
implementations may also be relying on), or similar.

Johan