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: <Yes6NFgUmcIcc5mm@robh.at.kernel.org>
Date:   Fri, 21 Jan 2022 16:56:52 -0600
From:   Rob Herring <robh@...nel.org>
To:     Sander Vanheule <sander@...nheule.net>
Cc:     linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Birger Koblitz <mail@...ger-koblitz.de>,
        Bert Vermeulen <bert@...t.com>, John Crispin <john@...ozen.org>
Subject: Re: [PATCH v3 4/6] dt-bindings: interrupt-controller:
 realtek,rtl-intc: require parents

On Sun, Jan 09, 2022 at 03:54:35PM +0100, Sander Vanheule wrote:
> The interrupt router has 32 inputs and up to 15 outputs, and the way
> these are mapped to each other is runtime configurable. The outputs of
> this interrupt router on the other hand, are connected to a fixed set of
> parent interrupts. This means that "interrupt-map" is inappropriate, and
> rather a list of parent interrupts should be specified.

I'm not sure why interrupt-map is not appropriate. It is not appropriate 
if you have to touch the interrupt router h/w in servicing the 
interrupts. If you just need one time configuration of the mapping, then 
it should be fine to use I think.

> Two-part compatibles are introduced to be able to require "interrupts"
> for new devicetrees. The relevant descriptions are extended or added to
> more clearly describe the inputs and outputs of this router.  The old
> compatible, "interrupt-map" and "#address-cells", is deprecated.
> Interrupt specifiers for new compatibles will require two cells, to
> indicate the output selection.
> 
> To prevent spurious changes when more SoCs are added, "allOf" is used
> with one "if", and the compatible enum only has one item.
> 
> The example is updated to provide a correct example for RTL8380 SoCs.
> 
> Signed-off-by: Sander Vanheule <sander@...nheule.net>
> ---
>  .../realtek,rtl-intc.yaml                     | 78 ++++++++++++++-----
>  1 file changed, 58 insertions(+), 20 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml
> index 9e76fff20323..aab8d44010af 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml
> @@ -6,6 +6,10 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
>  
>  title: Realtek RTL SoC interrupt controller devicetree bindings
>  
> +description:
> +  Interrupt router for Realtek MIPS SoCs, allowing each SoC interrupt to be
> +  routed to one parent interrupt, or left disconnected.
> +
>  maintainers:
>    - Birger Koblitz <mail@...ger-koblitz.de>
>    - Bert Vermeulen <bert@...t.com>
> @@ -13,45 +17,79 @@ maintainers:
>  
>  properties:
>    compatible:
> -    const: realtek,rtl-intc
> +    oneOf:
> +      - items:
> +          - enum:
> +              - realtek,rtl8380-intc
> +          - const: realtek,rtl-intc
> +      - const: realtek,rtl-intc
> +        deprecated: true
>  
> -  "#interrupt-cells":
> -    const: 1
> +  "#interrupt-cells": true
>  
>    reg:
>      maxItems: 1
>  
>    interrupts:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 15
> +    description:
> +      List of parent interrupts, in the order that they are connected to this
> +      interrupt router's outputs.
>  
>    interrupt-controller: true
>  
> -  "#address-cells":
> -    const: 0
> -
> -  interrupt-map:
> -    description: Describes mapping from SoC interrupts to CPU interrupts
> -
>  required:
>    - compatible
>    - reg
>    - "#interrupt-cells"
>    - interrupt-controller
> -  - "#address-cells"
> -  - interrupt-map
> +
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          const: realtek,rtl-intc
> +    then:
> +      properties:
> +        "#interrupt-cells":
> +          const: 1
> +
> +        "#address-cells":
> +          const: 0
> +
> +        interrupt-map: true
> +      required:
> +        - "#address-cells"
> +        - interrupt-map
> +    else:
> +      properties:
> +        "#interrupt-cells":
> +          description:
> +            Two cells to specify which line to connect to, and which output it should
> +            be routed to. Both cells use a zero-based index.

Picking the index picks the priority? Which is higher priority?


> +          const: 2
> +      required:
> +        - interrupts
>  
>  additionalProperties: false
>  
>  examples:
>    - |
>      intc: interrupt-controller@...0 {
> -      compatible = "realtek,rtl-intc";
> -      #interrupt-cells = <1>;
> +      compatible = "realtek,rtl8380-intc", "realtek,rtl-intc";
> +      #interrupt-cells = <2>;
>        interrupt-controller;
> -      reg = <0x3000 0x20>;
> -      #address-cells = <0>;
> -      interrupt-map =
> -              <31 &cpuintc 2>,
> -              <30 &cpuintc 1>,
> -              <29 &cpuintc 5>;
> +      reg = <0x3000 0x18>;
> +
> +      interrupt-parent = <&cpuintc>;
> +      interrupts = <2>, <3>, <4>, <5>, <6>;
> +    };
> +
> +    irq-consumer@0 {
> +      reg = <0 4>;
> +      interrupt-parent = <&intc>;
> +      interrupts =
> +        <19 3>, /* IRQ 19, routed to output 3 (cpuintc 5) */
> +        <18 4>; /* IRQ 18, routed to output 4 (cpuintc 6) */
>      };
> -- 
> 2.33.1
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ