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: <20241106-fragment-luckiness-51ccb4bd2b4e@spud>
Date: Wed, 6 Nov 2024 17:06:40 +0000
From: Conor Dooley <conor@...nel.org>
To: Matt Coster <Matt.Coster@...tec.com>
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 Wed, Nov 06, 2024 at 10:17:53AM +0000, Matt Coster wrote:
> 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.

You can just constrain clock-names: maxItems: 1 like you have already
done for clocks. The items list that was already in the file enforces
that the first clock provided must be core. When you add your new
compatible you can set clock{-names}: minItems: 3 for it, and that will
ensure that either 1 clock (core) or all 3 are the only options.

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