Re: [PATCH v6 3/6] irqchip: RISC-V per-HART local interrupt controller driver

From: Marc Zyngier
Date: Sun May 31 2020 - 05:33:47 EST


On 2020-05-31 06:36, Anup Patel wrote:
On Sat, May 30, 2020 at 5:31 PM Marc Zyngier <maz@xxxxxxxxxx> wrote:

[...]

> plic_set_threshold(handler, PLIC_DISABLE_THRESHOLD);

Why do you need to both disable the interrupt *and* change the priority
threshold? It seems to be that one of them should be enough, but my
kno9wledge of the PLIC is limited. In any case, this would deserve a
comment.

Okay, I will test and remove "disable the interrupt" part from plic_dying_cpu().

Be careful, as interrupt enabling/disabling is refcounted in order
to allow nesting. If you only enable on CPU_ON and not disable
on CPU_OFF, you will end-up with a depth that only increases,
up to the point where you hit the roof (it will take a while though).

I would keep the enable/disable as is, and drop the priority
setting from the CPU_OFF path.

> return 0;
> @@ -260,7 +266,11 @@ static int plic_starting_cpu(unsigned int cpu)
> {
> struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
>
> - csr_set(CSR_IE, IE_EIE);
> + if (plic_parent_irq)
> + enable_percpu_irq(plic_parent_irq,
> + irq_get_trigger_type(plic_parent_irq));
> + else
> + pr_warn("cpu%d: parent irq not available\n");

What does it mean to carry on if the interrupt cannot be signaled?
Shouldn't you error out instead, and leave the CPU dead?

The CPU is not dead if we cannot enable RISC-V INTC external
interrupt because the Timer and IPIs interrupts are always through
RISC-V INTC. The PLIC external interrupt not present for a CPU
only means that that CPU cannot receive peripherial interrupts.

On a sane RISC-V system, if PLIC is present then all CPUs should
be able to get RISC-V INTC external interrupt. Base on this rationale,
I have put a warning for plic_parent_irq == 0.

Fair enough.

M.
--
Jazz is not dead. It just smells funny...