linux-toradex.git/drivers/of/irq.c, branch v6.3-rc3

of/irq: add missing of_node_put() for interrupt parent node

2023-01-18T17:31:42+00:00

After calling of_irq_parse_one(), the node provided in the of_phandle_args
has a refcount increment by one. Add missing of_node_put in of_irq_get()
to decrement the refcount once used.

Signed-off-by: Clément Léger 
Link: https://lore.kernel.org/r/20230117144929.423089-1-clement.leger@bootlin.com
Signed-off-by: Rob Herring

of/irq: export of_msi_get_domain

2022-10-19T13:28:04+00:00

Export of_mis_get_domain to enable it for users from outside.

Signed-off-by: Matthias Brugger 
Acked-by: Rob Herring 
Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20200122104723.16955-1-peter.ujfalusi@ti.com
Signed-off-by: Kevin Hilman 
Acked-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20220929234820.940048-2-khilman@baylibre.com
Signed-off-by: Vinod Koul

of: irq: Report individual failures in of_irq_init()

2022-09-07T15:54:55+00:00

New pr_err(), a copy of preceeding pr_debug(), faciliates debugging.

This change was inspired by a long lasting debugging of the
octeon_irq_init_ciu() which fails completely silently and leaves the
interrupt controller half-way configured which in turn had very non-obvious
effects.

Signed-off-by: Alexander Sverdlin 
Link: https://lore.kernel.org/r/20220907121629.54330-1-alexander.sverdlin@nokia.com
Signed-off-by: Rob Herring

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