From: Nishanth Menon <nm@ti.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-input@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] Input: misc: introduce palmas-pwrbutton
Date: Tue, 19 Aug 2014 05:17:52 -0500 [thread overview]
Message-ID: <53F32450.5070809@ti.com> (raw)
In-Reply-To: <20140819052344.GA21199@core.coreip.homeip.net>
Hi Dmitry
On 08/19/2014 12:23 AM, Dmitry Torokhov wrote:
Thanks for the review.
[...]
>> +
>> +/**
>> + * pwron_irq() - button press isr
>> + * @irq: irq
>> + * @palmas_pwron: pwron struct
>> + */
>> +static irqreturn_t pwron_irq(int irq, void *palmas_pwron)
>> +{
>> + struct palmas_pwron *pwron = palmas_pwron;
>> + struct input_dev *input_dev = pwron->input_dev;
>> +
>> + cancel_delayed_work_sync(&pwron->input_work);
>> +
>> + pwron->current_state = PALMAS_PWR_KEY_PRESS;
>> +
>> + input_report_key(input_dev, KEY_POWER, pwron->current_state);
>> + pm_wakeup_event(input_dev->dev.parent, 0);
>> + input_sync(input_dev);
>> +
>> + schedule_delayed_work(&pwron->input_work, 0);
>
> Instead of cancel/schedule use mod_delayed_work. BTW, why do you need to
> schedule immediately instead of waiting key_recheck_ms? Also, are there any
Good point, I had missed these. Will fix.
> concerns about need to debounce?
I believe PMIC already takes care of debounce, let me see if there are
configuration registers possible. if yes, I think it might be nice to
add in.
[...]
>> +
>> + irq = platform_get_irq(pdev, 0);
>> +
>> + device_init_wakeup(dev, 1);
>> +
>> + ret = devm_request_threaded_irq(dev, irq, NULL, pwron_irq,
>> + IRQF_TRIGGER_HIGH |
>> + IRQF_TRIGGER_LOW,
>> + dev_name(dev),
>> + pwron);
>
> I am confused about this code sequence. Why do we get IRQ, then set up wakeup,
> and then request irq? Normally you get irq number, and then you request it, and
> then do other stuff.
Uggh.. right.. will fix.
>
>> + if (ret < 0) {
>> + dev_err(dev, "Can't get IRQ for pwron: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + enable_irq_wake(irq);
>
> Shouldn't this be in suspend callback?
yes, it should have been.. my bad.. :( thanks for catching it.
>> +
>> + ret = input_register_device(input_dev);
>> + if (ret) {
>> + dev_dbg(dev, "Can't register power button: %d\n", ret);
>> + goto out_irq_wake;
>> + }
>> + pwron->irq = irq;
>> +
>> + pwron->key_recheck_ms = PALMAS_PWR_KEY_Q_TIME_MS;
>> +
>> + platform_set_drvdata(pdev, pwron);
>> +
>> + return 0;
>> +
>> +out_irq_wake:
>> + disable_irq_wake(irq);
>> +
>> + return ret;
>> +}
>> +
>> +static int palmas_pwron_remove(struct platform_device *pdev)
>> +{
>> + struct palmas_pwron *pwron = platform_get_drvdata(pdev);
>> +
>> + disable_irq_wake(pwron->irq);
>
> Should be in resume callback().
yep.
>
>> + input_unregister_device(pwron->input_dev);
>
> With devm you do not need to unregister input device. However this has problem:
> what will happen if interrupt arrives here and we schedule workqueue? You need
> free interrupt then cancel work and then free input device. Similar needs to be
> done in probe(). I'd recommend not use devm_* here as you need to manually
> unwind anyway.
True. I will fix these as well.
>> +
>> + return 0;
>> +}
>> +
>> +#ifdef CONFIG_PM
>> +/**
>> + * palmas_pwron_suspend() - suspend handler
>> + * @dev: power button device
>> + *
>> + * Cancel all pending work items for the power button
>> + */
>> +static int palmas_pwron_suspend(struct device *dev)
>> +{
>> + struct platform_device *pdev = to_platform_device(dev);
>> + struct palmas_pwron *pwron = platform_get_drvdata(pdev);
>> +
>> + cancel_delayed_work_sync(&pwron->input_work);
>> +
>> + return 0;
>> +}
>> +
>> +static UNIVERSAL_DEV_PM_OPS(palmas_pwron_pm, palmas_pwron_suspend, NULL, NULL);
>
> Why universal? Do they make sense for runtime pm?
>
>> +
>> +#else
>> +static UNIVERSAL_DEV_PM_OPS(palmas_pwron_pm, NULL, NULL, NULL);
>> +#endif
>
> You do not need to protect these with #ifdef and have 2 versions, just pull
> UNIVERSAL_DEV_PM_OPS (and change to SIMPLE_DEV_PM_OPS) out of #idef code.
I will just switch over to SIMPLE_DEV_PM_OPS here.. it is better here.
Thanks for the suggestion.
>> +
>> +#ifdef CONFIG_OF
>> +static struct of_device_id of_palmas_pwr_match[] = {
>> + {.compatible = "ti,palmas-pwrbutton"},
>> + {},
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, of_palmas_pwr_match);
>> +#endif
>> +
>> +static struct platform_driver palmas_pwron_driver = {
>> + .probe = palmas_pwron_probe,
>> + .remove = palmas_pwron_remove,
>> + .driver = {
>> + .name = "palmas_pwrbutton",
>> + .owner = THIS_MODULE,
>> + .of_match_table = of_match_ptr(of_palmas_pwr_match),
>> + .pm = &palmas_pwron_pm,
>> + },
>
> Weird indentation here.
Ugggh.. Lindent.. :(
---
Regards,
Nishanth Menon
WARNING: multiple messages have this Message-ID (diff)
From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] Input: misc: introduce palmas-pwrbutton
Date: Tue, 19 Aug 2014 05:17:52 -0500 [thread overview]
Message-ID: <53F32450.5070809@ti.com> (raw)
In-Reply-To: <20140819052344.GA21199@core.coreip.homeip.net>
Hi Dmitry
On 08/19/2014 12:23 AM, Dmitry Torokhov wrote:
Thanks for the review.
[...]
>> +
>> +/**
>> + * pwron_irq() - button press isr
>> + * @irq: irq
>> + * @palmas_pwron: pwron struct
>> + */
>> +static irqreturn_t pwron_irq(int irq, void *palmas_pwron)
>> +{
>> + struct palmas_pwron *pwron = palmas_pwron;
>> + struct input_dev *input_dev = pwron->input_dev;
>> +
>> + cancel_delayed_work_sync(&pwron->input_work);
>> +
>> + pwron->current_state = PALMAS_PWR_KEY_PRESS;
>> +
>> + input_report_key(input_dev, KEY_POWER, pwron->current_state);
>> + pm_wakeup_event(input_dev->dev.parent, 0);
>> + input_sync(input_dev);
>> +
>> + schedule_delayed_work(&pwron->input_work, 0);
>
> Instead of cancel/schedule use mod_delayed_work. BTW, why do you need to
> schedule immediately instead of waiting key_recheck_ms? Also, are there any
Good point, I had missed these. Will fix.
> concerns about need to debounce?
I believe PMIC already takes care of debounce, let me see if there are
configuration registers possible. if yes, I think it might be nice to
add in.
[...]
>> +
>> + irq = platform_get_irq(pdev, 0);
>> +
>> + device_init_wakeup(dev, 1);
>> +
>> + ret = devm_request_threaded_irq(dev, irq, NULL, pwron_irq,
>> + IRQF_TRIGGER_HIGH |
>> + IRQF_TRIGGER_LOW,
>> + dev_name(dev),
>> + pwron);
>
> I am confused about this code sequence. Why do we get IRQ, then set up wakeup,
> and then request irq? Normally you get irq number, and then you request it, and
> then do other stuff.
Uggh.. right.. will fix.
>
>> + if (ret < 0) {
>> + dev_err(dev, "Can't get IRQ for pwron: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + enable_irq_wake(irq);
>
> Shouldn't this be in suspend callback?
yes, it should have been.. my bad.. :( thanks for catching it.
>> +
>> + ret = input_register_device(input_dev);
>> + if (ret) {
>> + dev_dbg(dev, "Can't register power button: %d\n", ret);
>> + goto out_irq_wake;
>> + }
>> + pwron->irq = irq;
>> +
>> + pwron->key_recheck_ms = PALMAS_PWR_KEY_Q_TIME_MS;
>> +
>> + platform_set_drvdata(pdev, pwron);
>> +
>> + return 0;
>> +
>> +out_irq_wake:
>> + disable_irq_wake(irq);
>> +
>> + return ret;
>> +}
>> +
>> +static int palmas_pwron_remove(struct platform_device *pdev)
>> +{
>> + struct palmas_pwron *pwron = platform_get_drvdata(pdev);
>> +
>> + disable_irq_wake(pwron->irq);
>
> Should be in resume callback().
yep.
>
>> + input_unregister_device(pwron->input_dev);
>
> With devm you do not need to unregister input device. However this has problem:
> what will happen if interrupt arrives here and we schedule workqueue? You need
> free interrupt then cancel work and then free input device. Similar needs to be
> done in probe(). I'd recommend not use devm_* here as you need to manually
> unwind anyway.
True. I will fix these as well.
>> +
>> + return 0;
>> +}
>> +
>> +#ifdef CONFIG_PM
>> +/**
>> + * palmas_pwron_suspend() - suspend handler
>> + * @dev: power button device
>> + *
>> + * Cancel all pending work items for the power button
>> + */
>> +static int palmas_pwron_suspend(struct device *dev)
>> +{
>> + struct platform_device *pdev = to_platform_device(dev);
>> + struct palmas_pwron *pwron = platform_get_drvdata(pdev);
>> +
>> + cancel_delayed_work_sync(&pwron->input_work);
>> +
>> + return 0;
>> +}
>> +
>> +static UNIVERSAL_DEV_PM_OPS(palmas_pwron_pm, palmas_pwron_suspend, NULL, NULL);
>
> Why universal? Do they make sense for runtime pm?
>
>> +
>> +#else
>> +static UNIVERSAL_DEV_PM_OPS(palmas_pwron_pm, NULL, NULL, NULL);
>> +#endif
>
> You do not need to protect these with #ifdef and have 2 versions, just pull
> UNIVERSAL_DEV_PM_OPS (and change to SIMPLE_DEV_PM_OPS) out of #idef code.
I will just switch over to SIMPLE_DEV_PM_OPS here.. it is better here.
Thanks for the suggestion.
>> +
>> +#ifdef CONFIG_OF
>> +static struct of_device_id of_palmas_pwr_match[] = {
>> + {.compatible = "ti,palmas-pwrbutton"},
>> + {},
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, of_palmas_pwr_match);
>> +#endif
>> +
>> +static struct platform_driver palmas_pwron_driver = {
>> + .probe = palmas_pwron_probe,
>> + .remove = palmas_pwron_remove,
>> + .driver = {
>> + .name = "palmas_pwrbutton",
>> + .owner = THIS_MODULE,
>> + .of_match_table = of_match_ptr(of_palmas_pwr_match),
>> + .pm = &palmas_pwron_pm,
>> + },
>
> Weird indentation here.
Ugggh.. Lindent.. :(
---
Regards,
Nishanth Menon
next prev parent reply other threads:[~2014-08-19 10:17 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-18 20:13 [PATCH 0/2] Input: palmas: add support for palmas power button Nishanth Menon
2014-08-18 20:13 ` Nishanth Menon
2014-08-18 20:13 ` Nishanth Menon
2014-08-18 20:13 ` [PATCH 1/2] doc: dt/bindings: input: introduce palmas power button description Nishanth Menon
2014-08-18 20:13 ` Nishanth Menon
2014-08-18 20:13 ` Nishanth Menon
2014-08-19 5:28 ` Dmitry Torokhov
2014-08-19 5:28 ` Dmitry Torokhov
2014-08-19 10:23 ` Nishanth Menon
2014-08-19 10:23 ` Nishanth Menon
2014-08-18 20:13 ` [PATCH 2/2] Input: misc: introduce palmas-pwrbutton Nishanth Menon
2014-08-18 20:13 ` Nishanth Menon
2014-08-18 20:13 ` Nishanth Menon
2014-08-19 5:23 ` Dmitry Torokhov
2014-08-19 5:23 ` Dmitry Torokhov
2014-08-19 10:17 ` Nishanth Menon [this message]
2014-08-19 10:17 ` Nishanth Menon
2014-08-21 16:02 ` [PATCH V2 0/2] Input: palmas: add support for palmas power button Nishanth Menon
2014-08-21 16:02 ` Nishanth Menon
2014-08-21 16:02 ` Nishanth Menon
2014-08-21 16:02 ` [PATCH V2 1/2] doc: dt/bindings: input: introduce palmas power button description Nishanth Menon
2014-08-21 16:02 ` Nishanth Menon
2014-08-21 16:02 ` Nishanth Menon
2014-08-21 16:02 ` [PATCH V2 2/2] Input: misc: introduce palmas-pwrbutton Nishanth Menon
2014-08-21 16:02 ` Nishanth Menon
2014-08-21 16:02 ` Nishanth Menon
2014-08-21 16:59 ` Murphy, Dan
2014-08-21 16:59 ` Murphy, Dan
2014-08-21 17:12 ` Nishanth Menon
2014-08-21 17:12 ` Nishanth Menon
[not found] ` <00FC9A978A94B7418C33AFAE8A35ED49DF0662-l8PMxShYob2IQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2014-08-21 17:19 ` Nishanth Menon
2014-08-21 17:19 ` Nishanth Menon
2014-08-21 17:19 ` Nishanth Menon
2014-08-21 17:32 ` Murphy, Dan
2014-08-21 17:32 ` Murphy, Dan
[not found] ` <00FC9A978A94B7418C33AFAE8A35ED49DF07A2-l8PMxShYob2IQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2014-08-21 17:37 ` Nishanth Menon
2014-08-21 17:37 ` Nishanth Menon
2014-08-21 17:37 ` Nishanth Menon
2014-08-21 17:46 ` Murphy, Dan
2014-08-21 17:46 ` Murphy, Dan
2014-08-21 18:03 ` Dmitry Torokhov
2014-08-21 18:03 ` Dmitry Torokhov
2014-08-21 18:03 ` Dmitry Torokhov
2014-08-21 19:01 ` Nishanth Menon
2014-08-21 19:01 ` Nishanth Menon
2014-09-10 21:13 ` Dmitry Torokhov
2014-09-10 21:13 ` Dmitry Torokhov
2014-09-11 12:01 ` Nishanth Menon
2014-09-11 12:01 ` Nishanth Menon
2014-09-12 6:44 ` Dmitry Torokhov
2014-09-12 6:44 ` Dmitry Torokhov
2014-08-21 17:05 ` Dmitry Torokhov
2014-08-21 17:05 ` Dmitry Torokhov
2014-08-21 17:09 ` Nishanth Menon
2014-08-21 17:09 ` Nishanth Menon
[not found] ` <1408392810-16011-1-git-send-email-nm-l0cyMroinI0@public.gmane.org>
2014-08-21 18:52 ` [PATCH V3 " Nishanth Menon
2014-08-21 18:52 ` Nishanth Menon
2014-08-21 18:52 ` Nishanth Menon
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=53F32450.5070809@ti.com \
--to=nm@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
/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.