Patchwork [1/2] of/irq: Fix irq-mapping in of_irq_parse_raw()

login
register
mail settings
Submitter Jason Gunthorpe
Date March 11, 2014, 8:15 p.m.
Message ID <20140311201533.GF31835@obsidianresearch.com>
Download mbox | patch
Permalink /patch/329213/
State Not Applicable
Headers show

Comments

Jason Gunthorpe - March 11, 2014, 8:15 p.m.
On Tue, Mar 04, 2014 at 06:54:24AM -0800, Tim Harvey wrote:
> When an interrupt-map contains multiple entries an imap pointer arithmetic
> bug can cause only the first entry to be properly evaluated and causes
> the out_irq parameters to be incorrect depending on the #interrupt-cells
> and #address-cells of the parent interrupt controller.

Tim,

I took a bit closer look at this for you, and I suspect the root fix
is this:

(plus the corresponding purge from the .dt files)

It looks like the implementation does follow the OF specification:

 Each mapping entry consists of a 3-tuple of (child-interrupt,
 interrupt-parent, parent-interrupt). The number of cells for the
 child-interrupt specifier is determined by the "#address-cells" and
 "#interrupt-cells"property of this node. The number of cells for the
 parent-interrupt value is determined by the "#address-cells"and
 "#interrupt-cells"property values of this node's
 interrupt-parent.

So by specifying interrupt-cells = 3, address-cells = 1, the GIC is
requiring 4 DWs for its interrupt specifier.

I see no reason why it doesn't have an address-cells = 0 like other
interrupt controllers..

Setting #address-cells to 0 in the GIC node should be functionally
equivalent to your patch below, since newaddrsize will == 0.

Regards,
Jason

> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 9bcf2cf..8829197 100644
> +++ b/drivers/of/irq.c
> @@ -237,11 +237,11 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
>  			/* Check for malformed properties */
>  			if (WARN_ON(newaddrsize + newintsize > MAX_PHANDLE_ARGS))
>  				goto fail;
> -			if (imaplen < (newaddrsize + newintsize))
> +			if (imaplen < newintsize)
>  				goto fail;
>  
> -			imap += newaddrsize + newintsize;
> -			imaplen -= newaddrsize + newintsize;
> +			imap += newintsize;
> +			imaplen -= newintsize;
>  
>  			pr_debug(" -> imaplen=%d\n", imaplen);
>  		}
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tim Harvey - March 12, 2014, 3:37 a.m.
On Tue, Mar 11, 2014 at 1:15 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> On Tue, Mar 04, 2014 at 06:54:24AM -0800, Tim Harvey wrote:
>> When an interrupt-map contains multiple entries an imap pointer arithmetic
>> bug can cause only the first entry to be properly evaluated and causes
>> the out_irq parameters to be incorrect depending on the #interrupt-cells
>> and #address-cells of the parent interrupt controller.
>
> Tim,
>
> I took a bit closer look at this for you, and I suspect the root fix
> is this:
>
> --- a/Documentation/devicetree/bindings/arm/gic.txt
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -55,7 +55,6 @@ Example:
>         intc: interrupt-controller@fff11000 {
>                 compatible = "arm,cortex-a9-gic";
>                 #interrupt-cells = <3>;
> -               #address-cells = <1>;
>                 interrupt-controller;
>                 reg = <0xfff11000 0x1000>,
>                       <0xfff10100 0x100>;
> (plus the corresponding purge from the .dt files)
>
> It looks like the implementation does follow the OF specification:
>
>  Each mapping entry consists of a 3-tuple of (child-interrupt,
>  interrupt-parent, parent-interrupt). The number of cells for the
>  child-interrupt specifier is determined by the "#address-cells" and
>  "#interrupt-cells"property of this node. The number of cells for the
>  parent-interrupt value is determined by the "#address-cells"and
>  "#interrupt-cells"property values of this node's
>  interrupt-parent.

Ok - I see I misunderstood the spec with regards to what the
address-cells related to.

>
> So by specifying interrupt-cells = 3, address-cells = 1, the GIC is
> requiring 4 DWs for its interrupt specifier.

Agreed, and the interrupt mapping for the imx6 pcie host controller:

interrupt-map = <0 0 0 1 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
                <0 0 0 2 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
                <0 0 0 3 &intc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
                <0 0 0 4 &intc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;

has only 3 cells for the parent interrupt, and only 3 are needed so I
suppose there is no 'address' necessary.

>
> I see no reason why it doesn't have an address-cells = 0 like other
> interrupt controllers..

I agree, and I see that as well for other cortex-a9 gic interrupt controllers.

>
> Setting #address-cells to 0 in the GIC node should be functionally
> equivalent to your patch below, since newaddrsize will == 0.

yes, it does.  I'll verify and post a followup patch tomorrow for the
invalid dtsi's.  Thanks for digging into this!

Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -55,7 +55,6 @@  Example:
        intc: interrupt-controller@fff11000 {
                compatible = "arm,cortex-a9-gic";
                #interrupt-cells = <3>;
-               #address-cells = <1>;
                interrupt-controller;
                reg = <0xfff11000 0x1000>,
                      <0xfff10100 0x100>;