Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1055311rwd; Thu, 8 Jun 2023 11:21:00 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6D2iiHL8bgH37c6tPm7A3PAcZrzaoHqHiQmAKtAmhH0K8sIEyenfU0OG2QA8UPgYhgz6KK X-Received: by 2002:a17:903:22ce:b0:1b2:4e00:a3a9 with SMTP id y14-20020a17090322ce00b001b24e00a3a9mr4283470plg.41.1686248460132; Thu, 08 Jun 2023 11:21:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686248460; cv=none; d=google.com; s=arc-20160816; b=UPQRaW7ZSnwdC5fi69maZP6hbDbGz49R3q6M5ZTUPFgmkAazCWnwOqBHEuC9n9zFBm 2bn6C29QChc25FJ/jhmMlmqj/81g7TNA/+QS48ji9Q8rXjNpXZBMqdjybf3cyJI91Xnv SO1FA3E9ewBsipS0cz63DPoOuFjIo7T9UVv6XYqTavdybK0Lqkm9MIIMJ+s3HvAG/5pT ZlUKBgakxFIBokM61RpE934t4QAxFq/rzjyOoL5GUmL6Mku+EEsGfCLdg5hf9kqgGR8W EeCFQ3SyM/vahL0mmQz+E/P2qOxMEaEVjRleI4ayR4PNGim3EbbdnT1KVPdLSLVyddZs zvUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=mp0FR39SuxL+WmMJgcXG5sjnksxhUCnzwFMUs+zD8p8=; b=nOsu09IXg5hDeE/naXg9wl6/EpBKtbSZWjH1ynCzlNAx0JpIbA7g0Bm790WnbhUmRr GICGHEd2SpApG10kivWOfHiX3kL/NIkGXinIXozc+Kq4FZfeX0v0l6QCX4+qx+Y6G9/n JzcwdS3xBe+VxQ0e12RlYM+uWc3sbNub2eFsYLFbM0qOPFJsY2cp3cMiD65SebfCAx9q YFqQLrGJ1iCXLACGDmzy+21UbGvfJozXzht0ZuxOrqQGzvHIpK0prMR/dvOOTvDELB2z WbxzIVA6jdld/cQEiXk2f800it2ejHg/NYSMkzOUP+mC//GOO5QPn93+RmaaHKD1w4yN QwrQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ku4-20020a170903288400b001b03213eb84si1345590plb.516.2023.06.08.11.20.43; Thu, 08 Jun 2023 11:21:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233160AbjFHRnc (ORCPT + 99 others); Thu, 8 Jun 2023 13:43:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229593AbjFHRnb (ORCPT ); Thu, 8 Jun 2023 13:43:31 -0400 Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC08E2D41; Thu, 8 Jun 2023 10:43:29 -0700 (PDT) Received: by mail-il1-f181.google.com with SMTP id e9e14a558f8ab-33b22221da6so4112905ab.1; Thu, 08 Jun 2023 10:43:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686246209; x=1688838209; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mp0FR39SuxL+WmMJgcXG5sjnksxhUCnzwFMUs+zD8p8=; b=euPadxOthIRRRAqqZex4rM9inqIjP4uXP+77YZDZmYMnKdJtotck4j2KOvnUsDvfIh ZTmGvuozy8Frp+T8WxP2gA6IrO6UQetyoo3Pdiq/3CeRnUCb5yWEa1GoD0Njtr+TS/4a ff6iAQaInl67LgcmGM3NZaE9g1p490WhmDHmD+ERK3hj10qkIeSKMss+2VS3G2j9j+4L s+gYQmyhNLN/AZWbrLnKkpTR6UVKLKJGAgcNoWMzsGZHhDr9fQlYGsPm1r9kwqgQrzw5 yUbdj4W2aRikbFkYLdQQuyZ0n+oSQD0smfwWAKLvunmtXTh39j7kH85XsjdZHfca4L/X ncrg== X-Gm-Message-State: AC+VfDxXknXLBEjYxzAC68ofnsWQmrwcGe3ciEkO1iXObjp529A59186 9bFBrEHaCU/vGoth1DfzOw== X-Received: by 2002:a92:c647:0:b0:33e:7c8d:3de with SMTP id 7-20020a92c647000000b0033e7c8d03demr1724662ill.32.1686246208868; Thu, 08 Jun 2023 10:43:28 -0700 (PDT) Received: from robh_at_kernel.org ([64.188.179.250]) by smtp.gmail.com with ESMTPSA id j12-20020a02cb0c000000b0041d859c5721sm410050jap.64.2023.06.08.10.43.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jun 2023 10:43:28 -0700 (PDT) Received: (nullmailer pid 3079477 invoked by uid 1000); Thu, 08 Jun 2023 17:43:26 -0000 Date: Thu, 8 Jun 2023 11:43:26 -0600 From: Rob Herring To: Etienne Carriere Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, op-tee@lists.trustedfirmware.org, Alexandre Belloni , Ulf Hansson , Jonathan Cameron , Jens Wiklander , Krzysztof Kozlowski , Marc Zyngier , Sumit Garg , Pascal Paillet Subject: Re: [PATCH v5 1/2] dt-bindings: arm: optee: add interrupt controller properties Message-ID: <20230608174326.GA2791381-robh@kernel.org> References: <20230506073235.2770292-1-etienne.carriere@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230506073235.2770292-1-etienne.carriere@linaro.org> X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +Sudeep, again... Sudeep, you may want to look at v2 again. On Sat, May 06, 2023 at 09:32:34AM +0200, Etienne Carriere wrote: > Adds an optional interrupt controller property to optee firmware node > in the DT bindings. Optee driver may embeds an irqchip exposing > OP-TEE interrupt events notified by the TEE world. Optee registers up optee, Optee, or OP-TEE? > to 1 interrupt controller and identifies each line with a line > number from 0 to UINT16_MAX. > > The identifiers and meaning of the interrupt line number are specific > to the platform and shall be found in the OP-TEE platform documentation. Why can't you standardize the interrupt numbering for standard events like SCMI? I think there's still concern as to why this can't all be discoverable. The Optee driver should know or discover from Optee that it is an interrupt controller and can register itself as such. Likewise, the SCMI driver knows for scmi-optee, the interrupt comes from the Optee node. It can find that node (by compatible) and then find the irqchip/domain provider for that node. OTOH, SCMI already supports interrupts in the binding, so this isn't too big of a deal. I'm more concerned that once you have Optee interrupts, then you are going to want a node for every Optee sub-function with an interrupt. Then we're back to the very first Optee binding with a child node for every sub-function. Using it for gpio-keys as you did in the first version for example. If Sudeep is okay with this from an SCMI perspective and Marc is from an irqchip perspective, then I'm okay with it too. > In the example shown in optee DT binding documentation, the platform SCMI > device controlled by Linux scmi driver uses optee interrupt irq 5 as > signal to trigger processing of an asynchronous incoming SCMI message > in the scope of a CPU DVFS control. A platform can have several SCMI > channels driven this way. Optee irqs also permit small embedded devices > to share e.g. a gpio expander, a group of wakeup sources, etc... between > OP-TEE world (for sensitive services) and Linux world (for non-sensitive > services). The physical controller is driven from the TEE which exposes > some controls to Linux kernel. > > Cc: Jens Wiklander > Cc: Krzysztof Kozlowski > Cc: Marc Zyngier > Cc: Rob Herring > Cc: Sumit Garg > Co-developed-by: Pascal Paillet > Signed-off-by: Pascal Paillet > Signed-off-by: Etienne Carriere > --- > Changes since v4: > - Removed empty line between Cc: tags and S-o-b tags. > > No changes since v3 > > Changes since v2: > - Added a sentence on optee irq line number values and meaning, in > DT binding doc and commit message. > - Updated example in DT binding doc from comment, fixed misplaced > interrupt-parent property and removed gic and sram shm nodes. > > Changes since v1: > - Added a description to #interrupt-cells property. > - Changed of example. Linux wakeup event was subject to discussion and > i don't know much about input events in Linux. So move to SCMI. > In the example, an SCMI server in OP-TEE world raises optee irq 5 > so that Linux scmi optee channel &scmi_cpu_dvfs pushed in the incoming > SCMI message in the scmi device for liekly later processing in threaded > context. The example includes all parties: optee, scmi, sram, gic. > - Obviously rephrased the commit message. > --- > .../arm/firmware/linaro,optee-tz.yaml | 38 +++++++++++++++++++ > 1 file changed, 38 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml > index 5d033570b57b..9d9a797a6b2f 100644 > --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml > +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml > @@ -41,6 +41,16 @@ properties: > HVC #0, register assignments > register assignments are specified in drivers/tee/optee/optee_smc.h > > + interrupt-controller: true > + > + "#interrupt-cells": > + const: 1 > + description: | > + OP-TEE exposes irq for irp chip controllers from OP-TEE world. Each > + irq is assigned a single line number identifier used as first argument. > + Line number identifiers and their meaning shall be found in the OP-TEE > + firmware platform documentation. > + > required: > - compatible > - method > @@ -65,3 +75,31 @@ examples: > method = "hvc"; > }; > }; > + > + - | > + #include > + firmware { > + optee: optee { > + compatible = "linaro,optee-tz"; > + method = "smc"; > + interrupt-parent = <&gic>; > + interrupts = ; > + interrupt-controller; > + #interrupt-cells = <1>; > + }; > + > + scmi { > + compatible = "linaro,scmi-optee"; > + linaro,optee-channel-id = <0>; > + shmem = <&scmi_shm_tx>, <&scmi_shm_rx>; > + interrupts-extended = <&optee 5>; > + interrupt-names = "a2p"; > + #address-cells = <1>; > + #size-cells = <0>; > + > + scmi_cpu_dvfs: protocol@13 { > + reg = <0x13>; > + #clock-cells = <1>; > + }; > + }; > + }; > -- > 2.25.1 >