From: Jonathan Cameron <jic23@kernel.org>
To: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: robh@kernel.org, alexandre.belloni@bootlin.com, lars@metafoo.de,
heiko@sntech.de, linux-iio@vger.kernel.org,
claudiu.beznea@tuxon.dev, yangyingliang@huawei.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH -next v2 2/3] iio: adc: at91_adc: Use devm_request_irq() helper function
Date: Sun, 27 Aug 2023 18:13:17 +0100 [thread overview]
Message-ID: <20230827181317.10ea9aa7@jic23-huawei> (raw)
In-Reply-To: <20230826022922.3457054-3-ruanjinjie@huawei.com>
On Sat, 26 Aug 2023 10:29:21 +0800
Jinjie Ruan <ruanjinjie@huawei.com> wrote:
> Use devm_request_irq() to request the interrupt, so we can
> avoid having to manually clean this up.
>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> drivers/iio/adc/at91_adc.c | 28 +++++++++++++---------------
> 1 file changed, 13 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index 318e33ce22fb..2ac1b64f0fb7 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -1077,11 +1077,13 @@ static int at91_adc_probe(struct platform_device *pdev)
> at91_adc_writel(st, AT91_ADC_IDR, 0xFFFFFFFF);
>
> if (st->caps->has_tsmr)
> - ret = request_irq(st->irq, at91_adc_9x5_interrupt, 0,
> - pdev->dev.driver->name, idev);
> + ret = devm_request_irq(&pdev->dev, st->irq,
> + at91_adc_9x5_interrupt, 0,
> + pdev->dev.driver->name, idev);
> else
> - ret = request_irq(st->irq, at91_adc_rl_interrupt, 0,
> - pdev->dev.driver->name, idev);
> + ret = devm_request_irq(&pdev->dev, st->irq,
> + at91_adc_rl_interrupt, 0,
> + pdev->dev.driver->name, idev);
> if (ret) {
> dev_err(&pdev->dev, "Failed to allocate IRQ.\n");
> return ret;
> @@ -1092,7 +1094,7 @@ static int at91_adc_probe(struct platform_device *pdev)
> dev_err(&pdev->dev,
> "Could not prepare or enable the clock.\n");
> ret = PTR_ERR(st->clk);
> - goto error_free_irq;
> + return ret;
Whilst they go away in the next patch, this does look odd as you can clearly just
do
return PTR_ERR(st->clk);
In the interests of easy step wise patch review, I'd prefer that you made that
change in this patch in all the places this pattern occurs.
> }
>
> st->adc_clk = devm_clk_get_enabled(&pdev->dev, "adc_op_clk");
> @@ -1100,7 +1102,7 @@ static int at91_adc_probe(struct platform_device *pdev)
> dev_err(&pdev->dev,
> "Could not prepare or enable the ADC clock.\n");
> ret = PTR_ERR(st->adc_clk);
> - goto error_free_irq;
> + return ret;
> }
>
> /*
> @@ -1119,8 +1121,7 @@ static int at91_adc_probe(struct platform_device *pdev)
>
> if (!st->startup_time) {
> dev_err(&pdev->dev, "No startup time available.\n");
> - ret = -EINVAL;
> - goto error_free_irq;
> + return -EINVAL;
> }
> ticks = (*st->caps->calc_startup_ticks)(st->startup_time, adc_clk_khz);
>
> @@ -1148,7 +1149,7 @@ static int at91_adc_probe(struct platform_device *pdev)
> ret = at91_adc_channel_init(idev);
> if (ret < 0) {
> dev_err(&pdev->dev, "Couldn't initialize the channels.\n");
> - goto error_free_irq;
> + return ret;
> }
>
> init_waitqueue_head(&st->wq_data_avail);
> @@ -1163,19 +1164,19 @@ static int at91_adc_probe(struct platform_device *pdev)
> ret = at91_adc_buffer_init(idev);
> if (ret < 0) {
> dev_err(&pdev->dev, "Couldn't initialize the buffer.\n");
> - goto error_free_irq;
> + return ret;
> }
>
> ret = at91_adc_trigger_init(idev);
> if (ret < 0) {
> dev_err(&pdev->dev, "Couldn't setup the triggers.\n");
> at91_adc_buffer_remove(idev);
> - goto error_free_irq;
> + return ret;
> }
> } else {
> ret = at91_ts_register(idev, pdev);
> if (ret)
> - goto error_free_irq;
> + return ret;
>
> at91_ts_hw_init(idev, adc_clk_khz);
> }
> @@ -1195,8 +1196,6 @@ static int at91_adc_probe(struct platform_device *pdev)
> } else {
> at91_ts_unregister(st);
> }
> -error_free_irq:
> - free_irq(st->irq, idev);
> return ret;
> }
>
> @@ -1212,7 +1211,6 @@ static int at91_adc_remove(struct platform_device *pdev)
> } else {
> at91_ts_unregister(st);
> }
> - free_irq(st->irq, idev);
>
> return 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-08-27 17:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-26 2:29 [PATCH -next v2 0/3] iio: adc: at91_adc: Cleanup with the helpers Jinjie Ruan
2023-08-26 2:29 ` [PATCH -next v2 1/3] iio: adc: at91_adc: Use devm_clk_get_enabled() helper function Jinjie Ruan
2023-08-27 17:11 ` Jonathan Cameron
2023-08-26 2:29 ` [PATCH -next v2 2/3] iio: adc: at91_adc: Use devm_request_irq() " Jinjie Ruan
2023-08-27 17:13 ` Jonathan Cameron [this message]
2023-08-26 2:29 ` [PATCH -next v2 3/3] iio: adc: at91_adc: Simplify with dev_err_probe() Jinjie Ruan
2023-08-27 17:16 ` Jonathan Cameron
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=20230827181317.10ea9aa7@jic23-huawei \
--to=jic23@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=claudiu.beznea@tuxon.dev \
--cc=heiko@sntech.de \
--cc=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=robh@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=yangyingliang@huawei.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