linux-kernel - Re: [RFC 0/2] Add support for SCMI QTI Memlat Vendor Protocol

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]

Date:   Tue, 8 Nov 2022 16:31:12 +0530
From:   Sibi Sankar <quic_sibis@...cinc.com>
To:     Cristian Marussi <cristian.marussi@....com>
CC:     <andersson@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>,
        <robh+dt@...nel.org>, <sudeep.holla@....com>, <agross@...nel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <konrad.dybcio@...ainline.org>,
        <quic_avajid@...cinc.com>, <souvik.chakravarty@....com>
Subject: Re: [RFC 0/2] Add support for SCMI QTI Memlat Vendor Protocol

Hey Cristian,
Thanks for taking time to review the series.

On 11/3/22 15:11, Cristian Marussi wrote:
> On Thu, Nov 03, 2022 at 10:28:30AM +0530, Sibi Sankar wrote:
>> The patch series documents the bindings and adds support for the
>> SCMI QTI memlat (memory latency) vendor protocol. The protocol takes
>> in several tuneables including the IPM ratio (Instructions Per Miss),
>> bus bandwidth requirements and PMU maps to enable frequency scaling
>> of various buses (L3/LLCC/DDR). The scaling is performed by the HW
>> memory latency governor running on the CPUSS Control Processor.
>>
>> Depends on CPUCP mailbox driver:
>> https://patchwork.kernel.org/project/linux-arm-msm/cover/1663135386-26270-1-git-send-email-quic_sibis@quicinc.com/
>>
> 
> [+ CC: souvik.chakravarty@....com ]
> 
> Hi Sibi,
> 
> Nice to see vendor protocols starting to make their way into upstream !
> 
> I only glanced through the series as of now, and I'd have a few
> questions before going on with the review:
> 
>   - why this protocol is dependent on a specific transport ?
>     Is it to compile it only on platform supoprting it without adding
>     a per-protocol Kconfig ?

It was done just to compile it on platforms supporting it but it doesn't
have to done that way. I remove the dependency during the next re-spin.

- Sibi

> 
> Protocols are anyway enumerated at SCMI stack probe time so even if it
> is not there it just won't be activated...I maybe missing something.
> 
> Thanks,
> Cristian
> 
> 
>