linux-kernel - Re: [PATCH 02/21] dt-bindings: gpu: img: Further constrain clocks

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: <5b26e693-d37f-41ee-b119-32ef648de6f4@imgtec.com>
Date: Wed, 6 Nov 2024 10:17:53 +0000
From: Matt Coster <Matt.Coster@...tec.com>
To: Conor Dooley <conor@...nel.org>
CC: Frank Binns <Frank.Binns@...tec.com>, 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>, Nishanth Menon <nm@...com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Tero
 Kristo <kristo@...nel.org>,
        "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>,
        "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>,
        Randolph Sapp <rs@...com>, Darren
 Etheridge <detheridge@...com>
Subject: Re: [PATCH 02/21] dt-bindings: gpu: img: Further constrain clocks

On 05/11/2024 18:16, Conor Dooley wrote:
> On Tue, Nov 05, 2024 at 03:58:08PM +0000, Matt Coster wrote:
>> All Imagination GPUs use three clocks: core, mem and sys. All reasonably
>> modern Imagination GPUs also support a single-clock mode where the SoC
>> only hooks up core and the other two are derived internally. On GPUs which
>> support this mode, it is the default and most commonly used integration.
>>
>> Codify this "1 or 3" constraint in our bindings and hang the specifics off
>> the vendor compatible string to mirror the integration-time choice.
>>
>> Signed-off-by: Matt Coster <matt.coster@...tec.com>
>> ---
>>  .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 27 +++++++++++++++-------
>>  1 file changed, 19 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
>> index ef7070daf213277d0190fe319e202fdc597337d4..6924831d3e9dd9b2b052ca8f9d7228ff25526532 100644
>> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
>> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
>> @@ -30,15 +30,20 @@ properties:
>>      maxItems: 1
>>  
>>    clocks:
>> -    minItems: 1
>> -    maxItems: 3
>> +    oneOf:
>> +      - minItems: 1
>> +        maxItems: 1
>> +      - minItems: 3
>> +        maxItems: 3
> 
> Just put the outer constraints here and...
> 
>>    clock-names:
>> -    items:
>> -      - const: core
>> -      - const: mem
>> -      - const: sys
>> -    minItems: 1
>> +    oneOf:
>> +      - items:
>> +          - const: core
>> +      - items:
>> +          - const: core
>> +          - const: mem
>> +          - const: sys
>>  
>>    interrupts:
>>      maxItems: 1
>> @@ -56,15 +61,21 @@ required:
>>  additionalProperties: false
>>  
>>  allOf:
>> +  # Vendor integrations using a single clock domain
>>    - if:
>>        properties:
>>          compatible:
>>            contains:
>> -            const: ti,am62-gpu
>> +            anyOf:
>> +              - const: ti,am62-gpu
>>      then:
>>        properties:
>>          clocks:
>> +          minItems: 1
>>            maxItems: 1
> 
> ...adjust the constraints in conditional bits. Setting minItems to 1
> should be a nop too. Pretty sure what you already had here was actually
> already sufficient.
> 
> Cheers,
> Conor.

Is there an implicit constraint ensuring "clocks" and "clock-names" are
the same size? I wasn't sure if we could rely on that, hence the
slightly odd constraint on "clocks". The only real goal here is to
codify that you can't have one of "mem" or "sys". it's both or nothing.

Cheers,
Matt

>> +        clock-names:
>> +          items:
>> +            - const: core
>>  
>>  examples:
>>    - |
>>
>> -- 
>> 2.47.0
>>

-- 
Matt Coster
E: matt.coster@...tec.com


Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)