linux-hardening - Re: [PATCH v3 01/10] dt-bindings: gpu: mali-valhall-csf: add mediatek,mt8196-mali variant

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: <c210de74-6eb5-40a4-b87d-a4a5c3123e65@kernel.org>
Date: Fri, 19 Sep 2025 13:28:54 +0900
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Boris Brezillon <boris.brezillon@...labora.com>,
 Steven Price <steven.price@....com>, Liviu Dudau <liviu.dudau@....com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Matthias Brugger
 <matthias.bgg@...il.com>, MyungJoo Ham <myungjoo.ham@...sung.com>,
 Kyungmin Park <kyungmin.park@...sung.com>,
 Chanwoo Choi <cw00.choi@...sung.com>, Jassi Brar <jassisinghbrar@...il.com>,
 Kees Cook <kees@...nel.org>, "Gustavo A. R. Silva" <gustavoars@...nel.org>,
 Chia-I Wu <olvaffe@...il.com>, Chen-Yu Tsai <wenst@...omium.org>,
 kernel@...labora.com, dri-devel@...ts.freedesktop.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 linux-pm@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v3 01/10] dt-bindings: gpu: mali-valhall-csf: add
 mediatek,mt8196-mali variant

On 18/09/2025 23:01, Nicolas Frattaroli wrote:
> On Thursday, 18 September 2025 02:30:09 Central European Summer Time Krzysztof Kozlowski wrote:
>> On Wed, Sep 17, 2025 at 02:22:32PM +0200, Nicolas Frattaroli wrote:
>>> The Mali-based GPU on the MediaTek MT8196 SoC uses a separate MCU to
>>> control the power and frequency of the GPU.
>>>
>>> It lets us omit the OPP tables from the device tree, as those can now be
>>> enumerated at runtime from the MCU. It also means the mali GPU node
>>> described in this binding does not have any clocks in this case, as all
>>> clock control is delegated to the MCU.
>>>
>>> Add the mediatek,mt8196-mali compatible, and a performance-domains
>>> property which points to the MCU's device tree node in this case. It's
>>> required on mt8196 devices.
>>>
>>> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
>>> ---
>>>  .../bindings/gpu/arm,mali-valhall-csf.yaml         | 32 ++++++++++++++++++++--
>>>  1 file changed, 30 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> index 7ad5a3ffc5f5c753322eda9e74cc65de89d11c73..ccab2dd0ea852187e3ab75923e19739622b2b3b8 100644
>>> --- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> @@ -38,7 +38,6 @@ properties:
>>>        - const: gpu
>>>  
>>>    clocks:
>>> -    minItems: 1
>>
>> I don't understand why.
>>
>> Best regards,
>> Krzysztof
>>
>>
> 
> I am executing a Convex hull algorithm on the 3D space of "dt-bindings
> maintainer opinions" to get a convex hull of acceptable dt-bindings
> choices where two different choices are functionally equivalent.
> 
> With this additional opinion on the krzk axis, I now know that having
> the base properties accurate for the general case is not required if
> the per-compatible case sets the property to false anyway.
> 
> I hope no two opinions are collinear, as this would surely be my
> undoing.
> 
> You get to pick which axis (X, Y, Z) you are. Right-hand rule, of
> course.

This piece of code is wrong and I could not deduce the reason. That's
why I asked why you need that change. If you intend to waste my time, I
will don't bother with this, but code is still wrong.

Best regards,
Krzysztof