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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 4B6F4C07E95 for ; Tue, 13 Jul 2021 09:16:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2B860613AE for ; Tue, 13 Jul 2021 09:16:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234735AbhGMJTA (ORCPT ); Tue, 13 Jul 2021 05:19:00 -0400 Received: from foss.arm.com ([217.140.110.172]:39018 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234397AbhGMJS7 (ORCPT ); Tue, 13 Jul 2021 05:18:59 -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 F257E31B; Tue, 13 Jul 2021 02:16:09 -0700 (PDT) Received: from bogus (unknown [10.57.79.213]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 81C003F7D8; Tue, 13 Jul 2021 02:16:08 -0700 (PDT) Date: Tue, 13 Jul 2021 10:15:02 +0100 From: Sudeep Holla To: Geert Uytterhoeven Cc: "Lad, Prabhakar" , Lad Prabhakar , Rob Herring , Sudeep Holla , 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: <20210713091108.7nx2d2fxolx2wrg5@bogus> References: <20210611152108.6785-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20210713085508.nq6473icf5gt3nm5@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org On Tue, Jul 13, 2021 at 11:04:09AM +0200, Geert Uytterhoeven wrote: > Hi Sudeep, > > On Tue, Jul 13, 2021 at 10:56 AM Sudeep Holla wrote: > > On Tue, Jul 13, 2021 at 10:30:36AM +0200, Geert Uytterhoeven wrote: [...] > > > 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. > > Probably both. Might make sense to reset on wake-up, after having disabled > clocks and powered down the AP CPU, AP GIC, ... > /me confused. If this is arm64 platform, then you have to use *PSCI* and I expect the reset to be done as part of CPU wake-up in PSCI firmware. > If that bypasses PSCI: well, if the unsecure software can do it, it > means the hardware is not secure. Or at least Linux has to be trusted. > No, if the system has PSCI, then you simply can't bypass that for GIC reset. Or at-least I am failing to understand the complete flow of that. -- Regards, Sudeep