linux-kernel - Re: [PATCH] iommu/arm-smmu: add actlr settings for mdss and fastrpc

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: <02d7c0a9-0d24-4fd8-980a-da9d7307588a@oss.qualcomm.com>
Date: Wed, 12 Nov 2025 15:02:52 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Charan Teja Kalla <charan.kalla@....qualcomm.com>,
        robin.clark@....qualcomm.com, will@...nel.org, robin.murphy@....com,
        joro@...tes.org, dmitry.baryshkov@....qualcomm.com
Cc: iommu@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        bibek.patro@....qualcomm.com
Subject: Re: [PATCH] iommu/arm-smmu: add actlr settings for mdss and fastrpc

On 11/11/25 3:02 PM, Charan Teja Kalla wrote:
> 
> 
> On 11/5/2025 2:44 PM, Konrad Dybcio wrote:
>>> +	{ .compatible = "qcom,fastrpc-compute-cb",
>>> +			.data = (const void *) (PREFETCH_DEEP | CPRE | CMTLB) },
>> This will be globally applied to all smmu-v2 targets with fastrpc,
>> starting from MSM8996 ending at Kaanapali and everything inbetween
>>
>> Are these settings always valid?
> Oops, you are correct...this settings are not always applicable it seems.
> 
> Example: lpass compute and cdsp compute node uses the
> "qcom,fastrpc-compute-cb", but it is for the later that ACTLR settings
> are valid.
> 
> Then for these cases, should we be extending the actlr match array with
> additional compatible string and then add them in all the device nodes
> that require actlr setting? example:
> 
> @@ -3119,7 +3119,8 @@ fastrpc {
>       compute-cb@1 {
> -         compatible = "qcom,fastrpc-compute-cb";
> +         compatible = "qcom,fastrpc-compute-cb",
> +                      "qcom,fastrpc-compute-cb-actlr";

dt-bindings (and especially compatible strings) must not be altered solely
to work around a driver being suboptimal

But because you reported that these settings can change both between
platforms and instances of the same devices on these platforms, we could
possibly reconsider adding ACTRL settings to the consumer device nodes
where they stray away from the otherwise seemingly reasonable baseline
we have in the driver so far..

Or we could introduce some more bespoke matching logic.

I would like to know more about the scope of this issue, i.e. the matrix
of (soc, device, actlr_val) that needs special handling.

Konrad