All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: op-tee@lists.trustedfirmware.org
Subject: Re: [PATCH 2/3] dt-bindings: arm: optee: add interrupt controller properties
Date: Fri, 13 Jan 2023 14:42:31 -0600	[thread overview]
Message-ID: <20230113204231.GA2873887-robh@kernel.org> (raw)
In-Reply-To: <20230112145424.3791276-3-etienne.carriere@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

On Thu, Jan 12, 2023 at 03:54:23PM +0100, Etienne Carriere wrote:
> Adds optional interrupt controller properties used when OP-TEE generates
> interrupt events optee driver shall notified to its registered
> interrupt consumer. The example shows how OP-TEE can trigger a wakeup
> interrupt event consumed by a gpio-keys compatible device.

Why do we need this in DT? It's not a GPIO key, but an abuse of the 
binding. It looks like unnecessary abstraction to me.


> 
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> ---
>  .../arm/firmware/linaro,optee-tz.yaml         | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> index d4dc0749f9fd..42874ca21b7e 100644
> --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> @@ -40,6 +40,11 @@ properties:
>        HVC #0, register assignments
>        register assignments are specified in drivers/tee/optee/optee_smc.h
>  
> +  interrupt-controller: true
> +
> +  "#interrupt-cells":
> +    const: 1
> +
>  required:
>    - compatible
>    - method
> @@ -48,12 +53,24 @@ additionalProperties: false
>  
>  examples:
>    - |
> +    #include <dt-bindings/input/input.h>
>      #include <dt-bindings/interrupt-controller/arm-gic.h>
>      firmware  {
> -        optee  {
> +        optee: optee {
>              compatible = "linaro,optee-tz";
>              method = "smc";
>              interrupts = <GIC_SPI 187 IRQ_TYPE_EDGE_RISING>;
> +            interrupt-controller;
> +            #interrupt-cells = <1>;
> +        };
> +    };
> +
> +    wake_up {
> +        compatible = "gpio-keys";
> +
> +        button {
> +            linux,code = <KEY_WAKEUP>;
> +            interrupts-extended = <&optee 0>;

In the end, you just need optee IRQ #0 to generate KEY_WAKEUP. Does 
either the optee interrupt number or the key code need to be 
configurable? If so, why? Why isn't #0 just wakeup and the driver can 
send KEY_WAKEUP?

DT is for non-discoverable hardware that we can't fix. Why repeat that 
for software interfaces to firmware?

Rob

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Etienne Carriere <etienne.carriere@linaro.org>
Cc: linux-kernel@vger.kernel.org,
	Jens Wiklander <jens.wiklander@linaro.org>,
	Sumit Garg <sumit.garg@linaro.org>, Marc Zyngier <maz@kernel.org>,
	op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Subject: Re: [PATCH 2/3] dt-bindings: arm: optee: add interrupt controller properties
Date: Fri, 13 Jan 2023 14:42:31 -0600	[thread overview]
Message-ID: <20230113204231.GA2873887-robh@kernel.org> (raw)
In-Reply-To: <20230112145424.3791276-3-etienne.carriere@linaro.org>

On Thu, Jan 12, 2023 at 03:54:23PM +0100, Etienne Carriere wrote:
> Adds optional interrupt controller properties used when OP-TEE generates
> interrupt events optee driver shall notified to its registered
> interrupt consumer. The example shows how OP-TEE can trigger a wakeup
> interrupt event consumed by a gpio-keys compatible device.

Why do we need this in DT? It's not a GPIO key, but an abuse of the 
binding. It looks like unnecessary abstraction to me.


> 
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> ---
>  .../arm/firmware/linaro,optee-tz.yaml         | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> index d4dc0749f9fd..42874ca21b7e 100644
> --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> @@ -40,6 +40,11 @@ properties:
>        HVC #0, register assignments
>        register assignments are specified in drivers/tee/optee/optee_smc.h
>  
> +  interrupt-controller: true
> +
> +  "#interrupt-cells":
> +    const: 1
> +
>  required:
>    - compatible
>    - method
> @@ -48,12 +53,24 @@ additionalProperties: false
>  
>  examples:
>    - |
> +    #include <dt-bindings/input/input.h>
>      #include <dt-bindings/interrupt-controller/arm-gic.h>
>      firmware  {
> -        optee  {
> +        optee: optee {
>              compatible = "linaro,optee-tz";
>              method = "smc";
>              interrupts = <GIC_SPI 187 IRQ_TYPE_EDGE_RISING>;
> +            interrupt-controller;
> +            #interrupt-cells = <1>;
> +        };
> +    };
> +
> +    wake_up {
> +        compatible = "gpio-keys";
> +
> +        button {
> +            linux,code = <KEY_WAKEUP>;
> +            interrupts-extended = <&optee 0>;

In the end, you just need optee IRQ #0 to generate KEY_WAKEUP. Does 
either the optee interrupt number or the key code need to be 
configurable? If so, why? Why isn't #0 just wakeup and the driver can 
send KEY_WAKEUP?

DT is for non-discoverable hardware that we can't fix. Why repeat that 
for software interfaces to firmware?

Rob

  reply	other threads:[~2023-01-13 20:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-12 14:54 [PATCH 0/3] optee: async notif with PPI + interrupt provider Etienne Carriere
2023-01-12 14:54 ` Etienne Carriere
2023-01-12 14:54 ` [PATCH 1/3] optee: add per cpu asynchronous notification Etienne Carriere
2023-01-12 14:54   ` Etienne Carriere
2023-01-17  4:56   ` kernel test robot
2023-01-17  4:56     ` kernel test robot
2023-01-12 14:54 ` [PATCH 2/3] dt-bindings: arm: optee: add interrupt controller properties Etienne Carriere
2023-01-12 14:54   ` Etienne Carriere
2023-01-13 20:42   ` Rob Herring [this message]
2023-01-13 20:42     ` Rob Herring
2023-01-17  2:19     ` Etienne Carriere
2023-01-17  2:19       ` Etienne Carriere
2023-01-12 14:54 ` [PATCH 3/3] optee core: add irq chip using optee async notification Etienne Carriere
2023-01-12 14:54   ` Etienne Carriere
2023-01-13  9:22   ` Marc Zyngier
2023-01-13  9:22     ` Marc Zyngier
2023-01-13 15:27     ` Etienne Carriere
2023-01-13 15:27       ` Etienne Carriere
     [not found] < <CAN5uoS-Q5ePtNcJ2-8BBV+rxUK6xcbU1ywtcRfYf=sRbWShNpg@mail.gmail.com>
2023-01-15 10:13 ` Marc Zyngier
2023-01-15 10:13   ` Marc Zyngier
2023-01-17  1:50   ` Etienne Carriere
2023-01-17  1:50     ` Etienne Carriere

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230113204231.GA2873887-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=op-tee@lists.trustedfirmware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.