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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,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 9CE02C07E95 for ; Tue, 13 Jul 2021 08:56:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 82E7A600EF for ; Tue, 13 Jul 2021 08:56:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234869AbhGMI7D (ORCPT ); Tue, 13 Jul 2021 04:59:03 -0400 Received: from foss.arm.com ([217.140.110.172]:38752 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234796AbhGMI7D (ORCPT ); Tue, 13 Jul 2021 04:59:03 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 113F431B; Tue, 13 Jul 2021 01:56:13 -0700 (PDT) Received: from bogus (unknown [10.57.79.213]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EF0CE3F7D8; Tue, 13 Jul 2021 01:56:10 -0700 (PDT) Date: Tue, 13 Jul 2021 09:55:08 +0100 From: Sudeep Holla To: Geert Uytterhoeven Cc: "Lad, Prabhakar" , Lad Prabhakar , Sudeep Holla , Rob Herring , Magnus Damm , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux Kernel Mailing List , Linux-Renesas , Biju Das Subject: Re: [PATCH] arm64: dts: renesas: r9a07g044: Add missing GICv3 node properties Message-ID: <20210713085508.nq6473icf5gt3nm5@bogus> References: <20210611152108.6785-1-prabhakar.mahadev-lad.rj@bp.renesas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org On Tue, Jul 13, 2021 at 10:30:36AM +0200, Geert Uytterhoeven wrote: > Hi Prabhakar, > > On Tue, Jul 13, 2021 at 10:22 AM Lad, Prabhakar > wrote: > > On Tue, Jul 13, 2021 at 9:08 AM Geert Uytterhoeven wrote: > > > On Mon, Jun 14, 2021 at 2:48 PM Geert Uytterhoeven wrote: > > > > On Fri, Jun 11, 2021 at 5:21 PM Lad Prabhakar > > > > wrote: > > > > > Add the below missing properties into GIC node, > > > > > - clocks > > > > > - clock-names > > > > > - power-domains > > > > > - resets > > > > > > > > > > Signed-off-by: Lad Prabhakar > > > > > Reviewed-by: Biju Das > > > > > > > > Reviewed-by: Geert Uytterhoeven > > > > > > > > Queueing pending on[1]. > > > > > > > > > [1] https://lore.kernel.org/linux-devicetree/ > > > > > 20210609155108.16590-1-prabhakar.mahadev-lad.rj@bp.renesas.com/ > > > > > > The dependency has been accepted, but this patch needs a respin > > > for the changed clocks. > > > > > Thank you for pointing this out. wrt resets the GIC has two signals > > (which I learnt lately when the dependency path was accepted). Earlier > > discussion in irc with Sudeep pointed out that there wouldn't be any > > use case of having GIC resets in DTSI, so either we drop the resets > > property in DT binding doc or correct it. > > > > Let me know your thoughts on this and how we proceed further. > > DT Rule #1: DT describes hardware not software policy. > Completely agreed, no disagreement 😄. > And a possible use case: the RT CPU core may want to reset the AP GIC. > I didn't want to add new bindings without details on the implementation to avoid possible issues with backward compatibility as this was not thought through completely and correctly before it was added. OK, now let us discuss your use-case: *RT CPU wants to reset AP GIC* 1. Will it just reset AP GIC or will it request the AP reset as a whole ? I am not sure if we can handle former, if you think otherwise what is the reset notification mechanism ? 2. Will that bypass secure world/PSCI ? Again more details on this would be helpful to visualise the entire use-case end-to-end better. By GIC reset, I am assuming it will be complete GIC reset including it's CPU interface. I don't think we can reset GIC without actual CPU reset. Even if we get some notification magically to the CPU that its GIC alone needs to be reset, it needs to safely higher exceptions to get its GIC CPU interface reprogrammed to correct (saved) values before OS can reprogram the NS world values. All these seems overall complicated and may be unnecessary. -- Regards, Sudeep