kernel/linux.git/drivers/of/irq.c, branch v5.19

of/irq: fix typo in comment

2022-05-23T21:37:01+00:00

Spelling mistake (triple letters) in comment. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220521111145.81697-59-Julia.Lawall@inria.fr

of/irq: Use interrupts-extended to find parent

2022-04-12T18:21:16+00:00

The RISC-V PLIC binding uses interrupts-extended to specify its parent domain(s). That binding does not allow the interrupt-parent property to appear in the irqchip node. This prevents of_irq_init from properly detecting the irqchip hierarchy. If no interrupt-parent property is present in the enclosing bus or root node, then desc->interrupt_parent will be NULL for both the per-CPU RISC-V INTC (the actual root domain) and the RISC-V PLIC. Similarly, if the bus or root node specifies `interrupt-parent = <&plic>`, then of_irq_init will hit the `desc->interrupt_parent == np` check, and again all parents will be NULL. So things happen to work today for some boards due to Makefile ordering. However, things break when another irqchip ("foo") is stacked on top of the PLIC. The bus or root node will have `interrupt-parent = <&foo>`, since that is what all of the other peripherals need. When of_irq_init runs, it will try to find the PLIC's parent domain. of_irq_find_parent will fall back to using the interrupt-parent property of the PLIC's parent node (i.e. the bus or root node), and of_irq_init will see "foo" as the PLIC's parent domain. But this is wrong, because "foo" is actually the PLIC's child domain! So of_irq_init wrongly attempts to init the stacked irqchip before the PLIC. This fails and breaks booting. Fix this by using the first node referenced by interrupts-extended as the parent when that property is present. This allows of_irq_init to see the relationship between the PLIC and the per-CPU RISC-V INTC, and thus only the RISC-V INTC is (correctly) considered a root domain. Signed-off-by: Samuel Holland Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220412051529.6293-1-samuel@sholland.org

of/irq: Add a quirk for controllers with their own definition of interrupt-map

2021-12-03T17:30:22+00:00

Since commit 041284181226 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller"), a handful of interrupt controllers have stopped working correctly. This is due to the DT exposing a non-sensical interrupt-map property, and their drivers relying on the kernel ignoring this property. Since we cannot realistically fix this terrible behaviour, add a quirk for the limited set of devices that have implemented this monster, and document that this is a pretty bad practice. Fixes: 041284181226 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller") Cc: Rob Herring Cc: John Crispin Cc: Biwen Li Cc: Chris Brandt Cc: Geert Uytterhoeven Cc: Sander Vanheule Signed-off-by: Marc Zyngier Tested-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20211201114102.13446-1-maz@kernel.org Signed-off-by: Rob Herring

of/irq: Don't ignore interrupt-controller when interrupt-map failed

2021-11-12T16:10:00+00:00

Since 041284181226 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller"), the irq code favors using an interrupt-map over a interrupt-controller property if both are available, while the earlier behaviour was to ignore the interrupt-map altogether. However, we now end-up with the opposite behaviour, which is to ignore the interrupt-controller property even if the interrupt-map fails to match its input. This new behaviour breaks the AmigaOne X1000 machine, which ships with an extremely "creative" (read: broken) device tree. Fix this by allowing the interrupt-controller property to be selected when interrupt-map fails to match anything. Fixes: 041284181226 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller") Reported-by: Christian Zigotzky Reviewed-by: Rob Herring Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/78308692-02e6-9544-4035-3171a8e1e6d4@xenosoft.de Link: https://lore.kernel.org/r/20211112143644.434995-1-maz@kernel.org Cc: Bjorn Helgaas

of/irq: Allow matching of an interrupt-map local to an interrupt controller

2021-11-04T19:14:57+00:00

of_irq_parse_raw() has a baked assumption that if a node has an interrupt-controller property, it cannot possibly also have an interrupt-map property (the latter being ignored). This seems to be an odd behaviour, and there is no reason why we should avoid supporting this use case. This is specially useful when a PCI root port acts as an interrupt controller for PCI endpoints, such as this: pcie0: pcie@690000000 { [...] port00: pci@0,0 { device_type = "pci"; [...] #address-cells = <3>; interrupt-controller; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &port00 0 0 0 0>, <0 0 0 2 &port00 0 0 0 1>, <0 0 0 3 &port00 0 0 0 2>, <0 0 0 4 &port00 0 0 0 3>; }; }; Handle it by detecting that we have an interrupt-map early in the parsing, and special case the situation where the phandle in the interrupt map refers to the current node (which is the interesting case here). Link: https://lore.kernel.org/r/20210929163847.2807812-3-maz@kernel.org Tested-by: Alyssa Rosenzweig Signed-off-by: Marc Zyngier Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Rob Herring

of: Add missing 'Return' section in kerneldoc comments

2021-03-27T18:59:03+00:00

Many of the DT kerneldoc comments are lacking a 'Return' section. Let's add the section in cases we have a description of return values. There's still some cases where the return values are not documented. Cc: Frank Rowand Cc: Mauro Carvalho Chehab Signed-off-by: Rob Herring Reviewed-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/20210325164713.1296407-8-robh@kernel.org

of/irq: Make of_msi_map_rid() PCI bus agnostic

2020-07-28T14:51:32+00:00

There is nothing PCI bus specific in the of_msi_map_rid() implementation other than the requester ID tag for the input ID space. Rename requester ID to a more generic ID so that the translation code can be used by all busses that require input/output ID translations. No functional change intended. Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Cc: Bjorn Helgaas Cc: Rob Herring Cc: Marc Zyngier Link: https://lore.kernel.org/r/20200619082013.13661-11-lorenzo.pieralisi@arm.com Signed-off-by: Catalin Marinas

of/irq: make of_msi_map_get_device_domain() bus agnostic

2020-07-28T14:51:32+00:00

of_msi_map_get_device_domain() is PCI specific but it need not be and can be easily changed to be bus agnostic in order to be used by other busses by adding an IRQ domain bus token as an input parameter. Signed-off-by: Diana Craciun Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Acked-by: Bjorn Helgaas # pci/msi.c Cc: Bjorn Helgaas Cc: Rob Herring Cc: Marc Zyngier Link: https://lore.kernel.org/r/20200619082013.13661-10-lorenzo.pieralisi@arm.com Signed-off-by: Catalin Marinas

of/iommu: Make of_map_rid() PCI agnostic

2020-07-28T14:51:31+00:00

There is nothing PCI specific (other than the RID - requester ID) in the of_map_rid() implementation, so the same function can be reused for input/output IDs mapping for other busses just as well. Rename the RID instances/names to a generic "id" tag. No functionality change intended. Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Acked-by: Joerg Roedel Cc: Rob Herring Cc: Joerg Roedel Cc: Robin Murphy Cc: Marc Zyngier Link: https://lore.kernel.org/r/20200619082013.13661-7-lorenzo.pieralisi@arm.com Signed-off-by: Catalin Marinas

of: irq: fix a trivial typo in a doc comment

2019-08-15T02:12:16+00:00

Diverged from what the code does with commit 530210c7814e ("of/irq: Replace of_irq with of_phandle_args"). Signed-off-by: Lubomir Rintel Signed-off-by: Rob Herring