Re: [PATCH] arm64: dts: renesas: r9a07g044: Add missing GICv3 node properties

Hi Sudeep,

On Tue, Jul 13, 2021 at 10:56 AM Sudeep Holla [off-list ref] wrote:

On Tue, Jul 13, 2021 at 10:30:36AM +0200, Geert Uytterhoeven wrote:

quoted

On Tue, Jul 13, 2021 at 10:22 AM Lad, Prabhakar
[off-list ref] wrote:

quoted

On Tue, Jul 13, 2021 at 9:08 AM Geert Uytterhoeven [off-list ref] wrote:

quoted

On Mon, Jun 14, 2021 at 2:48 PM Geert Uytterhoeven [off-list ref] wrote:

quoted

On Fri, Jun 11, 2021 at 5:21 PM Lad Prabhakar
[off-list ref] wrote:

quoted

Add the below missing properties into GIC node,
- clocks
- clock-names
- power-domains
- resets

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Queueing pending on[1].

quoted

[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 .

Good ;-)

quoted

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@linux-m68k.org

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