| Message ID | 20240829131051.43200-1-shenlichuan@vivo.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v1] gpio: stmpe: Simplify with dev_err_probe() | expand |
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
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,
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)
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 > >
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);
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(-)