From: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
To: Thierry Reding <thierry.reding@kernel.org>
Cc: Jonathan Hunter <jonathanh@nvidia.com>,
Mikko Perttunen <mperttunen@nvidia.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
linux-pwm@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] pwm: tegra: Make use of dev_err_probe()
Date: Mon, 21 Sep 2026 14:46:03 +0200 [thread overview]
Message-ID: <arEiVZG7UqxpqAPZ@monoceros> (raw)
In-Reply-To: <arD6ILv1sd8YBUXj@orome>
[-- Attachment #1: Type: text/plain, Size: 4651 bytes --]
Hello Thierry,
On Mon, Sep 21, 2026 at 11:38:41AM +0200, Thierry Reding wrote:
> On Fri, Sep 18, 2026 at 04:33:45PM +0200, Uwe Kleine-König wrote:
> > Usage of dev_err_probe() is more compact than dev_err()'s, emits the
> > error code and handles -ENOMEM and -EPROBE_DEFER properly. Benefit from
> > these improvements.
> >
> > Also add a few messages in error paths that lacked an output before.
> >
> > Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> > ---
> > drivers/pwm/pwm-tegra.c | 52 ++++++++++++++++++++++++-----------------
> > 1 file changed, 31 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
> > index 5cdbe120ba2d..efb7ab60f602 100644
> > --- a/drivers/pwm/pwm-tegra.c
> > +++ b/drivers/pwm/pwm-tegra.c
> > @@ -316,14 +316,15 @@ static const struct pwm_ops tegra_pwm_ops = {
> >
> > static int tegra_pwm_probe(struct platform_device *pdev)
> > {
> > + struct device *dev = &pdev->dev;
> > struct pwm_chip *chip;
> > struct tegra_pwm_chip *pc;
> > const struct tegra_pwm_soc *soc;
> > int ret;
> >
> > - soc = of_device_get_match_data(&pdev->dev);
> > + soc = of_device_get_match_data(dev);
> >
> > - chip = devm_pwmchip_alloc(&pdev->dev, soc->num_channels, sizeof(*pc));
> > + chip = devm_pwmchip_alloc(dev, soc->num_channels, sizeof(*pc));
> > if (IS_ERR(chip))
> > return PTR_ERR(chip);
> > pc = to_tegra_pwm_chip(chip);
> > @@ -331,28 +332,39 @@ static int tegra_pwm_probe(struct platform_device *pdev)
> > pc->soc = soc;
> >
> > pc->regs = devm_platform_ioremap_resource(pdev, 0);
> > - if (IS_ERR(pc->regs))
> > + if (IS_ERR(pc->regs)) {
> > + /*
> > + * devm_platform_ioremap_resource() already emits an error
> > + * message with CONFIG_HAS_IOMEM, so don't emit another message
> > + * here.
> > + */
>
> Seems a bit counter-productive to leave comments like this. Function
> comments should document what the function does and then people should
> read those comments. Then we don't need to mention it every time we call
> these functions.
I often deal with bug reports by users where things fail without an
error message[1]. So a usual thing I do is checking probe (and other)
functions for silent error paths. As I fail to follow the (continously
changing) set of functions that emit an error message, this comment is
very useful for a me at least and I'd wish others would add such
comments, too. (An IMHO fine thing here would be to let no generic
resource getter function emit an error message, but that ship has
sailed.)
I'd be open for a shorter marker, that might even be machine-parsable.
> > return PTR_ERR(pc->regs);
> > + }
> >
> > platform_set_drvdata(pdev, chip);
> >
> > - pc->clk = devm_clk_get(&pdev->dev, NULL);
> > + pc->clk = devm_clk_get(dev, NULL);
> > if (IS_ERR(pc->clk))
> > - return PTR_ERR(pc->clk);
> > + return dev_err_probe(dev, PTR_ERR(pc->clk), "Failed to get clock\n");
> >
> > - ret = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
> > - if (ret)
> > + ret = devm_tegra_core_dev_init_opp_table_common(dev);
> > + if (ret) {
> > + /*
> > + * devm_tegra_core_dev_init_opp_table_common() emits an error
> > + * message most of the time, so don't add another.
> > + */
>
> Same here.
>
> > @@ -385,17 +395,17 @@ static int tegra_pwm_probe(struct platform_device *pdev)
> >
> > ret = pwmchip_add(chip);
> > if (ret < 0) {
> > - dev_err(&pdev->dev, "pwmchip_add() failed: %d\n", ret);
> > + dev_err_probe(dev, ret, "Adding pwmchip failed\n");
>
> This stands out as very different from other error messages, so maybe
> change this to something like "Failed to add PWM chip" for consistency?
Fine for me, will fix in the next submission.
Thanks for your feedback,
Uwe
[1] last instance was just today, where on a bananapi USB didn't work
and /sys/kernel/debug/devices_deferred ended up containing:
1c13000.usb platform: supplier 1c13400.phy not ready
1c1c000.usb platform: supplier 1c13400.phy not ready
1c14400.usb platform: supplier 1c13400.phy not ready
1c13400.phy platform: supplier axp20x-usb-power-supply not ready
1c14000.usb platform: supplier 1c13400.phy not ready
1c1c400.usb platform: supplier 1c13400.phy not ready
axp20x-usb-power-supply
It would be so easy[2] to add a useful debugging hint here
[2] https://lore.kernel.org/all/b699f8251afed736af454a981630926e45eb7da7.1789983244.git.ukleinek@debian.org/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-09-21 12:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 14:33 [PATCH v2 0/3] pwm: tegra: Cleanups and .get_state() Uwe Kleine-König
2026-09-18 14:33 ` [PATCH v2 1/3] pwm: tegra: Make use of dev_err_probe() Uwe Kleine-König
2026-09-21 9:38 ` Thierry Reding
2026-09-21 12:46 ` Uwe Kleine-König [this message]
2026-09-21 16:14 ` Thierry Reding
2026-09-18 14:33 ` [PATCH v2 2/3] pwm: tegra: Check for match_data being NULL Uwe Kleine-König
2026-09-21 9:47 ` Thierry Reding
2026-09-21 14:34 ` Uwe Kleine-König
2026-09-21 16:24 ` Thierry Reding
2026-09-21 20:10 ` Uwe Kleine-König
2026-09-22 8:33 ` Uwe Kleine-König
2026-09-22 10:06 ` Thierry Reding
2026-09-18 14:33 ` [PATCH v2 3/3] pwm: tegra: Implement .get_state() Uwe Kleine-König
2026-09-21 10:18 ` Thierry Reding
2026-09-21 14:26 ` Uwe Kleine-König
2026-09-22 10:07 ` Thierry Reding
2026-09-21 10:22 ` [PATCH v2 0/3] pwm: tegra: Cleanups and .get_state() Thierry Reding
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=arEiVZG7UqxpqAPZ@monoceros \
--to=u.kleine-koenig@baylibre.com \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mperttunen@nvidia.com \
--cc=p.zabel@pengutronix.de \
--cc=thierry.reding@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®