Re: [PATCH 2/2] irqchip/econet-en751221: Support MIPS 34Kc VEIC mode

[Thomas Gleixner <tglx@kernel.org>]

On Sat, Apr 25 2026 at 12:35, Caleb James DeLisle wrote:
> This of course subverts the traditional intc hierarchy, and on the
> 1004Kc the interrupt controller is standardized (IRQ_GIC) so it can be
> reasonably considered part of the CPU itself - and tighter coupling
> between IRQ_GIC and arch/mips/* is tolerable. However on the 34Kc
> the intc is defined by each SoC vendor, so we have the task of making a

s/so we have.../so it's required to have a modular driver/

or something like that. Please use passive and factual voice for change logs.

> reasonably modular driver - but for a device which in fact ends up
> taking over the entire interrupt system.
>
> We let the DT describe which IRQs which come from the CPU and should
> be

s/we let/Let/

> routed back and handled by the CPU intc. These particularly include the
> two IPI interrupts which would otherwise necessitate duplication of all
> the IPI supporting infrastructure from the CPU intc.
>  /**
>   * @membase: Base address of the interrupt controller registers
> + * @domain: The irq_domain for direct dispatch
> + * @ipi_domain: The irq_domain for inter-process dispatch

Can you please make that tabular for easier parsing?

>   * @interrupt_shadows: Array of all interrupts, for each value,
>  
> +/* When in VEIC mode, the CPU jumps to a handler in the vector table.

This is invalid multiline comment style.

https://www.kernel.org/doc/html/latest/process/maintainer-tip.html

> + * The only way to know which interrupt is being triggered is from the vector table offset that
> + * has been jumped to. Reading REG_PENDING(0|1) will tell you which interrupts are currently

> +		if (receive >= IRQ_COUNT) {
> +			pr_err("%pOF: Entry %d:%d in %s (%u) %s\n",
> +			       node, i, 0, field, receive, "is out of bounds");

Yuck. What's the point of the last string constant argument? Just stick
it into the format string. All over the place.

Other than those nits, this look like a reasonable solution for a
completely unreasonable hardware design.

Thanks,

        tglx