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]
Date: Tue, 20 Feb 2024 19:32:53 +0000
From: Conor Dooley <conor@...nel.org>
To: Dharma.B@...rochip.com
Cc: robh@...nel.org, tglx@...utronix.de, krzysztof.kozlowski+dt@...aro.org,
	conor+dt@...nel.org, Nicolas.Ferre@...rochip.com,
	alexandre.belloni@...tlin.com, claudiu.beznea@...on.dev,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2] dt-bindings: interrupt-controller: Convert Atmel AIC
 to json-schema

On Mon, Feb 19, 2024 at 03:30:52PM +0000, Dharma.B@...rochip.com wrote:
> Hi Rob and Conor,
> 
> On 14/02/24 12:43 am, Conor Dooley wrote:
> > On Tue, Feb 13, 2024 at 04:23:36AM +0000,Dharma.B@...rochip.com  wrote:
> >> On 12/02/24 7:38 pm, Rob Herring wrote:
> >>> On Fri, Feb 09, 2024 at 03:31:22PM +0530, Dharma Balasubiramani wrote:
> >>>> +  atmel,external-irqs:
> >>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>>> +    description: u32 array of external irqs.
> >>> Constraints on the array size and/or entry values?
> >> The hardware's support for external IRQs may differ, which is why a u32
> >> array is utilized. This choice is based on the fact that IRQ numbers are
> >> commonly expressed as integers, and a 32-bit unsigned integer provides a
> >> standardized size capable of representing a broad range of numbers. This
> >> size is more than adequate for accommodating IRQ numbering.
> > I don't think Rob was questioning your use of u32s, but rather the fact
> > that you do not limit the values at all nor the number of values.
> 
> The peripheral identification defined at the product level corresponds 
> to the interrupt source number.
> 
> SoC           External Interrupts    Peripheral ID
> AT91RM9200    - IRQ0–IRQ6            25 - 31
> SAMA5D2       - IRQ0–IRQn            49
> SAMA5D3       - IRQ0–IRQn            47
> SAMA5D4       - IRQ0–IRQn            56
> SAM9x60       - IRQ0–IRQn            31
> 
> To reflect these constraints in bindings, I intend to make the following 
> changes.
> 
>    atmel,external-irqs:
>      $ref: /schemas/types.yaml#/definitions/uint32-array
>      description: u32 array of external irqs.

>      if:
>        properties:
>          compatible:
>            contains:
>              const: atmel,at91rm9200-aic
>      then:
>        minItems: 1
>        maxItems: 7
>      else:
>        minItems: 1
>        maxItems: 1

Just to point out, that if this is not psuedocode, the syntax here is
not quite right. It should be:

allOf:
- if:
    properties:
      compatible:
        contains:
          const: atmel,at91rm9200-aic
  then:
    properties:
      atmel,external-irqs:
        minItems: 1
        maxItems: 7
  else:
    properties:
      atmel,external-irqs:
        minItems: 1
        maxItems: 1

But you can simply this further by applying minItems: 1 & maxitems: 7
to the property directly and just setting maxItems: 1 when the
compatible is not atmel,at91rm9200-aic.

There should be plenty of examples in-tree for you to copy this sort of
thing from - clock-names is a property you often see this used for.

Cheers,
Conor.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ