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 A1E2AC11F67 for ; Tue, 13 Jul 2021 10:25:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 88A5060FF0 for ; Tue, 13 Jul 2021 10:25:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235519AbhGMK16 (ORCPT ); Tue, 13 Jul 2021 06:27:58 -0400 Received: from foss.arm.com ([217.140.110.172]:40148 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235143AbhGMK15 (ORCPT ); Tue, 13 Jul 2021 06:27:57 -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 0F9726D; Tue, 13 Jul 2021 03:25:07 -0700 (PDT) Received: from bogus (unknown [10.57.79.213]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8EBF83F7D8; Tue, 13 Jul 2021 03:25:04 -0700 (PDT) Date: Tue, 13 Jul 2021 11:23:53 +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: <20210713102326.kc56a4yqhkbv3ymm@bogus> References: <20210611152108.6785-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20210713085508.nq6473icf5gt3nm5@bogus> <20210713091108.7nx2d2fxolx2wrg5@bogus> 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-kernel@vger.kernel.org On Tue, Jul 13, 2021 at 11:24:24AM +0200, Geert Uytterhoeven wrote: > Hi Sudeep, > > On Tue, Jul 13, 2021 at 11:16 AM Sudeep Holla wrote: > > On Tue, Jul 13, 2021 at 11:04:09AM +0200, Geert Uytterhoeven wrote: [...] > > > > > > 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. > > DT Rule #1: DT describes hardware not software policy. > As mentioned before I agree on that. But I assume you too agree that not all bits and pieces of hardware are represented in DT. Only ones that are essential for any software to understand the hardware and make it work. So my opinion is that this GIC reset information is implicit like many other hardware information. > The fact that _Linux_ must use PSCI is a (unfortunate) software policy. > What about other OSes, or bare-metal software? > Disagree. PSCI is OS agnostic and _Linux_ is not the sole user. Do you have examples of other OS that deploy alternate to PSCI ? Or bare-metal that uses DT ? Again if there is a use-case, you need to spell out details on when this can be used and where it can't be of much use(of-course with the mention of Linux). There are complaints that DT bindings are too Linux specific, so please pull in the other OS folks or other users so that we get details on use-cases. Based on your argument we should have loads of other information in DT on CPU or CPU peripherals for example even if PSCI hides them for OS. Do we really want to get down that path ? I agree PSCI is software policy but definitely fortunate, helped prevent lot of non-sense in OS 😉. > > > 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. > > PSCI can only prevent other software from bypassing GIC reset if PSCI > programs the hardware to prevent access to the GIC reset (if possible > at all). > It is not matter of preventing, it is matter of what we can support architecturally and sanely. While I agree with non-Linux use-case, we can't support this in Linux. -- Regards, Sudeep