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: <2a35d31a-1a3e-4cd4-ac3a-27104ff12801@kernel.org>
Date: Sun, 28 Dec 2025 08:56:33 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: rob.clark@....qualcomm.com,
 Krzysztof Kozlowski <krzysztof.kozlowski@....qualcomm.com>
Cc: 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 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).

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ