On Mon, 2019-02-11 at 08:50 +0000, Marc Zyngier wrote:

On Mon, 11 Feb 2019 06:35:29 +0000,
Seiya Wang [off-list ref] wrote:

quoted

On Thu, 2019-02-07 at 15:52 +0000, Marc Zyngier wrote:

quoted

On 07/02/2019 15:47, Marc Zyngier wrote:

quoted

On 07/02/2019 15:20, Matthias Brugger wrote:

quoted

On 24/01/2019 09:07, Erin Lo wrote:

quoted

From: Seiya Wang <redacted>

To support partitioned PPIs, 4 interrupt parameters should be valid
for sysirq.

Signed-off-by: Seiya Wang <redacted>
Signed-off-by: Erin Lo <redacted>
---
 drivers/irqchip/irq-mtk-sysirq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c
index 90aaf19..282736a 100644
--- a/drivers/irqchip/irq-mtk-sysirq.c
+++ b/drivers/irqchip/irq-mtk-sysirq.c

@@ -81,7 +81,7 @@ static int mtk_sysirq_domain_translate(struct irq_domain *d,
 				       unsigned int *type)
 {
 	if (is_of_node(fwspec->fwnode)) {
-		if (fwspec->param_count != 3)
+		if (fwspec->param_count != 3 && fwspec->param_count != 4)

Where is this 4th parameter used?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt#n14

Sorry, I fired Send way too early.

What I wanted to add is that it is not clear to me why this change would
be required here, as this driver only supports SPIs. It could be fixed
by just relaxing the binding itself.

Thanks,

	M.

Do you mean that we should change #interrupt-cells back to 3 for sysirq
and remove the 4th parameters of every spi interrupts in mt8183.dtsi
(i.e. 3 parameters for spi, 4 for ppi) such that we can discard this
patch?

It is more subtle than that:

- PPIs must have the affinity parameter in their int-spec (since you
  need that for the PMU)

- SPIs that are directly routed to the GIC must also have the affinity
  parameter (although set to zero).

- SPIs that are routed via the sysirq block (or any other) can use the
  3 parameter variant, as they are not resolved in the context of the
  GIC, but in that of the sysirq.

But in short, yes. You should be able to drop this patch altogether.

quoted

If yes, we may need some time to verify the change before resending the
patch.

That's absolutely fine.

Thanks,

	M.

Thanks for the detailed descriptions.
We will remove this patch and resend again.