On Wednesday 22 July 2009, Mark Brown wrote:

Yes, I think that'll be required for users like gpiolib.  If someone's
done something like have a button implemented by attaching switch to a
GPIO input on for something like jack detect on an audio CODEC or a wake
source for a PMIC then we've got generic code that expects to just take
a gpio/irq and interact with it.

Is there a problem with how it works now?  GPIO calls come in
sleeping (e.g. over I2C or SPI) and non-sleeping (classic SoC
GPIOs) varieties.  And it's not gpiolib which would handle any
IRQ support ... it's the driver for the GPIO chip, which would
expose both irq_chip and gpio_chip facets.  (Just like classic
SoC GPIO drivers.)

So if a handler uses only non-sleeping calls, it needs at most
minor tweaks to make sure it can be used from a threaded context.

If it uses sleeping calls, it already has to arrange that it
runs in a threaded context.