linux-kernel - Re: [PATCH 1/2] dt-bindings: display/msm/gpu: Narrow reg and reg-names for Adreno 610.0 and alike

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8288af85-13da-46e3-8d89-71995fbd17f8@kernel.org>
Date: Mon, 29 Dec 2025 08:23:56 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: rob.clark@....qualcomm.com
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@....qualcomm.com>,
 Sean Paul <sean@...rly.run>, Konrad Dybcio <konradybcio@...nel.org>,
 Akhil P Oommen <akhilpo@....qualcomm.com>,
 Dmitry Baryshkov <lumag@...nel.org>, Abhinav Kumar
 <abhinav.kumar@...ux.dev>, Jessica Zhang <jesszhan0024@...il.com>,
 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>, linux-arm-msm@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: display/msm/gpu: Narrow reg and
 reg-names for Adreno 610.0 and alike

On 28/12/2025 15:59, Rob Clark wrote:
> On Sat, Dec 27, 2025 at 11:56 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>> On 27/12/2025 23:01, Rob Clark wrote:
>>> On Sat, Dec 27, 2025 at 3:05 AM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@....qualcomm.com> wrote:
>>>>
>>>> DTS files for qcom,adreno-610.0 and qcom,adreno-07000200 contain only one
>>>> "reg" entry, not two, and the binding defines the second entry in
>>>> "reg-names" differently than top-level part, so just simplify it and
>>>> narrow to only one entry.
>>>
>>> I'll defer to Akhil about whether this is actually needed (vs just
>>> incomplete gpu devcoredump support for certain GPUs).  In general
>>> cx_dbgc is needed to capture state for gpu devcoredump state
>>> snapshots, but not directly used in normal operations.  It seems
>>> similar to the situation with mapping gpucc as part of gmu, ie. not
>>> something the CPU normally deals with directly, but necessary to
>>> capture crash state.
>>
>> I don't get why binding was added with cx_dbgc, but DTS not. Neither
>> binding nor DTS depends on actual usage, so I assume someone
>> intentionally did not want DTS to contain cx_dbgc and binding should
>> follow. Otherwise we should make the DTS complete and make the binding
>> strict (leading to warnings if DTS is not updated).
> 
> I'm not sure about the history.. but I can say that cx_dbgc is only
> used for gpu state snapshot / devcoredump.  So it would be easy to not
> notice if it were missing.
> 
> We have a similar slightly ugly thing where gpucc is included in the
> gmu map.. only for devcoredump.  Maybe we need a different way to
> handle these things that are only mapped for state capture?

No. Either hardware has it or not. If hardware has it, then both DTS and
binding should have it. If people decided that DTS should not have it
(for whatever reason), then apparently that's the desired hardware
description and let's remove it from the binding to match the ABI.

Best regards,
Krzysztof