Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> writes: > On Mon, Nov 30, 2009 at 09:59:06PM +0100, Ferenc Wagner wrote: >> Mika Westerberg <mika.westerberg@xxxxxx> writes: >> >>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
