linux-kernel - Re: [PATCH V5 0/2] 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] [day] [month] [year] [list]

Message-ID: <Z1HWVfIS-w0OXQHl@bogus>
Date: Thu, 5 Dec 2024 16:35:33 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Sibi Sankar <quic_sibis@...cinc.com>
Cc: <cristian.marussi@....com>, <andersson@...nel.org>,
	<konrad.dybcio@...aro.org>, <linux-kernel@...r.kernel.org>,
	Sudeep Holla <sudeep.holla@....com>,
	<linux-arm-msm@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <quic_rgottimu@...cinc.com>,
	<quic_kshivnan@...cinc.com>, <arm-scmi@...r.kernel.org>
Subject: Re: [PATCH V5 0/2] arm_scmi: vendors: Qualcomm Generic Vendor
 Extensions

On Fri, Nov 15, 2024 at 06:45:13AM +0530, Sibi Sankar wrote:
> The QCOM SCMI vendor protocol provides a generic way of exposing a
> number of Qualcomm SoC specific features (like memory bus scaling)
> through a mixture of pre-determined algorithm strings and param_id
> pairs hosted on the SCMI controller. Introduce a client driver that
> uses the memlat algorithm string hosted on QCOM SCMI Vendor Protocol
> to detect memory latency workloads and control frequency/level of
> the various memory buses (DDR/LLCC/DDR_QOS).
> 
> QCOM SCMI Generic Vendor protocol background:
> It was found that a lot of the vendor protocol used internally was
> for debug/internal development purposes that would either be super
> SoC specific or had to be disabled because of some features being
> fused out during production. This lead to a large number of vendor
> protocol numbers being quickly consumed and were never released
> either. Using a generic vendor protocol with functionality abstracted
> behind algorithm strings gave us the flexibility of allowing such
> functionality exist during initial development/debugging while
> still being able to expose functionality like memlat once they have
> matured enough. The param-ids are certainly expected to act as ABI
> for algorithms strings like MEMLAT.
> 
> Thanks in advance for taking time to review the series.
> 
> V4:
> * Splitting the series into vendor protocol and memlat client.
>   Also the move the memlat client implementation back to RFC
>   due to multiple opens.

Sorry if I missed the rationale for the split here from the previous
discussions, but I would like to see the DT bindings if any for all the
users first before I can merge this. I am happy to get this series reviewed
independently but my views might change looking at how it will be used as
I might get better idea looking at the users. I really don't like the
interface as well as the DT bindings that might be enforcing us to define.
I have given my initial comments there.

No need to respin it together immediately or even in future as along as
there is a reference for me to look at.

--
Regards,
Sudeep