Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> writes: > On Fri, Sep 18, 2009 at 03:44:41PM +0400, Dmitry Eremin-Solenikov wrote: >> On Wed, Sep 16, 2009 at 10:41 PM, Dmitry Eremin-Solenikov >> <dbaryshkov@xxxxxxxxx> wrote: >>> On Wed, Sep 16, 2009 at 8:28 PM, Dmitry Torokhov >>> <dmitry.torokhov@xxxxxxxxx> wrote: >>>> On Wed, Sep 16, 2009 at 07:03:18PM +0400, Dmitry Eremin-Solenikov wrote: >>>>> There is nothing that disallows gpio-keys to share it's IRQ line >>>>> w/ other drivers. Make it use IRQF_SHARED in request_irq(). >>>>> >>>>> An example of other driver with which I'd like to share IRQ line >>>>> for GPIO buttons is ledtrig-gpio. >>>>> >>>>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@xxxxxxxxx> >>>>> --- >>>>> drivers/input/keyboard/gpio_keys.c | 1 + >>>>> 1 files changed, 1 insertions(+), 0 deletions(-) >>>>> >>>>> diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c >>>>> index efed0c9..9fc2fab 100644 >>>>> --- a/drivers/input/keyboard/gpio_keys.c >>>>> +++ b/drivers/input/keyboard/gpio_keys.c >>>>> @@ -147,6 +147,7 @@ static int __devinit gpio_keys_probe(struct platform_device *pdev) >>>>> } >>>>> >>>>> error = request_irq(irq, gpio_keys_isr, >>>>> + IRQF_SHARED | >>>>> IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, >>>>> button->desc ? button->desc : "gpio_keys", >>>>> bdata); >>>> >>>> How will you determine which device generated the interrupt? Because you >>>> can't return IRQ_HANDLED unconditionally and expect both devices work >>>> reliably. >>> >>> It's a single device (gpio pin). However I'd like to be able to attach >>> several handlers to it. >>> E.g. one isr is gpio-keys (for reporting event to userspace), another >>> isr will be from >>> ledtrig-gpio (controlling the LED). Another can be some kind of >>> battery driver, etc. >>> >>> All these drivers will provide different kinds of response for single GPIO pin. >> >> So, what about this patch? > > OK, will apply. I still think it's dangerous. But I am not a kernel hacker and a very beginner on this whole field, so please let me explain why, and please correct my conclusions as needed. I met this problem playing with an embedded platform (brcm47xx), where I wanted to employ the gpio_keys driver. Registering the gpio_keys platform device wasn't enough, because the gpio_keys module still couldn't be loaded as the serial console already used the same interrupt line of the Sonics Silicon Backplane. (Also, it used shared, but level triggered interrupts, so simply adding in IRQF_SHARED wouldn't have helped either, besides breaking both devices). Anyway, such platforms may have several GPIO buttons, typically using the same interrupt line, so there must be a way to tell them apart, which looks impossible without some GPIO access to acknowledge (change polarity of) the correct button. So I plan to put forward some changes in this area, like switching to level triggered interrupts to facilitate sharing. I've got some proof of concept code, but still have to learn the ropes. Apart from this, adding in IRQF_SHARED like above for being able to attach several handlers looks fishy big time. Would the rest be invoked at all once you returned IRQ_HANDLED from the first (it's a question of fact in Linux interrupt handling, I just down't know, but would guess yes, for level triggered interrupts at least)? Is this common practice? -- Thanks, 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
