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 <sudeep.holla@xxxxxxx> 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
