Thread (1 message) 1 message, 1 author, 2009-12-01

Re: [linux-pm] [PATCH v2 1/2] Input: gpio-keys - allow platform to specify exact irq flags

From: Ferenc Wagner <hidden>
Date: 2009-12-01 01:05:33

Possibly related (same subject, not in this thread)

Dmitry Torokhov [off-list ref] writes:
On Mon, Nov 30, 2009 at 09:59:06PM +0100, Ferenc Wagner wrote:
quoted
Mika Westerberg [off-list ref] writes:
quoted
If it suits you, I would go with the "can_disable" -field in the
struct gpio_keys_button. This way it should be possible to extend
gpio-keys in future to support multiple buttons sharing the single IRQ
and it also works for us.
Why not simply release the corresponding IRQ?  No new fields are needed
in the platform data, you don't even have to change the IRQ flags.  Or
do I miss something again?
It would work but with one unpleasant possibility - of you release IRQ
some other device might "steal" it. I don't think it is a good style for
a device to fail due to resources conflict if it was working to begin
with.
Well, the IRQ is shared, so if somebody steals it, you have a resource
conflict anyway, only with another loser this time.  Unmuting can fail
with -EBUSY.  The Linux Device Drivers book (the only reference I could
find) strongly suggests acquiring resources (especially IRQ in ch.10) on
open() and releasing them on close() -- it wasn't my idea. :)  What's
more, that would in itself make a pure user space solution possible, if
inconvenient, and also be a natural extension of your suggestion to
support multiple buttons on one IRQ by registering the shared handler
separately for each button.  Anyway, it's your call, I just wonder...
-- 
Cheers,
Feri.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help