From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Mathias Nyman <mathias.nyman@linux.intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Alexandre Courbot <acourbot@nvidia.com>
Subject: Re: [PATCH] gpio: lynxpoint: lock IRQs when starting them
Date: Tue, 26 Nov 2013 15:18:58 +0200 [thread overview]
Message-ID: <52949FC2.6010702@ti.com> (raw)
In-Reply-To: <CACRpkdYLNWgfOFsRYiy5VBpmiJRGZ-3zo2AMBqAdufqRNFpUwA@mail.gmail.com>
On 11/26/2013 11:52 AM, Linus Walleij wrote:
> On Wed, Nov 20, 2013 at 7:29 PM, Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>> On 11/20/2013 04:42 PM, Linus Walleij wrote:
>>>
>>> This uses the new API for tagging GPIO lines as in use by
>>> IRQs. This enforces a few semantic checks on how the underlying
>>> GPIO line is used.
> (...)
>>> +static unsigned int lp_irq_startup(struct irq_data *d)
>>> +{
>>> + struct lp_gpio *lg = irq_data_get_irq_chip_data(d);
>>> +
>>> + if (gpio_lock_as_irq(&lg->chip, irqd_to_hwirq(d)))
>>> + dev_err(lg->chip.dev,
>>> + "unable to lock HW IRQ %lu for IRQ\n",
>>> + irqd_to_hwirq(d));
>>> + return 0;
>>> +}
>>> +
>>> +static void lp_irq_shutdown(struct irq_data *d)
>>> +{
>>> + struct lp_gpio *lg = irq_data_get_irq_chip_data(d);
>>> +
>>> + gpio_unlock_as_irq(&lg->chip, irqd_to_hwirq(d));
>>> +}
>>
>> Seems, such changes may be risky, because .irq_startup()
>> and irq_enable()/irq_umask() are mutually exclusive, at least at IRQ request time.
>> request_threaded_irq()->__setup_irq()->irq_startup()
>>
>> More over, IRQ core assumes that IRQ is enabled, unmasked and ready for use after
>> .irq_startup() call. You can check functions irq/chip.c->irq_startup() for more info.
>>
>> So, .irq_enable() functionality need to be duplicated in .irq_startup() at least.
>>
>> if you agree - above comment is valid for most of similar recent patches ;)
>
> Yep. I just showcase what a worthless IRQ core user I am...
Yeah. That's the Gray hole in Linux's universe :)
>
> Now what would be the best way to call this?
>
> Should I just move this into the .enable callback, and if there is no
> such callback, create it and call the .unmask explicitly
> at the end of it? It would seem a bit counter-intuitive to do this
> in the .mask/.unmask callback, as that should only do exactly
> that - mask/unmask.
>
> I'll try this approach...
I'm glad to help. Seems you've made it work.
Regards,
-grygorii
prev parent reply other threads:[~2013-11-26 13:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-20 14:42 [PATCH] gpio: lynxpoint: lock IRQs when starting them Linus Walleij
2013-11-20 18:29 ` Grygorii Strashko
2013-11-26 9:52 ` Linus Walleij
2013-11-26 13:18 ` Grygorii Strashko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52949FC2.6010702@ti.com \
--to=grygorii.strashko@ti.com \
--cc=acourbot@nvidia.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=mika.westerberg@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.