[PATCH] octeon-irq: Fix GPIO number in IRQ chip private data

[PATCH] octeon-irq: Fix GPIO number in IRQ chip private data

[Alexander Sverdlin]

octeon-irq: Fix GPIO number in IRQ chip private data

Current GPIO chip implementation in octeon-irq is still broken, even after upstream
commit 87161ccdc61862c8b49e75c21209d7f79dc758e9 (MIPS: Octeon: Fix broken interrupt
controller code). It works for GPIO IRQs that have reset-default configuration, but
not for edge-triggered ones.

The problem is in octeon_irq_gpio_map_common(), which passes modified "hw" variable
(which has range of possible values 16..31) as "gpio_line" parameter to
octeon_irq_set_ciu_mapping(), which saves it in private data of the IRQ chip. Later,
neither octeon_irq_gpio_setup() is able to re-configure GPIOs (cvmx_write_csr() is
writing to non-existent CVMX_GPIO_BIT_CFGX), nor octeon_irq_ciu_gpio_ack() is able
to acknowledge such IRQ, because "mask" is incorrect.

Fix is trivial and has been tested on Cavium Octeon II -based board, including
both level-triggered and edge-triggered GPIO IRQs.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin.ext@nsn.com>
Cc: David Daney <david.daney@cavium.com>
---
--- linux.orig/arch/mips/cavium-octeon/octeon-irq.c
+++ linux/arch/mips/cavium-octeon/octeon-irq.c
@@ -1034,9 +1034,8 @@ static int octeon_irq_gpio_map_common(st
  	if (!octeon_irq_virq_in_range(virq))
  		return -EINVAL;

-	hw += gpiod->base_hwirq;
-	line = hw >> 6;
-	bit = hw & 63;
+	line = (hw + gpiod->base_hwirq) >> 6;
+	bit = (hw + gpiod->base_hwirq) & 63;
  	if (line > line_limit || octeon_irq_ciu_to_irq[line][bit] != 0)
  		return -EINVAL;

Re: [PATCH] octeon-irq: Fix GPIO number in IRQ chip private data

[David Daney]

On 03/08/2013 06:47 AM, Alexander Sverdlin wrote:
> octeon-irq: Fix GPIO number in IRQ chip private data
>
> Current GPIO chip implementation in octeon-irq is still broken, even
> after upstream
> commit 87161ccdc61862c8b49e75c21209d7f79dc758e9 (MIPS: Octeon: Fix
> broken interrupt
> controller code). It works for GPIO IRQs that have reset-default
> configuration, but
> not for edge-triggered ones.
>
> The problem is in octeon_irq_gpio_map_common(), which passes modified
> "hw" variable
> (which has range of possible values 16..31) as "gpio_line" parameter to
> octeon_irq_set_ciu_mapping(), which saves it in private data of the IRQ
> chip. Later,
> neither octeon_irq_gpio_setup() is able to re-configure GPIOs
> (cvmx_write_csr() is
> writing to non-existent CVMX_GPIO_BIT_CFGX), nor
> octeon_irq_ciu_gpio_ack() is able
> to acknowledge such IRQ, because "mask" is incorrect.
>
> Fix is trivial and has been tested on Cavium Octeon II -based board,
> including
> both level-triggered and edge-triggered GPIO IRQs.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin.ext@nsn.com>
> Cc: David Daney <david.daney@cavium.com>

Yes, this patch is needed...

Acked-by: David Daney <david.daney@cavium.com>

> ---
> --- linux.orig/arch/mips/cavium-octeon/octeon-irq.c
> +++ linux/arch/mips/cavium-octeon/octeon-irq.c
> @@ -1034,9 +1034,8 @@ static int octeon_irq_gpio_map_common(st
>       if (!octeon_irq_virq_in_range(virq))
>           return -EINVAL;
>
> -    hw += gpiod->base_hwirq;
> -    line = hw >> 6;
> -    bit = hw & 63;
> +    line = (hw + gpiod->base_hwirq) >> 6;
> +    bit = (hw + gpiod->base_hwirq) & 63;
>       if (line > line_limit || octeon_irq_ciu_to_irq[line][bit] != 0)
>           return -EINVAL;
>
>
>
>