uses of irq_to_gpio() in drivers/staging/iio
Whilst looking in drivers/staging/iio/accel/lis3l02dq_core.c, I came across the following lines of code
708 if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0) {
709 ret = request_threaded_irq(st->us->irq,
710 &lis3l02dq_th,
711&lis3l02dq_event_handler,
712 IRQF_TRIGGER_RISING, 713 "lis3l02dq", 714 indio_dev);
Which gives rise to the following questions:
1) IRQ0 and GPIO0 are often valid numbers for GPIOs.
2) Not all interrupts are necessarily GPIO interrupts. What happens if the device is attached to a hardware interrupt line which is not a GPIO?
Signature · 1 line
Ben Dooks <[email protected]> http://www.fluff.org/ben/
Quoted 11 lines · Ben Dooks
Whilst looking in
drivers/staging/iio/accel/lis3l02dq_core.c, I came across the following lines of code708 if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0) { 709 ret = request_threaded_irq(st->us->irq, 710 &lis3l02dq_th, 711 &lis3l02dq_event_handler, 712 IRQF_TRIGGER_RISING, 713 "lis3l02dq", 714 indio_dev);
Quoted 3 lines
Which gives rise to the following questions:
1) IRQ0 and GPIO0 are often valid numbers for GPIOs.
Good point - should fix that one. Any suggestions for a neat way to do it?
Quoted 5 lines
2) Not all interrupts are necessarily GPIO interrupts. What happens if the device is attached to a hardware interrupt line which is not a GPIO?
Easy. It doesn't work. Stupid hardware doesn't necessarily drop the interrupt line on a read. Hence it sticks high. If one only has edge triggered interrupt lines that's a pain. Is there an easy way around this? When I wrote the relevant code a long time ago I couldn't get anything else to work.
There may well be a better way but I haven't revisited this recently.