linux-kernel - Re: [PATCH V4 0/5] arm_scmi: vendors: Qualcomm Generic Vendor Extensions

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: <Z1HceQegfMl07qj_@bogus>
Date: Thu, 5 Dec 2024 17:01:45 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Johan Hovold <johan@...nel.org>
Cc: Sibi Sankar <quic_sibis@...cinc.com>,
	Sudeep Holla <sudeep.holla@....com>,
	Cristian Marussi <cristian.marussi@....com>, andersson@...nel.org,
	konrad.dybcio@...aro.org, robh+dt@...nel.org,
	krzysztof.kozlowski+dt@...aro.org, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, quic_rgottimu@...cinc.com,
	quic_kshivnan@...cinc.com, conor+dt@...nel.org,
	arm-scmi@...r.kernel.org
Subject: Re: [PATCH V4 0/5] arm_scmi: vendors: Qualcomm Generic Vendor
 Extensions

On Fri, Nov 22, 2024 at 09:37:47AM +0100, Johan Hovold wrote:
> On Thu, Nov 14, 2024 at 09:52:12AM +0530, Sibi Sankar wrote:
> > On 11/8/24 20:44, Johan Hovold wrote:
>
> > >> On Wed, Nov 06, 2024 at 01:55:33PM +0100, Johan Hovold wrote:
>
> > >>> Second, after loading the protocol and client drivers manually (in that
> > >>> order, shouldn't the client driver pull in the protocol?), I got:
> > >>>
> > >>> 	scmi_module: Loaded SCMI Vendor Protocol 0x80 - Qualcomm  20000
> > >>> 	arm-scmi arm-scmi.0.auto: QCOM Generic Vendor Version 1.0
> > >>> 	scmi-qcom-generic-ext-memlat scmi_dev.5: error -EOPNOTSUPP: failed to configure common events
> > >>> 	scmi-qcom-generic-ext-memlat scmi_dev.5: probe with driver scmi-qcom-generic-ext-memlat failed with error -95
> > >>>
> > >>> which seems to suggest that the firmware on my CRD does not support this
> > >>> feature. Is that the way this should be interpreted? And does that mean
> > >>> that non of the commercial laptops supports this either?
>
> > > Yeah, hopefully Sibi can shed some light on this. I'm using the DT
> > > patch (5/5) from this series, which according to the commit message is
> > > supposed to enable bus scaling on the x1e80100 platform. So I guess
> > > something is missing in my firmware.
> >
> > Nah, it's probably just because of the algo string used.
> > The past few series used caps MEMLAT string instead of
> > memlat to pass the tuneables, looks like all the laptops
> > havn't really switched to it yet. Will revert back to
> > using to lower case memlat so that all devices are
> > supported. Thanks for trying the series out!
>
> I have a Lenovo ThinkPad T14s set up now so I gave this series a spin
> there too, and there I do *not* see the above mentioned -EOPNOSUPP error
> and the memlat driver probes successfully.
>
> On the other hand, this series seems to have no effect on a kernel
> compilation benchmark. Is that expected?
>

Hijacking this thread to rant about state of firmware implementation on
this platform that gives me zero confidence in merging any of these without
examining each of the interface details in depth and at lengths.

Also I see the standard protocol like PERF seem to have so many issues which
adds to my no confidence. I can't comment on that thread for specific reasons.

I will briefly mention my suspicion here. This Lenovo ThinkPad T14s being
primarily targeting other OS using ACPI might have just implemented what is
required for ACPI CPPC which conveniently doesn't have to discover lot of
fastchannel details since they are supplied in the tables straight away.
But that also would mean it could be not fully compliant to SCMI spec.

Either we need to run some compliance test suite(which again may need more
work as it is unfortunately make platform specific - referring to [1])
or use the raw interface in the kernel and throw /dev/random at it and see
how well it can cope up.

--
Regards,
Sudeep

[1] https://gitlab.arm.com/tests/scmi-tests (Not so great and needs platform
     specific vectors to check compliance)