# Garrett D'Amore 2006-06-12:
> I have a question, regarding gpios (gpiobus) and interrupts.
> 
> On AR5312, the GPIO pins can be tied to an interrupt, so that you get an
> external interrupt (don't recall off hand whether edge or level
> triggered).  This is useful because, for example, one of the devices
> that these GPIOs are used with is an external factory reset button.

Yes, GPIOs on SoC chips tend to have special properties:

  * can be configured for interrupt, as you note
  * can be configured for "alternate function" (the same pad is used
    by on-chip peripheral and GPIO pin, MUX is used to select the
    actual connection)

Neither of them seems to be addressed by the gpio framework. It should
at least be possible to mark pin as unavailable when it's switched
to interrupt mode/alternate function (maybe this can already be done
via gpio API but I missed it?).

Model situation -- on-chip IDE controller is attached, so it should
disable those GPIOs that happen to share pads with IDE signals and
probably configure some GPIO to generate IRQ. Any further attempt
(kernel or userland) to use any of those pins should result in an
error, thus catching misconfigurations early and preventing dangerous
things from happening.

> The question I have is how do folks feel about the notion of adding some
> kind of interrupt support/facility to the GPIO framework, as an extra
> capability.  Then I could have a device like "resetbutton@gpio7" or
> somesuch.
> 
> What do folks think?  Does it make sense, or should I just use a
> non-GPIO framework based software approach to this problem?

I wouldn't go for too much abstraction here, but perhaps extend the
API with function that maps "gpio_pin_t" to interrupt number usable
by intr_establish() (and marks the pin appropriately). OTOH, this
would mostly be provided by SoC GPIO controllers and used by
SoC-specific drivers...

	-- Jachym