linux-kernel - Re: [PATCH v16 3/5] iommu/arm-smmu: add support for PRR bit setup

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]

Message-ID: <92f0df16-c755-49c2-8356-0b7b94754390@quicinc.com>
Date: Thu, 31 Oct 2024 01:57:47 +0530
From: Bibek Kumar Patro <quic_bibekkum@...cinc.com>
To: Rob Clark <robdclark@...il.com>, Robin Murphy <robin.murphy@....com>
CC: <will@...nel.org>, <joro@...tes.org>, <jgg@...pe.ca>,
        <jsnitsel@...hat.com>, <robh@...nel.org>,
        <krzysztof.kozlowski@...aro.org>, <quic_c_gdjako@...cinc.com>,
        <dmitry.baryshkov@...aro.org>, <iommu@...ts.linux.dev>,
        <linux-arm-msm@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v16 3/5] iommu/arm-smmu: add support for PRR bit setup



On 10/30/2024 10:28 PM, Rob Clark wrote:
> On Wed, Oct 30, 2024 at 8:23 AM Robin Murphy <robin.murphy@....com> wrote:
>>
>> On 30/10/2024 1:14 pm, Bibek Kumar Patro wrote:
>>>
>>>
>>> On 10/29/2024 6:59 PM, Robin Murphy wrote:
>>>> On 2024-10-08 1:54 pm, Bibek Kumar Patro wrote:
>>>>> Add an adreno-smmu-priv interface for drm/msm to call
>>>>> into arm-smmu-qcom and initiate the PRR bit setup or reset
>>>>> sequence as per request.
>>>>>
>>>>> This will be used by GPU to setup the PRR bit and related
>>>>> configuration registers through adreno-smmu private
>>>>> interface instead of directly poking the smmu hardware.
>>>>>
>>>>> Suggested-by: Rob Clark <robdclark@...il.com>
>>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum@...cinc.com>
>>>>> ---
>>>>>    drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 37 ++++++++++++++++++++++
>>>>>    drivers/iommu/arm/arm-smmu/arm-smmu.h      |  2 ++
>>>>>    include/linux/adreno-smmu-priv.h           | 10 +++++-
>>>>>    3 files changed, 48 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/
>>>>> iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>> index 6e0a2a43e45a..38ac9cab763b 100644
>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>> @@ -25,6 +25,7 @@
>>>>>
>>>>>    #define CPRE            (1 << 1)
>>>>>    #define CMTLB            (1 << 0)
>>>>> +#define GFX_ACTLR_PRR        (1 << 5)
>>>>>
>>>>>    static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
>>>>>    {
>>>>> @@ -109,6 +110,40 @@ static void
>>>>> qcom_adreno_smmu_resume_translation(const void *cookie, bool termina
>>>>>        arm_smmu_cb_write(smmu, cfg->cbndx, ARM_SMMU_CB_RESUME, reg);
>>>>>    }
>>>>>
>>>>> +static void qcom_adreno_smmu_set_prr_bit(const void *cookie, bool set)
>>>>> +{
>>>>> +    struct arm_smmu_domain *smmu_domain = (void *)cookie;
>>>>> +    struct arm_smmu_device *smmu = smmu_domain->smmu;
>>>>> +    const struct device_node *np = smmu->dev->of_node;
>>>>> +    struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
>>>>> +    u32 reg = 0;
>>>>> +
>>>>> +    if (of_device_is_compatible(np, "qcom,smmu-500") &&
>>>>> +            of_device_is_compatible(np, "qcom,adreno-smmu")) {
>>>>
>>>> These conditions aren't going to change between calls - wouldn't it
>>>> make more sense to conditionally assign the callbacks in the first
>>>> place? Not the biggest deal if this is a one-off context-setup type
>>>> thing, just that it looks a little funky.
>>>>
>>>
>>> Let me know if you want to pursue this still.
>>>   From the current PRR implementation in the graphics
>>> vendor layer, this seems to be just setup kind-of thing.
>>> Also if we keep this conditional check before assigning callbacks,
>>> and vendor layer caller won't be having any such check,
>>> wouldn't it be an issue in unsupported platforms (!qcom,smmu-500 or
>>> !qcom,adreno-smmu)
>>> as the callbacks won't be assigned?
>>> So as per my understanding I think it would be safe to keep the
>>> condition check here?
>>
>> Like I say, it makes more sense to me personally if SMMUs which don't
>> have a PRR don't offer a callback for setting the PRR which they don't
>> have, and for it to be the caller's responsibility not to call a NULL
>> callback where they wouldn't need to call one anyway. But the
>> adreno_priv interface is kind of Rob's thing, so I'll leave it to his
>> preference.
> 
> We can go the route of NULL cb if it is not supported (but should make
> note of that in the adreno-smmu-priv.h header comment)
> 

Actually I liked Robin's suggestion to use the compatible check before 
assignment in the sense that there won't be repeated compatible checks
for each call. My only concern was how to handle the non PRR supported 
targets incase vendors called it.
Thanks for clarifying the same, we can use null callbacks for non-PRR 
supported targets with a note in adreno-smmu-priv.h header, so that
caller could take care while implementing the same.
I'll incorporate these changes in next patch along with the CPRE workaround.

Thanks & regards,
Bibek


> BR,
> -R
> 
>> Thanks,
>> Robin.