octeon-irq: Fix GPIO number in IRQ chip private data
Current GPIO chip implementation in octeon-irq is still broken, even after
commit 87161ccdc61862c8b49e75c21209d7f79dc758e9 (MIPS: Octeon: Fix broken
controller code). It works for GPIO IRQs that have reset-default configuration,
not for edge-triggered ones.
The problem is in octeon_irq_gpio_map_common(), which passes modified "hw"
(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.
neither octeon_irq_gpio_setup() is able to re-configure GPIOs (cvmx_write_csr()
writing to non-existent CVMX_GPIO_BIT_CFGX), nor octeon_irq_ciu_gpio_ack() is
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 <firstname.lastname@example.org>
Cc: David Daney <email@example.com>
@@ -1034,9 +1034,8 @@ static int octeon_irq_gpio_map_common(st
- 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)