From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: "grant.likely@secretlab.ca" <grant.likely@secretlab.ca>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
Stephen Warren <swarren@nvidia.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v2 2/4] input: keyboard: tegra: use devm_* for resource allocation
Date: Sat, 5 Jan 2013 15:18:58 -0800 [thread overview]
Message-ID: <20130105231858.GD6475@core.coreip.homeip.net> (raw)
In-Reply-To: <50E80C9A.7040404@nvidia.com>
On Sat, Jan 05, 2013 at 04:50:58PM +0530, Laxman Dewangan wrote:
> HI Dmitry,
> Thanks for quick review.
>
> I will take care of your comment in next version. Some have my answer.
>
>
> On Saturday 05 January 2013 01:36 PM, Dmitry Torokhov wrote:
> >Hi Laxman,
> >
> >On Sat, Jan 05, 2013 at 01:15:08PM +0530, Laxman Dewangan wrote:
> >>Use devm_* for memory, clock, input device allocation. This reduces
> >>code for freeing these resources.
>
> >> err = tegra_kbd_setup_keymap(kbc);
> >>- if (err) {
> >>+ if (err < 0) {
> >Why is this change? As far as I can see tegra_kbd_setup_keymap() never
> >returns positive values.
>
> Ok, mostly errors are in negative and hence this change, I will
> revert it and will keep original.
>
> >
> >> dev_err(&pdev->dev, "failed to setup keymap\n");
> >>- goto err_put_clk;
> >>+ return err;
> >> }
> >> __set_bit(EV_REP, input_dev->evbit);
> >>@@ -790,15 +784,15 @@ static int tegra_kbc_probe(struct platform_device *pdev)
> >> err = request_irq(kbc->irq, tegra_kbc_isr,
> >> IRQF_NO_SUSPEND | IRQF_TRIGGER_HIGH, pdev->name, kbc);
> >>- if (err) {
> >>+ if (err < 0) {
> >Neither request_irq(). BTW, why not devm_request_irq?
>
> I understand from Mark B on different patches that using
> devm_request_irq() can create race condition when removing device.
> Interrupt can occur when device resource release is in process and
> so it can cause isr call which can use the freed pointer.
> devm_request_irq() should be avoided.
devm_request_irq() has a potential of creating a race condition, but it
depents on the driver. In this particular case tegra driver ensures that
interrupts are inhibited when input device is unregistered by providing
tegra_kbc_close() method, so in this particular case it is safe to
use devm_request_irq().
Also, when using managed input devices, the unregistering and final
freeing is a 2-step process, so even in absence of close() method, if
initialization sequence was:
devm_input_allocate_device()
...
devm_request_irq()
...
input_unregister_device()
then order of freeing resources (behind the scenes) will be
devm_input_device_unregister();
/* input device is still present in memory and can
* handle input_event() calls.
*/
free_irq();
devm_input_device_release();
So using managed request_irq() _together_ with managed input devices is
OK.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2013-01-05 23:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-05 7:45 [PATCH V2 0/4] input: keyboard: tegra: cleanups and DT supports Laxman Dewangan
[not found] ` <1357371910-3164-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-05 7:45 ` [PATCH v2 1/4] input: keyboard: tegra: fix build warning Laxman Dewangan
2013-01-05 7:45 ` [PATCH v2 2/4] input: keyboard: tegra: use devm_* for resource allocation Laxman Dewangan
2013-01-05 8:06 ` Dmitry Torokhov
2013-01-05 11:20 ` Laxman Dewangan
2013-01-05 23:18 ` Dmitry Torokhov [this message]
[not found] ` <20130105231858.GD6475-WlK9ik9hQGAhIp7JRqBPierSzoNAToWh@public.gmane.org>
2013-01-06 11:00 ` Laxman Dewangan
[not found] ` <20130105080658.GA1315-WlK9ik9hQGAhIp7JRqBPierSzoNAToWh@public.gmane.org>
2013-01-06 19:27 ` Thierry Reding
2013-01-06 19:57 ` Dmitry Torokhov
2013-01-09 7:07 ` Thierry Reding
2013-01-09 9:19 ` Dmitry Torokhov
[not found] ` <20130109091939.GA4369-WlK9ik9hQGAhIp7JRqBPierSzoNAToWh@public.gmane.org>
2013-01-09 9:23 ` Thierry Reding
2013-01-14 15:49 ` Thierry Reding
2013-01-14 16:16 ` Greg Kroah-Hartman
2013-01-14 22:15 ` Thierry Reding
[not found] ` <20130114221551.GA30020-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2013-01-14 22:24 ` Arnd Bergmann
[not found] ` <201301142224.11243.arnd-r2nGTMty4D4@public.gmane.org>
2013-01-15 6:44 ` Thierry Reding
2013-01-15 12:32 ` Wolfram Sang
2013-01-15 13:06 ` Wolfram Sang
[not found] ` <20130115130623.GC2625-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2013-01-15 15:44 ` Thierry Reding
2013-01-16 6:35 ` Wolfram Sang
2013-02-09 9:04 ` Grant Likely
2013-01-05 7:45 ` [PATCH v2] input: keyboard: tegra: add support for rows/cols configuration from dt Laxman Dewangan
2013-01-05 7:45 ` [PATCH v2 4/4] input: keyboard: tegra: remove default key mapping Laxman Dewangan
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=20130105231858.GD6475@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=ldewangan@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=swarren@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).