Re: [PATCH V1 1/2] irqchip/loongson-pch-pic: Support to set irq type for ACPI path

From: Jianmin Lv
Date: Wed Sep 28 2022 - 22:36:23 EST




On 2022/9/28 下午10:49, Marc Zyngier wrote:
On Mon, 15 Aug 2022 22:01:30 -0400,
Jianmin Lv <lvjianmin@xxxxxxxxxxx> wrote:

For ACPI path, the translate callback used IRQ_TYPE_NONE and ignored
the irq type in fwspec->param[1]. For supporting to set type for
irqs of the irqdomain, fwspec->param[1] should be used to get irq
type.

On Loongson platform, the irq trigger type of PCI devices is
high level, so high level triggered type is inputed to acpi_register_gsi
when create irq mapping for PCI devices.

Signed-off-by: Jianmin Lv <lvjianmin@xxxxxxxxxxx>
---
drivers/acpi/pci_irq.c | 3 ++-
drivers/irqchip/irq-loongson-pch-pic.c | 10 ++++++----
2 files changed, 8 insertions(+), 5 deletions(-)

$ ./scripts/get_maintainer.pl drivers/acpi/pci_irq.c
Bjorn Helgaas <bhelgaas@xxxxxxxxxx> (supporter:PCI SUBSYSTEM)
"Rafael J. Wysocki" <rafael@xxxxxxxxxx> (supporter:ACPI)
Len Brown <lenb@xxxxxxxxxx> (reviewer:ACPI)
linux-pci@xxxxxxxxxxxxxxx (open list:PCI SUBSYSTEM)
linux-acpi@xxxxxxxxxxxxxxx (open list:ACPI)
linux-kernel@xxxxxxxxxxxxxxx (open list)

How about you start Cc-ing some of the relevant people?

Ok, thanks, I'll cc relevant people list here.


diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 08e1577..34483b3 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -393,7 +393,8 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
* controller and must therefore be considered active high
* as default.
*/
- int polarity = acpi_irq_model == ACPI_IRQ_MODEL_GIC ?
+ int polarity = acpi_irq_model == ACPI_IRQ_MODEL_GIC ||
+ acpi_irq_model == ACPI_IRQ_MODEL_LPIC ?
ACPI_ACTIVE_HIGH : ACPI_ACTIVE_LOW;

The comment just above this only talks about ARM. Should it be
updated?

Ok, I'll update the comment.


Is this a limitation of the underlying interrupt controller?

It's the limitation that pci interrupt source of LoongArch only sends high level trigger signal to interrupt controller(though, pci spec requires asserted low).


char *link = NULL;
char link_desc[16];
diff --git a/drivers/irqchip/irq-loongson-pch-pic.c b/drivers/irqchip/irq-loongson-pch-pic.c
index b6f1392..5067010 100644
--- a/drivers/irqchip/irq-loongson-pch-pic.c
+++ b/drivers/irqchip/irq-loongson-pch-pic.c
@@ -177,13 +177,15 @@ static int pch_pic_domain_translate(struct irq_domain *d,
if (fwspec->param_count < 1)
return -EINVAL;
- if (of_node) {
+ if (of_node)
*hwirq = fwspec->param[0] + priv->ht_vec_base;
- *type = fwspec->param[1] & IRQ_TYPE_SENSE_MASK;
- } else {
+ else
*hwirq = fwspec->param[0] - priv->gsi_base;
+
+ if (fwspec->param_count > 1)
+ *type = fwspec->param[1] & IRQ_TYPE_SENSE_MASK;
+ else
*type = IRQ_TYPE_NONE;

Isn't that a change in behaviour if of_node is non-NULL and
param_count==1?


It seems that current code here has bug that if fwspec->param_count==1 and of_node is non-null, fwspec->param[1] will be accessed, which is introduced from previous patch(irqchip/loongson-pch-pic: Add ACPI init support). Before the patch, for non-null of_node, translate callback(use irq_domain_translate_twocell) will return -EINVAL if fwspec->param_count < 2.

For ACPI path, fwspec->param_count can be 1 or 2.

So in this patch, I'll fix the bug and change the code as following:

if (fwspec->param_count < 1)
return -EINVAL;

if (of_node) {
if (fwspec->param_count < 2)
return -EINVAL;

*hwirq = fwspec->param[0] + priv->ht_vec_base;
*type = fwspec->param[1] & IRQ_TYPE_SENSE_MASK;
} else {
*hwirq = fwspec->param[0] - priv->gsi_base;

if (fwspec->param_count > 1)
*type = fwspec->param[1] & IRQ_TYPE_SENSE_MASK;
else
*type = IRQ_TYPE_NONE;
}


- }
return 0;
}

This irqchip change should probably be a separate patch.


As a separate patch, the input trigger type of pci devices will be low level because of lacking of workaround to acpi_pci_irq_enable, which will cause kernel hang, unless the patch of workaround to acpi_pci_irq_enable is in front of this separated patch.


M.