linux-kernel - Re: [PATCH v3 2/6] dt-bindings: display/msm: gpu: Document A612 GPU

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: <5bad57b5-ab05-477e-b8e9-5086139b2326@kernel.org>
Date: Sat, 29 Nov 2025 10:21:47 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Akhil P Oommen <akhilpo@....qualcomm.com>
Cc: Rob Clark <robin.clark@....qualcomm.com>, Sean Paul <sean@...rly.run>,
 Konrad Dybcio <konradybcio@...nel.org>, Dmitry Baryshkov <lumag@...nel.org>,
 Abhinav Kumar <abhinav.kumar@...ux.dev>,
 Marijn Suijten <marijn.suijten@...ainline.org>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
 Jessica Zhang <jesszhan0024@...il.com>,
 Dan Carpenter <dan.carpenter@...aro.org>, linux-arm-msm@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 2/6] dt-bindings: display/msm: gpu: Document A612 GPU

On 28/11/2025 11:29, Akhil P Oommen wrote:
> On 11/25/2025 1:28 PM, Krzysztof Kozlowski wrote:
>> On 24/11/2025 22:39, Akhil P Oommen wrote:
>>> On 11/22/2025 4:32 PM, Krzysztof Kozlowski wrote:
>>>> On Sat, Nov 22, 2025 at 03:22:16AM +0530, Akhil P Oommen wrote:
>>>>> +
>>>>> +  - if:
>>>>> +      properties:
>>>>> +        compatible:
>>>>> +          contains:
>>>>> +            const: qcom,adreno-612.0
>>>>> +    then:
>>>>> +      properties:
>>>>> +        clocks:
>>>>> +          items:
>>>>> +            - description: GPU Core clock
>>>>> +
>>>>> +        clock-names:
>>>>> +          items:
>>>>> +            - const: core
>>>>> +
>>>>> +      required:
>>>>> +        - clocks
>>>>> +        - clock-names
>>>>> +
>>>>>      else:
>>>>
>>>> I am pretty sure you break not only intention/logic behindi this else,
>>>> but actually cause real warnings to appear.
>>>>
>>>> The else was intentional, right? So the pattern further will not match
>>>> some of devices defined in if:. Now else is for different part, so only
>>>> 612 out of these devices is excluded.
>>>>
>>>> There is a reason we do not want ever else:if: in bindings. If it
>>>> appeared, sure, maybe there is some benefit of it, but it means you need
>>>> to be more careful now.
>>>
>>> Aah! I missed that this comes under an 'allOf'. Not an expert in this
>>
>> The allOf does not matter here. If these were separate if:then: then it
>> would be the same.
>>
>>> syntax, does moving this entire block under an 'else' make sense? Or is
>>
>> No, never nest blocks.
>>
>>> there a saner alternative?
>>
>> Not sure, I don't remember the code. Original code was not easy to read,
>> with your changes it will not be easier. So the only alternative I see
>> is to make it simple and obvious.
> 
> Could you please confirm if the below change would be okay?
> 
> @@ -384,6 +384,31 @@ allOf:
> 
>   - if:
>       properties:
>         compatible:
>           contains:
>             enum:
>               - qcom,adreno-610.0
>               - qcom,adreno-619.1
>               - qcom,adreno-07000200
>     then:
>       properties:
>         clocks:
>           minItems: 6
>           maxItems: 6
> 
>         clock-names:
>           items:
>             - const: core
>               description: GPU Core clock
>             - const: iface
>               description: GPU Interface clock
>             - const: mem_iface
>               description: GPU Memory Interface clock
>             - const: alt_mem_iface
>               description: GPU Alternative Memory Interface clock
>             - const: gmu
>               description: CX GMU clock
>             - const: xo
>               description: GPUCC clocksource clock
> 
>         reg-names:
>           minItems: 1
>           items:
>              - const: kgsl_3d0_reg_memory
>              - const: cx_dbgc
> 
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: qcom,adreno-612.0
> +    then:
> +      properties:
> +        clocks:
> +          items:
> +            - description: GPU Core clock
> +
> +        clock-names:
> +          items:
> +            - const: core
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - qcom,adreno-610.0
> +              - qcom,adreno-612.0
> +              - qcom,adreno-619.1
> +              - qcom,adreno-07000200
> +    then:
>       required:
>         - clocks
>         - clock-names

Yes, this should work, but I think it is better to require clocks in the
same block which defines them. You also need to restrict reg/reg-names
for the new device.

> 
>     else:
>       if:
>         properties:
>           compatible:
>             contains:
>               oneOf:
>                 - pattern: '^qcom,adreno-[67][0-9][0-9]\.[0-9]+$'
>                 - pattern: '^qcom,adreno-[0-9a-f]{8}$'

This if:else:if: should be just removed and written in a way to choose
specific devices affected here. The code is not readable and your
mistake was a proof of that.

> 
>       then: # Starting with A6xx, the clocks are usually defined in the
>         properties:
Best regards,
Krzysztof