Use dev_err_probe() to simplify the error path and unify a message 
template.

Using this helper is totally fine even if err is known to never 
be -EPROBE_DEFER.

The benefit compared to a normal dev_err() is the standardized format
of the error code, it being emitted symbolically and the fact that
the error code is returned which allows more compact error paths.

Signed-off-by: Shen Lichuan <shenlichuan@vivo.com>
---
 drivers/gpio/gpio-stmpe.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-stmpe.c b/drivers/gpio/gpio-stmpe.c
index 6c5ee81d71b3..6cf545f5fc9d 100644
--- a/drivers/gpio/gpio-stmpe.c
+++ b/drivers/gpio/gpio-stmpe.c
@@ -513,10 +513,9 @@ static int stmpe_gpio_probe(struct platform_device *pdev)
 		ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
 				stmpe_gpio_irq, IRQF_ONESHOT,
 				"stmpe-gpio", stmpe_gpio);
-		if (ret) {
-			dev_err(&pdev->dev, "unable to get irq: %d\n", ret);
-			return ret;
-		}
+		if (ret)
+			return dev_err_probe(&pdev->dev, ret,
+					     "unable to get irq");
 
 		girq = &stmpe_gpio->chip.irq;
 		gpio_irq_chip_set_chip(girq, &stmpe_gpio_irq_chip);
-- 
2.17.1

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>


On Thu, 29 Aug 2024 21:10:51 +0800, Shen Lichuan wrote:
> Use dev_err_probe() to simplify the error path and unify a message
> template.
> 
> Using this helper is totally fine even if err is known to never
> be -EPROBE_DEFER.
> 
> The benefit compared to a normal dev_err() is the standardized format
> of the error code, it being emitted symbolically and the fact that
> the error code is returned which allows more compact error paths.
> 
> [...]

Applied, thanks!

[1/1] gpio: stmpe: Simplify with dev_err_probe()
      commit: 1882e769362b8e4ef68fd30a05295f5eedf5c54a

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

On Mon, Sep 02, 2024 at 11:46:34AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> On Thu, 29 Aug 2024 21:10:51 +0800, Shen Lichuan wrote:

[...]

> Applied, thanks!

Be careful with patches from @vivo.com [1]!

This one in particular missed '\n' (and yes, I know that it's not an issue
for the ev_*() cases).

[1]: https://lore.kernel.org/linux-spi/20240829033511.1917015-1-11162571@vivo.com/
(read full discussion)

-- 
With Best Regards,
Andy Shevchenko

On Mon, Sep 2, 2024 at 12:42 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Mon, Sep 02, 2024 at 11:46:34AM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > On Thu, 29 Aug 2024 21:10:51 +0800, Shen Lichuan wrote:
>
> [...]
>
> > Applied, thanks!
>
> Be careful with patches from @vivo.com [1]!
>

Thanks for the heads-up!

> This one in particular missed '\n' (and yes, I know that it's not an issue
> for the ev_*() cases).
>

b4 didn't complain so I didn't pay attention.

Bart

> [1]: https://lore.kernel.org/linux-spi/20240829033511.1917015-1-11162571@vivo.com/
> (read full discussion)
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

On Thu, Aug 29, 2024 at 3:11 PM Shen Lichuan <shenlichuan@vivo.com> wrote:

> Use dev_err_probe() to simplify the error path and unify a message
> template.
>
> Using this helper is totally fine even if err is known to never
> be -EPROBE_DEFER.
>
> The benefit compared to a normal dev_err() is the standardized format
> of the error code, it being emitted symbolically and the fact that
> the error code is returned which allows more compact error paths.
>
> Signed-off-by: Shen Lichuan <shenlichuan@vivo.com>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij