From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CEDDC433DB for ; Tue, 9 Mar 2021 16:13:10 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D8B4F650BB for ; Tue, 9 Mar 2021 16:13:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8B4F650BB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=v4ZSeQSu+kWJPjqikLcDAGmmNqMShvEsxuHmLi3MofI=; b=nG6w4R0u3hBGw/Zyjnw3FqsmB JKN+m+zdncqVKPzLBJV7l9ElL0BMrvDnoOrQa0y0619InSnit81gQFVyf0TAPSEA5XB6H4iDKnEY5 YnhSDbR9DEdU1xYJw6FnnDmF7o3D8LZ+61+dkYvPdYX+I2TJAGNrh4lqz57GfQAQhf7AAaWRaWeWu A3BEpZPaqfbVecBE6xs2o3TL4DXF+iGRReN2ULgHXdvhQ2ZgP6sFJfVFnD8C2VzCrmlVAHj3xszog 4ybhd3Y8kcyFslEr3coHwqh/zTKTUqutPA9o8xHxbpBAQOhNVLAWijwxIq3R0oJX/dYowbGfX6amm CcwC4GWCw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lJexN-0052zO-TU; Tue, 09 Mar 2021 16:11:38 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lJexI-0052y8-82 for linux-arm-kernel@lists.infradead.org; Tue, 09 Mar 2021 16:11:34 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 1FDD96528C for ; Tue, 9 Mar 2021 16:11:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615306289; bh=jP4SlGRYL9z9+eyGPwRsaTLzvGEXcjhnvO8W76wpgNg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZVrTVRlsTUZ6UvAFSqnFRXzFTuQ+RTH+KKVz80hwNJhcVb8oPDqu3VUXPxU08MljE KwQn8X4P+k3aO/P71x48UcI3mUXon9e0sO13vmZTlYMgq5vLgEnwqAFq9sKDfMkxTd mDT80HetJ45/BY6gIZetj74YgC344aL8/8eHU48l2pI2a5a9g64isjQpFurdbGLNpM 1ycmOuKDCP2N2pkLoFejOEAw0aDIBrZeyVy/G/6GwYn4rhVAfdqB5arhHGktPsqT5V PeMh/vzPynAhkBZcSvYJte7w9F2ZVQNfDAeX5D1G++lMklup3F8WUxdNtaqCcjZCBh DYVpOQRq4uP0g== Received: by mail-ej1-f51.google.com with SMTP id e19so29233115ejt.3 for ; Tue, 09 Mar 2021 08:11:29 -0800 (PST) X-Gm-Message-State: AOAM533c8CmGXIgMmtjiNr0zJ3zVkui7WBQDe6PSMxUw3wr27eMXTzZ9 r9ysfho/p5/gLjUr1z7yuee3rN54dm9lRXvz1A== X-Google-Smtp-Source: ABdhPJyUkLV5udpIPwopun4y9FIyMOM7Kb/GLOh2/MhA1kzOLho0N807A6srQjeEqqxkaM/xpiP2WAOCDXgqauEOczc= X-Received: by 2002:a17:906:25c4:: with SMTP id n4mr21228200ejb.359.1615306287477; Tue, 09 Mar 2021 08:11:27 -0800 (PST) MIME-Version: 1.0 References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-7-marcan@marcan.st> <20210308203841.GA2906683@robh.at.kernel.org> <87zgzdqnbs.wl-maz@kernel.org> In-Reply-To: <87zgzdqnbs.wl-maz@kernel.org> From: Rob Herring Date: Tue, 9 Mar 2021 09:11:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFT PATCH v3 06/27] dt-bindings: timer: arm,arch_timer: Add interrupt-names support To: Marc Zyngier Cc: Hector Martin , linux-arm-kernel , Arnd Bergmann , Olof Johansson , Krzysztof Kozlowski , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Will Deacon , Linus Walleij , Mark Rutland , Andy Shevchenko , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , devicetree@vger.kernel.org, "open list:SERIAL DRIVERS" , Linux Doc Mailing List , linux-samsung-soc , "open list:GENERIC INCLUDE/ASM HEADER FILES" , "linux-kernel@vger.kernel.org" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210309_161132_656234_E77720AD X-CRM114-Status: GOOD ( 29.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Mar 8, 2021 at 3:42 PM Marc Zyngier wrote: > > On Mon, 08 Mar 2021 20:38:41 +0000, > Rob Herring wrote: > > > > On Fri, Mar 05, 2021 at 06:38:41AM +0900, Hector Martin wrote: > > > Not all platforms provide the same set of timers/interrupts, and Linux > > > only needs one (plus kvm/guest ones); some platforms are working around > > > this by using dummy fake interrupts. Implementing interrupt-names allows > > > the devicetree to specify an arbitrary set of available interrupts, so > > > the timer code can pick the right one. > > > > > > This also adds the hyp-virt timer/interrupt, which was previously not > > > expressed in the fixed 4-interrupt form. > > > > > > Signed-off-by: Hector Martin > > > --- > > > .../devicetree/bindings/timer/arm,arch_timer.yaml | 14 ++++++++++++++ > > > 1 file changed, 14 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml > > > index 2c75105c1398..ebe9b0bebe41 100644 > > > --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml > > > +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml > > > @@ -34,11 +34,25 @@ properties: > > > - arm,armv8-timer > > > > > > interrupts: > > > + minItems: 1 > > > + maxItems: 5 > > > items: > > > - description: secure timer irq > > > - description: non-secure timer irq > > > - description: virtual timer irq > > > - description: hypervisor timer irq > > > + - description: hypervisor virtual timer irq > > > + > > > + interrupt-names: > > > + minItems: 1 > > > + maxItems: 5 > > > + items: > > > + enum: > > > + - phys-secure > > > + - phys > > > + - virt > > > + - hyp-phys > > > + - hyp-virt > > > > phys-secure and hyp-phys is not very consistent. secure-phys or sec-phys > > instead? > > > > This allows any order which is not ideal (unfortunately json-schema > > doesn't have a way to define order with optional entries in the middle). > > How many possible combinations are there which make sense? If that's a > > reasonable number, I'd rather see them listed out. > > The available of interrupts are a function of the number of security > states, privileged exception levels and architecture revisions, as > described in D11.1.1: > > > - An EL1 physical timer. > - A Non-secure EL2 physical timer. > - An EL3 physical timer. > - An EL1 virtual timer. > - A Non-secure EL2 virtual timer. > - A Secure EL2 virtual timer. > - A Secure EL2 physical timer. > > > * Single security state, EL1 only, ARMv7 & ARMv8.0+ (assumed NS): > - physical, virtual > > * Single security state, EL1 + EL2, ARMv7 & ARMv8.0 (assumed NS) > - physical, virtual, hyp physical > > * Single security state, EL1 + EL2, ARMv8.1+ (assumed NS) > - physical, virtual, hyp physical, hyp virtual > > * Two security states, EL1 + EL3, ARMv7 & ARMv8.0+: > - secure physical, physical, virtual > > * Two security states, EL1 + EL2 + EL3, ARMv7 & ARMv8.0 > - secure physical, physical, virtual, hyp physical > > * Two security states, EL1 + EL2 + EL3, ARMv8.1+ > - secure physical, physical, virtual, hyp physical, hyp virtual > > * Two security states, EL1 + EL2 + S-EL2 + EL3, ARMv8.4+ > - secure physical, physical, virtual, hyp physical, hyp virtual, > secure hyp physical, secure hyp virtual > > Nobody has seen the last combination in the wild (that is, outside of > a SW model). > > I'm really not convinced we want to express this kind of complexity in > the binding (each of the 7 cases), specially given that we don't > encode the underlying HW architecture level or number of exception > levels anywhere, and have ho way to validate such information. Actually, we can simplify this down to 2 cases: oneOf: - minItems: 2 items: - const: phys - const: virt - const: hyp-phys - const: hyp-virt - minItems: 3 items: - const: sec-phys - const: phys - const: virt - const: hyp-phys - const: hyp-virt - const: sec-hyp-phy - const: sec-hyp-virt And that's below my threshold for not worth the complexity. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel