Hi Sudeep, On Tue, Jul 13, 2021 at 10:56 AM Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > On Tue, Jul 13, 2021 at 10:30:36AM +0200, Geert Uytterhoeven wrote: > > On Tue, Jul 13, 2021 at 10:22 AM Lad, Prabhakar > > <prabhakar.csengg@xxxxxxxxx> wrote: > > > On Tue, Jul 13, 2021 at 9:08 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > > > On Mon, Jun 14, 2021 at 2:48 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > > > > On Fri, Jun 11, 2021 at 5:21 PM Lad Prabhakar > > > > > <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> wrote: > > > > > > Add the below missing properties into GIC node, > > > > > > - clocks > > > > > > - clock-names > > > > > > - power-domains > > > > > > - resets > > > > > > > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > > > > > > Reviewed-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx> > > > > > > > > > > Reviewed-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> > > > > > > > > > > Queueing pending on[1]. > > > > > > > > > > > [1] https://lore.kernel.org/linux-devicetree/ > > > > > > 20210609155108.16590-1-prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx/ > > > > > > > > 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 . Good ;-) > > 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, ... 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
